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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 19 February 2018 20:32 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4FB1205D3; Mon, 19 Feb 2018 12:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO9MgDFuOQ-X; Mon, 19 Feb 2018 12:32:21 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C8C1200B9; Mon, 19 Feb 2018 12:32:21 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id 17so2579134pfw.11; Mon, 19 Feb 2018 12:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ny09NFf8KpOBog/u/Ae4r8927O+Ruf8xjde755gc4+w=; b=g0y1MwINxbyxC3x7RYaehSf3SwXzX9M46gkMBiX7IdGBmTyThxzpew0/Q4upUpU+zq +HDUwJtPwzfHqhYCnAAgo7n7ZjVeMwwa30k95KC1YCPyjMyDEhSWrOqfxjh+fUkeeaO2 dj9Tm3VdUm/eABwZPEH8eXNHaHplBLejfNkzfA+suHu0kqT6TU5TllCxDyPsU08oCS9n 2CsZ8OJpo3r79MzHo7Rcv8dj/zh1Zg0YJ1NwaKcuNLcVxcrCIZ2UscKT/dTSQ84aaY4J 67xSnG9VtHN4tgt2ioZ8Yhzef6GJ17SUWtOaBUVoEyrYNGXTKi7aPe6O8k0yxE6qGSjP VgSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ny09NFf8KpOBog/u/Ae4r8927O+Ruf8xjde755gc4+w=; b=Pns1YBDHrr0MSOp4193erKsG/gZbqau/o91gRkECtfjTh31U+XTZP+opMjaLd/fZJQ H6puRquMj0bzgTtnWoTuD5bpEczpS3vbI7MKviyCmDuIIVWRdcK2rAp0PwOYvfqAsvrO EjJ5ghzmwByXANZVQmE6CcNZu5VR4/Zvgn9KDe1NCh/8bPiFfpYA3V8Hw6GnZWj04KdN 1ZdrCXQHiO+AuJPakXcEsiZyu9WukghrCFSGX9uYdOe1lEdjb4RXgMDa7UVQi+CIppXk pg1VydjZVK5OnHZGLQi4jim0UMMkyUB/0k1DUz+SKwn6W5GwEDzaUfDxKgo37xwcnD3f tKOg==
X-Gm-Message-State: APf1xPC+MXDzjJSjhy5JHItqRHxTFVpheKE2mjk0+HfE/V0nJSfEmrhv SDHHqcQBlbEnqPCf7LMLUDK+DS8OYjNcpOBkkiA=
X-Google-Smtp-Source: AH8x2246mvIp4Gn36WwQ6bZ6iZ9w3NwbjwR9I+xUIxjvNCst1dpL/sZ+100HH5OlbRlPBn6PADrcvfQtIpzBeHCvXR8=
X-Received: by 10.99.111.130 with SMTP id k124mr4944302pgc.236.1519072341239; Mon, 19 Feb 2018 12:32:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.229.67 with HTTP; Mon, 19 Feb 2018 12:31:40 -0800 (PST)
In-Reply-To: <20180219194957.GL54688@kduck.kaduk.org>
References: <CAHbuEH45PYDuhwFPhv-ybDY6LyzsBhfdEwhJPFLQg9b+ndNK9w@mail.gmail.com> <CAAF6GDdsHW4ynWm15cMgL3BRkJw5xFshhQVO3S47MQD8fVMMag@mail.gmail.com> <20180219194957.GL54688@kduck.kaduk.org>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 19 Feb 2018 15:31:40 -0500
Message-ID: <CAHbuEH719ywfXnYwZUoFJcOq3eq+NgYk_x6jJAy_8OTVCsD-hg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Colm MacCárthaigh <colm@allcosts.net>, "tls@ietf.org" <tls@ietf.org>, "draft-ietf-tls-tls13@ietf.org" <draft-ietf-tls-tls13@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YSOMXBM0BdCcBy5mePmQ74mnXBw>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 20:32:24 -0000

On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 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.

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.

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

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.

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

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
>
> -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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen