On Tue, May 2, 2017 at 8:17 PM, Eric Rescorla <e...@rtfm.com> wrote: > Colm, > > Thanks for your review. Interesting stuff. >
Thanks too for taking the time to read it. > Scrolling ahead to the recommendations, I see you have: > > * Require implementations to robustly prevent Ticket re-use for 0-RTT. > > This seems like a good idea. I think it's arguable that we got a bit > nihilistic about this, and as you say, you can do a pretty good job of > reducing replay within a given data center using some local > anti-replay mechanism. I would tend to think that a strong SHOULD is > what you want here, as a MUST is going to be a lot more like a 6919 > MUST (BUT WE KNOW YOU WON'T). > A provider choosing to allow replays to their own applications is on them, they can own the stack top to bottom, take the risk, have a response team handle attack events, etc ... That's a legitimate case for "SHOULD", there are exceptions to everything. But at the same time, what I think we should care most about is the interoperability case. So for example, if a TLS library, a web server, or an upstream CDN, can break the assumptions of a down-stream service or application, that's where we'll see CVEs cropping up. In those cases, I think the problem is the upstream component, breaking long-held and fair assumptions. In those cases, it feels like a "MUST". I'm not sure how to strike a balance, so chose the more secure option. > I understand from your document and our previous conversation that you > believe single-use tokens are easier to implement on the server side, > but I'm not sure I really follow your argument. If you want to provide > some short text on that that we can all agree on, then I think we > could incorporate this as well. > It's probably not important to get into a single-use token cache in the draft itself. That was just intended for implementors. One thing that makes a single-use cache slightly easier to implement is that reads and writes to keys need not be sequenced relative to any kind of checkpoint. With a strike register, some kind of checkpoint process is needed. A simple one is to start with a clean slate, accept only writes for a time period equivalent to the replay window, and then go read-write. But that kind of modality is, I think, required. With a single-use cache, it need only sequence the reads and writes to individual keys. Though it must store much much more state, so there are different trade-offs to consider. > * Partial mitigation for Gilmor attacks: deliberately duplicate 0-RTT > data > > This seems like some sort of extra-grease, but I'm kinda skeptical > that anyone is going to do it. Perhaps it would be useful to add it to > draft-ietf-tls-grease? > Grease is a good place for it for sure. > * Require TLS proxies to operate 0-RTT transitively > > I've read this several times but I have to admit I don't understand > it. Do you think you could rephrase? > What's in the draft is that there should be an application profile and that TLS implementations should provide applications with special functions to tell apart the early and regular data. The problem is that doesn't work with TLS proxies (like CDNs) ... because the proxies are re-combulating the data as a single stream to the origin. So the origin can't tell which data was replayable. If 0-RTT replay is tolerated, I think that's a big gnarly problem leading to CVEs. If we prevent replay by other means, like the strike register, it's not so big a deal. What I was suggesting was that such proxies always send an outgoing 0-RTT section to the origin that exactly lines up with the 0-RTT section that came in on the front end. It's quite hard to make that all work; the CDN would have to accept 0-RTT only if the origin also does. But I can't see another way that really works, especially for Layer 4 accelerators. Again, if 0-RTT replay is forbidden, not nearly as big a deal. > The following doesn't appear in your recommendations, but I think you > also think we should: > > * Adopt something like PR#998 to make each PSK_id correspond to a > different PSK even when they are issued on the same connection. > Big +1 to this. > For the reasons Viktor indicated, I tend to think this is inadvisable. > I've been thinking more about this. What if tickets are single-use when used with 0-RTT, but otherwise allowed for multiple uses? If that's acceptable, then could we drop the age from tickets purely used for resumption. That way the age would only appear on tickets that are used once. I think that way we get everything. * Remove ticket_age > > This doesn't seem like a good idea: if you are implementing a strike > register, you want to use ticket_age to help distinguish "fresh" from > "unknown state". I.e., the ticket_age + the ticket issue time allows > you to determine approximately when a CH was sent, and any CH that > is significantly older or newer than now is forced back into 1-RTT. > Yep, I was wrong about this, I get it now, and that makes sense. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
