Re: [TLS] review comments on draft-rescorla-tls-dtls13-01

[Hannes Tschofenig <[e-mail]>]

Hi Ben,

thanks for the review.

On 03/29/2017 04:25 AM, Kaduk, Ben wrote:
> A few things I noticed while reading the draft to prepare for today’s
> session:
> 
> We talk in a couple places about datagram protocols being
> “vulnerable” or “susceptible” to DoS attacks, which leads me to at
> least partially read that as meaning that the protocol’s own service
> will be disrupted; as we know, this is not the whole story, as the
> reflection/amplification part can facilitate DoS attacks targeted at
> other services/networks.  So perhaps some rewording is in order.

I created an issue https://github.com/ekr/dtls13-spec/issues/18 to take
this into account.

Note, however, that the DDoS attacks from last year had nothing to do
with this protocol design issue. If you control a large number of
endpoints then you can flood networks and servers with messages.

> 
> We should catch up to the ClientHello1 being included in the
> transcript hash as the synthetic message_hash message, so the full
> transcript of it need not be stored in the HelloRetryRequest.
> 
Yes, the most recent version of the TLS spec talks about this issue and
we need to take it into account.

> On page 20, second paragraph, please be clear that it is the
> message_seq vs. the record sequence_number that must match
> next_receive_seq.

Yes, one has to read carefully in order not to miss this fine
distinction. We will try to improve the text.

> 
> I also made a note of the different key update behavior of this draft
> vs. draft-ietf-tls-tls13-19, with the epoch change and lockstep
> rekeying between peers.  That was in the presentation as well, but I
> haven’t had my thoughts settle into which flavor I prefer, yet,
> though the explicit KeyUpdate does have some advantages.

In practice, I believe the KeyUpdate message will not be used too often.
We nevertheless have to figure out whether the loss of functionality
(which I believe is minimal) is worth using a separate message. By
moving to the implicit rekeying feature (in comparison to the explicit
KeyUpdate message) we loose the ability to give the other party the
option to decide whether they also want to update their keys.
I personally don't see this as a big issue.

Ciao
Hannes

> 
> -Ben
> 
> _______________________________________________ TLS mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>