Re: [TLS] Pull request for session hash

[Ilari Liusvaara <[e-mail]>]

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.


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