Transport Layer Security (TLS) Minutes Meeting : IETF 78, Thursday 29 July 2010 Location : MEC Maastricht, Chairs : Joseph Salowey , Eric Rescorla Minutes : Paul Hoffman Version 0 =========================================================== Agenda 1. Administrivia (5 Min) Notetakers,Jabber,Blue Sheets,Agenda,Note Well etc 2. Cached Information Extension (15 min) - Santesson http://tools.ietf.org/html/draft-ietf-tls-cached-info-09 3. AES-CCM ECC Cipher Suites (10 min) - McGrew http://tools.ietf.org/id/draft-mcgrew-tls-aes-ccm-ecc-00.txt 4. SSL MUST NOT (10 min) - Turner http://tools.ietf.org/html/draft-turner-ssl-must-not-01 5. TLS Server Cert Identity (10 min) -- Saint-Andre http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-08 ============================================================ (Things from the slides not copied here. You must read the slides to get more details) 1. AES-CCM ECC Cipher Suites - David McGrew - draft-mcgrew-tls-aes-ccm-ecc-00.txt Main goal: compact implementation reusing crypto already on the platform Four new cipher suites Want to use use the same ciphersuites, doesn't have to interop with web browsers - draft-mcgrew-tls-aes-ccm-00.txt Specifies RSA and PSK usage If concerned about cert size, see draft-pritikin-comp-x509 GCM would use less power, but CCM is already in the device Ekr: Wants more than one draft, concerned about the use of the ciphersuite for things which there are other indications in the protocol How much bandwidth is saved by this? Wants a CCM doc for RSA ciphersuites on standards track Bob Moskowitz: Why only 8 byte ICV Dave: The draft does have 8 and 16 2. Cached Information Extension - Stefan Santesson - draft-ietf-tls-cached-info-09 Lots of earlier discussion Didn't want to break the security properties of the Finished calculation Not clear what the attack is here - This does not work for TLS 1.1 Thus use the PRF function instead But we don't have a hash identifier for the PRF So maybe use a "select", or maybe do it by TLS version Ekr: Don't guarantee 2nd-preimage protection, so why do this? Not pro-PRF Prefers "just use SHA-1" Doesn't need to be coupled to the ciphersuite Must be one of the functions that the client is using in the signature algorithms Client doesn't know in advance which digest will be selected Stefan: There are many acceptable solutions Problem is finding one that has enough people to be acceptable If you're using SHA-1 in your certificate and it is broken, you're dead anyway Thinks that the proposal would work technically, but would be weird to use in TLS 1.2 Paul Hoffman: Wants to use a hash from the cert, and don't use "select" Ekr: Do we agree that if I offer a cached object and the server replies it in the response The server must respond Very scared of any mode where you must know if the server replaces it Stefan: This works in reconnaissance Will propose to the list 3. SSL MUST NOT - Sean Turner - draft-turner-ssl-must-not People didn't agree with the prohibition of SSL 3.0 The headers of the document says it updates TLS Making a new draft explaining some of the issues with different versions Ekr: Wants this to be a WG item in order to get consideration here WG agreed to take the document into the WG with Sean as author 4. TLS Server Cert Identity - Peter Saint-Andre - draft-saintandre-tls-server-id-check-08 There will be a last call in TLS Request for volunteers to review Wes Hardaker Jim Schaad Joe and Ekr Sean Yngve Jeff Hodges: People who work in the CA Browser Forum should also get reviews Ekr: Doesn't like the prohibition on multiple CNs Many browsers support them Peter: Trying to get consensus Seem current consensus that it is acceptable to have multiple Perhaps say "some implementations don't support this so be careful" This strongly encourages the use SAN Stefan: Question of whether this is in the same RDN? Answer: Probably Jeff Hodges: Paul T from Digicert says that they are going to start supporting SAN Original intent of the spec was for how clients handle certs, not what CAs should put in certs Peter: Reached out to the CA community but didn't get much response Certificate surveys happen; one will be announced at Defcon by EFF Ekr: also did survey Different results for port scans than looking by name Peter: This can get updated at some point when we have more experience Ekr: Question of status Stefan: Issue of name constraints Lots of hacks on how to do it Reason to deprecate CN Ekr: Need to see how this document interacts with other documents that have guidance Peter: Future documents can point to this Ekr: Could do a 2818bis to follow this, but this does not affect 2818 Stefan: pointed out that the rule of checking CN if not SAN may be a security problem because of name constraints Ekr: wait for a new version Will solicit more reviewers Will wait a week Do a WG Last Call