Re: [TLS] Comments on PR #95

[Watson Ladd <[e-mail]>]

On Tue, Dec 30, 2014 at 3:19 PM, Eric Rescorla <[e-mail]> wrote:
> Thanks again for the detailed comments.
>
>
>
<snip>
>>
>> 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?

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.

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

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"

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

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

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

You are right, and I was wrong.

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

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.

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

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
>> protocol.
>
>
> This is deliberate.

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.

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

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

Sincerely,
Watson Ladd
>
> -Ekr
>>
>>
>



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