Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd like to boil down what I think are the nits and risks with 0-RTT, and if others want to weigh in they can. I'll state my own position at the bottom.
Broadly, I think there are three issues with 0-RTT:
1) The TLS 1.3 draft allows for 0-RTT data, including things like requests and headers, to be replayed by attackers.
2) 0-RTT data, again including requests and headers, has no cryptographic guarantee of forward-secrecy and will likely be protected by symmetric session ticket encryption keys (STEK) that can be used quite broadly with no limits on re-use, rotation, and rely on vendors being able to share and revoke keys frequently and securely. Basically: If a vendors STEK is compromised, than an unbounded number of end-user requests and headers can be decrypted. This obviously defeats the goal of achieving forward secrecy.
3) While no working attack has been found, some cryptographers and protocol experts believe that the 0-RTT exchange is overly-complex and a source of risk. Kenny Paterson made the most prominent statement ( http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html ), but I've heard it echoed at several IACR events. It is definitely true that 0-RTT resumption complicates the TLS state machine and creates unusual conditions such as needing to restart messaging sequences.
The TLS-WG was chartered with "aiming for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes. The aim is also to maintain current security features" (https://datatracker.ietf.org/wg/tls/charter/). But with these 3 issues, there is a clearly a trade-off between security (the S in TLS) and speed.
Issue 3 is matter of judgment; my personal judgement is that we will see implementation bugs due to state machine complexity, but there's no evidence that the cryptographic and protocol semantics are not robust.
With regards to issues 1, and 2, the latest TLS draft makes it possible to achieve both of these aims. Through the use of single-use session tickets, it is possible to provide anti-replay and forward-secrecy properties for 0-RTT data. I'm grateful for the changes that were introduced for this.
At the same time though, most vendors have stated that they don't plan to do that and instead have designed around limited replay time windows, non-transactional strike registers, and non-forward secure tickets. This is what I expect to see deployed, and already see with some TLS1.3 deployment experiments. TLS1.3 could be more restrictive here; limiting the size of session tickets to smaller than the size of session state would effectively forbid any kind of session encoding which would force the issue, but several vendors are against it because it doesn't align with current practices and it incurs the cost of server-size caching. For balance, in the last year I have heard from most vendors that they do plan to implement some anti-replay mitigation though, beyond the simple time-windowing, which goes a way to protecting users from throttle limits.
I am disappointed by the unfortunate preference for cost-saving over robust security. Good cryptography usually costs money, or else we'd still be using RC4. I do think that we will see security and correctness issues due to replays interacting with non-idempotent services and throttling configurations. While it's true that browsers can be made to replay requests already, there are many web and non-HTTP services that are certainly not tolerant of replays. Secondly, I think that it is inevitable that vendor security compromises will disclose troves of user requests, passwords, credit cards to decryption; but this is perhaps more of a nation-state-adversary level risk. Some more detail on attacks related to issues 1/ and 2/ is available in the security review of 0-RTT data: https://github.com/tlswg/tls13-spec/issues/1001 .
After all of that, here's my own position:
I strongly support the current TLS1.3 draft progressing to RFC status. I work at Amazon, where one of our leadership principles is "Disagree and Commit" (https://www.amazon.jobs/principles); the idea is that it's important to make yourself heard, but also to move forward and not be endlessly bogged down. I've been vocal about 0-RTT risks, and certainly heard and understood, and those concerns have been reflected in generous changes to the draft. I'm happy that it's possible to build a forward-secret, non-repayable 0-RTT implementation and that's what I'm doing. I wish everyone else would too, but that's not consensus; others have a different weighting for the trade-offs between speed, security and cost and those views are also legitimate.
But my more important reason for supporting is that overall TLS1.3 is much much better than TLS1.2, including in regards to forward-secrecy, which is now guaranteed for all non-0RTT data. I still believe that it will meaningfully increase the overall security posture for the internet, and I'm super excited to get it out and for users to be getting the benefits. TLS has always been a bit of a mess, it's not as clean as something designed by a single voice focused on modern cryptographic best-practices, but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things can't be improved further, and delay inflicts 1.2 and lower versions on users for even longer. So let's go!
On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote:
Dear Yuhong,
As the sponsoring Area Director, my job is to take the draft forward
as was determined by working group consensus. Like Stephen, I'm also
not particularly happy about the choice to leave in 0-RTT, but I have
to support it as a WG decision. Whatever the version number in the
ServerHello decision is from the WG, I will support that decision.
The ServerHello decision doesn't really fall into the, "arms race" as
you put it. More on that in another thread.
Best regards,
Kathleen
On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_386@xxxxxxxxxxx> wrote:
> I wonder what is IESG's opinion on the TLS arms race with middleboxes.
> Yes, I am talking about moving the version number in the ServerHello.
>
> ________________________________________ > Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
> From: TLS <tls-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx>
> Sent: Thursday, February 15, 2018 1:13:48 PM
> To: IETF-Announce
> Cc: draft-ietf-tls-tls13@xxxxxxxx; tls-chairs@xxxxxxxx; tls@xxxxxxxx
-->
>
> The IESG has received a request from the Transport Layer Security WG (tls) to
> consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
> <draft-ietf-tls-tls13-24.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2018-03-01. Exceptionally, comments may be
> sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document specifies version 1.3 of the Transport Layer Security
> (TLS) protocol. TLS allows client/server applications to communicate
> over the Internet in a way that is designed to prevent eavesdropping,
> tampering, and message forgery.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ ballot/
>
> The following IPR Declarations may be related to this I-D:
>
> https://datatracker.ietf.org/ipr/2900/
>
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls
Best regards,
Kathleen
Colm
