Re: [TLS] TLS@IETF100: Agenda Requests

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 05 November 2017 14:13 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 97FCD13F920 for <tls@ietfa.amsl.com>; Sun, 5 Nov 2017 06:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=0.001] 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 p7Bn3js2Sk1O for <tls@ietfa.amsl.com>; Sun, 5 Nov 2017 06:13:29 -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 5E70713AF75 for <tls@ietf.org>; Sun, 5 Nov 2017 06:13:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 271B1BDD8; Sun, 5 Nov 2017 14:13:26 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 gw17c0e6uCqs; Sun, 5 Nov 2017 14:13:21 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CF984BE24; Sun, 5 Nov 2017 14:13:20 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509891201; bh=mZhCoVbVzGyZmUk/lJfFulMyahEkHMoBuCXOfnrBB2o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rC5o+2jIC6Zu2gZOpBY8oK6aCyEwrQz+/+Q139j0Z0KIX9CjblHE69OAaRW0pz0+x KlJsg0if4IBmfNNN3JR0qGSq2QAfzMunrv60hReVcvwaKxuq9eu4cCFfEqPGZ8f0Zn 5NwrUD/0Iplrz6EdB/Gm4mEYT94pFJtJctGm8/dc=
To: Ted Lemon <mellon@fugue.com>, "Salz, Rich" <rsalz@akamai.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <FE182172-D69A-4451-B77B-CCD78B3AEFD1@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <efe6b92e-ab1b-aa58-e328-e4ccd11b1ecc@nomountain.net> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> <CAPt1N1kx-9OsRADLm_1LDi9K3cjku0d-iVL-7yqTcs8KBWewKQ@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <78b3fc21-b9f2-5081-c1ee-268edbeccb53@cs.tcd.ie>
Date: Sun, 05 Nov 2017 14:13:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAPt1N1kx-9OsRADLm_1LDi9K3cjku0d-iVL-7yqTcs8KBWewKQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="j0ojNVc5BscI6WwTOLLBQ949msEWbGhLn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Vp-CPQMkGrhkLw7ym1Amw4KtYGQ>
Subject: Re: [TLS] TLS@IETF100: Agenda Requests
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, 05 Nov 2017 14:13:31 -0000

Hiya,

On 05/11/17 13:09, Ted Lemon wrote:
> Consensus isn't about number of votes. However, I think we can say that
> although there seems to be some interest in making sure this use case is
> addressed, there are known ways of addressing it, and little interest in
> inventing a new way that weakens a new feature of tls 1.3

Don't disagree. In addition there's always been folks in the
rough when it comes to any security BCP or similar and ISTM
that the breaking-TLS case is no different - there'll always
be people who (mistakenly IMO) perceive that it'd be better
to break TLS (and prioritise their particular concern) than
it is do our best to improve Internet security and privacy
overall. (That's one reason the chairs' question in Prague
wasn't a good one - it will always be the case that there are
IETFers who do want to break TLS and similar - we learned
nothing from that hum at all.)

As a meta-comment, I think it's really a pity that most or
all such break-TLS proposals appear to be accompanied (not
necessarily from draft authors) by bad argument, overstatement
and ignoring the existence of downsides. (*) IMO that is yet
another indicator that those arguing to break TLS know that
they're likely to end up in the rough and hence at tempted
to attempt the "hard-sell" (as you Ted I think called it,
perhaps too generously) which is I think disruptive to WG
progress.

So I'd argue to not bother discussing this bad idea again at
IETF-100 - it's consumed enough cycles already and we won't
learn anything at all if we do waste time in that way yet
again.

S.

(*) I fully admit to meeting such bad argument with robust
argument and will continue doing so:-)

> 
> On Nov 5, 2017 14:03, "Salz, Rich" <rsalz@akamai.com> wrote:
> 
>> So if the only people in favor of it are the draft authors, then we have
>> consensus, right?
>>
>>
>>
>> _______________________________________________
>> 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
>