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

Benjamin Kaduk <bkaduk@akamai.com> Thu, 03 May 2018 12:54 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 0EC36126C83 for <tls@ietfa.amsl.com>; Thu, 3 May 2018 05:54:15 -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 Qw5Y4XVJTrqw for <tls@ietfa.amsl.com>; Thu, 3 May 2018 05:54:14 -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 CC9301204DA for <tls@ietf.org>; Thu, 3 May 2018 05:54:13 -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 w43CqZrf028704 for <tls@ietf.org>; Thu, 3 May 2018 13:54:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=aAFR9rvZLxyqwhhI/+KILHyLeFwxYMXKz6dwa2sDVCM=; b=J/1OmRnh3KZKVnG5zTYf9lz5XJmoCpSFRK2f4NqZCv1dlcjG16gq00FBFVAIRGM2JD6k PLEgd1O+TGai12vOui8HVUO/TeZaQ0vWzysFltlckW0/u2YKPdLp36Dl59Y2RnwM93N2 0lwkvgat04WTFMzWrK7p+ftLWCv/scI7AkHqjf1h3/sMko+bC71szd1XLcsMBFX4de5F IVa9N2wLX2SoH9+cfDOJdkJn3Wk83djy0b1//HyD5KsZDInp05YSsixu1f8QT1zPfAGz drQk/Lyo10WPj5zEFNogViMv/rAS38Xb0kDSy3ISfFmn3HL8Vgmq2vSSM6f8uIy2q/wo bw==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2hqyfp8dmy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Thu, 03 May 2018 13:54:12 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w43CkgEg017520 for <tls@ietf.org>; Thu, 3 May 2018 08:54:12 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hmm9wkbhd-1 for <tls@ietf.org>; Thu, 03 May 2018 08:54:12 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 121DC81FA2 for <tls@ietf.org>; Thu, 3 May 2018 12:54:12 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fEDkR-0005Mw-6X for tls@ietf.org; Thu, 03 May 2018 07:54:11 -0500
Date: Thu, 03 May 2018 07:54:11 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: TLS WG <tls@ietf.org>
Message-ID: <20180503125410.GL5742@akamai.com>
References: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org> <CAHPuVdV+qhC=jS-JEoS6ig6ofRXV__VLOmSL=6c=3_vJK-zCpQ@mail.gmail.com> <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org>
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=806 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030115
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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=777 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030116
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/t7NJ3yI53pD0qmDeGD6kL1q9wTo>
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:54:15 -0000

On Sat, Apr 28, 2018 at 01:40:25PM -0400, Viktor Dukhovni wrote:
> 
> 
> We may yet have to see how much support or opposition the follow-on
> document will meet.  What continues to be puzzling is resistance to
> adding a field that imposes negligible burden on the present spec,
> and would clearly be included in the follow-on extension.  It might

It is not puzzling to me, for two reasons:

(1) fairly early on, the proposal was framed as something that might be
obtained from "good faith in return", which can be interpreted as the
sort of "horse trading" that many IETFers have a visceral objection to.
It is hard to erase this memory when considering subsequent discussions.

(2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority
that the 16-bit value (in hours) is sufficient, and no other fields or
semantic changes would be needed.  While I (and presumably others) do have
a great deal of confidence in your collective technical expertise, it still
seems to be presumptuous and a coopting of the WG consensus process for the
follow-up pinning document.

> well be the only thing that's in the follow-on extension, and so
> provisioning space for it has a strong chance of simplifying the
> burden on future implementations that would need only implement code
> for just one extension structure instead of two.  Worst-case we have
> two reserved bytes in the current extension.

The above notwithstanding, I'm not sure that I can dispute this worst case
assessment, at present.  (Presumably "egg on our collective faces" doesn't
really count.)

-Ben