Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

From: Sean Turner <[email-masked]>
Date: Wed, 17 Jun 2015 15:03:13 -0400

All,

The consensus of the WG is to replace the current TLS PRF with an HKDF PRF.  Being more specific (and using Brian’s wording), the TLS 1.3 will use an HKDF-Extract, then HKDF-Expand, with suitable parameters, as recommended in RFC5869, to build the keyblock that will be partitioned into keys.  The TLS extractor will also use HKDF in a similar way for new versions of TLS.

WRT the downref issue, this seems entirely procedural and can be dealt with during the WG/IETF LCs; we’ll call it out in our WGLC,  get our AD to do it during the IETF LC per the procedures in RFC 3967, and assuming consensus is reached we can normatively refer to an informational RFC.

WRT msj’s technical comments about including the length L of the output key material to the info string, it seems like we are free to do so if we choose to.  I want to avoid having a consensus call on every issue so if somebody is really against adding the length L of the output key material to the info string - please start a thread and say why not.

spt

On Apr 01, 2015, at 14:00, Sean Turner <[email-masked]> wrote:

> This message is to confirm the consensus reached @ the IETF 92 TLS session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an HKDF-based PRF (see http://datatracker.ietf.org/doc/rfc5869/?include_text=1).
> 
> Please indicate whether or not you agree with the consensus by 2015-04-17.  If not, please indicate why.  Also, please note that we’re interested in uncovering new issues not rehashing issues already discussed.
> 
> Thanks - J&S

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jun 2015 12:06:19 -0700

Chairs,

I will work with Hugo to develop an appropriate proposal based on this
direction.

Thanks,
-Ekr

On Wed, Jun 17, 2015 at 12:03 PM, Sean Turner <[email-masked]> wrote:

> All,
>
> The consensus of the WG is to replace the current TLS PRF with an HKDF
> PRF.  Being more specific (and using Brian’s wording), the TLS 1.3 will use
> an HKDF-Extract, then HKDF-Expand, with suitable parameters, as recommended
> in RFC5869, to build the keyblock that will be partitioned into keys.  The
> TLS extractor will also use HKDF in a similar way for new versions of TLS.
>
> WRT the downref issue, this seems entirely procedural and can be dealt
> with during the WG/IETF LCs; we’ll call it out in our WGLC,  get our AD to
> do it during the IETF LC per the procedures in RFC 3967, and assuming
> consensus is reached we can normatively refer to an informational RFC.
>
> WRT msj’s technical comments about including the length L of the output
> key material to the info string, it seems like we are free to do so if we
> choose to.  I want to avoid having a consensus call on every issue so if
> somebody is really against adding the length L of the output key material
> to the info string - please start a thread and say why not.
>
> spt
>
> > This message is to confirm the consensus reached @ the IETF 92 TLS
> session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF
> be an HKDF-based PRF (see
> http://datatracker.ietf.org/doc/rfc5869/?include_text=1).
> >
> > Please indicate whether or not you agree with the consensus by
> 2015-04-17.  If not, please indicate why.  Also, please note that we’re
> interested in uncovering new issues not rehashing issues already discussed.
> >
> > Thanks - J&S
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>