Hi, > It's not necessarily the case that you would end up with an insecure protocol > in this case.
One should rather ask: Is it necessarily the case that you would still end up with a secure protocol, and if so, why. I don't see an attack either, but I think the binding of epochs to keys is fundamental to DTLS, and if there's danger of violating it, this may well be worth pointing out. For example, is it obvious enough that there cannot be any risk to early data confidentiality if a non-conforming client sends two batches of 0-RTT after its first and second ClientHello, both with epoch 1 but with different keys? Unless this can be ruled out easily, I think it would be worth adding an explicit reminder and/or entry in the "Implementation pitfalls" section. Cheers, Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
