TLS Interim Meeting =================== -------- DAY 1 - Thanks to Rich Salz for taking these. -------- Should we remove SSLv3 from the session hash draft? Various points about why SSLv3 is either not being used, or in devices that aren’t being updated. One more update to remove SSLv3, some other cleanups, and then go to WG LC. Sean will try to force out any issues for discussion in Hawaii. Bodo slides are at http://www.ietf.org/proceedings/interim/2014/10/21/tls/slides/slides-interim-2014-tls-3-1.pdf Based on list feedback, going to add some clarifications (no changes to the mechanism). False start I-D needs to be updated since attacker can force a version; Bodo to do that. Discussion of distinguishing between TCP reset (in FF) and version intolerance. Discussion of when to ‘guess’ failure is transient or version intolerance. Need to add some guidance to the I-D: mixing SCSV and version-intolerant servers will cause a pain. Sean went through issues raised on mailing list. What is status of false-start? Was held back by Google for interop concerns. MSFT always tries based on cipher-suite (says MT); others do it conditional on NPN or ALPN and a modern cipher like a DH. It’s in wide use. Bodo will update the draft and ask the WG to adopt Dkg on named groups. No longer an extension; allocating points within the namedcurve list, they are finite-field groups. Interacts with cipher-suite list. Discussion about adding ordering semantics between the two lists. Change: clients that wish to express an ordering may order the curves/groups in their order of preference. Discussion of RC4 draft. Andrei via phone. Room strongly supports prohibiting RC4. Discussion about being able to address concerns raised by a few. Chair will close discussion and move it forward. Sean to include text about “just upgrade to TLS 1.2” as we considered alternatives and rejected them in his shepherd notes or equivalent. YouTube currently allows two cipher suites for video streams, TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_RC4_128_SHA, but Firefox doesn't support the former without ECDHE (https://bugzilla.mozilla.org/show_bug.cgi?id=1029179). Return to DH named groups. Dkg prefers not-using IKEv2 primes, so that national-scale adversaries workload doubles. We’ll ask CFRG “do you have a problem with these groups?” Decided that SRP re-use of IKEv2 groups is not an issue. Discussion of sizes. Sean going to straw poll the list for 2048 or 2432, will work with dkg to draft the message. Proposed sizes 20xx 3032 4096 8192. Discussion of having server return the full key. Dkg to come back to the mailing list. Discussion of how to do PSK with PFS; neat hack/thought, treat it like a resumption. Compressed points. Certicom says no IPR coverage any more. Likely to drop uncompressed points (and their negotiation) from TLS 1.3 ekr to do a straw poll on the mailing list. -------- DAY 2 - Thanks to Hannes Tschofenig for taking these. -------- Session Hash, Resumption and Key Fresh Original TLS: Initial session establishes the session index with session id and establishes pre-master-secret. If you wanted to do a re-key you do a new handshake. But the re-negotiation feature got removed. This removed two features: incremental authentication and re-keying. Additionally, attacks against the weak binding were found. Session hash signs the entire transcript. People want to keep session resumption for performance reasons. Nobody was in favour of removing session resumption. Goal: There has to be a way to re-run the key exchange without the public key operation. Challenge with mobility is that DTLS record layer has no additional identifier that allows selection of the correct key in case of a client IP address change. Ekr mentions that the use of UDP was probably wrong. Ekr suggests to merge PSK and resumption. Martin mentions tickets and the potential vulnerability to lots of sessions when the key encrypting the ticket is compromised. Rich mentions their policy whereby the customer key gets mixed into the ticket key; session lifetime roughly 24 hours. Idea: Updating traffic keying material considering key compromise (useful for long-lived connections). Previously an issue because of certain ciphers. The problem is compromise of keying material. Rich and Martin mention that tickets are stored on a large number of servers in content distribution servers. Ekr: In the design we thought it would be easier to distribute revocation state rather than session state. Ekr+Rich: Companies today don't do revocation. Ekr: Just deleting your DH shares does not provide PFS. If you use session resumption then you do not get PFS either. Alfredo: Unify resumption and pre-shared keys. Question: Should the PSK resumption use the same ciphersuite? Group: Yes Rich: Combine tickets with session Id. Could be used as a key identifier for the PSK case. Session ID has to be sent in clear to avoid the public key operation. Ekr: It would be good to have a session id that it is not the same all the time. Assumption: server keeps no state Discussion about how a design could look like. All solution ideas seem to require a pool of ids to be kept at the server (which is similar to how EAP-AKA works, see http://tools.ietf.org/html/rfc4187). Discussion about which protocols require multiple connections to the same server; HTTP and IMAP mentioned. The security properties are totally dependent on the servers policy. It turns out that there is no way to provide the desire properties without doing another DH exchange during the resumption (or to re-start the full exchange). Goal: Avoid public key crypto during the session resumption. XMPP guys turn off session resumption. They have to deal with the situation that connections break regularly. Application protocols need to be able to handle multiple connection setups in parallel. Network access authentication: Resumption could also be done for avoiding user authentication. We want to update keys: Simplest thing is to add a message that says "I am unilaterally updating my key". This would deal with cryptographic exhaustion (e.g., nonces with GCM) and with future compromise of the keys for the data you have already sent. Should you also force the other side to change their keys? It might also be useful for asymmetric key data exchange (more sending than receiving) XMPP: A server will often be multi-tendency but it also happens with HTTP 2.0. There is a way to create two connections with different domains. There are ideas about application layer delegation. The question whether client authentication should be pushed entirely to the update mechanism. Questions for the group to discuss: * refresh keying material * adding a Diffie-Hellman exchange * add authentication during the session * what are we exposing to the developer? what is the conceptual model for the user (e.g., certificates expire during the lifetime of a session) With the removal of re-negotiation ciphersuites cannot change anymore during the lifetime of a session. Martin: Multiple data in flight (interleaving streams) and then I add a certificate during the connection. What happens when the server processes the pending request should the received certificate apply to the pending data. When an Web server receives the request it does a look-up to the identity provided by the TLS layer. Martin starts to draw a picture about the problem. Argument that this topic is already covered with the Renegotiation Indication Extension spec: https://tools.ietf.org/html/rfc5746. Is there a way a retro-actively asserts the right order of the application protocol exchange? There is a race condition. Existing application don't offer this functionality (because they don't have this renegotiation feature). This is a future-facing problem rather than a backwards facing problem. So, it does not cause problems in past behavior. Suggestion to use the token binding and ALPN message since it is similar to client authentication and it is similar to session authentication: https://tools.ietf.org/html/draft-popov-token-binding-00 Any information about what keying material the client could be using should be pushed to the application layer. Ekr provides critique to the way how the CertificateRequest could look like (since it is incomplete; CA list is empty or populated from the system root store, which is large). It would be better to move that part of the logic to the application layer. It is easier for the client to indicate what it wants to talk to (other than SNI). The type of certificate the client is supposed to present is very application. Ekr suggests for the IoT case that the client just sends it. This would require an update to the HTTP stack rather than just a TLS stack update. Ekr suggests that we should abandon PAKE. Others agree. The problem seems to be in the interaction with the user interface. Suggestion to look at SSH since it also follows a similar pattern. Sean: Should we annotate the IANA registry to indicate what can and cannot be used with TLS 1.3? Ekr: We should add another text field in there (a new column). Key hierarchy Ekr draws a diagram with the key hierarchy and how the UPDATE and the ACK message is used. --> UPDATE (nonce) <-- ACK (H(UPDATE)) The ACK is needed for DTLS. Using the UPDATE to trigger an update by the other side; it allows the party that has better information about the cipher lifetime can dictate how often the key to change. Discussion about the use of a Diffie-Hellman exchange incorporated. Dan raised the idea of re-using old key shares to have new keys available right after sending the first message. --> UPDATE (Yc) <-- ACK (Ys) Issue surfaced that there is a need to add another exchange: C -> S: Ya S -> C: Yb S -> C: Update C -> S: UpdateAck UpdateMsg: { type: dh_req | rekey | ack case (type) dh_req: Yx rekey: nonce dh_resp: Yx || tid ack: hash(over-something) GCM: Argument by Stephen Kent to guarantee no nonce re-use. (GCM: carried the nonce on the wire) http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf Some others wanted to get rid of the info carried over the wire. * 0-Roundtrip Point of session resumption is to remove the DH exchange. The purpose of the 0-roundtrip is to send data on the first flight of data (i.e., roundtrip latency) For a PK-based exchange there have to be multiple ways to learn the keys upfront (e.g., previous exchange, DNS, etc.) If we have a non-trivial connection error rate then we should tell service operator to connect to a 1.3 server and to also have 1.2 servers in the same clusters. It is theoretically safe to send a TLS client hello to any server. Requirement: have extension tolerance across your cluster. 0-roundtrip: Goal is that resumption leads to no worse behaviour than an ordinary exchange if it fails. Suggestion is to use a PSK combined with a DH-exchange (PSK for authentication and DH for PFS) so that the server can choose in case something got wrong. The server could publish his DH share in the DNS. Ekr claims that 0-roundtrip could also work for resumption. Hugo says that PSK and static DH is the same. In the PSK there is a identity hint to select the key and in the second case there is Ys as a pointer to the private key. Discussion about how the API would look like for distinguishing the early data vs. complete exchange. Ekr says that he implemented early data and it was complicated due to special handling of the code path for finished message. Hugo draws a 0-roundtrip and a 1-roundtrip exchange on the whiteboard. Hugo suggested a solution to have certificates for static Diffie-Hellman by taking a regular certificate that is then used to sign the public Diffie-Hellman key. Dan says that this is similar to proxy-Certs that just don't use the X.509 structure. In response to whether this is a new design Hugo said that a similar design goes back to the above paper (from NDSS'96:http://webee.technion.ac.il/~hugo/skeme-lncs.ps) which had actually many of the same motivations than the current proposal (PFS, identity protection, a uniform treatment of pre-shared key and re-key, etc). On the other hands, there are some significant differences in the new proposal such as the support of 0-RTT and server-only authentication. In cryptography little changes can introduce vulnerabilities so OPTLS needs to be considered as a new design for the sake of analysis (and there are important details to be nailed down, especially the key derivation definitions). * FlexTLS Alfredo presented their work on FlexTLS. He demonstrated the ability to re-produce the Early CCS attack. The attack is described here: https://www.imperialviolet.org/2014/06/05/earlyccs.html http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html ---- ssl_send_flight_completed: function executed every time last message of exchange is sent out. --> call ssl_write_record (the message is already in ssl->out_msg)