The doc says that it is maintained at https://github.com/tlswg/dtls13-spec This is untrue (currently). I found it at https://github.com/hannestschofenig/tschofenig-ids
Speaking of which, it would be really nice if there were an issue tracker that we could use for this. I hope that the working group adopts this an moves it to this location so that I don't have to dump issues in an email. Issues in email get lost. I realize that we're going to look carefully at the packet format and probably streamline the record structure a little. ekr has my analysis on this, which I'm happy to share. The diagrams in Section 5.5 talk about discrete flights, which makes sense when talking about the handshake, but once it starts, application data can be continuously exchanged. That's a detail that might be lost. Retransmissions of handshake messages use new record sequence numbers (though the handshake sequence number stays the same). This really isn't dealt with prominently enough to my mind. It's important that repacketization doesn't produce a two-time pad. The effect of processing packets independently isn't given proper treatment in security considerations. In TLS, when a packet doesn't decrypt, the connection dies, so an attacker has to start over if they want to probe the decryption oracle. In DTLS, packets that don't decrypt just get dropped, which gives an attacker a huge advantage. I believe that the rekeying design needs a little better description. This is what I've implemented and what I think the intent is: * if you want to update, just send with the next epoch * if you see the other side update, and you haven't already, update yourself * don't update until you see that the other side has used the current epoch That's also what QUIC currently uses. With this design, you can reduce the epoch bits to 2 during the handshake and 1 afterwards, if you care about saving bits. The draft is says this, which I can't really parse: Upon receiving a payload with such a new epoch value, the receiver MUST update their receiving keys and if they have not already updated their sending state up to or past the then current receiving generation MUST send messages with the new epoch value prior to sending any other messages. I really don't understand the "prior to sending any other messages" part. Is this right? Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a "unexpected_message" alert. For example, client incorrectly uses epoch value 5 when sending early application data in a 0-RTT exchange. A server will not be able to compute the appropriate keys and will therefore have to respond with an alert. It seems like that is in violation of the "drop if you can't decrypt it" rule. I wonder how many implementations do this: However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again NSS certainly doesn't. Section 5.5.2 mentions re-handshake. That's not possible any more. Probably best to use NewSessionTicket or post-handshake client authentication as the example here. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
