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 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
