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

[Hugo Krawczyk <[e-mail]>]

Illari

(I wrote this offline as a response to your email below -
it may not address issues raised in follow up email)

As usual you raise good questions, even when I don't agree with your
answers or
conclusions. Let me refer to what I believe is the most important point in
your
email, namely, the reliance on theoretical analysis of cryptographic
protocols.

I agree with warnings about total reliance on theoretical analysis or its
interpretation as demonstrating the absolute lack of attack venues against a
protocol. Any mathematical model that attempts to capture real-world
phenomena
is prone to fail in some circumstances, and this is certainly the case for
systems of the complexity of TLS and the Internet. Add to this that the
attacker
being modeled in the case of cryptography is as malicious as only humans
can be
(how do you design an airplane against an insane pilot purposely crashing it
into the Alps or a building that needs to withstand the impact of a jet
guided
by suicide terrorists?) and you can ensure without doubt that no model will
be
full proof.

However, I cannot agree with the unqualified conclusion that
  "relying on [these models] is a very bad idea".
Relying on the theoretical models developed and refined over the years is a
major source of confidence in the soundness of the core design of a
cryptographic protocol, a core that may miss essential specification and
implementation details and semantics but that tells us that the very
foundation
of the building is sound.  Many things can fail in that building at higher
levels but not at the most basic foundational cryptographic aspect.
Moreover,
contrary to what you indicate, cryptographic analysis while imperfect has
been
remarkably successful in predicting attacks, particularly against TLS. This
is
the case for CCA attacks against RSA, the essential role of unpredictable
IVs in
CBC mode, the shortcomings of mac-then-encrypt, the potential exploits from
packet compression, etc.  It is true that theoreticians (like me) don't
always
have the knowledge or skills to translate the failures demonstrated in our
proofs into real-world attacks, but the world eventually catches up and
finishes
what we started.

One way to look at cryptographic analysis is as a debugging process. Any
such
process is successful when it helps spotting problems and potential
failures but
you never really trust that any of these problems is the *last* bug to be
found.
Yet everyone agrees on the usefulness of such tools. Fortunately, the
analysis
tools at our disposal increase over time and so is the number of problems
we can
spot before they become practical ones. The recent works from INRIA and
Microsoft on automated tools for analyzing not only the core cryptographic
protocol but also its fuller specifications and implementation are great
examples.

With respect to the point that
  "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
  vulnerabilities.",
This is of course a possibility. It falls under "keep it simple but not
simpler"
principle, but it is in no way a demonstration that simplifications aren't
important. They are and if they can be founded on formal analysis then the
better. A simpler protocol is easier to specify, implement and maintain
(e.g.,
adopting it to new settings and requirements). Safety margins are necessary
but
we need to understand what is their role, or else we will end with
impractical
or unnecessarily complex schemes that are likely to fail in many other ways.

In the particular case of OPTLS, I strongly believe that it contributes
significantly to the simplification of TLS 1.3 and to a sound cryptographic
design (although we need the proofs to move this from a personal belief to
something others can verify). I am also under the impression that
implementers
and specifiers do appreciate the simplification of the protocol, and future
designers will do as well when coming to evolve the protocol into new
realities.

Hugo


On Fri, Mar 27, 2015 at 11:00 AM, Ilari Liusvaara <
[e-mail]> wrote:

> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>