TLS Friday, August 2, 0900 Eric Rescorla and Joe Salowey, chairs Minutes taken by Paul Hoffman (Text from the slides is not repeated here) Administrivia happened Document Status         draft-ietf-tls-oob-pubkey-07                 Ready for IETF Last Call         draft-ietf-tls-pwd-00                 Wants more discussion on the list         draft-ietf-tls-cached-info-14                 Relevant to the DICE BoF, so we should meet their needs                 Hannes Tschofenig: Has one remaining item related to what is to be cached                         Should we wait for data, or should we move ahead?                 Ekr: Hasn't gotten data yet, notes lack of enthusiasm                         If DICE wants it, we'll find the energy                 Sean Turner: Let's get it out the door                 Ekr: Just do the changes ALPN         Steve Friedl         draft-ietf-tls-applayerprotoneg-01         Has a code point assigned by IANA         Yoav Nir: Didn't know we would do TLS 1.3                 Private was for clients that don't do HTTP inside                 Don't want to have to write a separate draft for the string         Joe: Ready to go to WG Last Call after the meeting TLS 1.3 Discussion         Ekr         More protection for data in handshake         Is there enough to do         Is there consensus for the big pieces         Lots of proposals for cutting down the number of round trips                 The server will need to agree, but then         Wes Hardaker: Will we be doing DTLS 1.3 as well?                 Ekr: Yes, in parallel         Some problems with replay attacks, but can be dealt with with sequence numbers         More protection is also needed for RTCweb                 Want to hide both certificates         Yaron Sheffer: IKE doesn't protect many extensions                 Ekr: Need ability to protect some extensions, some identity         Paul: How will the WG be discussing the two major issues?                 Ekr: Will discuss them at the same time because they interact         Derek Atkins: This feels like it will add a round trip back in         Stephen Farrell: We should agree that one part of the target will always in scope         Have TLS strip out all the stuff about composition of ciphers, only use AEAD modes         Joe: We would need AEAD descriptions of current cipher suites         Derek: We could also do EtAtE         Yaron: Would someone who wanted a particular suite have to come to the TLS WG?                 Ekr: Probably yes         Paul: Might add version number to the ciphersuites to make 1.3 specific         Make the random longer                         Russ Housley: When there is a bad random generator,                 you really want key uniqueness from these                 Ekr: If either side has a good generator you should have                      uniqueness [though a good PRNG is needed for secret data.]                 Paul Wouters: The date helps identify the client                 Ekr: If the servers are relying on this, they might choke                         Let's relax the restriction but do some research                 Wes: Doesn't believe that more bad random is better than less bad random         Maybe go to Chinese menu         Maybe: "Your ciphersuite needs to meet a certain bar"         Jim Schaad: We should reduce the number of variations, or go to Chinese menu         Hannes: Maybe use the IKEv2 handshake instead                 Making massive changes with a different state machine         Sean: Hearing from implementers that there are too many to implement         Tero Kivinen: Maybe we can use IKEv2 while using TLS packet format                 Might have a completely new state machine anyway                 Ekr: I think we can do better than that         Hannes: Which other WGs do we need to ask?                 Ekr: Enough to motivate with rechartering, ask them to feed us their requirements         Zach Shelby: Let's look at the DTLS fragmentation state machine         Sean: Maybe do reverse TLS to support NETCONF?         Paul: Maybe move some popular extensions into the main document         Almost everyone wanted to do this work. TLS Channel ID         Dirk Balfanz         draft-balfanz-tls-channelid-01         IPR status: not aware of any patent applications         Will do what they normally do when handing over to the IETF         Main idea: give more security to application protocols         Hannes: Looks similar to the OOB document                 Dirk: Let's talk         Been running this for six months         Are using it for cookies on Google servers         Seeing problems when it is set behind a proxy but then goes outside of the proxy         Revocation in wired in the UI         Ekr: This seems tied to ECDSA                 Current draft has it hard-coded to a particular curve                 Might have some negotiation for crypto built in                 Maybe better to just do it as a new extension         Certain that they want this extension encrypted         Joe: Is this somewhat related to session resumption or session ID?                 Dirk: Sessions are not long-lived enough: weeks vs. hours         Richard Barnes: This is like a bearer public key                 Maybe just roll this into TLS 1.3                 Dirk: Might be a good way forward         Tobias Gondrum: Could this be used to replace cookies?                 Dirk: Some servers have more than just a sesssion ID in cookies                         Lets you choose whether or not to use cookies                 Jeff Hodges: Getting rid of cookies would be a huge change         Alfredo Pironti: If we want to protect the identity of the user, do this in 1.3         Hannes: Will do a comparison with OOB, which is now in IETF LC         Ekr: How sure are you that this is the right design?                 Dirk: We're much happier with this now, is in "Stable"         Brian Smith: Mozilla has some interest because of client privacy                 Worried about user experience for user experience                 Dirk: Changing the key will be like cleaning out the cookie jar                 Makes more sense to do at the application layer because you can                 Google doesn't carry channel IDs to third-party sites         Richard: This is the TLS WG, not the HTTPS WG         Robin Wilson: Going to a farm, they send an identifiable cert         Stephen: Not sure where this sits now because we don't have encrypted extensions now         Ekr: Doesn't want two things that are not very different that are doing the same things         Brian: We have lots of options that we can think about Salsa20         draft-josefsson-salsa20-tls-02         Nikos Mavrogiannopoulos         Cannot have a fast cipher in DTLS         Ekr: Questions the values in the comparisons         Yoav: If you have NI it is much faster         Derek: Doesn't believe the measurements                 Alfredo: Maybe we need some comparisons across platforms         Ekr: Need to make comparisons on optimized implementation         Quynh Dang: Thinks that SHA1 should not be as slow as UMAC                 Thinks the results are surprising         Brian: More interested in constant time than the speed improvement         Ekr: We rejected the design because FIPS requires the IV inside the crypto boundary                 Need to consider design consistency         Paul: This calls back to the Chinese menu         Dan Harkins: Likes the idea of doing something like this                 Hopes that there is not going to be an explosion of ciphersuites: don't do SHA-1         Sean: Is this one the best from the competition?                 Nikos: No, it's just one of the five winners         Joe: Wants guidance from CFRG for stream ciphers                 Kevin Igoe: CFRG will take this on                 Ekr: Wants advice on Salsa, on UMAC, and number of rounds TLS Length Hiding         draft-pironti-tls-length-hiding-01         Alfredo Pironti         TLS does not protect the length of messages that are being exchanged         Padding is not being used effectively         Yoav: Similar to an extension of IPsec that was rarely used                 Alfredo: Application can tailor the size                         Can go to next fragment size         Hannes: Wants more data                 Alfredo: Link is in the draft Other:         Yaron: wants to do a document on how to do 1.2 securely today