Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Feb 2014 12:40:38 -0800

Folks,

I have prepared a new version of the TLS 1.3 flows document which
should appear in the repository shortly and in the meantime can be
found at:

https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt

This version fleshes out a "recommended" set of flows:

- 2-RTT where the client has no knowledge of the
  server's capabilities.

- 1-RTT where the client knows the server's semi-permanent
  DHE/ECDHE key pair.

- 0-RTT where the client and the server have shared anti-replay
  state.

There are still a number of open issues, but this should be clear
enough to see the direction I am trying to go. These flows are
structured so that the 1-RTT case is the base case with the 2-RTT and
0-RTT versions being variants of the basic 1-RTT handshake. All
variants encrypt the client extensions that are not required
to define the cryptographic processing (e.g., SNI is encrypted
but curve negotiation is not).

I think the high order bit here is whether we want to have
encrypted SNI, because that dictates the position of the DHE
exchanges with respect to the server's messages.

There are three options here:

- Never
- Sometimes
- Always

The flows in this draft take the position of "Always" which is
simple. "Never" is actually simpler. "Sometimes" is the most
complicated.  There are two cases where we could shave off latency if
we were willing to disclose the SNI to passive attackers (and in cases
where the client and server have never talked before.) My sense of
recent discussion is that people feel it's important to have modes
that protect SNI even if those are not the only modes. However, that
means that if we want to have non-SNI protecting modes, they are
additional complexity. Please let me know if I have misread the WG
here.

Here are some other things to keep in mind as you read the document.

- Per my sense of the list, I have totally removed static RSA.  If
people strongly object to that, please speak up and let me know.

- There has been no real security analysis of this material other than
at the hand-wavy level. We clearly need that, but the first thing we
need is to be clear on whether this is approximately the right set of
points in the complexity/performance/privacy tradeoff space and then
make sure that the security properties are correct. So, if you see
something that looks wrong or even grievously wrong, don't panic (but
do point it out).

- There is no currently defined support for any kind of resumption.
We need to decide if resumption is still an important feature in light
of the trend towards more PFS and faster processors.  I'm particularly
looking for input from the IoT/DICE guys here.

- We will probably need to work out some of the details for DTLS, but
I wanted to get TLS nailed down first.

- We also need to do some work on the symmetric crypto, e.g., to make
encrypt-then-MAC the default, perhaps to deprecate some ciphers,
compression, etc. I haven't forgotten that, but I want to deal with
the handshakes first.

- As before, this incorporates ideas from a lot of different people
(and many times the same idea from different people). If you think
you should acknowledged in the text and/or acknowledgements
differently, please let me know.

Thanks and comments welcome
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Feb 2014 13:54:06 -0800

One more point that someone made to me offline.

The flows in this document make multiple use of the same DH/ECDH
share (i.e., pairing the client's ECDH share with two separate server
shares.) This is in some respects like static DH and so we should
provide appropriate security guidance. There's already some such
guidance in RFC 5246 Section F.1.1.3:

http://tools.ietf.org/html/rfc5246#appendix-F.1.1.3

We might also consider whether it makes sense to specify a fixed
set of DH parameters (a la IKE and in the spirit of the specified
curves in RFC 4492), thus avoiding any need for people to
validate. That seems like something that might be valuable for
all versions of TLS.

Do we need anything else?

-Ekr

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 19 Feb 2014 23:10:26 +0100

> - 0-RTT where the client and the server have shared anti-replay

So reading this, one of the points I see if that you could
distribute this semi-permanent DHE/ECDHE key pair via DNS for
instance.  I think that the presence of that information
in DNS could indicate that the server does support it and I
currently don't see why:
- You can't do 0-RTT
- SNI needs common crypto parameters

The only reason I can find in your document is to prevent replay,
but I currently don't see how this is a problem.

I'd also like to point out that you might be leaking the site
you're connecting to via DNS.

Kurt

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Feb 2014 14:24:48 -0800

You could put half of the first round trip in DNS, but that's a fairly
major change to the protocol.  Note however that the ServerParameters
described in the draft is something that could be discovered through
other channels, definitely.  No one is checking where
PredictedParameters came from, just that it is correct.

> but I currently don't see how this is a problem.

If I had any reason to believe that your first flight included
non-idempotent HTTP requests of interest to me (e.g., transfer $X to
account Y) then replay protection is extremely interesting.

> you're connecting to via DNS.

There's already been a fair amount of discussion on why some people
are interested in protecting SNI, and that point was addressed there.
I'll point out that confidentiality protection for DNS queries is
being discussed.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Feb 2014 14:35:41 -0800

Kurt,

Thanks for your comments. Responses below.

On Wed, Feb 19, 2014 at 2:10 PM, Kurt Roeckx <[email-masked]> wrote:

> instance.

Absolutely. This is contemplated in:

http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.1

> I think that the presence of that information
> but I currently don't see how this is a problem
>

Generally replay is a problem whenever the server might take
some action based on the client's messages. E.g., I'm buying
something and I don't want to buy four of them.

The reason for SNI requiring common crypto parameters is that
otherwise the attacker can observe which crypto parameters you
use and thus determine which virtual server you are trying to
contact.

> you're connecting to via DNS.

Absolutely. In order to hide which virtual server one is talking to you
need to hide both:

- The DNS query
- The SNI and cert

There are other people working on the first of these (and in many
cases the attacker will only be positioned to see the SNI because
of DNS caching), so hiding SNI is a bet on that other work being
done.

-Ekr

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 20 Feb 2014 00:03:21 +0100

> PredictedParameters came from, just that it is correct.

I'm not saying that it's the only way, but it could be a way that
some sites might want to use.  I also think this doesn't add any
additional RTT on DNS, you can run 2 or more queries at the same
time.

> account Y) then replay protection is extremely interesting.

I was only looking at this from the client side for some reason.
At the server side I ussually deal with this at the application
level instead.

Kurt

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 21 Feb 2014 15:46:27 +0100

> should appear in the repository shortly and in the meantime can be

Hello,
 I haven't read it yet to comment, but may I suggest something
procedural? I think it would be better to first agree on the list of
issues that TLS 1.3 will fix, and the list of features it will bring, 
and the security requirements for this protocol; as the charter is very
high level for that.

I believe you have already done that as part of your presentation in
IETF 88, and there was some discussions on the list some time ago, but I
don't know what was considered or discarded. It would be nice to have a
draft that sets the desired requirements for TLS 1.3. (I'd volunteer
maintain one if that is the issue)

Then it will be much more easy to check whether a proposed solution
satisfies the requirements, and input from other unrelated groups such
as CFRG would be more easy to get.

regards,
Nikos

PS. As I believe that security protocol design is part of cryptography, 
I'm still of the opinion that we should more actively seek for external
expertise (e.g., by a competition or other appropriate methods).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Feb 2014 07:16:58 -0800

> as CFRG would be more easy to get.

I'm certainly sympathetic to this, but I don't think it's really practical
to do detailed requirements first. That's always a hard approach in
IETF, but it's especially hard here because there are a lot of tradeoffs
to be made in terms of feature set and once you get beyond the
trivial mandatory elements it's hard to make them without
understanding the implications of opting to include or not include
any given features without understanding the effect they have on
the protocol in some detail. So, instead we've been doing this
as a cyclical design process, with the charter as the very high
level goals and then trying to work downward.

After Vancouver, I had a lot of feedback to the effect that we
needed to work out the mechanisms more so that people could
make an informed decision, so that's what I've tried to do here.
What I'm hoping we can do in London is to use these more worked
out mechanisms to reach informed decisions on a number of the
big requirements questions (static RSA, encrypted SNI, resumption,
etc.) and then we can work on a refined design that matches
those requirements.

-Ekr

regards,

---

From: Tom Ritter <[email-masked]>
Date: Sat, 22 Feb 2014 11:38:34 -0500

> https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt

Thanks Eric!

> that protect SNI

I agree with this.

> even if those are not the only modes. However, that
> additional complexity.

But not so much with this.  TLS has suffered from the multitude of
options and the complexity choosing them provides. If at all possible,
I lean away from accommodating more modes in favor of fewer much more
secure, but perhaps slightly more complicated modes.

> Thanks and comments welcome

Random:

---------------------------------------------
On replays

"   o Once the client and server have communicated once, they can
      establish an anti-replay token which can be used by the client to
      do a 0-RTT handshake with the server in future.  This is shown in
      Figure 5."

This confused me, because from this paragraph alone, it seemed like
the server was providing the client with a nonce, storing it, and when
the client used it again, the server forgot it and thus invalidated
it.  This does prevent replay - but it's not what the draft actually
describes.  I would try and rephrase this.

"Generally all of them require the server to give
   the client some identifier which is later replayed to the server to
   help it recover state and detect replays."

I don't think this is accurate wording either.  It implies a session
resumption. I would describe all of them as "the client remembers the
server's preferred parameters (ciphersuites, groups, orbit), and may
include something unique the server is expected to remember and use to
reject replays".

Two techniques I'm aware of for rejecting replays are relatively simple.
The first is the same as snap start, I'll mention that it's used by
mixmaster. The server stores identifiers, and discards any message
that has the same identifier or a timestamp older than X hours;
discarding state older than X hours as well.
The other is used by mixminion, and does not require roughly
synchronized clocks. The server stores the packet identifiers, and
rotates its keys every X hours, discarding the state and the keys upon
rotate. The server can detect replayed packets using it's state up
until discard and after discard, cannot decrypt any replayed packets
at all.  This also removes the need for an orbit.

On the topic of 0-RT and PFS. It adds complexity, but I can envision
an inline key exchange happening alongside the first few application
data packets.  I think this is what you mention on line 458, but I'm
not sure I understand why you say it's too expensive on a regular
basis? The client is doing two DH operations, the server similarly
does two. Normal PFS handshakes today require a RSA decryption and a
DH.  A resumption is much cheaper, yes.  Is this what you meant or did
I miss it?

---------------------------------------------

RE: No SNI and the issue on line 657 - I suspect, but testing would
need to be done, that nearly all major sites and most in general will
serve a valid default certificate if SNI is omitted.  I suspect this
would not be a difficult test for someone with a SSL scanning setup to
run.

-tom

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Feb 2014 12:23:35 -0800

Tom,

Thanks for your comments.

> secure, but perhaps slightly more complicated modes.

Can you unpack this a little for me? Are you saying we should always
protect SNI or something else?

> Thanks and comments welcome

Yeah, this section is badly written. I was trying to characterize all the
possible options with a single description and ended up characterizing
them all in a confusing way. Once we select a design, we can just
remove all the generic text and in the meantime I will try to clean this
up.

> DH.  A resumption is much cheaper, yes.  Is this what you meant or did

This is old text. When I wrote it it seemed to me that two DHs was a big
deal, but I'm less sure now. Still, it's a nonzero cost and the WG should
probably discuss it before we just decide to impose the cost.

> run

Agreed. I'll see if I can get someone to do that...

Thanks,
-Ekr

---

From: Tom Ritter <[email-masked]>
Date: Sat, 22 Feb 2014 23:46:42 -0500

> protect SNI or something else?

Yes, that we should always protect SNI. Having options to protect or
not protect introduces complexity, even moreso in my mind over having
a single more complicated option that always protects.  Likewise, if
major software chooses the option not to protect - that's a very high
percentage where the protection is not used, and the higher security
option will stand out as unusual.

-tom

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Feb 2014 12:13:05 -0800

It seems to me the basic idea is to have the client encrypt its
handshake after learning the server ECDH key, under the idea that this
protects the client handshake. But this is wrong: the server's key
isn't authenticated, so the handshake isn't actually being protected.
This is why we need to know the server ECDH key for the 1RTT
transaction.

90% of what people use TLS for can be handled by the following flow:
C->S: g^x
S->C: g^y, Sign(g^y, g^x), certificates
C->S:everything encrypted with g^(xy).

This is 1 round trip with no preknowledge, and has additional security.
In particular for SNI we could get some additional information from
DNS like "hi, I'm hosted with alice.com and bob.com, so if you see
other certificates, close the connection." I don't see a way to do
that with the current round trip proposals.

As a sidenote: kick DH. ECDH has the DH speed record, and isn't going
to give it up anytime soon. The IPR issues are long gone for something
invented in 1985.

Sincerely,
Watson Ladd

On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> 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: Hovav Shacham <[email-masked]>
Date: Sun, 23 Feb 2014 12:34:01 -0800

On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd <[email-masked]> wrote:

C->S: g^x
> This is 1 round trip with no preknowledge, and has additional security.

Um, *which* certificates?  All of them?  And a signature under which key?
 All of them?

-hs.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Feb 2014 12:36:04 -0800

> Um, *which* certificates?  All of them?  And a signature under which key?

Under a key then signed with the certificate. Even with SNI you should
be able to pick an identity to respond with first.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Feb 2014 13:26:37 -0800

Watson,

> isn't authenticated, so the handshake isn't actually being protected.

It's being protected from passive attack.

In general, because the server has multiple certificates and uses
SNI to select between them, we can't really authenticate the DH
exchange until the client has supplied the SNI to indicate which
certificate is to be used to authenticate the exchange.
The idea here is to do an initial unauthenticated DH exchange
to protect the SNI from passive attackers. Obviously this isn't
perfect, but it's an improvement over the current state.

Note that once the client and the server have spoken once and the
client has a valid server key (via ServerParameters or the like), the
client can use that key to form a secure connection and therefore
protect the SNI from an active adversary (in theory).  However (and
this is a big however) if you won't fall back to the non-optimistic
case, you have a permanent commitment for the server to use those
parameters, and if it forgets those for some reason (or you have
multiple servers without totally shared state), then you would have no
way to recover, so it's a tradeoff. [There are similar tradeoffs with
cert pinning.]

See Section 8.1:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-8.1

> C->S:everything encrypted with g^(xy).

This is effectively what's in Appendix C:

http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C

I agree it's basically what you want if you don't care about protecting SNI.
As I said in my note, I am assuming we want to try to protect SNI from
passive attackers.

BTW, I note that this still is counting on some degree of
pre-knowledge, namely, of what groups are acceptable to the server, so
there's still a possibility you will end up having to do a second
round trip.

> that with the current round trip proposals.

I'm not sure quite what you're proposing here, but there's been a
bunch of work on using DNS and DNSSEC to indicate information
about the server's certificates. See, for instance:

http://tools.ietf.org/html/rfc6698
http://tools.ietf.org/html/draft-ietf-dane-srv-05

However, this work is mostly agnostic to the details of the handshake
flow, so I'm not sure how it interacts with the question of the internals
of TLS.

> to give it up anytime soon. The IPR issues are long gone for something

This seems like an orthogonal issue, so I suggest we discuss it separately.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Feb 2014 16:41:10 -0800

> It's being protected from passive attack.

At a cost that would suffice to protect it from active attack, namely
a DH computation on each side after looking up one end in the DNS.

> As I said in my note, I am assuming we want to try to protect SNI from

True, but my point was more that anything more than 128 bytes and
certificates is cruft. Some of that is unavoidable given backwards
necessity Some of that (SNI, ALPN) is of dubious necessity. But if we
want to make a real improvement in security, we need to massively
simplify the protocol and the code required to implement it.
> there's still a possibility you will end up having to do a second

Easy solution: limit the options so that there is one acceptable
choice, with a means to negotiate a future one when that one
acceptable choice falls. There is no reason to have a smorgasbord of
possibilities here.
> about the server's certificates. See, for instance:

I'm proposing that we secure the key we are sending SNI data to with
some certificate, so that a future extension can impose restrictions
on who gets to see that data. With your proposal of security only
against passive attackers, this requires the server to keep the ECDH
key it uses in memory and say something like "expect this ECDH key",
which is much more restrictive operationally.

> flow, so I'm not sure how it interacts with the question of the internals

It's not agnostic. The kind of key I get from DNS can dramatically
change what sorts of protocols are possible, and hence how the
handshake works. Get an ECDH key and we can do some sort of MQV
variant (AKE or SIGMA is probably the right thing here). Get out the
SHA256 fingerprint of an RSA key and there is nothing you can do: the
other side has to go first to tell you what the key is.

Sincerely,
Watson Ladd

---

From: Stephen Checkoway <[email-masked]>
Date: Sun, 23 Feb 2014 20:20:01 -0500

Hi Watson,

On Feb 23, 2014, at 7:41 PM, Watson Ladd <[email-masked]> wrote:

> choice,

As much as this appeals to me, this route seems unlikely to be adopted since what's acceptable to you or me is probably not acceptable to everyone.

> with a means to negotiate a future one when that one
> acceptable choice falls.

It seems likely that this will because the default method and I'm not sure how this is simpler than offering options initially.

> some certificate

I'm not sure I'm following you here. As I understand it, the whole issue is that with SNI the server doesn't know which cert to use until after it sees the SNI. Are you proposing that there is some master cert which secures the key used for SNI data and then a separate cert for the given server name?

-- 
Stephen Checkoway

---

From: Watson Ladd <[email-masked]>
Date: Sun, 23 Feb 2014 17:31:50 -0800

> It seems likely that this will because the default method and I'm not sure how this is simpler than offering options initially.

Does anyone have a problem with P256 or Curve25519 with some fallback
option TBD?

> I'm not sure I'm following you here. As I understand it, the whole issue is that with SNI the server doesn't know which cert to use until after it sees the SNI. Are you proposing that there is some…

In the SNI case the server has a great number of certificates to pick
from, and doesn't know which one to use. My suggestion is that they
use on initially, and if informed they messed up, use that one.

Sincerely,
Watson Ladd

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 24 Feb 2014 08:01:18 -0500

> Does anyone have a problem with P256 or Curve25519 with some fallback

I don't have a problem with either but, again, that doesn't say anything about everyone else.

> use on initially, and if informed they messed up, use that one.

So say the server picks the wrong one. This reveals a different server name to the client. This would seem to be an issue if the various names the server is willing to use are private for some reason. With the wrong one chosen, the client has three options: (1) send the SNI in the clear to the server; (2) use the unauthenticated server parameters to establish a key and send the SNI encrypted under that key; or (3) say "nope, pick a different cert and try again."

(1) is essentially what we have today but with more overhead;
(2) is essentially the proposed mechanism except that it has more overhead and exposes the server name of the incorrectly chosen cert; and
(3) could take a significant number of round trips to get the right cert and also enables a client to enumerate all supported server names.

None of these seem better so I've probably misunderstood what you're actually proposing.

-- 
Stephen Checkoway