Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13

Colm MacCárthaigh <colm@allcosts.net> Sun, 14 January 2018 22:41 UTC

Return-Path: <colm@allcosts.net>
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 56A7E12D882 for <tls@ietfa.amsl.com>; Sun, 14 Jan 2018 14:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 QquK42F-UyhL for <tls@ietfa.amsl.com>; Sun, 14 Jan 2018 14:41:47 -0800 (PST)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 E299E12D890 for <tls@ietf.org>; Sun, 14 Jan 2018 14:41:46 -0800 (PST)
Received: by mail-yb0-x22e.google.com with SMTP id h62so3753711ybi.11 for <tls@ietf.org>; Sun, 14 Jan 2018 14:41:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H0ICI05lvj7HtI08N2FaKXsW4OxlOugFRTrT6e2y7wU=; b=OYnOm8LQ3mBa/3dGKki/X1ze4OxW1uwEFUVLVRKxrNvWqFdkiOhTT30kwXPJQiJA5g NUUUd/pfZXnGl8aB2AXoBwUh4MaaEbx5KSffRv6l1sVcNZv+nkXJ46PmEG40DobyR/sK VsY2TNTFxtxIexbIGl0Hu/DQGJJVRfT8PW21EmeZg4cO6I2oJH0tBtfyw9N6j7FkNgdC c77SOIcU2oMfUdlga7yESOlUzWzbM4lVTIIVM6Mwz2KTjRp8lx+Y4fEM5ODuLAyY461J qs5gO4gE++u9DdEFBUp6Ec/saXVv/7mS/aBRhztoXky/s+zHfUprAW0DXFSFvZs0CLcm XkFw==
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; bh=H0ICI05lvj7HtI08N2FaKXsW4OxlOugFRTrT6e2y7wU=; b=AKLqRzIdilW+PBdgHKWJKcgyOjxBZF/ha//7+v+/ynEbVOZQU+BpZl5eps1my40LTT ggfn/6aHwlH+LOfUWiqPBmW7iP899rBuAH/EqpIuOrPd/8iRtzNmcO96+FDZvS2AfRss nkesfsmftr75OTqW3h0UZ9W/nWE0eA/Zg83wSskTZgI3cPp1steWMKaG6GQhw5yIMVVu HTwU6CE5MuwZuKkZ204rx46IXTHfgCNVm1WKF9I2v0beX6y00BvbetlU4aqyjdaG19jY lANf7AmUzPpso839o/knJCeiSPFDh+BXzHmnKOh/vC6JsDHvNBgf4umc6eGu69MTdTPg PwPw==
X-Gm-Message-State: AKGB3mIk7pNwZxktyQN7cBem6dvX0JVFR9++G57vtTsgOEeLBpjceWvv vcxTNVRSR0g5lWtAF4ppmyAVDPeqTpdCj/yLzjk1xg==
X-Google-Smtp-Source: ACJfBotGUq6EWO/Mg5RaJZvvGKy2oORAXzRZmUQURRRMrpc3cIGzjbfd39vPKPOhVFy1yGaDXiwXdSqb7rCxqP1rCi0=
X-Received: by 10.37.10.65 with SMTP id 62mr30548978ybk.300.1515969706005; Sun, 14 Jan 2018 14:41:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.42.6 with HTTP; Sun, 14 Jan 2018 14:41:45 -0800 (PST)
In-Reply-To: <CABcZeBP9LJtB_3=VB2h_T-EhVmximSTYh47RO1aXq-BABqZoUQ@mail.gmail.com>
References: <DE3D47D0-140B-45FF-8B25-BD3675886613@sn3rd.com> <CAAF6GDePwzJBHcuELUHwccfi3r7VyakQcnjeoBYoR-WgYX=8qA@mail.gmail.com> <CABcZeBP9LJtB_3=VB2h_T-EhVmximSTYh47RO1aXq-BABqZoUQ@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Sun, 14 Jan 2018 23:41:45 +0100
Message-ID: <CAAF6GDf9stivfDM=PrtXaAQxU-99MfN=fMuGYoBy5SRf6wisQA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113db54ad127b60562c4335d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2c7iMC9dLj3nXgMiIy7MSnxGLKA>
Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13
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: Sun, 14 Jan 2018 22:41:49 -0000

Thanks for the abundant generosity of patience, but I didn't mean that I
wanted to add a note to the text of the I-D, there's been enough delay and
I'm excited to see this progress. I just meant "add a note" in my e-mail
;-) Though I do like your terse note, it's right to the point.

On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Hi Colm,
>
> Thanks for your note. This seems straightforward to handle before IETF-LC.
>
> Maybe something like:
> "Note: many application layer protocols implicitly assume that replays are
> handled at lower levels. Tailure to observe these precautions may exposes
> your application to serious risks which are difficult to assess without a
> thorough top-to-bottom analysis of the application stack"?
>
> -Ekr
>
>
> On Sun, Jan 14, 2018 at 12:15 PM, Colm MacCárthaigh <colm@allcosts.net>
> wrote:
>
>>
>> Back during the previous last call, I felt really guilty about bringing
>> up the 0-RTT stuff so late. Even though it turned out that middle boxes
>> turned out to be a bigger problem to deal with anyway, I just want to say
>> that I'm really grateful for the 0-RTT related changes in the document and
>> for the time and effort that went into all that. I think those changes are
>> sufficient to make a TLS1.3 implementation that handles 0-RTT in a
>> forward-secret, secure and safe way. The changes represent a good
>> compromise between having a secure state and supporting vendors who want to
>> be a bit more loose because their application environment can tolerate it
>> and forward secrecy is not as valuable to their users. Thanks especially to
>> ekr for inventing the fixes, for stewarding the clarifications, and for
>> being awesome about it.
>>
>> At the same time, I just want to add a small note of caution to vendors;
>> if you're going to accept 0-RTT, trying to cut corners by tolerating
>> replays - even a little, is really likely to bite you! I've found even more
>> examples of application protocols and web protocols that implement
>> transactions. Also, if the secrecy of trillions and trillions of users web
>> requests are going to rest on how well session ticket encryption keys are
>> managed, protected, rotated and revoked, we really owe it to users to come
>> up with some collective guidance for vendors on how to do that well.
>>
>>
>> On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner <sean@sn3rd.com> wrote:
>>
>>> All,
>>>
>>> This is the 3rd working group last call (WGLC) announcement for
>>> draft-ietf-tls-tls13; it will run through January 26th.  This time the WGLC
>>> is for version -23 (https://datatracker.ietf.org/
>>> doc/draft-ietf-tls-tls13/).  This WGLC is a targeted WGLC because it
>>> only address changes introduced since the 2nd WGLC on version -21, i.e.,
>>> changes introduced in versions -22 and -23.  Note that the editor has
>>> kindly included a change log in s1.2 and the datatracker can also produce
>>> diffs (https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-tls13-21&u
>>> rl2=draft-ietf-tls-tls13-23).  In general, we are considering all other
>>> material to have WG consensus, so only critical issues should be raised
>>> about that material at this time.
>>>
>>> Cheers,
>>>
>>> spt
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>>
>> --
>> Colm
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>


-- 
Colm