Minutes for TLS at IETF-92
minutes-92-tls-1

IETF 92 - TLS Working Group Meeting
Location: Dallas, TX, USA
Date: Thursday, March 27, 2015 - Morning Session
Chairs: Sean Turner, Joe Salowey
Note Taker: Rich Salz
Version: 1
———————————————————
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 .