[TLS] Comments on PR #95

[Watson Ladd <[e-mail]>]

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