Hi Colm, thanks for your review.
I disagree with your assessment in a few places. First, talk about tickets and point out that distributing the session key for encrypting the ticket content (Session Ticket Encryption Keys (STEKs)) is a challenge and raises security concerns. You point to Akamai CDN and their huge number of hosts. The TLS 1.3 ticket concept combines three types of tickets approaches standardized for earlier versions of TLS, namely session resumption (which caches keys on both sides), and RFC 5077, which allows you to use self-contained tokens aka tickets in the style of Kerberos tickets. Finally, you could use RFC 5077 with references to tickets but you loose the stateless nature (since you have to write keys, and other necessary parameters in a database). Which approach is best depends on your infrastructure. When you use TLS in your environment you need to make a few decisions about the algorithms you want to support, key lengths, etc. You also have to determine what ticket concept you want. Maybe the right decision for a deployment that has to synchronize STEKs across so many hosts isn't a great idea. Second, you talk about 0-RTT and replay attacks. In a 0-RTT exchange you cannot rely on the nonce exchange for replay protection (as it was done in earlier TLS versions). Instead, you have to rely on other replay protection mechanisms, and taking the application semantic into account is obvious approach. Clearly 0-RTT is not applicable to all environments and hence the spec contains a warning: "Protocols MUST NOT use 0-RTT data without a profile that defines its use." What I could, however, imagine is to add either in the TLS handshake or at the application layer something like a timestamp or a sequence number so that the server-side can check for replays. This is what has been done with other security protocols in the past. Is the TLS layer the right place or the application layer? Hard to say. Minor issues: You also suggest that 0-RTT supports PFS. The definition of PFS unfortunately is not super helpful here when there are so many keys in play. The PFS definition talks about the loss of the long-term key. What you care about is the potential loss of the STEKs, which is not a long-term key. You write: "Any client that attempts to use a ticket multiple times will also likely leak the obfuscated_ticket_age value, which is intended to be secret." The obfuscated_ticket_age is not secret - it is sent in the clear. What is supposed to be kept confidential is the ticket age. I have been wondering myself what the privacy value of the obfuscated_ticket_age, and the ticket age is and I am still not convinced that it provides much benefit. Ciao Hannes PS: You talk about OATH in this paragraph: " To avoid simple spoofing risks, many such systems perform throttling post-authentication. For example the request may be signed cryptographically (see the AWS SIGv4 signing protocol or the OATH signing process), that signature is verified prior to throttling. This post-authentication property is one reason why such protocols are designed to be extremely fast to verify, which often means as much cryptography as possible must be pre-computed, making random nonces infeasible in many cases. " What you actually mean is OAuth (OATH is a different effort also related to earlier IETF work on one-time-passwords). Your reference points to an old OAuth specification that has been replaced by OAuth 2.0, which does not use the same application layer signing anymore. On 05/02/2017 04:44 PM, Colm MacCárthaigh 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 > <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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
