Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

"Holland, Jake" <jholland@akamai.com> Thu, 18 June 2020 18:08 UTC

Return-Path: <jholland@akamai.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5B3A0DC3; Thu, 18 Jun 2020 11:08:26 -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 qCDQ4A3XTpu6; Thu, 18 Jun 2020 11:08:25 -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 69D0B3A0DC5; Thu, 18 Jun 2020 11:08:25 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05II87ML005419; Thu, 18 Jun 2020 19:08:24 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wyFVBcW+8F0IaOFl0t9Lbqi1ByM6XbOsqExgEjbS6EQ=; b=QfBKlHcjnGzHFdInD35g2KhIuEIfWbPRuHwPgqRqNSYGd3ZHsorugZTpdiuSAuvA58ND uwNQrV8tx4PWwMukOZdfQmQB0Nf+EVTTJSLQOd8jHilRra3f7WRUuKpOcnFTkp7k8S9Q MBKOqy0brGp2zkWpvExFtz0Gb0leH1nWSpUls3F2rPFbCXT8AUPThT+zsuPrww+6hmaB 0wMjSm4nTPVFCjqa3pc81ZZoH99XpjAK8GX3GyTlbd9fkRrX9CorOsd1QVgI8l+uQMre B5lHrmVU3SjMSosCZg5GxrjrUpRf/svh7PDYl/pSs0oKbu8brlFc64yEkvD6Crg+6VX6 3g==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31qre9fcap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 19:08:23 +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 05II5Rvq009377; Thu, 18 Jun 2020 14:08:23 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 31qjmbpnqg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 14:08:23 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 14:08:22 -0400
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.006; Thu, 18 Jun 2020 14:08:22 -0400
From: "Holland, Jake" <jholland@akamai.com>
To: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: int-area <int-area@ietf.org>, IETF SAAG <saag@ietf.org>
Thread-Topic: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Thread-Index: AdY9/kL5KQoLk/CbSKeZ9xMZ8uq3SAHhAr+A
Date: Thu, 18 Jun 2020 18:08:22 +0000
Message-ID: <504C4220-D120-45F4-9D51-8E48F63B0ACB@akamai.com>
References: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.93.179]
Content-Type: text/plain; charset="utf-8"
Content-ID: <42FCB9A54D705142894A67F95ADC2B53@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_15:2020-06-18, 2020-06-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180138
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_15:2020-06-18, 2020-06-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 adultscore=0 spamscore=0 cotscore=-2147483648 malwarescore=0 phishscore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180138
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RYzzDook1EmRCux9hF6hMD4J6zg>
Subject: Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 18:08:27 -0000

+1 on Kyle's remarks[1], and well-put.

IMO, this doc seems useful and should move forward as informational.

While I do also think a BCP would be great, since we're not there
yet an informational RFC articulating the points this one does is a
very welcome step forward and much better than nothing, IMO.

-Jake


PS: Also +1 to Paul Vixie's suggestion that the objections should
ideally be phrased as a pull request.  There's perhaps room for
some editorial improvements, but as it stands it's pretty readable,
and has some crucial information about the new challenges that
transport header encryption introduces to existing operational
practices.

So my +1 on objections-as-pull-request is because I'm not
understanding the tone or balance problems that were raised.  I
don't see what kinds of edits would address them outside of "stop
acknowledging that there are new challenges raised by transport
header encryption" or "add 14 pages duplicating info in the
referenced RFCs about why encryption is good".  Both of these seem
counterproductive to me, so absent a more specific set of productive
suggestions (ones that don't lose information about the new
operational challenges that are introduced by transport header
encryption), I am against stalling publication of this doc as an
RFC based on the objections raised so far.

[1] Kyle's remarks:
https://mailarchive.ietf.org/arch/msg/tsvwg/0UNJbELTHMw7xjV9SIXoavADK6g/