On Thu, May 4, 2017 at 3:00 PM, Erik Nygren <erik+i...@nygren.org> wrote:
> On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> >> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekr...@fb.com> wrote: >> >>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, >>> explaining both session-cache and strike register styles and the merits of >>> each. >>> >>> >>> >>> First, a point of clarification, I think two issues have been conflated >>> in this long thread: >>> >>> 1) Servers rejecting replayed 0-RTT data (using a single use session >>> cache/strike register/replay cache/some other method) >>> >>> >>> >>> There are definitely cases (i.e. application profiles) where this should >>> be done. I think a general case HTTPS server is one. But I don’t think this >>> is strictly necessary across the board (for every application using 0-RTT >>> at all). DNS was brought up earlier in this thread as an example of a >>> protocol that is likely quite workable without extra measures to prevent >>> replay. >>> >>> >>> >>> We already state “Protocols MUST NOT use 0-RTT data without a profile >>> that defines its use.”. We could also describe methods that may be used to >>> provide further replay protection. But I don’t think it’s appropriate to >>> make a blanket requirement that *all* application protocols should require >>> it. >>> >>> >>> >>> I also consider it quite misleading to say TLS 1.3 is insecure without >>> such a recommendation. Uses of TLS can be insecure, that does not mean the >>> protocol itself is. It’s insecure to use TLS without properly >>> authenticating the server. Some users of TLS do not do this correctly. I’d >>> actually argue that it is easier to mess this up than it is to mess up a >>> 0-RTT deployment (and it can result in worse consequences). That doesn’t >>> mean we should require a particular method of authentication, for all uses >>> of TLS. >>> >> >> I think this is basically right. In the PR I just posted, I spent most of >> my time describing the >> mechanisms and used a SHOULD-level requirement to do one of the >> mechanisms. >> I think there's a bunch of room to wordsmith the requirement. Perhaps we >> say: >> >> - You can't do 0-RTT without an application profile >> - Absent the application profile saying otherwise you SHOULD/MUST do one >> of these mitigations? >> > > I generally agree with Kyle here (and also added a few minor comments to > the PR). > I think we should be clear where the responsibilities generally lie as > well, for example: > > "The onus is on clients not to send messages in 0-RTT data which are not > safe to have replayed and which they would not be willing to retry across > multiple 1-RTT connections. The onus is on servers to protect themselves > against attacks employing 0-RTT data replication." > > The server responsibility is a general property TLS can maintain while the > client responsibility requires an application profile to define. > These seem like good changes. I will work to incorporate them. -Ekr > > Erik > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
