Subject: [TLS] Comments on PR #95

From: Watson Ladd <[email-masked]>
Date: Wed, 24 Dec 2014 16:20:59 -0500

Dear all,
I've read PR #95 with a critical eye, and in addition to some
infelicities of the text, see some more substantial issues. This email
is my notes in the order they occurred to me: not necessarily
correlated with severity. I've tried to triage them, but may have done
so inaccurately. Most of these are editorial in nature.

Line 291: we're citing DSA. old text. More broadly, applications don't
care how we provide what we provide: they care about the end goals. At
some point this should be revised accordingly.

Line 418: Security means what exactly?

Line 437-453: this needs to be rewritten. Why are we talking about SSL
v3, when any similarity is like that of a whale to a platypus?

Line 743: I'm confused by the comment on how one finds the length of
the signature data: it seems to be sent on the wire, but the document
says " The length of the signature is known because the algorithm and
key used for the signing are known prior to encoding or decoding this
structure.", which is a different method.

I recommend removing that last sentence: the parser should parse with
as little input as possible from above.

Line 836: 800 lines in, and we've gotten about nowhere: defined a PRF,
and a representation format. Now we hear that TLS doesn't provide some
security properties, but we don't know what those are. A succinct,
correct description should appear at the beginning and again in the
security considerations section.

Line 1015: Zero-length fragments of application data as traffic
analysis countermeasure? I think this was written when padding between
the fragment and record layers existed, and I'll have to check how
this was supposed to work. As it stands, I've not yet gotten to a
description of the record layer at the time I read this.

Lines 1066-1072: We've got a perfectly good nonce in the sequence
number. Why not use that? Oh right, hysterical raisins.

Line 1119: Open issue #5. I've got to think about this one. Likely as
not this will be a very complicated change, that makes TLS 1.3 a lot
harder to implement.

Line 1190: More forward references to resumption. Note that
authentication status isn't defined as part of what gets resumed. I
believe, but am not sure, that this was part of what made the SSL v3
multihoming fallback attack work.

Line 1439: Finally, the handshake protocol. In this description there
are a ton of forward references, that make understanding this a bit
tricky. What's an Encrypted Extensions method, on line 1505? While the
earlier description of the Alert protocol was by type of message, this
overview is chronological.

Line 1623: We're getting to the beef. But the reader already knows
this: no need to reintroduce the handshake protocol.

Line 1763: It's not clear what servers have to do, or not do, to deal
with stolen session IDs. They need to not "breach security", whatever
that means.

Line 1863: Previously, hello extensions were relegated to a different
document. Now they are needed for backwards compatibility.

Line 1912: Was anyone using SRP? The more generic we have to make TLS
1.3, and the more we have to shoehorn in, the more complex it gets.
This open issue could get hairy.

Line 2199: Mandating the presence of the signature_algorithms
extension would simplify things considerably.

There are a bunch of open issues in the description of the handshake
protocol, and some warts. I haven't thought about provability yet.

Line 2995: A TODO DTLS, probably related to the possibility of the
Update message being lost. I don't remember how DTLS deals with this
in the handshake, but there data is not being sent with the new keys
before the other side acknowledges receipt. Will think about it.

Does ignoring an update still update the record layer?

There does not seem to be a way to request a certificate in the update protocol.

Line 3151: AES-GCM or AES-CCM seem the logical options here.

Line 3165: This doesn't seem to be a very fleshed out security
considerations section.

Line 3606: Do we need the glossary?

The implementation notes needs a substantial amount of work. The
advice on random number generation is vintage 90's.  The discussion of
certificate checks could be substantially expanded. A lot of attacks
that have been used in the wild are not discussed here.

Line 4015: SSL v2? Really?

Line 4034: This is not a security analysis.
http://eprint.iacr.org/2014/182.pdf is a security analysis. It would
be much more helpful if this was significantly edited: there is some
valuable information in here, but much of it is misleading.

Line 4185: This reads a bit strangely with things like DANE. Yes, I
don't think DNSSEC has adequate security, and it's worth noting that
CAs can be a problem. I think it's worth telling implementors to study
the lessons of attacks in the past.

This version of the draft is very clearly a work in progress. 0-RTT
was introduced in a different pull-request, and I've not given it a
hard look.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2014 17:30:03 -0800

Watson,

Thanks for the comments. Many of these are comments on the draft as
a whole (and a lot are text that remains from TLS 1.2 and before). I'll
go through these and turn them into Github issues for discussion
(though given the holidays it probably won't be this week).

Best,
-Ekr

On Wed, Dec 24, 2014 at 1:20 PM, Watson Ladd <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Dec 2014 12:19:07 -0800

Thanks again for the detailed comments.

On Wed, Dec 24, 2014 at 1:20 PM, Watson Ladd <[email-masked]> wrote:

> Line 291: we're citing DSA. old text.

I agree that it would be better to cite ECDSA here. I'll fix.

> More broadly, applications don't

I'm not sure I agree with this. This text isn't targeted only at application
developers, and it is is important to know roughly what kind of thing
is being specified here.

Yes, it would be useful to provide some more context here, though note
that this is an introductory paragraph so it's necessarily going to be a
bit handwavy. Probably the right thing to do here is have slightly
more detail and then point to a security considerations section.
https://github.com/tlswg/tls13-spec/issues/114

> v3, when any similarity is like that of a whale to a platypus?

https://github.com/tlswg/tls13-spec/issues/115

> structure.", which is a different method.I recommend removing that last
> sentence: the parser should parse with

Agreed.

> security considerations section.

Seems like  https://github.com/tlswg/tls13-spec/issues/114 again.

> description of the record layer at the time I read this.

Yes, this doesn't work if you don't have padding. However, I know this
is something that there is interest in having, so I suggest we leave in for
now. See: https://github.com/tlswg/tls13-spec/issues/69

> number. Why not use that? Oh right, hysterical raisins.

There are two things going on here:

1. Some AEAD ciphers have nonces that are longer than the TLS sequence
number, so you need to somehow specify that construction.

2. There was a desire to have the nonce be output by the AEAD cipher
rather than input to it, so that the AEAD cipher itself could guarantee
non-reuse. Note that there are other constructions that could work
here (e.g., having a specified pattern and requiring the cipher to enforce
that).

> not this will be a very complicated change, that makes TLS 1.3 a lot

Can you elaborate more on why you think that?

> multihoming fallback attack work.

If you want to provide some text, that would be welcome.

> overview is chronological.

Yeah, it's always hard to figure out how to make this work editorially.
If you have some concrete suggestions, that would certainly be welcome.
I suppose we could push this section to later.

> this: no need to reintroduce the handshake protocol.

I'm not sure how much you'd like to shorten here. Can you propose
a concrete change.

> with stolen session IDs. They need to not "breach security", whatever

Yeah, I see what you mean. I can clean this up when we do the
sessionid/ticket
merge.

> document. Now they are needed for backwards compatibility.

Hello extensions are actually in 5246.
https://tools.ietf.org/html/rfc5246#section-7.4.1.4

> This open issue could get hairy.

Agreed. I think we should remove SRP support.

> extension would simplify things considerably.

Yes. Let's do that.
https://github.com/tlswg/tls13-spec/issues/116

> before the other side acknowledges receipt. Will think about it.

The general way you deal with this in the handshake is that the last
flight is used as an acknowledgement of the previous flight. The sender
of the previous flight has to retransmit until they receive the last flight
and the sender of the last flight has to keep their state around long
enough to be able to handle the retransmit or up to 2MSL.

This general pattern should work here, but we need to work out the
details for DTLS, hence the TODO.

Yes, it should. You're just saying "I updated my state but I have no idea
what
you wanted".

> There does not seem to be a way to request a certificate in the update

This is deliberate.

> Line 3151: AES-GCM or AES-CCM seem the logical options here.

Well, we need to specify the public key algorithms as well. But GCM does
seem like probably the choice.

> considerations section.

I'd certainly welcome contributions here.

Unsure. Comments welcome:
https://github.com/tlswg/tls13-spec/issues/117

> that have been used in the wild are not discussed here.

I'd welcome contributions here as well.

> Line 4015: SSL v2? Really?

There's been a bunch of mailing list discussion on this recently.
See also:
https://github.com/tlswg/tls13-spec/pull/105
https://github.com/tlswg/tls13-spec/pull/107

> the lessons of attacks in the past.

I'd welcome contributions here.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Wed, 31 Dec 2014 11:54:02 -0500

> Thanks again for the detailed comments.
<snip>
> Can you elaborate more on why you think that?

Right now the key calculation is the same as TLS 1.2. Changing this to
separate the generated nonce would be annoying. Probably the easiest
solution is to not generate the nonce from the master secret, and so
have all PRF outputs be used only as keys. But this has knock-on
effects.

> If you want to provide some text, that would be welcome.

How about "In certain cases, servers may have multiple identities. In
this case resumption does not guarantee that the client and server
share the same view of which identity is involved. For examples of
security vulnerabilities introduced by neglecting this detail, see
Virtual Host Confusion https://bh.ht.vc/vhost_confusion.pdf"

> I'm not sure how much you'd like to shorten here. Can you propose

Removing lines 1634-1674? They just seem repetitive to me.

> https://tools.ietf.org/html/rfc5246#section-7.4.1.4

You are right, and I was wrong.

> details for DTLS, hence the TODO.

I don't think this is right. After A sends an update, they change the
encryption keys for data from A to B. Now if the update arrives late,
we get a bad MAC when the data A sent arrives at B.

One solution is to carefully trim down the size of updates, and send
an update along with the data, until confirmation comes that we can
stop. This is a much messier mechanism, but may be necessary if we
want DTLS to be able to use update.

> Yes, it should. You're just saying "I updated my state but I have no idea

That wasn't clear from the text to me. I'll think about clarifications.
>> There does not seem to be a way to request a certificate in the update

So how do servers tell clients what sorts of certificates they want?
Are we kicking this to higher layers? This prevents drop in
replacement as I seem to remember HTTP+client cert doesn't work like
that.

>> that have been used in the wild are not discussed here.

For all of these I'll try making a Pull Request, separated by where in
the doc they appear.

Sincerely,
Watson Ladd

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 Dec 2014 09:08:44 -0800

[Trimming aggressively]

> have all PRF outputs be used only as keys. But this has knock-on

I don't think this is going to be too bad, but I guess we'll find out when
we go to do it :)

> we get a bad MAC when the data A sent arrives at B.

You'll have to update the DTLS epoch value so that you can distinguish
which set of keys it uses. In DTLS 1.2, the epoch was used for
rehandshake, but we don't need that here, so it's a natural fit.

> replacement as I seem to remember HTTP+client cert doesn't work like

The situation here is a bit messy.

In TLS 1.3 presently, the server sends a CertificateRequest which contains
the same information as it did in TLS 1.2. So we have a number of options
here:

1. Leave client auth as-is.
2. Have client auth in update but allowed only once with CertificateRequest
used
to indicate which certificate you expect.
3. Do client auth in update but with only application level signaling.
4. Some combination of these.

I don't think there's consensus on the best approach because it's partly
about interaction with upper layer semantics.

Best,
-Ekr