Re: [TLS] Pull request for session hash

[Eric Rescorla <[e-mail]>]

On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara <
[e-mail]> wrote:

> On Mon, Dec 22, 2014 at 01:33:13PM -0800, Eric Rescorla wrote:
> > I've posted an updated PR at:
> >
> > https://github.com/tlswg/tls13-spec/pull/89
> >
> > Note that I did not restore the ChangeCipherSpec message as my sense of
> > the WG discussion and private conversations was that people preferred to
> > have it gone. If you feel strongly about this change one way or the
> other,
> > and haven't already posted to the list about it, please do so now, as I'd
> > like to resolve this and merge this PR this week.
> >
>
> (General philosophical note: I'm in favor of more complicated protocol if:
> - It fixes something that is just plain nasty to analyze, or
> - It causes bad implementations to break fast instead of being security
> timebombs.)
>
>
> Regarding CCS removal, I'm very much in favor.
>
>
> Reading through this, some comments:
>
> "At this point, the handshake is complete, and the client and server may
> exchange application layer data, which is protected using a new set of
> keys derived from both the premaster secret and the handshake transcript
> (see {{I-D.ietf-tls-session-hash}} for the security rationale for this.)"
>
> AFAIK, I-D.ietf-tls-session-hash doesn't really contain security rationale
> for this. It only has security rationale for hashing exchange keys (which
> are included in the first keying anyway) and says about including
> certificates (paraprhased): "Compliant with NIST recommediations" and
> "SSH does this" (actually, it only does that for server key, not client
> key).
>
> Now, if EncryptedExtensions contains extensions that twiddle with some
> critical parameters, there is very much reason to rekey after that.
>

In conversations with the INRIA guys, the general consensus seemed to
be that hashing more was more conservative. I'll work with them to get
some text around this either here or in the session hash draft.




> "[[OPEN ISSUE: Should we restart the handshake hash?
> https://github.com/tlswg/tls13-spec/issues/104.]]"
>




> I regard restarting the hashes as very dangerous (not that I think that
> the whole HRR is a good idea, but I don't say more about that).
>

The expectation in the current draft is that you do not restart the
handshake
hash, but I know there are different opinions about that, hence the open
issue. Let's discuss this separately, since the only change in this area
in this PR is to add the issue marker.


"This master secret value is used to generate the record protection
> keys used for the handshake, as described in {{key-calculation}}. It is
> also used with TLS Exporters {{RFC5705}}."
>
> Wasn't there an idea for giving TLS Exporter its own master secret?
>

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?




> "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?



> Obviously, generating the resumption premaster secret has to wait for
> client finished (otherwise one can run into trouble with just
> transport glitches, no attackers required).
>
>
> Looks like for the resume case, the ClientHello and ServerHello are
> hashed into keys. I think this should be done (I don't se attacks
> otherwise, but that doesn't mean there could not be one... This
> is another of those "I don't want to analyze that" places).


If I am reading this correctly, you are happy with this piece, or are you
suggesting a change?

Best,
-Ekr