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? 2) Preventing clients from sending 0-RTT data multiple times (on separate > connections) using the same PSK (for forward secrecy reasons) > > > > I think this should be allowed. Otherwise, clients will not be able to > retry 0-RTT requests that fail due to an unknown network error prior to > receiving a NST (if they are out of cached PSKs). I’d expect the need for > these retries to be larger with 0-RTT data, particularly when 0-RTT data is > sent without even a transport roundtrip (in the case of TFO or QUIC). > Servers are definitely not required to accept multiple 0-RTT connections > using the same PSK, but I don’t think clients should be banned from > attempting. > I agree, and the PR I provided doesn't attempt to do so. > 4. I would add to this that we recommend that proxy/CDN implementations > signal which data is 0-RTT and which is 1-RTT to the back-end (this was in > Colm's original message). > > > > I’m not sure that the TLS 1.3 spec is the right place to make > recommendations for this. I can see several reasonable approaches here, for > example: > > - Adding some kind of application level annotation (for example an HTTP > header) > > - Robustly preventing replay on the 0-RTT hop > > - Sending proxied early data with a different TLS ContentType, etc. > > I don’t see a need to specifically endorse any particular method here. > I think Colm has also agreed we shouldn't do this and it's not in my PR. > > > > There was also a point brought up about the use of ticket_age without > 0-RTT. I’m not aware of any use for ticket_age other than 0-RTT replay > protection. I believe that ticket_age is sent with all PSKs mostly out of > convenience/consistency. I don’t really have an objection to the current > method, but I also wouldn’t be opposed to moving the ticket age to the > early data extension, so that it is only sent along with 0-RTT data. > I would be OK with this as well. It does seem slightly more elegant. > It also seems a little under-specified what implementations unable to > compute a reasonable ticket age should send (for example in the case of a > device without a real time clock, > Right. I have been basically assuming that you can't really do TLS without a real-time clock, but maybe that's wrong? > or with an external PSK). > This actually is well-specified (though maybe wrong) "For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value." https://tlswg.github.io/tls13-spec/#pre-shared-key-extension -Ekr > *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, May 3, 2017 11:13 PM > *To:* Colm MacCárthaigh <c...@allcosts.net> > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Security review of TLS1.3 0-RTT > > > > [Deliberately responding to the OP rather than to anyone in particular] > > > > Hi folks, > > > > I'm seeing a lot of back and forth about general philosophy and the > > wisdom of 0-RTT but I think it would be useful if we focused on what > > changes, if any, we need to make to the draft. > > > > I made some proposals yesterday > > (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23088.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=XgHbUwT6upAsOin4T6P8ePs8i0ZFsnD-_BNvueeq83E&e=> > ). > > > > Specifically: > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining > > both session-cache and strike register styles and the merits of each. > > > > 2. Document 0-RTT greasing in draft-ietf-tls-grease > > > > 3. Adopt PR#448 (or some variant) so that session-id style implementations > > provide PFS. > > > > 4. I would add to this that we recommend that proxy/CDN implementations > > signal which data is 0-RTT and which is 1-RTT to the back-end (this was in > > Colm's original message). > > > > Based on Colm's response, I think these largely hits the points he made > > in his original message. > > > > There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. > > What would be most helpful to me as Editor would be if people could review > > these PRs and/or suggest other specific changes that we should make > > to the document. > > > > Thanks, > > -Ekr > > > > > > > > > > On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > > On Sunday at the TLS:DIV workshop I presented a summary of findings of a > security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n. > Thanks to feedback in the room I've now tightened up the findings from the > review and posted them as an issue on the draft GitHub repo: > > > > https://github.com/tlswg/tls13-spec/issues/1001 > > > > I'll summarize the summary: Naturally the focus was on forward secrecy and > replay. On forward secrecy the main finding was that it's not necessary to > trade off Forward Secrecy and 0-RTT. A single-use session cache can provide > it, and with the modification that ekr has created in > https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for > both pre-auth and post-auth tickets, and it allows clients to build up > pools of meaningfully distinct tickets. > > > > There's also an observation there that it should really be that clients > "MUST" use tickets only once. Any re-use likely discloses the obfuscated > ticket age, which is intended to be secret. Right now it's a "SHOULD". > > > > On replay, the main finding is that what's in the draft is not workably > secure, and the review includes 5 different attacks against 0-RTT data to > illustrate that. Attacks 1 and 2 show that the kind of replay permitted by > the draft is very different from the kind of replay permitted by dkg's > existing downgrade-and-retry attack. I also go over why it very very > difficult to many applications to achieve that idempotency, and why one > idempotency pattern actually relies on non-replayable messages. > > > > Attack 3 shows that idempotency is not sufficient, applications must also > be free of measurable side-effects, which is not practical. Attack 4 shows > that 0-RTT breaks a common security mechanism: spoofing-resistant > throttles. Attack 5 shows that 0-RTT replay-ability enables an additional > form of traffic analysis. > > > > The recommendation in the review is that implementations "MUST" prevent > replays of 0-RTT section, with some additional discussion about why the > existing advice is unlikely to be followed, and why consistent > interoperability matters here. > > > > Unfortunately, I wasn't aware until Friday that this review would be > coming so late in the TLD1.3 draft process, and my apologies for that. I am > now planning to attend the future WG in-person meetings and look forward to > seeing many of you there. > > > > -- > > Colm > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0&s=6GIocGzW6wPK4EAlqDLIirNvsuQj7gWhYG_OzROR2qY&e=> > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
