On Fri, Jun 2, 2017 at 2:25 PM, Eric Rescorla <e...@rtfm.com> wrote: > > Sure. For the sake of clarify, I'm going to suggest we call: > > - replay == the attacker re-sends the data with no interaction > with the client > - retransmission == the client re-sends (possibly with some slight > changes) >
O.k., cool. > 7. With the current design, clients have no way of knowing what, if any, > anti-replay mechanisms the servers are using. Thus, they cannot be > sure that servers are ensuring at-most-once semantics for the 0-RTT > data (at-most-twice if the client retransmits in response to 0-RTT > failure) [0]. This makes it difficult for clients to know what is > safe to send in 0-RTT. > > 8. The more broadly distributed the information required to process > a session ticket (on the server), the worse the FS situation is, > with session tickets encrypted under long-lived keys being the > worst. > > I note that you suggest separating out 0-RTT tickets and resumption > tickets, but I don't actually see how that changes matters. As Ilari > notes, it is possible to say that a ticket cannot be used for 0-RTT > and if you have a ticket which can be used for resumption globally > but for 0-RTT at just one site, the server can implement that policy > unilaterally. > Yep, that's right, and should work. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
