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@gmail.com> 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@hotmail.com>
> 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.
> >
> > ________________________________________
> > From: TLS <tls-bounces@ietf.org> on behalf of The IESG <
> iesg-secretary@ietf.org>
> > Sent: Thursday, February 15, 2018 1:13:48 PM
> > To: IETF-Announce
> > Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org
> > Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport
> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
> >
> >
> > 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@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may
> be
> > sent to iesg@ietf.org 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> Best regards,
> Kathleen
>
>


-- 
Colm