Re: [TLS] HKDF

[Ilari Liusvaara <[e-mail]>]

On Wed, Mar 25, 2015 at 09:07:55PM -0500, Hugo Krawczyk wrote:
> On Wed, Mar 25, 2015 at 11:36 AM, Nikos Mavrogiannopoulos <[e-mail]>
> wrote:
> 
> > On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote:
> >
> >
> > >         One idea for meaningful reduction of complexity in TLS is if
> > >         we could switch to cipher-based KDF.
> > > ​That's for the WG to decide but the results we have for the
> > > extraction properties of block-cipher based PRFs are much weaker.
> >
> > I'm not sure whether the WG should even decide on replacing the KDF or
> > the main protocols used. That was certainly a non-goal for TLS 1.3 and
> >
> 
> ​
> There is an explicit goal of supporting forward secrecy and 0-RTT.
> Both require changes to the protocol, in particular the latter requires
> introducing server's (semi) static DH keys and an authentication mode that
> cannot be solely based on signatures hence necessarily departing from
> previous TLS versions. You could add support for the above elements as a
> patch/addition to the protocol but even then you would need a review of the
> new cryptographic elements and their interaction with the old ones (which
> may be trickier to analyze than a well-formed uniform protocol).

Well, these changes to "unify" the key exchange completely change how
to the key exchange works, and need to completely redo any security
analysis. This is nasty for multiple reasons:
a) The scope of analysis is very broad (there have been a number of
   "TLS proven secure" papers that don't prove TLS secure, due to
   insufficient scope)
b) The changes to proposed look to make it much harder to analyze,
   even if 0RTT is assumed unsupported
c) When 0RTT is added, I don't see how the changes make the interaction
   any easier to analyze.


-Ilari