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

Hi Colm,

On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote:
> 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.

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

> Broadly, I think there are three issues with 0-RTT:
> 
[...]
> 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

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.

> 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.
> 
[...]
> 
> 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!

Well said!

-Benjamin

> 
> 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