Re: [TLS] Additional TLS 1.3 results from Chrome

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 19 December 2017 14:19 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 80958126DFE for <tls@ietfa.amsl.com>; Tue, 19 Dec 2017 06:19:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 pdqhzrMBLxlJ for <tls@ietfa.amsl.com>; Tue, 19 Dec 2017 06:19:46 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0341201F8 for <tls@ietf.org>; Tue, 19 Dec 2017 06:19:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F071BE51; Tue, 19 Dec 2017 14:19:43 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP9iPbNIGn6X; Tue, 19 Dec 2017 14:19:43 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12450BE39; Tue, 19 Dec 2017 14:19:43 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513693183; bh=bgHw+JK/dWqa/kbz9Y38pBdt1Azr73wLHk0Z5FPjMZ4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OlxzNpqj/ZZ42HfkaGukN2leM7BlhtSI+1fBHyvRMjy3SF9YfHmLxfEeU0Tf4BhQS R3aJ8GwuS/4SDnrG3Io6JnwZs6bIXvHSmgDaLor2XYL3McWQ4xVI8Eu29iZR4nsABI t45rvtJEV3VdTzzwNJCEKTdc9bLOhSsOduy9UKX8=
To: "Salz, Rich" <rsalz@akamai.com>, Eric Rescorla <ekr@rtfm.com>, David Benjamin <davidben@chromium.org>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CAF8qwaA4su2j-Lh9XRcLbT_Tysg9H24ys=TCC=Rd1bvrFNds7A@mail.gmail.com> <CABcZeBN9ABRSY76NWfqy5QouVE9BJR78nwExNGe-bXsnn1GkmA@mail.gmail.com> <68370EF8-8F21-435C-98F0-D621D142C629@akamai.com> <2da50a0b-4b28-35fc-fe32-44a4afff9f4f@cs.tcd.ie> <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d8bce966-6ba6-eb29-6ac7-d65bd854c1a4@cs.tcd.ie>
Date: Tue, 19 Dec 2017 14:19:41 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <6720AF4C-390C-4197-921D-33B7BD9AB679@akamai.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MJUMaqTNM441VTGNESV04Qwvx3QUAVNH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qfCf1uKnIXe4jFRrUTxbnIkL9Ew>
Subject: Re: [TLS] Additional TLS 1.3 results from Chrome
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: Tue, 19 Dec 2017 14:19:48 -0000

Hiya,

On 19/12/17 13:56, Salz, Rich wrote:
> “dropped as a bad idea” is an interesting end-state.  Also “on hold
> for now” (which is how I want to see the TLS-breaking proposals).
> 
> Having more I-D workflow options seems like something the IESG should
> take up.
> 

Well, TBH I doubt it'd be best done from the IESG down.

If some WG wanted to pursue this kind of thing, I'd say
it'd be much better done by the WG and then the IESG
could get to decide what they think if/when such a draft
is ever put forward by the WG for publication as an RFC.

And for most WGs, there's little danger in expired I-Ds
hanging about unchanged. For TLS, as we've seen in this
case, there might be a downside to the expired I-D not
containing text saying: "Don't do this! Really. And
<here's> why." :-)

As an aside, I'd say it'd be better to not think of
this as a retraction, but more as a case of ensuring
that the public record, as seen in the I-D repository,
better reflects the WG consensus, for the few cases
where there would be a concrete reason to not want
people to write or deploy code implementing the draft
concerned.

For a WG draft, the WG itself can always decide that
the right thing to happen is to publish a tombstone
draft, so that could be handled easily enough.

For a draft that's proposed for WG adoption, or that's
discussed but not adopted, it might get complicated, if
the authors don't agree that WG non-adoption is a good
reason to put out a tombstone. (We'd likely need the WG
to adopt the draft solely to put out the tombstone,
which'd be a bit weird.)

So as I said, I'm about half-convinced:-)

Cheers,
S.