First of all, I think that this is pretty good work. I've implemented a version of DTLS 1.3 that you might assume based on the TLS 1.3 drafts and this is much better in several ways.
The explicit ACK is nice, but I REALLY like the epoch management stuff, when I implemented it, it made things a lot easier all around. The big open item here is that the record format is grossly wasteful. Hannes and I have been discussing this offline and I have a sketch of a plan that should maintain compatibility but it will shave off 9 octets per record. We might be able to drop two more if we are willing to send more packets during the handshake. (Note that the draft seems to not do the content-type encryption, we'd fix that at the same time.) Nits: As in TLS, implementations MUST either abandon an association or re- key using a KeyUpdate message prior to allowing the sequence number to wrap. You also forbid use of KeyUpdate, which I think is the best answer. I wouldn't mark key_update as reserved though, lest IANA take that as an instruction somehow :) (Don't fix this, but why is fragment_length a uint24? You can't put that much data into a single record!) Figure 10 shows an arrow that spits off the middle of another line. That arrow isn't labelled. I can't see how to interpret that, nor conceive of what might belong there. Figure 10 should also switch from "last flight" to "ACK" (in two places). The change summary should reference TLS 1.3 for changes between TLS 1.2 and 1.3. It should talk about changes that are relevant to DTLS: the change of cookie handling, the change in record layout, the addition of an explicit ACK, and the handling of key updates. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
