Re: [TLS] Pull request for session hash

[Eric Rescorla <[e-mail]>]

On Wed, Dec 24, 2014 at 11:21 AM, Watson Ladd <[e-mail]> wrote:

> On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <[e-mail]> wrote
> >
> >> That would stop applications from exporting important system keys.
> >
> >
> > I suggested that, but  upon reconsideration it seemed a bit
> > over-complicated. What's the threat model you have in mind
> > here?
>
> Application authors shouldn't depend on magic details for their
> applications to be secure. So long as the exporter is capable of
> generating keys used to encrypt or authenticate data, the application
> author has to ensure that they don't accidentally do that. By making
> it impossible to mess up, we make the application author's job easier.
>
> I'm strongly in favor of making it easy to make secure systems.


It seems like the underlying desire is for separation between keys
and exporters, right? I know MSJ has asked for context separation
to make things more compatible with HSMs. Would that solve the
issue here as well, without creating a new MS?



>> "If the server does not request client authentication, the master
> >> secret can be computed at the time that the server sends its Finished,
> >> thus allowing the server to send traffic on its first flight (see
> >> [TODO] for security considerations on this practice.) If the server
> >> requests client authentication, this secret can be computed after the
> >> client's Certificate and CertificateVerify have been sent, or, if the
> >> client refuses client authentication, after the client's empty
> >> Certificate message has been sent."
> >>
> >> Server can't send data on first flight (to anonymous recipient) if
> >> it requests client authentication? E.g. HTTP/2 settings blocks,
> >> protocol banners or various other protocol capability negotiations.
> >
> >
> > That's correct. This is obviously not ideal but the alternative with this
> > design is to have an even more complicated key schedule. The idea
> > behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to
> > address this, though that's of course not the only way. What are
> > your thoughts here?
>
> I think we can deal with a more complicated implementation, so long as
> exposing the feature isn't that complicated. Transporting data ahead
> of checking who the person is that it is being sent to is very simple
> to expose: a function to accept data and send it, and one to check if
> the authentication is complete and who it is. Applications that can't
> meaningfully deal with this can be written as normal. But I'm still
> thinking about the right way to do this


See also the PR I point to above for an alternative protocol-level
implementation
of this.

-Ekr