Hi Ben, thanks for your remark. I don't think that this is an issue in DTLS since the epoch field provides additional information to properly select the correct key.
Ciao Hannes On 04/20/2017 04:34 PM, Benjamin Kaduk wrote: > On 04/20/2017 01:22 AM, Hannes Tschofenig wrote: >> >> On 04/19/2017 07:07 PM, Mark Dunn wrote: >>> >>> I understand an HRR cookie should cause an extra round trip, but in this >>> case because of >>> "DTLS servers SHOULD perform a cookie exchange whenever a new >>> handshake is being performed" >>> And >>> "Early data is not permitted after HelloRetryRequest." >>> This results in 2-RTT as the default case, is this what you intended? >> This is a very good observation. I added an issue to the tracker about >> this question: >> https://github.com/tlswg/tls13-spec/issues/972 >> >> It would be good to have a justification for this restriction and it >> would be worthwhile to re-consider it in the DTLS specification since >> the use of HRRs will be common with connection-less transport protocols. > > Note that we currently document sending HRR as a way for a server to > reject early data without having to do trial decryption to determine the > end of early data (since the outer content-type is meaningful for the > ClientHello2). I expect there will be some situations where servers do > not want to implement trial decryption, so removing this functionality > without replacement seems ill-advised. > > -Ben
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
