On Wed, Nov 13, 2024 at 01:39:43PM -0500, David Benjamin wrote: > > Not to say that every implementor would have noticed every issue (I'm sure > I overlooked some issues too), but I think DTLS's biggest challenge has > always been the relatively little attention it receives compared to TLS.
- When can the server drop epoch 2 (handshake) receive keys? Suppose client 2nd flight makes it through, but the ACK is lost. This causes the client to re-transmit the flight. The re-transmission happens with epoch 2. So the server needs epoch 2 receive keys in order to ACK the re-transmit. And this ACK could get lost as well. So the server needs to keep epoch 2 receive keys until client considers its 2nd flight complete. However, the server does not seem to have means to determine when this has happened. If the server did not send CertificateRequest, then NewSessionTicket is unordered w.r.t. client 2nd flight. And even if the server did send CR, then NST is not considered implicit ACK for client 2nd flight. Is there some prohibition on client sending post-handshake messages before considering handshake complete? If no, one can't use PS messges as an indicator, and the client might not send PS messages anyway. - Single epoch, multiple prepare for next epoch messages. What does it mean for a single epoch to contain multiple messages that prepare for the next epoch? Does that prepare one epoch or multiple epochs? Doing multiple might cause issues with epoch reconstruction. AFAICT, sending multiple KeyUpdates in one epoch is not forbidden (the spec requires ACK, not actual epoch bump in between). And in future extensions, there might be more message types that prepare epoch bumps (e.g., some Extended Key Update messages). The interactions between those (and regular KeyUpdate) might not be simple. I think there should be requirement that in each epoch, there is at most one message that prepares for the next epoch, and that all application data epoch except the last have exactly one. And with restriction that retransmissions must occur on the same epoch (why is that there for post-handshake messages?), the message that prepares for the next epoch must always be the last in its flight. > This is exacerbated by the kinds of things we need attention on. While the > security, cryptography, and handshake bits (this WG's forte), more-or-less > carry over as-is, it picks up a whole mess of transport-related concerns > that just don't apply to TLS. I remember that when developing HTTP/2, the HTTP WG people had a joint session with Transport Area folks about transport aspects of the protocol. HTTP/2 does not need to deal with loss or reordering. > And then there's also a wide range of possible implementations, depending > on the simplifying assumptions you make (e.g. refusing to have multiple > outgoing post-handshake flights active at once). That, in turn, means that > a reader might not have bothered thinking about the more complex case, if > they didn't mean to implement it. (On my end, I don't expect we'll > implement everything in here either!) And even if some case is implemented, it might still be subtly broken (or completely broken if it is not actually used). E.g., Long time ago, I saw a TLS client with totally broken KeyUpdate handling. And this was MTI feature. Or subtle issues in ACK implementation exposing endpoint to DoS or being abused as an amplifier. > While I think this WG's analysis (formal and otherwises) are mostly on > security properties, the issues I found are mostly making sure the protocol > can make forward progress under packet loss/reordering. But also whether > the text sufficiently defines the protocol at all. For example, it's quite > common for DTLS implementations to take these simplifying assumptions, but > all that actually needs to be written down as allowed behavior, because it > means that, when we analyze the protocol, receivers must accommodate a > sender that, say, artificially block sending one flight on the ACK of > another one. And then there is stuff that works only because senders are being conservative, not because protocol requires it. E.g., server that fragments from multiple messages at once (I don't see anything prohibiting that), and client that does not implement full out- of-order receive buffering (I don't see anything requiring that). Guaranteed deadlock in handshake, even with zero packet loss or reordering. > The remedy for all that is, well, more eyes on it, which we get by having > the WG take on a bis document. :-) Beyond that, whether we need > implementers, formal analysis, or just people reading and reasoning through > the draft, I think we just welcome anyone who is interested in doing that > work and go forth. All three sources of feedback ultimately involve a human > reading the document and trying to understand what it's trying to say > anyway, which I think is the biggest gap here. Once we even know what our > protocol is, if there are folks available to model that and formally check > a forward-progress property (rather than a security property), awesome! If > not, we can resort to traditional "think very hard about it" techniques. I > don't think we need to preemptively worry about which options we'll have > available when we get there. There is also semi-formal reasoning. While not even close to actual formal check, it is big step up from just thinking very hard about it. And then, then there are possible future extensions to TLS that interact with this somehow. For example, a new message that updates keys. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
