Re: [TLS] Precluding bilateral opt-in for downgrade protection.

Benjamin Kaduk <bkaduk@akamai.com> Thu, 03 May 2018 12:42 UTC

Return-Path: <bkaduk@akamai.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 CEC8512426E for <tls@ietfa.amsl.com>; Thu, 3 May 2018 05:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 4SdEsP6j-rEu for <tls@ietfa.amsl.com>; Thu, 3 May 2018 05:42:16 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4211204DA for <tls@ietf.org>; Thu, 3 May 2018 05:42:16 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w43CSAog009667; Thu, 3 May 2018 13:42:15 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=H6x1YiSr1jPwVhaNKWay7BUOVB+gLy8ePJwYHQmQbdo=; b=b+MiF72/pqKYXxhjAHZavujkX23hdD33OLc4daqb0/8gC+SRfMWYVRjG13TRYbqRh5qj em1sEUWTTOffVJICTKwZV1tGsqQIii3TP5+uPpNgiG5twix5r3BQpnaUWqP9eWBo4kty VPVRpkCJj1YCOayvAugLxvKz2B9TxZYgElpZ/LZJmdxbIaNgLHctOULm9Ci5Kn1yJ5WD F3gBBI/Awfdo5GoO42Js95RUFyfMp3tQHGE7uQL66Xjgu25HJzd8u7vznBxncCMr59gS TttTRYZ804aRliNy/9QBk6W1Xqc/CZvQT97I6O4B1Oapcjrb4mBbBRLGieDyaaBxxXG9 Kg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2hqyfp8cuj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 13:42:14 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w43CflZQ009674; Thu, 3 May 2018 08:42:13 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2hr1anr8qq-1; Thu, 03 May 2018 08:42:13 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 6028C27E2F; Thu, 3 May 2018 12:42:13 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fEDYq-0005Lf-Ph; Thu, 03 May 2018 07:42:12 -0500
Date: Thu, 03 May 2018 07:42:12 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Paul Wouters <paul@nohats.ca>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20180503124212.GK5742@akamai.com>
References: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org> <CAHPuVdV+qhC=jS-JEoS6ig6ofRXV__VLOmSL=6c=3_vJK-zCpQ@mail.gmail.com> <alpine.LRH.2.21.1804281435500.11560@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.21.1804281435500.11560@bofh.nohats.ca>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030114
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030113
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k1MlWyKVmo7NGODwsgklD3vKbdQ>
Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection.
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: Thu, 03 May 2018 12:42:18 -0000

On Sat, Apr 28, 2018 at 03:01:34PM -0400, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
> 
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
> 
> >First, there is no agreement that your reason for doing pinning,
> >i.e. that DANE needs downgrade resistance against PKIX attacks
> >is even valid.
> 
> This is incorrect. From the replies to the consensus call on the list,
> it actually weights in favour of _some_ kind of downgrade resistance.
> 
> In fact, it worries me that the consensus call outcome seems to come
> from non-public voices and not from a tally of those participants on
> the TLS list.

Given that this mail is framed as just a process comment, and even though you
rightly refer to "technical merits" in a later (trimmed) portion, I must
object to the use of "tally of those participants on the TLS list".
"Tallying participants" implies counting votes, but of course the person
making the consensus call is charged with using their technical judgment to
assess the replies received on the merits.

-Ben