[TLS] TLS 1.3 draft-07 sneak peek
Eric Rescorla <ekr@rtfm.com> Tue, 30 June 2015 22:24 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4641A1B333A for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 15:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Level:
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKE3eQKiaFW for <tls@ietfa.amsl.com>; Tue, 30 Jun 2015 15:23:59 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E4F1B3339 for <tls@ietf.org>; Tue, 30 Jun 2015 15:23:59 -0700 (PDT)
Received: by wiar9 with SMTP id r9so50873692wia.1 for <tls@ietf.org>; Tue, 30 Jun 2015 15:23:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=hyl6NysfFNqNnIepGJHEpj87it9eOwYOTPfD+7ugZU0=; b=K6kXaikKRo627dMmotVoaPU5TWArO4m7ClsAAYqWZ6qprcdjQHQaZoeLoJWSWI72Ob yfWUjOCAbztKhzLOOfvBC88AjG+7nnFQoccAJlezBno/pZm5FobCtKvpZJbs8MODzvmZ NVm7BieosB9DZOMxMWHffn5nxBwHoSCjTI55Ox99ANl0CQys1UxiMuLEtg+G3Gqh+v5m OunkQACo69PpmSYuKm0WBW+dSNfXVm0VX/w+7K4YVX/oZ3XFgUVtf+ktyYrTqElDvxUX XOUtM1cn9spSGCBGtR7XBhLDEsN23lMl9druGCZh7+misBxaY26V8h7C7LPwQ/yUaFra +7Mw==
X-Gm-Message-State: ALoCoQmmqiuXPJXD2/3cR/rXIdgsDNEq4uxg+9Qez78RRncNLD1/8jEnZNVYHYneM110s2LXfR7z
X-Received: by 10.180.72.179 with SMTP id e19mr38604716wiv.53.1435703037649; Tue, 30 Jun 2015 15:23:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.95.211 with HTTP; Tue, 30 Jun 2015 15:23:18 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 30 Jun 2015 15:23:18 -0700
Message-ID: <CABcZeBOWK_WnHAefsZUBr4UyEkyiZqi1mhoZH8ZeGFftdOqTTw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f46d043c7ba28ff9360519c3a995"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vGmVMaWy0YHhS2JLLHxVckCZbAs>
Subject: [TLS] TLS 1.3 draft-07 sneak peek
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 22:24:02 -0000
Folks, Yesterday, I posted the -06 draft which snapshots the consensus changes made since -05, specifically: - Prohibit RC4 negotiation for backwards compatibility. - Freeze & deprecate record layer version field. - Update format of signatures with context. - Remove explicit IV. In the background, I've also been working with Hugo, Hoeteck, Karthik, and others to develop a new draft using semi-ephemeral DH based on Hugo's ideas as discussed in Dallas. I'm planning to merge this into master soon and submit it as draft-07 next week, but I wanted to e-mail the list and give people a chance to comment before I do that. I've provided a summary of the major changes and open issues below. Remember, this is a WIP so if you see something wrong, don't panic, but do let me know. CHANGES 1. Move ClientKeyShare into an extension so that the ClientHello is the only message in the client's first flight. This removes a bunch of ugliness around the "early_data" extension which could encapsulate handshake and application data. 2. Added a mechanism for the server to indicate a known (EC)DHE key/configuration which the client can then use in subsequent handshakes (via the known_configuration extension). The net effect here is that the client and server can skip over the signature in subsequent handshakes, which provides benefit when signatures are much slower than key exchange, as with RSA; it also enables 0-RTT. 3. Added support for 0-RTT data, both with and without client authentication. 4. Removed most of the support for resumption in favor of a mechanism proposed by Karthik where you just establish a PSK in connection N which you then use to key a PSK cipher suite in connection N+1. All of these keying mechanisms use a unified key schedule based on two keys the "Ephemeral Secret" (ES) and the "Static Secret" (SS). Depending on the exact handshake type, these may be equal, but the logic is the same regardless. In the process, I also converted the key schedule to use HKDF (per WG consensus). OPEN ISSUES There are still a number of known open issues to discuss: 1. The present known_configuration mechanism allows the client to resurrect the handshake parameters (though not the keys) which were negotiated in a previous handshake, but this is done implicitly, i.e., the server provides a label and the client returns it on the next connection. This has the advantage of keeping things short but the disadvantage the it means that you can't have a static configuration ID for everyone (instead, the server has to somehow embed the properties in the configuration ID). There are (at least) three potential alternative designs: (a) Have the client indicate in his first flight "these are the parameters I expect you to negotiate", along with the configuration identifier, based on what the server negotiated the previous time. [Optionally, the server can run the same negotiation locally and abort on mismatch.] (b) As in (a) but with no indication of the expected parameters, just the configuration ID, and the client just preemptively uses the parameters from the last time and if the negotiation ends up differently, all the data is undecryptable (ugh) and you somehow fall back. (c) Have the server provide a preference list in his ServerConfiguration (this can be the same as in the ClientHello) and have the client do the negotiation based on that rather than the server (as in QUIC). This is a little odd in that it means that sometimes the server selects the parameters and sometimes the client does, but it's not that hard to make this code symmetrical. As I think this through, I am leaning towards (a) but other people's opinions on this topic would be welcome. 2. Should we require that PSK cipher suites where the PSK is used for resumption use compatible ciphers? This is the way it was in TLS 1.2 and below for resumption and tickets, but once you have a PSK, that's not really necessary [0]. So, for instance, if you had the following cipher list order: ECDHE + AES-GCM ECDHE + ChaCha/Poly PSK + ChaCha/Poly PSK + AES-GCM You could potentially negotiate one connection with GCM, use it to establish a shared key, and then reconnect with ChaCha/Poly. This seems like it probably should be something we avoid, though I'm not sure we have a concrete reason why, and it means a weird special case for PSK. Note that this issue might be ameliorated some (though not completely) with a la carte negotiation. 3. I don't currently have PSK/Resumption + 0-RTT working, because you need a way to indicate the expected parameters (see point #1 above). 4. I plan to rewrite the Handshake Protocol Overview (S 6.2) to be clearer. I hope to do this before submitting -07. 5. Security Considerations is badly out of date, so I plan to rewrite that soon, but probably not before Prague. I also intend to do a pretty substantial editorial cleanup pass and potentially some restructuring after Prague. As indicated above, this is still a WIP, so no doubt contains a number of errors, potentially serious ones. Comments and PRs welcome. Thanks, -Ekr [0] With the exception of cryptographic concerns about the use of the same IKM with different hash functions for HKDF, but this is a problem that applies to any use of PSK, not just this one.
- [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hanno Böck
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Thomson
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Quynh Dang
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Watson Ladd
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Quynh Dang
- [TLS] MTI Extensions (was Re: TLS 1.3 draft-07 sn… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek William Whyte
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hanno Böck
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] TLS 1.3 draft-07 sneak peek Peter Gutmann
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dang, Quynh
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Martin Rex
- Re: [TLS] TLS 1.3 draft-07 sneak peek Ilari Liusvaara
- Re: [TLS] TLS 1.3 draft-07 sneak peek Karthikeyan Bhargavan
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Salz, Rich
- [TLS] Deprecate SHA1 for signatures in TLS 1.3 (w… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] TLS 1.3 draft-07 sneak peek Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Karthikeyan Bhargavan
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] TLS 1.3 draft-07 sneak peek Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Yoav Nir
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] TLS 1.3 draft-07 sneak peek Jeffrey Walton
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Yoav Nir
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Henrik Grubbström
- Re: [TLS] TLS 1.3 draft-07 sneak peek Salz, Rich
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Watson Ladd
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- [TLS] Explicit error expectations (was Re: Deprec… Dave Garrett
- Re: [TLS] Explicit error expectations (was Re: De… Viktor Dukhovni
- Re: [TLS] Explicit error expectations (was Re: De… Dave Garrett
- Re: [TLS] Explicit error expectations (was Re: De… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Henrik Grubbström
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Ilari Liusvaara
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Eric Rescorla
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Dave Garrett
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 for … Dave Garrett
- Re: [TLS] DANE & TLS 1.3 (was Re: Deprecate SHA1 … Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Hubert Kario
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Rex
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Andrei Popov
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Martin Thomson
- Re: [TLS] Deprecate SHA1 for signatures in TLS 1.… Viktor Dukhovni