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

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 08:36:41 -0500

Folks,

At the interim discussed transitioning to a DH-based handshake (rather
than a signature-based one) like that proposed by Hugo Krawczyk and
Hoeteck Wee. The major rationale for this change is that any 0-RTT
mode is inherently DH-based and so if we make that our basic mode,
then we can simplify the protocol logic and key derivation model. This
model also allows us to pull in PSK modes under the same basic
structure.

However, in the near term it's clear that servers will continue to
have RSA and ECDSA certificates rather than (EC)DH certificates, so
we need some way to reuse those credentials. The two major options are:

- An offline signature of the server's DH share.
- An online signature of the server's DH share that's tied to the
  handshake in some way.

The WG sentiment was generally favorable to exploring this avenue but
there was also airly strong WG sentiment that we didn't presently want
to do an offline signatures. This leaves with a model in which the
client initially learns the server's semi-static DH share through
an online-signed 1-RTT handshake but then can cache it for use with
future connections.

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.

A number of other notes:

- There is generally not support here for 0-RTT. I am developing that
  on a separate branch (based on that branch) and will be cleaning it
  up and posting it in the next few days. You will, however, probably
  notice some hooks for 0-RTT that don't do anything yet.

- In Section 7.3.7 there is a discussion about using the same DH share
  for the semi-static and epehemeral server keys. This is an important
  part of getting performance comparable between the 1-RTT mode and
  the current 1-RTT mode. We discussed this extensively at the interim
  and I believe that Hugo and Hoeteck consider this safe, but any
  information to the contrary would be very useful at this point.

- The key schedule in Section 8.1 is probably going to change, but
  that shouldn't impede understanding.

- During the interim we also discussed moving to HKDF. This branch
  includes a draft version of that change as well as using separate
  HKDF invocations to generate each traffic key.

As usual comments welcome; I look forward to discussing this in Dallas.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Mar 2015 16:05:47 +0100

> model also allows us to pull in PSK modes under the same basic
[...]
> an online-signed 1-RTT handshake but then can cache it for use with

Wasn't that discussed in the list before? My impression was that the
outcome of that discussion was not to add that.

Anyway, a first question that comes to mind, is why this isn't defined
as separate ciphersuites? Why does it even have to be TLS 1.3 related?
Static DH parameters is an experiment that failed years ago. What has
changed since then that we believe now it is going to work? You even
dropped the static DH ciphersuites from TLS 1.3. Please make that part
optional so you don't doom the whole TLS 1.3 protocol enhancements if
no-one switches to static DH keys (in the document they are described as
semi-static DH keys - but there is no definition of what that means).

A second question is why HKDF? Why is it even there? Is there any issue
with the current TLS PRF and we need another? Is there a valid reason to
bloat implementations with shipping multiple KDFs? This kind of changes
shouldn't be done without thought, as it is now there cannot be any code
sharing between TLS 1.2 and 1.3 and we risk having implementers stay
with TLS 1.2 for the next decade.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 11:13:56 -0500

> outcome of that discussion was not to add that.

There was enough interest that we decided to revisit it at the interim
in view of the considerations I listed above, and the chairs asked
me to draft it up so we could discuss here and in Dallas. As I said
above, the WG can of course decide not to proceed in this direction
which is why this is a separate branch rather than -06.

> semi-static DH keys - but there is no definition of what that means).

Well, what's being done here is qualitatively different in three ways:

1. The DH keys aren't in DH certificates (though one supposes they
    could be), rather they are attested to by the server signing key.

2. The semi-static DH keys are expected to be quite short-lived
    (possible because of point #1). Hence 'semi-static'.

3. We are doing a separate ephemeral-ephemeral DH exchange to
    provide PFS.

The argument for not making it a cipher suite is that doing things
this way allows us to have a unified protocol logic whereas that's
not true if it's a separate option.

> bloat implementations with shipping multiple KDFs?

As I said separately [0], there was some sentiment in the interim that
HKDF was a more modern primitive. As above, I can easily back this
out and use the existing PRF if that's what people prefer.

-Ekr

[0] https://www.ietf.org/mail-archive/web/tls/current/msg15625.html

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 23 Mar 2015 15:22:05 -0400

Hi Nikos,

These are good questions - see responses below.

> outcome of that discussion was not to add that.

​The objections to the original proposal were related to the use of offline
signatures to sign a semi-static DH key. This is not an option in ekr's
draft. Neither the draft accommodates DH certificates. All server's
authentication is based on regular (online) TLS signatures except if the
client has cached a semi-static key from the server as needed to support
0-RTT. In the latte case authentication must be done via the possession of
the semi-static DH secret by the server (a 0-RTT flow cannot be
authenticated via signatures).
​

> changed since then that we believe now it is going to work? You even

​Two important things change in TLS 1.3:​
- Forward secrecy (PFS) is now mandatory.
- The protocol accommodate a 0-RTT mode.

These two changes can only be implemented via Diffie-Hellman transforms (in
theory, any CCA-secure public key encryption can be used but (EC)DH is the
only currently practical instantiation in this setting). In particular,
0-RTT requires supporting semi-static DH keys for the server. All that ekr
draft does is to build a protocol where PFS is supported, 0-RTT is
supported, semi-static keys are supported, and TLS-type signatures are
supported in any case where the client does not have a cached semi-static
key of the server. The beauty of it, if I can say so, is that all these
modes are just subsets of a single protocol with a single crypto logic and
uniform specification (which also covers uniformly PSK and resumption).

The alternative is to keep TLS 1.2 and add to it the semi-static case as a
patch, hence requiring essentially implementing all that is now in ekr's
draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the
cryptographic analysis point of view this would mean analyzing two separate
protocols as well as making sure these two protocols do not have any bad
interaction when put together.

​

> with TLS 1.2 for the next decade.

​HKDF is just a way of structuring the use of TLS PRF (HMAC-PRF) in a way
that supports a uniform, hierarchical key derivation scheme which is common
to all the modes of the protocol as discussed above (including PSK, Export,
resumption, etc.) and which accommodates deriving keys from possibly
non-uniform secrets such as DH values, passphrases, etc. In particular, it
sets no requirements or assumptions in the form of the secret/entropy
source from which keys are derived, hence freeing the protocol
instantiation from things like point representation in an elliptic curve
(it will work with compressed representation, uncompressed ones, etc).

I believe these are all huge benefits at all levels: design, analysis,
specification, implementation, maintenance of the protocol (future
changes/additions). I cannot comment on code sharing though, although I
hope we do not ruin the future by tying ourselves too much to the past.

Hugo
​

>
> regards,
> Nikos
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Mar 2015 22:54:57 +0200

On Mon, Mar 23, 2015 at 03:22:05PM -0400, Hugo Krawczyk wrote:
> 0-RTT.

I think that is the worst case.

ECC signature generation are faster than ECDH operation. But OTOH, ECDH
operation is much easier to implement than ECC signature. So one gets
slowdown for no simplification.

Also, two-level key schemes have certain benefits, but lack of offline
signing makes it one-level key scheme with two keys.

> interaction when put together.

The simplest way to do 0RTT would be for server to signal parameters for
0RTT in extension and then client to put public keys and 0RTT data ((EC)IES)
into ClientHello extension (doesn't work that well in TLS 1.2 still).

Of course, that provodes absolutely no replay protection...

> hope we do not ruin the future by tying ourselves too much to the past.

Well, to me the key derivation in EKR draft (using HKDF) looks much more
messy than the one in editor draft (using classic TLS PRF)

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 16:01:35 -0500

> messy than the one in editor draft (using classic TLS PRF)

Note that we could certainly use the TLS PRF with this DH-based structure,
I'm just trying to keep the number of branches I'm working on down to a
managable
structure and I had the sense from the interim that people wanted HKDF.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 23 Mar 2015 17:05:22 -0400

0-RTT with (EC)IES is exactly what we are doing.
Keeping online signatures is what the WG wanted (the other option is
offline signatures or DH certificates which had opposition).
If you can come with a simplified design combining these things, I will be
happy to hear.

The KDF derivation scheme is as simple as it gets for all keys that need to
be derived and is uniform for all modes.
You could save one level of extraction if you were willing to key the prf
with your DH secrets, which I do not recommend.

Hugo

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Mar 2015 21:15:41 +0000

So this is pretty amazing.  We have a proposed uniform key exchange method that uses one primitive and covers all the use cases.  And we have a proposed uniform KDF function that also covers all use cases.

How can you not like this?  :) Let's call it 2.0, drop record version, IV duplication, etc.  Just have to keep the existing hello messages for interop.

	/r$

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 16:21:03 -0500

On Mon, Mar 23, 2015 at 4:15 PM, Salz, Rich <[email-masked]> wrote:

> IV duplication, etc.

Can you clarify what you mean about "IV duplication"? Are you referring
to the per-record IVs? If so you might be interested in:

https://github.com/tlswg/tls13-spec/pull/155

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 Mar 2015 21:23:54 +0000

Yes, I meant the per-record IV.  I was just too distracted to look up the PR.

--
Senior Architect, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Dave Garrett <[email-masked]>
Date: Mon, 23 Mar 2015 18:52:57 -0400

> How can you not like this?  :) Let's call it 2.0, drop record version, IV duplication, etc.  Just have to keep the existing hello messages for interop.

I'm in favor of naming this TLS 2.0 as well, but the on-the-wire version number should stay {3,4} and not {4,0} because TLS version intolerance >1.x is even worse. Probably time to change ProtocolVersion to a 16-bit enum with values based on the existing pattern instead of keeping up the {major,minor} farce. ;)

Dave

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 24 Mar 2015 09:12:26 +0100

On Mon, 2015-03-23 at 17:05 -0400, Hugo Krawczyk wrote:

> The KDF derivation scheme is as simple as it gets for all keys that
> need to be derived and is uniform for all modes.

Note, that an implementation will still have to keep the original PRF to
support all previous protocols. Given the average life time of a
protocol that means keeping two separate KDFs for 10-20 years. That is
not an enormous cost, but the piling of simple primitives don't make a
simple protocol or even worse a simple implementation.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 24 Mar 2015 09:28:29 +0100

On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote:

> These two changes can only be implemented via Diffie-Hellman
> transforms (in theory, any CCA-secure public key encryption can be
> used but (EC)DH is the only currently practical instantiation in this
> setting). In particular, 0-RTT requires supporting semi-static DH keys
> for the server. All that ekr draft does is to build a protocol where
> PFS is supported, 0-RTT is supported, semi-static keys are supported,
> and TLS-type signatures are supported in any case where the client
> does not have a cached semi-static key of the server. The beauty of
> it, if I can say so, is that all these modes are just subsets of a
> single protocol with a single crypto logic and uniform specification
> (which also covers uniformly PSK and resumption).

So if I understand well the additional semi-static key is to support the
0-rtt case only, and otherwise it should be simply a copy of the
ephemeral key? I cannot say I fully follow the protocol in all possible
scenarios. It would be nice to have a message flow of the interactions
for the DH key exchange in all the cases (e.g., PSK) either as an
appendix or the main text. As we are moving to non-widely known key
exchanges it makes sense to document them clearly, or at least link to
documents which define them.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Mar 2015 16:03:45 +0200

>From what I can understand, it adds interrim server DH key, which server
signs (which may be the same as the server eph. key), computes DH of
both with client eph. key and mixes those to become session keys
(the interrim key can be reused to become 0RTT key for the next
connection).

So roughly:
- Client: C_pub_e 
- Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages)
- 0RTT key: F(DH(S_pub_s_prev, C_pub_e)
- Session keys: G(DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e))

To me, this looks to lose all the benefits of of offline version:
- The offline version is two-level key scheme, this isn't.
- This version is quite a bit slower unless you disable 0RTT.
- The offline version avoids server to have implement online
  signature, simplifying the code a good bit (especially if the
  signature is apparently intentionally made difficult, like ECDSA).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Mar 2015 09:07:52 -0500

> - This version is quite a bit slower unless you disable 0RTT.

Note: we haven't yet determined how we are going to establish
the key for  future 0-RTT messages. You could reuse the key
as you said above, but you could also just send a second key
in a separate message, in which case you wouldn't have to take
the hit, but at slightly more protocol complexity.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 24 Mar 2015 11:31:06 -0400

On Tue, Mar 24, 2015 at 10:03 AM, Ilari Liusvaara <
[email-masked]> wrote:

> - 0RTT key: F(DH(
> ​​
> S_pub_s_prev, C_pub_e)
> - Session keys: G(
> ​​
> DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e))
>

​Yup. That's the basic idea.
In the case that there is no ​​S_pub_s_prev cached at the client (hence not
in 0-RTT mode), one can save one exponentiation in the computation of
session keys by making the new S_pub_s ephemeral, or equal to S_pub_e.
In this case  DH(S_pub_s, C_pub_e) = DH(S_pub_e, C_pub_e)
hence requiring a single exponentiation. This is as efficient as it gets if
you want to use online signatures for freshness and also provide PFS.
(Note that you are getting PFS by virtue of S_sub_s being ephemeral, i.e.,
used for a single session.)

Those happy with the signature mode of TLS 1.3 prior to the inclusion of
OPTLS techniques should be happy with the above ephemeral-only mode. It is
essentially equivalent to what was there before except that it is
structured to match the overall logic of OPTLS.

>   signature is apparently intentionally made difficult, like ECDSA).

​I agree with your sentiment. These were all advantages of the original
OPTLS but people raised objections to offline signatures​

​so we had to keep as many of the original advantages while resorting to
online signatures.
Still, there are significant advantages in providing a simple and uniform
structure to all the modes of the protocol (0-RTT, cached server's
semi-static key at the client, ephemeral-only server key, and pre-shared
key with and without PFS).

Moreover, the protocol is already structured for possible future
adaptations to the case of offline signatures (possibly eliminating all
signatures other than for certificate verification)  and/or use of DH
certificates.

Hugo

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Mar 2015 17:00:32 +0200

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.

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Mar 2015 10:29:16 -0500

On Fri, Mar 27, 2015 at 10:00 AM, Ilari Liusvaara
> is the same as handshake master secret nor does it hash enough state.

This was an editorial error in -04 but should be the final master secret
in -05:

https://github.com/tlswg/tls13-spec/commit/ee4a437d0824efaa7e0c952a4af960bdc304a2f3

-Ekr

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 27 Mar 2015 15:27:54 +0000

Hi Ilari,

On 27/03/2015 10:00, "Ilari Liusvaara" <[email-masked]> wrote:

>the screwyness that this causes. E.g. breaking authentication.

No, the papers that I think you are referring to did not overlook that TLS
MS is not CRK. The problem is that they did not include renegotiation and
resumption in their scope, thereby not excluding the renegotiation attack
and the subsequent triple Handshake attack. So, yes, it's a scoping issue.
But no, it's not the thing you point to, it's that thing in combination
with other things.

Recent papers on this topic (one of which [0] I am a co-author on) are, I
believe, quite clear about their limitations of scope (my own paper [0],
for example, contains a whole section explaining what is not included in
the model and why that matters).

The limitation of scope does not mean the papers are useless. As you write
above, one just needs to be wary of over-interpreting what they say.

>Or

I'm pretty familiar with the TLS and the relevant symmetric crypto
literature, but can't immediately identify your source here. If you can
give an exact reference, then we can debate what it did and did not say,
and thereby discuss the value of proofs and the limitations of models.

However, one thing I can say immediately is that the symmetric crypto
literature is pretty clear that IVs for CBC mode need to be random (see
[1], from 1997), and exhibited on-paper distinguishing attacks when they
are not (see Section 9 of [2], dating from 1995).

TLS 1.0 used predictable IVs despite clear warnings from the crypto
community. And predictable IVs enabled BEAST. Please don't shoot the
messengers.

>Short summary: Security proofs are useful, but relying on them

This I can almost agree with. I would put it this way: they provide a form
of assurance, but they should not be the only thing we rely on for
assurance.

Cheers

Kenny

[0] H. Krawczyk, K.G. Paterson and H. Wee. On the Security of the TLS
Protocol: A Systematic Analysis. In R. Canetti, J.A. Garay (eds.), CRYPTO
2013 (1), Lecture Notes in Computer Science Vol. 8042, pp. 429-448,
Springer, 2013

[1] M. Bellare, A. Desai, E. Jokipii, P. Rogaway. A Concrete Security
Treatment of Symmetric Encryption. FOCS 1997: 394-403

[2] P. Rogaway. Problems with proposed IP cryptography. Unpublished
manuscript, 1995. 
http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.t
xt

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Mar 2015 18:17:46 +0200

> above, one just needs to be wary of over-interpreting what they say.

Well, not useless, but...

There are different kinds of problems arising for over-interpreting
security proofs:

Take some protocol X that is designed to use TLS feature Y for purpose
Z (e.g. SPDY used TLS-Extractor for channel binding).

This can be outright broken (like the example is in TLS 1.2 without
extensions).

This calls for documenting limiations of various TLS features. And
preferably not provoding "attractive nuisances". But that doesn't
mean the features provoded won't be used in strange ways.

More nasty case is if there is a security proof that some strengthening
A is unnecressary given assumptions B (which seems quite broadly applicable).
Then TLS removes A as "unnecressary". Except that using Y for Z breaks B
and relies on A, so now X is insecure. This is obviously highly attractive
for crypto sabotage projects.

E.g. suppose TLS had renego-fix-like fix for resumption. Now remove
session-hash because it is unnecressary given proper certificate
authentication. Except now TLS-Extractor for channel binding is broken.

This calls for being conservative with strengthening.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 27 Mar 2015 17:44:30 -0400

> model also allows us to pull in PSK modes under the same basic

I was not at the interim, but I was at the TLS session at IETF 92 in Dallas.

I was watching your presentation pretty carefully, and I do not recall a slide on support for PSK.  Can you point me to a description of "PSK modes under the same basic structure"?

Russ

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 27 Mar 2015 19:33:19 -0400

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Mar 2015 18:49:33 -0500

On Fri, Mar 27, 2015 at 4:44 PM, Russ Housley <[email-masked]> wrote:

> I was watching your presentation pretty carefully, and I do not recall a
> slide on support for PSK.  Can you point me to a description of "PSK modes
> under the same basic structure"?
>

The document I pointed to upthread contains a description of the key
schedule. I still have to write up the PSK negotiation syntax.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 27 Mar 2015 19:51:54 -0400

The theme of simplification applies to your concerns below too.
The simpler the protocol the closer it stays to its underlying
cryptographic core hence the closer it stays to the cryptographic semantics.
Actually, the issue of simplifying semantics is of utmost importance.

For example, the hierarchical key derivation scheme in TLS 1.3/OPTLS bind
terminal keys (those used for data protection either inside the handshake
or output for record protection) to a unique context encompassing a label
defining the key's functionality and information that ties the key to
particular handshake session (including nonces, negotiated parameters,
identities, etc.). That defines the semantics and provenance of keys which
should be the only thing that consumers of the TLS handshake need to know
about these keys.

One thing to double check when specifying the handshake protocol is that
context and intended semantics match indeed.
(I wonder, for example, if we should label keys derived with PFS from those
derived without PFS.)

Hugo

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Mar 2015 11:55:22 +0200

> by suicide terrorists?) and you can ensure without doubt that no model will

At one level one can consider mathematical idealities. But because real
world affects the assumptions (e.g. that TLS-Extractor outputs have to be
suitable for channel binding), full analysis becomes an impossiblity
(there are probably much nastier real-world assumptions in proving the
security of real-world protocols using TLS).

Also, sometimes even at this level, the answer to "how to protect against
X?" is "you can't". Like TLS (and QUIC) designers realized with replay
resistant 0-RTT.

Then there is real-world implementation. Can't even be reliably modelled.
However, there are many kinds of constructs that are asking for trouble
here. An example might be to first MAC the ciphertext, then pad it with
deterministic rule and finally encrypt the whole thing (TLS block ciphers
anyone?). This is the construct that gave rise to LUCKY 13 and POODLE TLS.

> proofs into real-world attacks, but the world eventually catches up and

Sure, if you have "negative" security result, and it appears it could
apply with primitives used in real world, that is something worth fixing.

My post was about cauntion about "positive" security results.

(Then there is "elusive" result, where one can't prove something either
secure or insecure).

> or unnecessarily complex schemes that are likely to fail in many other ways.

I don't think the simplest protocol is optimal. This is because such protcol
likely will have security arising from subtle intreactions, which causes
several undesirable things:
- It is likely hard to analyze (doesn't modularze well).
- It likely can't handle loosening assumptions well.
- Implementation errors tend to have bad consequences.

OTOH, too complex protocol is also very undesirable:
- It is hard to to analyze due to number of things that can go wrong.
- Implementation errors tend to be inevitable.

I think the optimum is at simple side but not at the simplest, having
stregthening at carefully chosen places.
- Easy to analyze (modular structure).
- Minimize chances it breaks horribly on loosening assumptions.
- Minimize chances of implementation error.

And as for implemenation, it should be designed in a way that there are
very few or none tempting shortcuts that compromise security. That includes
minimizing number of checks performed, since each that is needed for
security is a potential vulernability waiting to happen.

If you have strict set of assumptions, correct implementations and can
handle hard proving work, you don't need any security margins here.
Unfortunately, you don't have that, so you need security margin.

And then the question becomes, in what places one puts that security
margin, so it defends against wrong assumptions and implementation errors
and simplifies the analysis the best.

> designers will do as well when coming to evolve the protocol into new

It is also very useful for security analysis to modularize, giving
useful results about various parts. Such tends to be very helpful in
generalizing security analysis when it turns out you need looser assumptions.

And, well, the "simplificiations" for implementation I had in mind are
more about encouraging implementations to do the right thing by removing
tempting "shortcuts" like handshake message type info (Java got screwed
over hard by that "shortcut").

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Mar 2015 12:06:46 +0200

> context and intended semantics match indeed.

I consider it important to:

1) Ensure that there are point where entiere context is captured.

E.g. Handshake master secret not being in every key derivation chain
or not including transcript so far makes security analysis quite a bit
harder.

This is from attackers being able to penetrate deeper into structure
in less well defined ways.

See the session_hash I-D for example of things potentially going
wrong due lack of such point ("attacks [...] are not yet known").

To be fair to session_hash, TLS 1.2 structure is the problem. But
TLS 1.3 has very natural point of doing so: The place where handshake
goes encrypted and associated handshake MS.

2) Capture entiere relevant context for anything potentially used for
   authentication.

TLS-Extractor MS needs to incorporate EncryptedExtensions in case
there is some extension affecting TLS-Extractor.

3) Mix in input keys at the earliest available stage.

The PSK and static-DH inputs are not the same!

4) Keep separate keys separate

Using application MS as exporter MS seems like a bad idea.

-Ilari