[TLS] Draft minutes from IETF 92

"Salz, Rich" <rsalz@akamai.com> Thu, 26 March 2015 16:33 UTC

From: "Salz, Rich" <rsalz@akamai.com>
To: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Thread-Topic: Draft minutes from IETF 92
Thread-Index: AdBnzMwJmCFbGvO3RB6aOB5sq2b72w==
Date: Thu, 26 Mar 2015 16:31:22 +0000
Message-ID: <4c1c3b9cad294bd49d6a5ba5f007eeff@usma1ex-dag1mb2.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/KX6QuLsE34lKbnkntITznE23axg>
Subject: [TLS] Draft minutes from IETF 92
Precedence: list

Draft minutes; please post corrections.

Swap two agenda items (0RTT and OPTLS)

Draft status update; see pages 5 and 6 of http://tools.ietf.org/agenda/92/slides/slides-92-tls-1.pdf WG chairs intend to ask if WG wants to adopt
draft-mavrogiannopoulos-chacha-tls, draft-josefsson-tls-curve25519 and draft-bmoeller-tls-falsestart as documents (starting points,

Backward compatibility: reviewed github pull request 107; no controversy, going to adopt it.

Changes since -03 draft http://www.ietf.org/proceedings/92/slides/slides-92-tls-3.pdf Point format negotiation removed; add context to signatures (to prevent re-use); remove renegotiation; remove ChangeCipherSpec; extendedMasterSecret draft is included; remove ability to negotiate sslv3

0RTT; client has "static" ephemeral key, encrypts first part using that, server reply has its ephemeral, and now rest of data is PFS. This is well-understood key exchange. Issues arise with anti-reply, based on each side providing random value mixed into keying material. With 0RTT client anti-reply guaranteed, but not server. Protect this with server cache. But that doesn't work; see p8-10, and mail list thread. Propose concept of a special API to set or read the 0RTT payload. Strong consensus to do this, to be confirmed on the list. There are concerns about how/when other protocols could use this. Sean to take up initial conversations. Ekr, dkg, agl to post something to the list based on "option 3" on p11.

DH-based handshake. First brought up in Paris Interim, discussed in HI, Seattle Interim, etc. Moving to static DH based (two DH key exchanges) unifies 0RTT, 1RTT, PSK ciphers. There are some extra costs; server that doesn't do 0RTT it can make both keys the same and avoid the extra modexp Hugo presented slides on the rationale for this approach; see http://www.ietf.org/proceedings/92/slides/slides-92-tls-4.pdf . Basically since TLS 1.3 has PFS 0RTT and EC-centric, there can be a unified approach (two dh keys). Also benefit of simpler protocol to analyze and (perhaps only brand new) implementations. Discussion of possible loss of resumption. Should we move to OPtls (pull request 90). Consensus hum was to do this.

Move to HKDF. (Is there anything wrong with TLS PRF? Hugo: Yes, initially keyed with a secret that is not necessarily strongly random; okay with RSA). HKDF has better properties. Strong consensus to do this.

AEAED IV. Strong consensus to do nothing; some support for per-sesion XOR mask. To go to the list .

--
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz

[TLS] Draft minutes from IETF 92 Salz, Rich