Subject: Re: [TLS] Simplifying the proof

From: Markulf Kohlweiss <[email-masked]>
Date: Tue, 2 Sep 2014 15:03:38 +0000

Dear Watson, Nigel,

I would like to reply to your email on simplifying the proof of TLS,
primarily to keep this important discussion alive and to invite
everyone interested in cryptographic definitions and modelling to
participate.

There have been many efforts on verifying TLS, some computer checked
but in the symbolic cryptographic model, others hand-written and
brain-checked in the computational cryptographic model.

miTLS is our latest effort to be faithful to the TLS protocol, both
with respect to the low-level cryptography, unless abstracted by
cryptographic assumptions, as well as with respect to the protocol
logic. (http://www.mitls.org, http://eprint.iacr.org/2014/182)

You are right, extending the miTLS proof to TLS 1.3 is hard work. We
believe that it would be worthwhile. One goal of using a high-level
functional programming language to implement miTLS was to make it both
accessible for human as well as machine reasoning. In addition it's
meant to be a test platform for implementing new extensions and even
attacks.

Working out which changes in TLS 1.3 would simplify a security
analysis is an important and timely question---at the minimum we
should aim at not making it harder.

At the same time there is no panacea or silver bullet. The "encrypted
finished message" or "key confirmation" issue is more of a distraction
or red herring than a show stopper for verification and provable
security. It means that a key-exchange protocol secure under a Bellare
& Rogaway style definitions may not necessarily result in a secure
Handshake protocol when used in TLS. But there are many other reasons
why this is not the case, such as key reuse for encryption and
signing, ciphersuite negotiation, resumption, backward compatibility
through support of older protocol versions that make use of the same
long-term keys...

We completely agree that it is desirable to "defining security
properties we want new features to have" in advance "instead of going
back from a design to determine the security it actually provides" (if
any). Protocol design and protocol analysis should go hand-in-hand.

At the danger of preaching to the converted, the ideal methodology for
designing a protocol corresponds to that of building a bridge, the
requirements should come first, then one should get an understanding
of the building blocks one wants to use--and their properties-- and
how to put them together to get the necessary structural properties.

A few constructive and less philosophical ideas:

* While developing miTLS, we felt that the biggest obstacle to
  verifying TLS was the lack of an API which formalizes how
  applications should use TLS.

* To remove distraction and be closer to standard models like Bellare
  & Rogaway, we would prefer unencrypted finished messages. In
  practice this means that the finished message should be sent before
  the ChangeCipherSuite message.

* A lot of (tedious) work in miTLS went into proving that message
  formats are disjoint to achieve cross-protocol security, e.g. that
  ServerKeyExchange parameters for one key exchange method cannot be
  confused with ServerKeyExchange parameters for another ciphersuite.
  See http://www.cosic.esat.kuleuven.be/publications/thesis-208.pdf
  for a discussion of these attacks. Changing the message format would
  prevent such attacks once and for all.

Ultimately if our verification methodology is shown to work and once
we have sufficient confidence that our model captures all necessary
requirements we can remove redundant security components in the
protocol that are not necessary for security, but that were put there
just in case. This makes both the security analysis and the protocol
itself more efficient. In future work on miTLS we want to focus
particularly on system engineering and performance aspects.

To conclude and falling back into the philosophical again, protocol
analysis---be it of the cryptographic or the formal methods
variant---is not mean to be formalism for the sake of formalism, but
something in which everyone building secure systems participates.

Domain knowledge is just as important (arguably more important) than
cryptographic reductions or logical specification of functions to help
tools along, most of which in the real world are tedious but
mathematically simple. The biggest danger is that, in order to avoid this
tedious, often boring work, researchers focus on his/her own part of
the puzzle--i.e. stays on separate islands.

Our hope is that, with miTLS already supporting SSL 3.0 - TLS 1.2,
a lot of existing code and annotations can be reused to verify TLS 1.3.

Let's continue building bridges,

Markulf

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 05 Sep 2014 12:08:45 -0400

Hi Markulf--

Thanks for your post encouraging ongoing collaboration between the 
theoretical and engineering sides of the security community.  This is a 
worthwhile goal.

Can you provide clarification on this point below?

>    the ChangeCipherSuite message.

I understand that the goal here is to be able to improve cryptanalysis 
of the confidentiality guarantees provided to the application data 
stream.  Does this mean that the finished message needs to be 
unencrypted, or does it just mean that the finished message (and/or 
other parts of the handshake) should not be encrypted using the same 
keying material/session as the application data?

That is, would the cryptanalytic side of the community be OK with having 
the handshake messages encrypted as long as they were using keys/session 
material that are distinct from the keys/session material used for the 
application data?

Part of the TLS WG's charter for 1.3 is to encrypt as much of the 
handshake data as possible.  I don't want that goal to interfere with 
theoretical cryptanalysis, but there are serious privacy concerns 
related to the handshake data that is sent in the clear in TLS 1.2 and 
below.  If the cryptanalysis community insists on entirely cleartext 
handshake data, that will be in direct opposition to one of the two 
major prongs of the TLS charter.

(as an aside, it would be nice to get some cryptanalytic review of any 
confidentiality/integrity we attempt to provide for the handshake 
material itself, though i understand this may be a separate question 
from the confidentiality/integrity guarantees we strive for in the 
application data)

Regards,

	--dkg

---

From: Watson Ladd <[email-masked]>
Date: Tue, 9 Sep 2014 18:37:48 -0700

On Fri, Sep 5, 2014 at 9:08 AM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> I understand that the goal here is to be able to improve cryptanalysis of
> the confidentiality guarantees provided to the application data stream.
> Does this mean that the finished message needs to be unencrypted, or does it
> just mean that the finished message (and/or other parts of the handshake)
> should not be encrypted using the same keying material/session as the
> application data?

If TLS is going over an encrypted channel, that doesn't change the
security of TLS. Rather the issue is the use of the master secret to
encrypt a finished message also derived from the master secret, and
then using the same keys to encrypt everything else. The solution is
to do what IKEv2 did: adopt wholesale a correct solution to the
problem.
>
> That is, would the cryptanalytic side of the community be OK with having the
> handshake messages encrypted as long as they were using keys/session

Maybe! It really depends on the details of what is going on. Look at
the history of Kerberos to see how subtle these issues can be.

>
> Part of the TLS WG's charter for 1.3 is to encrypt as much of the handshake
> data as possible.  I don't want that goal to interfere with theoretical
> cryptanalysis, but there are serious privacy concerns related to the
> handshake data that is sent in the clear in TLS 1.2 and below.  If the
> cryptanalysis community insists on entirely cleartext handshake data, that
> will be in direct opposition to one of the two major prongs of the TLS
> charter.
>
> confidentiality/integrity we attempt to provide for the handshake material
> itself, though i understand this may be a separate question from the
> confidentiality/integrity guarantees we strive for in the application data)

Review is not enough: Triple Handshake was missed for how long? Rather
we need design that makes useful proofs possible. Occasionally this
can mean doing things that don't "make sense" or seem "unnecessary"
but let the proof go through.

Sincerely,
Watson Ladd
>
> Regards,
>
>         --dkg
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

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

---

From: Markulf Kohlweiss <[email-masked]>
Date: Wed, 10 Sep 2014 10:55:52 +0000

Hi Daniel,

Thanks a lot for the discussion. 

1) We should be very clear about what should be done by TLS and what by application protocols, and how the two interact. A good example for this are Channel ID and Token Binding. Thus our call for standardizing a TLS API.

2) After a secure enough session has been established, a separate key could be used to protect additional handshake messages. As usual the concern is with the same key being used for different purposes. I don't think the cryptanalysis community would be concerned by separate keys in principle. 

Hiding which application protocols are being negotiated (and which keys they should use) could be one of the legitimate use-cases for this, cf. the discussion around NPN vs ALPN. Though there are probably many others that I am not aware of, and making the handshake look as uniform as possible for outsiders is good for privacy.

3) With the possibility of re-negotiation being abolished and key generation being strengthened, the need for finished messages may decrease. But I would be very careful before abolishing them.

These are great examples for questions for which a formal modelling of the handshake can create new insights. 

Best,

Markulf

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: 05 September 2014 17:09
To: Markulf Kohlweiss; [email-masked]
Subject: cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: [TLS] Simplifying the proof]

Hi Markulf--

Thanks for your post encouraging ongoing collaboration between the theoretical and engineering sides of the security community.  This is a worthwhile goal.

>    the ChangeCipherSuite message.

I understand that the goal here is to be able to improve cryptanalysis of the confidentiality guarantees provided to the application data stream.  Does this mean that the finished message needs to be unencrypted, or does it just mean that the finished message (and/or other parts of the handshake) should not be encrypted using the same keying material/session as the application data?

That is, would the cryptanalytic side of the community be OK with having the handshake messages encrypted as long as they were using keys/session material that are distinct from the keys/session material used for the application data?

Part of the TLS WG's charter for 1.3 is to encrypt as much of the handshake data as possible.  I don't want that goal to interfere with theoretical cryptanalysis, but there are serious privacy concerns related to the handshake data that is sent in the clear in TLS 1.2 and below.  If the cryptanalysis community insists on entirely cleartext handshake data, that will be in direct opposition to one of the two major prongs of the TLS charter.

(as an aside, it would be nice to get some cryptanalytic review of any confidentiality/integrity we attempt to provide for the handshake material itself, though i understand this may be a separate question from the confidentiality/integrity guarantees we strive for in the application data)

Regards,

	--dkg

---

From: Fabrice <[email-masked]>
Date: Wed, 10 Sep 2014 07:19:31 -0700

> On Sep 10, 2014, at 03:55, Markulf Kohlweiss <[email-masked]> wrote:
> 
> Hi Daniel,
> 

Regarding that specific point: Is the IETF an appropriate forum to standardize APIs, and has it successfully done so in other areas?

I'm also curious in what form a standard API would be defined, and how far you would go in standardizing it. 

For example, would you have the API specify how the data flow between the "connection", the TLS implementation and the application, or would you limit this API to interactions between the handshake implementation and the application ?

-- Fabrice

---

From: Markulf Kohlweiss <[email-masked]>
Date: Wed, 10 Sep 2014 16:18:24 +0000

Short answer: I don't know.

Long answer: 
API's are standardized for cryptographic primitives, though maybe not systematically, and what the inputs and outputs of an algorithm are may seem obvious. The most explicit check for this are test vectors. I would be a big fan of formal security definitions for primitives in standards.

There is a recommendation document for the secure use of TLS: https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02 .
A good API would attempt to enforce the UTA guidelines unless the application insists otherwise.

--Markulf

-----Original Message-----
From: Fabrice [mailto:[email-masked]] 
Sent: 10 September 2014 15:20
To: Markulf Kohlweiss
Cc: Daniel Kahn Gillmor; [email-masked]
Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof]

-- Fabrice

---

From: Michael StJohns <[email-masked]>
Date: Wed, 10 Sep 2014 12:47:57 -0400

> I'm also curious in what form a standard API would be defined, and how far you would go in standardizing it.

*IF* we do this, I'd recommend using the model from the original TCP 
documents.  They specified a service interface above and a required 
service interface below without getting into system specific "API"s See 
specifically section 3.8 of RFC793.  Note that it describes BOTH 
interfaces - the one used by applications to talk to TCP, and the 
minimum one needed by TCP to talk to the LLP (in this case IP).

---

From: [email-masked] (Martin Rex)
Date: Thu, 11 Sep 2014 17:18:37 +0200 (CEST)

Watson Ladd wrote:
> then using the same keys to encrypt everything else.

I'm sorry, but to me this discussion/argument look fairly bogus.

The TLS master secret is never used to encrypt anything, and
sending the finished messages in the clear would allow an attacker
to make *EVERY* TLS handshake complete successfully, i.e. seriouly
weaken TLS.

I also don't understand why the fact that TLS finished messages are
encrypted would make any proof harder.  I believe that to be untrue.

Think of the TLS master secret to be the (initial) entropy pool of
something like the Hash_DRBG of HMAC_DRBG from NIST SP 800-90A.

A problem would exit only if the TLS PRF construct would kill the
cryptographic hash properties of the underlying hash -- or if the
Hash_DRBG / HMAC_DRBG from NIST SP800-90A cryptographic random
number generators would have a serious problem by themselves.

For the AES-GCM TLS cipher suites, the encryption and MAC keys are also
derived from the same master secret, and GHASH itself does not have
cryptographic hash properties (i.e. it is invertible).  The entire security
of the AES-GCM is based on the assumption that the final encryption or the
GHASH output saves the day.  So the security of the existing TLS handshake
with the encrypted finished handshake messages will always be stronger
than the security of AES-GCM TLS cipher suites.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Sep 2014 09:16:11 -0700

> to make *EVERY* TLS handshake complete successfully, i.e. seriouly

I don't understand how this claimed attack supposed to work: the
finished messages in each direction are distinct, preventing replay.

> encrypted would make any proof harder.  I believe that to be untrue.

Have you tried to prove TLS secure? It's a very subtle issue related
to the usual definitions. Dealing with it is painful.
> number generators would have a serious problem by themselves.

The problem is close to that caused by key-dependent encryption: you
can have a cipher that is a PRP, but that fails on key-dependent
messages.  Yes, this seems like it shouldn't matter. Intuition is not
a reliable guide to protocol security: did you discover Triple
Handshake?

The reason we want to change features that are hard to deal with isn't
because they are necessarily insecure, but that the protocol may have
other problems which doing the proof may uncover. This is exactly how
Triple Handshake was discovered, and the issues in Kerberos v4, IPsec,
etc. were discovered through similar means.

IPsec was completely revamped, tossing IKEv1 and using a design by
Hugo Krawczyk for IKEv2 that was proven secure. Why aren't we doing
the same?

> than the security of AES-GCM TLS cipher suites.

You're dead wrong, because AES-GCM meets its security definition, and
the existing TLS handshake doesn't.  This should indicate something is
wrong with your argument.

Sincerely,
Watson Ladd

---

From: [email-masked] (Martin Rex)
Date: Thu, 11 Sep 2014 19:07:03 +0200 (CEST)

Watson Ladd wrote:
> messages. 

This doesn't apply to the TLS handshake, though.  As I wrote, this would
similarily break the Hash_DRBG and HMAC_DRBG designs from NIST SP800-90A
if it did.

>
> Yes, this seems like it shouldn't matter. Intuition is not

The triple handshake problem would have been fairly impossible to miss,
if one really cared to look for it.  The problem with the TLS spec is
that information is scattered out all over the place, which makes it
much more difficult to see its real properties.
Such as the problem that the TLS master secret is computed from only
the three inputs "premaster_secret", "ClientHello.random" and
"ServerHello.random" and not cryptographically bound to the handshake
(message hash) or the identities exchanged/established during the
handshake.

The original TLS renegotiation problem was a lack of cryptographic
binding, and it was unnecessary to perform any kind of formal proofs
to see the problem and its consequences.
Collecting the snippets from various places of the TLS spec, writing
it down and looking at it for an hour was perfectly sufficient to 
realize the problem.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Sep 2014 10:26:46 -0700

> similarily break the Hash_DRBG and HMAC_DRBG designs from NIST SP800-90A

The issue is that the obvious proof method doesn't work. Obviously as we
have a proof, this is not fatal to security.

As for the Hash DRBG, details matter.
> (message hash) or the identities exchanged/established during the

Why didn't you find it then? This is another problem which frustrates
analysis which should be fixed.

> it down and looking at it for an hour was perfectly sufficient to

Which you did the first time, but not the second.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Sep 2014 12:28:01 -0500

TLS should be secure with Finished messages sent unencrypted.  That
should be a goal for the design of the Finished message construction.

That said, once that is so I fail to see how encrypting them can
weaken the protocol.  And if the Finished messages are entirely
pseudo-random (e.g., a cryptographic authentication tag) then I fail
to see how encrypting them strengthens the protocol either.

Therefore to me this is neither here nor there.

That said, not encrypting the Finished messages has a small
performance benefit; it's probably worthwhile for that reason.  Count
me as in favor of not encrypting then, with the above
[non-controversial, right?] caveats.

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Sep 2014 10:37:00 -0700

> to see how encrypting them strengthens the protocol either.

It's not about the security of TLS, but the relevance of the usual key
agreement definition to TLS. I used to think that it didn't matter. Then
someone asked me to prove that it didn't matter.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Sep 2014 11:04:42 -0700

> [non-controversial, right?] caveats.

Given that we are encrypting the rest of the handshake in TLS 1.3, exempting
just Finished seems problematic. In Toronto we discussed deriving different
keys for handshake encryption and application data encryption. Would that
also resolve the issue here?

-Ekr

---

From: Douglas Stebila <[email-masked]>
Date: Thu, 11 Sep 2014 20:33:02 +0000

On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss <[email-masked]> wrote:
> * To remove distraction and be closer to standard models like Bellare & Rogaway, we would prefer unencrypted finished messages. In practice this means that the finished message should be sent before the ChangeCipherSuite message.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <[email-masked]> wrote:
> Given that we are encrypting the rest of the handshake in TLS 1.3, exempting just Finished seems problematic.

I see no strong reason, cryptographically, to prefer unencrypted or encrypted Finished messages either way.  It's true that unencrypted Finished messages make it easier to prove a secure channel property by using the traditional cryptographic approach of concatenating key exchange and authenticated encryption.  But that is just one way to build a secure channel, and we now know how to prove TLS is a secure channel even without the clear separation between the handshake and the channel encryption.  So with our current state of the art proof techniques, encrypted Finished messages are now a relatively minor inconvenience in proofs.

Normal key exchange security definitions rely on indistinguishability of the session key: once the key exchange is complete, if you give the adversary either the real session key or a random one, can she tell which she was given?  The encrypted Finished messages make it tricky because the Finished message has a recognizable format: the first byte of the Finished message is the TLS content type, for example.  Decryption using a random key would with high probability yield something not in that format.  Exempting the Finished message but encrypting other parts of the handshake with the session key would not fix the problem, as the other handshake messages would still have a recognizable format.

To me, there is far more benefit gained from encrypting handshake messages compared to the minor inconvenience to cryptographers trying to prove security.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <[email-masked]> wrote:
> In Toronto we discussed deriving different keys for handshake encryption and application data encryption. Would that also resolve the issue here?

Unclear to me.  My gut tells me the proof would probably go through either way, but I'd have to check.  It's also unclear to me whether this offers any benefit -- intuitively it feels like there's a nice "functional separation" that comes from encrypting application data with a separate key from handshake data, but cryptographically there's probably not much difference since they both are derived from the same master secret key.  

If I were to make two changes in TLS 1.3 for the purposes of improving cryptographic proofs, they would be
1) to include the hash of the transcript in the derivation of the master secret as has already been proposed (so that something can be proved about session resumption), and
2) to fix the signature in signed-DH by signing the full transcript (fixing the Mavrogiannopoulos cross-ciphersuite attack) and moving the server signature to a separate CertificateVerify message just before the [ChangeCipherSpec] (getting rid of the pesky Oracle-DH assumption in the proofs).

Douglas

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Sep 2014 13:36:56 -0700

On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebila <[email-masked]> wrote:

> > * To remove distraction and be closer to standard models like Bellare &
> Rogaway, we would prefer unencrypted finished messages. In practice this
> means that the finished message should be sent before the ChangeCipherSuite
> message.
>
> > Given that we are encrypting the rest of the handshake in TLS 1.3,
> exempting just Finished seems problematic.
>
> I see no strong reason, cryptographically, to prefer unencrypted or
> encrypted Finished messages either way.  It's true that unencrypted
> Finished messages make it easier to prove a secure channel property by
> using the traditional cryptographic approach of concatenating key exchange
> and authenticated encryption.  But that is just one way to build a secure
> channel, and we now know how to prove TLS is a secure channel even without
> the clear separation between the handshake and the channel encryption.  So
> with our current state of the art proof techniques, encrypted Finished
> messages are now a relatively minor inconvenience in proofs.
>
> Normal key exchange security definitions rely on indistinguishability of
> the session key: once the key exchange is complete, if you give the
> adversary either the real session key or a random one, can she tell which
> she was given?  The encrypted Finished messages make it tricky because the
> Finished message has a recognizable format: the first byte of the Finished
> message is the TLS content type, for example.  Decryption using a random
> key would with high probability yield something not in that format.
> Exempting the Finished message but encrypting other parts of the handshake
> with the session key would not fix the problem, as the other handshake
> messages would still have a recognizable format.
>
> To me, there is far more benefit gained from encrypting handshake messages
> compared to the minor inconvenience to cryptographers trying to prove
> security.
>
> > In Toronto we discussed deriving different keys for handshake encryption
> and application data encryption. Would that also resolve the issue here?
>
> Unclear to me.  My gut tells me the proof would probably go through either
> way, but I'd have to check.  It's also unclear to me whether this offers
> any benefit -- intuitively it feels like there's a nice "functional
> separation" that comes from encrypting application data with a separate key
> from handshake data, but cryptographically there's probably not much
> difference since they both are derived from the same master secret key.
>
> 1) to include the hash of the transcript in the derivation of the master
> secret as has already been proposed (so that something can be proved about
> session resumption), and
>

I believe (and the WG chairs can correct me) that this change has consensus
and there is a Github issue to make the change.

2) to fix the signature in signed-DH by signing the full transcript (fixing
> the Mavrogiannopoulos cross-ciphersuite attack) and moving the server
> signature to a separate CertificateVerify message just before the
> [ChangeCipherSpec] (getting rid of the pesky Oracle-DH assumption in the
> proofs).

A version of this change is already there. However CertificateVerify now
comes *after* CCS because otherwise we can't encrypt the certificate.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 11 Sep 2014 23:11:44 -0400

Sorry for the long post.

Beyond the specifics of the changes for TLS 1.3, I want to address the
question of to-encrypt-or-not encrypt the Finish message. The question is
not just a philosophical, stylistic or indicating how lazy cryptographers
are when coming to analyze a protocol (it sounds like that from some of the
"inconvenience" comments), but it rather touches on fundamental approaches
to designing secure protocols (and systems).

There is no problem encrypting the Finish msgs with a key derived from the
master secret for that purpose AS LONG AS the key for encrypting
application data is also derived from the master secret ms in a
"computationally independent" way (i.e., in both cases you use ms as a PRF
key but the inputs for deriving each type of key are different). What if
Finish is encrypted under the same key as used for application data?
Depending on how you do it, it can be fine or it can break security. What
is surely broken is *modularity*.

In a modular design you design a key exchange protocol (KEP) responsible
for creating, sharing, and deriving keys for the endpoints to the
communication. Then these keys are used to encrypt/authenticate application
data. If the KEP is (generically) secure then you can design the
application layer security under the abstraction than the parties start
with a fresh secure shared key. This separation helps design, analysis,
protocol maintenance and, very importantly, robustness. That is, better
resistance to future changes in the protocol. When both KEP and application
protocol are dependent in the details of each other, it is easy to break
security and TLS has a great track record doing that.

Let me exemplify how encrypting the Finish message breaks the generic
security of the protocol, hence also its modularity.
By generic security I mean that you can use the key output by the KEP with
any security application without regards to what that application does. All
you need to know is that the application is secure if the parties use a
secret pre-shared key.

So consider the following application: Alice and Bob exchange a key which
is then used for triggering some action at Bob (attack, buy, sell, go to
sleep, etc.). The trigger for Bob is defined as getting a message that is
encrypted and authenticated with the key shared with Alice, regardless of
the plaintext in that message. If such a msg is received by Bob, it takes
the action. This is perfectly secure since only Alice can send such a
message and which message she sends is immaterial as long as it is
authenticated by the shared key. If the KEP that was used to share the key
was generically secure, then the composition of KEP and this application is
secure. In turn, if it was a protocol utilizing the application's key to
also encrypt one of the KEP messages (e.g. TLS's Finish) then the protocol
is fully insecure. Indeed, the attacker can replay the encrypted Finish
(which is also authenticated) and trigger Bob's action even if Alice did
not intend to do so.

I can hear some voices: that's nice but this is not TLS. Correct. But also
correct is that generic security is lost. There is necessarily a dependency
between the KEP and the specifics of the application protocol. You change
one, you need to re-assess security and maybe change the other. You want to
add some functionality to the shared key, you need to re-assess security.
You want to generate further keys, you need to check for dependencies. And
guess what, all the works analyzing TLS do all these things one way or the
other. Sometimes taking care of the dependencies; sometimes modeling things
in a way that breaks dependent stuff into separate pieces and showing that
these pieces interact nicely; sometimes just ignoring some details too
complex for correct modeling, etc. It is all the product of non-generic
security, of broken modularity. It is a design that invites shortcuts,
patches, confusion, failures. What is the upside?

So beyond the encrypt-or-not-encrypt dilemma what this shows is that one
needs a clean modular cryptographic design and an equally clean proof.

Design from scratch, not by patch. Ouch.

Hugo

On Thu, Sep 11, 2014 at 4:36 PM, Eric Rescorla <[email-masked]> wrote:

>> To me, there is far more benefit gained from encrypting handshake
>> messages compared to the minor inconvenience to cryptographers trying to
>> prove security.
>>
>> > In Toronto we discussed deriving different keys for handshake
>> encryption and application data encryption. Would that also resolve the
>> issue here?
>>
>> Unclear to me.  My gut tells me the proof would probably go through
>> either way, but I'd have to check.  It's also unclear to me whether this
>> offers any benefit -- intuitively it feels like there's a nice "functional
> 2) to fix the signature in signed-DH by signing the full transcript
>> (fixing the Mavrogiannopoulos cross-ciphersuite attack) and moving the
>> server signature to a separate CertificateVerify message just before the

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Sep 2014 21:00:51 -0700

> is surely broken is *modularity*.

Hugo, thanks for your message....

FWIW, I don't see an inherent with problem with changing TLS to use
separate key for encrypting the handshake messages from the
application layer messages.

-Ekr

---

From: Alfredo Pironti <[email-masked]>
Date: Fri, 12 Sep 2014 08:17:02 +0200

Using different encryption keys for application data and handshake messages
gives the attacker a distinguishability argument, especially if we go for
the content type encryption.

The TLS record layer is a protocol that multiplexes several streams
(handsake, alerts, app data...). In isolation, it does it correctly (when a
proper AEAD scheme is used). This is a valuable feature of the protocol
that gives us a chance to get more privacy, and we should not give it up
using different keys for each stream.

What has historically been wrong in TLS is that it uses the record layer
keys too early, before the Finished messages confirm them. So, it's more
important to define different keys for messages sent before (and crucially
including) the Finished message, and different, confirmed keys for all the
record layer encryption than comes afterward.

In TLS <= 1.2 this is easy to do: move the finish messages before CCS
(hence the first set of keys is the NULL key for the first handshake).

>From my understanding of the current TLS 1.3 draft: the server and client
key exchange messages are used to derive ephemeral keys to protect the
first handshake; hence one should derive and use different record layer
encryption keys after the finished messages are exchanged (and yes, such
keys should depend on the full transcript of the handshake)

Alfredo

On Fri, Sep 12, 2014 at 6:00 AM, Eric Rescorla <[email-masked]> wrote:

>> There is no problem encrypting the Finish msgs with a key derived from
>> the master secret for that purpose AS LONG AS the key for encrypting

---

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Sep 2014 08:25:55 -0700

> Sorry for the long post.

The S/N ratio more than justifies the consumption of bandwidth.
> patches, confusion, failures. What is the upside?

Let me note that some IETF protocols do exactly this: RFC 5764 comes
to mind. I don't think the security analysis was redone for it.
Furthermore, there are a bunch of interactions with GSSAPI that are
non-obvious. Channel binding and connection-specific cookies also come
to mind as features that require more thought than was put into them
the first time. Furthermore, it's not just TLS 1.3 we need to get
right. It's TLS 1.3 plus this little-known extension that does X, plus
this one that does Y, minus this other extension doing Z.

There is no reason we cannot meet the privacy and round-trip goals
while maintaining modularity. Modularity will also make things like
post-quantum enhancements much easier than they would be today: the
current proofs rely on nonstandard assumptions, which may or may not
be true for primitives meeting standard assumptions, so any change
requires some nasty analysis.

> Design from scratch, not by patch. Ouch.

Or just go take one of the many, many, authenticated key agreement
protocols from the literature and use it.
Sincerely,
Watson Ladd
>>> encrypted Finished messages either way.  It's true that unencrypted Finished
>>> messages make it easier to prove a secure channel property by using the
>>> traditional cryptographic approach of concatenating key exchange and
>>> authenticated encryption.  But that is just one way to build a secure
>>> message is the TLS content type, for example.  Decryption using a random key
>>> would with high probability yield something not in that format.  Exempting
>>> the Finished message but encrypting other parts of the handshake with the
>>> session key would not fix the problem, as the other handshake messages would
>>> still have a recognizable format.
>>>

---

From: [email-masked] (Martin Rex)
Date: Fri, 12 Sep 2014 18:01:01 +0200 (CEST)

Watson Ladd wrote:
> "Martin Rex" <[email-masked]> wrote:
>>>
> Why didn't you find it then?

Because I never looked for such problems in the first place!

I was _not_ doing any kind of review of the TLS protocol (of which I knew
fairly little back then) when I noticed the MITM susceptibility of the
TLS renegotiation handshake.  It was a simply by-product of the discussion
of TLS channel bindings on the TLS mailing list, after I had collected
and wrote down that there was exactly no cryptographic binding between
the Connection state (aka traffic protection keys) of the existing
TLS session and the Connection state of the newly renegotiated session.

After writing that down and looking at what I wrote, the issue and
its consequences jumped right at me.

At that point, I hadn't looked at the details of the computation of the
TLS master secret, and wasn't aware of a similar lack of binding
of the master secret to the handshake (message hash) and the
resulting consequences of that shortcoming.

In the TLS implementation for which I had maintenance responsibility,
I hardwired renegotiation attemps to a fatal handshake failure on the
server side back then (I had never exposed that possibility to applications,
because I had never felt comfortable with this significantly underspecified
TLS protocol feature, so I could easily remove it without paperwork.) 

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Fri, 12 Sep 2014 12:18:13 -0400

> resulting consequences of that shortcoming.

I'm probably missing something in the above, but I would say the master 
secret was bound to the handshake:  the handshake is hashed, and that 
hash is signed by the master secret.  If you mean that the traffic keys 
aren't bound to the handshake, I think that would be a more correct 
statement.  E.g.

 1. the master secret is used to sign/verify the handshake, and to
    create the traffic keys;
 2. the handshake hash used to verify the handshake (finished message)
    includes data from the authentication process, but that data is not
    brought forward to the derivation of the traffic keys (until
    draft-bhargavan-tls-session-hash changes the process if adopted)

Probably a nit, but important to get it right if its to be fixed 
efficiently and correctly.

Mike

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 14:22:20 -0500

On Thu, Sep 11, 2014 at 11:11:44PM -0400, Hugo Krawczyk wrote:
>             [...]. Indeed, the attacker can replay the encrypted
> Finish (which is also authenticated) and trigger Bob's action even if
> Alice did not intend to do so.

The key word here is "replay".  Both TLS and DTLS are intended to detect
replays and must continue to for other reasons anyways.  Don't
misunderstand me though: I'm all for key hygiene and modularity.  I
agree with you; I'm only picking... the nit you predicted we'd pick :)

More seriously, I have a concrete example of how encrypting the Finished
messages has complicated security analysis in the past.

Back when we put together RFC5929 (channel binding to TLS) some
reviewers argued that using unencrypted Finished messages was a bad idea
because doing so might leak important information.  It didn't take too
much effort to put that concern to rest, but it was surprising that
there was no need to encrypt them Finished messages and yet, they were.

Encrypting the Finished messages may well have been a psychological
crutch: a device to avoid having to prove that the Finished messages
as-is were good enough.  We should not have such crutches.

> Design from scratch, not by patch. Ouch.

I agree with this sentiment.  It's not always practical though.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 14:35:30 -0500

> non-obvious. Channel binding and connection-specific cookies also come

I'm not sure if you have any concerns re: GSS beyond channel bindings.
Please clarify.

GSS is really just an API.  You might have issues with the mechanisms,
such as Kerberos and ABFAB.  Or you might think the API itself has
issues such that it isn't possible to produce a GSS mechanism that we
can analyze easily or at all, or that can be secure.  Either way I would
like to hear your concerns.

> this one that does Y, minus this other extension doing Z.

RFC5929 was and is fine as-is.  What wasn't fine was the lack of binding
in TLS session resumption and renegotiation.

It *is* true that we could have noticed the problems with TLS session
resumption and renegotiation _then_, but we failed to analyze TLS
session resumption and renegotiation.  We assumed modularity.  TLS
failed to provide the semantics we thought it did.

This is a great example of why modularity helps where we really do have it.

If you have _other_ concerns about CB, we need to hear those too!
Whether in the specific details of RFC5929 (TLS CB) or in general with
RFC5056, your concerns will be of great interest.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 14:58:50 -0500

> the content type encryption.

The record type goes in the clear in TLS 1.2 and less anyways.
Encrypted handshake messages are *already* distinguishable from
application data.  That is something we absolutely should change in 1.3.

In any case, encrypted messages have to be of a form like:
<length> <ciphertext> <authentication tag> or <length> <AEAD ciphertext>.

The cipher and authentication had better be indistinguishable when using
the same key but different plaintext, or just plain different keys.  If
it is then we have a problem.

There have been proposals for encrypting parts of the handshake.  For
such proposals we'll need to derive a different key for those encrypted
handshake records.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 15:03:51 -0500

> the history of Kerberos to see how subtle these issues can be.

Certainly Hugo K. indicated that he'd be fine with that.

Can you expand on the Kerberos issues?

Kerberos has had (and in some cases still has) issues with: too much
plaintext, the Ticket in KDC responses not being sent within nor bound
into the encrypted payload of the KDC response, poor ciphers (1DES with
CRC... RC4...)...  But Kerberos at least does nowadays have good key
hygiene, deriving sub-keys for different purposes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 15:06:09 -0500

> encrypted would make any proof harder.  I believe that to be untrue.

Hugo K.'s rationale is that you then need to have replay protection.  We
need replay protection anyways, but if you're only analyzing the
handshake then it helps to not have to include subsequent replay
protection in the analysis.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Sep 2014 02:19:43 +0200 (CEST)

> security of the protocol, hence also its modularity.

While I think that your modularity argument has a little merit,
I do not buy the "generic security" idea at all, which I liken to
what Jeff Schiller used to call "magic security pixie dust",
because it is what has caused by far the most security goofs
over the past decades.

Apps can't wait to get their hands on "generic security" stuff,
a number of folks seem to assume that TLS was/is/or should be the
IETFs magic security pixie dust.  But I do not believe you could
design such a thing (at least not one that is practical to the
real world IETF audience), even when starting from scratch.

IPsec originally went overboard with modularization and offered
integrity and confidentiality as seperate and indendent services.
Maybe you should re-check how that ended.

There is no such thing as generic security, and being greedy on
security does not pay off.

Deploying the fully backwards compatible 1/(n-1) TLS record splitting
countermeasure for the paranoids that misunderstand the BEAST as a
practical attack/vulnerability, would not have been possible if
TLSv1.0 had not been encrypting the MAC. 

I've seen an implementation bug vaguely similar to OpenSSL CVE-2014-0224
(premature ChangeCipherSpec), but where the fact that the TLS finished
messages are encrypted prevented that bug from becoming exploitable
(because traffic protection keys computed from an empty premaster secret
were only used on one of the communication directions, they keys for
the other direction were properly computed.

I consider using seperate/independent keys for handshake and app data
a bad idea, because it will significatly increase protocol and implementation
complexity _without_ adding value.  And you should keep in mind
just how many serious and silly bugs already affect implementations
of the current TLS protocol versions in the real world.

One of the downsides of spartanic theoretic cryptography is that it
is often hard to support and brittle like hell.  We need less
of the cryptoglycerin stuff, not more of it, and stuff that is easy
to implement, test and support, rather than complex stuff where
the result of (interop) failures is an opaque "failed".

(did you ever have to help app folks troubleshooting app bugs or weird network
 data corruptions that make xmldsig signature verifications fail?
 You might start to appreciate the properties of RSA PKCS#1 v1.5 signatures
 over other signature schemes). 

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Sep 2014 18:35:25 -0700

> because it is what has caused by far the most security goofs

TLS and SSH are the only IETF standards that provide anything close to
a secure channel for applications to use.

We've known what a secure key exchange should be since 1992. We've
known how to compose MACs+encryption correctly since 1995. In 2014, we
still can't put the two together.

"Generic security" is a technical term: it means that you have a set
of definitions for each component to meet, such that the composition
is secure. The point Hugo is making is that the TLS does not provide a
key: rather it provides a secure channel, and any application (like
RFC 5764) which doesn't use the channel makes life annoying for anyone
interested in analyzing the result. Furthermore, making extensions to
TLS becomes something of a black art: as Douglas Stebila noted (on a
different but related point) the assumptions needed are highly
nonstandard, and could be weakened with very minor changes.

> real world IETF audience), even when starting from scratch.

Hugo Krawczyk is the designer of IKEv2, which does meet the generic
security definition for an authenticated key exchange, and certainly
is deployed. The authors of RFC5764 went out and used TLS as a key
agreement protocol. It's clear that secure channels, which we
/haven't/ actually provided, are of interest. Furthermore, some
applications want their own transport protocols, and want a key
agreement for use with them.

> TLSv1.0 had not been encrypting the MAC.

Wrong: see my reply to Adam Langley on this mailing list about this
point: 1/n-1 record splitting is sufficient even if there is no MAC in
the record layer. Of course, I tend to think an attack that steals
credit card information, demoed live and onstage, is a problem, but
you and I can just disagree on this point.

> of the current TLS protocol versions in the real world.

How much complexity is another CCS message and PRF invocation?

> the result of (interop) failures is an opaque "failed".

The current TLS spec is not easy to implement, nor test, nor support.
I don't see how a hypothetical simplification with stronger security
guarantees would necessarily be worse from this perspective.

>  over other signature schemes).

How does v1.5 vs PSS affect debugging?.

Sincerely,
Watson Ladd

---

From: Markulf Kohlweiss <[email-masked]>
Date: Sat, 13 Sep 2014 10:36:55 +0000

This is in reply to the whole encrypted finished message & modularity discussion.

As I said before, I am all for removing distraction and focusing on the clear analysis of an as simple as possible (but not simpler) design.

Right now I fear that we are getting distracted again. Let me nevertheless try to advertise (once more, see footnote) a nice feature of our modular analysis of TLS in miTLS: We do not have to model Record "replay" detection as part of our Handshake analysis. In our Handshake model Finished messages are not encrypted. Thus they cannot be "replayed" as application data.

We have unencrypted finished messages, that get encrypted only by the Record protocol which anyway multiplexes several streams (Handshake, Alerts, AppData...) as already pointed out by Alfredo Pironti.

So in a sense we have "generic" composition between the Handshake and the Record. But its "generic" composition for a key exchange model that releases keys before they are confirmed good with a symmetric key model that can request and deliver Finished messages. The latter can use keys, e.g., to encrypt the finished message, but at its own danger (i.e., it has to implement its own replay detection), and most Handshake security guarantees hold only after successful Finished message verification.

In my opinion the issue is 

- *not* one of "replay" and keys becoming distinguishable from random by encrypting a Handshake message, as it is often construed, and the current discussion is a good example, 

- *but* one of using keys before they are confirmed as good by verifying the Finished. The latter is not the greatest idea for application data (pace FalseStart), it's also not great for Handshake and Alert messages. Consequently restricted key exchange models like Bellare & Rogaway that do not allow for such an early key release may be preferable.

I would prefer to shift the discussion towards ensuring that keys are good as early as possible. The extended master secret is a step in the right direction. Is there a plan for extended record keys?

> I agree with this sentiment.  It's not always practical though.

If we are modular, or if (de-)construct a legacy protocol into plausible modules, we can at least redesign each module at a time from scratch, even if we can never pull the whole ship into the dry dock to rebuild it completely from scratch. 

Markulf 

PS Footnote: Maybe it's enlightening, though many found it confusing in the past.

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: 12 September 2014 20:22
To: Hugo Krawczyk
Cc: Eric Rescorla; Markulf Kohlweiss; [email-masked]
Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof]

> Alice did not intend to do so.

The key word here is "replay".  Both TLS and DTLS are intended to detect replays and must continue to for other reasons anyways.  Don't misunderstand me though: I'm all for key hygiene and modularity.  I agree with you; I'm only picking... the nit you predicted we'd pick :)

More seriously, I have a concrete example of how encrypting the Finished messages has complicated security analysis in the past.

Back when we put together RFC5929 (channel binding to TLS) some reviewers argued that using unencrypted Finished messages was a bad idea because doing so might leak important information.  It didn't take too much effort to put that concern to rest, but it was surprising that there was no need to encrypt them Finished messages and yet, they were.

Encrypting the Finished messages may well have been a psychological
crutch: a device to avoid having to prove that the Finished messages as-is were good enough.  We should not have such crutches.

Nico
--

---

From: Markulf Kohlweiss <[email-masked]>
Date: Sat, 13 Sep 2014 12:29:38 +0000

Just using different keys for the Handshake and the Record, isn't quite that simple, especially if one wants to interleave Handshake and Record messages. In current TLS terminology one should probably say for Handshake and AppData (what about Alert?). Record messages wrap the messages for all three of these protocols.

The property that a ciphertext does not reveal which key it was generated with, or that two ciphertexts of the same key cannot be linked is formalized as key privacy. It holds if ciphertexts are indistinguishable from random bytes, but is not implied by plaintext indistinguishability.

In general this has a performance impact as in order to determine the key with which to decrypt one has to try all possible keys. Specialized schemes can make this more efficient, or one could use a fragment header that is always encrypted with yet another key. I haven't thought about the details, and maybe there are already good proposals for this, but yes, there is some complexity. 

A different question is the extent to which interleaving Handshake and Record messages is necessary in TLS 1.3? I expect that there are good use cases for this. One question is whether these use cases can be separated in a modular way from the core key exchange functionality, e.g. Token Binding, but this may be hard for certain purposes, like protecting the confidentiality of certificates.

Markulf 

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: 12 September 2014 20:59
To: Alfredo Pironti
Cc: Eric Rescorla; Markulf Kohlweiss; [email-masked]
Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof]

On Fri, Sep 12, 2014 at 08:17:02AM +0200, Alfredo Pironti wrote:
> Using different encryption keys for application data and handshake 
> messages gives the attacker a distinguishability argument, especially 
> if we go for the content type encryption.

The record type goes in the clear in TLS 1.2 and less anyways.
Encrypted handshake messages are *already* distinguishable from application data.  That is something we absolutely should change in 1.3.

The cipher and authentication had better be indistinguishable when using the same key but different plaintext, or just plain different keys.  If it is then we have a problem.

There have been proposals for encrypting parts of the handshake.  For such proposals we'll need to derive a different key for those encrypted handshake records.

Nico
--

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 13 Sep 2014 16:46:33 +0200

On 12/09/2014 21:22, Nico Williams wrote:
> replays and must continue to for other reasons anyways.

As a matter of fact, replay detection is optional in DTLS, quoting RFC 6347
section 3.3: "DTLS optionally supports record replay detection".

Manuel.

---

From: Nico Williams <[email-masked]>
Date: Sat, 13 Sep 2014 17:10:19 -0500

> a secure channel for applications to use.

There's also IPsec w/ connection latching (RFC5660, though sadly
unimplemented).  Without that IPsec doesn't provide anything like a
secure channel, not without having to manually inspect and manage the
configuration of IPsec befure establishing the channel and throughout
the channel's lifetime (indeed, this is what connection latching does,
in an automated way).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 13 Sep 2014 17:14:29 -0500

On Sat, Sep 13, 2014 at 12:29:38PM +0000, Markulf Kohlweiss wrote:
> Just using different keys for the Handshake and the Record, isn't
> quite that simple, especially if one wants to interleave Handshake and
> Record messages. In current TLS terminology one should probably say
> for Handshake and AppData (what about Alert?). Record messages wrap
> the messages for all three of these protocols.

For synchronoush handshake messages it's not problem at all.

For async handshake messages we must rely on replay protection (which we
needed anyways) and we can't use different keys, indeed.

> A different question is the extent to which interleaving Handshake and
> Record messages is necessary in TLS 1.3? I expect that there are good
> use cases for this. One question is whether these use cases can be
> separated in a modular way from the core key exchange functionality,
> e.g. Token Binding, but this may be hard for certain purposes, like
> protecting the confidentiality of certificates.

If you want any kind of re-keying at anything other than
deterministically pre-selected points in a connection's lifetime, or if
you want to have any kind of alerts (e.g., disconnect), then we need to
be able to interleave control and data.  That means either that the
record type must go in the clear, that we use the same keys for all
records, or that receivers must try all possible sub-keys.

Nico
--

---

From: Markulf Kohlweiss <[email-masked]>
Date: Sat, 13 Sep 2014 22:27:46 +0000

To be more efficient than full trial decryption, one can use pseudo-random values (pre-)computed for all possible keys to detect the key of a ciphertext.
 
Do we know of other systems that designed, implemented, and tested such a mechanism?

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: 13 September 2014 23:14
To: Markulf Kohlweiss
Cc: Alfredo Pironti; Eric Rescorla; [email-masked]
Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof]

For async handshake messages we must rely on replay protection (which we needed anyways) and we can't use different keys, indeed.

> protecting the confidentiality of certificates.

If you want any kind of re-keying at anything other than deterministically pre-selected points in a connection's lifetime, or if you want to have any kind of alerts (e.g., disconnect), then we need to be able to interleave control and data.  That means either that the record type must go in the clear, that we use the same keys for all records, or that receivers must try all possible sub-keys.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Thu, 18 Sep 2014 03:16:22 +0200 (CEST)

> protection in the analysis.

Somehow that argument feels quite lame when it is combined with the
argument "the proof would be easier when the finished messages were
sent in the clear, could we not change this".

Just do the proof under the assumption/premise that the finished messages
*ARE* in the clear.  Then send them encrypted.  Unless you're doing avoidable
weird things, sending them encrypted rather then in the clear should not
affect the original proof at all.

If the TLS channel would be sensitive to what exact data is transferred
within that encrypted channel, then you would have *MUCH* larger problems
and it would apply to just about any kind of arbitrary application data.

-Martin

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 17 Sep 2014 21:44:31 -0400

> because it is what has caused by far the most security goofs

​I have no idea what you understand by generic security but it is certainly
not what I (and the cryptographic literature) mean by that. There is no
magic in this notion, not in dust or any other form. Generic security
refers to well-defined (mathematical) notions​

​of security pertaining to some security/cryptography task. Key exchange is
such a task that is defined in a way that is independent of applications.
This is the meaning of "generic". It has the advantage, as I mentioned in
my email, to support cryptographic designs that can work independently of,
and with, multiple applications. As with any mathematical model of an
engineering problem the guarantees you get following this approach are
limited by the model itself. In the case of cryptography, a model may not
cover all avenues of attack or may make some assumptions not met in some
scenarios. Therefore, generic security is no magic, in particular no magic
bullet. But it is one of the best tools we have to design sound
cryptography and the track record of this approach is MUCH better than the
design by intuition-only or by "word of gentleman" (such as "trust me - if
there was a problem in this design I would have spotted it already"). Of
course, one can use the "word of gentleman" approach also to the selection
of cryptographic models and definitions. Luckily we have a very active and
vibrant community reviewing these notions and adapting them to new
realities and new findings. Formal models and definitions are thus tools to
inform us about good and bad designs. While these should not be the only
elements for judging cryptographic constructs, ignoring them would take us
back 20 years - the days of "I know better - trust me" (and 20 years of
demonstrations of why that approach didn't work too well).

> ​This example is indeed illustrative of generic security​

​but not in the way you present it.
When one asks the question of how to build a "secure channel" (a notion
that requires a definition) between two endpoints that share a secret key
there are different solutions depending on the type of encryption and
authentication you use. But there is only one generic-secure solution: you
first encrypt then authenticate the ciphertext. It means that any
encryption that is generically secure against passive attacks combined in
that particular way with any authentication mechanism secure against chosen
message attack will give you a secure channel. Other combinations may or
may not work hence they are not generically secure.

As for IPsec, there are many things to complain about  ipsec but except for
the historic case of independent ESP and AH (deprecated quite early in that
history), IPSec has done the right thing: Use generic
encrypt-then-authenticate. IPsec did also much better than TLS with repect
to cryptographic key exchange - even in the case of IKEv1 the problems were
of unnecessary options and complexity, not of insecurity of the basic
cryptographic mechanisms.

​

> security does not pay off.

​???
​

> One of the downsides of
> ​​
> spartanic theoretic cryptography is that it
> of the
> ​​
> cryptoglycerin stuff, not more of it, and stuff that is easy

​to the contrary, good crypto theory can inform you about how to simplify
designs by getting rid of unnecessary (and often counterproductive) safety
margins. It is a very practical theory if you know how to use it. I guess
that glycerin is also quite practical if you know how to use it...

Hugo
​

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Sep 2014 19:03:10 -0700

> affect the original proof at all.

Yes, that's what previous analysis had to do. In combination with
other misfeatures (need for Oracle DH assumptions, additional
complexity) the result was that protocol weaknesses went undetected.

The bigger the difference between TLS and the protocol that is
actually analyzed, the weaker the guaranties are about the safety of
TLS. Furthermore the space of changes people make to TLS is much
larger than is actually realized: take all the RFCs referring to any
version of TLS, and consider that each one may or may not be
implemented. The resulting combinatorial explosion cannot be dealt
with except by modularizing the proof.

TLS 1.3 adds new tricks, like Zero-RTT, one-RTT forms, and possibly
new forms of encrypted data. The easier it is to analyze the core
protocol the easier it will be to analyze these proposals, and fix
them. Most of the people who are making proposals including myself
have not got the ability or time to do a proper analysis. The few
people who do are really overworked, and so far we've heard nothing
from them (for good reason: you don't want a late change to turn a
significant amount of work into a nonstarter) It is a substantially
more complicated protocol.

We need to think about how to avoid the past two decades of major
cryptographic weaknesses, repeatedly identified in TLS
implementations, some of which are still not fixed.

Sincerely,
Watson Ladd

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Sep 2014 22:40:47 -0500

> affect the original proof at all.

To me the argument feels lame because we must anyways be able to
distinguish record types[0] and detect replays[1] (at least for TLS, and
for DTLS[2] I would argue that replays of handshake messages must always
be enabled).

[0] Certainly if we retain any asynchronous handshake or other
    non-application records post-initial handshake then we must be able
    to securely distinguish record types!

[1] Certainly if we retain any asynchronous... then we must be able to
    securely detect replays.

[2] I understand application record replay detection being optional in
    DTLS.  But certainly it mustn't be for any async handshake records.

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Sep 2014 22:43:01 -0500

To clarify: I don't oppose not encrypting the Finished messages, and IMO
it is better to not encrypt them.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Sep 2014 21:29:27 -0700

> for DTLS[2] I would argue that replays of handshake messages must always

That wasn't the argument Mr. Krawczyk and I made. TLS provides a
secure channel, and we know how to prove it does.
Rather the problem is that some applications like RFCs I've cited,
that are deployed, use the TLS handshake to derive a key
that is used for another purpose. This is not safe without analysing
the specifics of the encryption scheme used.

In particular, an application that has its own record layer may
interpret the Finished message in strange ways. This can cause
problems.

There are other unpatched issues, like the possibility to misinterpret
the Server Key Exchange field and use this to impersonate a server,
that need addressing. And so far nothing has been said about the
proposed changes.

Sincerely,
Watson Ladd

---

From: Michael Sweet <[email-masked]>
Date: Thu, 18 Sep 2014 07:29:49 -0400

My $0.02: Would it make sense to stop treating extensions as an a la carte mechanism, and instead define "extension suites", much as TLS already groups specific combinations of cryptographic primitives that can be selected in cipher suites?

Seems like that would limit the allowed combinations of extensions to those that have gone through the necessary analysis and are considered "safe" to use together?

>> and it would apply to just about any kind of arbitrary application data.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 18 Sep 2014 16:24:24 +0200

On Thu, 2014-09-18 at 07:29 -0400, Michael Sweet wrote:
> My $0.02: Would it make sense to stop treating extensions as an a la
> carte mechanism, and instead define "extension suites", much as TLS
> already groups specific combinations of cryptographic primitives that
> can be selected in cipher suites?

Well, I think we need more than your 2 cents for that. Could you
elaborate what you mean here? The extensions were put in place to
overcome the limitation of the ciphersuites that you just mentioned.

> Seems like that would limit the allowed combinations of extensions to
> those that have gone through the necessary analysis and are considered
> "safe" to use together?

Isn't that the set of all extensions that are published by this working
group?

regards,
Nikos

---

From: Michael Sweet <[email-masked]>
Date: Thu, 18 Sep 2014 10:52:32 -0400

Nikos,

The claim was made that TLS + some combination of extensions will produce a non-secure result.  I.e., TLS + Extension Foo is secure, TLS + Extension Bar is secure, but TLS + Foo + Bar is not secure (or cannot be proven to be secure).

Thus, my comment was just a question: if we can't ensure that all combinations of TLS extensions are secure, does it make sense to negotiate sets of extensions instead of the individual extensions?  Obviously a single extension should be secure on its own (otherwise, why is it being approved for use in TLS?), but if a combination of extensions can cause interactions that are not secure then it would make sense to have a way to lock those combinations out (blacklist) or negotiate known good combinations (whitelist).  And having worked with enough security people over the years, I know what the usual preference is for such things (whitelists)...

(I am not a TLS or security expert, just somebody that uses TLS and knows that I don't know everything about it, so I ask questions even if the answers are obvious to those that can claim to be experts...)

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Sep 2014 18:40:52 +0300

On Thu, Sep 18, 2014 at 10:52:32AM -0400, Michael Sweet wrote:
> Nikos,
> 
> The claim was made that TLS + some combination of extensions will
> produce a non-secure result.  I.e., TLS + Extension Foo is secure,
> TLS + Extension Bar is secure, but TLS + Foo + Bar is not secure
> (or cannot be proven to be secure).

There are also extensions that individually screw security (and to
some degree, such extension already exists).

And one would think that if some combination of extensions screws
up security, at least one of those would do odd things (the result
may still be "provably secure").

The places in TLS 1.3 that are especially critical are keying/
encryption (including early handshake) and authentication
(including TLS-UNIQUE and TLS-EXTRACTOR).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Sep 2014 21:52:20 +0300

> the specifics of the encryption scheme used.

Is there some application protocol that uses important TLS system
subkeys for its own purposes? I would rather see such just break.

Such apps are horrible layering violation for no apparent purpose
for one. And I really hope I don't run into TLS libraries supporting
such blatant misuse. And wonder how the heck such thing got past
review.

I'm aware of SRTP that gets its keying material from TLS (it is exactly
that RFC5764). It does not use any TLS system subkeys for itself,
but it dervies dedicated subkeys. So it is OK.

And if security of that depends on specifics of some encryption
scheme, you got problems... SERIOUS problems.

> interpret the Finished message in strange ways. This can cause

If any app does that, it would seem like it would already be broken in
TLS 1.3 (since the key exchange looks nothing like it did in TLS 1.2).

Or are you saying some application replaces major parts of TLS?

SRTP-style mux just uses unused TLS record types to denote non-TLS data,
and passes all TLS data to TLS stack without trying to interpret it
(it can't even interpret anything encrypted, since it lacks keys to
do that).

> that need addressing.

I thought that draft TLS 1.3 + master secret fix would already fix the
SKE issue? Are you talking about fixing it in TLS 1.0-1.2?

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Thu, 18 Sep 2014 20:29:50 -0700

> but it dervies dedicated subkeys. So it is OK.

Yes, it is OK. But I'm not sure if the extractor is defined in the
core TLS spec, or was covered by the miTLS proof, or was not. As a
practical matter the nonstandard assumptions of TLS are much more
worrying: however, SRTP shows that people do use TLS as a key
agreement mechanism, not simply as a secure channel abstraction.

Even as a key agreement mechanism TLS falls to a UKS issue. TLS 1.3
will fix some of these problems: maybe not all.
<snip>

> SKE issue? Are you talking about fixing it in TLS 1.0-1.2?

Yes, in TLS 1.0-1.2. The TLS 1.3 draft changes the way the server
certificate is used to fix this issue, and I think it also fixes some
of the strong assumption issues, but have not looked hard enough to
figure that out. There doesn't seem to be draft solving this problem,
unlike the other known weaknesses. Anyone care to comment? We would
need an extension that changes the format of the Server Key Exchange.

Sincerely,
Watson Ladd

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Sep 2014 08:39:59 +0300

> agreement mechanism, not simply as a secure channel abstraction.

It is not in core TLS spec, it was published after TLS 1.2, nor has
it been incorporated into 1.3.

Basically, it just invokes the PRF.

It does have some (possibly minor) issues:
- It can extract important TLS system subkeys[1].
- The underlying PRF does not cleanly separate the label and seed
  (so one can trivially find collisions)[2].

Also, the extractor is used to authenticate connections by
signing output. That needs to work even in face of total failure
(universal forgery) of server signature.

[1] Application using those for its own purposes can really create
a mess security-wise (using the same key for two different
algorithms, or even the same algorithm without coordinating nonces
can really create problems).

[2] E.g.

PRF(secret, "foo", "barbaz") and PRF(secret, "foobar", "baz")
and PRF(secret, "foobarbaz") of the same length all collide.

-Ilari