Re: [TLS] Comments on PR #95

[Eric Rescorla <[e-mail]>]

Thanks again for the detailed comments.



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.


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



> 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.
>

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.


Line 418: Security means what exactly?
>

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


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?
>

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



> 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.
>

Agreed.



> 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.
>

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


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.
>

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



> Lines 1066-1072: We've got a perfectly good nonce in the sequence
> 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).


> 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.
>

Can you elaborate more on why you think that?


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.
>

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



> 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.
>

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.


> Line 1623: We're getting to the beef. But the reader already knows
> 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.


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.
>

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



> Line 1863: Previously, hello extensions were relegated to a different
> 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


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.
>

Agreed. I think we should remove SRP support.



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

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




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.
>

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.


Does ignoring an update still update the record layer?
>

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
> protocol.
>

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.


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

I'd certainly welcome contributions here.


Line 3606: Do we need the glossary?
>

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



> 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.
>

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


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.
>

I'd welcome contributions here.

-Ekr

>
>