Subject: Re: [TLS] Pull request for session hash

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Dec 2014 13:33:13 -0800

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.

Best,
-Ekr

On Fri, Nov 7, 2014 at 2:01 PM, Eric Rescorla <[email-masked]> wrote:

> I've created a preliminary pull request to adapt the session hash fix for
> TLS 1.3
> for feedback from the WG.
>
> Points to note:
>
> - IMPORTANT: Because the initial handshake messages are encrypted
>   under separate keys from the application data traffic, it seems like we
> need
>   to have 2 sets of CCS messages or none. In anticipation of removing
>   renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88).
>   Based on conversations with Alfredo and Martin, it seemed easier
>   to remove them. Warning: analysis needed here.
>
> - I created a separate resumption master secret that is fed into the
>   key hierarchy. This makes the description of that simpler but will
>   need revisiting if we adopt either Rich's unification of session hash
>   and tickets or Karthik's PSK-as-tickets unification, but that seemed
>   like a separate issue.
>
> - If we adopt the Update proposal we will also need to split the master
>   keys into two directional keys, but that's distinct as well.
>
> - I still need to add the names of the session hash authors t
>   acknowledgements.
>
> This will probably need another revision before it is ready for merging,
> but
> I wanted to get it out there for feedback.
>
> -Ekr
>
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Dec 2014 16:26:48 +0200

> 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.

"[[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).

Yes, I know that the hellos MUST be the same. But didn't we have a
case of MUST being violated leading into a nasty security hole recently?

If hashes are restarted and 1st ClientHello and HelloRetryRequest can be
tampered with, the conseqences are not something I want to even try to
analyze (implementation-dependent!).

If hashes are continued, then it requires MITM to modify anything in
key exchange. And the latter authentication pass should be able to
detect that MITM.

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

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

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).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 10:29:33 -0800

> 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.

> 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.

I suggested that, but  upon reconsideration it seemed a bit
over-complicated. What's the threat model you have in mind
here?

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

> 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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 24 Dec 2014 14:21:41 -0500

On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <[email-masked]> wrote:
>
>
> On Tue, Dec 23, 2014 at 6:26 AM, Ilari Liusvaara
> <[email-masked]> wrote:
>>

I don't know why it existed in the first place, so I feel compelled to
ask what that reason was and why it doesn't still apply.

> over-complicated. What's the threat model you have in mind

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.

> address this, though that's of course not the only way. What are

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.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 13:03:44 -0800

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

> On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <[email-masked]> wrote
> >

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?

> 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