Re: [TLS] Comments on PR #95

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>