IETF-85 TLS (Transport Layer Security Meeting Minutes) TUESDAY, November 6, 2012 - 1700-1830 Chairs: Joe Salowey and Eric Rescorla Minutes: Paul Hoffman Version: 1 ---------------------------------- 1. Note Well, Agenda, Note Takers, Blue sheets (5 Min) ---------------------------------- 2. Cached Info (10 Min) - Stefan Santesson http://tools.ietf.org/html/draft-ietf-tls-cached-info-13 Stefan: Some change of syntax, but no changes to bits on the wire Adam Langley: Why is this a vector of cached objects? Stefan: didn't want to constrain the server to doing just one Eric: Yes, there should be just one type Hannes Tschofenig: It is a vector of just one in the response But it can be more than one in the request so the client can ask for many Robert Cragie: Maybe should be able to cache the intermediate certificates Zigbee wants smaller packets Hannes: if the trust anchors are different, the fingerprints would be sent for the trust anchors Stefan: Maybe some optimization, If we have to split the object, the hashes are impossible to match Chairs: In favor of adding support for intermediate certificates? Not many people voted but 4 were against and 1 supported the idea ------------------------------------------------------------------------------- 3. Certificate Status Extension (5 Min) - Joe (for Yngve Pettersen) http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02 Removed SCVP Ready for WG Last Call ------------------------------------------------------------------------------ 4. Out-of-band public key validation (15 Min) - Hannes Tschofenig http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06 Hannes: Clarified SubjectPublicKeyInfo usage, Copying the full ASN.1 structure Hannes: Remove dependency on RFC 6091, which is Informational; Removed OpenPGP keys Chairs: Hum for supporting raw public key from one side and password on the other: most supported this Eric Rescorla (Ekr): some debate about whether we should be using the same mechanism/registry as RFC 6901. There is general consensus on the desired properties and a question about whether RFC 6091 could support it. EKR to analyze and report back, will take this to the list --------------------------------------------------------------------------------------- 5. HTTP 2.0 Update - Mark Nottingham (10 min) Mark: Request from httpbis WG Working on HTTP 2.0 How does one get from HTTP 1.x to 2.x How does one do that in the TLS handshake? Eric: Is this work the WG should take on? Mark: People will do it anyways Adam: We should do this Sean Turner: If this WG doesn't do it, might shut down the WG Yoav Nir: We should do it Derek Atkins: If this isn't done in TCP, why should it be done here Dan Wing: There are proposals to put this in the TCP SYN Yoav: It is like ports Mark: Wants this to be generic Paul Hoffman: Supports NPN Brian Smith: Do we want people to use non-standards? Wants it to be efficient. Chairs: Take Hum -- Everyone thinks we should work on this --------------------------------------------------------------------------------------- 6. Origin Bound Certificates update (10 min) - Adam Langley Adam: Why we are not talking about OBCs Now we don't want to use client certificates: - Don't want to send user ID in the clear, Thus can't send it in the regular place in handshake - Uncomfortable about servers passing arbitrary ASN.1 - Might want to move the keys into TPM - OBC must Become part of the session state, too much data - So they weren't really client certificates, you can't use client certs and OBC at same time Now just doing key pair and signatures Hannes: Why don't you use the raw public key Adam: Would have only fixed some of the problems Eric: Is this something that will come back into the WG? Adam: Yes Eric: Is there any intention to do other than ECDSA Adam: Will do what needs to be done A draft is coming soon, not sure of the time scale Brian: Is this going to be specified for protocols other than HTTP? Adam: Will need to use channel bindings in HTTP 2.0 Not thinking of things other than HTTPS Eric: Can this all be done in HTTP 2.0? If NPN fails to HTTPS, it's not clear where the user ends up Could make some users into a low-security state Richard Barnes: XMPP is also working on multiple channels across one connection --------------------------------------------------------------------------------------- 7. DTLS Multicast Security (15 Min) - Sye Loong Keoh http://tools.ietf.org/html/draft-keoh-tls-multicast-security-00 Sye Loomg: Securing group communications CoAP makes us to want use group security Derive multiple keys for different parts of multicast from RFC 3830 (MIKEY) Matthew Kaufman: What does the MAC protect? Sye Loong: Same as DTLS. Matthew: Missing an opportunity to protect a DoS because the sequence number is not there The more state you can transmit, the more you will know about attacks going on Cullen Jennings: This is an important use case We don't have other mechanisms that are viable to use Likes the work Adam: Does the lightbulb (simple device) need to generate randomness? Looking at sequence numbers gives you order, not freshness Yoav Nir: No source authentication A rogue lightbulb can turn off other ones Sye: the assumption is that the lightbulbs will receive only Brian Weiss: TESLA is not that expensive And would solve some of the replay issues Sye: Requires time sources? Brian: Talk offline Important to keep the policies separate Why are you downloading the random instead of getting the server to do the group key? Eric: Two different technologies that are folded together No actual TLS work in this Robert: Worried about nonce reuse Key update is difficult Unknown: Threat model might require source authentication -------------------------------------------------------------------------------------- 8. TLS Tack (15 Min) - Trevor Perrin http://tools.ietf.org/html/draft-perrin-tls-tack-01 Trevor: Allows a server to assert pins, works well with other auth methods Server sends a mini-certificate just for pinning Can be expired and revoked Activates pins go longer each time, up to 30 days Lots of questions for private key handling Typical for other systems Discussion of other types of pinning Combining Tack with them Signature-based approach has advantages CA pinning is complicated Introduces weak links Who is the audience for pinning? Is locking to CAs a good model? Worth thinking about multiple approaches Ryan Sleevi: HTTP key pinning is not just restricted to CA hierarchy Trevor: give people their own key ------------------------------------------------------------------ 9. Authz Extension to use TDCP Certificates in TLS handshake - Darshak Thakore draft-dthakore-tls-authz Darshak: Want to enable smaller devices to use current certificates for new services They already have these (TDCP) authorization certificates which are not the same as necessarily client certs. Cable Labs has IPR