IETF TLS Interium Meeting - March 10-11, 2015 - 9AM - 5PM Location: F5 Networks, 401 Elliott Ave W, Seattle, WA Chairs: Sean Turner, Joe Salowey Notes: Jim Schaad Version: 1.0 =============================== Attendees: Sean Turner Hannes Tschofenig Martin Thomson Daniel Kahn Gillmor Andrei Popov Andrey Jivsov Tod Ouska Chris Conton John Safranek Larry Stefonic Hoeteck Wee Hugo Krawczyk David Holmes Richard Barnes Jim Schaad Adam Langley Brian Klisch Colin MacCarthaigh Rich Saltz Eric Rescorla Joe Salowey J Harper Jeroen de Borst Brian Hamon Agenda Bashing Hannes - Chached Info Also add some time for padding with DKG Status pages with the chairs TLS 1.3 Changes EKR - Review of changes to -04 and -05 drafts Only allow duplicate curve representations for existing ones and not for new ones Add restirction on a single point format to 4492 BIS(?) ---- ACTION Should the list be compete for code point in handshake? Open issue for now - Sean no - because would need to do all of the lists anyway. Some questions still open about when the hash needs to be included - dissusions open with Hugo Not all of the backwards compatiblity changes got incorperated as some of it is till open issue Pull request 107 finishes backwards compatability Pull Rquestion 107 Fixing the record version of the client hello Mozzilla and Google say - do this and make it strict EKR - can we remove the record version or not? Need to have all alerts carry it and the client hello Prolem with anyone in the middle looking for it Alternative - force the record version number to always be (3,1) It could be tested in Chrome - but alot of work MT - Move to make it fixed to 3.1 in the absence of tests to see if it can be removed. AP - send whatever and ignore on receipt - sending 3.1 ok. What does it send on the server hello ACTION: Change to always send 3.1 and ignore the value on the receive 0-RTT - EKR For a 0-RTT mode - server must have some state to prevent replay attacks Need to make it consentual for the server ** Overview of 0-RTT flow slide Question of how much PFS is lost - Adam points out that this is the same as is done currently in TLS, but EKR responds with the fact that since the key derivication has changed with a different session key and master key so that this is not going to be an issue for TLS 1.3 Lose PFS on multple resumptions? Have a timestamp in the clear from the client - allows for fingerprinting, but this is a requirement to release this info to somebody. AP - requires a shared database across multiple machines What to do on failure AL - suggests using retry 0 RTT mode EKR - Two slides - first one is when the server key is correct but the window is out Second slide is the normal case when the key has been changed as well Some preference to just have the second case. It is required in any event. DKG - Attack - have sent some data using 0-RTT - messed up in the middle (delay or block) - Retry and succeed with full handshake - replay (or release) of app data from the first sentence AL - This is already done in TLS 1.2 with this for HTTP. EKR - might be prevented because the random is part of the replay AL - If attacker sends to a new cluster with a different orbit value then cannot be prevented. AL - Why did I do the strike register with this attack EKR - If use orbit and it is wrong then do a handshake failure - moves it back to the appliction layer rather thn the TLS layer ** WHITE BOARD OF PROBLEM ** Two cases where this works - non-multi home systems, very tight global cache (relly hard to do ), if partioning can be enforced - i.e. queries between data centers needed. HTTP has replay in it already - so not an issue for that protocol, big issue for other protocols Document the mode - make the requirements are known in the RFC. State exhaustion attacks are a problem - Close down by narrowing scope rather than broaden which is normal DDS attack prevention methods. Need to make sure that you don't race the packets to different servers - Part of the consistancy definition for the centers ACTION - Write down what the mechansim and the security text for implementing this feature Details of how to do it: Problem with cases of not sending application data - client may not do it. Other messages are encrypted, but with a key I don't know - how do you decide how to skip them. * Skip until I can decrypt * Or tag which says that I can skip this. * Have a way of specifying in the hello of the length (fails if you want streaming on the app data) * Send one application data packet with all data and one handshake packet - can then skip one item. (AL) Suggestion to move all of the handshake messages into a single "extension" so that all of the messages are present and you can foroward - Break messages on change of encryption and change of direction - otherwise it goes into a single message Does kill all existing middleware state machines - have died anyway Already doing this to some extent for backwards compatability with TLS 1.2 negotiation Client Hello { Client Key Share } ------> Server Hello { Server Key Share } Server Data 2 { extensions, server cert, cert verify, cert request, finish } [ App data] <-------- Client Data { cert, cert verify, finish } [App data] ----------------------------- 0-RTT Client Hello { Client Key Share } { Client Data2 {..., finish} [Replayable app data] ------> Server Hello { Server Key Share } Server Data 2 { extensions, server cert, cert verify, cert request, finish } [ App data] <-------- Issues with encrypting content types - can't figure out what is app data in that case. There are some problems with encrypting alerts for DTLS - middle boxes can know when things are going away if not encrypted. Every part with consistant cryptographic treatment is batched together. Use count of app data messages to skip for 0-RTT fail to the next handshake message Question of wrapping this together does not change the question of co-mingling or using a state machine for TLS 1.3 (EKR) If you have a DTLS implemenation that is doing this piecemeal as chucks come in, then you are going to have the current state problems [MT] Question on what happens if a new message shows up - is this fatal or treat like extensions where it is ignored? Probably should be fatal which is 1.2 behavior. Question of removing the numbers from the container handshake messages except for the client hello - required for bacwards compatability. ACTION - Adam will sketch out further to know what the messages are and how processing works. Identifying Cryptographic Parameters (Bhargavan/Pironti) EKR - Providing a labeled block with the label reflected by the client Question on using the same for PSK - Can you do a 0-RTT fail and negotiate if cyrpto suite changes? Reponse - message because need to have proveing alg ids which we are trying to eliminate Disadvantage in configuration of the client and server needs more data. Would need to have the TLS WG define the ids for the PSK suites so back to equivalent of cipher suites. QUIC is propsosed as one solution - would need changes to separate the data not encrypted from the data encrypted so it becomes more complicated Rather than pickling the data - Server gives state number, and the client uses that state and value and goes foward assuming that set of state data is correct and does a full negotation later if there is a problem. Server still runs the negotation algorithm on re-connect and will get the same answer because it does not change the algorithm and the client is assumed to supply the same input (or equivalent) and the result will end up with the same cyrptographic algirthm set. Problem with resumption as the id would need to be unique per client because it needs to incude the cipher suite. If config id disappears - anounce the result algorithm and preference list - and have server verify it is acceptable result. Still need id for the server dh share. PROPOSAL - Client sends hello - annouces parameters to use - server validates correctness - client indicates a key id - EKR to write up Padding with DKG - Pull request 142 Proposal only provides a mechanism for padding or traffic analysis- does not say how much or when to pad Two new content types: Padded data, Padded handshake EKR - Not padding to block sizes or client hello passing F5 devices. In this proposal Padding is being done in the plain text block structure EKR - suggest negotate padding in the extesion for data -always pad handshake messages EKR - if large records - then two bytes is a small overhead - what is the case where you have mixed padded and unpadded records where the overhead is large. Can you pad in one directonly only - AL - it would be crazy to do this. Benefits appear limited to making the client life eaiser by not having both methods on send DKG - desire the padding of the data because you are in 1.3 - server could do it because it knows that the data is sentive and the client must be able to receive it. MT - Suggests that extension on padding is Opt Out EKR - Updated proposal - allow data padded and data unpadded - but handshake is always padded MT - push pack on the size of padding_length - make it 8 Can'd do that because it messes with things. What is the value of the padding bytes? - OPEN ISSUE: Three proposals - discussion appears to be approaching zeros and no verify. OPEN ISSUE - can a record consist solely of padding. AL - There are problems with having too much padding just like zero length records today. Need to have some limit on the amount of bandwidth used by the TLS stack. SUGGESTION - flip the order of fragment and padding in the PaddedFrgment structure. Policy description - easy policy is pad to a multiple of X bytes Discussion of timing attacks based on cache freshness in the server - could be fixed by always sending on a timing boundary - but this is not an issue for this document. Timing attack problems are very difficult to fix. What about the policy descussions - where should they be? MT - use somehting similar to what is in the HTTP2 document. - Put it into security considerations. Cached-Info - Hannes Slide set displayed Question for group: Omission of handshake messages - AL - grumpy about this because it moves the world to the state machine hell again AL - what if it had multiple cached server certificates? - which is chosen by the server. currently only allows selection of one certificate by client(?) Quick has this built in - common sets of certificates are tagged Move into some type of configuration id. EKR - can we move this into 1.3 and not have for backwards compatability? Does IoT need client certificates? Does it need it for 1.2? Digest of the ceritifcate message and not the key or the certificate. Use SHA-256 for the hash Needs to eliminate the issues of the triple-handshake questions. IoT does not need OCSP END OF DAY #1 DAY #2 - March 11, 2015 Addendees: Rich Salz Sean Turner Jim Schaad Martin Thomson DKG Hoeteck Wee Hugo Krawczyk Andrey Jivsov Andre Popov Eric Rescorla Hannes Tschofenig Joe Salowey Adam Langley David Holmes Colm MacCarthaigh J Harper Peter Bowen Mike St. Johns (remote) OPTLS - EKR 1-RTT mode based on signtures, 0-RTT based on shared secret/semi-static DH negotiation Recapture concerns expressed in Honolulu about the security issues of having a long term DH key that is signing things. Temp compromise of a TLS 1.2 server can lead to building a fake TLS 1.3 server beyond the acutal compromise of the 1.2 server. Look at the Performance Comparisons Some potential issues for use of HMQV for patents. Both IBM and Certicom have them. IBM has committed to do free usage for TLS (per Hugo). EKR - If think could solve into the cases of == or HMQV, then do it and worry about other issues later For variabe base - VB DH is about 3 times that of signature Can always put deligation back in later without it being here now. Offline will be slower for server than online The equality hack - can be done unilterally by the server w/o client support - client can detect by doing a comparison of the publics (memcmp) Working out details of the equivalent point Sig(g^s) deivered under encryption, but g^s is not. Issues for 0-RTT that need to supply a new g^s' for the next time. Cost of doing RSA for signatures will still dominate the issues. In the zero RTT case there are no options - no function for signatures - must use the authetiction from the prevsious round trip in moved forward In the 0-RTT case could force the server to re-prove key possion - but cost does not seem worth while Distinct case of 1-RTT with a cached cert from the server - does not need signature signature again use the caached key for proof. HMQV cannot encrypt the static key of the server w/o one additional expodentiation. MT - Currently no stomache for offline signing case - so worse case is the online signing - but should be able to do line 4 or 5 Hugo - need to make sure that offline signing case can be in the protocol even if no need to have it present today. need to have a hole for a ECDH certificate for future work. HMQV has different properties for the server identity hiding. EKR - I have a hard hat version of line 2 - could do the line 4 in about a week - if you don't have tight roll over you kind of get from line 2 to line 4 anyway. ACTION - EKR to write up lines 2 and 4 (+ 0-RTT) for review by the group. Remove server cert verify Add signature blob over session hash Add a bit on the performance numbers If IP clear on HMQV then can look at if it is worth doing - will require changes in terms of what goes forward. HMQV Disscussion K = g^(x(y+es)) e = H(g^x, g^y) for 1-RTT case, server needs to send g^s in the clear or encrypted by g^xy If you split the signatures of g^s from g^s and encrypt only the signature - less possible information for tracking - less certanty. Possible issue w/post authentication Privacy model - linkage between two different entityes Discrimiination between two different servers on the same hardware Need to look at the implications of SNI encryption and how it interacts with this. If use g^y=g^s - then send a separate semi-static key and make g^y be totally ephemeral. Update/Rekey - Martin Want to protect old traffic from future compromise Need to deal with the sync problem - can only force and sync an update in one direction Why is there a requirement to make it unidirectional - DTLS w/ lossy transmission - is possible problem if a message is dropped Force the other side to update it's keys as well Allow for force up update for other purposes. Why do this in DTLS? It is a complexity problem. Could use epoch change for DTLS if no need for adding additional entropy. Client auth is going to be more important than this issue because exhaustion of IV space is not feasible. Client Authentication Version of this keeping current client auth in the front end is protected Rectroactive authetication of request HTTP 1.1 problems - AL is willing to say this is dead Move to application layer for kick How does this interact with resumption? Server will not remember authentication added in stream. Can stil remember the one at the start People are saying that they do not want to deal with new session tickets to come mid stream - just the one right after the handshae. Need to be able to deliver the ticket immediately after the initial handshake. Could use that as the response for TLS session tickets w/ new authentication Concept is that a new client id will retroactively bless all previous keying material. EKR - Moving to towards saying that we should do this - does just what AP needs - Can be optional Does not roll the traffic keys - make sure that this is not the way to do a key roll. If that is provided needs to be light weight. ACTION - AP to do a writup for his cases and also do some work to cleanup the certificate request so it is not as large. Given that this is decoupled from Update - ACTION - make the update mechanism simple and different between TLS and DTLS Key Heirachy/Derivation Suggestion is to do HKDF In picture - PRF is the extract and PRFH is the expand functions of HKDF. Make sure don't use the same secret with two different HKDF hash functions. Questions of why the 0 in the picture - response is that this is the key and the random values is the data to be hashed. For HKDF - all context goes into the expansion and not into the extraction. AL - why is the server config not input to the early appliction traffic keys? AL - believes that should tie this to SHA-256 for ever. MT - If we need to fix then new protocol EKR - configure one PSK and allow it to be used with different hash functions - this violates the problem ACTION - need a security consideration on this at a minimum Use different context values for the three way split at the bottom of the picture. Allows for HSM to enforce on some exporting and others not Question of where unique comes from Make it just an exporter value For PSK w/o DH - put the PSK in for both the static and the ephermal secret Consider doing two extrations for the traffic keys rather than overlong generation of data and parsing. Need to correct the nonce so it is always a counter and has no input from the KDFs for the purpose of AED functions. ACTION: fix AES-GCW top 32bits are 0, 96 bits are counter HUGO - use the same salt value if you are makeing multiple calls MTI cipher suites What should the symmetric algorithm be - AES-GCM-128 vs ChaCha/Poly - MUST AES-GCM-128 - SHOULD ChaCha/Poly fips requirements IoT - wants to use CCM but there could be a profile to support the environement. What should the hash function be - SHA-256 What should the ECDH be - MUST P-256 - SHOULD 24559 What should the signature be: certs - MUST ECDSA P-256, MUST RSA --- need to be able to drop SHOULDS from CRFG assume they show up in the "near" future What to do with the curves currently in the draft. Pull the rest of the curves and mark as reserved? EKR - normalize - and mark as reserved/obsolete Keep - suite B P-384? Brainpool curves - some german projects may object to removal ACTION: Create a recommended list of algorithms in the TLS 1.3 spec. To update the recommended list requires an update to TLS 1.3. People can do vanity algoirthm registration but does not hit the recommended list. Question about ANON_ANON ciphers - do we remove this. Only known use is mail servers - may be others. Signature format/orthaognal negotiation need to specify in 1.2 and above signature information Cipher suite infrmation either redundant or conflicts Remove the signature infomration from the current ciphersuite table - move only to the extension Make the removal of signature infomation only from new cipher suites Pushing for this was to get PSS signatures supported correctly. ACTION - Find somebody who is enthausitic and get a proposal from them about this. MT will write a pull request on this. Should we transition to PSS in 1.3 as well? TLS must be able to process both PSS and 1.5 for verification, must use pss for online signature creation? Question of hardware support for PSS would that be an issue? Might be true ACTION: Push the idea out and see what people are going to think about this