Re: [TLS] Draft minutes for TLS at IETF 108

Benjamin Kaduk <bkaduk@akamai.com> Tue, 11 August 2020 17:06 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 60E9E3A0809; Tue, 11 Aug 2020 10:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 g_eHYco_gvBd; Tue, 11 Aug 2020 10:06:08 -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 AF0CC3A0805; Tue, 11 Aug 2020 10:06:08 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07BH4Xw2004745; Tue, 11 Aug 2020 18:06:03 +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=uKEsSKxx7oOCyFfjJPOqBwPqODH/a6Dhzq2S369GQJc=; b=k49spMO+c5Og2GXfwkEgoIjgab0h917slVhArgYgJwKpP+d0BwZFrl+u29Dl2TRW2bGS th5Fz4RrdUtZTccV30B1BPZifncGCPacD2pT2iYGnbrdFdU2MFtX0YHsCY0D3HH3km6s a5V4RpAIUqXdXJ5esgaAwh5J3ZjiW/F1vIDBFZY1oHA8X7CxK/x2ADAAW1m34E4eL+1n INXN49Z40Nwu2Mu1+hq9m7CLVTgAWn18yTFXDREShF7qqSRQSSzXqg3N066ZkrB6PPn9 3/g0MacJywRc2Lc0u29TsK8ikjKuixa/wnHLFryJzS6/olfnSwL3WX0VeUgJ+tTC9NMq Ig==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 32smfc2t78-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2020 18:06:03 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07BH54in024881; Tue, 11 Aug 2020 13:06:03 -0400
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 32sqcy0nga-1; Tue, 11 Aug 2020 13:06:03 -0400
Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 690873B92F; Tue, 11 Aug 2020 17:06:02 +0000 (GMT)
Date: Tue, 11 Aug 2020 10:06:01 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: tom petch <ietfc@btconnect.com>
Cc: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <TLS@ietf.org>, TLS Chairs <tls-chairs@ietf.org>
Message-ID: <20200811170601.GH20623@akamai.com>
References: <7f7f3878-446c-4f95-9cdd-cde6bb955134@www.fastmail.com> <c8e841ec-1bbf-412b-bb3c-ee8ecc4f1adb@www.fastmail.com> <AM7PR07MB624877C5210063BC88E692EBA04B0@AM7PR07MB6248.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AM7PR07MB624877C5210063BC88E692EBA04B0@AM7PR07MB6248.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-11_15:2020-08-11, 2020-08-11 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=790 spamscore=0 malwarescore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008110119
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-11_15:2020-08-11, 2020-08-11 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 mlxscore=0 bulkscore=0 clxscore=1011 phishscore=0 adultscore=0 mlxlogscore=710 priorityscore=1501 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008110119
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tQXUqT9Pg_KZZAxKawVlZN9jHas>
Subject: Re: [TLS] Draft minutes for TLS at IETF 108
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Aug 2020 17:06:10 -0000

On Wed, Aug 05, 2020 at 10:30:39AM +0000, tom petch wrote:
> From: TLS <tls-bounces@ietf.org> on behalf of Christopher Wood <caw@heapingbits.net>
> Sent: 04 August 2020 19:16
> 
> The official minutes are now up:
> 
>    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e= 
> 
> <tp>
> What is Benjamin talking about at the end?
> 
> It looks as if you are proposing action on all or some RFC that have TLS 1.0 or 1.1 as MTI, related to oldversions-deprecate but that is a guess from reading between the lines and that topic is a live one for me so I would appreciate clarity.

oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or
1.1 as MTI (there are some 80-odd documents in the Updates: header).  The
particular itesm I was mentioning in the meeting relate to various subsets of
those documents that may need some additional handling on top of the basic
"don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content
of the updates.  Details are at https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/
So:

- RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the
  document as a whole should be historic

- The downgrade-detection SCSV of RFC 7507 is probably in a similar boat

- We should be more clear about "if the document being updated says you
  MUST use TLS 1.0/1.1, that part is removed"

- No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers
  are no longer considered very good)

Were there additional specific items you were unsure about?

-Ben