IETF Transport Layer Security Working Group (TLS) Minutes Meeting : IETF 95, Tuesday, April 5, 2016 and Thursday, April 7, 2016 Location: Buenos Aires Hilton, Buenos Aires, Argentina Chairs : Joe Salowey , Sean Turner Minutes : Jim Schaad Version : 1.1 ——————————————————————————————————— TLS Working Group Session #1 - Tuesday, April 5, 2016 10:00-12:30 (Argentina) a. Agenda Bashing Slides updated with bashing done before the meeting. b. Status Report - Need to deal with the falsestart - EKR (Eric Rescorla) - Draft has information about what algorithms are.  Problem is that security guarantees are not the same. Client needs to enforce that client gets back an acceptable list - as this is not protected SF( Stephen Farrell) - Lets take this off line - IANA Registry Rule Changes Dan Harkins (DH) - what are the rules for this (PWD) draft SPT (Sean Turner) - Need to determine process for the PWD draft, but nationals can do this easy. Some will need to go to ISE to have a review. Still hard to get a publicly available spec published, should the pwd draft go through the WG or be kicked out? EKR - There was substantial objections from members of the working group, probably won't get consensus DH - give me a code point and I'll go away. EKR - verify that 16-bit space above will have this policy. Be sane about allocation - don't do things that have huge allocations DKG (Daniel Kahn Gillmor) - Values may change over time - how do we move things from Y to N SPT - Need to have some type of consensus from the IETF to do the change SF - Does the TLS working group want to be the gate way for a Y to be allocated? SPT - Yes SF - will need to have a charter update to do this - EC Cipher suites for TLS 1.2 - Yoav Nir (YN) EKR - did you adopt David Benjamin's changes - no need to have a code point assignement. Going forward from 1.3 - no signature group different from the signature algorithm. Should move this back into this document. Don't name the group separately SPT - once the alignment for EC done - go to WGLC c. TLS 1.3 discussions - EKR - Have assigned some code points for the PSK for testing. - Not ready for doing early code point, but we probably need to do some reserve on this so they don't get used someplace else. - New end-of-early-data marker for dealing with dead lock situation found during testing 
- Note that w/ the revised signature algorithm Negotiation - there are things which mean one thing in TLS 1.2 and will mean something somewhat different in TLS 1.3 as the curve is now going to be fixed. Specifically something like SHA-512, ECDSA no implies a curve but did not before. DKG: not sure that this is not going to be a bigger mess w/ interop with current systems EKR: probably not well done today MT (Martin Thomson): NSS looks at the cipher suite selected and do the curve fixed on the certificate. Hash is input - and finds one that we like - so will do the  David Benjamin (DB): Could allocate new points so that there are no collisions EKR: Don't think we need to deal with this except for the non-sensical cases. MT: Burning the existing code points for compatibility with crazies is needed.  Don't want to send larger handshakes because of this. YN: Need named curves for the interop w/ 1.2 EKR: Assign new code point for 1.2 which is the same as here. for 1.2 - don't change the curves selection, just use the new signature points DKG: What is the size of the existing cross product - the craze on EKR: in the neighborhood of - don't know about 10-20 that you can't use any more ??: Problem comes with a TLS 1.3 client downgrading to 1.2 server. Client might become confused DKG:  4 entries for signature and 7 for hashes - some are reasonable and some are not 28 points being blocked out - should not be a problem in a 64K registry EKR:  Request for DB to do the pull request for DB to do the pull request for the 1.2 draft - Anti-downgrade attack Does not protect w/ weak static RSA The extended master secret will not solve the downgrade on its own Possible problem w/ this document forcing behavior on 1.2 implementations MT: When 1.2 shipped 1.1 was obsoleted, can obsolete and update at the same time EKR: If 1.2 did this today, then defense against downgrade to 1.1 w/ client updates. No existing defense deal with the reset problem Client needs to check against original version negotited not current one in the event of new request after a reset. DKG: in 1.2 there is time in the start of random. EKR: values chosen to be in the past DKG: Could resurrect the kill unix time draft and put this into that draft as well. - 0-RTT Client Authentication (remove client authentication from 0-RTT) EKR: If people object please speak  MT: Can always add back in later  Hannes (HT): Been trying use in IoT - 1.3 has better performance Reasons to switch from 1.2 to 1.3 become less apparent People who object to TLS become justified Understand in web community where client auth is done at the app layer not important IoT wants mutual auth. SPT: May need to have you write something to say how to do this securely. Please help find some people to supply this type of text. Kyle Nekritz (KN):  Can carry over client authenticatiob 0-RTT resumption Christian: Very hard to do both 0-RTT auth and keep anonymity.  Need to show how this is done SPT:  Sense of the room is strongly to remove this at this time. Possibly do something later HUMM:     Who is in favor of removing: Large noise     Object to remove: crickets - ECDHE-based 0-RTT People really want PSK for resumption Ian Swett(IS): Slight slight wrong - google only looked at the desktop and not mobile. May be slightly different answer there EKR: Ticket lifetimes need to be in the multiple hours to week time frame. Christan (CX): PSK identifier is clear text so lose some privacy. Mitigation - each time get a new ticket EKR: Current says that tickets supersede.  Would be useful to get a handful of tickets as well DKG: two types of tracking -  server can re-identify the client - no mitigation for this external can re-identify the client - need to prevent this. Will commit to write the privacy/security text for this. HT: Wondering of mobile uses more trusted secure Ian Swett (IS): yes there are better trusted storage opportunities. Server Proof of Private key: DKG: Why not require 1-RTT if you care about this EKR: Can change the crypto to provide this for low cost. Details to follow later -  CX:  Cases where client decide not to do 0-RTT -  Since 1-RTT requires support - if this matters to the client they can do 1-RTT instead. MT: I think this is simple - but other things are more important right now. HUMMM:     In favor of removal of 0-RTT DHE modes: Large Noise     Object to removal: crickets - NewSessionTicket Format MT: Think this is overly complicated. Hardwire everything possible just with or without ecdhe fallback is from resumption to no resumption EKR: Issue if the server couples 0-rtt and resumption MT: Presence or absence of algorithm used by NSS to make the decision (only one supported cipher suite to do this) EKR: Client has more problems predicting behavior. Simplify to DHE, no DHE or both rather than cipher suite list CX:  Does the decision on 0-RTT change this? EKR: I don't think so EKR: MT please create a PR for that change MT:  will try this EKR: What type of early data is accepted DKG: if one server and all state is written and a reliable replay cache - or no side effects. Then can allow all early data. IS: Need to deal with that all GETs are not side effect free think its ok, but need to think about it. DKG: Think that the client should not rely on the server to deal with this JS (Joe Salowey): How tied is this to the application - what about non HTTP MT: Suggest that it should be binary and stop there KE: Perhaps this should be ok - some clients are doing this. EKR: Plan to make this a flags word rather than as two fields - 0-RTT PSK Extensions (Encrypted Extensions) The encrypted extensions is not part of the handshake digest MT: Issue where get an upgrade from HTTP 1.x to 2.0 will have issues in trying to get things done right Andrey Popov (AP): some of these should be part of the remembered context such as ALPN. KE: Probably want to kill when changing the ALPN Tight situation where can trickle data in on the time check from the 0-RTT data Could move to the end of the 0-RTT EKR: Suggest dealing with that offline. JS: With change of ALPN - avoid problem with cross protocol attacks. EKR: Talk to the semantics slide DKG: Client should keep its configuration the same - store the list of parameters with the cache? EKR: Difference between having the 0-RTT being off and resumption being off. In one case the ALPN change would be allowed but not in the other case. MT: Really need to keep the ALPN tied in context - Find the next handshake block Discussion of the end-of-early-data-alert and security properties. CX: When does this happen that cannot deal with bit on server. This is an error case EKR: I think it will be fairly common to occur MT: Do people have any stats. IS: about 75% of time successfully complete EKR: Question on how often a client asks and the server says no IS: About 5-10% ballpark DKG: Why solve this is a privacy problem if other solutions are safer and just force the TLS handshake termination EKR: Consensus seems to be to stick with the existing text. - Exporter for 0-RTT Discussion on if it is needed.  MT says that it is not needed. DKG: Starting to smell a lot like the client auth discussions —————————————————————————————
 TLS Working Group Session #2 - Thursday, April 7, 2016 10:00-12:30 (Argentina) - Key Separation: A Layman's view Eric Nygren (EN): would option #2 use a separate api as some data ok even in client auth case EKR: Still no way for the client to know what the difference is on the data If resumption is carrying over client auth, this is not an issue. DKG: Looking for justification of no API EKR: Could concede the point Russ Housley (RH): Where do you see the failure if the MUST is violated EKR: No change - server logic should prevent it from happening Nick Sullivan: Does this include PSK implicit client auth EKR: No HT: How frequently does 0.5 RTT data occur EKR: HTTP 2.0 lots of items Jim Schaad: describe replay EKR: Will take action to make sure 0.5 RTT security considerations for PSK resumption w/ client auth is done ACTION: Room consensus is that we should use option #2  - EKR: Demuxing Options MT: Side channel created for trial decryption EKR: In TLS you get one byte at the apple and then get alert on encryption fail. With the two keys you either get an immediate or slightly slower failure DKG: Please use two keys - active interest from the crypto community KE: Require 3 trials when switching from 0-RTT to application data on the server? EKR: hmmmm.. No for unsuccessful 0-RTT either a success decryption and then end - so just 2 trials AP: Support 2 keys DB: Trial decryption does make doing decryption in place slightly harder. If mac check fails then have mucked in place buffers already DKG: recognize problem, but still would like to fix IS: Only do trial decryption looking for edge but not every packet BK (Ben Kaduk): Wrapping would not have this problem EKR: Mingling keys that way would be messy from analysis need to get input from the crypto community KE: Should do an analysis on doing the reversal encryption to get better data MT: Preference would be nested and then reverse  MT: Would be a problem w/ PKCS#11 HUMM: Validate w/crypto if wrapping solves the key separation issue and if yes then continue w/ that Pro: Lots Con: a couple of people What key to use for handshake encipher Suggest that KeyUpdate should be use - Which Key? MT: suggesting the use of the entire transcript including client second flight? EKR: Just crank the KDF one more time to get the new key DKG: Prefer to have cleaner key for PFS type thinks No objections the room to using new handshake key. 
- Key Context: MT: Like the implicit binding  EKR:  will take this as no objections and make a PR and get review - Simplified Key Schedule: This should be fine for dealing with the triple wrapping as long as the RMS for the entire transcript MT: What is ES EKR: Should adopt policy that either non-existing keys are 0 or that they duplicate the other key (what we do today). I think duplication is simpler (probably) JS: Will it be impossible to the the fancy mode of long term if this is done EKR:  No it should be possible - and gives explanation of how Sense of the room is that this seems correct SPT: This was presented at TRON and they seemed ok with this - Issue #215: (let servers send known groups) No objections in the room for this 
 - Issue #426 These are people trying to get rid of middle boxes by using a cabinet version DKG: Be clear about the semantics. This is to say that I reuse to use the last set of keys Issue of DTLS where there is a delay on this as old keys may still be used. Want to know what keys (plural) are you willing to accept for DTLS Need to deal with that issue in the proposal BK: Making a case about forward secrecy. You need to make sure that both parties have destroyed the key. Makes it easier to know that the peer has destroyed the key EKR: Make no assurances about having keys destroyed. MT: Handshake traffic key - do we throw that away here as well EKR: Since it is not updated, don't bother that BK: Claim that an attack exists where all update key messages are suppressed SPT: Don't feel it is baked enoughShould not merge PR. Chairs will notify the requesters - RSAPSS EKR: Document currently says don't use 1.5 for cert verify but can use for certificates Two code points, one for PSS and one for 1.5, but the semantics of them don't match Requirement is to in the future say don't send 1.5 certificates DKG: conflated semantics in the signature algorithm field. EKR: Unfortunate temporary state. DKG: Will continue to have this problem in the future for a new broken signature algorithm. Need to accept certificates for a while even if TLS is updated EKR: Policy question of 1.5 for certificate verify is the real problem. Want to solve that question before the encoding question JS: Anyone in the room object to not allowing 1.5 for certificate verify Crickets in the room - EKR: Now willing to talk about the encoding question DKG: Will have this problem again in the future should encode to solve EKR: Posit new encoding exists Is this advisory for certificates or mandatory Less excited if not mandatory DKG: Can demand that cert verify comes in flavors but might accept. Expect that servers are going to have multiple chains in the future Server guesses w/o a signal EKR/DKG: Argue about not having any preference and thus the client has not control AP: Prefer to make it mandatory and have the client fails if wrong things returned RS (Rich Salz): Having to guess the optimal cert types based on heuristics bad.  Prefer to get strong signal from client Both from the OpenSSL and the Akamai point of views EKR: New extension w/ advisory semantics on the certificates would be the proposal BK: If the server has to guess, why would it change what it does today? BK: If the server always pick the stronger one and the client can reject then would seem ok. Some don't do this correctly today EKR: Not all servers guarantee conformance w/ client request Distinction is between certificate verify and everything else RS: Needs this to be a reject on the client side not the server side. AP: If server does not need to object the extension, why would it even look at it. MT: Can we do this later? EKR: Yes MT: What if this was specified if the client says I cannot do PSS YN: Need to be clearer about what the current extension says in any event. Opposed to new extension since this is only an RSA problem. Usage is going down for RSA so may not be long problem. JS: Why do you think this is not going to be a problem w/ new EC algorithms in the future YN: Has not come up yet JS: Only an issue because of deprecation of algorithm, but agrees with DKG that this will come up lgain HUMMMM:     Change the spec now - some nose     Leave alone - slightly greater - OCSP stapling MT:  Want to move pinning to the top level and don't make it an extension any more JS: Just EE cert? EKR: Do clients which ignore OCSP need to have the data dumped as well? MT: Sure EKR: Should it be asked for or always sent? MT: Inclined to second KE: If the data has not changed then it seems to be alot of extra data MT: Make cached info better as it has a hash of the cert message DKG: Will this be true if OCSP message changes over time? - Questions on timeline EKR: Should produce two draft by this time in may Get the technical issues in the next 2-3 weeks Hopefully last call around end of may MT: we now have a dependency on draft-matson - Can we remove citation on this HT: Have an interop event as well? EKR: Good idea to think about SF: think about a TRON + interop event together - Interop questions: SPT: When should other implementations be done RS: OpenSSL - may release is currently all things Next focus will be 1.3 Hard for non-dev team people to help given the invasive  Proabably not before year end DB: Start working in Boring SSL soon Duration unknown AP: Will support at some point in the future Implementing is not the same as making it the default Kyle ?: Apple will implement but no schedule RS: OpenSSL probably be by default - but 0-RTT - who knows Richard Barnes: Should be in the NSS tree soon and start to get some measurements of seeing a new version number MT: Hope to get some states on reduction of record overhead HT: Playing around in embedded version - probably better to re-write than to adapt. MT: Don't change the 1.2 code, write a 1.3 stack and steal code is much better option. - DNSSEC Chain Extension Request for adoption SPT: Had deferred this to deal with 1.3 Would like to get a sense of the room  Nobody really read latest draft based on poll Is this applicable to both 1.2 and 1.3?  Nods from the room HUMM:     Would like to adopt the draft: Lots of nose     Against: Crickets DKG:  Would be useful to get an early code point assignment SPT: Doable after adoption and review And the meeting closes