Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Feb 2018 10:58:07 -0500

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 <[email-masked]> 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 <[email-masked]> on behalf of The IESG <[email-masked]>
> Sent: Thursday, February 15, 2018 1:13:48 PM
> To: IETF-Announce
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> [email-masked] mailing lists by 2018-03-01. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 

Best regards,
Kathleen

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 19 Feb 2018 11:13:44 -0800

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 <
[email-masked]> wrote:

> > Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport
> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
> >
> >

-- 
Colm

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Feb 2018 13:49:57 -0600

Hi Colm,

> others want to weigh in they can. I'll state my own position at the bottom.

Thanks for this summary and review; I think it's well-said.

> Broadly, I think there are three issues with 0-RTT:
[...]
> experiments.  TLS1.3 could be more restrictive here; limiting the size of

I don't disagree.  It might be helpful to have a conslidated list of
references for the vendor statements, so we can get a more clear
picture of where to set our expectations.  Though of course I do not
insist that you assemble one, and I do not want my comment to be
seen as detracting from your review overall.

> goes a way to protecting users from throttle limits.
[...]
> users for even longer. So let's go!

Well said!

-Benjamin

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Feb 2018 15:31:40 -0500

> Thanks for this summary and review; I think it's well-said.

Yes, agreed and  also thank you for your work on this important topic
to improve the security for 0-RTT and implementing the mitigation
techniques.

> seen as detracting from your review overall.

And this can and should be done separate from the draft publication
process.  I'm pretty sure that's what Ben intended as we don't want to
hold this up any more.

>> users for even longer. So let's go!

Agreed.  I didn't mean to kick off a new thread on this, I was just
using it as an example of where I'll uphold the WG decision and
support it fully in IESG discussions in my role as AD.

Thanks again for your and others work to improve the 0-RTT situation!

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Feb 2018 22:04:40 +0000

Just on the 0-RTT thing:

As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely
argued too btw.)

I do believe we'll live to regret 0-RTT when implementation
issues and unsuitable application uses emerge over time but
neither that nor general dislike of 0-RTT are IMO sufficient
reasons to hold TLS 1.3 at this point, given the benefits of
other aspects of TLS 1.3.

In addition, the fact of 0-RTT as an (in practice) unavoidable
part of TLS 1.3 and the implications of that were previously
raised with both the IESG and IAB in a fair amount of detail,
(about 1.5-2 years ago maybe but the issues are the same) and
IIRC at an IETF plenary as well, so this has been rehearsed
before the IETF already, even if not during a formal IETF LC.

Cheers,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 19 Feb 2018 17:58:32 -0500

Sent from my mobile device

> On Feb 19, 2018, at 5:04 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Just on the 0-RTT thing:
> 
+1 on all of the above.

> before the IETF already, even if not during a formal IETF LC.

Agreed.  

Thank you,
Kathleen 

> <0x7B172BEA.asc>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Feb 2018 19:47:52 -0600

> process.  I'm pretty sure that's what Ben intended as we don't want to

Right.

-Ben