IETF TLS Working Group Interim Meeting Dates: May 15-16, 2014 Location: 1899 Wynkoop Street, Suite 600, Denver, CO, USA Chairs: Joe Salowey, Eric Rescorla, Sean Turner Note Taker: Jim Schaad Revision: 1 =========================================================== Attendees ========================================================== Eric Rescorla Martin Thomson Wan-Teh Chang Sean Turner Joe Salowey Daniel Kahn-Gillmor Hovav Shacham Steve Checkoway Rich Salz Brian Sniffen Charlie Gero Erik Nygren Andrei Popov Jim Schaad Andy Lutomirski Joe Hall Quynh Dang Alfredo Pironti David Holmes Tom Ritter Mike St. Johns Joe Hildebrand Matt Miller (part of day 2) Day One (15 May 2014, 9:00 am - 5:00 pm MDT) =========================================== Review of agenda * Introductory materials (Note well) * Agenda bashing - ** Swap the SNI and triple handshake agend Day 1 Agenda ----------------- - Get Settled, Administrivia, Agenda - Encrypt SNI or not - Fixing Session Resumption (Triple Handshake) - Client Puzzles - Discuss Handshake Flows **** Start with EKR presentation on SNI Desire to get a strong consensus on where the SNI is going by the end of the meeting MSTJ (Mike St. Johns) - this is the only thing not used by TLS - Martin (Martin Thomson) - put them on a wild card server Sean (Sean Turner) - do nothing not an option MSTJ - proxy setup - put work factor w/ the side the benefits Alfredo (Alfredo Pironti) - What is fail hard EKR (Eric Rescorla) - will not connect at all for pre-knowledge fail hard - fail soft - then go though the full protocol MSTJ - if publish public keys - then a transition problem EKR - do future pending martin - makes moving servers around harder MSTJ - talking about inserting a layer 3.5 in the net mapping from application/naming to multiple sites on single IP set virtualization of IP addresses - should this be in the stack? use multiple ip addresses on single location wait until it gets fixed elsewhere JoeH (Joe Hildebrand) - if TLS 1.3 does not allow similar scenarios as 1.2 then adoption problems DKG (Daniel Kahn Gilmore) - problems with multiplexing 1.2 and 1.3 on the same port Erik (Erik Nygren) - lack of SNI is blocking some deployment for TLS ***** ERIK Nygren presentation Brian (Brian Sniffen) - most up to date python has SNI Charlie Gero - active attack look @ SNI to drop connections - DOS attacks Erik - does really not wnt to entertain dropping SNI Rich (Rich Salz) - does death of XP help? Erik - XP is std boogey man - but is only 20% android is much bigger problem DKG- androids are not being updated Brian- passive adversary - is generic NSA one - ATT will look at DNS and addresses - for advertising if used encryption - then they are not passive because they own DNS JoeH (Joe Hall) - Turkey was blocking DNS requests from some spaces DKG - we are talking about the intentions of the handshake not the data brian - timing attacks against hTTP over tls my lead to leak of information on which page can protect secrets but not privacy. Tom - assuming closed world of pages encrypted SNI is trying to protect against closed world brian - assume attacker knows which systems are on which ip addresses tom (Tom Ritter) - recap of mail message from today dkg - questions on TLS padding - why bother if somebody else might leak alfredo - need to have corporation on the websites on the shared location to shape traffic to make things better masked brian - case of wikipedia - is there a recipe to protect for a single site tom (Tom Ritter)- miller paper presents way to do this erik - how do you modify enough content providers to go through the effort to do this. wtc (Wan-Teh Chang) - examples of sensitive web sites are virtual hosts? confused about the severity of this problem ekr - not chartered to be tor - is there something we can do to make life better - ekr - on appendix slide - questions erik - return enough information to clean up - rotate to prevent building lookup tables JoeS (Joe Salowey) - on pictures page - does the multiplexor operator (TCP forwarder) need to be protected Erik - TCP forward would need to deal with protection of the encrypted stream to know the forwarding material ekr - covers what you need - don't need to have strong shared key material erik - DNS will cover the requirements for these cases - don't need to have just decrypts sni info to forward. design discussion from ekr on how a middle box could be configured for triggering ekr - first time give up is a way of not doing - then get token back - token returned encrypted ***** DKG & Tom slide deck ekr - client start w/ no info on the server gets the data from the dns dns middle boxes strip dnssec forces you into the posture I want you in dkg - in the future there will be clients willing to do a lock down if not all conditions are met erik - want to have a whole picture not build piece meal ekr - on danish slide - thinking DH group and public requires a new decryption (group operation) on each new connection mstj - guy managing middle box is now managing key material and publishing to dns --- question on why if you get dnssec then do 1.2 cannot distinguish w/ middle box that is stripping all dnssec that kills everything tom - people behind load balancer can leak the information in lots of ways - more than just ing the key id as an SNI brian - customers which are highly sensitive to delays - may be willing to leak the SNI information ekr - why not carry algorithm in message some agreement is that this consumes bandwidth ekr - people who remove stuff from the protocol live to regret it this is all public info -why not send it *** BREAK Andy (Andy Lutomirski)- presentation on ideas - no slides IP mask_id mask_ pubkey mask_algo mask_overhead - excess bytes to emit tls version hard/soft fail Enc function: indistinguishable from random and non-malleable (intermediate can't monkey and get something that works) C->S contains hello TLS 1.3, masked hell [ real hello] = mask_id, Enc(maked_pubkey) front end can deal with start - decrypt and just forward everything else ekr - only info needed is server group encryption can be symmetric return using new serverHelloMask for how the server encrypts back ekr - this and last presentation seem to be similar - just difference in focus tom - agreed - just different parts of it ekr - what is in the finish messages? dkg - would be nice if there was a MITM for the pre-handshake details tom - include extension w/ hash of pre-handshake inputs Discussion on using a key vs a token (previous EKR proposal) Tom - loses security on multiple clear uses ekr - discussion on resumption has not happened - leak data then ekr - the designs appear similar complexity of the coordination of key material with the designer complexity of crypto in the load balancer sync between clients and and load balances roll over erik - use of ip addresses may be problematic for DNSSEC combinations between ip addresses and dns names hovav (Hovav Shacham) - cannot bind between the security properties of the balancers and the server * if you include info about the balancer info erik - big difference in the security level - mask is a good name for what the balancer has ekr - proposals are all interconnection w/ DNS DNS dependencies needs to not be required DKG - don't needs DNS for one more RT DKG - re-handshake - in the case of no info ekr - should have this ode and allow for a method of doing SNI in the clear as well. brian - when get a wild card cert - cache this - then use then SNI for the wild card name If keep info in the browser then can get to zero RT case. ****** Lunch Sean - AD has sent message with suggestion of hashing the SNI - room - not much value of just hashing MSTJ - can we split the SNI out of TLS to some other layer? make the client build and encrypted SNI and supply -- does not deal with the APLN MSTJ - the SNI needs to be dealt with by non TLS entities - APLN could be inside of the TLS connection - setup key material before doing things one possibility is to visit an external side to get the information for this and off load ll of the data can be symmetric decryption of the tag and then route tom - leads to most people will send clear and rest will send SNI replacements - can allow both non-encrypted and encrypted key id/sni pairs Discussion on how a nation state will block this - block anything with an encrypted SNI - block the protocol that gets the SNI - country will not allow for TLS 1.3 Discussion of number of EC operations - one for the load balancer - two or three for the client and server? Problem is you make the load balance into the world of crypto, auditors, additional managers DKG - in that case keep an encrypted SNI that is just simple lookup EKR - problem is where does the client get the data is even bigger - problem doing a combined approach is additional complexity with fallback question of the NIST community using a non-nist curve for this purpose. problem with auditor -- don't go there Different types of algs for the pre-handshake ekr - question on what to do if the first DH group is not supported by the server. difference between one time sni tokens - and replay detection tokens - they have different requirements of security - - one needs to just keep some state - needs to be able to rebuild from the token, EKR - political question - people who deploy the big systems - really excited about mandatory to use encrypted SNI brian - mandatory encrypted SNI is a wonderful dream - - many big providers stay on 1.2 if too hard erik - for the case of optional bootstrap from the DNS - worry about the fact that at scale people are going to be fine, but for small people it might be a real issue - Fallback to two round trip if it is too complicated ?? - If share info - then can approach a 1RT over time - shared info would be keys and who you can talk to Return the set of information on a query from the client can be hit by active attackers - but not passive ones loose one RT only on first connection - can then cache the info Discussion of SRV and other types of records Sean - how do we summarize this? Erik - having an option that allows for optional client hello encryption by putting bootstrapping in the DNS appears to have no strong objections MSTJ - issue of discussions between the dns and http administrators - what happens with wrong information? - no extra costs for the server if things are not up-to-date Erik - the complexity is getting so high that leaving things in the clear are simpler - DNS is the only way not to have the layers of security. MSTJ - forget about SNI issues Client Server ---->Ephem Propsed ----> <---- Ephem Ack ---- at the end you have shared secret on both sides - need cipher neg somewhere -----CL----> all of these lines are encrypted <---- Sever---- Erik - should the first piece be at the TCP-crypt layer not in TLS MSTJ - the SNI is not part of the TLS negotiation the rest of this does not need the DNS crap in the TLS world ??? - pre-routing stuff is part of routing info routing does not appear to be in the proposal - how to you get securely to the right virtual server. brian - where is the consensus - should not abandon SNI - problem should not require SNI for all 1.3 (YES) ---- room pushes back - allow encrypted SNI for all who wants it (YES) - require support for encrypted SNI - (NO) - allow many round trip encrypted SNI - (??) - propose a DNS mech for keys - (??) - Support all three of the pictures from Erik's pictures (YES) * single name * virtual host * multiplex router if join 5 and 6 then needs to deal with complexity MSTJ - appears to believe that there is a difference between one and two routes for the pictures Early adopters - would do 2 RRT for things MSTJ - is there a caching requirement? EKR - if out of band mechanism then May be able to do clear cache on failure rather than TTL Worry about long term caching may lead to tracking attack - ala beast? Stored state on the client leaks info about the client === Sense of the room === 1. KEEP SNI - unanimous 7. Keep all 3 SNI modes for 1.3 - YES ** prolonged argument if the middle box is allowed to do crypt or if it must rout based solely on bit-string match * existing topologies * only an issue for looking at servers on the same site. * ekr - browser would do it if saw that it was there and not if not. 2. Require any SNI for TLS 1.3 if start w/ DNS address moving the bar forward to get SNI there. Consensus - Yes * (needs to have word smithing for MUST/SHOULD wording) 3. Allow encrypted SNI - - go to 2 RT if the client has no information about server large argument about the fact that SNI needs to be known to route in order to do the item - first argument is on the SNI vs client hello * Consensus - seems to be Yes but lots of questions about how to do it. 4. Require support for encrypted SNI - * TLS modes that do not involve encrypted SNI will exist * Can either side force it and on what conditions * server can at best hint to the client * servers must support both ESNI (encrypted) and plan text SNI and should have an announce method to do it. * More useful for client to force server than reverse Working on the whiteboard Client Load Balance Virtual Host Virtual Server MK (to dns) |--- {CH}mk---->| | ----- CH -------|----------------->| |<--------SH------------------------------------------| |------ UH?---->| |<---- MK_pub---| Only supports passive attacker - allows for MITM for this case 8. clear SNI must not get worse than it is today - YES 6. propose DNS mech - DEFER - see what happens EKR - recap Will defer 4 and 5 until tomorrow ****** BREAK **** Triple Handshake Alfredo gives Fast review of the problem questions: what type of extension do we do this? ekr - question on buffering data until the hash is known - what is the hash alfredo - 1.2 use the PRF - for older use the SHA1-MD5 pair ekr - clients must buffer entire hello for all hashes which are used wtc - finish message hand shake has worse properties than this ekr - allows both the client and the server to object arbitrary amounts of data into the key computation - client can add in random weird extensions to have arbitrary data - server is more restricted as it just has the server.random MSJT - has proposal for changing out the functions - the current ones have not be analyzed for the way things are used - use the 801 KDF functions since they have been analyzed for this type of thing alfredo - Is there a problem for using a smaller number of bytes for the input to the master secret derivation function? MSJT - does not mix in a positional value but does it recusively EKR - look for somebody to look at this question EKR - why se the hash Wtc - because we are already computing H(handshakes) for the finish message Sean - will take an action item to get the two questions looked at. ekr - what is the indicator> - use an extension makes more sense - do the same thing for 1.3 - should the indicator be echoed? ** from the list recommend prevention of resumption and re-negotiation ekr - no mitigation for channel bindings - some for certificates - client and auth ** - put in the correct security considerations for what happens if you don't do it correctly. and what is broken. Andy - should we make the exporter be at one level removed to deal with the fact tht some labels are currently restricted. JoeS - not to make too many changes unless they are within the scope of things to be fixed ekr - preference not to fix at this time erik - question about DTLS is that a question ekr - it is deterministic already - need to put into this draft ++ CONSENSUS SUMMARY - In room to adopt the triple handshake fix pending analysis of the exact construction by cryptographers. Need to solicit that analysis by at least two people. **** Client Puzzles Discussion led by Erik Nygren Need to do some modeling of how do the different offload methods compare - sleep vs puzzle vs throttling vs ? Look at the cost effectiveness of the botnet for solving the problems vs other attacks it could be doing. Easier to parlellize the wait problem than the client puzzle problem. ++ CONSENSUS SUMMARY - no real consensus in the room for where to go from here. Questions on the value of puzzles versus other rate limiting schemes. Day Two (16 May 2014, 9:00 am - 2:00 pm MDT) ============================================== Revised agenda 30 min on padding return to hand shake A (Alfredo Pironti) - Padding issues traffic analysis attacks based on size of message since no padding stream ciphers are easy - right length block ciphers - small fuzz but not much random length padding - not useful if sending id multiple times as padding is different each time - look at the shortest propose change function to AEAD(K, AD, P) --> AEAD(K, AD, P, TargetLength) TargetLength is policy input from the application Keep the code in TLS to keep multitude of different methods from appearing Tradeoffs on bandwidth vs privacy is a function for the application MSTJ - objecting to any additional bytes in the plain text JoeS - would it make sense to make this at the context rather than on a send api? A - Yes it would be cool Can hide length of certificate if already encrypting Fragments is referring to the TLS fragmentation size ? - What happens if stacked up TLS send records - these can be combined - Discussion on flushing A - Currently not helping even if you consolidate - does not change shaping - ok to send fragments that are pure paddings - to keep traffic shape consistent - HTTP browsers are being proactive about getting http links as soon as seen - leaks information about where the link is in the page - even w/padding - while good idea to have buffering of n packets - number of packets can be part of the size - but no-one would implement it. EKR - allows for retrofit of current system with ability to have anonymity. ? - what data is to be put into the padding A - mac is computed on the entire pad + plain text - in principle does not matter what the content is could be all zeros Outside of TLS processing may still be variable based on the length of the data this may give a timing channel Erik - if we look at crossing the pad boundary - if you can do the statistic analysis to figure out when you are crossing the boundary - then can look at things A - yes - if attacker can control some data - then it can get length DKG - does this make it harder for an application to do it's own padding. EKR - should it mandatory or optional? given possible attacks from the other side + two bytes waste - may want to this to be optional If looking at from a streaming - then will inject padding in the middle since it is streaming If trying to make all files the same size then would need to pad at the end needs to be application not TLS based EKR - we are looking at consuming a large amount of bandwidth - 2 bytes per records - last night we were talking about killing the version just to save the two bytes - 2 bytes over tons of records is significant bandwidth JoeH - would be happy with guidance on how to do this with various protocols - ?? - if in an extension - then could block if is clear ? - SSH changed to encrypt record length headers - DTLS is leaking record boundaries - so encrypting headers there is waste? SSH has possible attack based on the fact taht the length is encrypted EKR - willing to do this as long as cheap JoeH - started as excited - then went to make the app deal with it. MSTJ - what about the handshake? * - some agreement that we need this for the handshake MSTJ- it is reasonable to have pad handshake but not application JoeS - needs to be a simple mode for the application to set one parameter and say go Debates on when you want to do the interstitial record padding - Apps sending small data blocks are going to be badder Going to be a mess for applications to do the full analysis - if simple parameter - then Sean - want to ask two questions 1. Do we want to do padding in TLS as an optional feature? * Don't want to necessarily specify API but might be good to give guidance * Does not complicate statement machine - two records types? * may not be padding all records - might be able to fool adversary into not knowing that you are padding on some things * EKR - want to see hard proposal if the question is just complexity. Andy, Alfredo - produce concrete proposal 2. Should we do a BCP that gives application guidance on the goodness of padding * Possibly punt this to UTA? ++ CONSENSUS SUMMARY - general agreement to work on BCP, Alfredo to start. Follow up with concrete padding proposals ******* Encrypt SNI EKR day 2 Slides Add back #0 - Encrypt SH always Add in #8 - Clear SNI available w/ no penalty DKG - makes it harder to analyze if going into encrypted mode before finishing making it worse. Andy - variants that don't require a signature - triple, double DH Rich (rich Salz) - is there an issue with the fact that the client certificate is not in master secret computation Discussion - if it is now from ordering - Alex -needs to be in if unique is part of the cert EKR - this is basically false start Could separate header keying material from data material Andy - does the problem exist - because the better protocol make the problem go away. * protect against attacks - * if use real DH group - may go away * slide #3 Add round trip w/ corrected group if the first hello is not for the server * Slide #4 Allow for encryption on client hello Questions on consistency of the policy data between the two ServerHello messages Not clear that they need to be the same, not clear that they need to be consistent. Probably should not require the same for the load balancer case This says that perhaps the first flight is not hashed in **** DKG, Tom slides does it makes sense to have the client send under policy ekr - this appears to be the necessary complexity to support ESNI the fact that the best and worst case scenarios becoming much closer are pain? Questions about what happens if no SNI for the L4 box - Discussion of where the keys live supporting existing topologies - where load balance needs some level of access * decrypt routing info in initial handshake. DNS priming is wrong - hard failure/soft failure - initial hand shake - If large gyrations to accommodate the fact that DNS data is wrong - EKR is not willing to do this. EKR - difference of design - not trying to make the first encipherment part of the hello - similar to the previous day presentation for the load balancer case - the balancer shoves the key into the maskSessonKey slot and sends to back end server - the back end server then it can use the bytes to do the decryption. Not protected data between the front end and the back end David Holmes - balancers can be outside of the centers and thus sending data across the internet to send the data. Also balancers currently have not crypto certification requirements JoeS - summary Having an intermediate thing is a realistic deployment - if SNI gets common enough Cloud service providers - using the left hand side approach (L4 picture) Do we support w/o DNS priming or in band If don't care about ESNI - then guess group wrong is re-transmit of client hello w/ different key - fewer states than ESNI case DKG - thinks the cost is worth paying EKR - no way tot do ESNI w/o priming w/o two DH exchanges ESNI in in band then 1) two DH exchanges 2) recognize it the same guy and use cached material DNS primed case and inline has different PFS and active protection properties If no ESNI - then do you have a DNS priming question - only for group Should encrypt server extensions if client hello not encrypted - yes because of ALPN selections zero-rtt needs more DH exchanges to get PFS Discussion of using a single SNI for a group of items and re-route based on the HTTP headers to deal with the issue. Does not work correctly for non HTTP systems. Get the SNI from DNS - Looking differences with the client and server implemention complexity - Discussions on what the inputs to the hash function for key generation of the master secret is going to be - in the case of primed vs non-primed and how to prime the inputs would seem to be different. poll of the room - very slight for no but almost even EKR - this argument is only on the in band version of the protocol. ESNI will always be able via DNS priming. query - any problems with making it optional - both sides have to opt in - vast majority agrees One person objecting as wants to reduce number of options. MSTJ - maybe want to have an ID on privacy considerations for TLS. This is not something I want to write. ++ CONSENSUS SUMMARY - 1. Consensus to Keep SNI 2. General Consensus to Require any SNI for TLS 1.3 if start w/ DNS address (wording and 2118 language needs work) 3. General Consensus to Allow encrypted SNI (general support, not sure how yet) 4. partial support in room for Requiring support for encrypted SNI 5. mixed response for multi RT ESNI. 6. General consensus for DNS priming for ESNI 7. General support for supporting ESNI in the case of load balancers and directors, but significant push back on intruding 3rd party into TLS exchange General consensus for the following modes: - a 1-RTT no-SNI encryption mode - a 1-RTT encrypted SNI mode with DNS priming requiring consent from both sides (server or client can refuse) - a 2-RTT encrypted SNI mode without priming requiring consent from both sides (server or client can refuse) ***** Re-negotiation Reasons to do it: 1) long session nonce 2) get cert when you did not know it earlier 3) privacy protection on the cert EKR - claims 3 is covered in the new protocol - tell client TLS handshake - app protocol can say re-connect w/ cert (Martin draft) - Andy - should just get rid of the cert-request message as it is just not giving useful info Some clients use it to do some filtering, but still inadequate to get a good selection. EKR - could do the re-key w/o renegotiation - just single to crank the PRF. Poll Matt if need to re-confirm that the entities still hold the key at re-negotiation time or can just re-key from history. consensus call to keep re-negotiation - Majority - any objections - would like to keep for the cert request want to get better filtering questions back as well as deferred. ALL PEOPLE ACTION - Look for any protocol other than HTTP and w/o a way to get re-connect to get ID information. (i.e something that delays client auth and cannot just re-connect.) ++ CONSENSUS SUMMARY - general consensus to remove renegotiation in 1.3 pending making sure it is not needed for things like client certificate authentication