Re: [TLS] Initial draft of DH-based key exchange

[Ilari Liusvaara <[e-mail]>]

Sorry, this is quite long.

Some background:

Be very vary about "security proofs". The scope of how TLS is used is
very broad. There have been numerious papers about "TLS proven secure"
or "part X of TLS proven secure", that have later turned out to be
irrelevant in practice due to insufficient scope (then there are
ocassional security proofs that are just plain wrong).

E.g. number of papers that overlooked that TLS MS is not CRK and
the screwyness that this causes. E.g. breaking authentication. Or
paper that proved that "BEAST" is impossible... Only to turn out
that it had made an assumption that BEAST attack broke.

This problem is compounded by the fact that TLS is often used in
environments like WWW, where attackers have unusual powers to
exploit weaknesses that normally are not exploitable.

The consequence is that even if some "security proof" says that
it is okay to simplify system in some way, that simplification
might still introduce vulernabilities.

E.g. Consider TLS 1.3 draft -03 (I picked this because it is the
earliest version that I think is implementable at all). It is a
bit simpler than -04, and I think that it in some scope can be
proven "secure". But it also has a known security hole (fixed in
-04).

OTOH, security proofs that produce conterexamples to security
are useful to look at. The counterexample may or may not be
relevant (telling which is likely nontrivial). If it is relevant
or might be relevant, fixing the problem is worth it.


Symmetric crypto is very fast, so a bit of extra hashing, PRFing
or somesuch is pretty much insignificant compared to asymmeric
things like computing signatures, DHFs or DHKGs.


Short summary: Security proofs are useful, but relying on them
is a very bad idea.


On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote:
> Folks,
> 
> As an outcome of the interim, I was asked to write up an initial draft
> of what this would all look like and post it to the list. You can find
> such a draft at:
> 
> Git branch:
> https://github.com/ekr/tls13-spec/tree/WIP_dh_based
> 
> Text file:
> https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt
> 
> HTML diff:
> https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.html
> 
> 
> Please note that this is a very rough draft and no doubt contains
> a number of major errors (and certainly has seen no security review).
> Please point these out to me if you find them, especially if they
> impede understanding. Assuming that people are happy with this
> general direction, I will clean it up and turn it into a PR.

Okay, let's analyze what goes wrong (and fix the thing so it is easy
to analyze):

- For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs, not two.
  1) PSK input.
  2) PFS diffie-hellman input
  3) Static Diffie-Hellman input.
  -> 1 and 3 are not the same, even if they can't appear simultaneously!
- For chaining keys from 0RTT (optional), you need _fourth_ input:
  4) Static diffie-hellman from 0RTT.
  -> Only computable if server accepts 0RTT.
  -> Needed for gradual static-DH rollover.
- The "handshake master secret" needs to be CR function of:
  1) PFS diffie-hellman iput.
  2) PSK input.
  3) Static diffie-hellman from 0RTT (if exists)
  4) Hash of *Hello and *KeyShare packets.
  -> The reason for last is to defend against class of attacks including
     Triple Handshake.
- The "application master secret" needs to be CR function of:
  1) handshake master secret.
  2) Static Diffie-Hellman input.
  -> The hash is not needed here (but can be included).
  -> Can be different in both directions (which has some benefits,
     in this case, the hash should be included).
- The "exporter master secret" needs to be CR function of:
  1) hanshake master secret.
  2) Static Diffie-Hellman input.
  3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is
     carrying the server static DH key packets (more can be included
     for a good measure).
  -> The reason why EncryptedExtensions needs to be included is in case
     it contains some extensions affecting TLS-Extractor. The reason
     server static DH key is needed is again to guard against attacks
     like THS.
- The "resume premaster secret" needs to be CR function of:
  1) hanshake master secret.
  2) Static Diffie-Hellman input.
  3) Hash of entiere handshake.
  -> The reason why last needs needs to be entiere handshake is that
     otherwise session may be resumed in inocnsistent state.
  -> Also so that resumption doesn't destroy forward security.
- Online signature (if present) TBS needs to include:
  1) *Random
  2) Purpose of signature (e.g. server PoP)
  3) Ciphersuite #
  4) Prf-hash of messages so far
  -> *Random is to support privsep. Which is extremely useful even with
     pure SW if you have MMU available (and most of the time you do).
  -> Ciphersuite # is to pin the prf-hash algorithm (I think that is
     just the simplest way).


The "function of" listings above are what I consider the absolute
minimum, that's the reason why "application master secret" hash input
is not marked as needed. It can (and should) be included.

Also, one should take care that none of the different secrets may
end up being same (except by very bad luck).

The only thing above -05 fails is "exporter master secret", which
is the same as handshake master secret nor does it hash enough state.


Also, other comments:
- I consider HKDF-HMAC-SHA256 to be too weak.
  -> I think it needs at least HMAC-SHA384 (also would just give one
     prf-hash).
  -> SHA384 is FASTER than SHA256 on modern hardware (that's why
     SHA-512/256 exists). But SHA3-384 is slower than SHA3-256.
- There is no need to intermingle static DH key with signature, even if
  statid DH key exists.
  -> Signatures work like in -05.
  -> Can completely eliminate signature if one has fixed-DH cert (DHF
     is WAY simpler than signature primitive).


Also, will *server* 0RTT be supported, even with client authentication?
It would set the following boundary conditions:
- Server application keys can't include hashes of client certificate,
  as those need to be computable immediately on server finished.
- The same for exporter master secret.

The restrictions here are:
- Replay protection is provoded.
- There is no authentication (the server hasn't heard client's
  certificate, which keeps misuse potential way down).

Usecases:
- Protocol banners, feature negoitiation (ALPN doesn't scale!),
  etc...


Also regarding splitting application keys to directional ones:
- Allows JIT derivation, eliminating temporarily invalid keys.
- Allows rekeying (since requirement is no dead time and arbitrarily
  delayed responses, as breaking this causes problems for all
  applications).



-Ilari