On Tue, Oct 31, 2017 at 10:45 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> (From https://github.com/tlswg/dtls13-spec/issues/25) > > Using the TLS process for KeyUpdate - as the current draft does - > leads to a suboptimal set of choices in implementations. > > Sending KeyUpdate followed immediately by a key change means that > KeyUpdate isn't a reliable indicator of a key change at the receiver. > If the record containing the KeyUpdate is lost, then the receiver will > be unable to decrypt anything sent after it unless it looks at the > epoch and tries the new keys. It's important to be clear that this creates head-of-line blocking, not deadlock. The sender will retransmit the KeyUpdate eventually. And (though it's not in the document), the sender could also retransmit the packet itself. Given the comparative rarity of KeyUpdates, I don't actually think either of these is disastrous. I would prefer a different design, even if it diverges from the TLS design. > > 1. That could be the same design as QUIC uses, with the epoch bit > signaling intent. The cost there is that you need to use the bit as an > acknowledgment of a key update, so you end up having to keep key > updates in lock step, even if no update is needed. If there are > asymmetric sending patterns, this isn't ideal. > Yeah, I don't think this is a good design in QUIC and I wouldn't be in favor of it here. We've gone to some trouble to have explicit updates in DTLS and this is far cleaner than the situation in QUIC, and I'm not eager to make a change in the opposite direction. > 2. Wait until the KeyUpdate is acknowledged before installing new > keys. When KeyUpdate is received, the receiver installs new keys, but > retains old keys on a timer (the holddown timer would do). This is already required by the spec and would be needed in any case. > The sender > waits for the ACK and starts using new keys when it sees it. The cost > here is that switching keys can't be immediate True, but that logic only happens at the sender. > and it requires hooks > into the ACK handling logic, neither of which is ideal > As above, I'm not persuaded that this change is necessary, given that DTLS is inherently a lossy protocol, and that receivers *can* be clever, but if the resolution is that it is, then I think this is the right approach. -Ekr > I have implemented the former and it's a little ugly, but I haven't > tried the latter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
