From nobody Mon Jun 1 05:03:50 2020 Return-Path: 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 833D13A0FE7 for ; Mon, 1 Jun 2020 05:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 vFAyGdRjyw0a for ; Mon, 1 Jun 2020 05:03:42 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 EA11A3A0FE4 for ; Mon, 1 Jun 2020 05:03:42 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 051Bseh0029463; Mon, 1 Jun 2020 13:03:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ag01L/R2LX+urmXj7dvVvLH9iYJIzTsFB5lJCARrOuY=; b=O9Wn5f8kwJhqjtm6nJa4LWZZXCI243AltqlFuH4df+dW8AYblETvQlHIxxlM83hVNaZI O/jiX0qU+4z/RfxiLka0GE1hQzLq1DKLazF+eggeQdVUe9X8oICfPZ7EtHH+2q5x2qqD ip5SMXUYwrSRgTdMOQJKCJFecqmhUnTyh8FACtyTf+2OOKQ0VlE8aqcRScO6QZgw2NgC HNQz8mxlt3ILySQoNIel9kjPZTucLhtZOyXP7y4pd+QQ7DB4sByn6+sE/rAEhqTKM7AU P4CRSPOzancDB72dRg2/+mlnB9+Y+qaZpRd2yAW8PhFlE4a/dYmjstC/IgFvORPq8gfK mA== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 31bert0p0v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Jun 2020 13:03:42 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 051C2OnT028599; Mon, 1 Jun 2020 08:03:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint7.akamai.com with ESMTP id 31d18e80t4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Jun 2020 08:03:40 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 07:03:39 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Mon, 1 Jun 2020 07:03:39 -0500 From: "Salz, Rich" To: Joseph Salowey , "" Thread-Topic: [TLS] Working group last call for draft-ietf-tls-subcerts-07 Thread-Index: AQHWLU6MHLe6TA5NRUq6SQIDCjafn6jDmjiAgAA1TAA= Date: Mon, 1 Jun 2020 12:03:38 +0000 Message-ID: <631077AF-6A16-40EB-9CE4-E376EF83AE35@akamai.com> References: In-Reply-To: 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.43.132] Content-Type: multipart/alternative; boundary="_000_631077AF6A1640EB9CE4E376EF83AE35akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-01_07:2020-06-01, 2020-06-01 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=905 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006010090 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-01_07:2020-06-01, 2020-06-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 suspectscore=0 bulkscore=0 mlxlogscore=904 cotscore=-2147483648 priorityscore=1501 impostorscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 phishscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006010089 Archived-At: Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 12:03:47 -0000 --_000_631077AF6A1640EB9CE4E376EF83AE35akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZXJlYWQgdGhpcyBhbmQgc3VwcG9ydCBpdC4gIFdlIGFyZSBsb29raW5nIGF0IGltcGxlbWVu dGF0aW9uLiBXZeKAmXJlIGN1cmlvdXMgaWYgYW55b25lIGlzIHdvcmtpbmcgb24gYSBzdGFuZGFy ZCBmb3Igc2VydmVyL29yaWdpbiByZWNlcnRpZmljYXRpb24sIGV0Yy4NCg0KRnJvbTogSm9zZXBo IFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldD4NCkRhdGU6IE1vbmRheSwgSnVuZSAxLCAyMDIwIGF0 IDEyOjUzIEFNDQpUbzogInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbVExTXSBXb3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi10bHMtc3ViY2Vy dHMtMDcNCg0KUmVtaW5kZXI6IHRoZSBsYXN0IGNhbGwgZXhwaXJlcyB0aGlzIHdlZWsuDQoNCk9u IE1vbiwgTWF5IDE4LCAyMDIwIGF0IDEyOjU2IFBNIEpvc2VwaCBTYWxvd2V5IDxqb2VAc2Fsb3dl eS5uZXQ8bWFpbHRvOmpvZUBzYWxvd2V5Lm5ldD4+IHdyb3RlOg0KVGhpcyBpcyB0aGUgV29ya2lu ZyBHcm91cCBMYXN0IENhbGwgZm9yICJEZWxlZ2F0ZWQgQ3JlZGVudGlhbHMgZm9yIFRMUyIgYXZh aWxhYmxlIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxz LXN1YmNlcnRzLzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkR0bHMtMkRzdWJj ZXJ0c18mZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2 RnRzS0ktdyZtPU55S0tCUE13T2ZZNjNTQ1NobE9vVUhjQ1J2aElQbFhrQVdMWEJ0VTNneE0mcz15 WU9ZYWd3SVc4dldTSThra0U5ODJrejNfM3JoTHJxdUV0UlhSaUw5RHRVJmU9Pi4gIFBsZWFzZSBy ZXZpZXcgdGhlIGRvY3VtZW50IGFuZCByZXNwb25kIHRvIHRoZSBsaXN0IHdpdGggYW55IGNvbW1l bnRzIGJ5IEp1bmUgMiwgMjAyMC4NCkNoZWVycywNCg0KQ2hyaXMsIEpvZSAmIFNlYW4NCg== --_000_631077AF6A1640EB9CE4E376EF83AE35akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSByZXJlYWQgdGhpcyBhbmQgc3VwcG9ydCBpdC4mbmJzcDsgV2UgYXJl IGxvb2tpbmcgYXQgaW1wbGVtZW50YXRpb24uIFdl4oCZcmUgY3VyaW91cyBpZiBhbnlvbmUgaXMg d29ya2luZyBvbiBhIHN0YW5kYXJkIGZvciBzZXJ2ZXIvb3JpZ2luIHJlY2VydGlmaWNhdGlvbiwg ZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Sm9zZXBoIFNh bG93ZXkgJmx0O2pvZUBzYWxvd2V5Lm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBK dW5lIDEsIDIwMjAgYXQgMTI6NTMgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3Rsc0BpZXRmLm9y ZyZxdW90OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1RM U10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVtaW5kZXI6IHRoZSBsYXN0IGNhbGwgZXhwaXJlcyZuYnNwO3RoaXMgd2Vl ay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE1vbiwgTWF5IDE4LCAyMDIwIGF0IDEyOjU2IFBNIEpvc2VwaCBTYWxvd2V5ICZsdDs8YSBocmVm PSJtYWlsdG86am9lQHNhbG93ZXkubmV0Ij5qb2VAc2Fsb3dleS5uZXQ8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgaXMgdGhlIFdvcmtpbmcg R3JvdXAgTGFzdCBDYWxsIGZvciAmcXVvdDtEZWxlZ2F0ZWQgQ3JlZGVudGlhbHMgZm9yIFRMUyZx dW90OyBhdmFpbGFibGUgYXQmbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFm dC0yRGlldGYtMkR0bHMtMkRzdWJjZXJ0c18mYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1OeUtLQlBNd09m WTYzU0NTaGxPb1VIY0NSdmhJUGxYa0FXTFhCdFUzZ3hNJmFtcDtzPXlZT1lhZ3dJVzh2V1NJOGtr RTk4Mmt6M18zcmhMcnF1RXRSWFJpTDlEdFUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtc3ViY2VydHMvPC9hPi4m bmJzcDsNCiBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgcmVzcG9uZCB0byB0aGUgbGlz dCB3aXRoIGFueSBjb21tZW50cyBieSBKdW5lIDIsIDIwMjAuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8YnI+DQo8YnI+DQpDaHJpcywg Sm9lICZhbXA7IFNlYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_631077AF6A1640EB9CE4E376EF83AE35akamaicom_-- From nobody Mon Jun 1 12:41:58 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C83A11C7; Mon, 1 Jun 2020 12:41:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159104051676.18465.12498199656412028384@ietfa.amsl.com> Date: Mon, 01 Jun 2020 12:41:56 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-esni-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 19:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Encrypted Client Hello Authors : Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Filename : draft-ietf-tls-esni-07.txt Pages : 31 Date : 2020-06-01 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-esni-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 1 13:16:40 2020 Return-Path: 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 5E02B3A152E for ; Mon, 1 Jun 2020 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=DQb60JsO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FxII4f61 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 drCYlMDkA10Q for ; Mon, 1 Jun 2020 13:16:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EA73A152D for ; Mon, 1 Jun 2020 13:16:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3070F5C008D for ; Mon, 1 Jun 2020 16:16:37 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 01 Jun 2020 16:16:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=Q8CpN Lx2KPAxiHrlC87dKHljnwgtm+wfQU/OZE30fy8=; b=DQb60JsOAFwl0InmKeONo IDmjIbp4mXxyNAHCxCkSctY3qdA+E3O4uX0RICuSX8Q4pdAg+ZwtEqXxpwPp1KHJ bgZSBrw0BI6S0g27MUOtd5e2PpNLSmx3jRuMMLHX5VmQ7I22qf7febxKb+BkqZ9M AJh+6GkMyAmw+04n5xK+MBQeQuFSRUu6gSrIp3TnqwUbm+6wUbGz6in+tXvEO5ev JJgbHVPvR01DOYeBhZMLV/i7DH5/XgYO6T2iLbcWDNWVTXpkNerRq4/O9CRTOFd2 I5jGWKestQydVDeSm1RtdkTfze94+ZixpnQCLYKSFP0xMNDYdjCv2LwqlJat+cRl Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Q8CpNLx2KPAxiHrlC87dKHljnwgtm+wfQU/OZE30f y8=; b=FxII4f61TkddmW5IioSRNVJGyE8CZGoKw8PtHW9K3pCwWsRIvpBy/57Bo c492ae18bmsCWlYPFIQNcsEqN+aUWMeKTsL+PfL9ndCroXRR3V2jxI/4p4ZIStxS zc2+NIt28UVFea55eOLR8m/QQQmlixccOMF0zcj0T6Wvp6eM6jNNYeZNnW9BukMU mpp89ISc+s3t8+mJLgrgfKkY+g1lTXEiXW8qzHLShM7wFqwkMv1k00SHgo4JNxNv wNhQLnhir2WC8lHjnS2In4Azf0Cd5YLd5IPg636rNFia/Hvz5Kan8frXwZ9TFTPm 75is4jE8HNZxzKT6TT82FdGfr2NrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefhedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegt rgifsehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeekffekve eghffgtdffieevudfgledthefhfedvvdehleeivdegveegleefteejudenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinh hgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2A293C00A1; Mon, 1 Jun 2020 16:16:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <630127d8-3423-4afc-808a-e61165a76a26@www.fastmail.com> In-Reply-To: <730DE2CB-BD16-47B9-9729-B8D49615AB7B@gmail.com> References: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> <730DE2CB-BD16-47B9-9729-B8D49615AB7B@gmail.com> Date: Mon, 01 Jun 2020 13:15:37 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 1.3" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 20:16:39 -0000 On Sat, Apr 25, 2020, at 11:38 AM, Yoav Nir wrote: > See below. >=20 > I think the next thing to do is to get a signal from the working group= =20 > about whether we do or don=E2=80=99t want to allow unsolicited server = flags,=20 > because prohibiting it will require a significant change in the draft.= >=20 > I=E2=80=99m happy to make such a change, because I still can=E2=80=99t= come up with such a flag. Given that it's a deviation from the norm, and we don't have a compellin= g use case, I think we ought to make the change. If you have cycles, wou= ld you be willing to draft that change for review? > > On 23 Apr 2020, at 3:07, Martin Thomson wrote: > >=20 > > On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: > >>> Third, more substantially, and invalidating the above, I don't thi= nk that we should make flags introduce a new style of negotiation just b= ecause it can. I would strongly prefer that this function as close as p= ossible to "empty ClientHello extension; empty EncryptedExtensions exten= sion". Aside from that, the utility of an advertisement from the server= that a client cannot respond to is pretty marginal. > >>=20 > >> If this is what the group prefers, I=E2=80=99m fine with it, but th= en there=E2=80=99s=20 > >> never any point in sending an empty extension, either from the clie= nt=20 > >> of form the server. The absence of an individual flag is always imp= lied=20 > >> from the absence of the extension. > >=20 > > When you say "empty extension" here, do you mean "empty flags extens= ion" or are you speaking more generally? > >=20 > > If the server can't add flags, then I agree that having the client s= end an empty flags extension has little value. Same for the server send= ing an empty flags extension in that case. >=20 > I mean the flags extension. An empty extension conveys just that the=20= > sender supports the extension. An empty CH flags extension just says=20= > the client supports the flags extension. Unless the server is allowed=20= > to send unsolicited flags, an empty flags extension in CH does not=20 > convey any useful information. > >=20 > >>> Are we confident that sending the same extension in both places is= safe? I know that clients have to implement this and so should be able= to test that this works, but it seems awkward. And it might not be nec= essary. It's also not sufficient, as we currently allow responses to Cl= ientHello extensions to appear in Certificate (and for CertificateReques= t to carry "requests" in the other direction). > >>=20 > >> I don=E2=80=99t think the two extensions ever carry the same flags.= Each server=20 > >> side flag should be one of three: serverHello, encrpytedExtensions,= or=20 > >> neither (if we are not expecting a response) > >=20 > > So the intersection of flags in different responses must be zero? i= .e. flags[ServerHello] & flags[EncryptedExtensions] =3D=3D 0 (and the sa= me for any combination that we allow, including Certificate and NewSessi= onTicket, I guess). >=20 > I can=E2=80=99t think of any flag that will have a different meaning w= hen sent=20 > in SH or EE so that you might want to send both. Just in case, the fla= g=20 > registry should have a field similar to the extension registry which=20= > says where the field is valid. That seems reasonable, though I think restricting the flags to EE is pro= bably better. The possible cases for inclusion in SH (another KEX or KDF= algorithm?) seem like they can be handled by existing client extensions= .=20 Best, Chris (no hat) From nobody Mon Jun 1 21:24:49 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 737EA3A003E; Mon, 1 Jun 2020 21:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: joe@salowey.net, tls@ietf.org, kaduk@mit.edu, tls-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159107188638.28677.5407528328920253589@ietfa.amsl.com> Date: Mon, 01 Jun 2020 21:24:46 -0700 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 108 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 04:24:47 -0000 A new meeting session request has just been submitted by Joseph A. Salowey, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 120 Conflicts to Avoid: Chair Conflict: pearg git mls emu Technology Overlap: cfrg dprive dnsop lake Key Participant Conflict: quic httpbis taps secdispatch saag People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 1 22:16:21 2020 Return-Path: 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 04B8B3A07A6 for ; Mon, 1 Jun 2020 22:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 lJzy-QF28XRc for ; Mon, 1 Jun 2020 22:16:19 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 243433A079D for ; Mon, 1 Jun 2020 22:16:18 -0700 (PDT) Received: from xse39.mail2web.com ([66.113.196.39] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jfzHU-000tUI-3P for tls@ietf.org; Tue, 02 Jun 2020 07:16:15 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49bg4N6R4kz2bhc for ; Mon, 1 Jun 2020 22:06:28 -0700 (PDT) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jfz88-0000rI-Pe for tls@ietf.org; Mon, 01 Jun 2020 22:06:28 -0700 Received: (qmail 26395 invoked from network); 2 Jun 2020 05:06:28 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.176]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 05:06:28 -0000 To: tls@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Mon, 1 Jun 2020 22:06:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <159104051676.18465.12498199656412028384@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------3245572B0C16F87370477BF9" Content-Language: en-US X-Originating-IP: 66.113.196.39 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.39/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.39/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.01) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVc0fhsgZRfdlt aVbpzxKgcETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4YF7Ly8xhsfxcuNIIyzNabOgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efq6k/ICmf4myKtZN20xbt8wI6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZECoO4gCQkfvynnCsTu+Y7qysYn+2WmjiNmrC+0DLVCYuyVxP/304RoSHqErUyt3I93 abJVHw3Qw8OjNJfyX2HtIXHsfel69cEEEe/b1ZXJoKzNjLvclnGzlTC8ZgkR3laMWpHinwUZhktg Vr2pl68ECuf7H41/Wi1lr4jHJII6UV2jZAOanSBpz6Rja2u/0jLaReUYqr0ck5VjzIfw66ZLUUhQ mYkf0nCed5xLy2GgGU+FqboeKny9Q71ZpU7eHyLz67dSPlwMz53FR7kSGrDg7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 05:16:21 -0000 This is a multi-part message in MIME format. --------------3245572B0C16F87370477BF9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This draft looks really good. I just have two questions of clarification.= I am not sure that I understand the point made in appendix B, Total Client Hello Encryption. The text in that appendix explains that "The design described here only provides encryption for the SNI, but not for other extensions, such as ALPN." This seems to contradict the design description in the introduction, "The design in this document introduces a new extension, called Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server." Am I correct to assume that the text in appendix B is a leftover from the previous version of the draft? I am also not sure on how we could implement the "Optional Record Digests and Trial Decryption" methods described in section 10.3. The syntax description in section 5 specifies the record digest as "opaque record_digest<0..2^16-1>", and defines that field as containing "A cryptographic hash of the ECHConfig structure from which the ECH key was obtained". Would it be correct to implement the "optional record digest" method by just encoding a zero length field? -- Christian Huitema On 6/1/2020 12:41 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Transport Layer Security WG of the IET= F. > > Title : TLS Encrypted Client Hello > Authors : Eric Rescorla > Kazuho Oku > Nick Sullivan > Christopher A. Wood > Filename : draft-ietf-tls-esni-07.txt > Pages : 31 > Date : 2020-06-01 > > Abstract: > This document describes a mechanism in Transport Layer Security (TLS= ) > for encrypting a ClientHello message under a server public key. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-esni-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-esni-07 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------3245572B0C16F87370477BF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This draft looks really good. I just have two questions of clarification.

I am not sure that I understand the point made in appendix B, Total Client Hello Encryption. The text in that appendix explains that "The design described here only provides encryption for the SNI, but not for other extensions, such as ALPN." This seems to contradict the design description in the introduction, "The design in this document introduces a new extension, called Encrypted Client Hello (ECH), which allows clients to encrypt the entirety of their ClientHello to a supporting server." Am I correct to assume that the text in appendix B is a leftover from the previous version of the draft?

I am also not sure on how we could implement the "Optional Record Digests and Trial Decryption" methods described in section 10.3. The syntax description in section 5 specifies the record digest as "opaque record_digest<0..2^16-1>", and defines that field as containing "A cryptographic hash of the ECHConfig structure from which the ECH key was obtained". Would it be correct to implement the "optional record digest" method by just encoding a zero length field?

-- Christian Huitema

On 6/1/2020 12:41 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : TLS Encrypted Client Hello
        Authors         : Eric Rescorla
                          Kazuho Oku
                          Nick Sullivan
                          Christopher A. Wood
	Filename        : draft-ietf-tls-esni-07.txt
	Pages           : 31
	Date            : 2020-06-01

Abstract:
   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-esni-07
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------3245572B0C16F87370477BF9-- From nobody Tue Jun 2 05:44:33 2020 Return-Path: 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 1A6903A083B for ; Tue, 2 Jun 2020 05:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=kjKw++q8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mZWZUJUo 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 TceeSVKQxvd8 for ; Tue, 2 Jun 2020 05:44:29 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710803A083A for ; Tue, 2 Jun 2020 05:44:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C11B55C013C for ; Tue, 2 Jun 2020 08:44:28 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 02 Jun 2020 08:44:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=ybqEvALfEJ+XG2QW0t7COXBPx9Vlf52 pOP3wnLhBBGQ=; b=kjKw++q8sZJq0d0hBeKqE6RsyER7AgO6ffb0VAgzomwTnrs 5mN+kuKu4B3y+qNRWP2oNM1Luzm5gopL0U5MRYFvjenmlcxkPmXECRT8YofFFvC+ L3wWME+ThnYq8C9ii/VX7vdA6i1d18gjk3lVZWu5SPRXXzvX3Gg6/ucXRyRwWcyb 7YVdnqj7n7oZYU1s6rL0DbvDZDdYebyJ59IJIUc37ZPxIAKx0aG5zZC+Lu6JrYCr AbLf3KNBhqMMfe+SQXwPd94xbq71GY823YjvLgtGABPKM9WAeULCjzCiWsoKsb13 zmXUSkcWL53frf/w2g92TUJMAOn1ic3RCut7dAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ybqEvA LfEJ+XG2QW0t7COXBPx9Vlf52pOP3wnLhBBGQ=; b=mZWZUJUo6WC+DchmqK0zUI w0Osz+lnyRs38vE152IWmVo4wYO1tIexXC+E2AlR3sb/HGSd6JQY8QJ2YYiAG0q6 hQLImeyle7f8q6sMppnCjRZd63aIvJzPIY8mnUb621iWt9y+6l5t2v5v6dIhXQgU l/123iWR9ZaZsimPtBgRGTrLLEysxvKz4LQZ5RzaLu+a577SCwaYf+FKvc2ycqhV yJ6KvdnXUgDRSuJu2BSNcG0Ta0eTcEKu8IyfovJxEpWjeRVgKd2MO9AMVlm3hBgj 4CRDsmzlrLFQCZfM36FZc/pCOA2xaoEKrcuxzuH0EOaGEqxK7VOTZxdczM17WLSQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefjedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpefgveeggeffvd eugeevvefgveffleduleffgeejudffhfefkeeguedugedtvefftdenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6C5DB3C00A1; Tue, 2 Jun 2020 08:44:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> Date: Tue, 02 Jun 2020 05:44:08 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 12:44:31 -0000 On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote: > This draft looks really good. I just have two questions of clarification. > > I am not sure that I understand the point made in appendix B, Total > Client Hello Encryption. The text in that appendix explains that "The > design described here only provides encryption for the SNI, but not for > other extensions, such as ALPN." This seems to contradict the design > description in the introduction, "The design in this document > introduces a new extension, called Encrypted Client Hello (ECH), which > allows clients to encrypt the entirety of their ClientHello to a > supporting server." Am I correct to assume that the text in appendix B > is a leftover from the previous version of the draft? Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly. > I am also not sure on how we could implement the "Optional Record > Digests and Trial Decryption" methods described in section 10.3. The > syntax description in section 5 specifies the record digest as "opaque > record_digest<0..2^16-1>", and defines that field as containing "A > cryptographic hash of the ECHConfig structure from which the ECH key > was obtained". Would it be correct to implement the "optional record > digest" method by just encoding a zero length field? Indeed, that was the intent. Would you prefer a different way? Best, Chris > > -- Christian Huitema > > On 6/1/2020 12:41 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : TLS Encrypted Client Hello > Authors : Eric Rescorla > Kazuho Oku > Nick Sullivan > Christopher A. Wood > Filename : draft-ietf-tls-esni-07.txt > Pages : 31 > Date : 2020-06-01 > > Abstract: > This document describes a mechanism in Transport Layer Security (TLS) > for encrypting a ClientHello message under a server public key. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-esni-07 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > 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 > From nobody Tue Jun 2 11:04:06 2020 Return-Path: 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 A7CF03A0E5F for ; Tue, 2 Jun 2020 11:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yS47q45SbW2K for ; Tue, 2 Jun 2020 11:04:03 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B828B3A0E5E for ; Tue, 2 Jun 2020 11:04:02 -0700 (PDT) Received: from xse425.mail2web.com ([66.113.197.171] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jgBGV-000auF-Hf for tls@ietf.org; Tue, 02 Jun 2020 20:04:01 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49bzXX12RJz9KfW for ; Tue, 2 Jun 2020 10:28:28 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jgAiC-00086H-11 for tls@ietf.org; Tue, 02 Jun 2020 10:28:28 -0700 Received: (qmail 20444 invoked from network); 2 Jun 2020 17:28:27 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 17:28:27 -0000 To: Christopher Wood , "TLS@ietf.org" References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> Date: Tue, 2 Jun 2020 10:28:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6465F8AE248A2737849D14F1" Content-Language: en-US X-Originating-IP: 66.113.197.171 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVSIwSY28s/GvY d32ZK8grXUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bSdKfwYkQOkFU54xpUF8gRgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+c10h9aHNaslh2Yjb8ceaq51aOsarGPChhedL2Py5oHk46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ5juR84l1u3F4RJk4edtIO8VP+XOAW5422i4vvxf7U4zSrz38ZDMn1XgiFSzMpJBsjv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqQWXiK63IBlEyx 50xFFL1+8SP3vpvbnzv7vbeEFVncHzzAXPU1UvCyITFs2AML0PrLguDkihqdzHmpxf0TdAYJHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+2+nozS7+ZmQHrkbYdX3rjC08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:04:05 -0000 This is a multi-part message in MIME format. --------------6465F8AE248A2737849D14F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/2/2020 5:44 AM, Christopher Wood wrote: > On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote: >> This draft looks really good. I just have two questions of clarificati= on. >> >> I am not sure that I understand the point made in appendix B, Total=20 >> Client Hello Encryption. The text in that appendix explains that "The = >> design described here only provides encryption for the SNI, but not fo= r=20 >> other extensions, such as ALPN." This seems to contradict the design=20 >> description in the introduction, "The design in this document=20 >> introduces a new extension, called Encrypted Client Hello (ECH), which= =20 >> allows clients to encrypt the entirety of their ClientHello to a=20 >> supporting server." Am I correct to assume that the text in appendix B= =20 >> is a leftover from the previous version of the draft? > Yep! I'd opt to remove this text entirely, but if others want to keep i= t I suppose we can update the text accordingly.=20 That's probably the simple option, yes. > >> I am also not sure on how we could implement the "Optional Record=20 >> Digests and Trial Decryption" methods described in section 10.3. The=20 >> syntax description in section 5 specifies the record digest as "opaque= =20 >> record_digest<0..2^16-1>", and defines that field as containing "A=20 >> cryptographic hash of the ECHConfig structure from which the ECH key=20 >> was obtained". Would it be correct to implement the "optional record=20 >> digest" method by just encoding a zero length field? > Indeed, that was the intent. Would you prefer a different way? Length 0 is a fine way to mark the absence of an optional component. But I would like a short mention of that either in section 5 or in section 10.3. For example: 10.3. Optional Record Digests and Trial Decryption Optional record digests may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension. In such settings,=20 >> clients prevent server identification by sending >> an empty record_digest field in the ClientEncryptedCH, and=20 =C2=A0servers must perform trial decrypt upon receipt of= an empty record digest, which may exacerbate DoS attacks. Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption. Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. Fairly minimal change, but it would clarify the intent and avoid interop problems. -- Christian Huitema --------------6465F8AE248A2737849D14F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 6/2/2020 5:44 AM, Christopher Wood wrote:
On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote:

This draft looks really good. I just have two questions of clarification.

I am not sure that I understand the point made in appendix B, Total 
Client Hello Encryption. The text in that appendix explains that "The 
design described here only provides encryption for the SNI, but not for 
other extensions, such as ALPN." This seems to contradict the design 
description in the introduction, "The design in this document 
introduces a new extension, called Encrypted Client Hello (ECH), which 
allows clients to encrypt the entirety of their ClientHello to a 
supporting server." Am I correct to assume that the text in appendix B 
is a leftover from the previous version of the draft?

Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly.
That's probably the simple option, yes.


I am also not sure on how we could implement the "Optional Record 
Digests and Trial Decryption" methods described in section 10.3. The 
syntax description in section 5 specifies the record digest as "opaque 
record_digest<0..2^16-1>", and defines that field as containing "A 
cryptographic hash of the ECHConfig structure from which the ECH key 
was obtained". Would it be correct to implement the "optional record 
digest" method by just encoding a zero length field?

Indeed, that was the intent. Would you prefer a different way?

Length 0 is a fine way to mark the absence of an optional component. But I would like a short mention of that either in section 5 or in section 10.3. For example:


10.3.  Optional Record Digests and Trial Decryption

   Optional record digests may be useful in scenarios where clients and
   client-facing servers do not want to reveal information about the
   client-facing server in the "encrypted_client_hello" extension.  In
   such settings, 

>>                clients prevent server identification by sending
>> an empty record_digest field in the ClientEncryptedCH, and 

                  servers must perform trial decrypt upon receipt of an
   empty record digest, which may exacerbate DoS attacks.  Specifically,
   an adversary may send malicious ClientHello messages, i.e., those
   which will not decrypt with any known ECH key, in order to force
   wasteful decryption.  Servers that support this feature should, for
   example, implement some form of rate limiting mechanism to limit the
   damage caused by such attacks.

Fairly minimal change, but it would clarify the intent and avoid interop problems.

-- Christian Huitema

--------------6465F8AE248A2737849D14F1-- From nobody Tue Jun 2 11:19:34 2020 Return-Path: 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 C93733A0EB7 for ; Tue, 2 Jun 2020 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=Kebwutzo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d8VDLtAH 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 EHmLr6TBKxnk for ; Tue, 2 Jun 2020 11:19:31 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88503A0EB3 for ; Tue, 2 Jun 2020 11:19:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 241DF5C010C; Tue, 2 Jun 2020 14:19:30 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 02 Jun 2020 14:19:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=mDDPP LRFV1HjSjPMp8/eEiu0KPg27AS2tVJwbotIW4I=; b=KebwutzohYn36QqF5aU76 hub7kxk2JS9C/Ne8hBWijT3Z/f1JOKMR/NOpGQg/ROW8R34MB2uyc3TV30skM509 kTIFJ1OAQPSEZgX7uY08G6RDsKhf5AwrpH4C+NUpqlWDEcGjWsjYzDpIuj1/ELxT nWN4UO5oETsl6riKCyAb0yKsj37JcDuUN8mpYJ8HHnl8Ul+ncFvYy8qa3kUsZShT dN5wKfutcAX4VgFdaTKgHeLzZaRE7BFB+HANIDzwk3phuUJkuKwsXSthuRYLWI8s t4UvBr25NzAKBFS1jMw6tFCm8i3qkvMlZS8WxLLgSCrp4cES8pCTAOavvl5WUYpa g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mDDPPLRFV1HjSjPMp8/eEiu0KPg27AS2tVJwbotIW 4I=; b=d8VDLtAHjHcGQaIkVGPK3k/u/uJKJ82my1DmDMbWrAXvt2j69j/e46xBe p7KXMPgtboYWVd1MpI6G16sqnt/9B29YbZ/MPkdvlR8lulnlghT38zswFKX1lv/c mL5I+PYgPW/3b+vuoUZy/agtJ2BhYtTkkALBslKqCEMWWs7xuHbm8ja6idGNDWNN yUrcvpqwENdWLdcdrxBBsq1fcmtwPbsClxxQVcKFZx4XupyESIFb6i4Qj5FogdFj xxymjZ/nfzXWTGHjntO0PewgGpu4RKNYlgezB5bwwJ9QT8M01ctfNWOQwB6j6aFN 0O4CHhzYjXxy38g4Ty9bq3ASnrbUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefjedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucggtffrrghtthgvrhhnpeekffekveeghffgtdffieevudfgledthefhfedvvdeh leeivdegveegleefteejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A98DB3C00A1; Tue, 2 Jun 2020 14:19:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <4c5b4170-4dbe-43df-b6b4-04a9793da1c2@www.fastmail.com> In-Reply-To: <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> Date: Tue, 02 Jun 2020 11:18:35 -0700 From: "Christopher Wood" To: "Christian Huitema" , "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:19:33 -0000 On Tue, Jun 2, 2020, at 10:28 AM, Christian Huitema wrote: >=20 >=20 > On 6/2/2020 5:44 AM, Christopher Wood wrote: > > On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote: > >> This draft looks really good. I just have two questions of clarific= ation. >=20 > I am not sure that I understand the point made in appendix B, Total=20= > Client Hello Encryption. The text in that appendix explains that "The=20= > design described here only provides encryption for the SNI, but not fo= r=20 > other extensions, such as ALPN." This seems to contradict the design=20= > description in the introduction, "The design in this document=20 > introduces a new extension, called Encrypted Client Hello (ECH), which= =20 > allows clients to encrypt the entirety of their ClientHello to a=20 > supporting server." Am I correct to assume that the text in appendix B= =20 > is a leftover from the previous version of the draft? > > Yep! I'd opt to remove this text entirely, but if others want to kee= p it I suppose we can update the text accordingly. That's probably the = simple option, yes. > >> I am also not sure on how we could implement the "Optional Record=20= > Digests and Trial Decryption" methods described in section 10.3. The=20= > syntax description in section 5 specifies the record digest as "opaque= =20 > record_digest<0..2^16-1>", and defines that field as containing "A=20 > cryptographic hash of the ECHConfig structure from which the ECH key=20= > was obtained". Would it be correct to implement the "optional record=20= > digest" method by just encoding a zero length field? > > Indeed, that was the intent. Would you prefer a different way?=20 > Length 0 is a fine way to mark the absence of an optional component.=20= > But I would like a short mention of that either in section 5 or in=20 > section 10.3. For example: >=20 >=20 >=20 > 10.3. Optional Record Digests and Trial Decryption >=20 > Optional record digests may be useful in scenarios where clients an= d > client-facing servers do not want to reveal information about the > client-facing server in the "encrypted_client_hello" extension. In= > such settings,=20 >=20 > >> clients prevent server identification by sending > >> an empty record_digest field in the ClientEncryptedCH, and=20 >=20 > =C2=A0servers must perform trial decrypt upon receipt= of an > empty record digest, which may exacerbate DoS attacks. Specificall= y, > an adversary may send malicious ClientHello messages, i.e., those > which will not decrypt with any known ECH key, in order to force > wasteful decryption. Servers that support this feature should, for= > example, implement some form of rate limiting mechanism to limit th= e > damage caused by such attacks. > Fairly minimal change, but it would clarify the intent and avoid=20 > interop problems. Would you mind creating a PR for this? :-) Thanks, Chris From nobody Tue Jun 2 11:30:59 2020 Return-Path: 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 16B0B3A0C8B for ; Tue, 2 Jun 2020 11:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (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 l0tjv5TC4P7b for ; Tue, 2 Jun 2020 11:30:56 -0700 (PDT) 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 3B98B3A0784 for ; Tue, 2 Jun 2020 11:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E444ABE2C; Tue, 2 Jun 2020 19:30:51 +0100 (IST) 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 pXf3DFMoZluF; Tue, 2 Jun 2020 19:30:50 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2BC33BE20; Tue, 2 Jun 2020 19:30:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1591122650; bh=eaXgYSVORd2JRFmq+J49wOQigOXcqDIC5IsEUvIEuik=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AG5oCbBQ86R2bcBV1F7U586XosSepG6hy/++Bvbp+p3L9rTW2a57pozmNMODQA3xW DvoiSTTT5xouRPCvtScyPqjz9n5LOv0LSN6DMl9igx4NvXCW9Lnr3/9AeAYIb5r/2J 6ZWXgQ2e4NHNzStd5DUZ6dsmbpWRmcLxCYK5rMnc= To: Christian Huitema , Christopher Wood , "TLS@ietf.org" References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 2 Jun 2020 19:30:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EVQXyQDm9QS7bNu85SpL5AHx4LKjWSFbM" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:30:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EVQXyQDm9QS7bNu85SpL5AHx4LKjWSFbM Content-Type: multipart/mixed; boundary="YWmlMxu8B1m8FZ1S3479LtlpmZp48lKZq"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , Christopher Wood , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> In-Reply-To: <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> --YWmlMxu8B1m8FZ1S3479LtlpmZp48lKZq Content-Type: multipart/mixed; boundary="------------D7EE15ADEBA8801704431946" Content-Language: en-US This is a multi-part message in MIME format. --------------D7EE15ADEBA8801704431946 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Sorry if I'm missing a bit of context... On 02/06/2020 18:28, Christian Huitema wrote: > clients prevent server identification by sending > an empty record_digest field in the ClientEncryptedCH, and=20 That seems to me to be an unnecessary breach of the do-not-stick-out requirement. In my code it was quite easy to attempt trial decryption (if so configured). I don't think there's an expectation of a use-case where the number of keys in use would be so high as to cause a problem. So I'd prefer the client in that case to just send random data of the usual length. That said, ECH is sticking out a lot already so this is not a huge deal;-) Cheers, S. --------------D7EE15ADEBA8801704431946 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------D7EE15ADEBA8801704431946-- --YWmlMxu8B1m8FZ1S3479LtlpmZp48lKZq-- --EVQXyQDm9QS7bNu85SpL5AHx4LKjWSFbM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7WmtkACgkQWrL68XsX K+oaERAAxzKFYcWkdgiEVhY68ctNyOXw9fg68pczPt8V/R4cabj2EdiLQXop/Zk1 NRC7PakT8KKBbj2qaiyjbHJHcsf/RYmNU15OjcHZ640qcJaVPDD6Cvpid6rHXAFk Sso6e3bHLlXO5MHI5YOPQai52KPgWefEz0FR3TBaufkSZUF01yBjC/OeX9/twSJl +TyzQGW/JtBZC/mQ+2yH13vidOKZzT+RZYfL6lq6pxKOy9W70CILOiUqblYzdiPX ml46cMxobzy5DIEC71/U9mIbx1RiUDLEk/ZbkUaaUwtjyUUcFGqnSs2jjWB77o1m lr7BoHn+md2BlBJom94pnsYNd4TsSP3m210QQ6CXjUICze3TyBJk0KsCmtxll3Zt GyVXwZKtCCJgrzPq/w/H/RNteLma8SWwVDEO8MjQSakUL3aJRNvW7825fChFUUB2 2wPBznC2FYKqTtSOX/pxZHoDv03EtyRwPfGeW+8F0NP3toIWXj4c46J1QQExTyLL WaVnU6wlKPPTtvHzSrPFsjMyvPfE5bKzaIlbX4tHh22XiYyarI/TA9S+HTGKEOst GqZm+Asp2vqP7mAmnsjjjqz1FSlGIUuJDNV4wKmC28aJIj+FjqBo7OQ8oKLq5i64 1YSZf6dk6YwJUceZmESPwwKl0pdiMN5SKADOUOLemXvKo1enrnc= =krRO -----END PGP SIGNATURE----- --EVQXyQDm9QS7bNu85SpL5AHx4LKjWSFbM-- From nobody Tue Jun 2 11:45:13 2020 Return-Path: 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 3A2CC3A0CCB for ; Tue, 2 Jun 2020 11:45:12 -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 cSuh4-kZKgh7 for ; Tue, 2 Jun 2020 11:45:11 -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 0B2203A0CCA for ; Tue, 2 Jun 2020 11:45:10 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 052IfZuN026007; Tue, 2 Jun 2020 19:44:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Itx4/2DJRU1/gTWakOXSV7XvvB/ONpW9ur9NJw7lcaM=; b=CAa0mgYLwMpqY4HWCQS2jYMlvpJ9rEGyJlkqSz/sfzodIBStDBGrGhqikiUh9dkZY4m7 uWpzOrmv2qltRuwxuYrYFWjXys/6ylC/R/+rJ9i63yTMc8PAXiSOT+PUh5sdNxvk0+Iv lfNz1tq7Dbga3FnqiVz6xKoidKdbc7G0SeYXNqjLHAc3Qf+3IIMetfWLyIBhcp1tVWGv +v8F6pC0nc2ysSVtOSNb1i3d6x8hfKwtVItRmmGAWTS4mr7GMfEhHnK/M83PwUrUwDiV W8B0e5beVR66rkyaHMnHdFLcwhsB7r/vV/ql/0xeMzGj8J7zAUuoyNExGTc8TeV9n/mB zA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 31d8t19nva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Jun 2020 19:44:57 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 052IXln1026605; Tue, 2 Jun 2020 14:44:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint3.akamai.com with ESMTP id 31dv5d0183-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Jun 2020 14:44:57 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Jun 2020 11:44:56 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Tue, 2 Jun 2020 13:44:56 -0500 From: "Salz, Rich" To: Stephen Farrell , Christian Huitema , Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-esni-07.txt Thread-Index: AQHWOEy/hLnzomuOOU2FfdoSPfCkSajFGluAgAB/4ACAAE9wgIAAEW2A///A4oA= Date: Tue, 2 Jun 2020 18:44:56 +0000 Message-ID: <45EE8BA0-2CC4-4110-9008-45C130C98202@akamai.com> References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> In-Reply-To: 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.118.24] Content-Type: text/plain; charset="utf-8" Content-ID: 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-02_13:2020-06-02, 2020-06-02 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-2004280000 definitions=main-2006020134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-02_13:2020-06-02, 2020-06-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 cotscore=-2147483648 mlxscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 priorityscore=1501 clxscore=1011 spamscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020135 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 18:45:12 -0000 VHJpYWwgZGVzY3JpcHRpb24gc2NhcmVzIG1lLiAgUGVyaGFwcyB0aGF0J3Mgbm90IGEgcmF0aW9u YWxlIGZlYXIgLS0gb25lIG9mIHRoZSBwb2ludHMgb2YgQ0ROIHN1cHBvcnQgaXMgYSBsYXJnZSBh bm9ueW1pdHkgc2V0IC0tIGJ1dCBJIHdvcnJ5IGFib3V0IHRoZSBEb1MgcG9zc2liaWxpdGllcy4g RXNwZWNpYWxseSBpZiBRVUlDIHBpY2tzIHRoaXMgdXAgKG5vdyB0cml2aWFsIHRvIGZha2UgImNs aWVudCBJUCIpIGFuZCBpZiBzb21lIGxhcmdlIG1vYmlsZSBtYW51ZmFjdHVyZXJzIG1vdmUgdG8g dXNlIHRoaXMgYXMgdGhlIGRlZmF1bHQgYXMgSSd2ZSBoZWFyZCB0aGV5IGFyZSBjb25zaWRlcmlu Zy4NCg0K From nobody Tue Jun 2 13:35:14 2020 Return-Path: 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 077983A0FCF for ; Tue, 2 Jun 2020 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JMoIF7vdaVZd for ; Tue, 2 Jun 2020 13:35:10 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 7A8A23A0FD2 for ; Tue, 2 Jun 2020 13:35:00 -0700 (PDT) Received: from xse125.mail2web.com ([66.113.196.125] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jgDcO-000eEk-WB for tls@ietf.org; Tue, 02 Jun 2020 22:34:53 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49c2vd2TL8z6fJN for ; Tue, 2 Jun 2020 13:00:13 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jgD53-0002k1-7j for tls@ietf.org; Tue, 02 Jun 2020 13:00:13 -0700 Received: (qmail 27527 invoked from network); 2 Jun 2020 20:00:13 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 20:00:13 -0000 To: Stephen Farrell , Christopher Wood , "TLS@ietf.org" References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <0e3105b1-3d43-c5e2-e526-69a187701aca@huitema.net> Date: Tue, 2 Jun 2020 13:00:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wUPfcnofZlktKPMoRAR1oH4R5HGc3qK3d" X-Originating-IP: 66.113.196.125 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.125/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.125/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVQMCsol8nFT4c ybECHTZe40TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bTu/hUqk0wB0xIGLQFdRAZgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efq6k/ICmf4myKtZN20xbt8wI6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZECoO4gCQkfvynnCsTu+Y7qysYn+2WmjiNmrC+0DLVCYi8CA6FlUzy28jATJvi5EH9X dU571qBU/d2sq9m7FB7HOTKohW1LdIa7IkvZM3iuLmkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulx+Z35JsYprPLEWyJDYNOgB2re/hsBBxzR0ZxLcHZ9dOiXTyagf7f9s4ASqMhjJ9C4mHBw o0TowpIoKmXuwuW3NAEH5tktsnhMr4gG+2qXrJ35y/5W65h5idrw/xlP8KmZ9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:35:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wUPfcnofZlktKPMoRAR1oH4R5HGc3qK3d Content-Type: multipart/mixed; boundary="CizUPagA0zt4cpRSMVU0zneoIpbiWo1CQ"; protected-headers="v1" From: Christian Huitema To: Stephen Farrell , Christopher Wood , "TLS@ietf.org" Message-ID: <0e3105b1-3d43-c5e2-e526-69a187701aca@huitema.net> Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> In-Reply-To: --CizUPagA0zt4cpRSMVU0zneoIpbiWo1CQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 6/2/2020 11:30 AM, Stephen Farrell wrote: > Hiya, > > Sorry if I'm missing a bit of context... > > On 02/06/2020 18:28, Christian Huitema wrote: >> clients prevent server identification by sending >> an empty record_digest field in the ClientEncryptedCH, and=20 > That seems to me to be an unnecessary breach > of the do-not-stick-out requirement. In my code > it was quite easy to attempt trial decryption > (if so configured). I don't think there's an > expectation of a use-case where the number of > keys in use would be so high as to cause a problem. > So I'd prefer the client in that case to just > send random data of the usual length. > > That said, ECH is sticking out a lot already > so this is not a huge deal;-) I see your point, Stephen. Length=3D0 is a clear signal to the server, so= server processing is just a bit easier than sticking a random number that looks like a SHA256 hash, or whatever the cipher-suite mandates. With length=3D0 third parties can casually observe that "this server want= s to remain private"; with random numbers they can only observe that the record digest does not match any of the digests that they are tracking. Random numbers are thus a little bit better for privacy, at the cost of a little bit more work for the server. As I said, my first goal is to avoid silly interop issues and have a recommended behavior for servers that desire privacy. Chris is nudging me to create a PR;=C2=A0 If the consensus is for random numbers, I will p= ut that in the PR. -- Christian Huitema --CizUPagA0zt4cpRSMVU0zneoIpbiWo1CQ-- --wUPfcnofZlktKPMoRAR1oH4R5HGc3qK3d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTDcbg3CLhASkABdRQQsCaooFi0lAUCXtavzAAKCRAQsCaooFi0 lBphAQCyU+wJ3SWhN2cnlQLSCC3m8gOlA1rrMwy7BaHVBSAtyQD/ehgrPbUkK33C +N3AmJH4Axk+tpONg6eqq1NaNe6xkg4= =iOH0 -----END PGP SIGNATURE----- --wUPfcnofZlktKPMoRAR1oH4R5HGc3qK3d-- From nobody Tue Jun 2 13:50:08 2020 Return-Path: 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 D31DC3A0D32 for ; Tue, 2 Jun 2020 13:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZmCzGXBmIDWL for ; Tue, 2 Jun 2020 13:50:04 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 7FA543A0AE5 for ; Tue, 2 Jun 2020 13:50:04 -0700 (PDT) Received: from xse286.mail2web.com ([66.113.197.32] helo=xse.mail2web.com) by mx169.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jgDrG-0010uZ-9R for tls@ietf.org; Tue, 02 Jun 2020 22:50:03 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49c3Bp5zRzz87JN for ; Tue, 2 Jun 2020 13:13:22 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jgDHm-0005GH-NZ for tls@ietf.org; Tue, 02 Jun 2020 13:13:22 -0700 Received: (qmail 30304 invoked from network); 2 Jun 2020 20:13:22 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 20:13:22 -0000 To: "Salz, Rich" , Stephen Farrell , Christopher Wood , "TLS@ietf.org" References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> <45EE8BA0-2CC4-4110-9008-45C130C98202@akamai.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <79bb1e11-6176-6341-11f8-6bf32ed9f286@huitema.net> Date: Tue, 2 Jun 2020 13:13:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <45EE8BA0-2CC4-4110-9008-45C130C98202@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.32 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4b/vZVSHybih3FABwRlz3kBgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cAdwcW/8Ox85Le8wqlbs5X1QmdZsu6kxo/qWEj6Z1d7Y6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm6ZQhvJRsM2m I6SM4wXHHdyYQa4hoJtrV/Sn0lX8Myv9VkdnYVVf0MQiQrvCtYZDhrTAnJRq2K10pYvjpDRmwzov UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azG3ZbAcVpCafrtCS2RRpXVZxMPnetLBJMh51NiRRoHICzfAvrqBkBfGCiqWSDtrf9miK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50uFYY1Jfxrz6WLSQTHOrR7R08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 20:50:06 -0000 On 6/2/2020 11:44 AM, Salz, Rich wrote: > Trial description scares me. Perhaps that's not a rationale fear -- on= e of the points of CDN support is a large anonymity set -- but I worry ab= out the DoS possibilities. Especially if QUIC picks this up (now trivial = to fake "client IP") and if some large mobile manufacturers move to use t= his as the default as I've heard they are considering. I am looking at a very specific use case: mobile servers. Suppose that you use TLS to connect from a mobile client to a mobile server using an untrusted network, such as a Wi-Fi network in an airport. Neither the client not the server want to reveal their identity when using the network. When using TLS, they will use ECH to hide finger-printable data such as SNI, ALPN, or QUIC initial parameters. But the record digest in the ECH blob is also an unique identifier of the server. Sending that in the clear will disclose the identity of the server if the ECHConfigis public. Even if server and authorized clients keep the structure private, the unique record digest still allows for tracking the server's movements. In practice, server privacy pretty much requires trial decryption -- any hint at server identity or key identity can be used to track the server. Of course, this is a specialized use case. This kind of behavior is not required at all if the client-facing server is public, such as in the CDN case. Servers will have to explicitly allow the feature, and yes this is a trade-off between privacy and exposure to DDOS. The point of section 10.3 is precisely to outline that trade-off. -- Christian Huitema From nobody Tue Jun 2 14:26:34 2020 Return-Path: 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 7AC413A1025 for ; Tue, 2 Jun 2020 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 pYwpklSD4juA for ; Tue, 2 Jun 2020 14:26:26 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80EF3A101F for ; Tue, 2 Jun 2020 14:26:25 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id q11so152210wrp.3 for ; Tue, 02 Jun 2020 14:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuZrMRZAM+bwBGq9sIBpwoiFn6lWSQsISu3zcC6So/Q=; b=K+XHF/zKBwYTZD7TQSjxwhmTCvyvWgEpuztrAR47CTI/YUAfhAssldTq7vOqMgMB2Z PS7QTDNFHW9RtVfW44ANx4S3V/cP1NC77adNlf3HAdJVZuGRgFu2Mx0J1yVck5nUsn7o hJItxPdIUWlUk8Y4o8IP9pGXF8KJsH6AR3hDMi4OmyRvgMX/eHg6Zfq6Yf6InpQXdn+A yRaQUuyc85Nk9ax6pAbQkTuanKljiX1ZT6pQB0YMZJYrasiCAdG0HWNio83ZvF5rxPX4 hDRdjs3MK32D0eUGZhO2eB9yYVI2kIX1PbluIe8PcrrqHAB0+9IWCumqu20WZlPPFrSa auAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DuZrMRZAM+bwBGq9sIBpwoiFn6lWSQsISu3zcC6So/Q=; b=Bwu12sydWxpR8bk8Z0BhhxLth8Al8XZO/nHJV/57gRbnHDvllHkxaG4AQH8ZQRl1Rc x1yehgr7t89N8Mys+6BOpeKWL6OOrbmBYK+fY8+N759yGU3tIIfad0Wc4X6xzBUn5aio 9ExtmfHKFk5NEZK3hiRQ2NhxoOL5NLMomHN5rOoQS2TR5HD2Cu/Z6IBWpz6waFpoeqKh MwhhIYGbiiF8vnN7yUr45gdxOWQPEg8mMmGk4pA89muPzwyKH0PREmQadzl0S5BAEfN7 BNfd0/JlbE8KMxLhsf31mhlPfSSdWezrIMqKi6VqpMjEu88Ve9YJBj587NM5G8pHJnvY 9EFA== X-Gm-Message-State: AOAM5333HKK/cN9C5iz2fcn738HcvHSI8RVs0H8Ukvz1RtNPQuOy+XrC cNFTj5vECqwje9chykYK7kj4CzN2vZQbMEh69Rv6sQ== X-Google-Smtp-Source: ABdhPJz6XfMnN53fIsSiQ1hN9Rrm6hYKo94o+mhJY/HCovID9zfWQmIKQDHH4mPYY4kVmDi4HfPF0MbxHqJM+xf9wXc= X-Received: by 2002:a5d:4cc4:: with SMTP id c4mr27429216wrt.159.1591133173822; Tue, 02 Jun 2020 14:26:13 -0700 (PDT) MIME-Version: 1.0 References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net> <45EE8BA0-2CC4-4110-9008-45C130C98202@akamai.com> <79bb1e11-6176-6341-11f8-6bf32ed9f286@huitema.net> In-Reply-To: <79bb1e11-6176-6341-11f8-6bf32ed9f286@huitema.net> From: Ben Schwartz Date: Tue, 2 Jun 2020 17:26:02 -0400 Message-ID: To: Christian Huitema Cc: "Salz, Rich" , Stephen Farrell , Christopher Wood , "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a675be05a7208f8d" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 21:26:33 -0000 --000000000000a675be05a7208f8d Content-Type: multipart/alternative; boundary="0000000000009e276605a7208ff3" --0000000000009e276605a7208ff3 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema wrote: > On 6/2/2020 11:44 AM, Salz, Rich wrote: > > > Trial description scares me. Perhaps that's not a rationale fear -- one > of the points of CDN support is a large anonymity set -- but I worry about > the DoS possibilities. Especially if QUIC picks this up (now trivial to > fake "client IP") and if some large mobile manufacturers move to use this > as the default as I've heard they are considering. > > I am looking at a very specific use case: mobile servers. Presumably, connecting to a mobile server requires a rendezvous (a.k.a. "signalling") channel, in order to learn its current IP address. > Suppose that > you use TLS to connect from a mobile client to a mobile server using an > untrusted network, such as a Wi-Fi network in an airport. Neither the > client not the server want to reveal their identity when using the > network. When using TLS, they will use ECH to hide finger-printable data > such as SNI, ALPN, or QUIC initial parameters. But the record digest in > the ECH blob is also an unique identifier of the server. For your use case, if the server's IP address is dynamic, and discovered through a rendezvous channel, can its ECH blob also be dynamic, and discovered through the same channel? --0000000000009e276605a7208ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 2, 2020 at 4:50 PM Christ= ian Huitema <huitema@huitema.net<= /a>> wrote:
O= n 6/2/2020 11:44 AM, Salz, Rich wrote:

> Trial description scares me.=C2=A0 Perhaps that's not a rationale = fear -- one of the points of CDN support is a large anonymity set -- but I = worry about the DoS possibilities. Especially if QUIC picks this up (now tr= ivial to fake "client IP") and if some large mobile manufacturers= move to use this as the default as I've heard they are considering.
I am looking at a very specific use case: mobile servers.
Suppose that
you use TLS to connect from a mobile client to a mobile server using an
untrusted network, such as a Wi-Fi network in an airport. Neither the
client not the server want to reveal their identity when using the
network. When using TLS, they will use ECH to hide finger-printable data such as SNI, ALPN, or QUIC initial parameters. But the record digest in
the ECH blob is also an unique identifier of the server.
--0000000000009e276605a7208ff3-- --000000000000a675be05a7208f8d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCB04IIkQ207q5XNhUmyA8CG7lUWFaNQOLLFtUFIOhRfTjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA2MDIyMTI2MTRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAZcVJ+iKmNRQ/fklFOmmO7p+HB28ktMvUSwNRLugOWeB0AtEgpzw0M+jH73pgPbcjIkFYRJHv GsIzrVHpXE1S+DZ05usoHx9I7snkbaVS02GvSI/YibPOG/C49hoiu+FDM6dQ32qPoBbNMGv5kSQ9 Dnu+Zyv1iV7evx3dD/5/AKYchL2WpN0hqyDAFKKplSLNYdzXFjgR7NcAFzGugclr4bOFxGIO6WH3 NB+uGxIM9Byd7pGYRE9ciN5cm+xSixdtosxt1VOIWrDn0rYptUOnCPo405vCsHRCh4gpFMgZ01Xy /lk321b6JBetKvN3JWomE3dUTfA097E31eb3sCjcJA== --000000000000a675be05a7208f8d-- From nobody Tue Jun 2 16:01:46 2020 Return-Path: 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 878F53A10D6 for ; Tue, 2 Jun 2020 16:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QfsLiTMFpGqI for ; Tue, 2 Jun 2020 16:01:43 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A200F3A10D0 for ; Tue, 2 Jun 2020 16:01:43 -0700 (PDT) Received: from xse58.mail2web.com ([66.113.196.58] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jgFue-0005nU-JC for TLS@ietf.org; Wed, 03 Jun 2020 01:01:42 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49c6Lm60G6z6PY0 for ; Tue, 2 Jun 2020 15:35:28 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jgFVI-0001Y3-Ni for TLS@ietf.org; Tue, 02 Jun 2020 15:35:28 -0700 Received: (qmail 6092 invoked from network); 2 Jun 2020 22:35:28 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 22:35:28 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-C06B0663-550D-4625-B134-BC743A22273E Content-Transfer-Encoding: 7bit From: Christian Huitema Mime-Version: 1.0 (1.0) Date: Tue, 2 Jun 2020 15:35:27 -0700 Message-Id: References: Cc: "Salz, Rich" , Stephen Farrell , Christopher Wood , "TLS@ietf.org" In-Reply-To: To: Ben Schwartz X-Mailer: iPhone Mail (17E262) X-Originating-IP: 66.113.196.58 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.58/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.58/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnUBp1CHDvSSSf3ax1RWBzOfH zJ6mVE7ewsipSVIfs4YHrj5Ke9hrHZgZIkL6h0ZIgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ejwQhTyQ8EpXEbK2N9rfagUz0sPgnpAk2KA2vJwMd1uY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmxx/Wk8McinP JEkgAVrOMpbpEBI3TsF8NtmMf8bfn4eBGr8dhfYPz+NSUYLHTfE0nFgJkowUXTKFU/ElT0PlbdL0 lSfuxANzRU5MAZzTOSGBYfVOjkou/1Xrs00iK3J96vKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6KWDRtf6HJAeNdm4/n62X9JxMPnetLBJMh51NiRRoHIBfD5ye+ePcSbVNKKdHpO0GmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50sSb7DLwUyExrL04iJcS+/F08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 23:01:46 -0000 --Apple-Mail-C06B0663-550D-4625-B134-BC743A22273E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 2, 2020, at 2:26 PM, Ben Schwartz wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema wr= ote: >> On 6/2/2020 11:44 AM, Salz, Rich wrote: >>=20 >> > Trial description scares me. Perhaps that's not a rationale fear -- on= e of the points of CDN support is a large anonymity set -- but I worry about= the DoS possibilities. Especially if QUIC picks this up (now trivial to fak= e "client IP") and if some large mobile manufacturers move to use this as th= e default as I've heard they are considering. >>=20 >> I am looking at a very specific use case: mobile servers. >=20 > Presumably, connecting to a mobile server requires a rendezvous (a.k.a. "s= ignalling") channel, in order to learn its current IP address. > =20 >> Suppose that >> you use TLS to connect from a mobile client to a mobile server using an >> untrusted network, such as a Wi-Fi network in an airport. Neither the >> client not the server want to reveal their identity when using the >> network. When using TLS, they will use ECH to hide finger-printable data >> such as SNI, ALPN, or QUIC initial parameters. But the record digest in >> the ECH blob is also an unique identifier of the server. >=20 > For your use case, if the server's IP address is dynamic, and discovered t= hrough a rendezvous channel, can its ECH blob also be dynamic, and discovere= d through the same channel? We actually spent a fair bit of time studying this discovery problem in DNSS= D. Turns out that all practical solutions involve some form of trial decrypt= ion, such as sending "are you there" question encrypted with the public key o= f the server -- or alternately "I am here" encrypted with the public key of t= he client. In both cases the public keys have to be maintained private so on= ly authorized clients or server know them. You can poke at various corners o= f the problem, and you always end up with one of these two variants. One very simple design in that pattern is to just broadcast the ECH in an in= itial UDP message, and have the server only responds if it can decipher the E= CH. That would work with Quic or DTLS. Of course you could always add a level of indirection, but you will still en= d up with a trial decryption pattern. I am not sure that the additional comp= lexity is worth it. -- Christian Huitema=20 --Apple-Mail-C06B0663-550D-4625-B134-BC743A22273E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jun 2, 2020, at 2:26 PM, Ben Schwartz <bema= sc@google.com> wrote:

=EF=BB=BF


<= div class=3D"gmail_quote">
On Tue, Jun 2= , 2020 at 4:50 PM Christian Huitema <huitema@huitema.net> wrote:
On 6/2/2020 11:44 AM, Salz, Rich wrote:

> Trial description scares me.  Perhaps that's not a rationale fear -= - one of the points of CDN support is a large anonymity set -- but I worry a= bout the DoS possibilities. Especially if QUIC picks this up (now trivial to= fake "client IP") and if some large mobile manufacturers move to use this a= s the default as I've heard they are considering.

I am looking at a very specific use case: mobile servers.
<= br>
Presumably, connecting to a mobile server requires a rendezvou= s (a.k.a. "signalling") channel, in order to learn its current IP address.
 
Suppo= se that
you use TLS to connect from a mobile client to a mobile server using an
untrusted network, such as a Wi-Fi network in an airport. Neither the
client not the server want to reveal their identity when using the
network. When using TLS, they will use ECH to hide finger-printable data
= such as SNI, ALPN, or QUIC initial parameters. But the record digest in
the ECH blob is also an unique identifier of the server.
For your use case, if the server's IP address is dynamic, and d= iscovered through a rendezvous channel, can its ECH blob also be dynamic, an= d discovered through the same channel?

We actually spent a fair bit of time studying th= is discovery problem in DNSSD. Turns out that all practical solutions involv= e some form of trial decryption, such as sending "are you there" question en= crypted with the public key of the server -- or alternately "I am here" encr= ypted with the public key of the client. In both cases the public keys have t= o be maintained private so only authorized clients or server know them. You c= an poke at various corners of the problem, and you always end up with one of= these two variants.

One very simple design in that= pattern is to just broadcast the ECH in an initial UDP message, and have th= e server only responds if it can decipher the ECH. That would work with Quic= or DTLS.

Of course you could always add a level of= indirection, but you will still end up with a trial decryption pattern. I a= m not sure that the additional complexity is worth it.

<= div>-- Christian Huitema 


= --Apple-Mail-C06B0663-550D-4625-B134-BC743A22273E-- From nobody Tue Jun 2 16:38:10 2020 Return-Path: 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 0E6F23A1111 for ; Tue, 2 Jun 2020 16:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WGzBtKUt0vNM for ; Tue, 2 Jun 2020 16:38:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 8F7F63A1110 for ; Tue, 2 Jun 2020 16:38:07 -0700 (PDT) Received: from xse389.mail2web.com ([66.113.197.135] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jgGTs-000Oo5-8A for TLS@ietf.org; Wed, 03 Jun 2020 01:38:05 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 49c73N0NNZzL7J for ; Tue, 2 Jun 2020 16:07:12 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jgFzz-0002km-Uf for TLS@ietf.org; Tue, 02 Jun 2020 16:07:11 -0700 Received: (qmail 23772 invoked from network); 2 Jun 2020 23:07:11 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jun 2020 23:07:11 -0000 From: Christian Huitema To: Ben Schwartz Cc: "TLS@ietf.org" References: Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <8ddeae10-b14d-2f13-ef2d-1bfc926937e5@huitema.net> Date: Tue, 2 Jun 2020 16:07:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E17D2E7A547FFED7ACC711E5" Content-Language: en-US X-Originating-IP: 66.113.197.135 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnUBp1CHDvSSSf3ax1RWBzOfH zJ6mVE7ewsipSVIfs4YeJJcL7JhnvoXQb9Ax6VdzgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ef7heanb/rBmrs7JMJfZdiPM2DmctUkuqITdPZ8a3LuY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ41LX6w8nTNDx15MayNoznTIz56flK3z1Qgu4uaza5o/3NG68GHGqBe+Ps2e3wNj5Pv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV24Gz0gAbxdMJWOBl4MellXNzzAXPU1UvCyITFs2AML0PpRtTQ6Yt0CQ0Vtxw3LoF8VHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+3aZrQ0ZYZgxsMxEZFhU2WM08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 23:38:09 -0000 This is a multi-part message in MIME format. --------------E17D2E7A547FFED7ACC711E5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/2/2020 3:35 PM, Christian Huitema wrote: > >> On Jun 2, 2020, at 2:26 PM, Ben Schwartz wrote: >> >>  >> >> >> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema > > wrote: >> >> On 6/2/2020 11:44 AM, Salz, Rich wrote: >> >> > Trial description scares me.  Perhaps that's not a rationale >> fear -- one of the points of CDN support is a large anonymity set >> -- but I worry about the DoS possibilities. Especially if QUIC >> picks this up (now trivial to fake "client IP") and if some large >> mobile manufacturers move to use this as the default as I've >> heard they are considering. >> >> I am looking at a very specific use case: mobile servers. >> >> >> Presumably, connecting to a mobile server requires a rendezvous >> (a.k.a. "signalling") channel, in order to learn its current IP address. >>   >> >> Suppose that >> you use TLS to connect from a mobile client to a mobile server >> using an >> untrusted network, such as a Wi-Fi network in an airport. Neither the >> client not the server want to reveal their identity when using the >> network. When using TLS, they will use ECH to hide >> finger-printable data >> such as SNI, ALPN, or QUIC initial parameters. But the record >> digest in >> the ECH blob is also an unique identifier of the server. >> >> >> For your use case, if the server's IP address is dynamic, and >> discovered through a rendezvous channel, can its ECH blob also be >> dynamic, and discovered through the same channel? > > We actually spent a fair bit of time studying this discovery problem > in DNSSD. Turns out that all practical solutions involve some form of > trial decryption, such as sending "are you there" question encrypted > with the public key of the server -- or alternately "I am here" > encrypted with the public key of the client. In both cases the public > keys have to be maintained private so only authorized clients or > server know them. You can poke at various corners of the problem, and > you always end up with one of these two variants. Sorry, not enough coffee. You can also send an "I am here" message encrypted with the private key of the server, provided only authorized clients know the public key. And "I am here, are you there", encrypted with the private key of the client, assuming only authorized servers know the public key of the client. But the point remain, you need trial decryption in all these cases if you don't want to expose the identities. > > One very simple design in that pattern is to just broadcast the ECH in > an initial UDP message, and have the server only responds if it can > decipher the ECH. That would work with Quic or DTLS. > > Of course you could always add a level of indirection, but you will > still end up with a trial decryption pattern. I am not sure that the > additional complexity is worth it. .. With correction -- Christian Huitema --------------E17D2E7A547FFED7ACC711E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 6/2/2020 3:35 PM, Christian Huitema wrote:

On Jun 2, 2020, at 2:26 PM, Ben Schwartz <bemasc@google.com> wrote:




On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <huitema@huitema.net> wrote:
On 6/2/2020 11:44 AM, Salz, Rich wrote:

> Trial description scares me.  Perhaps that's not a rationale fear -- one of the points of CDN support is a large anonymity set -- but I worry about the DoS possibilities. Especially if QUIC picks this up (now trivial to fake "client IP") and if some large mobile manufacturers move to use this as the default as I've heard they are considering.

I am looking at a very specific use case: mobile servers.

Presumably, connecting to a mobile server requires a rendezvous (a.k.a. "signalling") channel, in order to learn its current IP address.
 
Suppose that
you use TLS to connect from a mobile client to a mobile server using an
untrusted network, such as a Wi-Fi network in an airport. Neither the
client not the server want to reveal their identity when using the
network. When using TLS, they will use ECH to hide finger-printable data
such as SNI, ALPN, or QUIC initial parameters. But the record digest in
the ECH blob is also an unique identifier of the server.

For your use case, if the server's IP address is dynamic, and discovered through a rendezvous channel, can its ECH blob also be dynamic, and discovered through the same channel?

We actually spent a fair bit of time studying this discovery problem in DNSSD. Turns out that all practical solutions involve some form of trial decryption, such as sending "are you there" question encrypted with the public key of the server -- or alternately "I am here" encrypted with the public key of the client. In both cases the public keys have to be maintained private so only authorized clients or server know them. You can poke at various corners of the problem, and you always end up with one of these two variants.

Sorry, not enough coffee. You can also send an "I am here" message encrypted with the private key of the server, provided only authorized clients know the public key. And "I am here, are you there", encrypted with the private key of the client, assuming only authorized servers know the public key of the client. But the point remain, you need trial decryption in all these cases if you don't want to expose the identities.


One very simple design in that pattern is to just broadcast the ECH in an initial UDP message, and have the server only responds if it can decipher the ECH. That would work with Quic or DTLS.

Of course you could always add a level of indirection, but you will still end up with a trial decryption pattern. I am not sure that the additional complexity is worth it.

.. With correction

-- Christian Huitema

--------------E17D2E7A547FFED7ACC711E5-- From nobody Wed Jun 3 12:51:16 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F663A0EE0; Wed, 3 Jun 2020 12:51:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159121386956.7918.7706098839926014126@ietfa.amsl.com> Date: Wed, 03 Jun 2020 12:51:09 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 19:51:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-08.txt Pages : 17 Date : 2020-04-24 Abstract: The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-08 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 13:21:17 2020 Return-Path: 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 79D613A0F2D for ; Wed, 3 Jun 2020 13:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 (1024-bit key) header.d=cloudflare.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 cx7c43UIobWs for ; Wed, 3 Jun 2020 13:21:13 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90153A0EB7 for ; Wed, 3 Jun 2020 13:21:13 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id q2so2197912vsr.1 for ; Wed, 03 Jun 2020 13:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QpgtLvYC2ztE2mRsmzDpwb7MCvZKqB1yDDoj1Td1ZR4=; b=dB3ODFgHoJVMQMzVCkjplAyt6fDy/Fm17CIzNsrYuctIp4iAous2JNYCxGf2QHZoQp 67KJEPCgkwFkXetkkXBJTWcsHR/+dRuckUlfWy1onyP2HKHjT+mGldGJ1xbHBl6lhd3z pYf/uw/2dPXaMD/On3FQNALKD811mlOqkLslY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QpgtLvYC2ztE2mRsmzDpwb7MCvZKqB1yDDoj1Td1ZR4=; b=tCaEXV34msQmy3GZtjZTSe0FwE7UjeXEejmGO3PSx7807+PLs5yLqZGT0oodNa6Q9L 1CaSs8yYiDdooQrC3VnPCG7dWnYtv0plLCfNwWvRtvQB1m9LM8h6FFjwPXr+86WwTRYl 4duaV1B5Owuzy+XIlC/55qrReiUonuZHCGFJPnKlBXJt2Jaq99hjXKWVuuYISp0aKqlt etbO/E+25egM06eWtJYiwiKuz0BKjXxH6xYQaTjoQ/zWIyr4/Yd088zSbJXr/07MbFQq 4LX81e83zOJsHSYb0agjteodbH0j25ZShE+sPLxmzq0IiiDrf/SKLiu2mgUaOVSoiXoI qiqw== X-Gm-Message-State: AOAM5307jDLQj1yWxLg3QM35HLPWYAe1nEdn4tWNUO6r611Yb2Car+dH sOg8GUyM2p3hYlRKWt7dREXLlIKejyiXqJhA5WmQ46LNE7oxGg== X-Google-Smtp-Source: ABdhPJw2h+BhFe8L0b8sSb2j3onBLaPdtQ4dxU/vi1C99jwxL7H0KxHRrES7CMhhGEY/gToght2V4rqrvh7TsLSWYfg= X-Received: by 2002:a67:b741:: with SMTP id l1mr1013096vsh.180.1591215670960; Wed, 03 Jun 2020 13:21:10 -0700 (PDT) MIME-Version: 1.0 References: <631077AF-6A16-40EB-9CE4-E376EF83AE35@akamai.com> In-Reply-To: <631077AF-6A16-40EB-9CE4-E376EF83AE35@akamai.com> From: Nick Sullivan Date: Wed, 3 Jun 2020 13:20:54 -0700 Message-ID: To: "Salz, Rich" Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="000000000000d4955e05a733c409" Archived-At: Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 20:21:16 -0000 --000000000000d4955e05a733c409 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello TLSWG, We made a -08 version of this draft before the WGLC that incorporated some of the comments on-list for -07, but didn't notice until now that the submission didn't go through and therefore wasn't available for this RGLC. I apologize for this oversight. This submission just went through now and the changes from -07 can be seen here: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-08.txt The authors plan on submitting a -09 soon that incorporates the comments from this WGLC. We'll post it here with a summary of changes. Nick On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich wrote: > I reread this and support it. We are looking at implementation. We=E2=80= =99re > curious if anyone is working on a standard for server/origin > recertification, etc. > > > > *From: *Joseph Salowey > *Date: *Monday, June 1, 2020 at 12:53 AM > *To: *"tls@ietf.org" > *Subject: *Re: [TLS] Working group last call for > draft-ietf-tls-subcerts-07 > > > > Reminder: the last call expires this week. > > > > On Mon, May 18, 2020 at 12:56 PM Joseph Salowey wrote: > > This is the Working Group Last Call for "Delegated Credentials for TLS" > available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > . > Please review the document and respond to the list with any comments by > June 2, 2020. > > Cheers, > > Chris, Joe & Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d4955e05a733c409 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello TLSWG,

We made a -08 version of t= his draft before the WGLC that incorporated some of the comments on-list fo= r -07, but didn't notice until now that the submission didn't=C2=A0= go through and therefore wasn't available for this RGLC. I apologize fo= r this oversight. This submission just went through now and the changes fro= m -07 can be seen here:

The auth= ors plan on submitting a -09 soon that incorporates the comments from this = WGLC. We'll post it here with a summary=C2=A0of changes.

=
Nick

On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich <rsalz=3D= 40akamai.com@dmarc.ietf.org<= /a>> wrote:

I reread this and support it.=C2=A0 We are looking a= t implementation. We=E2=80=99re curious if anyone is working on a standard = for server/origin recertification, etc.

=C2=A0

From: = Joseph Salowey <joe@salowey.net><= br> Date: Monday, June 1, 2020 at 12:53 AM
To: "tls@ietf= .org" <tls@ie= tf.org>
Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcer= ts-07

=C2=A0

Reminder: the last call expires=C2=A0this week.=C2= =A0

=C2=A0

On Mon, May 18, 2020 at 12:56 PM Joseph Salowey <= joe@salowey.net>= ; wrote:

This is the Working Gro= up Last Call for "Delegated Credentials for TLS" available at=C2= =A0https://datatracker.ietf.org/doc/draft-ie= tf-tls-subcerts/.=C2=A0 Please review the document and respond to the list with any comments by Ju= ne 2, 2020. =C2=A0

Cheers,

Chris, Joe & Sean

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d4955e05a733c409-- From nobody Wed Jun 3 13:27:22 2020 Return-Path: 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 4D0263A0F2E for ; Wed, 3 Jun 2020 13:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 5Hs6GQYC3fH4 for ; Wed, 3 Jun 2020 13:27:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217BB3A0F34 for ; Wed, 3 Jun 2020 13:27:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DEDA7300B64 for ; Wed, 3 Jun 2020 16:27:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9lcp-9rTCphR for ; Wed, 3 Jun 2020 16:27:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id F183B300670; Wed, 3 Jun 2020 16:27:12 -0400 (EDT) From: Russ Housley Message-Id: <454F4A38-B367-4E8C-9C21-A52E0D081B41@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_15D70362-B218-4C2B-82D6-80870B7834CB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 3 Jun 2020 16:27:14 -0400 In-Reply-To: Cc: "Salz, Rich" , IETF TLS To: Nick Sullivan References: <631077AF-6A16-40EB-9CE4-E376EF83AE35@akamai.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 20:27:20 -0000 --Apple-Mail=_15D70362-B218-4C2B-82D6-80870B7834CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Nick: There is something wrong with the formatting of the numbered list in = Section 4.1.3. Russ > On Jun 3, 2020, at 4:20 PM, Nick Sullivan = wrote: >=20 > Hello TLSWG, >=20 > We made a -08 version of this draft before the WGLC that incorporated = some of the comments on-list for -07, but didn't notice until now that = the submission didn't go through and therefore wasn't available for this = RGLC. I apologize for this oversight. This submission just went through = now and the changes from -07 can be seen here: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-08.txt = >=20 > The authors plan on submitting a -09 soon that incorporates the = comments from this WGLC. We'll post it here with a summary of changes. >=20 > Nick >=20 > On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich = > wrote: > I reread this and support it. We are looking at implementation. = We=E2=80=99re curious if anyone is working on a standard for = server/origin recertification, etc. >=20 > =20 >=20 > From: Joseph Salowey > > Date: Monday, June 1, 2020 at 12:53 AM > To: "tls@ietf..org " > > Subject: Re: [TLS] Working group last call for = draft-ietf-tls-subcerts-07 >=20 > =20 >=20 > Reminder: the last call expires this week.=20 >=20 > =20 >=20 > On Mon, May 18, 2020 at 12:56 PM Joseph Salowey > wrote: >=20 > This is the Working Group Last Call for "Delegated Credentials for = TLS" available at = https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ = . Please review = the document and respond to the list with any comments by June 2, 2020. =20= >=20 > Cheers, >=20 > Chris, Joe & Sean >=20 > _______________________________________________ > 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 --Apple-Mail=_15D70362-B218-4C2B-82D6-80870B7834CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Nick:

There= is something wrong with the formatting of the numbered list in Section = 4.1.3.

Russ

On Jun 3, 2020, at 4:20 PM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

Hello TLSWG,

We made a -08 version of this draft = before the WGLC that incorporated some of the comments on-list for -07, = but didn't notice until now that the submission didn't go through = and therefore wasn't available for this RGLC. I apologize for this = oversight. This submission just went through now and the changes from = -07 can be seen here:
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-0= 8.txt

The authors plan on submitting a -09 soon that incorporates = the comments from this WGLC. We'll post it here with a summary of = changes.

Nick

On Mon, Jun 1, 2020 at 5:04 AM Salz, = Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:

I reread this and support it.  We are looking = at implementation. We=E2=80=99re curious if anyone is working on a = standard for server/origin recertification, etc.

 

From: Joseph Salowey <joe@salowey.net>
Date: Monday, June 1, 2020 at 12:53 AM
To: "tls@ietf..org" <tls@ietf.org>
Subject: Re: [TLS] Working group last call for = draft-ietf-tls-subcerts-07

 

Reminder: the last call = expires this week. 

 

On Mon, May 18, 2020 at 12:56 PM = Joseph Salowey <joe@salowey.net> wrote:

This = is the Working Group Last Call for "Delegated Credentials for TLS" = available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/.&= nbsp; Please review the document and respond to the list with any comments by = June 2, 2020.  

Cheers,

Chris, Joe & Sean

_______________________________________________
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

= --Apple-Mail=_15D70362-B218-4C2B-82D6-80870B7834CB-- From nobody Wed Jun 3 14:26:47 2020 Return-Path: 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 663363A0FCA for ; Wed, 3 Jun 2020 14:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 (1024-bit key) header.d=cloudflare.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 hL92HtRHuAI6 for ; Wed, 3 Jun 2020 14:26:42 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ED23A0FC7 for ; Wed, 3 Jun 2020 14:26:42 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id u17so2279272vsu.7 for ; Wed, 03 Jun 2020 14:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bcd+uj+fIb5X5Lkqwj5SJzIOt0pfqFUwKfIl0PFKSJ0=; b=cQVrsSbivzluFAsDnZOsdceDJuBddqT9Z8Um47PBpgYbG0pBtIkbQWAQcKgBWxjmLf 1yOYP5SO3L2ktUBaLTxHrlZ4cV3NhUcGeiecAdBSclrU4OJHy5q81tgiT/6pVeu+hbjR wRon9hNtJQfH5WJ2UV8MAVVqlQ6Lq/QLM49g0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bcd+uj+fIb5X5Lkqwj5SJzIOt0pfqFUwKfIl0PFKSJ0=; b=uHT5AT1usqxM+AsaeR5QY9aZlqHIgY5viCSc4wXC0dcwb3ZA6soMM5QxeiAvG9jgiY w5BsSCCYYIL4XT0jrD1/8jLGDsCtP+ogGOdczijvvb9brPA+vmvUfyljxMU853Vvammf zgKeuPnNC1+m8GddjQwyGa39ATcD8Q/Aio4rcUfuguJR9ysHqlcV54L2BmQrlBgT8qiz qL5vTqUK9xgT857CaU5EeqGA4urqo8+LahxJvKVbaEeZAjTqZyl/75R6WNSap4PT8e5Y ZHcsT5kzGeoSQnveWHoNfFyh7ap+9xRAoIo+wfP56eVCsrZfYYhqxvsaFEeq1bkeDUZY qThw== X-Gm-Message-State: AOAM533EPqtWniZqxUKlp4CnngZ2p+oJej+/6MZPMZJuhmoUf+IEvNNY LW3BCKX2AX5/IzHekxJ0mQmyPiSEn6ZCLwE47oxcXw== X-Google-Smtp-Source: ABdhPJxCYl1QHey0PMTNpU0WH0VWIWbQ/5c91TmfbdbVSkcmu/UMAq3tiib9LFPwclmmDcZ9kDU960PGV/Qiz26YrpU= X-Received: by 2002:a67:a40d:: with SMTP id n13mr1198626vse.212.1591219601483; Wed, 03 Jun 2020 14:26:41 -0700 (PDT) MIME-Version: 1.0 References: <631077AF-6A16-40EB-9CE4-E376EF83AE35@akamai.com> <454F4A38-B367-4E8C-9C21-A52E0D081B41@vigilsec.com> In-Reply-To: <454F4A38-B367-4E8C-9C21-A52E0D081B41@vigilsec.com> From: Nick Sullivan Date: Wed, 3 Jun 2020 14:26:25 -0700 Message-ID: To: Russ Housley Cc: "Salz, Rich" , IETF TLS Content-Type: multipart/alternative; boundary="0000000000001b742e05a734af09" Archived-At: Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcerts-07 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 21:26:45 -0000 --0000000000001b742e05a734af09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Russ, I filed an issue to address it. On Wed, Jun 3, 2020 at 1:27 PM Russ Housley wrote: > Nick: > > There is something wrong with the formatting of the numbered list in > Section 4.1.3. > > Russ > > On Jun 3, 2020, at 4:20 PM, Nick Sullivan < > nick=3D40cloudflare.com@dmarc.ietf.org> wrote: > > Hello TLSWG, > > We made a -08 version of this draft before the WGLC that incorporated som= e > of the comments on-list for -07, but didn't notice until now that the > submission didn't go through and therefore wasn't available for this RGLC= . > I apologize for this oversight. This submission just went through now and > the changes from -07 can be seen here: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-08.txt > > The authors plan on submitting a -09 soon that incorporates the comments > from this WGLC. We'll post it here with a summary of changes. > > Nick > > On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich 40akamai.com@dmarc.ietf.org> wrote: > >> I reread this and support it. We are looking at implementation. We=E2= =80=99re >> curious if anyone is working on a standard for server/origin >> recertification, etc. >> >> >> >> *From: *Joseph Salowey >> *Date: *Monday, June 1, 2020 at 12:53 AM >> *To: *"tls@ietf..org " >> *Subject: *Re: [TLS] Working group last call for >> draft-ietf-tls-subcerts-07 >> >> >> >> Reminder: the last call expires this week. >> >> >> >> On Mon, May 18, 2020 at 12:56 PM Joseph Salowey wrote: >> >> This is the Working Group Last Call for "Delegated Credentials for TLS" >> available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ >> . >> Please review the document and respond to the list with any comments by >> June 2, 2020. >> >> Cheers, >> >> Chris, Joe & Sean >> >> _______________________________________________ >> 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 > > > --0000000000001b742e05a734af09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Russ, I filed an issue to address it.

On Wed, Jun 3,= 2020 at 1:27 PM Russ Housley <h= ousley@vigilsec.com> wrote:
Nick:

=
There is something wrong with the formatting of the numbered lis= t in Section 4.1.3.

Russ

On Jun 3, 2020, at 4:20 PM, Nick Sullivan <nick=3D40c= loudflare.com@dmarc.ietf.org> wrote:

= Hello TLSWG,

We made a -08 version of this draft before = the WGLC that incorporated some of the comments on-list for -07, but didn&#= 39;t notice until now that the submission didn't=C2=A0go through and th= erefore wasn't available for this RGLC. I apologize for this oversight.= This submission just went through now and the changes from -07 can be seen= here:

The aut= hors plan on submitting a -09 soon that incorporates the comments from this= WGLC. We'll post it here with a summary=C2=A0of changes.
Nick

On Mon, Jun 1, 2020 at 5:04 AM Salz, Rich <rsalz= =3D40akama= i.com@dmarc.ietf.org> wrote:

I reread this and support it.=C2=A0 We are look= ing at implementation. We=E2=80=99re curious if anyone is working on a stan= dard for server/origin recertification, etc.

=C2=A0

= From: Joseph Salowey <joe@salowey.net>
Date: Monday, June 1, 2020 at 12:53 AM
To: "tls@ietf= ..org" <tls@i= etf.org>
Subject: Re: [TLS] Working group last call for draft-ietf-tls-subcer= ts-07

=C2=A0

Reminder: the last call expires=C2=A0this week.= =C2=A0

=C2=A0

On Mon, May 18, 2020 at 12:56 PM Joseph Salowey= <joe@salowey.net> wrote:

This is the Workin= g Group Last Call for "Delegated Credentials for TLS" available a= t=C2=A0https://datatracker.ietf.org/doc/dra= ft-ietf-tls-subcerts/.=C2=A0 Please review the document and respond to the list with any comments by Ju= ne 2, 2020. =C2=A0

Cheers,

Chris, Joe & Sean

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

<= /div>
--0000000000001b742e05a734af09-- From nobody Wed Jun 3 17:00:37 2020 Return-Path: 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 A85CE3A0AD3 for ; Wed, 3 Jun 2020 17:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1PhG50QT21HE for ; Wed, 3 Jun 2020 17:00:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E553A0ACE for ; Wed, 3 Jun 2020 17:00:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 387A5F4070F; Wed, 3 Jun 2020 17:00:11 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: caw@heapingbits.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200604000011.387A5F4070F@rfc-editor.org> Date: Wed, 3 Jun 2020 17:00:11 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 00:00:32 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6204 -------------------------------------- Type: Editorial Reported by: Chris Wood Section: E.1 Original Text ------------- Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension. Corrected Text -------------- Implementations MUST NOT combine external PSKs with certificate-based authentication of either client or the server. Future specifications MAY provide an extension to permit this. Notes ----- The existing text can be misread as permitting this combination upon negotiation of the "post_handshake_auth" extension, which would be incorrect. [1] describes an attack that can occur based on this misinterpretation. The proposed text aims to make clear that a *new* extension is required for this combination. [1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Jun 3 18:07:07 2020 Return-Path: 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 705413A0C0A for ; Wed, 3 Jun 2020 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=QqsUfk8l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vdjShyoR 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 3rRsqoAtcEry for ; Wed, 3 Jun 2020 18:07:03 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359793A0C08 for ; Wed, 3 Jun 2020 18:07:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 159D8622 for ; Wed, 3 Jun 2020 21:07:02 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 03 Jun 2020 21:07:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=468outCF1ZtACdw1KPINFo2Enhh39c2 gvAdw/ObXgKo=; b=QqsUfk8lwEiGnnF98k8HfIrB0ES1kme6gU6hQ7/R5a+hPkJ tT6M57N+MI63cClYrfA9qKdDaRVVGaTp8Y0bzzHMATcuK62juxOdMjrg38kdc0He i+OPY/Z0yFl+HFd0t8qAeWbZk7RyRsp/MIEjsNnWcf2myFq8t5yXsnvMFGFx3E5R 06ueJx1M3FK5xb/pmmcvVXyQWaxBdiGXcSPYgfGFMsW/bb91pRmXDHfK/+mLS0tg puB61Lf+97hxGD/7zmXFyRo1suRtLBAsuDDSNWcbP6OEB4AvU+0Xqfdf+V5lltJU +oQw7eBa23+AwQ/vq1TkaacV2tCXQET3A1mx0VA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=468out CF1ZtACdw1KPINFo2Enhh39c2gvAdw/ObXgKo=; b=vdjShyoR1CMaEooPs7+970 rr00+ykP6M6JqHTUUglo9hVdb17gpfF6dt82eD4e4NU/TRuvxQ4p6QIGl34X5PQR 6jv8Vw8tMgdgbQDNPSNE4nGMemfOI+GXQL7WOaZ+rnYYxaKbsSqUXmuDM4fZQE1T Qxui4/uyBZ9IJ1UoZvYQpjvVPqIDOZTioFMr2OQudTceBKRR1/twkZ6/bJwg8KNK muUOJftHhLLTCcQJgTWFBA3Q7rHkAQyeAiJtoazc00hMXuqR7syqKDrvGX2rDdnH TKscWgvcSWgphJjmZgmnkyL4vP5kJpk/T8BdsEXuF/eW6fLbUA6i3X9IvCKYWVWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefggfdvgfelveejtdefge dugeelkeeukeffgefggfethedthfejudfhkeegtdeifeenucffohhmrghinhepihgvthhf rdhorhhgpdhrfhgtqdgvughithhorhdrohhrghdpshhprhhinhhgvghrrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 52A37E00C9; Wed, 3 Jun 2020 21:07:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> In-Reply-To: <20200604000011.387A5F4070F@rfc-editor.org> References: <20200604000011.387A5F4070F@rfc-editor.org> Date: Thu, 04 Jun 2020 11:06:42 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 01:07:06 -0000 I think that this is a useful erratum and it should be approved/HFDU. The extension to which this text alludes is RFC 8773, not post_handshake_auth. There is one other piece to this that is very confusing, and less clear. "Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6)." The motivation is the attack that Sam Scott et. al. found in their analysis of resumption: https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ However, this statement is unclear on whether it applies to external, resumption, or both types of PSK, but without qualification as it is you might be forgiven for thinking that it is both. However, the document already says: "It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints." So I think that the right interpretation is that this statement applies to "a resumption PSK" only. If people agree with this interpretation, then I will file another erratum of the form: OLD: Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, [...] NEW: Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, [...] On Thu, Jun 4, 2020, at 10:00, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6204 > > -------------------------------------- > Type: Editorial > Reported by: Chris Wood > > Section: E.1 > > Original Text > ------------- > Implementations MUST NOT combine external PSKs with certificate-based > authentication of either the client or the server unless negotiated by > some extension. > > Corrected Text > -------------- > Implementations MUST NOT combine external PSKs with certificate-based > authentication of either client or the server. Future specifications > MAY provide an extension to permit this. > > Notes > ----- > The existing text can be misread as permitting this combination upon > negotiation of the "post_handshake_auth" extension, which would be > incorrect. [1] describes an attack that can occur based on this > misinterpretation. The proposed text aims to make clear that a *new* > extension is required for this combination. > > [1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Jun 3 18:45:26 2020 Return-Path: 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 2E47A3A0CA4 for ; Wed, 3 Jun 2020 18:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 4Js_juCf_V0h for ; Wed, 3 Jun 2020 18:45:22 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E983A0CA1 for ; Wed, 3 Jun 2020 18:45:21 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y11so3574837ljm.9 for ; Wed, 03 Jun 2020 18:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d1TbCcrITn7D17ECXJVPnuLAHR2RTFbuZt14mJRSRpM=; b=z3Gd3a2tHVvWYb/MbPTxsDW3Es20qO8eZSvG5n0wFLFF9hpkL8Ah6xmmEGE7fjlfQ/ YRway3bz7ewOAUKdqanR2dU1gK15w/RGNju5SyxIpZ8mCgzUIiqPbNudCflTSU7hno/C CxbppS43SEeNNpXnyW+K5Kd2F8jUtJRKbFY57vooEcgyZOux+sKA4k3h8AgnI+1+yg4b IHzjHsW+tuczmaf2dlKz2EJUNC9RufAL/07z5VDrWo29MOMbhU2d8hbI798cgvcmEuX2 RO14vJbOr6F5JGXGwCZs4Xx5ySQDQE/vOaibT15O9j1HUueqauZwb9Yab2ApKeYTIq6I 17PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d1TbCcrITn7D17ECXJVPnuLAHR2RTFbuZt14mJRSRpM=; b=B+6Q+0NuHVXue0DqmT/teKARQXcfkBdm/KqS8rkM7vfc4cYXlBAhVFzBLnCSSfrIq5 zlUKfvdjmnwioJT/5yoW+iisbuS5r8sH08YE5TjIkcocHx5RSAYvKVPt28RaeFHPAB3M GOOcxztBmpIy/Y6w+rsN8WKX6zt8P/UluAgUgZN5yVXx2GFy3JqlC5UbSA56++u96573 shmfgFXESV4v9y0++xGhsKdVSBLUWvfGLdtrH0J+I2tJxenH8lfFsSEJPfpEfLZWAYID Y4AZ3WaG4cqwNSP7VCx4qiXO/u791r3BC/iCckib5a3TXhwvkNwfp8TpiQaPzgaKIhrD tlfw== X-Gm-Message-State: AOAM532po2xFl1WX/y/Yh6QBrzAHOVC3greSUoCINaTimdF991ME1RM7 ZptuSka07PhA0fj6Ve6TZggpWvAIBlwbNAbKvN1oWtqySNY= X-Google-Smtp-Source: ABdhPJxRA0is6NgoOjTPUrG7f/yNIBdNwWqWyFqjRGsIV9XBI20MLGvb7/U8tQjsiaEXObGdvtwW9F+FAj04fFBuwTk= X-Received: by 2002:a2e:3609:: with SMTP id d9mr853714lja.409.1591235119893; Wed, 03 Jun 2020 18:45:19 -0700 (PDT) MIME-Version: 1.0 References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> In-Reply-To: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> From: Eric Rescorla Date: Wed, 3 Jun 2020 18:44:43 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000137c0b05a7384c66" Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 01:45:24 -0000 --000000000000137c0b05a7384c66 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote: > I think that this is a useful erratum and it should be approved/HFDU. The > extension to which this text alludes is RFC 8773, not post_handshake_auth. > Yes, although 8773 actually is not super-clear about post-handshake, so that's actually something we should clarify there. > There is one other piece to this that is very confusing, and less clear. > > "Servers which are authenticating with a PSK MUST NOT send the > CertificateRequest message in the main handshake, though they MAY send it > in post-handshake authentication (see Section 4.6.2) provided that the > client has sent the "post_handshake_auth" extension (see Section 4.2.6)." > > The motivation is the attack that Sam Scott et. al. found in their > analysis of resumption: > https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ > However, this statement is unclear on whether it applies to external, > resumption, or both types of PSK, but without qualification as it is you > might be forgiven for thinking that it is both. > > However, the document already says: > > "It is unsafe to use certificate-based client authentication when the > client might potentially share the same PSK/key-id pair with two different > endpoints."- > > So I think that the right interpretation is that this statement applies to > "a resumption PSK" only. > > If people agree with this interpretation, then I will file another erratum > of the form: > > OLD: > Servers which are authenticating with a PSK MUST NOT send the > CertificateRequest message in the main handshake, [...] > NEW: > Servers which are authenticating with a resumption PSK MUST NOT send the > CertificateRequest message in the main handshake, [...] > I see what you are trying to do, but I think if we are to restrict this to resumption here it might leave the wrong impression. I think it would help to be more explicit here: Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, [...], Servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message either in the main handshake or in the post-handshake phase. Future specifications MAY provide an extension to permit this. This would be consistent with the erratum Chris proposed -Ekr > > On Thu, Jun 4, 2020, at 10:00, RFC Errata System wrote: > > The following errata report has been submitted for RFC8446, > > "The Transport Layer Security (TLS) Protocol Version 1.3". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6204 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Chris Wood > > > > Section: E.1 > > > > Original Text > > ------------- > > Implementations MUST NOT combine external PSKs with certificate-based > > authentication of either the client or the server unless negotiated by > > some extension. > > > > Corrected Text > > -------------- > > Implementations MUST NOT combine external PSKs with certificate-based > > authentication of either client or the server. Future specifications > > MAY provide an extension to permit this. > > > > Notes > > ----- > > The existing text can be misread as permitting this combination upon > > negotiation of the "post_handshake_auth" extension, which would be > > incorrect. [1] describes an attack that can occur based on this > > misinterpretation. The proposed text aims to make clear that a *new* > > extension is required for this combination. > > > > [1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0 > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8446 (draft-ietf-tls-tls13-28) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol > Version 1.3 > > Publication Date : August 2018 > > Author(s) : E. Rescorla > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > 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 > --000000000000137c0b05a7384c66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 3, 2020 at 6:07 PM Martin= Thomson <mt@lowe= ntropy.net> wrote:
I think that this is a useful erratum and it should be approved/= HFDU.=C2=A0 The extension to which this text alludes is RFC 8773, not post_= handshake_auth.

Yes, although 8773 actu= ally is not super-clear about post-handshake, so that's actually someth= ing we should clarify there.

=C2=A0
There is one other piece to this that is very confusing, and less clear.
=C2=A0"Servers which are authenticating with a PSK MUST NOT send the C= ertificateRequest message in the main handshake, though they MAY send it in= post-handshake authentication (see Section 4.6.2) provided that the client= has sent the "post_handshake_auth" extension (see Section 4.2.6)= ."

The motivation is the attack that Sam Scott et. al. found in their analysis= of resumption:=C2=A0 https://= mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/=C2=A0 Ho= wever, this statement is unclear on whether it applies to external, resumpt= ion, or both types of PSK, but without qualification as it is you might be = forgiven for thinking that it is both.

However, the document already says:

"It is unsafe to use certificate-based client authentication when the = client might potentially share the same PSK/key-id pair with two different = endpoints."-

So I think that the right interpretation is that this statement applies to = "a resumption PSK" only.

If people agree with this interpretation, then I will file another erratum = of the form:

OLD:
Servers which are authenticating with a PSK MUST NOT send the CertificateRe= quest message in the main handshake, [...]
NEW:
Servers which are authenticating with a resumption PSK MUST NOT send the Ce= rtificateRequest message in the main handshake, [...]
=
I see what you are trying to do, but I think if we are to re= strict this to resumption here it might leave the wrong impression.

I think it would help to be more explicit here:
Servers which are authenticating with a resumption PSK MUST NOT send the C= ertificateRequest message in the main handshake, [...],
Servers w= hich are authenticating with an external PSK MUST NOT send the CertificateR= equest message either in the main handshake or in the post-handshake phase.= Future specifications=C2=A0 MAY provide an extension to permit this.
<= /div>

This would be consistent with the erratum Chris pr= oposed


<= div class=3D"gmail_quote">-Ekr



On Thu, Jun 4, 2020, at 10:00, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3". >
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6204
>
> --------------------------------------
> Type: Editorial
> Reported by: Chris Wood <caw@heapingbits.net>
>
> Section: E.1
>
> Original Text
> -------------
> Implementations MUST NOT combine external PSKs with certificate-based =
> authentication of either the client or the server unless negotiated by=
> some extension.
>
> Corrected Text
> --------------
> Implementations MUST NOT combine external PSKs with certificate-based =
> authentication of either client or the server. Future specifications <= br> > MAY provide an extension to permit this.
>
> Notes
> -----
> The existing text can be misread as permitting this combination upon <= br> > negotiation of the "post_handshake_auth" extension, which wo= uld be
> incorrect. [1] describes an attack that can occur based on this
> misinterpretation. The proposed text aims to make clear that a *new* <= br> > extension is required for this combination.
>
> [1] https://link.springer.com/art= icle/10.1007%2Fs11416-020-00352-0
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8446 (draft-ietf-tls-tls13-28)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Tran= sport Layer Security (TLS) Protocol Version 1.3
> Publication Date=C2=A0 =C2=A0 : August 2018
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Lay= er Security
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> 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
--000000000000137c0b05a7384c66-- From nobody Wed Jun 3 18:48:12 2020 Return-Path: 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 3B8B23A0CAA for ; Wed, 3 Jun 2020 18:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=Tv0fIZI1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TvX7nDh5 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 BFriL7yBeWMI for ; Wed, 3 Jun 2020 18:48:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DDB3A0CB0 for ; Wed, 3 Jun 2020 18:48:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id A6889874; Wed, 3 Jun 2020 21:48:07 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 03 Jun 2020 21:48:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=Wv30ouTfce7+UxXSShG4IfDKbRsF za+NmwpxIaa4nm8=; b=Tv0fIZI17z1ix+gyqzsEH8tejjwv14IeA9WMmvQlBi8m SA07hFtDB8yuDZi5yAD9Hq3DdkcIe9LQzI8//LMFzo2pvVs5OgM/A1ZbvGFZc5UM 63h53qL35lp6E6Vj60whcAaAe7FIm3m0if+2XTT63FI8CB7MvZxCf9iasoDUm4X9 47Q1/jqIhiTRnNw/02aQqqHzlqkRsNdjloIYMbvBVt+sTimUrp56VUZcoGEbMAr4 NNBm6RAx9h5r1C5ugfOTPklrFC1f+We6nnrehC28e/YozS+RAd3mK4nIJSD/bKM0 rE0XuN7oGDnA+dBE9e5fQAZHlLgg/BNnZW0fXmgSOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Wv30ou Tfce7+UxXSShG4IfDKbRsFza+NmwpxIaa4nm8=; b=TvX7nDh5OES4aWUr5V+VBp hfeWvARzoyXrn8vHLrRZ6+/n2QQRIBuxgBzfsUjQvS6tdOgwuakTseZDMZL8PPlp YLEss7AWCg6NzOh7LBxZNgQvTCT7x51lcItq7RFFHBb9l3lUhR5MDn1vN9VXMrGc KIPm0DN0IZFFznPBiC6cNMXyURk0Er957fg8QqPUBQsG2XBdJarkls0lL+Qh+wx/ xLM+NOWXxVp24ET0yu971vKdnh5uApEafILv+laKEaQY+EWKzrKo9278V9YbIcLn PL9U2W3INFqAsZbVfamdw9Qgf9c5jSeqPsTdkxdh33yIEQaotqCvxGOgVK4EJ5cA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AD891E00C9; Wed, 3 Jun 2020 21:48:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <8cfd2e2d-7df7-4054-ba15-c9bc33cdc034@www.fastmail.com> In-Reply-To: References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> Date: Thu, 04 Jun 2020 11:47:38 +1000 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 01:48:11 -0000 On Thu, Jun 4, 2020, at 11:44, Eric Rescorla wrote: > I think it would help to be more explicit here: > Servers which are authenticating with a resumption PSK MUST NOT send > the CertificateRequest message in the main handshake, [...], > Servers which are authenticating with an external PSK MUST NOT send the > CertificateRequest message either in the main handshake or in the > post-handshake phase. Future specifications MAY provide an extension to > permit this. That sounds great. I've a tiny tweak, but I will open an erratum with that suggestion. From nobody Wed Jun 3 18:58:27 2020 Return-Path: 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 81BB83A0CBC for ; Wed, 3 Jun 2020 18:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=LQ9fJ5IM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pouqIOZM 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 zK4qEasEO9Q1 for ; Wed, 3 Jun 2020 18:58:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5519B3A0CB8 for ; Wed, 3 Jun 2020 18:58:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 883815C00B5 for ; Wed, 3 Jun 2020 21:58:24 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 03 Jun 2020 21:58:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=D7yTNgiY61P51VF7UilVtT4Tdm7yy3h bhdMey9s74Ec=; b=LQ9fJ5IMmECIdpnH4yghVG/Bdydex6jOj5/VFewzPsKvCcy z1DJ/0tJChvH9KKup59APnCupTjbgIWVtEKUgUccGOakDGLnxYGAH5tTjcXJYnHM nlpQJRCxcnayA8XpocgkDKgDPAlTNO0JUxVrp9Yx+8v4ddzjbWiAE3utlajkiuRJ An9P9VQgXyNw9J8wiR2V5mDcHjLn4R11dT1h57yzG7L4HPlogWMhCz/snge0rrId d0sUcJxbTsDepYrHHPeonY46EsEzlyxBv1Xq0Lf9XL+LxcQwxfqenOTHqHMNN6WX 27dKoWsmV4W30WLhuMBvNokcBBYbAKpQIFXK7OA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=D7yTNg iY61P51VF7UilVtT4Tdm7yy3hbhdMey9s74Ec=; b=pouqIOZMphtB9cCvcPKrgO hRi8IrhKW1XA4EFGl4k90s3t1GLCp39G2tJ7SEuM8miHLpX3LtAueMAWJFcsGtjw wRK+PIKxeMTZqm4pb+NLW/m6RIwPC9Hct2ssK4AeWmCzZCRh0mApb3cuiV7sywWH pmgcpWxGYRMCZV7xSPRJSgW1nLkjrg8Ai6ZSp1Iu9eTghZL5UgY5t0MQdXjS/ZXr oioGhScn48taWoI+2Lvgk6gpuEpn+eQm4RyhumvDr35RvNiWDvkNLWqPBqK8xNGf VqcY8oH2vxw5L1w2dVx8TWTLZqHjhY+6QvOn3PxwJOAW2g1E5qPNyQOoM5wbY82Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeduffeitddutd etgfegfeekgedvkeelvdeiiedtjeetteeuvdejveelleeltedtheenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsg hithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3AFF03C00A1; Wed, 3 Jun 2020 21:58:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <679ee3de-16af-4933-98f0-a30c3596ae1b@www.fastmail.com> In-Reply-To: <8cfd2e2d-7df7-4054-ba15-c9bc33cdc034@www.fastmail.com> References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> <8cfd2e2d-7df7-4054-ba15-c9bc33cdc034@www.fastmail.com> Date: Wed, 03 Jun 2020 18:58:04 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 01:58:27 -0000 On Wed, Jun 3, 2020, at 6:47 PM, Martin Thomson wrote: > On Thu, Jun 4, 2020, at 11:44, Eric Rescorla wrote: > > I think it would help to be more explicit here: > > Servers which are authenticating with a resumption PSK MUST NOT send > > the CertificateRequest message in the main handshake, [...], > > Servers which are authenticating with an external PSK MUST NOT send the > > CertificateRequest message either in the main handshake or in the > > post-handshake phase. Future specifications MAY provide an extension to > > permit this. > > That sounds great. I've a tiny tweak, but I will open an erratum with > that suggestion. That works for me, too. Thanks, Chris From nobody Wed Jun 3 19:04:38 2020 Return-Path: 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 5B9B53A0CCB for ; Wed, 3 Jun 2020 19:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AVoDFEWkBXY8 for ; Wed, 3 Jun 2020 19:04:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152553A0CCA for ; Wed, 3 Jun 2020 19:04:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E2F39F40757; Wed, 3 Jun 2020 19:04:16 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mt@lowentropy.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200604020416.E2F39F40757@rfc-editor.org> Date: Wed, 3 Jun 2020 19:04:16 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6205) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 02:04:37 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6205 -------------------------------------- Type: Editorial Reported by: Martin Thomson Section: 4.3.2 Original Text ------------- Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6). Corrected Text -------------- Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6). Servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message either in the main handshake or request post-handshake authentication. Future specifications MAY provide an extension to permit this. Notes ----- The lack of qualification on "authenticating with a PSK" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK. We know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs. For post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above. [...] It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints. For this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply. Splitting the requirements as proposed makes this split clearer. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Jun 3 19:34:52 2020 Return-Path: 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 32D0E3A0DA1 for ; Wed, 3 Jun 2020 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 mvDa6P-WYIdr for ; Wed, 3 Jun 2020 19:34:48 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A25E3A0DA6 for ; Wed, 3 Jun 2020 19:34:48 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id e16so4052949qtg.0 for ; Wed, 03 Jun 2020 19:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=xNw7XI92e4/+bBaw3hVJ0DTx9f3lxfQCPh0dvjGL7IE=; b=J3yEdbrvoMBBuoTMIkK5sm585m77zyazmQgvDWi5wx4k9zUPtAksOWREXHJHh4Scqb jVybApFd6jJdWnkUe7qkXcvC9a0qd4K3Fyc+/oe1AhzfNgMFx0OZQhQ747SjSyHBDOY0 K/v+daSuL1xbl6cj0i8v86Na3XgllvfBl130Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=xNw7XI92e4/+bBaw3hVJ0DTx9f3lxfQCPh0dvjGL7IE=; b=dizOsi8zVRnWzgwdi5iCh2+KVhTPowNXhKeBStTN89QKmcMiKn+siR2pCmWwwDEApD nvUcKyWwabFs+nnar+/Fc/rVoxTA7Oc4srB+hsyWAK6PSVuOh1ntpLdQykpkXRd95nrg 5X6lziBpaVCsZoL11tKYyoYIf4uXPLWbVEm6vSbB4JzfWYP3sWALo+j5IhgXXH6i3LUh DMQ5tm++kZfaa6HvvI93tlSYfSD0IFezlej4yWnsF1zTNwgs9vERVHXdkTrquc03ToC7 2KtDUwJZw/niLaV0BvGCWEbkyKwEIMhC2DRsnlbx/wQwqKjQUYi3Raep1mJqlaEgu1zO iwgg== X-Gm-Message-State: AOAM530SqBnP10CoCCidRJ4VpMXyu2S9xUYWMNUycXsVSGTh28eU03AV y15mvWsOrO5FXI+aI80BfplRAQnZVcY= X-Google-Smtp-Source: ABdhPJx+ApdHwtfGr8VKCmGKumvg8hJyo4fNu7aVHembbzI6W64GH0snCPyh5Y1p6g0B1zMIqH+Fqg== X-Received: by 2002:aed:2084:: with SMTP id 4mr1645447qtb.43.1591238087358; Wed, 03 Jun 2020 19:34:47 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id a1sm3079973qkn.87.2020.06.03.19.34.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 19:34:46 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Jun 2020 22:34:45 -0400 References: <150AD400-C080-4676-80DE-7A0EC0ECE7BD@sn3rd.com> To: TLS List In-Reply-To: <150AD400-C080-4676-80DE-7A0EC0ECE7BD@sn3rd.com> Message-Id: <2202537F-8569-4F68-8DD2-92B3F3CA1900@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] Progressing DTLS 1.3 (was Re: 3rd WGLC for draft-ietf-tls-dtls13) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 02:34:50 -0000 All, Changes introduced in -38 were well discussed on the list. The AEAD = limits are the notable exception however those changes are to address = findings discovered by security researchers. The chairs believe that -38 = is ready for AD review. spt (for the chairs) > On Mar 20, 2020, at 10:17, Sean Turner wrote: >=20 > This is the third working group last call for the "The Datagram = Transport > Layer Security (DTLS) Protocol Version 1.3" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > review the document and send your comments to the list by 2359 UTC on > 27 March 2019. >=20 > This is a targeted one-week WGLC intended to focus on the changes from = -34, which was the subject of the second working group last call, and = -37. The diffs between -34 and -37 can be found at: > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-34&url2=3Ddraft-= ietf-tls-dtls13-37 > As you will see in the diffs, the changes include 2119-language = related changes in s5.1 and s7. These two changes were introduced in = -35, which was post in November. >=20 > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/dtls13-spec >=20 > Thanks, > Chris, Joe, and Sean From nobody Thu Jun 4 08:46:43 2020 Return-Path: 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 202573A03ED for ; Thu, 4 Jun 2020 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UaPTSvfBvO2f for ; Thu, 4 Jun 2020 08:46:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31E23A03EA for ; Thu, 4 Jun 2020 08:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5599C300B6B for ; Thu, 4 Jun 2020 11:46:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9pjXjY6KKeJ2 for ; Thu, 4 Jun 2020 11:46:34 -0400 (EDT) Received: from [192.168.1.161] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id B5474300670; Thu, 4 Jun 2020 11:46:34 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1BC4B06A-FFD3-4380-BC2B-88150FAA86D8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 4 Jun 2020 11:46:35 -0400 In-Reply-To: Cc: IETF TLS To: Eric Rescorla , Martin Thomson References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 15:46:41 -0000 --Apple-Mail=_1BC4B06A-FFD3-4380-BC2B-88150FAA86D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: > On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > wrote: > I think that this is a useful erratum and it should be approved/HFDU. = The extension to which this text alludes is RFC 8773, not = post_handshake_auth. >=20 > Yes, although 8773 actually is not super-clear about post-handshake, = so that's actually something we should clarify there. RFC 8773 is not intended for post handshake. So, I never thought about = that. What is the use case you are considering? Russ --Apple-Mail=_1BC4B06A-FFD3-4380-BC2B-88150FAA86D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Eric:

On Wed, Jun = 3, 2020 at 6:07 PM Martin Thomson <mt@lowentropy.net> wrote:
I = think that this is a useful erratum and it should be = approved/HFDU.  The extension to which this text alludes is RFC = 8773, not post_handshake_auth.

Yes, although 8773 = actually is not super-clear about post-handshake, so that's actually = something we should clarify there.

RFC 8773 is not intended for post handshake.  So, = I never thought about that.  What is the use case you are = considering?

Russ

= --Apple-Mail=_1BC4B06A-FFD3-4380-BC2B-88150FAA86D8-- From nobody Thu Jun 4 08:47:45 2020 Return-Path: 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 981B03A03EA for ; Thu, 4 Jun 2020 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4GPWnYJrP5_9 for ; Thu, 4 Jun 2020 08:47:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2703A03ED for ; Thu, 4 Jun 2020 08:47:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE534300B3B for ; Thu, 4 Jun 2020 11:47:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EvwY7h5JmqaK for ; Thu, 4 Jun 2020 11:47:38 -0400 (EDT) Received: from [192.168.1.161] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B29A300670; Thu, 4 Jun 2020 11:47:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> Date: Thu, 4 Jun 2020 11:47:39 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <251D504E-B349-480E-A0D7-2E3B11A612B4@vigilsec.com> References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 15:47:44 -0000 Martin: > I think that this is a useful erratum and it should be approved/HFDU. = The extension to which this text alludes is RFC 8773, not = post_handshake_auth. >=20 > There is one other piece to this that is very confusing, and less = clear. >=20 > "Servers which are authenticating with a PSK MUST NOT send the = CertificateRequest message in the main handshake, though they MAY send = it in post-handshake authentication (see Section 4.6.2) provided that = the client has sent the "post_handshake_auth" extension (see Section = 4.2.6)." >=20 > The motivation is the attack that Sam Scott et. al. found in their = analysis of resumption: = https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ = However, this statement is unclear on whether it applies to external, = resumption, or both types of PSK, but without qualification as it is you = might be forgiven for thinking that it is both. >=20 > However, the document already says: >=20 > "It is unsafe to use certificate-based client authentication when the = client might potentially share the same PSK/key-id pair with two = different endpoints." >=20 > So I think that the right interpretation is that this statement = applies to "a resumption PSK" only. >=20 > If people agree with this interpretation, then I will file another = erratum of the form: >=20 > OLD: > Servers which are authenticating with a PSK MUST NOT send the = CertificateRequest message in the main handshake, [...] > NEW: > Servers which are authenticating with a resumption PSK MUST NOT send = the CertificateRequest message in the main handshake, [...] Works for me too. Russ From nobody Thu Jun 4 09:12:11 2020 Return-Path: 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 311A63A099E for ; Thu, 4 Jun 2020 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 uZp_Ki4AtcpW for ; Thu, 4 Jun 2020 09:12:04 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6D13A0994 for ; Thu, 4 Jun 2020 09:12:03 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id s1so8043247ljo.0 for ; Thu, 04 Jun 2020 09:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=psNM1/sVEKOOVt1XcwWAxV3MgzDV0tHgWD+EZEXp84w=; b=vZBpJErBGCwLTIeWY3ICNiPlFFwreDks3Chw96AqD93CsydNpgELa8KQF1ZI6nSHyW 7pcB/8yTmFM+d1A8UsqUNU8PFaBMswSbIgrmnl+7CSVBPovOe6KMbBzXrDuher5F5mq6 eJeY0gVyimpIc7n5477cFK6mqCJGegyWoUMdMwufCphmmR0Lb/oQ1BDcHs0Fcn1/LReC z4lXejd0qlL2EO0mICAFoLe82NOC5+5fLE5qtCguKZqhr7oHN2lY8n9rNRNUqxYoeotS rF1M8YgSWGWXgJnLxEdudAZ65suCrVfmu+tQWhAwhMEwsUTeQBulwNWKJqmzx8rPUjpb PYFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=psNM1/sVEKOOVt1XcwWAxV3MgzDV0tHgWD+EZEXp84w=; b=dAWTmHjg/w48Vi3ujoxnRf9DesGa/t11l/qB7a/lanRp808ckTecqA5wxQ5A5aZlDV sNcMWp7NrRiwdO3LfPcpAF40dnttr1uV7OJK8emdG4+rUMlYORrPXV7neOSSsz7wi2Yw Qr1vBSACeYWne65vga/nXSsmF6AO/9QmpWL6LxST/qQxOEiaDXyzKm0XOHyFVqeIoFoi dKKkahj/xba38xOzhw7o1AV6ywB/SXFdbeR+5q8oeN8WZpvaDkaHcWneS0mx83pKOk6N GOzIVEgdEeLamq4a7CfAFn5RRXy72LNnSeDQXWeAUDT2Sskbxo3mRtKhnpyYceww3y5e 5W+Q== X-Gm-Message-State: AOAM532K7XR/OHMVPTaKudHgV1FOBZVcX/ynLqx4MEIN2US/i5pI9VoR kpiq/wE8gqhVamCg0nZGG0pWdHEOAOYBgVoi51G/jeNniwg= X-Google-Smtp-Source: ABdhPJy9jOu/BPScNMLlmBE1Z8Isd/CEd05WG2gAq7bVzzDGIAAPxjqTEfucxdWShVdNt/DWwn2KBwAWngOWv03AysM= X-Received: by 2002:a2e:81d4:: with SMTP id s20mr2552412ljg.184.1591287121571; Thu, 04 Jun 2020 09:12:01 -0700 (PDT) MIME-Version: 1.0 References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Thu, 4 Jun 2020 09:11:25 -0700 Message-ID: To: Russ Housley Cc: Martin Thomson , IETF TLS Content-Type: multipart/alternative; boundary="0000000000009e035005a74467fe" Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 16:12:09 -0000 --0000000000009e035005a74467fe Content-Type: text/plain; charset="UTF-8" On Thu, Jun 4, 2020 at 8:46 AM Russ Housley wrote: > Eric: > > On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote: > >> I think that this is a useful erratum and it should be approved/HFDU. >> The extension to which this text alludes is RFC 8773, not >> post_handshake_auth. >> > > Yes, although 8773 actually is not super-clear about post-handshake, so > that's actually something we should clarify there. > > > RFC 8773 is not intended for post handshake. So, I never thought about > that. What is the use case you are considering? > I don't have one. I'm just trying to make sure things are clear. perhaps an erratum on 8773 to make ultra clear? -Ekr > Russ > > --0000000000009e035005a74467fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 4, 2020 at 8:46 AM Russ H= ousley <housley@vigilsec.com= > wrote:
Eric:

On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson <mt@lowentropy.net&g= t; wrote:
I thin= k that this is a useful erratum and it should be approved/HFDU.=C2=A0 The e= xtension to which this text alludes is RFC 8773, not post_handshake_auth.

Yes, although 8773 actually is not super= -clear about post-handshake, so that's actually something we should cla= rify there.

RFC 8773= is not intended for post handshake.=C2=A0 So, I never thought about that.= =C2=A0 What is the use case you are considering?

I don't have one. I'm just trying to make s= ure things are clear. perhaps an erratum on 8773 to make ultra clear?

-Ekr


Russ

 --0000000000009e035005a74467fe-- From nobody Thu Jun 4 09:24:48 2020 Return-Path: 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 0DE953A0A93 for ; Thu, 4 Jun 2020 09:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mUmP47odPm4i for ; Thu, 4 Jun 2020 09:24:45 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5093A0A90 for ; Thu, 4 Jun 2020 09:24:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6FE97300B67 for ; Thu, 4 Jun 2020 12:24:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BYZWvOravLNW for ; Thu, 4 Jun 2020 12:24:41 -0400 (EDT) Received: from [192.168.1.161] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id BEDD8300A3B; Thu, 4 Jun 2020 12:24:40 -0400 (EDT) From: Russ Housley Message-Id: <070E5A6D-7D2F-405A-B5D8-8C90379306D9@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_547FA8C8-2CC0-4864-A66B-9CE5F7EA2795" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 4 Jun 2020 12:24:41 -0400 In-Reply-To: Cc: Martin Thomson , IETF TLS To: Eric Rescorla References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 16:24:47 -0000 --Apple-Mail=_547FA8C8-2CC0-4864-A66B-9CE5F7EA2795 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: >> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > wrote: >> I think that this is a useful erratum and it should be approved/HFDU. = The extension to which this text alludes is RFC 8773, not = post_handshake_auth. >>=20 >> Yes, although 8773 actually is not super-clear about post-handshake, = so that's actually something we should clarify there. >=20 > RFC 8773 is not intended for post handshake. So, I never thought = about that. What is the use case you are considering? >=20 > I don't have one. I'm just trying to make sure things are clear. = perhaps an erratum on 8773 to make ultra clear? I do not find it unclear. What do you have in mind? Russ --Apple-Mail=_547FA8C8-2CC0-4864-A66B-9CE5F7EA2795 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Eric:

On Wed, Jun = 3, 2020 at 6:07 PM Martin Thomson <mt@lowentropy.net> wrote:
I = think that this is a useful erratum and it should be = approved/HFDU.  The extension to which this text alludes is RFC = 8773, not post_handshake_auth.

Yes, although 8773 = actually is not super-clear about post-handshake, so that's actually = something we should clarify there.

RFC 8773 is not intended for post handshake.  So, = I never thought about that.  What is the use case you are = considering?

I don't have one. I'm just trying to = make sure things are clear. perhaps an erratum on 8773 to make ultra = clear?

I do not find it unclear.  What do you have in = mind?

Russ

= --Apple-Mail=_547FA8C8-2CC0-4864-A66B-9CE5F7EA2795-- From nobody Thu Jun 4 09:38:05 2020 Return-Path: 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 203D83A0DAD for ; Thu, 4 Jun 2020 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 tL6ylyGNnz7J for ; Thu, 4 Jun 2020 09:37:56 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D4F3A0D12 for ; Thu, 4 Jun 2020 09:37:55 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id c17so8090124lji.11 for ; Thu, 04 Jun 2020 09:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J0/WQu8/0quVezHK6P9GmIRCDFKFkSLn/dSydy53rfo=; b=b2Hg9WGR/Fu/njig6Db1wNByk1W6frzMU4qxdrTwotaFZu8vNBkA5DS5DxiZPnGvIb UfmJlL8XNDZKzaMH91npH9FJgeiMl4k3iusk7qZFp3GfHdnVnFZR+qTI/XpF6Np5hQa4 nuSpR2ogIpa81qljik4kERXaQjJmkFXbLrllg1I+DRKMExiXB6Emc2OFmpEH6gpC3UyU OQxOoFQcYwzkMe4q62Xroh5RlpNDLYehff10thSgXJwJBwKMGCBUbTMM9eQGQmLysHia iT2RD1PHLh9w7iQ6GQU31l9RuQkIsUPbf5TGKTS+arWj/x7UO1K/hG75K+U0z6OYiNE2 2uUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J0/WQu8/0quVezHK6P9GmIRCDFKFkSLn/dSydy53rfo=; b=ptxj+tN0tlDBDuaOqrWx2hMnAtIyiJqN0W4Hv11n6OUE5gSGUaWPQtFcfKVxEBFznF GJBGdkRGjguH8qcS9wXqipkbCL7JTCAxZ/r3KaKVqKeXWl9/s5TqTjUIpFnkyw4e7aL4 jYbBbObnu10CUVKae5yWYYDP6iFy1xVktzQwdA8cYnt559WOoIzlhAODxMb6uUf7gMaA phxgQ30jKZPbRun84EEXtKsw5QxdOp/GhdGQDIVartf+pJLCQFql6kWMYLxMwqHNhLVv aObRh5pL7OmxB8KLzlarw51Xd+cZgSCaeV56PprhRVSfUfagoGhpqt3ji087PQitcC9Y OcgQ== X-Gm-Message-State: AOAM533fgHY4To1FLrR4gnFTojIEE1Wk2w9iAVm6RWGuN6qe9kI1MJ5y 1IA5TTYSzejD6V+IsyeBsTizK8eZZI403LpFGafnAg== X-Google-Smtp-Source: ABdhPJz0eYU5Du7r/4GlghjjooqeLsxHc65UK7nBhEFOk8drExKJETBr8OFOgZxmtbup8jXFRHwx/ORXfY0acGHQFmM= X-Received: by 2002:a2e:3609:: with SMTP id d9mr2429215lja.409.1591288673575; Thu, 04 Jun 2020 09:37:53 -0700 (PDT) MIME-Version: 1.0 References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> <070E5A6D-7D2F-405A-B5D8-8C90379306D9@vigilsec.com> In-Reply-To: <070E5A6D-7D2F-405A-B5D8-8C90379306D9@vigilsec.com> From: Eric Rescorla Date: Thu, 4 Jun 2020 09:37:17 -0700 Message-ID: To: Russ Housley Cc: Martin Thomson , IETF TLS Content-Type: multipart/alternative; boundary="0000000000001fd61105a744c4f6" Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 16:38:04 -0000 --0000000000001fd61105a744c4f6 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 4, 2020 at 9:24 AM Russ Housley wrote: > Eric: > > On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson wrote: >> >>> I think that this is a useful erratum and it should be approved/HFDU. >>> The extension to which this text alludes is RFC 8773, not >>> post_handshake_auth. >>> >> >> Yes, although 8773 actually is not super-clear about post-handshake, so >> that's actually something we should clarify there. >> >> >> RFC 8773 is not intended for post handshake. So, I never thought about >> that. What is the use case you are considering? >> > > I don't have one. I'm just trying to make sure things are clear. perhaps > an erratum on 8773 to make ultra clear? > > > I do not find it unclear. > I am looking at 5.2 which seems like it could be more precise. > What do you have in mind? > Changing: TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. To: TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. To: TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. To: TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed for the main handshake when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. This extension has no impact on external PSK usage with post-handshake authentication, which is prohibited by TLS 1.3. -Ekr Russ > > --0000000000001fd61105a744c4f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 4, 2020 at 9:24 AM Russ H= ousley <housley@vigilsec.com= > wrote:
Eric:

=
On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson <mt@lowentropy.net> wrote:<= br>
I think that thi= s is a useful erratum and it should be approved/HFDU.=C2=A0 The extension t= o which this text alludes is RFC 8773, not post_handshake_auth.

Yes, although 8773 actually is not super-clear abo= ut post-handshake, so that's actually something we should clarify there= .

RFC 8773 is not in= tended for post handshake.=C2=A0 So, I never thought about that.=C2=A0 What= is the use case you are considering?
I don't have one. I'm just trying to make sure things = are clear. perhaps an erratum on 8773 to make ultra clear?
<= /div>

I do not find it unclear. =C2=A0

I am looking at 5.2 which se= ems like it could be more precise.

=C2=A0
What do you have in mind?

= Changing:
=C2=A0 =C2=A0TLS 1.3 does not permit the server to send a Cert= ificateRequest
=C2=A0 =C2=A0message when a PSK is being used. This restr= iction is removed when
=C2=A0 =C2=A0the "tls_cert_with_extern_psk&q= uot; extension is negotiated, allowing
=C2=A0 =C2=A0certificate-based au= thentication for both the client and the
=C2=A0 =C2=A0server.=C2=A0To: T= LS 1.3 does not permit the server to send a
=C2=A0 =C2=A0CertificateRequ= est message when a PSK is being used. This restriction
=C2=A0 =C2=A0is r= emoved when the "tls_cert_with_extern_psk" extension is
=C2=A0= =C2=A0negotiated, allowing certificate-based authentication for both the=C2=A0 =C2=A0client and the server.

To:
=C2=A0 =C2=A0TLS 1.3 do= es not permit the server to send a CertificateRequest
=C2=A0 =C2=A0messa= ge when a PSK is being used. This restriction is removed when
=C2=A0 =C2= =A0the "tls_cert_with_extern_psk" extension is negotiated, allowi= ng
=C2=A0 =C2=A0certificate-based authentication for both the client and= the
=C2=A0 =C2=A0server.=C2=A0To: TLS 1.3 does not permit the server to= send a
=C2=A0 =C2=A0CertificateRequest message when a PSK is being used= . This
=C2=A0 =C2=A0restriction is removed for the main handshake when t= he
=C2=A0 =C2=A0"tls_cert_with_extern_psk" extension is negoti= ated, allowing
=C2=A0 =C2=A0certificate-based authentication for both th= e client and the
=C2=A0 =C2=A0server. This extension has no impact on ex= ternal PSK usage
=C2=A0 =C2=A0with post-handshake authentication, which = is prohibited by
=C2=A0 =C2=A0TLS 1.3.
=C2=A0=C2=A0
-Ekr

Russ

--0000000000001fd61105a744c4f6-- From nobody Thu Jun 4 10:54:59 2020 Return-Path: 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 D8D563A095A for ; Thu, 4 Jun 2020 10:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9jPolzh29UCb for ; Thu, 4 Jun 2020 10:54:56 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D023A08F6 for ; Thu, 4 Jun 2020 10:54:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 71537300B0C for ; Thu, 4 Jun 2020 13:54:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fVuAAFnJrZr5 for ; Thu, 4 Jun 2020 13:54:51 -0400 (EDT) Received: from [192.168.1.161] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 296FB300670; Thu, 4 Jun 2020 13:54:51 -0400 (EDT) From: Russ Housley Message-Id: <466C44E4-2416-4FE2-AED0-F7DBE1EEFB21@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0019019F-6DF9-47EF-BA96-76846FA79E18" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 4 Jun 2020 13:54:51 -0400 In-Reply-To: Cc: Martin Thomson , IETF TLS To: Eric Rescorla References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> <070E5A6D-7D2F-405A-B5D8-8C90379306D9@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2020 17:54:58 -0000 --Apple-Mail=_0019019F-6DF9-47EF-BA96-76846FA79E18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 4, 2020, at 12:37 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Thu, Jun 4, 2020 at 9:24 AM Russ Housley > wrote: > Eric: >=20 >>> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > wrote: >>> I think that this is a useful erratum and it should be = approved/HFDU. The extension to which this text alludes is RFC 8773, = not post_handshake_auth. >>>=20 >>> Yes, although 8773 actually is not super-clear about post-handshake, = so that's actually something we should clarify there. >>=20 >> RFC 8773 is not intended for post handshake. So, I never thought = about that. What is the use case you are considering? >>=20 >> I don't have one. I'm just trying to make sure things are clear. = perhaps an erratum on 8773 to make ultra clear? >=20 > I do not find it unclear. =20 >=20 > I am looking at 5.2 which seems like it could be more precise. >=20 > =20 > What do you have in mind? >=20 > Changing: > TLS 1.3 does not permit the server to send a CertificateRequest > message when a PSK is being used. This restriction is removed when > the "tls_cert_with_extern_psk" extension is negotiated, allowing > certificate-based authentication for both the client and the > server. To: TLS 1.3 does not permit the server to send a > CertificateRequest message when a PSK is being used. This = restriction > is removed when the "tls_cert_with_extern_psk" extension is > negotiated, allowing certificate-based authentication for both the > client and the server. >=20 > To: > TLS 1.3 does not permit the server to send a CertificateRequest > message when a PSK is being used. This restriction is removed when > the "tls_cert_with_extern_psk" extension is negotiated, allowing > certificate-based authentication for both the client and the > server. To: TLS 1.3 does not permit the server to send a > CertificateRequest message when a PSK is being used. This > restriction is removed for the main handshake when the > "tls_cert_with_extern_psk" extension is negotiated, allowing > certificate-based authentication for both the client and the > server. This extension has no impact on external PSK usage > with post-handshake authentication, which is prohibited by > TLS 1.3. This works for me. I wonder if "initial handshake" would be better than = "main handshake" Russ --Apple-Mail=_0019019F-6DF9-47EF-BA96-76846FA79E18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jun 4, 2020, at 12:37 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Thu, Jun 4, 2020 at 9:24 AM Russ = Housley <housley@vigilsec.com> wrote:
Eric:

On Wed, Jun 3, 2020 at 6:07 PM Martin = Thomson <mt@lowentropy.net> wrote:
I = think that this is a useful erratum and it should be = approved/HFDU.  The extension to which this text alludes is RFC = 8773, not post_handshake_auth.

Yes, although 8773 = actually is not super-clear about post-handshake, so that's actually = something we should clarify there.

RFC 8773 is not intended for post handshake.  So, = I never thought about that.  What is the use case you are = considering?

I don't have one. I'm just trying to = make sure things are clear. perhaps an erratum on 8773 to make ultra = clear?

I do not find it unclear. =  

I am looking at 5.2 which seems like it = could be more precise.

 
What do you have = in mind?

Changing:
   TLS 1.3 does = not permit the server to send a CertificateRequest
  =  message when a PSK is being used. This restriction is removed = when
   the "tls_cert_with_extern_psk" extension = is negotiated, allowing
   certificate-based = authentication for both the client and the
  =  server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being = used. This restriction
   is removed when the = "tls_cert_with_extern_psk" extension is
  =  negotiated, allowing certificate-based authentication for both = the
   client and the server.

To:
   TLS 1.3 does not permit the = server to send a CertificateRequest
   message = when a PSK is being used. This restriction is removed when
   the "tls_cert_with_extern_psk" extension is = negotiated, allowing
   certificate-based = authentication for both the client and the
  =  server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being = used. This
   restriction is removed for the = main handshake when the
  =  "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the = client and the
   server. This extension has no = impact on external PSK usage
   with = post-handshake authentication, which is prohibited by
 =  TLS 1.3.

This works for me.  I wonder if "initial = handshake" would be better than "main handshake"

Russ


= --Apple-Mail=_0019019F-6DF9-47EF-BA96-76846FA79E18-- From nobody Thu Jun 4 18:48:29 2020 Return-Path: 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 AB3B43A1126 for ; Thu, 4 Jun 2020 18:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 4HI8_sKbjATg for ; Thu, 4 Jun 2020 18:48:26 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6273A1124 for ; Thu, 4 Jun 2020 18:48:26 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id w9so7260133qtv.3 for ; Thu, 04 Jun 2020 18:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=iWgdjzVvBAP0+2AHA4HYcMARtdj+qgsHbUwHKp5zKY8=; b=YBcOC+AquFoOoTeQdKa7Hz6soAA2JSA38iUAfRn84cvf3Dlpb2bvacquMTRuowOaHn rIjFGD8chzQRTTMTgfoedwoTvpoDDRQ6bOxZgxmLJJIaqJo785mIVSxS/0l+nM+bCvUs x7rxm2hcRpPGJ4vrUCb6tWnsWjPb0Do7TqgWk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=iWgdjzVvBAP0+2AHA4HYcMARtdj+qgsHbUwHKp5zKY8=; b=dyS4n5RWdy5jXsblbv3d+tZGCe90R7NCH8hv0bHcih7wi6jXAMZBu67p9Xk6ejxov2 kcDXlyk31BOpBmOD3m6vOrXFLZ/x5/rBMhANxojciPPAxQp1NW8ShFJPY9JVMn1FLjlX fd4tNOxU1NT3Y9y5gp3pno2rOqmQzR4JrdrC7W5cG0DtyetlxZSMozqTTyiZEPHyXtuc OJVOzSfbfqiDyW8j2bjRBLMEgVwu1F+pS9HGvveqq7usAiWvOsAZiL1mxusrYnEwoBnY VMzsvjNZqQNUvE0nZ2ukffROPe1Z7pCxHBnqogy0rEUNXmXU7UWguL2RQYIsqSqmTFE3 3bqA== X-Gm-Message-State: AOAM530fCRBsoA1CPfFGKok8bAlHjmVkr9oFjUfT3DsrUHtiB+2Kx38d nk8boa+gHO3ld41NGDg0V5hcxZChe+c= X-Google-Smtp-Source: ABdhPJzdavVVyNWKf9x2UMSIM6yBEUVNjwH3sQoLlW9V73l5lVIVZ+mBqWMMHMVCrDwXw4Krr4IAog== X-Received: by 2002:ac8:895:: with SMTP id v21mr7574740qth.185.1591321705295; Thu, 04 Jun 2020 18:48:25 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 185sm5831228qke.92.2020.06.04.18.48.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 18:48:24 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 4 Jun 2020 21:48:24 -0400 References: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> To: TLS List In-Reply-To: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> Message-Id: <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-exported-authenticators 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 01:48:28 -0000 Another reminder ... > On May 22, 2020, at 09:23, Sean Turner wrote: >=20 > This is the 3rd WGLC for "Exported Authenticators in TLS" draft = available at = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. = The secdir review during IETF LC raised some issues and as a result = there have been a couple of new versions. Please respond to the list = with any comments by 2359 UTC on 8 June 2020. >=20 > Cheers, > spt (for the chairs) From nobody Fri Jun 5 04:29:31 2020 Return-Path: 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 A3CA43A148D for ; Fri, 5 Jun 2020 04:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 H2MvGAf6l7RQ for ; Fri, 5 Jun 2020 04:29:28 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FCD3A1488 for ; Fri, 5 Jun 2020 04:29:28 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id h188so5575119lfd.7 for ; Fri, 05 Jun 2020 04:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fExovZiYu5XU4O6Pn5zneMS2200B9lA9lpayoSZgJlg=; b=CF0PVpBdnimtlND2nPnvgPdyLHga2QfTMxcjRSnhHHMbEmYvrOEK3S/SAPwL9vYsDT gRAiqOqPKvCZ0Jw+rbixbtErDCDocZTbMCK3NnlsqGk2IAkcb/0ax/b/uLsBZE6Pr5mr y4tPcdEXaKTERvJZ0lPBKxcTp8qnU8zQyR27+jg7/NeUFLHwSbQnBbc5s8GsUiagwbMO 2bG40WNMmX2MNpSAJGmvg07oHMsh9ATl44rTnY8xL110YETf5ZXVzWLcbSF/RJRheJcd aS6gKWtATlUTCr5on1KCtvfVNxcHa/77vSOmXNP7k8btfC3k95iqMkJWwupCqIx2Bh/b 5dCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fExovZiYu5XU4O6Pn5zneMS2200B9lA9lpayoSZgJlg=; b=a1/hRDdtN6aDGRX5ybuAiT7iIMlH6FuALvNQ8GJTSiVeBj4exfhnus9kvEE6gbVvPl mAyJ9K/ovNsaZhx4J+/4qquyHko/ZLw73m7V8SxmQOAvaiO6XQypidrOiuRWMtn067mH /eQXTzwsDo+MEwrearB0yHMnCkIshJkfcFOvyBXvIWTDymeNRSwSpYA3VT+1BHx3yiVd 6TpGIbw1xcbhGrp4yW/WaVp2J4Z0uRGfUb/efybobysk9ggdKWhVWWA11R4ZG+n3f3ht g/l/idlpZpi2buJWWdXkqU28NqKLg0x+T0sK0SZsDKvW5BCv5kCSAJnpa7T1GW4uYGw1 gsZg== X-Gm-Message-State: AOAM531KyTaxIDFZtv1i/0KOgfKHRtyqaw/wYgqYxclYROs/I/w68zM1 TEDzGcP8Lzm6MMCmi5haEPhtRQHI2Q+lOhmJgqQ= X-Google-Smtp-Source: ABdhPJy/oyRCAWKdwlLXvPIMfE7YCFrIBpvz2vnczpRAps5lWKeYAGAuAUvchtb8bUZe7I6PmKY9O8VYB0Bwlo+TBCQ= X-Received: by 2002:ac2:4641:: with SMTP id s1mr5114849lfo.147.1591356564426; Fri, 05 Jun 2020 04:29:24 -0700 (PDT) MIME-Version: 1.0 References: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> In-Reply-To: <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> From: Watson Ladd Date: Fri, 5 Jun 2020 07:29:13 -0400 Message-ID: To: Sean Turner Cc: TLS List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-exported-authenticators 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 11:29:30 -0000 On Thu, Jun 4, 2020 at 9:48 PM Sean Turner wrote: > > Another reminder ... > > > On May 22, 2020, at 09:23, Sean Turner wrote: > > > > This is the 3rd WGLC for "Exported Authenticators in TLS" draft availab= le at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticato= r/. The secdir review during IETF LC raised some issues and as a result the= re have been a couple of new versions. Please respond to the list with any = comments by 2359 UTC on 8 June 2020. I've implemented earlier drafts. I do have a concern with the validate API as presented in the draft: it treats empty authenticators as valid, and then returns the identity as a certificate chain that must be validated by the application. Similar APIs have lead to easily foreseeable pwnage. Instead I would recommend the validate API carry out X509 validation against a trust store or validation function and treat the empty authenticator as invalid. That way someone has to think before not checking the certificate returned. Sincerely, Watson Ladd From nobody Fri Jun 5 08:05:58 2020 Return-Path: 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 C1A2B3A05A0 for ; Fri, 5 Jun 2020 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 PYxFIlVl-61H for ; Fri, 5 Jun 2020 08:05:54 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38CF3A05A4 for ; Fri, 5 Jun 2020 08:05:53 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id q14so8682575qtr.9 for ; Fri, 05 Jun 2020 08:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=1lSNbHamfmfljDozu4jwnGfq8/vcbSkh/cFEluv6S/8=; b=k+x1pqTJHepMHcMWbE556D1iwmSh03D+B7cJ7Ho/w4RES8qY6xz9ymuyBEkgPCFSff 6fEyH3TfiaR1UGB+5eiHwtew3S/KoK9lKpsrES8d+boLhZyeUUPNNzypdqPfdNL9DBUS RgzNCfXcCnL71Ih2bhUWj4W+WXfRMW+Zk9o0w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=1lSNbHamfmfljDozu4jwnGfq8/vcbSkh/cFEluv6S/8=; b=arFaNjwRuAGLhHQY6bvTtYlj7A5Qu/fXctZykAXFLfB5GaW3NaYztNf6J7lQK/qD+j mZPtkcl8RVlScORk8G3z+Qlt3y0Y+XX3rMuTcEXbNcVMOAB3Xg9n3wuY+4JHdmQ63SBI y98EEczWBisqgoOBU4KLQerB2eFs0ayzNAxWnbAUikckYLjRB772aRexwiAb1vEkksM3 Hxcmx5xW/7sGMUfpiLBXu9yAHBwyHzj9T7XOq5qZ5xZ4H7SiRwflXBchTyajAKlPYRgF KO7D++m/Z7z8OlzSJrktaxec0Iw8znH7cKpf8/u7Fe5B8oKZlR9pemaEsYS2mK6irkA2 wW4Q== X-Gm-Message-State: AOAM532NVQPvy2Kh7CiPz28GpoOIGALP0ZwqxJnMZoAzZT6loUyxPKjE doiklE2vE4DkMZIRkRkQ/U2xJXW4CYI= X-Google-Smtp-Source: ABdhPJwqlF0jG3G3FM2Hy0ekFkrjOAAIgNiDJRTj9dDYsgpVvbIaMAsNUO8RnIhO0JMpWSA5iwEbWw== X-Received: by 2002:ac8:3382:: with SMTP id c2mr10213628qtb.356.1591369552806; Fri, 05 Jun 2020 08:05:52 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id a27sm8012513qtc.92.2020.06.05.08.05.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:05:52 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 5 Jun 2020 11:05:51 -0400 References: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> To: TLS List In-Reply-To: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 15:05:56 -0000 Just a reminder that this call ends today. So far we=E2=80=99ve only seen one response. I think I can safely say = assume that the 12 people on the DT agree, but let me know I got that = wrong. spt > On May 21, 2020, at 22:12, Sean Turner wrote: >=20 > This is a WG document adoption call for = draft-dt-tls-external-psk-guidance (aka Guidance for External PSK Usage = in TLS). This effort was kicked off @IETF106 by Ben Kaduk and supported = by others in the audience. There was also some nominal amount of support = for adopting the draft at the last virtual interim though no formal = adoption call was issued at the interim. >=20 > If you support adopting this draft as a WG Document, then please send = email indicating your support to the list. If you have any comments or = reservations send them to the list too. >=20 > This adoption call completes at 2359 UTC 5 June 2020. >=20 > Cheers, > spt (for the chairs) From nobody Fri Jun 5 08:33:08 2020 Return-Path: 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 58E463A07DF for ; Fri, 5 Jun 2020 08:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 TNe7ZLKvmwLz for ; Fri, 5 Jun 2020 08:33:05 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1DD3A07D6 for ; Fri, 5 Jun 2020 08:33:04 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id 59so3435099uam.7 for ; Fri, 05 Jun 2020 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qsRv1od9MVqZ4nLMfQ7DRr9qU/Bm4hiD1/WZfX77X4A=; b=JND5BLOi/i7jiSmCM89FvfMKKG+iSgU4NrkTo5A+tRcQSc/mb0/ABMOmm2wfIFjuuc Gtie+iNI/IIYJuXeS4qR53wkmetMioqryF12/gG7Srj6WiDS5AvJ81sKhP8CDXdqHzE8 iVhyhcPauXQmniTdiNHt4ywmebcXJLvPV70OdaQnstc89vZtr0cDXs/02/9GI+6fg0pE 6hhLlnp9QlyNesod11XiSvDeYhzfg5qopD0TKTX6OOxqD8Zpgb2Z31JDcutK22l4n2aq VnB0IuI5UUs0VAysm+4vFFbOkqHTHzzmXprkNWWhoLsVCnxqrVibZpCZhELC99DIs815 cH+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qsRv1od9MVqZ4nLMfQ7DRr9qU/Bm4hiD1/WZfX77X4A=; b=FlAJYd60lDW1oCeK3GdBhn5SkCqNgZKYxHx1mRKPXx822H2yt5F3dCpLV8D7W5TfkD 3gMVybqBF3YhX43MsGxaIbpbyrqadGaS1voU+/V5x7ejyBXNumSnqWx/J/M0Zesh2PpT 5U36ppC0FSLllw8VvggZqP0h2Iqjg7yGsdfIcxIVSFvjfhZ8jEJ6GXn878+lk56qqojq U/zbIr+3zjKHHgPLJD9B2oBwqeAREoluXvZq6dijy7ZZ5sFOHtlfOZVbGQfHtfPfyU6k 7vhJogRWQiqJoC7YY1bvdcsVJCYN7VNt1oeJuwBK71r5HwS9ZUd8a+D/T6QxXaxsdHkW wYEg== X-Gm-Message-State: AOAM5330lO3BKP72IOR14go/sFRvrler7OK7uwKyUYp1oL3SurtIgZRz T/XFHbNN9Q4gdCBihJQ2KM2l3T55ny+BCWycaRs= X-Google-Smtp-Source: ABdhPJzg/y/F/GqF3YteIoiAsz12l+qlohAk1cKiWe3+e1ueBNNimGCPNbkNCew3u57WFy62RKfY5djHWZvX3DaNNmI= X-Received: by 2002:ab0:7715:: with SMTP id z21mr8019408uaq.139.1591371183892; Fri, 05 Jun 2020 08:33:03 -0700 (PDT) MIME-Version: 1.0 References: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> In-Reply-To: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> From: Ira McDonald Date: Fri, 5 Jun 2020 11:32:51 -0400 Message-ID: To: Sean Turner , Ira McDonald Cc: TLS List Content-Type: multipart/alternative; boundary="0000000000001f33d905a757fadc" Archived-At: Subject: Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 15:33:07 -0000 --0000000000001f33d905a757fadc Content-Type: text/plain; charset="UTF-8" +1 for TLS WG adoption. Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Co-Chair - TCG Metadata Access Protocol SG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com (permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, May 21, 2020 at 10:12 PM Sean Turner wrote: > This is a WG document adoption call for draft-dt-tls-external-psk-guidance > (aka Guidance for External PSK Usage in TLS). This effort was kicked off > @IETF106 by Ben Kaduk and supported by others in the audience. There was > also some nominal amount of support for adopting the draft at the last > virtual interim though no formal adoption call was issued at the interim. > > If you support adopting this draft as a WG Document, then please send > email indicating your support to the list. If you have any comments or > reservations send them to the list too. > > This adoption call completes at 2359 UTC 5 June 2020. > > Cheers, > spt (for the chairs) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001f33d905a757fadc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for TLS WG adoption.

Ira McDonald (Musician / Sof= tware Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
= Co-Chair - TCG Metadata Access Protocol SG
Chair = - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Workin= g Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF D= esignated Expert - IPP & Printer MIB
Blue Roof Music / High North In= c
http://sites.google.com/site/blueroofmusi= c
http://sites.google.com/site/highnorth= inc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221=C2=A0 Grand Mara= is, MI 49839=C2=A0 906-494-2434

<= /div>

On Thu, May 21, 2020 at 10:12 PM Sean Turner <sean@sn3rd.com> wrote:
This is a WG document adoption call for draft-dt= -tls-external-psk-guidance (aka Guidance for External PSK Usage in TLS). Th= is effort was kicked off @IETF106 by Ben Kaduk and supported by others in t= he audience. There was also some nominal amount of support for adopting the= draft at the last virtual interim though no formal adoption call was issue= d at the interim.

If you support adopting this draft as a WG Document, then please send email= indicating your support to the list. If you have any comments or reservati= ons send them to the list too.

This adoption call completes at 2359 UTC 5 June 2020.

Cheers,
spt (for the chairs)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001f33d905a757fadc-- From nobody Sun Jun 7 00:32:47 2020 Return-Path: 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 D8CD83A0B62 for ; Sun, 7 Jun 2020 00:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=pQEcbAWk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=smvkQaM2 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 npAQUh9nLk2d for ; Sun, 7 Jun 2020 00:32:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914FB3A09FA for ; Sun, 7 Jun 2020 00:32:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DE87C5C00A6 for ; Sun, 7 Jun 2020 03:32:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 07 Jun 2020 03:32:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=jyez7cztG1M3ZOXPAsIl0fbmbcjIUJX5MVKG14ye6Dw=; b=pQEcbAWk a86eP4T6ugeHpb9Omvz7TBZqnVlx+OALhKrY56dmBi73ntN69i9JQ4ezeeM6AAv7 5dyH4uUDDfxnW/qa7Kiw5dF1D/HakTyBQi8UmyXg4dtE9yNcIJ2ytifnci1YdL21 frHr+1aCXiGrycdZhamKshHcd9xdbCkfIBbw7ZjigOx2zAXNApE4Q/wi3RGrFV/W XFEtyhZiYpVwoS1W9xDfop4RB7fyrcqJZc++WSNm8VqlGYX9uj4I+xIyW5t8mfJC yd9wwmX512QzgyGxpCNi+5L+9Rrae4y30Jy1U06vEtMbmxiXeWQTmcI+YzZ2N/oI e9Z1wR8d0WO4gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=jyez7cztG1M3ZOXPAsIl0fbmbcjIU JX5MVKG14ye6Dw=; b=smvkQaM2eHzz0Hvwi9p39bPuXOerAp2viW8XQE0HTxrh0 5EnaiUZBNN4KJi6KvyyClS0DBLEEUecPnO0aWJI/COVc3acEgeKK7gxDzvqf6/Qw gRugWPjQ/xa0xU5pB3MoU0qv1lENCNA/Se5RPi2ZYnpGyfJwe9x/+18dYIlFWYJX Slr96kxtfJabyFB2nW1tuKCwh6m4XpCV1MVa/s0z9YwHM32HJLF5CUx2MNacMKdy A1tpXe8eqZoVf7NeXagO71qqU8THW4Ga1mL7AiwQZ7D2ZGInTXcXZH5NCFP6U0TD 6BFYtoFe5n+BLRyWg2WoaENEmArOF6suq1GBBHSSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepgedtrdeihedruddufedrud efvdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [40.65.113.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 8CA14328005A for ; Sun, 7 Jun 2020 03:32:37 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8014099194050338888==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200607073237.8CA14328005A@mailuser.nyi.internal> Date: Sun, 7 Jun 2020 03:32:37 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 07:32:45 -0000 --===============8014099194050338888== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-subcerts (+7/-0/=F0=9F=92=AC0) 7 issues created: - There is something wrong with the formatting of the numbered list in Se= ction 4.1.3. (by grittygrease) https://github.com/tlswg/tls-subcerts/issues/71=20 - [WGLC] Nits (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/70=20 - [WGLC] Note problems with DCs having lifetimes matching issuing certifi= cates (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/69=20 - [WGLC] Address client clock skew (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/68=20 - [WGLC] Clarify extension vs EKU usage (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/67=20 - [WGLC] Clarify compromise text (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/66=20 - [WGLC] (by chris-wood) https://github.com/tlswg/tls-subcerts/issues/65=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+3/-3/=F0=9F=92=AC1) 3 pull requests submitted: - Fix typo of "ClientHelloInner". (by dmcardle) https://github.com/tlswg/draft-ietf-tls-esni/pull/244=20 - empty or random record digest for privacy (by huitema) https://github.com/tlswg/draft-ietf-tls-esni/pull/243=20 - Revert to experimental codepoints. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/242=20 1 pull requests received 1 new comments: - #242 Revert to experimental codepoints. (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/242=20 3 pull requests merged: - empty or random record digest for privacy https://github.com/tlswg/draft-ietf-tls-esni/pull/243=20 - Fix typo of "ClientHelloInner". https://github.com/tlswg/draft-ietf-tls-esni/pull/244=20 - Revert to experimental codepoints. https://github.com/tlswg/draft-ietf-tls-esni/pull/242=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============8014099194050338888== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday June 07, 2020

Issues

tlswg/tls-subcerts (+7/-0/=F0=9F=92=AC0)

7 issues created:

Pull requests

tlswg/draft-ietf-tls-esni (+3/-3/=F0=9F=92=AC1)

3 pull requests submitted:

1 pull requests received 1 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============8014099194050338888==-- From nobody Sun Jun 7 01:25:36 2020 Return-Path: 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 2DE233A0C26 for ; Sun, 7 Jun 2020 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 E3HdFrLDIn1d for ; Sun, 7 Jun 2020 01:25:32 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (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 A22ED3A0C21 for ; Sun, 7 Jun 2020 01:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q0Ty8TEZdWbP/FuKI2pql3xGhmfc5PZsYN+tGY5KUg0MEpcnWQaN6kPFYfPtuPmt+HpOoxKnHL771T/gAMLXnCwlvDhrRuJsTv0wOnp1TBVVJTzZOJvoYLBoM9cvnkCmEdNrgsHKmYGaZ7YecP1lah7iG/8H/iDLFn8670vOkSIxgZ8afVnowvk4NE9gk6mRG+ETX1GBAF930xmmh+kUDJbIaVnegRClFVbISD+UGz9DrJ8iDW/DcYiGFoClwWapo2BX2CJjDMTjDtB3/6zehefK/99mvuDYFMQekQHCtnbbl4rg/IQ+2d36H89lcYx64lygwMkZCfiKHo/JzVuQmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HAKSFSjeiG+q1vTTvXkQBFEfGhicu+6UBmSeUj9/zQI=; b=D/lNVJC6BhhJf7eSmnB6bTKvOzBUQLXwlKXNIO96WdFzqROG57TjSVWGX8sVkUtFQiHZUCdVJeZ1YjKF9TEYz5rdh3pV+Wgd4GXfotZBPaNx4WM053ffxMpwtVUzLIRHvQ83636+DVJekAYQ2d2TvTkNuMxJH6RiFKMuM3nv9nMJRpqfYDx8OhTmFRYcQcIJoexwmKm7kebLt+yrjYa6mmMgjSgPEK7weKUZCX+F7YiPDVX/vX0qHaqOEBBT42mKANgDvV9B8g2zqIYFPQ6saRrK/nl4brdTljp1CyIbR8UpHM1XJAs/vI5IYw1/kH/23xQftI5Jko1g24X7QloxUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HAKSFSjeiG+q1vTTvXkQBFEfGhicu+6UBmSeUj9/zQI=; b=tqqWnJIYRAPNO2U5icLrIxVOLJeRMcdMOG0s1uaxLrdnmfyo4DfxOq+qwctX50W3ZSuNT3byJbwfdYmzycWWJKt2wAYpj5H42spwZWoKs7+1JsevAWxgg6d0vGo/XEJf3TTNiIu+tkn+QNa5izLN2Y4VySCBez2Ep+xbxjwx2ig= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2252.eurprd07.prod.outlook.com (2603:10a6:3:29::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9; Sun, 7 Jun 2020 08:25:27 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::2569:99db:f1db:4f8e%7]) with mapi id 15.20.3088.016; Sun, 7 Jun 2020 08:25:26 +0000 From: Mohit Sethi M To: Sean Turner , TLS List Thread-Topic: [TLS] adoption call for draft-dt-tls-external-psk-guidance Thread-Index: AQHWPKUvj8S5P3ZwBEOOvxF9l54S7Q== Date: Sun, 7 Jun 2020 08:25:26 +0000 Message-ID: References: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [176.93.104.195] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19af24a6-330a-4253-14a6-08d80abc54f8 x-ms-traffictypediagnostic: HE1PR0701MB2252: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04270EF89C x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6//m2nWP5WDWnKSJvCqjZpjla91mI6fAXYGGknJ3F2urdtCfGcSaFRPgE40hEVFruuYJ4X2IyEZqv1ya20ZhWhXkePoXr4f3iAj76baut5hg/GT8CF5xPPrSmf3fHSQNof081WSTzkpDjNce+P3UNHXe/8kgYNjGZ8w27DSWAXnRHMvhu2ErdYKI2je/vHyG+velaEHh6xLK0lRSZ+0Ah4vgoq1z0E3WI3ZVTCuVeYpuu35oSp7R/EdnuOf+oemlJ2pMqWk8tQSZfwVkJkrPhz85prpDqAopXccNqUrrLri5e8TdF1oa8jjIrgJxZqVaoDZIiQVxEXDkNUqoUC54gebnHzEkIqrMiyLZ6NbiO23riUv1evO8W0iO5NIyuP0XNGSwvkXvqQJGtpnKh8w3r/IeyCXlKuysUE5RhYudbMNI/0fFL+mghUTumMyYP4W1/rlLTVwWSBt9pkHXElLPLg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(186003)(76116006)(66446008)(8936002)(86362001)(2616005)(66556008)(71200400001)(966005)(36756003)(316002)(66946007)(8676002)(66476007)(6486002)(64756008)(6512007)(478600001)(83380400001)(6506007)(53546011)(110136005)(2906002)(31686004)(26005)(5660300002)(31696002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: c8FmHk7noDC0Jas3bIGh1MVMMzGQ0YMeQO/w/6++/T+CCmxEESAafmS5EC5PGQgdIAbMhWAW61nGAbg9G/SU7/C7EC7LwxAS0nrMPEnnYjcUUrzzMefF0qzAOPBKfADFevAdlPoDjwcC9hn+ogdC9cUqLfmYgr1buNV/qkkNJ5g8GX6EKZk+ACGmPCE6mi/mciFismzOl9hjVoTpkkedEFdHwRrELgiWUR56lTMPW4YCWteuIQ0oqVveTU/nJCtX3QMn28i9jVP+853zJZpQCF1JCC0v7+BhYTyKx9aA7kbOQl04FBhLzdhAHuM0EBhM0Ni+Dbxo6THxbqODNaQE0zcWIcTV/7lAZFu3fLivBKWIE7B3ZD4Dp5BhdjJ7nymr669R1s0ymXr58EcwPCsx7fM1iKEOW1JAhl2X0vHy78fedQFQIlkSkMLXFk0xAErZZfUNYjYdMUliKGDQsCdrX6iZN8EQTIeIb+128LKEGv4qDzs7Gxh6eJ+w6bhTbNFM x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0CE281A8857B1C47A3AB0D07C2F44257@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19af24a6-330a-4253-14a6-08d80abc54f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2020 08:25:26.6110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 72I0gEcoNHro4YHmXmZ5Ert5i5FaeeArFiEtapx7uhFwuXEk30kenZ3rht+uIaAvHppkSL8XHRdb/aDhbX6oF1oJjKiJ+tBmsN8cT4XM2p4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2252 Archived-At: Subject: Re: [TLS] adoption call for draft-dt-tls-external-psk-guidance 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 08:25:34 -0000 QXMgYSBtZW1iZXIgb2YgdGhlIGRlc2lnbiB0ZWFtIChhbmQgYSBjby1hdXRob3IpLCBJIG5hdHVy YWxseSBzdXBwb3J0IA0KdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCkkgYWxzbyB0 YWtlIHRoaXMgb3Bwb3J0dW5pdHkgdG8gdGhhbmsgQ2hyaXMgV29vZCBmb3Igc2hlcGhlcmRpbmcg dGhlIA0KZGVzaWduIHRlYW0gYW5kIGdldHRpbmcgdGhlIGRvY3VtZW50IHJlYWR5Lg0KDQotLU1v aGl0DQoNCk9uIDYvNS8yMCA2OjA1IFBNLCBTZWFuIFR1cm5lciB3cm90ZToNCj4gSnVzdCBhIHJl bWluZGVyIHRoYXQgdGhpcyBjYWxsIGVuZHMgdG9kYXkuDQo+DQo+IFNvIGZhciB3ZeKAmXZlIG9u bHkgc2VlbiBvbmUgcmVzcG9uc2UuIEkgdGhpbmsgSSBjYW4gc2FmZWx5IHNheSBhc3N1bWUgdGhh dCB0aGUgMTIgcGVvcGxlIG9uIHRoZSBEVCBhZ3JlZSwgYnV0IGxldCBtZSBrbm93IEkgZ290IHRo YXQgd3JvbmcuDQo+DQo+IHNwdA0KPg0KPj4gT24gTWF5IDIxLCAyMDIwLCBhdCAyMjoxMiwgU2Vh biBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCj4+DQo+PiBUaGlzIGlzIGEgV0cgZG9j dW1lbnQgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtZHQtdGxzLWV4dGVybmFsLXBzay1ndWlkYW5j ZSAoYWthIEd1aWRhbmNlIGZvciBFeHRlcm5hbCBQU0sgVXNhZ2UgaW4gVExTKS4gVGhpcyBlZmZv cnQgd2FzIGtpY2tlZCBvZmYgQElFVEYxMDYgYnkgQmVuIEthZHVrIGFuZCBzdXBwb3J0ZWQgYnkg b3RoZXJzIGluIHRoZSBhdWRpZW5jZS4gVGhlcmUgd2FzIGFsc28gc29tZSBub21pbmFsIGFtb3Vu dCBvZiBzdXBwb3J0IGZvciBhZG9wdGluZyB0aGUgZHJhZnQgYXQgdGhlIGxhc3QgdmlydHVhbCBp bnRlcmltIHRob3VnaCBubyBmb3JtYWwgYWRvcHRpb24gY2FsbCB3YXMgaXNzdWVkIGF0IHRoZSBp bnRlcmltLg0KPj4NCj4+IElmIHlvdSBzdXBwb3J0IGFkb3B0aW5nIHRoaXMgZHJhZnQgYXMgYSBX RyBEb2N1bWVudCwgdGhlbiBwbGVhc2Ugc2VuZCBlbWFpbCBpbmRpY2F0aW5nIHlvdXIgc3VwcG9y dCB0byB0aGUgbGlzdC4gSWYgeW91IGhhdmUgYW55IGNvbW1lbnRzIG9yIHJlc2VydmF0aW9ucyBz ZW5kIHRoZW0gdG8gdGhlIGxpc3QgdG9vLg0KPj4NCj4+IFRoaXMgYWRvcHRpb24gY2FsbCBjb21w bGV0ZXMgYXQgMjM1OSBVVEMgNSBKdW5lIDIwMjAuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gc3B0IChm b3IgdGhlIGNoYWlycykNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== From nobody Mon Jun 8 17:56:01 2020 Return-Path: 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 07AB93A085A for ; Mon, 8 Jun 2020 17:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=k+AKryzZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mGNfNEjP 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 YB2Ur_sJxyIk for ; Mon, 8 Jun 2020 17:55:58 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67C03A085C for ; Mon, 8 Jun 2020 17:55:58 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 15FCE6D9; Mon, 8 Jun 2020 20:55:58 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 08 Jun 2020 20:55:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=xInZ+wMKGNpW2MsrWkkmovDHhpa0 a1natei2pKvMAf0=; b=k+AKryzZ5t/n6xLYL2KAoV0BNF4XaAl/3bCqnqQEPPwK TcV7YoaQo8hYp0NerF68j3Lc/Dl294VINO0gMvSNVCMVg3hLR3sRczgR5CpbNRzf sezlROUQ5xjDN7OOvaatRbN8/QUBY3JQbZ3kp1U3xHPyjU1Gfepqghc1GJDeE5Ea m2zTdh+RV09v6MXxi/NrzfB4D3ghGONgDJZhGysBjsqZFjkQobnliTQ/n7o5Jg89 JfoAh8vyPYYbDERF8byWVoBiWR8q35X8kjVlsuSpDX7ot+lN7p+F3i5/btA34R2k SwnlzMQckm8y/1lAqo0IckyaKjWr47XttRH9PZ7SDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xInZ+w MKGNpW2MsrWkkmovDHhpa0a1natei2pKvMAf0=; b=mGNfNEjPXUxkGcAuuo5x4s PihYCvAiaZ7nC7GFeTnwzVn6RX7ynFDQQj1AoIHDk8E6F446CEVJyRqnvzeFVXCQ XqZTNA1qg5TZsf3VJSfuogCSelnvHwUYETGuUel7g+dzFp4+WLUG0vu9m71RV+r3 i7B7zRvoMctGYlc8YieqEQIJU+CbMsq32vp1f4abTwDVHWIsJTK076jo7lpUEqJ+ Dwx0PbHgf/rCDRiV4dgCFoFXBWOe2ou71WJr4jWf6SiWpI9XknLHBUinmlqQY5+D ig70xzO/7hoe3SNKYv5dg+yCMTULwklhN4Owkk4bIxmM4hB9ceGlTzPXbOKNwXmg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehfedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E8B10E00A9; Mon, 8 Jun 2020 20:55:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <67c0d137-b5ae-4fb5-bc42-d68726e082d8@www.fastmail.com> In-Reply-To: <466C44E4-2416-4FE2-AED0-F7DBE1EEFB21@vigilsec.com> References: <20200604000011.387A5F4070F@rfc-editor.org> <73b5d3e2-d2f4-447c-84d6-0ae0a08374a9@www.fastmail.com> <070E5A6D-7D2F-405A-B5D8-8C90379306D9@vigilsec.com> <466C44E4-2416-4FE2-AED0-F7DBE1EEFB21@vigilsec.com> Date: Tue, 09 Jun 2020 10:55:40 +1000 From: "Martin Thomson" To: "Russ Housley" , "'Eric Rescorla'" Cc: "IETF TLS" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6204) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 00:56:00 -0000 On Fri, Jun 5, 2020, at 03:54, Russ Housley wrote: > > On Jun 4, 2020, at 12:37 PM, Eric Rescorla wrote: > > Changing: > > TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the > > server. To: TLS 1.3 does not permit the server to send a > > CertificateRequest message when a PSK is being used. This restriction > > is removed when the "tls_cert_with_extern_psk" extension is > > negotiated, allowing certificate-based authentication for both the > > client and the server. > > > > To: > > TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the > > server. To: TLS 1.3 does not permit the server to send a > > CertificateRequest message when a PSK is being used. This > > restriction is removed for the main handshake when the > > "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the > > server. This extension has no impact on external PSK usage > > with post-handshake authentication, which is prohibited by > > TLS 1.3. I see four copies of nearly the same text here, I just want to confirm that it is this last one that we are talking about: > TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed for the main handshake when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. This extension has no impact on external PSK usage with post-handshake authentication, which is prohibited by TLS 1.3. > This works for me. I wonder if "initial handshake" would be better than > "main handshake" "initial" or "main" both add confusion here, I would strike the qualification. In TLS, there is only one handshake. If you want to talk about use of a resumption PSK in this context, then maybe add another sentence that highlights the fact that a resumption PSK that is created from a connection that uses "tls_cert_with_extern_psk" can be used, but the resulting handshake cannot involve a CertificateRequest, though a post-handshake CertificateRequest is permitted. From nobody Tue Jun 9 19:08:31 2020 Return-Path: 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 1FCC03A0DD0; Tue, 9 Jun 2020 19:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 OngswFE5OJxQ; Tue, 9 Jun 2020 19:08:23 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A35F3A0DCC; Tue, 9 Jun 2020 19:08:23 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id q11so438829wrp.3; Tue, 09 Jun 2020 19:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iVswJkyv/RAqcaEx9aZCWfkY7eA3nos+EosxmLtoQaM=; b=Ah0UzS2rDghSZojjUd+uv1l8Wxi+1w3DRJa7ijtLsxCa6Sp5zhHcNp2+YALhPJcsXo vBWxGla5uAaKrhgQkMjOM3v9/Ff60sC4PzsN3PLvn6/wPanXuaj4NyBXMkA/K21DzjDi wxaYBw00GzlKk8OcGG3B2xazZYOJ5VBZCHDsmWJFInwJnUfqcXTjMo+WjS1/D2VNqHbi LQ0Mn8zor1LREAQBYyQ/WwejfwBykQjendzLZnnKHrGZtxvkm6CIwbsZmmHE4vIQBZAo Zf0jdJ3Wi99KSpegutcQVSjEU7SBL6HQ5/FC4c8cWOIETEfJx9QbUvbg0PUVkddV5mDf J//g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iVswJkyv/RAqcaEx9aZCWfkY7eA3nos+EosxmLtoQaM=; b=Z4wx1Axrke/2SUoDCLcfndNPTjnwd2Kq7Fs2+1Hy2ENDa/WnDoy2YRdseMSBz0qpjT abHRUNFd+FJpiZOz++zMdIoYLdWEvqtFssCzqUgQmXZ7hEXCowCsx9YSOOPSMvU8pj2D crrKR7BNr/jawelDGMD4vdOxC6/NQf0v4afxYEcMTYTormosdVJJ0VSu5Dh6eZi3eFtP 1Sm+71lrEuA3dUzzyLwLYfthkCPOu40Xu6PKS4AGPfYISRDq6FLGRsDxUygcVnZA9Wnq oMvQhxvn3VvO7EYceJdDbFbA9t/yWUwUKqi6KmYTTF+sX+WrTLeDoXmHaflcFcZXyx+D So3A== X-Gm-Message-State: AOAM533INgjVRWgDEDEuTWrNw104+K0ozNdSXmfF2gbTwH+svHz8xTMW 2v2pgU3EnFQr5H4fVS4ivQ9te59npSmw767NOJ61+WWB X-Google-Smtp-Source: ABdhPJwAsRtT0JYnzDjpdDtk09jZAzGsEb7Xrhu0umUfVTNbU7s0s74DmPjHW+A6MDzrzReVRBQR0+H9non/P9Ixy/4= X-Received: by 2002:a5d:4a04:: with SMTP id m4mr907385wrq.153.1591754901521; Tue, 09 Jun 2020 19:08:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Wed, 10 Jun 2020 03:08:10 +0100 Message-ID: To: HTTP Working Group , tsvwg@ietf.org, tls@ietf.org Cc: Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="00000000000079877205a7b151ca" Archived-At: Subject: [TLS] Fwd: Working Group Last Call: QUIC protocol drafts 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 02:08:25 -0000 --00000000000079877205a7b151ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello folks, Please see the forwarded Working Group Last Call announcement for the QUIC protocol drafts. The QUIC WG will only consider feedback directed towards it so please do not respond to this thread. Instead, review comments need to be opened on the GitHub repo or sent to the QUIC mailing list as described in the guidance below. Cheers, Lars, Lucas and Mark QUIC WG Chairs ---------- Forwarded message --------- From: Lucas Pardue Date: Wed, Jun 10, 2020 at 2:36 AM Subject: Working Group Last Call: QUIC protocol drafts To: QUIC WG Hello, After more than three and a half years and substantial discussion, all 845 of the design issues raised against the QUIC protocol drafts have gained consensus or have a proposed resolution. In that time the protocol has been considerably transformed; it has become more secure, much more widely implemented, and has been shown to be interoperable. Both the Chairs and the Editors feel that it is ready to proceed in standardisation. Therefore, this email announces a Working Group Last Call (WGLC) for the following QUIC documents: * QUIC Transport https://tools.ietf.org/html/draft-ietf-quic-transport-29 * QUIC Loss Detection and Congestion Control https://tools.ietf.org/html/draft-ietf-quic-recovery-29 * Using TLS to Secure QUIC https://tools.ietf.org/html/draft-ietf-quic-tls-29 * Version-Independent Properties of QUIC https://tools.ietf.org/html/draft-ietf-quic-invariants-09 * HTTP/3 https://tools.ietf.org/html/draft-ietf-quic-http-29 * QPACK Header Compression for HTTP/3 https://tools.ietf.org/html/draft-ietf-quic-qpack-16 The WGLC will run for four weeks, ending on 8 July 2020. As a reminder, we have been operating under the Late-Stage Process; see https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#late-stag= e-process. In theory, this means that the contents of the drafts above already have consensus. However, the Chairs would like to actively reaffirm that consensus and start the process of wider review through a formal WGLC. Please review the documents above and open issues for your review comments in our repository at https://github.com/quicwg/base-drafts. You may also send comments to quic@ietf.org. Issues raised during WGLC will be handled in accordance with the Late-Stage Process defined in the Contribution Guidelines (see link above). Please note that design issues that revisit a topic where there's already declared consensus (see https://github.com/quicwg/base-drafts/issues?q=3Dis%3Aclosed+label%3Ahas-co= nsensus) need to provide compelling reasons to warrant reopening the discussion. As part of this WGLC, we seek consensus on the remaining open design issue #3661 =E2=80=9CInclude epoch in the AAD or the nonce?=E2=80=9D ( https://github.com/quicwg/base-drafts/issues/3661). The proposed resolution for this issue is to close with no action, which means that the drafts above already reflect this emerging consensus. Subject to the feedback received during this WGLC, a subsequent smaller WGLC may be run in the near future to confirm any changes to the drafts made between now and then. The Applicability and Manageability drafts have some dependencies on the core drafts, so we'll run separate WGLCs for them. Cheers, Lars, Lucas and Mark QUIC WG Chairs --00000000000079877205a7b151ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello folks,

Please see the = forwarded Working Group Last Call announcement for the QUIC protocol drafts= .

The QUIC WG will only consider feedback dir= ected towards it so please do not respond to this thread. Instead, review c= omments need to be opened on the GitHub repo or sent to the QUIC mailing li= st as described in the guidance below.

Cheers,=
Lars, Lucas and Mark
QUIC WG Chairs
=
------= ---- Forwarded message ---------
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed= , Jun 10, 2020 at 2:36 AM
Subject: Working Group Last Call: QUIC protoco= l drafts
To: QUIC WG <quic@ietf.org<= /a>>


Hello,

After more than thr= ee and a half years and substantial discussion, all 845 of the design issue= s raised against the QUIC protocol drafts have gained consensus or have a p= roposed resolution. In that time the protocol has been considerably transfo= rmed; it has become more secure, much more widely implemented, and has been= shown to be interoperable. Both the Chairs and the Editors feel that it is= ready to proceed in standardisation.

Therefore, this email announce= s a Working Group Last Call (WGLC) for the following QUIC documents:
* QUIC Transport
=C2=A0 https://tools.ietf.org/html/draft-i= etf-quic-transport-29

* QUIC Loss Detection and Congestion Contr= ol
=C2=A0 https://tools.ietf.org/html/draft-ietf-quic-recover= y-29

* Using TLS to Secure QUIC
=C2=A0 https://tools.ie= tf.org/html/draft-ietf-quic-tls-29

* Version-Independent Propert= ies of QUIC
=C2=A0 https://tools.ietf.org/html/draft-ietf-q= uic-invariants-09

* HTTP/3
=C2=A0 https://tools.ietf.o= rg/html/draft-ietf-quic-http-29

* QPACK Header Compression for H= TTP/3
=C2=A0 https://tools.ietf.org/html/draft-ietf-quic-qpack-1= 6

The WGLC will run for four weeks, ending on 8 July 2020.
As a reminder, we have been operating under the Late-Stage Process; see <= a href=3D"https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md= #late-stage-process" target=3D"_blank">https://github.com/quicwg/base-draft= s/blob/master/CONTRIBUTING.md#late-stage-process. In theory, this means that the contents of the drafts above already ha= ve consensus. However, the Chairs would like to actively reaffirm that cons= ensus and start the process of wider review through a formal WGLC.

P= lease review the documents above and open issues for your review comments i= n our repository at https://github.com/quicwg/base-drafts. You may also send c= omments to quic@ietf.org= .

Issues raised during WGLC will be handled in accordance with t= he Late-Stage Process defined in the Contribution Guidelines (see link abov= e). Please note that design issues that revisit a topic where there's a= lready declared consensus (see https:= //github.com/quicwg/base-drafts/issues?q=3Dis%3Aclosed+label%3Ahas-consensu= s) need to provide compelling reasons to warrant reopening the discussi= on.

As part of this WGLC, we seek consensus on the remaining open de= sign issue #3661 =E2=80=9CInclude epoch in the AAD or the nonce?=E2=80=9D (= https://github.com/quicwg/base-drafts/issues/3661). The proposed r= esolution for this issue is to close with no action, which means that the d= rafts above already reflect this emerging consensus.

Subject to the = feedback received during this WGLC, a subsequent smaller WGLC may be run in= the near future to confirm any changes to the drafts made between now and = then.

The Applicability and Manageability drafts have some dependenc= ies on the core drafts, so we'll run separate WGLCs for them.

Ch= eers,

Lars, Lucas and Mark
QUIC WG Chairs
--00000000000079877205a7b151ca-- From nobody Sat Jun 13 10:20:43 2020 Return-Path: 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 9AFC63A0A1F for ; Sat, 13 Jun 2020 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 jqVgL8qPQvt3 for ; Sat, 13 Jun 2020 10:20:40 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7973A0A1C for ; Sat, 13 Jun 2020 10:20:39 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id q25so10823285wmj.0 for ; Sat, 13 Jun 2020 10:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=2ZAH4kWnHon8k82aSNmDN4IvSnyTPCf4s2dU7rTUwUc=; b=tOa6kUpyVwjkUINPQd7qdjAhZ8AhnKXI2SDeLgPO/Mz5+zvMyNOfyR90OQWTO2dIy4 7ufJP0/01jsLeV7F5ZrGVNk1rKmhe0fmOJe5j81jHz9ZRoAuWiGrKiQDJu/VOqqazn3A 95aIYI5gSf7xR+vwSYslNufC9dzD6FHTsSsnoeHyLbvBl+Tyg81At5XtGXT8DLom/Ciy nDrl88ix0c1/3bRWXyExiFWqnKcO+p+QkitJ8bPC2bNeEw6JEkkPnJcjp6NJyBqTEMLT gpfb5fNXAjRSd+p96QvP59iwfSSUfUMlUlWz114CpZF59s+aSvyHSP/KR7mlvrhimFk4 Oe4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=2ZAH4kWnHon8k82aSNmDN4IvSnyTPCf4s2dU7rTUwUc=; b=UllUJLhBAiALDYLB5bkgzfO+MRXEzj29z+judUxXtO246KH8Fq3bJy7ngKUkCfCELL eeRBqGouAJyNTXCQhZGDYV5mZgWEXX6ylXVJM76Ogq3pvKjuyX7LwjEn5WzIP6+sZ0RH gBaJ89En3f+7TWKQYeJnQEQOWeuIJXMNgvlx6QiqiFIopDbRhihYyPwmSggf9qXAnJIV QCOSoM0eSHR81Rd7AD1E4L/mjeQ1ovfFUFJWMn4kjsalZ5f81fbtowUnmmimMnfQzh8a HD9oNUupitrWDhqpOXCzOrMaDu443OazIC9TBE0944YKJb2DnPRXWF5odOO5JQgFdYas EtAg== X-Gm-Message-State: AOAM531ig9PdEDqvOZhbzMwsWr5brtzKhs50XwEvV6zxZh1ODdsKqR5V XrE0PuUHF68Cj5BaB0aUUOF2fDXd X-Google-Smtp-Source: ABdhPJytMhpPhmxABLQM+O5jzjiPrV1KSJ+76PFwrSJOG+psBRWqJxE8AAXJPe7uHFmkaHgySw7dKA== X-Received: by 2002:a1c:f204:: with SMTP id s4mr4906547wmc.159.1592068837806; Sat, 13 Jun 2020 10:20:37 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x8sm16321142wrs.43.2020.06.13.10.20.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2020 10:20:37 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_76DB07E9-BE4C-4C72-8DB7-59A63EF8CCBE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> Date: Sat, 13 Jun 2020 20:20:35 +0300 To: "" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 17:20:42 -0000 --Apple-Mail=_76DB07E9-BE4C-4C72-8DB7-59A63EF8CCBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. I=E2=80=99m posting this on behalf of the IANA experts for the TLS = registries. The IANA experts function is described in RFC 8447 [1]. We=E2=80=99ve received a request from ETSI to assign three ExtensionType = values from the ExtensionType registry [2]. ETSI is the European = Telecommunications Standards Institute [3]. Ordinarily requests from = other standards organizations are approved as long as they=E2=80=99re = not in conflict with current work within the IETF, and for the = ExtensionType registry the policy is =E2=80=9CSpecification Required=E2=80= =9D. The reason we are consulting this time is that we can foresee some = objections should these assignments appear in the IANA registry. So the request is for a part 2 of the Middlebox Security Protocol [4]. = You can read it all, but the gist is a protocol between a TLS endpoint = and a TLS middlebox that allows the middlebox read, read+delete, or = read+delete+write access to the data stream. If this idea is giving you = d=C3=A9j=C3=A0 vu, then yes, the TLS working group has considered = proposals in that domain in the past, and to put in mildly, did not = choose to take them up. To re-iterate, the policy for the registry is =E2=80=9CSpecification = Required=E2=80=9D and a specification is available. Unless we hear = convincing arguments to the contrary, we will approve this allocation. = We just prefer to have the kerfuffle before the assignment rather than = afterwards. Thanks Yoav (with the IANA expert hat on) [1] https://tools.ietf.org/html/rfc8447 = [2] = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-1 = [3] https://www.etsi.org/about [4] = https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TL= MSP-Transport-Layer-Middlebox-Security-Protocol.pdf = --Apple-Mail=_76DB07E9-BE4C-4C72-8DB7-59A63EF8CCBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi.

I=E2=80= =99m posting this on behalf of the IANA experts for the TLS registries. = The IANA experts function is described in RFC  8447 [1].

We=E2=80=99ve received a = request from ETSI to assign three ExtensionType values from the = ExtensionType registry [2]. ETSI is the European Telecommunications = Standards Institute [3]. Ordinarily requests from other standards = organizations are approved as long as they=E2=80=99re not in conflict = with current work within the IETF, and for the ExtensionType registry = the policy is =E2=80=9CSpecification Required=E2=80=9D.  The reason = we are consulting this time is that we can foresee some objections = should these assignments appear in the IANA registry.

So the request is for a = part 2 of the Middlebox Security Protocol [4].  You can read it = all, but the gist is a protocol between a TLS endpoint and a TLS = middlebox that allows the middlebox read, read+delete, or = read+delete+write access to the data stream. If this idea is giving you = d=C3=A9j=C3=A0 vu, then yes, the TLS working group has considered = proposals in that domain in the past, and to put in mildly, did not = choose to take them up.

To re-iterate, the policy for the registry is = =E2=80=9CSpecification Required=E2=80=9D and a specification is = available. Unless we hear convincing arguments to the contrary, we will = approve this allocation. We just prefer to have the kerfuffle before the = assignment rather than afterwards.

Thanks

Yoav
(with the = IANA expert hat on)


[1] https://tools.ietf.org/html/rfc8447
[2] https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml#tls-extensiontype-values-1
[3] https://www.etsi.org/about
[4] https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-00= 27-2v020-TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf


= --Apple-Mail=_76DB07E9-BE4C-4C72-8DB7-59A63EF8CCBE-- From nobody Mon Jun 15 11:41:19 2020 Return-Path: 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 22F5C3A0917 for ; Mon, 15 Jun 2020 11:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 3BvQ_VKDY4k7 for ; Mon, 15 Jun 2020 11:41:17 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E627D3A0911 for ; Mon, 15 Jun 2020 11:41:16 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id z2so16293906ilq.0 for ; Mon, 15 Jun 2020 11:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PT5TNIV5j0t/i1a4VR5xCECEufjqSVd8TKP+KFu20Dw=; b=RC52qB3q3cDCfEKOhYXXT+AOm7x7Kp2f5wRVixaWTUqWs4C0/wEtB4EgUkeqjS5lRT XqIdJGAO+oSfmWgEWafhpxRjB3NVR4fmUqappWJjAKrHu2bXn4EMKEJynrkklpJmzCm9 5lB9epqYwQbMQVn4Q7krW2C2/A1dxpq04wYnYjxocp01iB7Ch5HS5LgQWyyrVKW5etz5 VCmpJ7pYorbdExqBFRhYezewc/sxnqscQxctm89TGZue0SfsH/895ZHAgPcEoaSWCEOI mCZEGF3oCL3LrsklSpY/PUOtG4vmOfshmy4fm3pPdoGCTV7PAzYt71fqI/CgIUzL1TUo xYrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PT5TNIV5j0t/i1a4VR5xCECEufjqSVd8TKP+KFu20Dw=; b=TzwRF7YCddZg9KydlzaZewWWDx6gyNxkICAHueUNpcSp5txlOvqIxCWzAJvay/Xo/B PQ0T9BVwt1J3m9J5lBggzgqxaKrNow00MZRoKT9y7TxFsltMM6XQdGWif7NsgNyFiw7x DJtzQJTt5AFBD2T3MJL8WwRjUrulUFdeTO69OWsuEEhd8MHCggbZrR13E+QktLgPHNH+ ygDM3Gn4Ea901AAomkwkyLnd0XBW9h/Dq0LMnHe+1X+COZHzptid2lqzTrZAAaOzz1g0 nnMTs48IoNvybECxpOvmLkWsMnEcVWC50niusiIW+aJoc6J+NeYY2GLALHTaQ1nZPSog W93g== X-Gm-Message-State: AOAM532KwvDcJxM/9MIFjG+Uq22+T8QfnpZBHUFiMNmVVc/sRUDSl9uY atdPXCJQuCSljqHJ2tvDytTZuwLbbY+w2feNtFXGJM67xcI= X-Google-Smtp-Source: ABdhPJzDMVyr5f7EsAnXggqULZCPFfM3GzxAHM2NhhpaEnMK/fFX0wUpf6XJxNC+jl60DGjlGXPlfx+3wHuFqrq48/w= X-Received: by 2002:a92:c7c6:: with SMTP id g6mr28723700ilk.49.1592246475779; Mon, 15 Jun 2020 11:41:15 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Mon, 15 Jun 2020 11:41:04 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095757505a823c5a7" Archived-At: Subject: [TLS] TLS Encrypted Client Hello implementations? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 18:41:18 -0000 --00000000000095757505a823c5a7 Content-Type: text/plain; charset="UTF-8" Hi, I've been looking over https://github.com/tlswg/draft-ietf-tls-esni and it seems like things are firming up. Are there public implementations that track recent drafts and/or the github repository? Is anyone publishing DNS records that conform to the more recent specifications and names? I'd like to update the work I did on rustls for draft -02 (which interoperated with NSS, Cloudflare, and the defo.ie fork of OpenSSL).* thanks, Rob * https://github.com/ctz/rustls/pull/318 --00000000000095757505a823c5a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I've been looking over


and it seems like things are firming up.

Are= there public implementations that track recent drafts and/or the github re= pository? Is anyone publishing DNS records that conform to the more recent = specifications and names?

I'd like to update t= he work I did on rustls for draft -02 (which interoperated with NSS, Cloudf= lare, and the defo.ie fork of OpenSSL).*

thanks,
Rob



--00000000000095757505a823c5a7-- From nobody Mon Jun 15 14:00:07 2020 Return-Path: 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 55B013A0F5A for ; Mon, 15 Jun 2020 14:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (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 MKZBSDTNrd9a for ; Mon, 15 Jun 2020 14:00:04 -0700 (PDT) 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 8C4773A0F66 for ; Mon, 15 Jun 2020 14:00:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 656C4BE2E; Mon, 15 Jun 2020 22:00:02 +0100 (IST) 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 o-zaLVAXLntB; Mon, 15 Jun 2020 21:59:53 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04ACDBE2C; Mon, 15 Jun 2020 21:59:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1592254793; bh=ea4R3vkvuKGxGG0NhcDGMcHbQ0GLp7j2uUPCRdoGBXQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SUvQwKsrcmjMNRhxNgzY0FuTXq2Z92+t66xJ82OM0MfydflSTfhxNzqJJB34ZtWvG PAar6ZbKSYy6paZgJhnjAd+EhkAPuZVRtoLnLqViGDxvcedFvSaWfd4PC9P51ODzzh 8dPzRPUNKCUAwsKDQIuLkoxip+2Yr9iJmTX+n6D4= To: Rob Sayre , "TLS@ietf.org" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4f49f59e-0033-0bda-f7e9-3cae2ea7ed2f@cs.tcd.ie> Date: Mon, 15 Jun 2020 21:59:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HEJuEl21EPq8OhTMm8uVS0Ky3Tw8arlzF" Archived-At: Subject: Re: [TLS] TLS Encrypted Client Hello implementations? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 21:00:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HEJuEl21EPq8OhTMm8uVS0Ky3Tw8arlzF Content-Type: multipart/mixed; boundary="ik56dikft0URg4nKuD7we1Kx7aeiwUvuy"; protected-headers="v1" From: Stephen Farrell To: Rob Sayre , "TLS@ietf.org" Message-ID: <4f49f59e-0033-0bda-f7e9-3cae2ea7ed2f@cs.tcd.ie> Subject: Re: [TLS] TLS Encrypted Client Hello implementations? References: In-Reply-To: --ik56dikft0URg4nKuD7we1Kx7aeiwUvuy Content-Type: multipart/mixed; boundary="------------5FAEE79C82E6A2AB7EA53D0C" Content-Language: en-US This is a multi-part message in MIME format. --------------5FAEE79C82E6A2AB7EA53D0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/06/2020 19:41, Rob Sayre wrote: > Are there public implementations that track recent drafts and/or the gi= thub > repository? Is anyone publishing DNS records that conform to the more > recent specifications and names? I've been busy on another thing but do plan to do that based on the latest draft soon as I get time. Cheers, S. --------------5FAEE79C82E6A2AB7EA53D0C Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5FAEE79C82E6A2AB7EA53D0C-- --ik56dikft0URg4nKuD7we1Kx7aeiwUvuy-- --HEJuEl21EPq8OhTMm8uVS0Ky3Tw8arlzF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7n4UgACgkQWrL68XsX K+ouXQ//RHm5KspxpoVUnUPG9zPwtDn2MbcfAXkOQeX2v3hQ/7h5rSZvRNXpCvtQ JYvtOpcA400p4lMkZ1UpHD50E0elQnInjlDS8bepr5LxM55W++WX41UwXhQ4x4yn kgVhoyFnbr/zj3O5vTmx+nV0WfJHtLW1ucsQFlZ2qhsUebOr3E6K9s8SQP8p/0O6 dwmxAjYRxSMGbpXu3IpUQKqAmiyrHbmhdppzhWfJ9Q4Cy7BSgsBY9ukapVncefmb iZ99OzkMz3GSFzfuoELIFEHd5bgAt6qEQScqMNCsLLGzStI4uG/rC2HE8960TZQk Nna8ikof76ErdYcYNiRU77xaGtLz6x5ut5pe7ZG4Mbh/H9k6AqjnNr9EOC/bUg0p LozejlSGvTWhLGh5KInr+oDErGJlZgWTjwaCoMIY5HuiMkVcCaM306svvxSYGqvo Kl47QgjCBcLXusAtotHpUcSV1TdDSns3FW+0O29IvsBfn0BWFNijq8C2N5tVwrHz GYAfnKNMCnZjgtM5awJ7jOeIojwJeVWROftQsFgHU1cdrfzoj6LKZtDXQahOyaF+ nfqHd81qsAZ6DnbUBjXa9oZLzcs5EmlR6O+mFjv+gG36p6f2z2NMgVeinBy/46W8 sQpddDSnfG6XgOx7+W62IbDOYAPZ9bOuxyU1mutuvs+DfQzAk2U= =H/6g -----END PGP SIGNATURE----- --HEJuEl21EPq8OhTMm8uVS0Ky3Tw8arlzF-- From nobody Tue Jun 16 09:38:32 2020 Return-Path: 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 F3B243A00C1 for ; Tue, 16 Jun 2020 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 S3tUQ_GZlnUl for ; Tue, 16 Jun 2020 09:38:28 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696043A00C0 for ; Tue, 16 Jun 2020 09:38:28 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id l12so22187877ejn.10 for ; Tue, 16 Jun 2020 09:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pPqnGkh/0d073xaJ4s1F2nvXvfl0WVi+/HzEqioyOuk=; b=r90pGrSZNG9ozq3ivA1XAj4QsbJZ/xkJvvi5ZdsbR8CnAKdQ+kZjvN55J83ff0BNTL o57sVGT0QWSp8BaRqGXVsrasy1WFY/uN6RDv/nKaYUSDNJDINPhCWYH0ev/cUpADt2au Zvrugq0cHPsw/kwxI+v25JUqlU55Rc3PGyn5me+HgHLvUyxizR/A4lA4eXw0544JzsU7 N1yw9aMavdHsZv8e4z5Xanc643X89TpqRmOLHTU/rdjeNHxNQItoZ1UmxUnAnb8LsO67 hq27gaxEfniBtHTpP4rs2gLwXHhEm26NrDHP+M1GR6OqehLWl/cxzxphSy9QrZ8uALOT XCOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPqnGkh/0d073xaJ4s1F2nvXvfl0WVi+/HzEqioyOuk=; b=R5vLejmr1JbhytCetimDibUXRLWqb1ImH6Psw4TB5bPSfwQtF+C3p/Q0L/1q+JiC2X HrWVf2kSONwazFsWNhL2ynSoJX2p7BOR680dvTSxJWdWlewcwo48QqMr7uQVW0zWp6uy wdOxqg4KWP368uRWJt66MU1gcFCPDOI6CTpbIQFNWT9zt/SuM/YmZZQL9JSHnz1WNSxC W/gqH4Geo/AxxjaHp4BHePdwEqGH/LaPOYbnXCcypnkmA0mf1dAFLsVISRh9y5Fw4u45 NFyhMRKB+4qUrIzzWsZ/zQv335UUcHvfvVfb3MmlzRLAzha977hyIi3K7LV4oCe+Lw3V ZR5w== X-Gm-Message-State: AOAM533bt9oJBPtvsTSuQJ6Vk2GpZhFWwtO/2M59E9gMP4+kAz4nmnzc xd2IwjjdDAFt7sAr43/VPGD5iA8/VH0eZbEQlmxRkw== X-Google-Smtp-Source: ABdhPJw3QIwipkZvW+g4G5r27ykka48w1PlWXAJm+wAPacNl5Lk/0oSQUvtNOQeKJ9xg3wYldA6pyChgTPRFC9y1wTw= X-Received: by 2002:a17:906:f8c2:: with SMTP id lh2mr3531948ejb.112.1592325506682; Tue, 16 Jun 2020 09:38:26 -0700 (PDT) MIME-Version: 1.0 References: <4f49f59e-0033-0bda-f7e9-3cae2ea7ed2f@cs.tcd.ie> In-Reply-To: <4f49f59e-0033-0bda-f7e9-3cae2ea7ed2f@cs.tcd.ie> From: Dan McArdle Date: Tue, 16 Jun 2020 12:38:10 -0400 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000031d33105a8362cbd" Archived-At: Subject: Re: [TLS] TLS Encrypted Client Hello implementations? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 16:38:30 -0000 --00000000000031d33105a8362cbd Content-Type: text/plain; charset="UTF-8" Chrome/BoringSSL is planning on implementing the latest ECH draft, though we don't have a detailed plan to share yet. On the DNS side of things, we're still working through early prototyping and experimentation for HTTPS records, aka HTTPSSVC. If anyone is working on server-side implementations, we'd be happy to partner for interop testing, once we have a working prototype. Thanks! Dan On Mon, Jun 15, 2020 at 5:00 PM Stephen Farrell wrote: > > > On 15/06/2020 19:41, Rob Sayre wrote: > > Are there public implementations that track recent drafts and/or the > github > > repository? Is anyone publishing DNS records that conform to the more > > recent specifications and names? > > I've been busy on another thing but do plan to do that > based on the latest draft soon as I get time. > > Cheers, > S. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000031d33105a8362cbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chrome/BoringSSL is planning on implementing the latest EC= H draft, though we don't have a detailed plan to share yet. On the DNS = side of things, we're still working through early prototyping and exper= imentation for HTTPS records, aka HTTPSSVC.

If anyone is= working on server-side implementations, we'd be happy to partner for i= nterop testing, once we have a working=C2=A0prototype.

=
Thanks!
Dan

On Mon, Jun 15, 2020 at 5:00 PM = Stephen Farrell <stephen.fa= rrell@cs.tcd.ie> wrote:


On 15/06/2020 19:41, Rob Sayre wrote:
> Are there public implementations that track recent drafts and/or the g= ithub
> repository? Is anyone publishing DNS records that conform to the more<= br> > recent specifications and names?

I've been busy on another thing but do plan to do that
based on the latest draft soon as I get time.

Cheers,
S.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000031d33105a8362cbd-- From nobody Tue Jun 16 10:20:12 2020 Return-Path: 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 5ECFE3A0789 for ; Tue, 16 Jun 2020 10:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=mozilla.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 jEOhh0ydCC8z for ; Tue, 16 Jun 2020 10:20:08 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF403A0788 for ; Tue, 16 Jun 2020 10:20:08 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id l6so3500110ilo.2 for ; Tue, 16 Jun 2020 10:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BlJm6/MBnxVBmBnxuGcxdoZ+8tU/5z0thP14cRnl2q0=; b=TBYGjGFZIo+dCq1MSwHY3UgcNCwbm2gg4Clf9hLFRHUPNqAAdV+iCQ/Eb9Fs1eWt46 oZfIr0RLfJpm7WFeKeUzvlWgQg+hRfUlGgWZYpuSaJ1e2mSRIBkAemGpg/3laCa9Ridx qqrq7S2QuZhapMaWOHulq4tw+YCqhSuhHmv88= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BlJm6/MBnxVBmBnxuGcxdoZ+8tU/5z0thP14cRnl2q0=; b=GY2HNsox7frmYGu527iO/kfXUh6o2qEAwhHHZI3kYtf89FRjCNIKW3NAFukZ89eloU DVoLk9KrnGT6PkcIFi1p0e90I2Jfmzj3NT3w7p6hRAxUH25TJ4jA/yk89zo7bw70QCMA hWInHA3PXMB8Cn2LVbDNGF1/wSbpeLjHmBizBaOcmqrXkBhVamf75GqH6MKqqYHDwT/W Vao0d0sWq/3rLq4iyQMIRRZcdehwXWp305K4L+XGP+tGSOICh2Xs0zhv8G7I8WoXaTIH zCaZe+qsIFdxP2jydU0ow9RR88eQSKjvdTbgqG5FeQ2Br0wrVsgTn0TmAKCiAQlhQq+r Rp4w== X-Gm-Message-State: AOAM531PXtGSrXcIensB440hrkXJ9hF0xVNfngPFiG18SdyeY3LI+J48 6RsodIKsNj92l7JGcYtCQRZ+hqmGg1UpkB8i06u9Ew== X-Google-Smtp-Source: ABdhPJymRn5PX2lsmXj8qhcB2buLAtNkgCWWxa4ze2qAcqJjVD1PA6mo8oJpH97zPJG/xasoFTuK1cyqBnW/glKKj/c= X-Received: by 2002:a92:5e59:: with SMTP id s86mr4306014ilb.104.1592328007351; Tue, 16 Jun 2020 10:20:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Jacobs Date: Tue, 16 Jun 2020 10:19:56 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003e9e8505a836c1e0" Archived-At: Subject: Re: [TLS] TLS Encrypted Client Hello implementations? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 17:20:10 -0000 --0000000000003e9e8505a836c1e0 Content-Type: text/plain; charset="UTF-8" We plan to update NSS and Firefox to the latest draft over Q3/Q4, and will be happy to assist with interop testing. Thanks, Kevin On Mon, Jun 15, 2020 at 11:41 AM Rob Sayre wrote: > Hi, > > I've been looking over > > https://github.com/tlswg/draft-ietf-tls-esni > > and it seems like things are firming up. > > Are there public implementations that track recent drafts and/or the > github repository? Is anyone publishing DNS records that conform to the > more recent specifications and names? > > I'd like to update the work I did on rustls for draft -02 (which > interoperated with NSS, Cloudflare, and the defo.ie fork of OpenSSL).* > > thanks, > Rob > > * https://github.com/ctz/rustls/pull/318 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000003e9e8505a836c1e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We plan to update NSS and Firefox to the latest draft= over Q3/Q4, and will be happy to assist with interop testing.

Thanks,
Kevin

On Mon, Jun 15, 2020 at 11:41= AM Rob Sayre <say= rer@gmail.com> wrote:
Hi,

I've been look= ing over


and it seems like things are firming u= p.

Are there public implementations that track rec= ent drafts and/or the github repository? Is anyone publishing DNS records t= hat conform to the more recent specifications and names?

I'd like to update the work I did on rustls for draft -02 (which= interoperated with NSS, Cloudflare, and the defo.ie fork of OpenSSL).*

than= ks,
Rob



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000003e9e8505a836c1e0-- From nobody Tue Jun 16 10:23:26 2020 Return-Path: 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 4BC593A07C0 for ; Tue, 16 Jun 2020 10:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 Fxx7GX_XWVt2 for ; Tue, 16 Jun 2020 10:23:20 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEA53A0793 for ; Tue, 16 Jun 2020 10:23:20 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id k22so16080480qtm.6 for ; Tue, 16 Jun 2020 10:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=dcS1a/FjOR0W/2sO7eSCb+HKZ7eBhaQEwpYRZ4ZqMcU=; b=WELHwPqOH0Uq/QjR0Ll61BcKNfyX4ur41oOsFHe7uvYC/kbpPVxwzqqxqH5jAKKasK r441NIKOngSYve2QzebOGU2s58tFkHBtu5D9QXCjVugA/R1qSN7okJpb36lGPfdULN1Y vllmO7eRsBFVyGr3tzex8MxiYjGqdZaxAfUwA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=dcS1a/FjOR0W/2sO7eSCb+HKZ7eBhaQEwpYRZ4ZqMcU=; b=Pdz9rjZ5foG0NVbZGnMKksExb+rSvKw0cJccmH6DaP4GDqBncZdzYsgUXQWB/cTovd ZO9rBLZ5ZX+9tk9AMUCZt8sPcbp4KDWdA7F9SUVEWlMyloDxomgsgcSbBCBYpL6RaubT DiNsQFGhnaJhUcu3USDNeWEilP5kEK+7IpghBKh0r61SKTcAzRyvpSmC0Y1BaRNKsriR Kyikduj8Z31KP0EjuXhWRKKc6Cf1RzNnwslSWrXQwO16tSuFnmn1bvdUi2SForz2H63v txUwes+GWPnSt0chBXvuKbQiB7fafZeOgqDq1VWIBUUotrf6XKHm9kqPxr2Mo1M4Hcvi yvZg== X-Gm-Message-State: AOAM533Lx05TU0z6KjQdu0Aa9Q3krXn5cU6wUz6xBAltp6hABCvUUl1c ABfzhE77PCpzA4SEr1UFRhVbyV+q1OM= X-Google-Smtp-Source: ABdhPJyNNilWISMBR2f/qzn4jbkMROB6JdMFETyIN/UlmthgOHN522iLcXV99dPlivFljO9WTALBIw== X-Received: by 2002:ac8:60c9:: with SMTP id i9mr22312911qtm.287.1592328198905; Tue, 16 Jun 2020 10:23:18 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id x186sm13140726qkd.125.2020.06.16.10.23.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 10:23:18 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Jun 2020 13:23:17 -0400 References: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> To: TLS List In-Reply-To: Message-Id: <600F08CB-490A-477E-B92F-AFDA8E1F0B69@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] Closing WGLC (was Re: 3rd WGLC for draft-ietf-tls-exported-authenticators) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 17:23:25 -0000 Hi! This message closes out the 3rd WGLC for = draft-ietf-tls-exported-authenticators. I have created GH issues for the = two issues raised during WGLC: https://github.com/tlswg/tls-exported-authenticator/issues/62 https://github.com/tlswg/tls-exported-authenticator/issues/63 Once addressed, and assuming the changes are not large, we will progress = this draft towards our AD. I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D = needed awaiting resolution of the two issues. spt (for the chairs) > On Jun 5, 2020, at 07:29, Watson Ladd wrote: >=20 > On Thu, Jun 4, 2020 at 9:48 PM Sean Turner wrote: >>=20 >> Another reminder ... >>=20 >>> On May 22, 2020, at 09:23, Sean Turner wrote: >>>=20 >>> This is the 3rd WGLC for "Exported Authenticators in TLS" draft = available at = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. = The secdir review during IETF LC raised some issues and as a result = there have been a couple of new versions. Please respond to the list = with any comments by 2359 UTC on 8 June 2020. >=20 > I've implemented earlier drafts. I do have a concern with the > validate API as presented in the draft: it treats empty authenticators > as valid, and then returns the identity as a certificate chain that > must be validated by the application. Similar APIs have lead to easily > foreseeable pwnage. Instead I would recommend the validate API carry > out X509 validation against a trust store or validation function and > treat the empty authenticator as invalid. That way someone has to > think before not checking the certificate returned. >=20 > Sincerely, > Watson Ladd From nobody Wed Jun 17 20:21:17 2020 Return-Path: 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 112C93A0DB3 for ; Wed, 17 Jun 2020 20:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 kbYTb1B_ychl for ; Wed, 17 Jun 2020 20:21:13 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4103A0DAF for ; Wed, 17 Jun 2020 20:21:13 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id l17so4254267qki.9 for ; Wed, 17 Jun 2020 20:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=zUaLiHxjesyZcRh5U8t+pYXI/3UgVhwTXlhI0h+F8Mk=; b=O5mNh32QlmmNQmahq5lKK2emZHyIkWK7ZpzYx1U2rbEuQoB4/s/ViYvvQXqRZAzfhl G6EI3JIpqXYoMqlV3DDsb7gGTFm+vf4ueT2odsyHIPykSvYqX1CpLIXCBBU7ir9uymMr AoShkADcSODHC7T49b6XH/Rz2CpebwUL6LIxo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=zUaLiHxjesyZcRh5U8t+pYXI/3UgVhwTXlhI0h+F8Mk=; b=qP45EEadGcz4EQrhIk2pYgWYNY+G9nlA/WNxtOjxF+aRIbIHit3a/ZIEejKcfd2I0z pCZSo8AMzEm2oDVfWJ157/rRE0Zo40wswdfufGuz0LtGaFG5ytXo45Q7BrMrvn94m9PD gZV8phGNhQsuVMtrPXu4sDMjk3qT63faqx3ibDdwR5aT9MfQayb5lAR2idWWaNkRlFOD TJZKuGEnnOAhem/tlVw9XLPtwUirKMMZkG4V37XC9Uk2775WxfroAOum9p38qCVo8xph z1GMqSt0uRPSnivMrndtNPWfH/klzA7BFQEJkXFM132HlZtm/xxP/p7gz7oUl/H5hvZG eJvg== X-Gm-Message-State: AOAM533ysfjjXo6YvRdxwU+Yrdy0F/hmskRGxN0NhKZyok+TaffhWrWD pWUf75hflgAtYxYzaGpKRcd+4hLrioQ= X-Google-Smtp-Source: ABdhPJzw4LepQEoJwpnszstQwpdDk4kJ2ICZtH4ASuweCoVDU6734E6JvU5sdVO4gL+akUTz/msPkg== X-Received: by 2002:a37:a407:: with SMTP id n7mr1695049qke.366.1592450472086; Wed, 17 Jun 2020 20:21:12 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id r7sm877309qtm.66.2020.06.17.20.21.11 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 20:21:11 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 17 Jun 2020 23:21:09 -0400 References: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> To: TLS List In-Reply-To: <6F570C78-E010-4618-BB34-DD4FD4705CAA@sn3rd.com> Message-Id: <03D3D47C-0ABB-40C1-ABAF-BB9882FFF4B6@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] adopting (was Re: adoption call for draft-dt-tls-external-psk-guidance) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 03:21:16 -0000 All, While we did not get a lot of responses to adopt this I-D, there were an = abundance of DT members that we have assumed would be willing to see = this I-D published through the WG. Likewise, there were no objections to = adopting this I-D. So, I am judging that there is rough consensus to = adopt this I-D. After talking it over with Joe, we think the best plan is to adopt this = I-D, see if there are any comments on -00 before/at the IETF 108, and = then issue a WGLC shortly after IETF 108. Authors, Please feel free to migrate the draft over to the TLS repo. spt > On May 21, 2020, at 22:12, Sean Turner wrote: >=20 > This is a WG document adoption call for = draft-dt-tls-external-psk-guidance (aka Guidance for External PSK Usage = in TLS). This effort was kicked off @IETF106 by Ben Kaduk and supported = by others in the audience. There was also some nominal amount of support = for adopting the draft at the last virtual interim though no formal = adoption call was issued at the interim. >=20 > If you support adopting this draft as a WG Document, then please send = email indicating your support to the list. If you have any comments or = reservations send them to the list too. >=20 > This adoption call completes at 2359 UTC 5 June 2020. >=20 > Cheers, > spt (for the chairs) From nobody Wed Jun 17 20:28:22 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C03A0DE2; Wed, 17 Jun 2020 20:28:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159245090001.15841.1005352632597031983@ietfa.amsl.com> Date: Wed, 17 Jun 2020 20:28:20 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-guidance-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 03:28:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Guidance for External PSK Usage in TLS Authors : Russ Housley Jonathan Hoyland Mohit Sethi Christopher A. Wood Filename : draft-ietf-tls-external-psk-guidance-00.txt Pages : 12 Date : 2020-06-17 Abstract: This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-guidance-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 18 17:24:21 2020 Return-Path: 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 0AF1E3A0D17 for ; Thu, 18 Jun 2020 17:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (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 UhQreond1cO9 for ; Thu, 18 Jun 2020 17:24:17 -0700 (PDT) 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 A838A3A0EF2 for ; Thu, 18 Jun 2020 17:24:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86060BE20; Fri, 19 Jun 2020 01:24:12 +0100 (IST) 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 Dz-7i0_9eiZt; Fri, 19 Jun 2020 01:24:10 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 74E32BE1C; Fri, 19 Jun 2020 01:24:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1592526250; bh=dwZKJ5XZXKdDioX5tsMeu0SxQ5eTeVJ5oY5F2gNAgTA=; h=From:Subject:To:References:Date:In-Reply-To:From; b=O67khWfYWZFwhn9tzG2lekRf1QKTvRvgMWM5qK1NNhHC2adjcNnou6Fj9W6uaNz7m p7/4jp4BXtEFEY6A0PT2GBmHuckwbXCG6ZGeE4La1jonvBuLcUAt6TEQZeFyLvbV/R bYEIYnmmpgx5kHIY6d7TsWsOzQ8k7HQ1lh713XYI= From: Stephen Farrell To: Yoav Nir , tls@ietf.org References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 19 Jun 2020 01:24:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JlroBqXPT7yDHxKuBrMyorGWfrl8NsCfQ" Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 00:24:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JlroBqXPT7yDHxKuBrMyorGWfrl8NsCfQ Content-Type: multipart/mixed; boundary="qVLtxIyPN3ho68kP7ttfwqaWogzC9y0SN"; protected-headers="v1" From: Stephen Farrell To: Yoav Nir , tls@ietf.org Message-ID: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> In-Reply-To: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> --qVLtxIyPN3ho68kP7ttfwqaWogzC9y0SN Content-Type: multipart/mixed; boundary="------------7E4154C567448849F2DF5281" Content-Language: en-US This is a multi-part message in MIME format. --------------7E4154C567448849F2DF5281 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I think these are 16 bit code points? If so, I would barf slightly less if we could allocate 0x0bad every time. I do think signalling opprobrium somehow would be right here. Not sure how best we ought do that though tbh. Cheers, S. On 13/06/2020 18:20, Yoav Nir wrote: > Hi. >=20 > I=E2=80=99m posting this on behalf of the IANA experts for the TLS > registries. The IANA experts function is described in RFC 8447 [1]. >=20 > We=E2=80=99ve received a request from ETSI to assign three ExtensionTyp= e > values from the ExtensionType registry [2]. ETSI is the European > Telecommunications Standards Institute [3]. Ordinarily requests from > other standards organizations are approved as long as they=E2=80=99re n= ot in > conflict with current work within the IETF, and for the ExtensionType > registry the policy is =E2=80=9CSpecification Required=E2=80=9D. The r= eason we are > consulting this time is that we can foresee some objections should > these assignments appear in the IANA registry. >=20 > So the request is for a part 2 of the Middlebox Security Protocol > [4]. You can read it all, but the gist is a protocol between a TLS > endpoint and a TLS middlebox that allows the middlebox read, > read+delete, or read+delete+write access to the data stream. If this > idea is giving you d=C3=A9j=C3=A0 vu, then yes, the TLS working group h= as > considered proposals in that domain in the past, and to put in > mildly, did not choose to take them up. >=20 > To re-iterate, the policy for the registry is =E2=80=9CSpecification > Required=E2=80=9D and a specification is available. Unless we hear conv= incing > arguments to the contrary, we will approve this allocation. We just > prefer to have the kerfuffle before the assignment rather than > afterwards. >=20 > Thanks >=20 > Yoav (with the IANA expert hat on) >=20 >=20 > [1] https://tools.ietf.org/html/rfc8447 > [2] > https://www.iana.org/assignments/tls-extensiontype-values/tls-extension= type-values.xhtml#tls-extensiontype-values-1 > > >=20 [3] https://www.etsi.org/about > [4] > https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020= -TLMSP-Transport-Layer-Middlebox-Security-Protocol.pdf > > >=20 >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------7E4154C567448849F2DF5281 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7E4154C567448849F2DF5281-- --qVLtxIyPN3ho68kP7ttfwqaWogzC9y0SN-- --JlroBqXPT7yDHxKuBrMyorGWfrl8NsCfQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7sBaUACgkQWrL68XsX K+r59RAA0/aPvD+1UMvZXtzEuufnJQaiLxtQtEHg42+rNto5xvkwVnNCeNKBuySt BNYewp+XXl1AycM09l6IpTIvIoZf1cJ/0VZMbNUpUcR1W86YlIPjHy3gzo8XCYav JJqRBkVeK3Fp7Wrp3GMEU3As/GD5WBZLzbOU2WGxWFutnD2d4pM4DqqGYuoivF/K BjmLqhn2L+loU1bp1YpYHg6cn2LKlW0+mkepGMIGyXMIP5XNGCYroQ/lPS5RdTOQ 3HAZIDiorujK09BncTqHgVresn4OncT0cy/GUHex06QdP0Xobo4vsTTc5XC9ZdxR XKSp0kPwFZPhll6FXL/VDN+TCh0BXfcx2DXsXjk1QMalykcE/WmSDPEQMO8z4IbF 5dAY/mg0XXSc3dGAPk9bK9evllCtKuGPTGj98BwTwkJVBde+rzJRePzroXlM2lO6 Ksy5uVahFCxV7qOhqCLUca7NXjUzRXxB/cJEaN8Ki+VrWWGNIwwdqmN3Y1reBbLQ wxghzHAfRXLj81SA4ac8u7M9mGAfZIw3ztkTsvYbTgVhTUo2iyqhcPAC02ewafmu oPmhRCwP6RUY+dZzjvb9EzCWo55V5ZX97eyEXpRe66jNfkIqawejeUiLOYMMbBzJ R4HhFAQoaYF4Syxcpac0sw/msXiDDrpXxcN1SB4Y2u5xXDrFfT4= =7RBm -----END PGP SIGNATURE----- --JlroBqXPT7yDHxKuBrMyorGWfrl8NsCfQ-- From nobody Thu Jun 18 17:36:54 2020 Return-Path: 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 A6A013A0EFA for ; Thu, 18 Jun 2020 17:36:52 -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 6YfnKpXy0lpA for ; Thu, 18 Jun 2020 17:36:51 -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 814023A0E2C for ; Thu, 18 Jun 2020 17:36:51 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05J0J2YE020791; Fri, 19 Jun 2020 01:36:43 +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=pWSv1g8AU9ewIjR3wvvmYh8UoGJzf7AgfMx7OcEWQu8=; b=E9ANOjv1aHRKj0NxnX7ocIFUAxpYaUz2HExFkxiyVVyGC9Lh+mLb683ZYXXUQqftq7pj aqqYwrOGDzlTlugyM2GZELW2JJseuM/izalmBkP0/N5SQus8PGTn6jQbKxtODBgB57jS r3VTKPVFrB09Z3ZcRQKgnIY/295d0nPufD8urgl6CxeFlF0C9igXXQvMwt7nnHl64vG/ XqYH+KepFO/jFer1Mu1kkffocEwAMEeuwNCQDyEzqR+MIUwHg2Y8fHAvQOZWNtsRZ+QR LLiNPXN05FN/Re7qlGq+3/hT5s1xoMP36yFOokn63QhUsVKbuZsZeK758v9NY0zIJsrD zA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31qrdw6xkg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 01:36:43 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05J0UawG016725; Thu, 18 Jun 2020 17:36:43 -0700 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint5.akamai.com with ESMTP id 31qjmvndc5-1; Thu, 18 Jun 2020 17:36:42 -0700 Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5664B2228D; Fri, 19 Jun 2020 00:36:42 +0000 (GMT) Date: Thu, 18 Jun 2020 17:36:41 -0700 From: Benjamin Kaduk To: Stephen Farrell Cc: Yoav Nir , tls@ietf.org Message-ID: <20200619003641.GE20623@akamai.com> References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_21:2020-06-18, 2020-06-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxlogscore=719 mlxscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190000 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_21:2020-06-18, 2020-06-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 spamscore=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 mlxlogscore=683 impostorscore=0 bulkscore=0 cotscore=-2147483648 phishscore=0 adultscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190000 Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 00:36:53 -0000 On Fri, Jun 19, 2020 at 01:24:05AM +0100, Stephen Farrell wrote: > > Hiya, > > I think these are 16 bit code points? If so, I would > barf slightly less if we could allocate 0x0bad every > time. > > I do think signalling opprobrium somehow would be right > here. Not sure how best we ought do that though tbh. You could write an I-D and see how it looks ;) -Ben From nobody Thu Jun 18 18:26:11 2020 Return-Path: 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 8D4913A0F83 for ; Thu, 18 Jun 2020 18:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (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 nORbUH9g_Un8 for ; Thu, 18 Jun 2020 18:26:09 -0700 (PDT) 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 EAE5F3A09D9 for ; Thu, 18 Jun 2020 18:26:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E8CDBE20; Fri, 19 Jun 2020 02:26:06 +0100 (IST) 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 DpYCbTKY8IAZ; Fri, 19 Jun 2020 02:26:04 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 982A9BE1C; Fri, 19 Jun 2020 02:26:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1592529964; bh=NlHFb1wkTF+capJrw0O5SEBtr8J2ZmOzV7+DhlXFWpM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=2wRUZ5XL9DCahmnNHOKRLUuit6wrMTnW624UX5B+9y0/0V0XHjrXr5aOFRbJHC8KJ J4IXyBodyzGwLIXYjHNj98qXG2mW7FkRg9a7fiA0lN4+wx4POLe6/UjHVUvf05GwLr RNrjN24rcWHHiqIvdBLLZEoqRl5zLgkCvGEUVQfo= To: Benjamin Kaduk Cc: Yoav Nir , tls@ietf.org References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> <20200619003641.GE20623@akamai.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 19 Jun 2020 02:26:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200619003641.GE20623@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7ZRJguJMsNPQGOAuSkTjV5qrW5uYqZeka" Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 01:26:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ZRJguJMsNPQGOAuSkTjV5qrW5uYqZeka Content-Type: multipart/mixed; boundary="zw3mhX7I4Y4LJyaXZRwy8ohdBySfsDWjO"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk Cc: Yoav Nir , tls@ietf.org Message-ID: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> <20200619003641.GE20623@akamai.com> In-Reply-To: <20200619003641.GE20623@akamai.com> --zw3mhX7I4Y4LJyaXZRwy8ohdBySfsDWjO Content-Type: multipart/mixed; boundary="------------C3513788FAF676FA2EA76C48" Content-Language: en-US This is a multi-part message in MIME format. --------------C3513788FAF676FA2EA76C48 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 19/06/2020 01:36, Benjamin Kaduk wrote: > On Fri, Jun 19, 2020 at 01:24:05AM +0100, Stephen Farrell wrote: >> >> Hiya, >> >> I think these are 16 bit code points? If so, I would >> barf slightly less if we could allocate 0x0bad every >> time. >> >> I do think signalling opprobrium somehow would be right >> here. Not sure how best we ought do that though tbh. >=20 > You could write an I-D and see how it looks ;) I guess. Not sure I have the time right now for draft-not-green though:-) S. >=20 > -Ben >=20 --------------C3513788FAF676FA2EA76C48 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C3513788FAF676FA2EA76C48-- --zw3mhX7I4Y4LJyaXZRwy8ohdBySfsDWjO-- --7ZRJguJMsNPQGOAuSkTjV5qrW5uYqZeka Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7sFCsACgkQWrL68XsX K+p9XQ/9F0i7VXJ0mFnKtzSl9+BBaFklEWuTwufGx3pkQF5isxV1k4dnTbLZeSKf 2PWOdzoc9J5rwNVx64hPFJJ16rH289g1vUPGn5JS3LWnFDCKof2n0CB8lFXAcIw0 OutR2naOkAU10q2c5Y/EFY+9mTrrve3kZKoP0eux64aCDR74jD2sSGXW8VZ/wgOg VzcGz2zEXuXNNMCRkxFIq1GTxUcMlCJHOS9o3rE56Ph9YKlqx0V3o8MS/ZzhqUcq aQLU74mCxmBW3nsB9znkv1tDqUqDSTGylgIFujs47AOvr59bF4x8h8e3RDO1hHwf BE7/dtJJePVs1GwFwbVryiVh0B58xeDRkd++ilNSIcorgkPQ3NygYkdfQysL/Ku5 j7fjPibs9t9Ww/BjLJcILcHtbS5CGLfQYdwmOUKRSgtWvb0YZjRqvZ6qRDT8KHjg xULsXZDGV7CQZIsOr8gw1AIjr/NYPxZUX/RpGQpxmjNeclwgtKrPiz1HtgyLQmu7 bgKiIQ23YEDuDKomc4urqfEsFEjyJbWNOlEid+fRHY/zxytqU7zYckgg1X+0N9wk Dz8YV7VqJTlwHDrtFpXVocmuOBHNWLuLTpQaf8HIGvzASmsQoeyJmLJ62QBMZ0h3 CqhDRj0CKdNky5IJwPVCiIBEpuUj529O2lWAVfHduUkc9s2JtOY= =ISS3 -----END PGP SIGNATURE----- --7ZRJguJMsNPQGOAuSkTjV5qrW5uYqZeka-- From nobody Thu Jun 18 22:27:13 2020 Return-Path: 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 0AF913A10DB for ; Thu, 18 Jun 2020 22:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 PzuTUqDTzLF4 for ; Thu, 18 Jun 2020 22:27:09 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7D53A10D0 for ; Thu, 18 Jun 2020 22:27:09 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id r2so9936897ioo.4 for ; Thu, 18 Jun 2020 22:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=udWcV4TbRlWcVJjdp0KDWPbl8GmTqKJ0tqFss4ipQog=; b=XvIwP15NpoJ1eWUNfOt9arDhS+I0WlvSLas7/xV0ypIlkdG/HlWwJRs5jU4yUclQqo 74kkDFDJjHBcGgMkSdZI6BMQ9hV53EQk53WVutPlYOGej+RXvea3NIvSQIigUfnySV7O rgpOV3QsEym993khqtyZGonVp/WFBECf3Y/lABkXa1zvA9BzavSyZemgKRyjogZCdD2b HFL5ruB0t/mUmGnlhRvEEskHv16Fwvts0XAx+ZHsTKHARXHSg/lgqHgOtG/kcwl0i5Hm DHsrtrxKpOrFYSrF51kMCC7hCTyfDfhHj+8+Bcr2RVIK1lHKnOyqj5reDXoMAfSlefg1 bxdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=udWcV4TbRlWcVJjdp0KDWPbl8GmTqKJ0tqFss4ipQog=; b=jDnAWMoLebtEcFERp2tSpr/7hqJpdmD5Kx1TI5AIrZyS9Ue5EoIItk5WsEwdFsIM2Q jEx2ZbcuLOPc/Yc+Fsqj+VE48Ogw7DBhVAb0L008ss0CNplmmG4qsT5PPXlKy3h9YS+4 c9FeTU5PoBvy0gzbUSRVxlgMhh12Pip7cut45P+kR/Wu7GJSxLTJvBvzhp0Y2Whh+eAE zuHTpG1wBKYsxIJA3Nd56UyrYS+rkG6klQhz2vcrTEg5D/BEzi0sCo2frvkc3OROyrVZ S3n0TKFFnBrmmIyixCOXf8IeEDx/uYIoqxzF6S6B0Kkpsgd2qyL58PTVTLfyZ/25xecF kxIQ== X-Gm-Message-State: AOAM531ftEcvjsPpzstEEMaomi5L11XNhCidpwhIT0EZUuAC871im+Am +4E//sEkYswC1d6gTk9/NEljBpQJVUWZAgsc/nE= X-Google-Smtp-Source: ABdhPJzxkg6/bRTib48ku8flgbmHW1SDqdMz0t0eV+A9Yc8UGGjHLsldDt4sz+hc7O4ZNL/TwZSMTlAbBKh3hnp96Lk= X-Received: by 2002:a02:1784:: with SMTP id 126mr2201097jah.53.1592544428668; Thu, 18 Jun 2020 22:27:08 -0700 (PDT) MIME-Version: 1.0 References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> In-Reply-To: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> From: Rob Sayre Date: Thu, 18 Jun 2020 22:26:57 -0700 Message-ID: To: Yoav Nir Cc: "" Content-Type: multipart/alternative; boundary="000000000000f5bd0e05a86924f9" Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 05:27:11 -0000 --000000000000f5bd0e05a86924f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 13, 2020 at 10:20 AM Yoav Nir wrote: > > To re-iterate, the policy for the registry is =E2=80=9CSpecification Requ= ired=E2=80=9D and > a specification is available. Unless we hear convincing arguments to the > contrary, we will approve this allocation. We just prefer to have the > kerfuffle before the assignment rather than afterwards. > If the IANA experts feel the 99 page PDF is "sufficiently clear and technically sound" [1], then it should appear in the registry. [2] It seems like it should appear with a "Recommended" value of "No", and no value in the TLS 1.3 column, since the document says "The Middlebox Security Protocol builds on TLS 1.2". [3] Is that what's being proposed? thanks, Rob [1] https://tools.ietf.org/html/rfc8126#section-4.6 [2] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype= -values.xhtml#tls-extensiontype-values-1 [3] https://docbox.etsi.org/CYBER/CYBER/Open/Latest_Drafts/CYBER-0027-2v020-TLM= SP-Transport-Layer-Middlebox-Security-Protocol.pdf (Section 1, scope) --000000000000f5bd0e05a86924f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 13, 2020 at 10:20 AM Yoav Nir= <ynir.ietf@gmail.com> wro= te:

To re-iterate, the policy for the registry is =E2=80=9CSpecification Requ= ired=E2=80=9D and a specification is available. Unless we hear convincing a= rguments to the contrary, we will approve this allocation. We just prefer t= o have the kerfuffle before the assignment rather than afterwards.

If the IANA experts feel the 99 page PD= F is "sufficiently clear and technically sound" [1], then it shou= ld appear in the registry.=C2=A0[2]

It seems like = it should appear with a "Recommended" value of "No", an= d no value in the TLS 1.3 column, since the document says "The Middleb= ox Security Protocol builds on TLS 1.2". [3]

= Is that what's being proposed?

thanks,
Rob

--000000000000f5bd0e05a86924f9-- From nobody Fri Jun 19 06:41:17 2020 Return-Path: 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 6218C3A0A04 for ; Fri, 19 Jun 2020 06:41:16 -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 joRhR-BpkbUH for ; Fri, 19 Jun 2020 06:41:15 -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 1DD023A0A01 for ; Fri, 19 Jun 2020 06:41:14 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05JDZKal024063; Fri, 19 Jun 2020 14:41:09 +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=JzNdu9RPvS0FX+DqYjvBEWGMPSwjqjBWlwf1MDWYVIk=; b=hnl4+y1hRn751cxMLOj7bxjCRUEKLQnDt1/H0p+bi6rL+GQXCm577h0UtP9HmHlqsPln ghzTSvvpksp7YzaHbEoWepxgQXFon9P3fNvP/2vVGGBopj5rRRGTAg7ksicpXzF/Q5b5 wgEqwoBqRwnJ/yQzBq5quP7Tu7biFgiw72wGDl98Mf8P9i/kXrP308xqCqITqmTAqbHA YWiScxKO7yvIvgNfn0Mc/a/C3VVC6ElT9Ma/Oc+T3aI3KoKKlSWzcSkGBMR9+CJDSBUA heT6Utk7dEqKSS8v9bCeJOxLwZzeyI9AOiDJjJuYSEfdVBY5tOuyIe2yk+6b5nSkT3Ny sQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31qrdxj5xs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 14:41:08 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05JDLTi8024764; Fri, 19 Jun 2020 09:41:08 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 31qjm4v94e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 09:41:08 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by USTX2EX-DAG3MB2.msg.corp.akamai.com (172.27.165.126) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 06:41:07 -0700 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 19 Jun 2020 08:41:07 -0500 From: "Salz, Rich" To: Stephen Farrell , "Kaduk, Ben" CC: "tls@ietf.org" Thread-Topic: [TLS] Consultation About Assignment of ExtensionTypes Thread-Index: AQHWQacBJl9Orft490ixhQcIZsEEBqjfcGSAgAADhYCAAA3LgIAAilEA Date: Fri, 19 Jun 2020 13:41:06 +0000 Message-ID: References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> <20200619003641.GE20623@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.133] Content-Type: text/plain; charset="utf-8" Content-ID: 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-19_14:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=931 phishscore=0 malwarescore=0 spamscore=0 bulkscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190098 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_14:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 spamscore=0 clxscore=1015 lowpriorityscore=0 malwarescore=0 mlxlogscore=901 impostorscore=0 bulkscore=0 cotscore=-2147483648 phishscore=0 adultscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190101 Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 13:41:16 -0000 SW4gbXkgdmlldywgYXMgb25lIG9mIHRoZSB0aHJlZSBkZXNpZ25hdGVkIGV4cGVydHMsIHdlIGFs cmVhZHkgaGF2ZSB0aGUgb25seSBjaGFubmVsIHdlIG5lZWQsIGl0J3MgdGhlICJhcHByb3ZlZCIg Y29sdW1uLg0KDQpBbnl0aGluZyBlbHNlIC0tIGFueXRoaW5nIG1vcmUgLS0gcnVucyBjb3VudGVy IHRvIG91ciBwcmluY2lwYWwgb2YgaW50ZXJvcCBvdmVyIGFsbC4NCg0KDQo= From nobody Fri Jun 19 09:50:34 2020 Return-Path: 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 4FCDD3A0CC5 for ; Fri, 19 Jun 2020 09:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 v0UmIqDBIAWW for ; Fri, 19 Jun 2020 09:50:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA943A0CC8 for ; Fri, 19 Jun 2020 09:50:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AED3E389D2; Fri, 19 Jun 2020 12:47:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cai8VIN_avNN; Fri, 19 Jun 2020 12:47:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A2A5389AF; Fri, 19 Jun 2020 12:47:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62978240; Fri, 19 Jun 2020 12:50:17 -0400 (EDT) From: Michael Richardson To: Brian Campbell , ietf-http-wg@w3.org cc: tls@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 16:50:33 -0000 --=-=-= Content-Type: text/plain Brian, {I have been on the httpbis list, but I'm not right now, and I know that w3 and IETF do not share their whitelists, so this might not work} I was thinking about something-something-certificate yesterday while cleaning/swimming my pool. (A long thankless task, as the pool is not heated, we've been getting very a-seasonal *snow*, and nobody in my family but me will swim in it until it's "perfect". Also we have many many trees, which we won't cut down. You can see how my mind might wander) [This discussion would be better done with beer and napkins.] So I am thinking that we need to create a "digital twin" in the back-end server for the front-end TLS state machine. It needs to reflect the current state at a level of detail appropriate for the application. Thus, a single header isn't enough, although there could be some degeneration that results in a single header. We need a few variables to update. I think we have a choice between: 1) sending the state (possibly a few kb) on every transaction, which keeps the protocol stateless. We could explore ways to encode it: CDDL+CBOR seems like a good thing. TLS structures are another obvious choice, but that's a detail. 2) assuming that state will be maintained by both ends, and simply updating the state appropriately. When it comes to this, I think of the HTTP PATCH methods, but I'm not sure I mean this literally. It's the model of having a few objects per-connection that the TLS front-end might update on the backend, and making the management of the TLS connections explicit. Alternately, the TLS front-end could maintain a RESTful interface on a per-connection basis that the back-end could interrogate. The header would just provide the right reference to that. The RESTful interface could even be pushed/updated into some other CPU on the TLS terminator. This is cleaner, but this has read-latency round trip issues, while pushing the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot more pipelined. Or MQTT :-) To this, I think we'd have to look at the RFC8446 Appendix A.2 state machine and figure out how to express this. I don't really see re-auth in that diagram. Maybe I'm overthinking here, but given the opportunities in TLS 1.2 and 1.3 for newer states, and the review from TLS experts on the header, this might be cleaner and less of a hack to get the additional things in. This data model mechanism also better accomodates the split between those who need the entire certificate chain (w/ and w/o trust anchor used), and those that just care about the EE involved. --- I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend connection looks like. I haven't entered such a world personally. TLS front-end systems *are* collecting/storing state on a per-client connection basis, whether the transport is QUIC or not. I don't think it scales well to try to spread that state across load balancers, you want to split the traffic before the TLS terminators in order to horizontally scale them. A thought that I have is that with a move to HTTP/3, that the need for something-something-certificate declines. A model that I could see in such a situation is that since the bulk of the transport is via QUIC, it could be that it makes less sense to have TLS hardware terminators; by careful use of port numbers to demux upon, and/or IPv6 addresses, it might be easier to load balance directly to application servers, and just horizontally scale them wider. The hardware TLS offload box then is only important for adapting HTTP 1 and HTTP/2 connections to HTTP/3. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7s7MkACgkQgItw+93Q 3WXAAwgAkYD7L5eeaddtXyMPYFyjHA+GCEu7W/JcURyPYuBbw0ArWVc7qdkCwASs FR3O6BGigNmb1RhQKpJbljn89LA1M3GXtP0PeRwSW2tbNIUi4KickRStvb8oVxzh P9ehnYB78y4RIN0kZ6RTfZ7NILq46kJEO5aeBZ+/hCbwDCgDzbHOh42AEeaGIjg7 iV5MtGM2TxBZazMrlrSTFn6leiMtOvS/iZHCGPUYvcauilEFYmZwns5TywuOTP5S R2NUkSA3OiP1XpwSryCDKuq0Z2h0rUQpoL4jQs4wGXY+ebVx712Ecgayih6Ikzex L0FtPTBS+qJyGvP58EFunY47vjFmfQ== =RjPO -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 19 11:02:58 2020 Return-Path: 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 AD1F23A0D69 for ; Fri, 19 Jun 2020 11:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 I8aUimnEuIzT for ; Fri, 19 Jun 2020 11:02:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 9A1613A0D4E for ; Fri, 19 Jun 2020 11:02:55 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05JHdktG012716; Fri, 19 Jun 2020 19:02:54 +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 : mime-version; s=jan2016.eng; bh=m1pcuOaEMXRJExJboVRgp/ozYaEtKzF+SJ2NwZc5h+8=; b=i9zzPtn3zi/hn4nm+DmS8z3m3MmFWBs04uIh59375Cjo10RsKGlRZVVJ61RTro3d+vaX Lwbbul7JhJZv8uG49AyTP5fcMArfOPOmhgWkcXaIZUCBrhmz0RdpGigTsYipta3cQi4c 8zrw8pEpQ1mePaSRMLZx6TTrv9G2O51rQ6vPyrhkkdX4LIYPRa7Wbb7hB/jrp6iQC9Ed 5b6SGgym+eM6bSOlevmLPN/dLr0qDSaaZEa9j3MZPvURqweoAVvy+ul22gdIqC892Mxr DQqIrrE4kJEq4nFU/E1gcdLo/Od9PEutjD3PtvzElBs0fqV/3bh2fsxgoUTXUEqz+Zbg 3Q== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 31ru34kk10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 19:02:54 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05JHoEPw032394; Fri, 19 Jun 2020 14:02:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint7.akamai.com with ESMTP id 31qjmn5jub-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 14:02:53 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 11:02:52 -0700 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 19 Jun 2020 13:02:52 -0500 From: "Salz, Rich" To: Rob Sayre , Yoav Nir CC: "" Thread-Topic: [TLS] Consultation About Assignment of ExtensionTypes Thread-Index: AQHWQacBJl9Orft490ixhQcIZsEEBqjfxQOAgACQJIA= Date: Fri, 19 Jun 2020 18:02:51 +0000 Message-ID: <6451A1D4-9A9D-4E82-9D2D-268F7DFDB4D6@akamai.com> References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.119.28] Content-Type: multipart/alternative; boundary="_000_6451A1D49A9D4E829D2D268F7DFDB4D6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_20:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 mlxlogscore=728 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_20:2020-06-19, 2020-06-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 malwarescore=0 bulkscore=0 mlxscore=0 priorityscore=1501 cotscore=-2147483648 mlxlogscore=700 phishscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190132 Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 18:02:57 -0000 --_000_6451A1D49A9D4E829D2D268F7DFDB4D6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXQgc2VlbXMgbGlrZSBpdCBzaG91bGQgYXBwZWFyIHdpdGggYSAiUmVjb21tZW5kZWQi IHZhbHVlIG9mICJObyIsIGFuZCBubyB2YWx1ZSBpbiB0aGUgVExTIDEuMyBjb2x1bW4sIHNpbmNl IHRoZSBkb2N1bWVudCBzYXlzICJUaGUgTWlkZGxlYm94IFNlY3VyaXR5IFByb3RvY29sIGJ1aWxk cyBvbiBUTFMgMS4yIi4gWzNdDQoNCg0KICAqICAgSXMgdGhhdCB3aGF0J3MgYmVpbmcgcHJvcG9z ZWQ/DQoNClllcy4NCg== --_000_6451A1D49A9D4E829D2D268F7DFDB4D6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <098260B7D88B1343B4A1C7027F49298D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY3 NTExMjcxOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 NTY3NjIyMTAgMTg5ODA4NjI4MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkl0IHNlZW1zIGxpa2UgaXQgc2hvdWxkIGFwcGVhciB3 aXRoIGEgJnF1b3Q7UmVjb21tZW5kZWQmcXVvdDsgdmFsdWUgb2YgJnF1b3Q7Tm8mcXVvdDssIGFu ZCBubyB2YWx1ZSBpbiB0aGUgVExTIDEuMyBjb2x1bW4sIHNpbmNlIHRoZSBkb2N1bWVudCBzYXlz ICZxdW90O1RoZSBNaWRkbGVib3ggU2VjdXJpdHkgUHJvdG9jb2wgYnVpbGRzIG9uIFRMUyAxLjIm cXVvdDsuDQogWzNdPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5J cyB0aGF0IHdoYXQncyBiZWluZyBwcm9wb3NlZD88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+WWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6451A1D49A9D4E829D2D268F7DFDB4D6akamaicom_-- From nobody Fri Jun 19 17:40:02 2020 Return-Path: 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 A79643A0F8C for ; Fri, 19 Jun 2020 17:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 eCIf4zNZlyYK for ; Fri, 19 Jun 2020 17:39:59 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9098D3A0F8B for ; Fri, 19 Jun 2020 17:39:59 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id s18so13402817ioe.2 for ; Fri, 19 Jun 2020 17:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Su9p2KPG84Tn6kyqNYN8nLFIXAUsXa3PFPiT5ej+ElY=; b=mZ7QKeGPFW/Nqxp1ygs3j2pNEw6i7VXUYG3QvY2uRXePgAdaBm4e2baMHRheAqz8k4 yoAlnkJ+JU1VpeE669hGT2fE9esAnHtaQWt5beLfRAbA1WeJ69TlBdJx7/VqZFL2ZiM5 yiIDBUMYOphOH9pYiJoEykHDRCOS8hcXepB7nqR482cWvBNHJi6qEqWI8c96qKnAJ201 V9qhVnfOtV0ACpR8krt4HFAjic+cjMokoxtNUuPBkIAA6X5fhzqWa5Z0g4KM4R0GQ5JX fzj3iXj2Jk63Yb1Apg9k6dhtVwnAWBOicXBJM0ybcr8Q8zu4nM6lcMG6mwdMZOhS6X0T BX0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Su9p2KPG84Tn6kyqNYN8nLFIXAUsXa3PFPiT5ej+ElY=; b=Ji3bLS1kJ61RkBhoiKdxjvO0bVLNLZH7WAZI2OQfMXW/EBxR2AMhd0jUFl9zk6QOyp OpFD/rbg4EFAs502tOGezsFZBYfQ+yyfvwdAQM0fB9cPNfMIId40Ipa/YbqePtjKOOdr RWH43826fuOGED29nYjNIPrqljW1imyq7ozrMv0ron5NVw0TQvybM2YZ0O7WUHxJW5Ca RCYPZYs1t5VrD5O2nQ5m77VlOhYQIt2D+hqqGO8FAh0F7LWGLzq7FToJyIX/CAq2+Hdi qe3L0RgFjPlc14pdngKYMRw5aDCk4WJJ3Nx2AWzgBxg8Hq9aX9tMrM4oIGTgFsEPR0Fh 1Ajg== X-Gm-Message-State: AOAM5302LizLn5NIP6F3luQ1BJh2X5z2+uPuUquxM7heipdhvGaOaGLU 1b8tV+KrsN1unR/oyWRbxd0gX7ZePSSeAZbO2SU= X-Google-Smtp-Source: ABdhPJzyyUhfwm6ZMz96iCnWeip/9zTK4vUDmdNHFff6nOAfterCHb1JChJ+Wsu4inUDVo6CFvtOTktR9NGFwu2tHXM= X-Received: by 2002:a05:6602:2c0a:: with SMTP id w10mr7098340iov.46.1592613598702; Fri, 19 Jun 2020 17:39:58 -0700 (PDT) MIME-Version: 1.0 References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> <6451A1D4-9A9D-4E82-9D2D-268F7DFDB4D6@akamai.com> In-Reply-To: <6451A1D4-9A9D-4E82-9D2D-268F7DFDB4D6@akamai.com> From: Rob Sayre Date: Fri, 19 Jun 2020 17:39:45 -0700 Message-ID: To: "Salz, Rich" Cc: Yoav Nir , "" Content-Type: multipart/alternative; boundary="000000000000d0b27205a8793f61" Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 00:40:01 -0000 --000000000000d0b27205a8793f61 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 19, 2020 at 11:02 AM Salz, Rich wrote: > > - It seems like it should appear with a "Recommended" value of "No", > and no value in the TLS 1.3 column, since the document says "The Middlebox > Security Protocol builds on TLS 1.2". [3] > > > > - Is that what's being proposed? > > > > Yes. > I am in favor of this registration. thanks, Rob --000000000000d0b27205a8793f61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2020 at 11:02 AM Salz, Ri= ch <rsalz@akamai.com> wrote:<= br>
  • It seems like it should appear with a "Recommended" val= ue of "No", and no value in the TLS 1.3 column, since the documen= t says "The Middlebox Security Protocol builds on TLS 1.2". [3]

=C2=A0

  • Is that what's being proposed?

=C2=A0

Yes.

<= div>
I am in favor of this registration.

=
thanks,
Rob

--000000000000d0b27205a8793f61-- From nobody Fri Jun 19 20:39:55 2020 Return-Path: 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 6BFD33A1013 for ; Fri, 19 Jun 2020 20:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 NBfIcsx7bode for ; Fri, 19 Jun 2020 20:39:53 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E113A100D for ; Fri, 19 Jun 2020 20:39:52 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id e3so2373672qts.12 for ; Fri, 19 Jun 2020 20:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=5m4PAbBnoTtbNEkdv/zm68ew9s0Ng72nIrnlPiMO20c=; b=Izfnwu/Em7ku2gs07t0MSS4aOXfymBIliSwH+ScBuQ9prqN01OmRApd6tu5HlxMihn /kemleGWvppzVSrjMp5ZGar0pK3QDcKvByAQuRa5zC0MGdF4X1HBP+TLD1AbOkDVW0Ur q4ILLGc/PZmlmj3Zy16ibHBBOaZ9ulpGMu6Tw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=5m4PAbBnoTtbNEkdv/zm68ew9s0Ng72nIrnlPiMO20c=; b=hBEdjSBbLpioP40g7hyqonJBoFb0t8/gh7XoU8oSbn+cH1mVpR5IVXdnlPyYb/MhM5 kTWcPIrVAx06RIM8sN1195qJrffExBZvCJXuyQV0cv9zm7UsiKYS+Jt9jz6OlbzYLHOM OTVqCysXVHVpNXLc6wLTcNawSM8TTwL/khLYfbO6Mn0/OoNJZfV70hJi6N0G0effdXCV vFjPyNb1ekPcE81sXtSO70EWXCKTuYOX39H5OlXtTimNX/n5V7SPzmQdP5yUV8ythZid MIZtoj64hFYGGVxMTjwZpAHrlzL/T4c/Ln9vuSe3NidtJr4rNaLfRaAOg99T1pRetYSG Mj2w== X-Gm-Message-State: AOAM530Cb8yy13Xc5mBEPkVHvQyjgHYXSJIy1/ELrDp3QTyZmBjVFToM 754VSNK2HC31C7pSpLTPE2cFbAJq668= X-Google-Smtp-Source: ABdhPJxJfe+8TluI/pB4YGGYOG6sPBgrffQDc2GkN++AFJKKbqbZrHp3ahjmQXma2r2tDNu30lTFBg== X-Received: by 2002:aed:2001:: with SMTP id 1mr6467450qta.353.1592624391790; Fri, 19 Jun 2020 20:39:51 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id u14sm7662060qkj.18.2020.06.19.20.39.51 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 20:39:51 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 19 Jun 2020 23:39:49 -0400 References: <159245090001.15841.1005352632597031983@ietfa.amsl.com> To: TLS List In-Reply-To: <159245090001.15841.1005352632597031983@ietfa.amsl.com> Message-Id: <50D6989E-E267-4865-9AA7-9554AADEEE17@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-external-psk-guidance-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 03:39:55 -0000 Thanks to Chris for uploading the WG version of the draft. If you have some time over the next couple of weeks please take the time = to review this draft. The intent is to issue a WGLC after IETF 108 = barring any discontent prior that. spt > On Jun 17, 2020, at 23:28, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : Guidance for External PSK Usage in TLS > Authors : Russ Housley > Jonathan Hoyland > Mohit Sethi > Christopher A. Wood > Filename : draft-ietf-tls-external-psk-guidance-00.txt > Pages : 12 > Date : 2020-06-17 >=20 > Abstract: > This document provides usage guidance for external Pre-Shared Keys > (PSKs) in TLS. It lists TLS security properties provided by PSKs > under certain assumptions and demonstrates how violations of these > assumptions lead to attacks. This document also discusses PSK use > cases, provisioning processes, and TLS stack implementation support > in the context of these assumptions. It provides advice for > applications in various use cases to help meet these assumptions. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-00 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-guidance= -00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jun 20 14:05:02 2020 Return-Path: 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 C6C883A0994 for ; Sat, 20 Jun 2020 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 UyaoHRsqzMTV for ; Sat, 20 Jun 2020 14:04:59 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A43A3A0992 for ; Sat, 20 Jun 2020 14:04:59 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id w15so7475535lfe.11 for ; Sat, 20 Jun 2020 14:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P8pbP1pIr2mjjDdTPXL68I4s7sWJl1PizZi2s9rGjm4=; b=0BPMuQG9ZO6rh2+3Lg2HM5mclDkMyFJYlQPfv0QWSgI7pFAWX/K0PjqG1MkUC1m0Bp 1f4eMZbR1QE30tI3kpzfcQirjBGoQXSkikOD+HX78582ZSv9NOKTF9mcXa2ETnXYcW/g gCs4d7dSCNzhg90eSCY3By5GvOzXT5vyMR1NCsi6Eno00xuIXG15ALS9OP3vy7jJ9Ja5 RnnMIZvrCtCGHeow3n7oOTGGwuUUCoibNoCtL/13JDqU1vO2bNCuLE3Vj4OaS/xyEsg1 CyVjRVEGCEkrF9TKZH5WmcuF/AEf7dXd6EH/LpUHrp8A2/uktB2SEg54z4fl3kYz8lVQ 9BDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P8pbP1pIr2mjjDdTPXL68I4s7sWJl1PizZi2s9rGjm4=; b=q1QbNXSgyUvnFEIoxnBrR6ZqfBy5ZwXtSjvNCHvn6HRUovXHzqQ+8nisXrKnz91fZn FbrBe21LWzje+vytc9MV6iosd0O3Gsk8PP9pDQoqY/7uI2LNzBHT68cy3YUrCJa4Y5AG GK1VvJ6/80OlkOTblo/4aGnK/m/MCbtA1EC45Dk3ew/cPRYKW4i3q88b5eOtANaLm2nQ BaovkHWh9m+buUJmjC9ribBcsjm5EmINa24nOyQN6Ncd6u96ktS/lQAWV6PzAVzEGgUF 1nooM8R+kmYNYOLQgC4vjnF/Tv+DY0LgO6ZjW4+NGcIlEnVMOV95+qr2SYr1oRCqitDI 16Ww== X-Gm-Message-State: AOAM531mN+2NVq9v8Bd4i7i27VwszMmeIn1RvgJgFJtQMUYZt8WhUYV6 3v0fy2e7TgV+CMl9PN5NUG4ZyZ61GpCMAEODFEAtKg== X-Google-Smtp-Source: ABdhPJzeQp4OhxYcOqS3i6MT+F5VMNSvnQ6MX8JWcAr9agw1o2tKNW08L71hgIsrYK5kBMDRGhjhm+AJFigxB6pnFcI= X-Received: by 2002:ac2:5f0b:: with SMTP id 11mr5430594lfq.201.1592687097347; Sat, 20 Jun 2020 14:04:57 -0700 (PDT) MIME-Version: 1.0 References: <2F7403F6-C28A-4F5A-8128-A4B4609CA7C5@gmail.com> <6451A1D4-9A9D-4E82-9D2D-268F7DFDB4D6@akamai.com> In-Reply-To: <6451A1D4-9A9D-4E82-9D2D-268F7DFDB4D6@akamai.com> From: Eric Rescorla Date: Sat, 20 Jun 2020 14:04:19 -0700 Message-ID: To: "Salz, Rich" Cc: Rob Sayre , Yoav Nir , "" Content-Type: multipart/alternative; boundary="000000000000ad137505a88a5ce0" Archived-At: Subject: Re: [TLS] Consultation About Assignment of ExtensionTypes 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 21:05:01 -0000 --000000000000ad137505a88a5ce0 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 19, 2020 at 11:03 AM Salz, Rich wrote: > > - It seems like it should appear with a "Recommended" value of "No", > and no value in the TLS 1.3 column, since the document says "The Middlebox > Security Protocol builds on TLS 1.2". [3] > > > > - Is that what's being proposed? > > > > Yes. > _________________ I believe this is the right outcome. While I am not particularly a fan of this protocol and I believe it would likely be better if ETSI abandoned it, the purpose of the 8447 policy is that we do not use code point assignment to discourage the use of protocol extensions we don't approve of. -Ekr ______________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ad137505a88a5ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 19, 2020 at 11:03 AM Salz= , Rich <rsalz=3D40akamai.= com@dmarc.ietf.org> wrote:
  • It seems like it should appear with a "Recommended" value= of "No", and no value in the TLS 1.3 column, since the document = says "The Middlebox Security Protocol builds on TLS 1.2". [3]

=C2=A0

  • Is that what's being proposed?

=C2=A0

Yes.

_________________

I believe this is the rig= ht outcome. While I am not particularly a fan of this protocol and I believ= e it would likely be better if ETSI abandoned it, the purpose of the 8447 p= olicy is that we do not use code point assignment to discourage the use of= =C2=A0 protocol extensions we don't approve of.

-Ekr

______________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ad137505a88a5ce0-- From nobody Sun Jun 21 00:33:08 2020 Return-Path: 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 825913A0A5E for ; Sun, 21 Jun 2020 00:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=B5jLH4AW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jePoZ4Ef 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 6M2W_MB0XuGn for ; Sun, 21 Jun 2020 00:32:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A7F3A0A16 for ; Sun, 21 Jun 2020 00:32:56 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EC4C15C0077 for ; Sun, 21 Jun 2020 03:32:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 21 Jun 2020 03:32:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=9EJwfsw5jOMVCloAmWKgQhX67hpJrf1Yw1Lu1DMhz5M=; b=B5jLH4AW X9YjjDhCU2WA+W5hxtIbt+M8bvQ64K2gunPlgbgZgAmVUYDeYKrQ0ebwMGtZLt2E JYjiWXGnokRBn7IJ7tlrQ77EdAVzf4U88lSovhUU3Z96NsVWxAnZS6w7cfFZ8DN0 63pusXbc5gk0vwU3/qHActLnCvtjIXZ9YP6qto1UUOFRUpdEM9chMitR2+eUx8bt DuCMKfMPMoen50ciqWgpoVCkjkPp2Q12I2UmnKSOHjrNCfDO+rRyRehDDHquHekI ioT3R414hcMRx3k3PCLCO0GvyC7hb6OOp54Z3ByKxJeCgCAk2RopCS7Mv0YGbG5F xJOzagAPgQui/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=9EJwfsw5jOMVCloAmWKgQhX67hpJr f1Yw1Lu1DMhz5M=; b=jePoZ4Efr0R7G48anMFKQnDBDvoOKEqxZ48fFZMEsMR9N EsOfc4Pn60AzT4UdRO6ZZ4ufDruyg22SkGDpi2+PpDN+9aFgx520SGT7ik2hRtr/ lOnMEuUIbQDSO0Zw6IHfiRr2ibGDog6WB4QahjGpF0xEX7xIklJcPzwVbQ0bZ6U7 r+SSABnjsXWWcfIQZ0luzPQBVtANlweeV45phfv/E/Iz5kXO67pwoXa4xjoK1JcI kYuXLEadZeupMq2IZojq38/FWJ7+5zCP3hMY3mPyjgj07HE3lDlY8Rt+Iqwf16II ZyA+nhnAgROKyirz6h2CF9e1Hnwp4mxcc40COCNdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejledguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegvdekhffhhefhfeeluefhgedufeegudefkeeijeevffejfeektdeffeefvdel ieenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhhthhtphhsrhhrnhgrmhgvrdgshi enucfkphephedvrddugeelrdduheekrddvvdehnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhothdrnh gvth X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [52.149.158.225]) by mail.messagingengine.com (Postfix) with ESMTPA id B39AB3280060 for ; Sun, 21 Jun 2020 03:32:55 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2577849072778789450==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200621073255.B39AB3280060@mailuser.nyi.internal> Date: Sun, 21 Jun 2020 03:32:55 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 07:33:05 -0000 --===============2577849072778789450== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC2) 2 issues created: - Decryption failure guidance could be more detailed for trial decryption= (by raycoll) https://github.com/tlswg/draft-ietf-tls-esni/issues/248=20 - Describe risks and mitigations for privacy leaks from configuration dig= est (by sharpie7) https://github.com/tlswg/draft-ietf-tls-esni/issues/245=20 2 issues received 2 new comments: - #245 Describe risks and mitigations for privacy leaks from configuratio= n digest (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/245=20 - #240 Consider strict ECH mode (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/240=20 2 issues closed: - Describe risks and mitigations for privacy leaks from configuration dig= est https://github.com/tlswg/draft-ietf-tls-esni/issues/245=20 - Consider strict ECH mode https://github.com/tlswg/draft-ietf-tls-esni/i= ssues/240=20 * tlswg/tls-subcerts (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #69 [WGLC] Note problems with DCs having lifetimes matching issuing cer= tificates (2 by grittygrease, martinthomson) https://github.com/tlswg/tls-subcerts/issues/69=20 * tlswg/tls-exported-authenticator (+2/-0/=F0=9F=92=AC0) 2 issues created: - WGLC Issue: Watsson (by seanturner) https://github.com/tlswg/tls-exported-authenticator/issues/63=20 - WGLC Issue: Russ (by seanturner) https://github.com/tlswg/tls-exported-authenticator/issues/62=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC1) 2 pull requests submitted: - Expand text around security and privacy goals. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/247=20 - Adopt new HTTPS RR name. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/246=20 1 pull requests received 1 new comments: - #247 Expand text around security and privacy goals. (1 by sharpie7) https://github.com/tlswg/draft-ietf-tls-esni/pull/247=20 2 pull requests merged: - Expand text around security and privacy goals. https://github.com/tlswg/draft-ietf-tls-esni/pull/247=20 - Adopt new HTTPS RR name. https://github.com/tlswg/draft-ietf-tls-esni/pull/246=20 * tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - ROBUST: ePrint publication, typo fixes (by fxguenther) https://github.com/tlswg/dtls13-spec/pull/152=20 * tlswg/tls-subcerts (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Use title case for section titles (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/72=20 1 pull requests merged: - Use title case for section titles https://github.com/tlswg/tls-subcerts/pull/72=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============2577849072778789450== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday June 21, 2020

Issues

tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC2)

2 issues created:

2 issues received 2 new comments:

2 issues closed:

tlswg/tls-subcerts (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

tlswg/tls-exported-authenticator (+2/-0/=F0=9F=92=AC0)

2 issues created:

Pull requests

tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/tls-subcerts (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============2577849072778789450==-- From nobody Mon Jun 22 21:10:29 2020 Return-Path: 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 B67D33A1732 for ; Mon, 22 Jun 2020 21:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=sn3rd.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 3_v4uG6b4Eal for ; Mon, 22 Jun 2020 21:10:26 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFA23A1731 for ; Mon, 22 Jun 2020 21:10:26 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id e11so8413483qkm.3 for ; Mon, 22 Jun 2020 21:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=Nu16Ky/EAJMk1EoLZSMSoA6rtE6pGSqIcv9W8SsXFE4=; b=Fmok+JqKHQLPkSPIlNCUoiuRpc7huHW8LRZqC4q+YbdboW9L+8ryGdgHjamdI4AZtV MyeFSvNatWutQD/44wNLlcJjqfSPZfhuLN2MmvyCXcmlZ4yFtUalCsuNDjSNprQE0AQR HYmdWSKJPiqemuUBVawrX/7wMuW/vlIYsLt1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=Nu16Ky/EAJMk1EoLZSMSoA6rtE6pGSqIcv9W8SsXFE4=; b=U5Yd8cJlwd37pHVSG5I6vBaWMv3RIlZ1YBfXeQ+GK1h5AYExJVjnEv2zEiMmb6SKgT zwqDUIKqfEFsVcHTgevf9Ry27ZuByvHt0L96phGRTY3kcYawv6Juxnbh8tRlOp61Yu5J 9j+CllTbFeovlJcKIgB7ANNuV4bxD4Tv4cpNLR/VhIe5+SDh0XHl4kPGiIyqfcYpM4UH mEGETLepgJ6EuNJej4h/Lp3ttzwy5jSQH2PR8ko3HK34fYZ6zJoZ61ee404uXMmWtVUY zeqe9etCJ5EtcmtPVPmht78qQSTbopD44zQZcYhgmBGYM/Xj/3/9vBfJZvbu/ZQaZWJ/ Lkgw== X-Gm-Message-State: AOAM531aPZdqQSxx1o2npI70liI+ZWDHaFYGUZdj5AE8wAxif+t2hCce 1pmTEMDXSklmGsgYC06x8ClzKXFSqlg= X-Google-Smtp-Source: ABdhPJxh3Aez8DWJYcRy3SkYOXFDcOEsHJITSReUxdSHvfE55I62iW84RZnG0rIGtnPJ0OuAeDOGjA== X-Received: by 2002:a05:620a:102c:: with SMTP id a12mr18551373qkk.226.1592885425192; Mon, 22 Jun 2020 21:10:25 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id g4sm14646847qka.97.2020.06.22.21.10.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 21:10:24 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_0F816188-1F19-4B7E-AE14-6C7F506633DD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <9867FD59-5469-4190-BB60-B26C9173250A@sn3rd.com> References: <159251992201.11993.15942540018989542642@ietfa.amsl.com> To: TLS List Date: Tue, 23 Jun 2020 00:10:23 -0400 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] Fwd: Nomcom 2020-2021 Final Call For Volunteers 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 04:10:29 -0000 --Apple-Mail=_0F816188-1F19-4B7E-AE14-6C7F506633DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In case you are not on the IETF discuss list. spt > Begin forwarded message: >=20 > From: NomCom Chair 2020 > Subject: Nomcom 2020-2021 Final Call For Volunteers > Date: June 18, 2020 at 18:38:42 EDT > To: "IETF Announcement List" > Cc: ietf@ietf.org >=20 > Hi IETFers, > We're down to the last week of accepting NomCom volunteers. And I need = more! Lots more! >=20 > I have 64. I'd really like to get another 100 names. Hopefully, some = of you are checking the volunteer box on IETF 108 registration. But I = don't have anything from canceled IETF 107 registration, and the NomCom = question wasn't asked on IETF 106. So I need a flood of volunteers to = come in over the next week. > Barbara > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The IETF NomCom appoints people to fill the open slots on the LLC, = IETF Trust, the IAB, and the IESG. >=20 > Ten voting members for the NomCom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. >=20 > The details of the operation of the NomCom can be found in BCP 10 (RFC = 8713). RFC 3797 details the selection algorithm. >=20 > Special for this year (and only this year), we also have RFC 8788 = (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to = volunteer: >=20 > Members of the IETF community must have attended at least three = of > the last five in-person IETF meetings in order to volunteer. >=20 > The five meetings are the five most recent in-person meetings = that > ended prior to the date on which the solicitation for NomCom > volunteers was submitted for distribution to the IETF community. > Because no IETF 107 in-person meeting was held, for the 2020-2021 > Nominating Committee those five meetings are IETFs > 102 [Montreal, Canada; July 2018], > 103 [Bangkok, Thailand; November 2018], > 104 [Prague, Czech Republic; March 2019], > 105 [Montreal, Canada; July 2019], and=20 > 106 [Singapore; November 2019]. >=20 > Keep in mind that eligibility is based on in-person attendance at the = five listed meetings. You can check your eligibility at: = https://www.ietf.org/registration/nomcom.py. >=20 > If you qualify, please volunteer. Before you decide to volunteer, = please remember that anyone appointed to this NomCom will not be = considered as a candidate for any of the positions that the 2020 - 2021 = NomCom is responsible for filling. >=20 > People commonly volunteer by ticking the box on IETF registration = forms. The IETF 106 form did not ask whether people were willing to = volunteer. IETF 107 did ask, but all those registrations were canceled. = I have asked the Secretariat if it is possible to get the list if = volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering! >=20 > The list of people and posts whose terms end with the March 2021 IETF = meeting, and thus the positions for which this NomCom is responsible, = are >=20 > IETF Trust: > Joel Halpern >=20 > LLC: > Maja Andjelkovic >=20 > IAB: > Jari Arkko > Jeff Tantsura > Mark Nottingham > Stephen Farrell > Wes Hardaker > Zhenbin Li >=20 > IESG: > Alissa Cooper, IETF Chair/GEN AD > Alvaro Retana, RTG AD > Barry Leiba, ART AD > Deborah Brungard, RTG AD > =C3=89ric Vyncke, INT AD > Magnus Westerlund, TSV AD > Roman Danyliw, SEC AD > Warren Kumari, OPS AD >=20 > All appointments are for 2 years. The Routing area has 3 ADs and the = General area has 1; all other areas have 2 ADs. Thus, all areas (that = have more than one AD) have at least one continuing AD. >=20 > The primary activity for this NomCom will begin in July 2020 and = should be completed in January 2021. The NomCom will have regularly = scheduled conference calls to ensure progress. There will be activities = to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates. >=20 > While being a NomCom member does require some time commitment it is = also a very rewarding experience. >=20 > As a member of the NomCom it is very important that you be willing and = able to attend either videoconference or in-person meetings (which may = not happen) during 14-20 November (IETF 109 - Bangkok) to conduct = interviews. Videoconference attendance will be supported whether or not = there are in-person meetings. Orientation and setting of the NomCom = schedule will be done by videoconference during the week 20-24 July = (exact time and date to be determined after NomCom membership is = finalized on July 12), the week prior to IETF 108. Being at IETF 110 = (Prague) is not essential. >=20 > Please volunteer by sending me an email before 23:59 UTC June 24, = 2020, as follows: >=20 > To: nomcom-chair-2020@ietf.org > Subject: NomCom 2020-21 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name:=20 > // as you write it on the IETF registration form >=20 > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form >=20 > Emails:=20 > // All email addresses used to register for the past 5 IETF meetings > // Preferred email address first >=20 > Telephone:=20 > // For confirmation if selected >=20 > You should expect an email response from me within 5 business days = stating whether or not you are qualified. If you don't receive this = response, please re-send your email with the tag "RESEND"" added to the = subject line. >=20 > If you are not yet sure if you would like to volunteer, please = consider that NomCom members play a very important role in shaping the = leadership of the IETF. Questions by email or voice are welcome. = Volunteering for the NomCom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the NomCom web site at: > https://datatracker.ietf.org/nomcom/2020/ >=20 > I will be publishing a more detailed target timetable, as well as = details of the randomness seeds to be used for the RFC 3797 selection = process, within the next few weeks. >=20 > Thank you! >=20 > Barbara Stark > bs7652 at att dot com > nomcom-chair-2020 at ietf dot org >=20 --Apple-Mail=_0F816188-1F19-4B7E-AE14-6C7F506633DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = case you are not on the IETF discuss list.

spt

Begin = forwarded message:

From: = NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
Subject: = Nomcom 2020-2021 = Final Call For Volunteers
Date: = June 18, 2020 at 18:38:42 = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org

Hi IETFers,
We're= down to the last week of accepting NomCom volunteers. And I need more! = Lots more!

I have 64. I'd really like to = get another 100 names. Hopefully, some of you are checking the volunteer = box on IETF 108 registration. But I don't have anything from canceled = IETF 107 registration, and the NomCom question wasn't asked on IETF 106. = So I need a flood of volunteers to come in over the next week.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe IETF NomCom appoints people to fill the open slots on = the LLC, IETF Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a = verifiably random way from a pool of volunteers. The more volunteers, = the better chance we have of choosing a random yet representative cross = section of the IETF population.

The details = of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC = 3797 details the selection algorithm.

Special= for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

     Members of the = IETF community must have attended at least three of
=      the last five in-person IETF meetings in = order to volunteer.

=      The five meetings are the five most recent = in-person meetings that
=      ended prior to the date on which the = solicitation for NomCom
=      volunteers was submitted for distribution = to the IETF community.
=      Because no IETF 107 in-person meeting was = held, for the 2020-2021
=      Nominating Committee those five meetings = are IETFs
       102 = [Montreal, Canada; July 2018],
=        103 [Bangkok, Thailand; = November 2018],
=        104 [Prague, Czech Republic; = March 2019],
=        105 [Montreal, Canada; July = 2019], and
       106 = [Singapore; November 2019].

Keep in mind = that eligibility is based on in-person attendance at the five listed = meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you = decide to volunteer, please remember that anyone appointed to this = NomCom will not be considered as a candidate for any of the positions = that the 2020 - 2021 NomCom is responsible for filling.

People commonly volunteer by ticking the box on IETF = registration forms. The IETF 106 form did not ask whether people were = willing to volunteer. IETF 107 did ask, but all those registrations were = canceled. I have asked the Secretariat if it is possible to get the list = if volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering!

The list of people and posts = whose terms end with the March 2021 IETF meeting, and thus the positions = for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja = Andjelkovic

IAB:
=    Jari Arkko
   Jeff = Tantsura
   Mark Nottingham
=    Stephen Farrell
   Wes = Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF = Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
=    Deborah Brungard, RTG AD
=    =C3=89ric Vyncke, INT AD
=    Magnus Westerlund, TSV AD
=    Roman Danyliw, SEC AD
=    Warren Kumari, OPS AD

All = appointments are for 2 years. The Routing area has 3 ADs and the General = area has 1; all other areas have 2 ADs. Thus, all areas (that have more = than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 = and should be completed in January 2021.  The NomCom will have = regularly scheduled conference calls to ensure progress. There will be = activities to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates.

While being a = NomCom member does require some time commitment it is also a very = rewarding experience.

As a member of the = NomCom it is very important that you be willing and able to attend = either videoconference or in-person meetings (which may not happen) = during 14-20 November (IETF 109 - Bangkok) to conduct interviews. = Videoconference attendance will be supported whether or not there are = in-person meetings. Orientation and setting of the NomCom schedule will = be done by videoconference during the week 20-24 July (exact time and = date to be determined after NomCom membership is finalized on July 12), = the week prior to IETF 108.  Being at IETF 110 (Prague) is not = essential.

Please volunteer by sending me = an email before 23:59 UTC June 24, 2020, as follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom = 2020-21 Volunteer

Please include the = following information in the email body:

Your= Full Name:
   // as you write it on the = IETF registration form

Current Primary = Affiliation:
   // Typically what goes in = the Company field
   // in the IETF = Registration Form

Emails:
=   // All email addresses used to register for the past 5 IETF = meetings
  // Preferred email address first

Telephone:
=    // For confirmation if selected

You should expect an email response from me within 5 business = days stating whether or not you are qualified.  If you don't = receive this response, please re-send your email with the tag "RESEND"" = added to the subject line.

If you are not = yet sure if you would like to volunteer, please consider that NomCom = members play a very important role in shaping the leadership of the = IETF.  Questions by email or voice are welcome. Volunteering for = the NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site = at:
   https://datatracker.ietf.org/nomcom/2020/
I will be publishing a more detailed target timetable, as = well as details of the randomness seeds to be used for the RFC 3797 = selection process, within the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf = dot org


= --Apple-Mail=_0F816188-1F19-4B7E-AE14-6C7F506633DD-- From nobody Wed Jun 24 22:10:43 2020 Return-Path: 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 550033A00D3 for ; Wed, 24 Jun 2020 22:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 bA1XS5U_5ftW for ; Wed, 24 Jun 2020 22:10:41 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117CB3A00DF for ; Wed, 24 Jun 2020 22:10:40 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id v19so3697525qtq.10 for ; Wed, 24 Jun 2020 22:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=2nHoGMw+I0S/M8VTL4KzjrDXOmiy6gj0xJOryYsFGoc=; b=XaLUBat0clXn5kSsEl7M2jpsBGcCaoj641MB9vmOW8Q8tLKuH75L9LBm/A/KEaUZs7 7Jy03jQnXCcfHOSJ2GYBkDwtjWDtOnP1exrLNwQ/o6aoHCq58KISxzyh6zcaLS4Hhsf0 cb4rg/FGXEn3Zz/DYoc0zYNDUcSNGcvefzVr+0WRSPlefTu33WxMiYfuWfzUeB4tYoMY CH5dmHbmvVce8EExDegRIb0dlBsjXmY9Gs6ZgoNmGwty6RjjrZIviLK22jlSJvqhzp+B SxYkJQy4LlQus9GK0Q/kWR5ppdVXiH+7SJtpoizqxQzk6Ye7LMpaxF+5Z14ZPo/zYUnn h4QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2nHoGMw+I0S/M8VTL4KzjrDXOmiy6gj0xJOryYsFGoc=; b=FClnZlI5Jb/1HaGmE42gkPugvtG8Dc1tRIlaYDWkjRQB5awK8vsnC6ezn3yKQXxxX7 CjeoxSUc3alby5gb5KRmfmswZbtTq2mlN0mtCHQ1PaY/sZIzZycXEzWUWcqhiUDrl9Yi TrhTRTMiIt7kosJUnfZjAv4OxGZcrQZPMBusrcwmNaOu/VDI5KD8/SO0yStDNLMQOKoo Nl1hmcumoeaSf65Anw751bxnlavXU3bdcVgAUJcaEOYLkVQ65Obx53+nZ6qHpyruz9Na 9p3TOhXPXjKB0rM9poMdgjSAqnXHIUXHUs3iHLRQa42fGOxFoYi84P2RqMyRl1MKJjQI i8Cg== X-Gm-Message-State: AOAM5314cMfgNj3bXe61vNUMG1jdromT6I3GzAxU2zdPg6SF+TcsGnjT hnHtQUBLS6Ua2ILzDlrVc5Mpc187N1UFYKwYmVKvROYkMCs= X-Google-Smtp-Source: ABdhPJyF2ZbDTU1PvhYq6K0OQJS0mcV7LJaqGI1anjAvhW9wLvSQcPUCJIiWTuyRvafLSdgQOAA9/rRsYFpNUWM342s= X-Received: by 2002:ac8:1ac4:: with SMTP id h4mr17615769qtk.249.1593061839818; Wed, 24 Jun 2020 22:10:39 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Wed, 24 Jun 2020 22:10:28 -0700 Message-ID: To: "" Cc: Benjamin Kaduk , draft-ietf-tls-md5-sha1-deprecate@ietf.org Content-Type: multipart/alternative; boundary="00000000000011664405a8e19da1" Archived-At: Subject: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 05:10:42 -0000 --00000000000011664405a8e19da1 Content-Type: text/plain; charset="UTF-8" Hi All, I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the recommended IANA registry entries for rsa_pkcs1_sha1 and ecdsa_sha1 in the Signature Scheme registry from Y to N. This change can be incorporated with any updates from the AD review. Please post to this thread if you have any concerns with this change. Cheers, Joe [1] https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7 --00000000000011664405a8e19da1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I submitted a PR [1] for draft-= ietf-tls-md5-sha1-deprecate to move the recommended IANA registry entries f= or=C2=A0 rsa_pkcs1_sha1 and=C2=A0ecdsa_sha1 in the Signature Scheme registry from Y to N.= =C2=A0 =C2=A0This change can be incorporated with any updates from t= he AD review.=C2=A0=C2=A0

Please post to this thre= ad if you have any concerns with this change.=C2=A0=C2=A0
--00000000000011664405a8e19da1-- From nobody Thu Jun 25 04:32:39 2020 Return-Path: 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 265D13A094C; Thu, 25 Jun 2020 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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=gmail.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 pAcs3WnyhCDx; Thu, 25 Jun 2020 04:32:35 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C475B3A094D; Thu, 25 Jun 2020 04:32:35 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id i16so4279803qtr.7; Thu, 25 Jun 2020 04:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=+/OS5IIMUI7/wtNlRvXz76kJP4KU9Ri1obFuNWizqgY=; b=fgf+xLW2sd6nIwDTiEMwap4US5vkAs+Ya3gJnWhFsncNShf2w+LBOfh/0AEX41sVlw /IPsZj3501T7dY6/3oXC1E2Fs1n0g2C20vL9vMPAAycRHgL2DEb5NnhyGjxQHCSbNu8f Pg088bg7bobFGZ+gohtZ+muRRTnpIm4Q9JnvCPOAjhDFsOO69GEcx8+7hdZPkkg9LwjK xVvZBFifJuSHvxIvnLr6kVlkwNK5ZvzfWiYD/h/t1CJCUy3BvRQRHacNGHvzV5B0QSQc GL09A/9teE1Bg2QsQTEGlWDxXr3RDqZQ1vHqcZjxTaL81LXVOYs4k+g+OOfu6ZyqmoZU jXLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=+/OS5IIMUI7/wtNlRvXz76kJP4KU9Ri1obFuNWizqgY=; b=cJAtLsCi5/XurKjOCKtqW5VDB6p2MA8mnQgNJQdeE/Msj+02ATHweES2GDaENWC2AN IAlmetrhXtfLnLxEeMFzS2Khud3ali4JxhiDVMG1G3hJlSqH7O+dC07Ka/kXJN1mwXhe QIckC4evhVppl/9KQyYbO/peN1zCyrUxInxJ+qVdUNeracmZtJRA/RPK/6598a4l3Auf JvxyOk0VVRHrBJHdX0gAtBdSLFHKhw9W8/AMMneJiL9n3Xnj/u7juLW3p2TolkF75FSw +6ifphl+KCIT6tKwZEE5E1rVRl6I9AG64F4fbIA8H7Q7aXQn0WDAyFq7IPtbBvKsYKar Av9A== X-Gm-Message-State: AOAM531XVe08+vhKxZyKHyOM8RPq/xcdM3REQaBMTUOlTVxPeulNJDaa RRAQE67sgtY3ifA6pDQD7rWiomaH X-Google-Smtp-Source: ABdhPJwb/dxayG64dEmGcjyzX7Rej0m/oFusmZO3HHGcbTNzr+vM+YhyIA1c/9EK75EChMhMPRhwiw== X-Received: by 2002:ac8:4316:: with SMTP id z22mr19619394qtm.121.1593084754918; Thu, 25 Jun 2020 04:32:34 -0700 (PDT) Received: from [192.168.1.2] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id o12sm6188399qtl.48.2020.06.25.04.32.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 04:32:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-70C18F9E-9557-42B3-ABC8-C28159844D90 Content-Transfer-Encoding: 7bit From: Kathleen Moriarty Mime-Version: 1.0 (1.0) Date: Thu, 25 Jun 2020 07:32:33 -0400 Message-Id: <300221E9-F91E-4910-B07D-6568E364B5D4@gmail.com> References: Cc: "" , Benjamin Kaduk , draft-ietf-tls-md5-sha1-deprecate@ietf.org In-Reply-To: To: Joseph Salowey X-Mailer: iPhone Mail (17F80) Archived-At: Subject: Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 11:32:37 -0000 --Apple-Mail-70C18F9E-9557-42B3-ABC8-C28159844D90 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Joe. Sent from my mobile device > On Jun 25, 2020, at 1:10 AM, Joseph Salowey wrote: >=20 > =EF=BB=BF > Hi All, >=20 > I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the rec= ommended IANA registry entries for rsa_pkcs1_sha1 and ecdsa_sha1 in the Sig= nature Scheme registry from Y to N. This change can be incorporated with a= ny updates from the AD review. =20 >=20 > Please post to this thread if you have any concerns with this change. =20 >=20 > Cheers, >=20 > Joe >=20 > [1] https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7 >=20 >=20 --Apple-Mail-70C18F9E-9557-42B3-ABC8-C28159844D90 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, Joe.

Sen= t from my mobile device

= On Jun 25, 2020, at 1:10 AM, Joseph Salowey <joe@salowey.net> wrote:
= --Apple-Mail-70C18F9E-9557-42B3-ABC8-C28159844D90-- From nobody Thu Jun 25 05:36:30 2020 Return-Path: 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 64B593A097F; Thu, 25 Jun 2020 05:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 4IP_hKSUgBQz; Thu, 25 Jun 2020 05:36:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 1530A3A097D; Thu, 25 Jun 2020 05:36:26 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05PCYKV3016515; Thu, 25 Jun 2020 13:35:25 +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 : mime-version; s=jan2016.eng; bh=s2rE3vAEsSfy/bRgcb9Z9P3d/g4KLtCEfc5ZXn7aLHs=; b=JE5sjXr9PAMrUWqKYtCvCdgFYo5vnqIFjuK4bZgTlL7Sdaj5GZkrhe+tpt2rPjqBjk3t oX6Bst3DZHMBKNVFeZEKPakBoUDJd++iQ+/5GJWaJy6WL5i0pckLKBTMDSeN4gyVMOag Xjv5sKoIzTyafKTiX2YVpbdSvvtMH0fDo+tqorutQtxU7btJa1c5SkK7upshtp8Buf5f 0pqDQL6WDvRpiOzi4iuaIoN7HB44mS8imKrZc9m0obIXLfGgeaJ8cFhy1oFDIJesajt9 TZgJG9+g0S4QSW1tzyySe74x6j3FiL6NKA6IzlOzd+N5xKa387QlBQzYDZeGgmsk+zs6 /A== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31uus697dv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jun 2020 13:35:25 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05PCKjpf011754; Thu, 25 Jun 2020 08:35:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint4.akamai.com with ESMTP id 31uus99gnp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jun 2020 08:35:24 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 25 Jun 2020 07:35:23 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Thu, 25 Jun 2020 07:35:23 -0500 From: "Salz, Rich" To: Joseph Salowey , "" CC: Benjamin Kaduk , "draft-ietf-tls-md5-sha1-deprecate@ietf.org" Thread-Topic: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate Thread-Index: AQHWSq8CBJsJUNb3U0+Rw4Vr/2/hRqjpVZQA Date: Thu, 25 Jun 2020 12:35:22 +0000 Message-ID: <49C2B577-FD06-44E7-A6E1-6F74E2AB85A9@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.32] Content-Type: multipart/alternative; boundary="_000_49C2B577FD0644E7A6E16F74E2AB85A9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-25_05:2020-06-25, 2020-06-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=688 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006250078 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-25_08:2020-06-25, 2020-06-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 clxscore=1011 suspectscore=0 mlxlogscore=659 cotscore=-2147483648 mlxscore=0 adultscore=0 spamscore=0 impostorscore=0 malwarescore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006250080 Archived-At: Subject: Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 12:36:28 -0000 --_000_49C2B577FD0644E7A6E16F74E2AB85A9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBzdWJtaXR0ZWQgYSBQUiBbMV0gZm9yIGRyYWZ0LWlldGYtdGxzLW1kNS1zaGExLWRl cHJlY2F0ZSB0byBtb3ZlIHRoZSByZWNvbW1lbmRlZCBJQU5BIHJlZ2lzdHJ5IGVudHJpZXMgZm9y ICByc2FfcGtjczFfc2hhMSBhbmQgZWNkc2Ffc2hhMSBpbiB0aGUgU2lnbmF0dXJlIFNjaGVtZSBy ZWdpc3RyeSBmcm9tIFkgdG8gTi4gICBUaGlzIGNoYW5nZSBjYW4gYmUgaW5jb3Jwb3JhdGVkIHdp dGggYW55IHVwZGF0ZXMgZnJvbSB0aGUgQUQgcmV2aWV3Lg0KDQpZZXMgeWVzIHllcy4NCg0KT3Ig bm8gbm8gbm8/DQoNCkkgdGhpbmsgaXQgaXMgcmVtb3ZlIHRoZSDigJxZ4oCdIGFuZCBsZWF2ZSBi bGFuaywgcmlnaHQ/DQo= --_000_49C2B577FD0644E7A6E16F74E2AB85A9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <83EA1BBB32C870439F7088513F58A134@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkhlbHZldGljYSBOZXVlIjsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6OTUyMzIyNjgxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTIyMzExMjM3NCAtNzIwMDUwOTM4IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xk O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSBzdWJtaXR0ZWQgYSBQ UiBbMV0gZm9yIGRyYWZ0LWlldGYtdGxzLW1kNS1zaGExLWRlcHJlY2F0ZSB0byBtb3ZlIHRoZSBy ZWNvbW1lbmRlZCBJQU5BIHJlZ2lzdHJ5IGVudHJpZXMgZm9yJm5ic3A7IHJzYV9wa2NzMV9zaGEx IGFuZCZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrIj5lY2RzYV9zaGExDQogaW4gdGhlIFNp Z25hdHVyZSBTY2hlbWUgcmVnaXN0cnkgZnJvbSBZIHRvIE4uJm5ic3A7ICZuYnNwOzwvc3Bhbj5U aGlzIGNoYW5nZSBjYW4gYmUgaW5jb3Jwb3JhdGVkIHdpdGggYW55IHVwZGF0ZXMgZnJvbSB0aGUg QUQgcmV2aWV3LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ZZXMgeWVzIHllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3Igbm8gbm8g bm8/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgcmVtb3ZlIHRoZSDigJxZ 4oCdIGFuZCBsZWF2ZSBibGFuaywgcmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_49C2B577FD0644E7A6E16F74E2AB85A9akamaicom_-- From nobody Thu Jun 25 13:29:32 2020 Return-Path: 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 625323A0FF7 for ; Thu, 25 Jun 2020 13:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=selfienetworks-com.20150623.gappssmtp.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 KDMITe_yK10V for ; Thu, 25 Jun 2020 13:29:29 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF993A0F56 for ; Thu, 25 Jun 2020 13:29:28 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id e15so4304750vsc.7 for ; Thu, 25 Jun 2020 13:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=RLxmzLaG8mKow+IApNGl0Ad/kjaxMNzgnqDtxgGnegs=; b=qI0XOpaW8uUw/C5ggt1uYonhD/IqXumLfPt1ce2rvb+8z05K7zrMGxER9Ps9c0k4iI wBVrWo/gwpdtR54L4qiudC0Ehoo9B0SZgCGU/znkzWhKg4u64UW7DJDlL74n8npv4m6o JVXVXIkddQmYN5KTxx+8eERAdXnZ2liEEwCPGg9vHjE+Z9T/khLFcUxUZEONoU74FcH/ UrPCBmD8X8P3GSktOH9nVcFoi5rmRwRTqNd+hbEbMP+1oDjWl5zcA30zMptWA6G/Vxll V5dFsG0X+MlHkD11QfEH9n+F6ZPl3RWfTYcDpGG87OXJDtUcvzckW6ZaMAv7iqG5EISP vsVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=RLxmzLaG8mKow+IApNGl0Ad/kjaxMNzgnqDtxgGnegs=; b=MC1MwStejwCA4KPTWdFRem3qCIzqhDR1Wh1OzY8GDb5xGifuqG9CbIrm1dF3dkFs5q Nu0Zuo0yxVNFGb4aQiK/GCsHqKOyStnk4+zMIOit3kTrWTfT1HwCuMVi5r0u0DZxmTsh CfZTjTZP6mcoVpw9aDzgpuURwljikPoRQq1SGbmXe3BLq4FeEHF6s6VtLPCeZHgjrqyB d99mQCgZdWEFczZtXTT0gaDVgfVFLCH1hwzPUnLTho2scF9iNmZ6Yysj6xhIzNQNGbF0 TI+rgRjdvg7Y5lwthU2uGVIux9QCqTHseAnhxIY+USguA0QtfqR+k6nP3xlG1ywSVa/1 iCCA== X-Gm-Message-State: AOAM532KSydtbFsS2X80o7bmnMFXXU95oPjHdtPpxXX/35rZ0Y+eEZSe TUcNNBhvQ+9o4YgxbGdA/S0mmVs4CmY= X-Google-Smtp-Source: ABdhPJwqRaRwGRRRJaBigNNI3YTFGal0VrCIGZa9ANAoa48vMCN3WE4kICzy8u25nM8FUyvzLqjmqQ== X-Received: by 2002:a67:efd2:: with SMTP id s18mr8282463vsp.129.1593116967350; Thu, 25 Jun 2020 13:29:27 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id d3sm2211240vko.51.2020.06.25.13.29.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 13:29:27 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kbv8p2nq.aff97c29-172a-4561-abff-1bd6d6c99274 Date: Thu, 25 Jun 2020 20:29:26 +0000 Message-ID: X-Mailer: Superhuman Desktop (2020-06-25T18:26:57Z) X-Superhuman-Draft-ID: draft00b88c146cdc92dd X-Superhuman-Thread-ID: draft001206cc1f7ffca3 From: "Yiannis Yiakoumis" To: tls@ietf.org Content-Type: multipart/alternative; boundary=3e2d6228006edcdcbf3c41ee0ad58b4ead692f243030f1ecd1d75f04d2c1 Archived-At: Subject: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 20:29:31 -0000 --3e2d6228006edcdcbf3c41ee0ad58b4ead692f243030f1ecd1d75f04d2c1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi all, I wanted to briefly introduce network tokens ( https://networktokens.org ) = into this list, how they relate with TLS and ESNI, and kindly ask anyone th= at is interested to share feedback and join the discussion. Network tokens is a method for endpoints to explicitly and securely coordin= ate with networks about how their traffic is treated. They are inserted by = endpoints in existing protocols, interpreted by trusted networks, and may b= e signed or encrypted to meet security and privacy requirements. Network to= kens provide a means for network operators to expose datapath services (suc= h as a zero-rating service, a user-driven QoS service, or a firewall whitel= ist), and for end users and application providers to access such services. = Network tokens are inspired and derived by existing security tokens (like J= WT and CWT), borrowing several of their security and privacy properties, an= d adjusting them for use in a networking context. There are two ways that network tokens relate with TLS: * They can support ESNI adoption: in a world where ESNI is widely adopted, = network tokens can enable use cases where endpoint-network coordination is = required, without having to go back to plaintext SNI that everyone can read= . * Network tokens are embedded as TLS handshake extensions (among others). We are shooting for a BoF in November, and=C2=A0are very much interested in= to feedback around the concept, use cases, what we need to do to make netwo= rk tokens adopted as a TLS handshake extension, and folks that are interest= ed to get involved in the effort! Links to an IETF I-D, a mailing list, and initial implementation are availa= ble at https://networktokens.org ( https://networktokens.org/ ). Best, Yiannis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Yiannis Yiakoumis Co-Founder & CEO https://selfienetworks.com | +1-650-644-7857 --3e2d6228006edcdcbf3c41ee0ad58b4ead692f243030f1ecd1d75f04d2c1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
3D"
Hi all,

I wanted to briefly introduce=C2=A0network tokens in= to this list, how they relate with TLS and ESNI, and kindly ask anyone that= is interested to share feedback and join the discussion.

Network tokens is a method= for endpoints to explicitly and securely coordinate with networks about ho= w their traffic is treated. They are inserted by endpoints in existing prot= ocols, interpreted by trusted networks, and may be signed or encrypted to m= eet security and privacy requirements. Network tokens provide a means for n= etwork operators to expose datapath services (such as a zero-rating service= , a user-driven QoS service, or a firewall whitelist), and for end users an= d application providers to access such services. Network tokens are inspire= d and derived by existing security tokens (like JWT and CWT), borrowing sev= eral of their security and privacy properties, and adjusting them for use i= n a networking context.

There are two ways that network tokens relate with TLS:
=
  1. They can support ESNI adoption: in a world wh= ere ESNI is widely adopted, network tokens can enable use cases where endpo= int-network coordination is required, without having to go back to plaintex= t SNI that everyone can read.=C2=A0
  2. Network tokens = are embedded as TLS handshake extensions (among others).=C2=A0
    3. We are shooting for a BoF in November, and=C2=A0are very = much interested into feedback around the concept, use cases, what we need t= o do to make network tokens adopted as a TLS handshake extension, and folks= that are interested to get involved in the effort!

    Links to an IETF I-D, a mailing list, and ini= tial implementation are available at https://networktokens.org=C2=A0 .=C2=A0

    Best,
    Yiannis

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Yiannis Yiakoumis
    Co-Founder & CEO
    https://selfienetworks.com | +1-650-644-7857
    <= /div>

    --3e2d6228006edcdcbf3c41ee0ad58b4ead692f243030f1ecd1d75f04d2c1-- From nobody Thu Jun 25 14:31:43 2020 Return-Path: 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 CB3DE3A102F for ; Thu, 25 Jun 2020 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=pingidentity.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 t4Jd6Q0hzLyc for ; Thu, 25 Jun 2020 14:31:38 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCCF3A102E for ; Thu, 25 Jun 2020 14:31:38 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id b25so4545317ljp.6 for ; Thu, 25 Jun 2020 14:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M0c83yt8DuUJ8so7neCORgW723l3VAUAqtDAMPeYyBw=; b=RYihjtN3lYsJPSkK3MbSyYtoElWyQQYrl8UlwvG3mMNS0cdVxWFkW7E0Cmx09GVLfE /lfEmf7v1uMedNnqwNP2LVmZ3NY4z5EuBQA5MU+JMMwsbzxbxREO1rX8jZDRo9/SKZ1+ KpGT0COHDQhFbpCeYTZ3qlNtX0MHDzkNNeGVHLHxbYOH+UzdmSQwDwC+ky0lUyDhBjw9 WhfoulMw91gUl39Xa/9d4s251E6C3kevNnfWcB1xyuGNtNuAISTrcxmtLk+APUdQ+pxF joZ7TySxZ1mxMpzqQvEWg1P/4xB/bpFox7kYmNW8ycquUdubZz7S+hnZQhEykqb2ap5A 0s5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M0c83yt8DuUJ8so7neCORgW723l3VAUAqtDAMPeYyBw=; b=G9t34uyf0XHIkPLB91OjzeFbq+AN9QIBQGavqscneCq2msHxiLDBR/9lL+YIYo9PQA yh3GFvyUee6VkEdXDGjeL1V01fWMy6UvtklUDfyVpMeop5Klm3CvnvicywvHqvJsmomS 9N1eHr3PU3Ha1GyGqNC0Y5F4H+N/n0poiEeJ1eDAtqct6elknwS8AlkFDeg6rTeBG0lD vRvWE0BGaxj4J3+c/HcVQ4TLp612b7iq/bgiQMizxcxTraIp9UIa3QzO1O73mY8kYK7y M5IC7JZFSHjqsqf2PkLdBdC78bqfcGFLOj3O6vhhT5QdLY0IuoLLEnMX1arfuVNxnvbw ASnA== X-Gm-Message-State: AOAM531Os9wlrta6yePs0yxh33dn5CaHUzSAuE164bfkrDD5tmkpKX9S E68asK8m/0RtZiM6blU3rLUBz3zO1L87Smk3oYPI2rmt7UDxooTDWogUldKVdbdFWki1CCfNZgi Zh4Ei6sILEVM= X-Google-Smtp-Source: ABdhPJyQiRYHJ0EXRXEmNx1rTmK32ENiLJ5i452xMQAqNDvdjxHzHpiapnnpVHyS1GKJxd9g8DOQma+AiyoyV8g/Nio= X-Received: by 2002:a2e:b8c2:: with SMTP id s2mr18830609ljp.368.1593120696496; Thu, 25 Jun 2020 14:31:36 -0700 (PDT) MIME-Version: 1.0 References: <6663.1592585417@localhost> In-Reply-To: <6663.1592585417@localhost> From: Brian Campbell Date: Thu, 25 Jun 2020 15:31:10 -0600 Message-ID: To: Michael Richardson Cc: HTTP Working Group , tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000330abc05a8ef51af" Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 21:31:41 -0000 --000000000000330abc05a8ef51af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My aim with something-something- certificate is/was to address a narrow but existing need by documenting current practice while introducing enough commonality to the header name and its content/encoding so as to facilitate relatively simple interoperability between independently developed systems. I see where you are going with this boiling of a small lake but it's well beyond the scope of the kind of solution I'd envisioned or think would be practically deployed and useful in any meaningful numbers. On Fri, Jun 19, 2020 at 10:50 AM Michael Richardson wrote: > > Brian, > {I have been on the httpbis list, but I'm not right now, and I know that > w3 and IETF do not share their whitelists, so this might not work} > > I was thinking about something-something-certificate yesterday while > cleaning/swimming > my pool. (A long thankless task, as the pool is not heated, we've been > getting very a-seasonal *snow*, and nobody in my family but me will swim > in it > until it's "perfect". Also we have many many trees, which we won't cut > down. > You can see how my mind might wander) > > [This discussion would be better done with beer and napkins.] > > So I am thinking that we need to create a "digital twin" in the back-end > server for the front-end TLS state machine. It needs to reflect the > current > state at a level of detail appropriate for the application. > > Thus, a single header isn't enough, although there could be some > degeneration > that results in a single header. We need a few variables to update. > > I think we have a choice between: > > 1) sending the state (possibly a few kb) on every transaction, which keep= s > the protocol stateless. We could explore ways to encode it: CDDL+CBOR > seems like a good thing. TLS structures are another obvious choice, b= ut > that's a detail. > > 2) assuming that state will be maintained by both ends, and simply updati= ng > the state appropriately. When it comes to this, I think of the > HTTP PATCH methods, but I'm not sure I mean this literally. > > It's the model of having a few objects per-connection that the TLS > front-end > might update on the backend, and making the management of the TLS > connections explicit. > > Alternately, the TLS front-end could maintain a RESTful interface on a > per-connection basis that the back-end could interrogate. The header > would just provide the right reference to that. The RESTful interface > could even be pushed/updated into some other CPU on the TLS terminator. > > This is cleaner, but this has read-latency round trip issues, while pushi= ng > the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot > more > pipelined. Or MQTT :-) > > To this, I think we'd have to look at the RFC8446 Appendix A.2 state > machine > and figure out how to express this. I don't really see re-auth in that > diagram. Maybe I'm overthinking here, but given the opportunities in TLS > 1.2 and 1.3 for newer states, and the review from TLS experts on the > header, > this might be cleaner and less of a hack to get the additional things in. > > This data model mechanism also better accomodates the split between those > who > need the entire certificate chain (w/ and w/o trust anchor used), and tho= se > that just care about the EE involved. > > --- > > I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend > connection looks like. I haven't entered such a world personally. > > TLS front-end systems *are* collecting/storing state on a per-client > connection basis, whether the transport is QUIC or not. I don't think it > scales well to try to spread that state across load balancers, you want t= o > split the traffic before the TLS terminators in order to horizontally sca= le > them. > > A thought that I have is that with a move to HTTP/3, that the need for > something-something-certificate declines. > A model that I could see in such a situation is that since the bulk of th= e > transport is via QUIC, it could be that it makes less sense to have TLS > hardware terminators; by careful use of port numbers to demux upon, and/o= r > IPv6 addresses, it might be easier to load balance directly to applicatio= n > servers, and just horizontally scale them wider. > > The hardware TLS offload box then is only important for adapting HTTP 1 > and HTTP/2 connections to HTTP/3. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000330abc05a8ef51af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    My aim with something-something-certificate is/was to address a narrow but existing need by docum= enting current practice while introducing enough commonality to the header = name and its content/encoding so as to facilitate relatively simple interop= erability between independently developed systems. I see where you are goin= g with this boiling of a small lake but it's well beyond the scope of t= he kind of solution I'd envisioned or think would be practically deploy= ed and useful in any meaningful numbers.=C2=A0 =C2=A0

    On Fri, Jun 19, 2= 020 at 10:50 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

    Brian,
    {I have been on the httpbis list, but I'm not right now, and I know tha= t
    w3 and IETF do not share their whitelists, so this might not work}

    I was thinking about something-something-certificate yesterday while cleani= ng/swimming
    my pool.=C2=A0 (A long thankless task, as the pool is not heated, we've= been
    getting very a-seasonal *snow*, and nobody in my family but me will swim in= it
    until it's "perfect".=C2=A0 Also we have many many trees, whi= ch we won't cut down.
    You can see how my mind might wander)

    [This discussion would be better done with beer and napkins.]

    So I am thinking that we need to create a "digital twin" in the b= ack-end
    server for the front-end TLS state machine.=C2=A0 It needs to reflect the c= urrent
    state at a level of detail appropriate for the application.

    Thus, a single header isn't enough, although there could be some degene= ration
    that results in a single header.=C2=A0 We need a few variables to update.
    I think we have a choice between:

    1) sending the state (possibly a few kb) on every transaction, which keeps<= br> =C2=A0 =C2=A0the protocol stateless.=C2=A0 We could explore ways to encode = it: CDDL+CBOR
    =C2=A0 =C2=A0seems like a good thing.=C2=A0 TLS structures are another obvi= ous choice, but
    =C2=A0 =C2=A0that's a detail.

    2) assuming that state will be maintained by both ends, and simply updating=
    =C2=A0 =C2=A0the state appropriately.=C2=A0 =C2=A0When it comes to this, I = think of the
    =C2=A0 =C2=A0HTTP PATCH methods, but I'm not sure I mean this literally= .

    It's the model of having a few objects per-connection that the TLS fron= t-end
    might update on the backend, and making the management of the TLS connectio= ns explicit.

    Alternately, the TLS front-end could maintain a RESTful interface on a
    per-connection basis that the back-end could interrogate.=C2=A0 The header<= br> would just provide the right reference to that.=C2=A0 The RESTful interface=
    could even be pushed/updated into some other CPU on the TLS terminator.

    This is cleaner, but this has read-latency round trip issues, while pushing=
    the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot mor= e
    pipelined.=C2=A0 Or MQTT :-)

    To this, I think we'd have to look at the RFC8446 Appendix A.2 state ma= chine
    and figure out how to express this.=C2=A0 =C2=A0I don't really see re-a= uth in that
    diagram.=C2=A0 Maybe I'm overthinking here, but given the opportunities= in TLS
    1.2 and 1.3 for newer states, and the review from TLS experts on the header= ,
    this might be cleaner and less of a hack to get the additional things in.
    This data model mechanism also better accomodates the split between those w= ho
    need the entire certificate chain (w/ and w/o trust anchor used), and those=
    that just care about the EE involved.

    ---

    I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend connection looks like.=C2=A0 I haven't entered such a world personally.=

    TLS front-end systems *are* collecting/storing state on a per-client
    connection basis, whether the transport is QUIC or not.=C2=A0 I don't t= hink it
    scales well to try to spread that state across load balancers, you want to<= br> split the traffic before the TLS terminators in order to horizontally scale=
    them.

    A thought that I have is that with a move to HTTP/3, that the need for
    something-something-certificate declines.
    A model that I could see in such a situation is that since the bulk of the<= br> transport is via QUIC, it could be that it makes less sense to have TLS
    hardware terminators; by careful use of port numbers to demux upon, and/or<= br> IPv6 addresses, it might be easier to load balance directly to application<= br> servers, and just horizontally scale them wider.

    The hardware TLS offload box then is only important for adapting HTTP 1
    and HTTP/2 connections to HTTP/3.

    --
    ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
    ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
    ]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [






    --
    Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
    =C2=A0-=3D IPv6 IoT consulting =3D-




    <= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000330abc05a8ef51af-- From nobody Thu Jun 25 14:55:51 2020 Return-Path: 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 44CEB3A103A for ; Thu, 25 Jun 2020 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SorW2io3r-Jp for ; Thu, 25 Jun 2020 14:55:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAE03A1039 for ; Thu, 25 Jun 2020 14:55:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 02438389A0; Thu, 25 Jun 2020 17:53:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hrz4bAtosjK9; Thu, 25 Jun 2020 17:53:02 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E96B3899D; Thu, 25 Jun 2020 17:53:02 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BDF485DE; Thu, 25 Jun 2020 17:55:44 -0400 (EDT) From: Michael Richardson To: Brian Campbell cc: HTTP Working Group , tls@ietf.org In-Reply-To: References: <6663.1592585417@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 21:55:50 -0000 --=-=-= Content-Type: text/plain Brian Campbell wrote: > My aim with something-something- > > certificate > > is/was to address a narrow but existing need by documenting current > practice while introducing enough commonality to the header name and its > content/encoding so as to facilitate relatively simple interoperability > between independently developed systems. I see where you are going with > this boiling of a small lake but it's well beyond the scope of the kind of > solution I'd envisioned or think would be practically deployed and useful > in any meaningful numbers. I agree with you. I think it's useful to think about what the next step of complexity would be in order to understand the ROI for this simiplicity. I think that a key line is figuring out how/if the certificate chain will be provided with the simplest design. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl71HWAACgkQgItw+93Q 3WUwNwgAtFat1YOyduKMmpFnfZRLwhOp0t5h70QRMDRLwEOMlDXAFXP7d/aLyxLE A5Xqf77oIAzUQQx5Ko7eEfdz3VwtpGlTpSuQPOzt4S9ymAleGUj2hIrZsM37K6KJ SaupE/WG+Ct1lvC1zCM7HzEFMtHSSGkwgf8/XTscbcVhfxaQN6KbNmC6gtyNfrA1 8UXFnIJsFBVSvVZ9UgKlNddLanbBpQiivFTpM1lrWgqyA0cOtykOZ+f8vsfHVqUM qg2tyUI2Xpu1HBTYd6TRNVhdVVj3eMo5HzrWTFyDaQg6FQWbPt43Dq0/LJWnQ67+ UyFHFLL2qka56Hn0Ckk0Y51NR9qj5g== =RhVw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 16:29:44 2020 Return-Path: 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 7ABEB3A104A for ; Thu, 25 Jun 2020 16:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 7G-jQ8c0EIF8 for ; Thu, 25 Jun 2020 16:29:41 -0700 (PDT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7493A0C28 for ; Thu, 25 Jun 2020 16:29:40 -0700 (PDT) Received: by mail-wr1-f49.google.com with SMTP id j94so7679339wrj.0 for ; Thu, 25 Jun 2020 16:29:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G/ei7ok1javvv0vzZRneivS4oF3zGOmAdQS+eaRkFeU=; b=iDW6S8CNG3BX9hBh9YY9Tj6sc6Gi2G5WqscGoEVQnO1YbMu+ZzsQoQrs3+7ktvw8DG 11dg/Gel6vm5JsuAUOqt13tx3NIA1Fn7DjDdEWDr1hlHLFUQ1GTXAzUvLpnRbLiqPnah xT3jNj++cmnIDHTIV/LwISJ6+xGgPqupolPVmeene/KgVwXFNWRnHWTs1TtPDkPQ1lFS xrWrNSvPg6P8wI+dAZqFbD/YZsWKgbuHy21poeNlkcNC2F+wVwY4gIr8sebDa6Y7bwAd JbTJE+zglYZDtWwCzix+jd8mqwal1mNWVh3XlChLRJxI/N+ojVOx0nEr/jQqD34pPjcg AxLQ== X-Gm-Message-State: AOAM5307guwMAHr3IotVa7hJgNvf8pJ45dB2wdvAwTeZ10MolxckU5+d 9qU3Q3YPXLnZB1jqiq33nRzR9+s9OsWH0XaxQ0I= X-Google-Smtp-Source: ABdhPJxdbD68V9QeL9McdTmGT+emLjri72Cxzr/V6dJeFcMuAfNA69Za+u9OoCIrcYrIL2VsUNaUYUpzSocqi/LQnXA= X-Received: by 2002:a5d:4bd2:: with SMTP id l18mr599867wrt.119.1593127779116; Thu, 25 Jun 2020 16:29:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Nygren Date: Thu, 25 Jun 2020 19:29:27 -0400 Message-ID: To: Yiannis Yiakoumis Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005b2c0405a8f0f7fe" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 23:29:43 -0000 --0000000000005b2c0405a8f0f7fe Content-Type: text/plain; charset="UTF-8" One quick comment is that binding tokens to IP addresses is strongly counter-recommended. It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments. (Even in IPv6-only, privacy addressing causes problems here.) Even if you have a way to convert tokens over for your set of IP addresses (eg, to deal with dual-stack) that still may not help enough with NAT environments. Erik On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis < yiannis@selfienetworks.com> wrote: > Hi all, > > I wanted to briefly introduce network tokens > into this list, how they relate with TLS and ESNI, and kindly ask anyone > that is interested to share feedback and join the discussion. > > Network tokens is a method for endpoints to explicitly and securely > coordinate with networks about how their traffic is treated. They are > inserted by endpoints in existing protocols, interpreted by trusted > networks, and may be signed or encrypted to meet security and privacy > requirements. Network tokens provide a means for network operators to > expose datapath services (such as a zero-rating service, a user-driven QoS > service, or a firewall whitelist), and for end users and application > providers to access such services. Network tokens are inspired and derived > by existing security tokens (like JWT and CWT), borrowing several of their > security and privacy properties, and adjusting them for use in a networking > context. > > There are two ways that network tokens relate with TLS: > > 1. They can support ESNI adoption: in a world where ESNI is widely > adopted, network tokens can enable use cases where endpoint-network > coordination is required, without having to go back to plaintext SNI that > everyone can read. > 2. Network tokens are embedded as TLS handshake extensions (among > others). > > We are shooting for a BoF in November, and are very much interested into > feedback around the concept, use cases, what we need to do to make network > tokens adopted as a TLS handshake extension, and folks that are interested > to get involved in the effort! > > Links to an IETF I-D, a mailing list, and initial implementation are > available at https://networktokens.org . > > Best, > Yiannis > > ===================== > Yiannis Yiakoumis > Co-Founder & CEO > https://selfienetworks.com | +1-650-644-7857 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005b2c0405a8f0f7fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    One quick comment is that binding tokens to IP addresses is stro= ngly counter-recommended.
    It doesn't survive NATs or proxies, mobility, = and it is especially problematic in IPv6+IPv4 dual-stack environments.
    (Even= in IPv6-only, privacy addressing causes problems here.)=C2=A0 Even if you = have a way to convert tokens over
    for your set of IP addresses (eg, to dea= l with dual-stack) that still may not help enough with NAT environments.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


    On Thu, Jun 25, 2020= at 4:29 PM Yiannis Yiakoumis <yiannis@selfienetworks.com> wrote:
    3D""
    Hi all,

    I wanted = to briefly introduce=C2=A0network tokens into this list, how they relate with TLS and ESNI= , and kindly ask anyone that is interested to share feedback and join the d= iscussion.

    Network tokens is a method for end= points to explicitly and securely coordinate with networks about how their = traffic is treated. They are inserted by endpoints in existing protocols, i= nterpreted by trusted networks, and may be signed or encrypted to meet secu= rity and privacy requirements. Network tokens provide a means for network o= perators to expose datapath services (such as a zero-rating service, a user= -driven QoS service, or a firewall whitelist), and for end users and applic= ation providers to access such services. Network tokens are inspired and de= rived by existing security tokens (like JWT and CWT), borrowing several of = their security and privacy properties, and adjusting them for use in a netw= orking context.

    There are two ways that= network tokens relate with TLS:
    1. They can support ESNI ado= ption: in a world where ESNI is widely adopted, network tokens can enable u= se cases where endpoint-network coordination is required, without having to= go back to plaintext SNI that everyone can read.=C2=A0
    2. Network= tokens are embedded as TLS handshake extensions (among others).=C2=A0
      <= /li>
    We are shooting for a BoF in November, and=C2=A0are very much= interested into feedback around the concept, use cases, what we need to do= to make network tokens adopted as a TLS handshake extension, and folks tha= t are interested to get involved in the effort!

    Links to an IETF I-D, a mailing list, and initial implementation are avai= lable at https://n= etworktokens.org=C2=A0 .=C2=A0

    Best,
    Yiannis

    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Yiannis Yiakoumis
    Co-Founder & CEO
    <= a href=3D"https://selfienetworks.com" rel=3D"noopener noreferrer" target=3D= "_blank">https://selfienetworks.com | +1-650-644-7857
    =

    ___________________________________= ____________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls
    --0000000000005b2c0405a8f0f7fe-- From nobody Thu Jun 25 16:42:26 2020 Return-Path: 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 CDE9D3A107D for ; Thu, 25 Jun 2020 16:42:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=cryptonector.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 2bgzK0yNUC5y for ; Thu, 25 Jun 2020 16:42:22 -0700 (PDT) Received: from bonobo.elm.relay.mailchannels.net (bonobo.elm.relay.mailchannels.net [23.83.212.22]) (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 5B3A33A107B for ; Thu, 25 Jun 2020 16:42:22 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D86CE32027C; Thu, 25 Jun 2020 23:42:20 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-22-8.trex.outbound.svc.cluster.local [100.96.22.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5AB10320559; Thu, 25 Jun 2020 23:42:20 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Thu, 25 Jun 2020 23:42:20 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arch-Trouble: 30982dc8227dfdf7_1593128540657_179017828 X-MC-Loop-Signature: 1593128540657:3574415852 X-MC-Ingress-Time: 1593128540657 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 1A12883CFE; Thu, 25 Jun 2020 16:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=F6lC3jlwbYO5l/ O+6mTsgMxqeI8=; b=s6DoRLJObi15B+xzWLxN2pzsQizWG6xzoMUc0EhAFE6rBj qDQQ/JWg/IU44lHv0CkU391vgm17v9PjQ/yCvmSRmms0ZC8HMmUNmXSrBdjIU7Jq CSuEyNvlYHC/EXQWQOxaQHd5jV8IcIq5zjD6OCWm9Guz2frFjwpVU28KEE9vc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 4E9A683D0C; Thu, 25 Jun 2020 16:42:17 -0700 (PDT) Date: Thu, 25 Jun 2020 18:42:14 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Michael Richardson Cc: Brian Campbell , ietf-http-wg@w3.org, tls@ietf.org Message-ID: <20200625234212.GV3100@localhost> References: <6663.1592585417@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6663.1592585417@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeltddgvdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 23:42:24 -0000 BTW, thanks for the something-something-certificate work. Looking at the I-D, draft-bdc-something-something-certificate-04, I see there's no way to send the certificate chain on. I understand the motivation (compression), but it really would be best to send on the full chain sent by the client. More on this below: On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote: > Thus, a single header isn't enough, although there could be some degeneration > that results in a single header. We need a few variables to update. > > I think we have a choice between: HTTP/2 and, I imagine, /3, does header compression of the right sort here. If the backend is HTTP/1, then... that sucks, but maybe this is a good way to encourage migration to /2 or /3. That said, I think we can compress in the /1 case by first sending the certificate (and chain, please) and in subsequent requests in the same connection sending only a hash of the certificate. This would force a /1 backend to keep the kind of state that a /2 backend would for header compression. > 1) sending the state (possibly a few kb) on every transaction, which keeps > the protocol stateless. We could explore ways to encode it: CDDL+CBOR > seems like a good thing. TLS structures are another obvious choice, but > that's a detail. There's no need. HTTP/2 already does header compression. > 2) assuming that state will be maintained by both ends, and simply updating > the state appropriately. When it comes to this, I think of the > HTTP PATCH methods, but I'm not sure I mean this literally. Can TLS let a client authenticate multiple times? > Alternately, the TLS front-end could maintain a RESTful interface on a > per-connection basis that the back-end could interrogate. The header > would just provide the right reference to that. The RESTful interface > could even be pushed/updated into some other CPU on the TLS terminator. Yes, this would also work. In this case Client-Cert: would carry just a URI. This is nice because the backend can validate that the origin of that URL is one it trusts. Nico -- From nobody Thu Jun 25 22:34:20 2020 Return-Path: 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 8F7903A1154 for ; Thu, 25 Jun 2020 22:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=selfienetworks-com.20150623.gappssmtp.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 GtMG5G6zNeyd for ; Thu, 25 Jun 2020 22:34:15 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766C23A1153 for ; Thu, 25 Jun 2020 22:34:15 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id k7so3510442vso.2 for ; Thu, 25 Jun 2020 22:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:cc:from:in-reply-to:references:date:message-id:subject :to; bh=ELdOpZDBEsR1d15Luyj8SMpFyxnQzDnzOZqfQmtAoRM=; b=gOgEYKqzt2quhcbQ4ZKH82AQ0msIquH4h2A+DLPxpJFNE9JedMnVF7lNfDTGUhDvIt kgP571CapuknrHD5obpTDU5EI0I6mQUDl2r0+kh9VK2TdlaFAZ5pYt70crMS7bdGc3pT eaIMw2jXtbTE2H+gVYho6IjNVm96kbQmKl33z2a0RWavzoXtuDoiYJaiEAsYx//9F+Pf gq8hRIXqmRypFVrNRkvMg+M+H9A7JSogqIa6jiloWNwT9ZYU2WPVZ69oCjpxJ3yu9FUM BgTzFNgKxTbgzSJOG/33MVifbNJUjuppf8cHYSvHoSyaSsRbV7idq9/P41/ETzoTtHyG 9lXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:cc:from:in-reply-to:references:date :message-id:subject:to; bh=ELdOpZDBEsR1d15Luyj8SMpFyxnQzDnzOZqfQmtAoRM=; b=T42mvTowZHpI84IsY08YISMuYyTjwwvinNG2yW1DN81HvukNNZ4hr880s8zcK2zjie KV4teky3XgzO25oWGBwnKEX8AVacAgGEy9JIZN+ungn+zWUNdGt4V4lE57sNJCfaUVpO I5Zvq00NfqD9kpoLRk+oQeeU770aWwiXQNR66e1tPwi0XsGSXwkxPEw5obTWcu2kaDC6 dSTMy3iRjSuwpQ16NMv8hVidVdGR0P0vM06tBOUEKUso0XE0AcdORH/kjRYwgVod94R1 2SdHI/3ThYGqCfPr1CXud/+J3KY2R9BfSNyjyealMl9zT09itt/iDw235r0pA1rSWuHa bLHQ== X-Gm-Message-State: AOAM5308GmtnSZdTFx7KC4fPB2UVYE/r67QlqlbIjWzZjrZZsJisGlnU h5rMCfAPXVvxHnb7c/ddOE9XhU5iqAw= X-Google-Smtp-Source: ABdhPJynIBnQWMlFX/qdU4HyaoMxkH0A4MsrmBvuwVB3RQR8T6KQa8Afz/d0aGKRDsr3Jlbl/FJVGQ== X-Received: by 2002:a67:fc08:: with SMTP id o8mr1257906vsq.188.1593149654103; Thu, 25 Jun 2020 22:34:14 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id r139sm4022508vkr.20.2020.06.25.22.34.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 22:34:13 -0700 (PDT) Mime-Version: 1.0 Cc: "TLS@ietf.org" , network-tokens@ietf.org X-Superhuman-ID: kbvs5nf6.14a30a07-6e4d-49f3-98ca-1987f2ab8cad From: "Yiannis Yiakoumis" In-Reply-To: References: Date: Fri, 26 Jun 2020 05:34:12 +0000 Message-ID: To: "Erik Nygren" X-Mailer: Superhuman Desktop (2020-06-25T22:05:59Z) X-Superhuman-Draft-ID: draft00ec3fbbfa9578c5 Content-Type: multipart/alternative; boundary=697ccd776629fa39d1abd5761e4417a7ed64bb3b68c0e618b62b017daf11 Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 05:34:18 -0000 --697ccd776629fa39d1abd5761e4417a7ed64bb3b68c0e618b62b017daf11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 (cross-posting to network-tokens@ as this is the first related topic - apol= ogies for any duplicates) Hi Erik, Thanks for the comments. That's a good point, and wanted to clarify the rea= soning around binding fields in general, as well as=C2=A0 binding tokens to= IP addresses specifically. Unlike access and security tokens, network tokens are not protected by a se= cure TLS connection and can be read by any intermediary node. Therefore, th= ey are open to replay attacks, and unless=C2=A0 used in a fully trusted env= ironment, one should take measures against such attacks. There are two main= approaches here: * Limit a token's lifetime, to make replay attacks hard. The extreme here i= s to make tokens single use (e.g., through a nonce), and reject tokens with= previously seen nonces (within a time window). * Bind the token to a field that limits the scope it can be used (e.g., a u= ser, a device, a set of exit gateways, etc). The network should be able to = separately verify that the token is used within this scope. A binding field= can be in an IP address, an IMSI, or any other field the network operator = may use to limit the scope of a token. Note that the binding value matters only at the point of enforcement ( the = place where the network checks the scope). It doesn't play any role on the = client, the server, or other network nodes.=C2=A0 Moreover, when tokens are= encrypted, the binding field itself is not visible to anyone other than th= e network that issued the token, which should cover privacy concerns. Two use cases where binding tokens to IP addresses should be fine are i) wh= en users (a home or a mobile subscriber) are assigned a static IP address (= or a DHCP lease that lasts beyond a token's expiration time), and ii) for = public IP addresses.=C2=A0Consider the following scenario: home device =E2=86=92 home NAT =E2=86=92 operator network (static IP addres= ses) =E2=86=92 operator NAT =E2=86=92 Internet . Despite multiple NATs, the operator can bind the token to the IP address it= assigns to the modem and not worry about the downstream and upstream NAT. As you mentioned, there will be cases where IP binding won't work, either b= ecause the endpoint that gets the token doesn't have an assigned IP address= , because the enforcement point is behind a NAT, or because of heavy use of= proxies etc. In such cases one could bind tokens to a different field, or = use short-lived tokens and/or nonces to prevent replay attacks. The overall= benefit of binding tokens to certain fields is that they can have a longer= lifetime and require less state in the network. Does this address your concern? Also, any ideas/references on how common it= is to have static/long-leased IP addresses in different scenarios (e.g., r= esidential networks and mobile networks)? Thanks, Yiannis On Thu, Jun 25, 2020 at 4:29 PM, Erik Nygren < erik+ietf@nygren.org > wrote= : >=20 > One quick comment is that binding tokens to IP addresses is strongly > counter-recommended. >=20 > It doesn't survive NATs or proxies, mobility, and it is especially > problematic in IPv6+IPv4 dual-stack environments. >=20 > (Even in IPv6-only, privacy addressing causes problems here.)=C2=A0 Even = if you > have a way to convert tokens over >=20 > for your set of IP addresses (eg, to deal with dual-stack) that still may > not help enough with NAT environments. >=20 >=20 >=20 > Erik >=20 >=20 >=20 >=20 > On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis < yiannis@ selfienetwor= ks. > com ( yiannis@selfienetworks.com ) > wrote: >=20 >=20 >> Hi all, >>=20 >>=20 >>=20 >> I wanted to briefly introduce network tokens ( https://networktokens.org= ) >> into this list, how they relate with TLS and ESNI, and kindly ask anyone >> that is interested to share feedback and join the discussion. >>=20 >>=20 >>=20 >> Network tokens is a method for endpoints to explicitly and securely >> coordinate with networks about how their traffic is treated. They are >> inserted by endpoints in existing protocols, interpreted by trusted >> networks, and may be signed or encrypted to meet security and privacy >> requirements. Network tokens provide a means for network operators to >> expose datapath services (such as a zero-rating service, a user-driven Q= oS >> service, or a firewall whitelist), and for end users and application >> providers to access such services. Network tokens are inspired and deriv= ed >> by existing security tokens (like JWT and CWT), borrowing several of the= ir >> security and privacy properties, and adjusting them for use in a >> networking context. >>=20 >>=20 >>=20 >> There are two ways that network tokens relate with TLS: >>=20 >> * They can support ESNI adoption: in a world where ESNI is widely adopte= d, >> network tokens can enable use cases where endpoint-network coordination = is >> required, without having to go back to plaintext SNI that everyone can >> read. >>=20 >> * Network tokens are embedded as TLS handshake extensions (among others)= . >>=20 >> We are shooting for a BoF in November, and=C2=A0are very much interested= into >> feedback around the concept, use cases, what we need to do to make netwo= rk >> tokens adopted as a TLS handshake extension, and folks that are interest= ed >> to get involved in the effort! >>=20 >>=20 >>=20 >> Links to an IETF I-D, a mailing list, and initial implementation are >> available at https:/ / networktokens. org ( https://networktokens.org/ )= . >>=20 >>=20 >>=20 >> Best, >>=20 >> Yiannis >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Yiannis Yiakoumis >> Co-Founder & CEO >>=20 >> https:/ / selfienetworks. com ( https://selfienetworks.com ) | >> +1-650-644-7857 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ ietf. org ( TLS@ietf.org ) >> https:/ / www. ietf. org/ mailman/ listinfo/ tls ( >> https://www.ietf.org/mailman/listinfo/tls ) >=20 >=20 > --697ccd776629fa39d1abd5761e4417a7ed64bb3b68c0e618b62b017daf11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
    3D"
    (cross-posting to network-tokens@ as this is the f= irst related topic - apologies for any duplicates)

    Hi Erik,

    =
    Thanks for the comments. That's a good point, and wante= d to clarify the reasoning around binding fields in general, as well as=C2= =A0 binding tokens to IP addresses specifically.=C2=A0

    Unlike access and security tokens, network= tokens are not protected by a secure TLS connection and can be read by any= intermediary node. Therefore, they are open to replay attacks, and unless= =C2=A0 used in a fully trusted environment, one should take measures agains= t such attacks. There are two main approaches here:
    1. Limit a token's lifetime, to make replay attacks hard.= The extreme here is to make tokens single use (e.g., through a nonce), and= reject tokens with previously seen nonces (within a time window).=C2=A0
    2. Bind the token to a field that limits the scope it ca= n be used (e.g., a user, a device, a set of exit gateways, etc). The networ= k should be able to separately verify that the token is used within this sc= ope. A binding field can be in an IP address, an IMSI, or any other field t= he network operator may use to limit the scope of a token.=C2=A0
      3. <= /ol>
      Note that the binding value matters only at the point o= f enforcement ( the place where the network checks the scope). It doesn'= ;t play any role on the client, the server, or other network nodes.=C2=A0 M= oreover, when tokens are encrypted, the binding field itself is not visible= to anyone other than the network that issued the token, which should cover= privacy concerns.=C2=A0

      Two use cases where binding tokens to IP addresses should be fine are= i) when users (a home or a mobile subscriber) are assigned a static IP add= ress ( or a DHCP lease that lasts beyond a token's expiration time), an= d ii) for public IP addresses.=C2=A0Consider the following scenario:=C2=A0= =C2=A0

      home device =E2= =86=92 home NAT =E2=86=92 operator network (static IP addresses) =E2=86=92 = operator NAT =E2=86=92 Internet .=C2=A0

      Despite multiple NATs, the operator can bind the token to= the IP address it assigns to the modem and not worry about the downstream = and upstream NAT.=C2=A0

      As you mentioned, there will be cases where IP binding won't work, ei= ther because the endpoint that gets the token doesn't have an assigned = IP address, because the enforcement point is behind a NAT, or because of he= avy use of proxies etc. In such cases one could bind tokens to a different = field, or use short-lived tokens and/or nonces to prevent replay attacks. T= he overall benefit of binding tokens to certain fields is that they can hav= e a longer lifetime and require less state in the network.

      Does this address your concern? Also,= any ideas/references on how common it is to have static/long-leased IP add= resses in different scenarios (e.g., residential networks and mobile networ= ks)?=C2=A0

      = Thanks,
      Yiannis

    = On Thu, Jun 25, 2020 at 4:29 PM, Erik Nygren &= lt;erik+ietf@nygr= en.org> wrote:
    One quick comment is that binding tokens to IP addresses= is strongly counter-recommended.
    It doesn't survive NATs or proxie= s, mobility, and it is especially problematic in IPv6+IPv4 dual-stack envir= onments.
    (Even in IPv6-only, privacy addressing causes problems here.)= =C2=A0 Even if you have a way to convert tokens over
    for your set of = IP addresses (eg, to deal with dual-stack) that still may not help enough w= ith NAT environments.

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


    On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis <yiannis@selfienetworks.com> wrote:
    Hi all,

    I wanted to briefly introduce=C2=A0network tokens into this list, how they relate with TLS and ESNI, a= nd kindly ask anyone that is interested to share feedback and join the disc= ussion.

    Ne= twork tokens is a method for endpoints to explicitly and securely coordinat= e with networks about how their traffic is treated. They are inserted by en= dpoints in existing protocols, interpreted by trusted networks, and may be = signed or encrypted to meet security and privacy requirements. Network toke= ns provide a means for network operators to expose datapath services (such = as a zero-rating service, a user-driven QoS service, or a firewall whitelis= t), and for end users and application providers to access such services. Ne= twork tokens are inspired and derived by existing security tokens (like JWT= and CWT), borrowing several of their security and privacy properties, and = adjusting them for use in a networking context.

    There are two ways that network tokens rel= ate with TLS:
    1. They can support ESNI= adoption: in a world where ESNI is widely adopted, network tokens can enab= le use cases where endpoint-network coordination is required, without havin= g to go back to plaintext SNI that everyone can read.=C2=A0
    2. Network tokens are embedded as TLS handshake extensions (among oth= ers).=C2=A0
    We are shooting for a BoF in Nove= mber, and=C2=A0are very much interested into feedback around the concept, u= se cases, what we need to do to make network tokens adopted as a TLS handsh= ake extension, and folks that are interested to get involved in the effort!=

    Links to an IETF I-D,= a mailing list, and initial implementation are available at http= s://networktokens.org=C2=A0 .=C2=A0

    Best,
    Yiannis=

    =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    Yiannis Yiakoumis
    Co-Founder & CEO
    https://selfienetworks.com | +1-650= -644-7857

    __= _____________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls

--697ccd776629fa39d1abd5761e4417a7ed64bb3b68c0e618b62b017daf11-- From nobody Thu Jun 25 23:11:30 2020 Return-Path: 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 46DD63A1144 for ; Thu, 25 Jun 2020 23:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.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 a717FvPsAE3w for ; Thu, 25 Jun 2020 23:11:26 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B473A0121 for ; Thu, 25 Jun 2020 23:11:26 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id u185so2177643pfu.1 for ; Thu, 25 Jun 2020 23:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=Vb2cJ8hpg29nRU2kc1SQX1Rbrnc1foIbjZ0bxPS20L4=; b=B/86FJu+XgYPDH3IpXxKl+x794dy19s8mFB2spBP31ET9bf8kA7OtYwSufLUkqwlX7 XOAowqWNyrXmWU3sl2ClQh07jYAqHQjIcUaolSqUF3GMC44J3P/g2WMqOmYbYoXk03Ks 3v/CVEHaXPLcoar5SFwaK5tmBmI8ZRf2YdYwitnFP0OT5NIeJxYdwyB2aTq3cb+H+IcS 9M2VBg33P31aoOiZtdrladp5/DWFKqyMoHpMAL7JOmE+vu/zAxaHO5MEqdPG5oNTAxIE GEfD4YV6P1oADAdNEwBtIFvjDLYdq80+zlJMNjaxM2CGSbFFNNXI2Z26UA7MJlpZ780L YtOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=Vb2cJ8hpg29nRU2kc1SQX1Rbrnc1foIbjZ0bxPS20L4=; b=H0WO8Pq9/0gr08BXwt1jyQ2IdvTmwnIcY0tU/P2lhwk45c5UlodNibSexdmNYblq0+ QAzYRkKLYCjfJa4kd9ZDrd8kvc7M8GYVoV8ElSqchJ6HPh0pIqpCgMwFfxtBzJlOd6uh Z7s42W0e/hzNHzFoDQnBQBkV0Y5vCMuZjbAf136PkoEIYVrlzegTVFxlfthVstFREeIJ 2nAb2vHxTIddM9wZtPlQhlBr1a4QNXOUoc+pmSUP7PAsPRr0KKt8uyI3lf33759RwJkM V/4xthMqcNT0Eb0vO3uM7gDO9VLzuIhWYUhALGc2cVrf8VmVdJTcHvxn2aJSkaIW2NpQ XL+Q== X-Gm-Message-State: AOAM53270gmGG/V6JiKIUyMbEmllDVhgFabTQdmbPOGMv3tRARJoCElG Gghaxc90/0cgRZy7mPzITwbFlB4cmQ== X-Google-Smtp-Source: ABdhPJzpR383nrZB3rBFf5AeTT/cqhM5g3JsGQ0ev7MhEurADiOhhqu0pGGER63W5PKXAJg3p/ohyQ== X-Received: by 2002:a65:5a0f:: with SMTP id y15mr1350519pgs.6.1593151885207; Thu, 25 Jun 2020 23:11:25 -0700 (PDT) Received: from aspen.local (63-140-73-54-rb1.jnu.dsl.dynamic.acsalaska.net. [63.140.73.54]) by smtp.gmail.com with ESMTPSA id s23sm20521086pfs.157.2020.06.25.23.11.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 23:11:24 -0700 (PDT) To: tls@ietf.org References: From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> Date: Thu, 25 Jun 2020 22:11:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nUHavNkaxh1gRrxVJIlQYozIPKEP4Eyyc" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 06:11:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nUHavNkaxh1gRrxVJIlQYozIPKEP4Eyyc Content-Type: multipart/mixed; boundary="GY530UkzbvY7fRuJUiy0m7nzgdqbSCeXr" --GY530UkzbvY7fRuJUiy0m7nzgdqbSCeXr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/25/20 3:29 PM, Erik Nygren wrote: > One quick comment is that binding tokens to IP addresses is strongly > counter-recommended. > It doesn't survive NATs or proxies, mobility, and it is especially > problematic in IPv6+IPv4 dual-stack environments. There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection"). Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --GY530UkzbvY7fRuJUiy0m7nzgdqbSCeXr-- --nUHavNkaxh1gRrxVJIlQYozIPKEP4Eyyc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl71kYkACgkQ37iRcpp2 24/3VxAAwWfDkQ3zeXh5fJPArQmkMLf/HqCJJDljE47Ar+JNVqhlgqOOIjlPqcvw 0z4evFDnGESdvnoyRwKGW4Tk9pGRionV9wYLfPzczvBuAf6vPZIXe+YtZNBRoN/e vXmv0Fsjok8JTMj4mxRbCC2zQ2LWGm2dQBDlQVqc8Y6WH26ykKUPmizdU1nOKDRo Z1sXkUmJW3sJ2aeKAM0tKoINVA+u5rH4ySffSea5N+Vf480iCDV8gRcH1ivqc7dJ aWRhKABu6ZX7LpjFde6/i5cYGfti0EVIwDlDsFtzD2NZwETsTqqBG/+ntnXmjBly Aufr2RkXIA8u27aq3xF6Vz06kkP4uqZhaC4Q1LM7rveTVlMRGWdALebdVviWxlv4 ftUKni84rJhgsakwQjWURwdgjER5HJ5KKitff0EGYnQ09e/fqK2h4j6jLPdksC2w k3H6UYfQ9g2LDCoahYs986Bi8vpAZuNo5BeW1zM8kvcLQjxXpS6ib+4oPOpoU7JH XABImme9QfoB7TiFs6OyuMZsWm0zy1QL7HQqzlJbh50Op9mki8+vS+M0vdLIIdPP yD0Oma6k7dVxMohhgJbBTiNuymRLA2uWP1e191snwJWnueZ/lEyybMnWEdmyw66L k79lW0DKD9HEKQeEWPXHCNMGXKdQTiqe0ivSsyRM1k32RXSrEYY= =aw83 -----END PGP SIGNATURE----- --nUHavNkaxh1gRrxVJIlQYozIPKEP4Eyyc-- From nobody Fri Jun 26 07:30:28 2020 Return-Path: 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 535C63A03F3 for ; Fri, 26 Jun 2020 07:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fQRc0UR4K7-K for ; Fri, 26 Jun 2020 07:30:24 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 A64453A040F for ; Fri, 26 Jun 2020 07:30:24 -0700 (PDT) Received: from xse448.mail2web.com ([66.113.197.194] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jopMw-0011WI-AI for tls@ietf.org; Fri, 26 Jun 2020 16:30:22 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49tfRl2FRTz9m6 for ; Fri, 26 Jun 2020 07:30:11 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jopMp-000379-6M for tls@ietf.org; Fri, 26 Jun 2020 07:30:11 -0700 Received: (qmail 23722 invoked from network); 26 Jun 2020 14:30:11 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jun 2020 14:30:10 -0000 To: Melinda Shore , tls@ietf.org References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> Date: Fri, 26 Jun 2020 07:29:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rKgdl2dGY4fkXomXmV9AJ12H9ATKXOKUE" X-Originating-IP: 66.113.197.194 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVD46G4TYzZFwY VGJsUVc8QETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4aphbx4Ckv2LkcssKAxtcblgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efqTAas0edmB2q/yBRqnQY9Wo6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZHBhkQd7hzuzHZPvYWKxpxJznbr/iPR0U8WqNWDtD9jyQKkFr/2op3xdDB5v9zdhnH2 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LI+VSQJN/ZrCApq+UVRTKzF2jZAOanSBpz6Rja2u/0jLCoYGlDFqUCGkiW9JlgLvfS45r yi4J4ZFsGB+VEKPBnPysta6u1iHEyuS7GD1uvcqtGg2OYXXlB2xa18mpR0uPJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 14:30:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rKgdl2dGY4fkXomXmV9AJ12H9ATKXOKUE Content-Type: multipart/mixed; boundary="kyOSoRjk8LiGq2mvVEEaIpNsU3RpHb1dq"; protected-headers="v1" From: Christian Huitema To: Melinda Shore , tls@ietf.org Message-ID: <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> In-Reply-To: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> --kyOSoRjk8LiGq2mvVEEaIpNsU3RpHb1dq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 6/25/2020 11:11 PM, Melinda Shore wrote: > On 6/25/20 3:29 PM, Erik Nygren wrote: >> One quick comment is that binding tokens to IP addresses is strongly >> counter-recommended. >> It doesn't survive NATs or proxies, mobility, and it is especially >> problematic in IPv6+IPv4 dual-stack environments. > There's been a bunch of past work done developing similar sorts of > protocols, and for what it's worth I wrote up a mechanism for > using address tags and address rewrites, but unfortunately Cisco > decided to patent it. Anyway, there are ways of dealing with this > problem that don't require binding the address to the token ("all > technical problems can be solved by introducing a layer of > indirection"). There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways. Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN. There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version. -- Christian Huitema --kyOSoRjk8LiGq2mvVEEaIpNsU3RpHb1dq-- --rKgdl2dGY4fkXomXmV9AJ12H9ATKXOKUE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTDcbg3CLhASkABdRQQsCaooFi0lAUCXvYGZwAKCRAQsCaooFi0 lOYuAP4jskvuF/GNEH5dx/46L+kUNqCNs+vnrPe5gFD9WkFrfgD/dn4AyAoN5Ybn nIsn4BEmZv34u1T9+6bBLwc7hJ1FbQg= =WGOt -----END PGP SIGNATURE----- --rKgdl2dGY4fkXomXmV9AJ12H9ATKXOKUE-- From nobody Fri Jun 26 10:16:33 2020 Return-Path: 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 0A5CC3A09B3 for ; Fri, 26 Jun 2020 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=selfienetworks-com.20150623.gappssmtp.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 ALKHbasFnwjo for ; Fri, 26 Jun 2020 10:16:30 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00EB63A0977 for ; Fri, 26 Jun 2020 10:16:29 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id l24so3250873uar.10 for ; Fri, 26 Jun 2020 10:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:from:message-id:subject:to:cc:references :date; bh=7q2PivCoc4ZCIXMQnN4gaVu7Xi51O1PS89Xhvmjm9Nk=; b=PwhcZNKi1NW2ofu1BVrkbmYxuQONOTf3CmaqPPOd35WsAKSJ+RPUu1h9zFqrCOH6DT DoMX5mgOnTdUVxU+OlMr3fWHXT5AS+7HCUXCOxmisywoHkz4n/GCPgY1x7O8NTpPfRa0 OxCy/xO7gKrBr8DK63xoMKS5lGTmZGxSMMDoFSqgsGc7e7YT0LqAe2zdml87GiMAS/Hh M15CJJx6m6IApBLkeHpzygTvDRd8w6V+JN2iTP7wTzUPPGBxxmgdF30B4OUNLGlf8htg bqAKXwVtnCpuynvJd/1mvLGH2dHcWMCTQPp3YIwVpFAj3zoO8DOMxxOYGl4Qzf2j7Tv0 HGNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:from:message-id:subject :to:cc:references:date; bh=7q2PivCoc4ZCIXMQnN4gaVu7Xi51O1PS89Xhvmjm9Nk=; b=m9qBEx+80D1YiO3qhh4uNNCrzWd3+EZZ1w/qbvwaWSVXFaFYmFIomgD44+29XCMq+6 hw7eh8Id56aQPJnWwe3VVYgwlsvIjpe4g2sUTiR4cpzjmCimEznWV7P5nRqBybvPd/5V oIqdorV+/HWOmOf9zjtHMEBsl8XewUdtgtbHFFl9FsTP30yugq6GjDw3wcPZFVDLy6r0 FJ3xvrVfn0i2QACaQs2ibX1CQP3iW15/HUPULIKTxdL5iM/IoOgpB7wPlG2FOgltOnpm lJ5nb9b2Lm6t+dvvckrYH7Q+kDBl3qPq8CEakia2Kcch/xoSp9me93O0JcCaOh4aRNzJ wwgw== X-Gm-Message-State: AOAM531UTCsR0GeH0wlc9KFII9GWo6NsaRALL9BbkMEPL6Jov9zrV0zw da+zIUJcy8X33ecgcza1unzE8ATOeOo= X-Google-Smtp-Source: ABdhPJwQu1mzVJ24FPJX2zpZV/NC5DSo7IHL+tjOiLUFLKCd+ARO9ITVsMNrpm6Tt5tNN4LuNJHWIw== X-Received: by 2002:ab0:2695:: with SMTP id t21mr3020117uao.4.1593191788312; Fri, 26 Jun 2020 10:16:28 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id u22sm1666390vkb.19.2020.06.26.10.16.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jun 2020 10:16:28 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kbwh8pia.73cdffc6-52b8-4b57-87fa-a557c932d008 In-Reply-To: <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> From: "Yiannis Yiakoumis" Message-ID: To: "Christian Huitema" Cc: "Melinda Shore" , tls@ietf.org, network-tokens@ietf.org X-Mailer: Superhuman Desktop (2020-06-25T22:05:59Z) X-Superhuman-Draft-ID: draft00707e25cb964aab References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> Date: Fri, 26 Jun 2020 17:16:25 +0000 Content-Type: multipart/alternative; boundary=85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 17:16:32 -0000 --85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema < huitema@huitema.net > = wrote: >=20 >=20 >=20 > On 6/25/2020 11:11 PM, Melinda Shore wrote: >=20 >=20 >=20 >>=20 >>=20 >> On 6/25/20 3:29 PM, Erik Nygren wrote: >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> One quick comment is that binding tokens to IP addresses is strongly >>> counter-recommended. >>> It doesn't survive NATs or proxies, mobility, and it is especially >>> problematic in IPv6+IPv4 dual-stack environments. >>>=20 >>>=20 >>=20 >>=20 >>=20 >> There's been a bunch of past work done developing similar sorts of >> protocols, and for what it's worth I wrote up a mechanism for using >> address tags and address rewrites, but unfortunately Cisco decided to >> patent it. Anyway, there are ways of dealing with this problem that don'= t >> require binding the address to the token ("all technical problems can be >> solved by introducing a layer of indirection"). >>=20 >>=20 >>=20 >=20 >=20 >=20 > There is also an interesting privacy issue. The token is meant to let a > provider identify some properties of the connection. I suppose there are > ways to do that without having it become a unique identifier that can be > tracked by, well, pretty much everybody. But you have better spell out > these ways. >=20 >=20 >=20 >=20 You are right that for the duration of a token, one could use it to identif= y an endpoint (either application or most likely a combination of user/appl= ication). Tokens expire and intermediary nodes cannot correlate tokens with= each other as they are encrypted. So tracking cannot happen across differe= nt tokens (of the same user), or between token-enabled and non-token-enable= d traffic. I guess similar type of tracking happens when users are not behi= nd a NAT and their IP address can be used to track them. Would it make sens= e to have the user add a random value to a token, and then encrypt it with = the network's public key, so that each token becomes unique and cannot be t= racked. Would that address the privacy concerns better? >=20 >=20 >=20 > Then, there are potential interactions with ESNI/ECH. The whole point of > ECH is to keep private extensions private. The token extension would need > to be placed in the outer envelope, which is public but does not expose > seemingly important information like the SNI or the ALPN. >=20 >=20 >=20 >=20 Ah, I was not aware that ESNI can now include all CH extensions - thanks fo= r the pointer. Yes, the token would have to stay on the outer envelope so t= he network can process it. The main idea is you can encrypt everything that= is client-server specific, and just keep a token to explicitly exchange in= formation with trusted networks. >=20 >=20 >=20 > There are also implications for QUIC, in which the TLS data is part of an > encrypted payload. The encryption key of the TLS carrying initial packets > is not secret in V1, but it might well become so in a future version. >=20 >=20 >=20 >=20 Haven't looked into QUIC yet, but is on the list of things to do. If anyone= is interested to help us explore this, please let me know. >=20 >=20 >=20 > -- Christian Huitema >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ ietf. org ( TLS@ietf.org ) > https:/ / www. ietf. org/ mailman/ listinfo/ tls ( > https://www.ietf.org/mailman/listinfo/tls ) >=20 >=20 > --85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
3D"


On Fri, Jun = 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM, Erik Nygren wrote:

One quick comment is that binding tokens to IP addresses is strongly counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the durati= on of a token, one could use it to identify an endpoint (either application= or most likely a combination of user/application). Tokens expire and inter= mediary nodes cannot correlate tokens with each other as they are encrypted= . So tracking cannot happen across different tokens (of the same user), or = between token-enabled and non-token-enabled traffic. I guess similar type o= f tracking happens when users are not behind a NAT and their IP address can= be used to track them. Would it make sense to have the user add a random v= alue to a token, and then encrypt it with the network's public key, so = that each token becomes unique and cannot be tracked. Would that address th= e privacy concerns better?

<= /div>

Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


<= div class=3D"">

There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.


--85299a4e6af11a79b92c42f11ed8b5cf4aeb6776b9d92be92b084c8cb9e8-- From nobody Fri Jun 26 10:42:52 2020 Return-Path: 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 E70133A0BBF for ; Fri, 26 Jun 2020 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jOLUfoKy63yf for ; Fri, 26 Jun 2020 10:42:49 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 063D23A0BAB for ; Fri, 26 Jun 2020 10:42:48 -0700 (PDT) Received: from xse27.mail2web.com ([66.113.196.27] helo=xse.mail2web.com) by mx171.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1josN5-000snn-O7 for tls@ietf.org; Fri, 26 Jun 2020 19:42:47 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49tkjp14qwz22Mx for ; Fri, 26 Jun 2020 10:42:38 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1josN3-0006iQ-Vx for tls@ietf.org; Fri, 26 Jun 2020 10:42:38 -0700 Received: (qmail 3943 invoked from network); 26 Jun 2020 17:42:37 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.153]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jun 2020 17:42:37 -0000 To: Yiannis Yiakoumis Cc: Melinda Shore , tls@ietf.org, network-tokens@ietf.org References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> Date: Fri, 26 Jun 2020 10:42:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A1EF4775B662EB83EE14254E" Content-Language: en-US X-Originating-IP: 66.113.196.27 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.27/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.27/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0f6LF1GdvkEexklpcFpSF5apSDasLI4SayDByyq9LIhVMVvqKlQUtLwO BOP0oQh1dUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4adfMKcflL6IuPnpbJ760OOgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+eYkD5a9Nw7hRCVIMRq0efqTAas0edmB2q/yBRqnQY9Wo6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm6ZQhvJRsM2m I6SM4wXHHdy+nDmOO/l0k0eYmgKL9N7NJ6qydqunGeRucQzUa1BY6TESzAX/5TqBYIW16uDk9RT0 lSfuxANzRU5MAZzTOSGB3Akz5lm78RWIReBxnetgOPKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6rUrHvUp663w0CHIt3fUi3pxMPnetLBJMh51NiRRoHIA04+WXylLQLB2v6tymK4rhmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50slILRD2F7oGp9qyS24nW3A08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 17:42:51 -0000 This is a multi-part message in MIME format. --------------A1EF4775B662EB83EE14254E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: > > > > On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema > > wrote: > > On 6/25/2020 11:11 PM, Melinda Shore wrote: > > On 6/25/20 3:29 PM, Erik Nygren wrote: > > One quick comment is that binding tokens to IP addresses > is strongly counter-recommended. > It doesn't survive NATs or proxies, mobility, and it is > especially problematic in IPv6+IPv4 dual-stack environments. > > There's been a bunch of past work done developing similar > sorts of protocols, and for what it's worth I wrote up a > mechanism for using address tags and address rewrites, but > unfortunately Cisco decided to patent it. Anyway, there are > ways of dealing with this problem that don't require binding > the address to the token ("all technical problems can be > solved by introducing a layer of indirection"). > > There is also an interesting privacy issue. The token is meant to > let a provider identify some properties of the connection. I > suppose there are ways to do that without having it become a > unique identifier that can be tracked by, well, pretty much > everybody. But you have better spell out these ways. > > > You are right that for the duration of a token, one could use it to > identify an endpoint (either application or most likely a combination > of user/application). Tokens expire and intermediary nodes cannot > correlate tokens with each other as they are encrypted. So tracking > cannot happen across different tokens (of the same user), or between > token-enabled and non-token-enabled traffic. I guess similar type of > tracking happens when users are not behind a NAT and their IP address > can be used to track them. Would it make sense to have the user add a > random value to a token, and then encrypt it with the network's public > key, so that each token becomes unique and cannot be tracked. Would > that address the privacy concerns better? That would certainly be better. The basic rule is that any such identifier should be used only once. Pretty much the same issue as the session resume tickets. > > Then, there are potential interactions with ESNI/ECH. The whole > point of ECH is to keep private extensions private. The token > extension would need to be placed in the outer envelope, which is > public but does not expose seemingly important information like > the SNI or the ALPN. > > > Ah, I was not aware that ESNI can now include all CH extensions - > thanks for the pointer. Yes, the token would have to stay on the outer > envelope so the network can process it. The main idea is you can > encrypt everything that is client-server specific, and just keep a > token to explicitly exchange information with trusted networks.  > > There are also implications for QUIC, in which the TLS data is > part of an encrypted payload. The encryption key of the TLS > carrying initial packets is not secret in V1, but it might well > become so in a future version. > > > Haven't looked into QUIC yet, but is on the list of things to do. If > anyone is interested to help us explore this, please let me know. You may want to have that discussion in the QUIC WG. If you are building some kind of QoS service, you probably want it to work with QUIC too. -- Christian Huitema --------------A1EF4775B662EB83EE14254E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eT4NCiAgICA8cD48YnI+DQogICAgPC9wPg0KICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+T24gNi8yNi8yMDIwIDEwOjE2IEFNLCBZaWFubmlzDQogICAgICBZaWFrb3VtaXMg d3JvdGU6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpj aXRlPSJtaWQ6a2J3Z2ppY3MuM2UzMjdjZTUtMWQ1Yy00YmE0LTlkOGUtYWU5Y2I3OWYzMDAz QHdlLmFyZS5zdXBlcmh1bWFuLmNvbSI+DQogICAgICA8bWV0YSBodHRwLWVxdWl2PSJjb250 ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQogICAgICA8 ZGl2Pg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAgIDxkaXYgc3R5bGU9ImRpc3BsYXk6IG5v bmU7IGJvcmRlcjogMHB4OyB3aWR0aDogMHB4OyBoZWlnaHQ6DQogICAgICAgICAgICAwcHg7 IG92ZXJmbG93OiBoaWRkZW47IHZpc2liaWxpdHk6IGhpZGRlbjsiPjxpbWcNCnNyYz0iaHR0 cHM6Ly9yLnN1cGVyaHVtYW4uY29tL1FHTnpzTnljWFYtU1ZBalp1TEZ2cXhDVDQzU0pONm5P aFpqUWlTMmw5cGN3T2E3SE9vMkFJVjRXWl9HblBmajJYbXRrYW9iVFdUaFNyWU9Td1d6ajlS dHRCZ0FtWWVxMzVuQXpndmVZM0VzcU91cDRBUTJyN2V6eEdDRE1tWGFXXzJ2QnlzbUNMUjZQ eEJBdjRDNlBWRkFrZUUtRVRCVGl3bEw5clFoNlVyYXRMQWVXYmptSS5naWYiDQogICAgICAg ICAgICAgIGFsdD0iICIgc3R5bGU9ImRpc3BsYXk6IG5vbmU7IGJvcmRlcjogMHB4OyB3aWR0 aDogMHB4Ow0KICAgICAgICAgICAgICBoZWlnaHQ6IDBweDsgb3ZlcmZsb3c6IGhpZGRlbjsg dmlzaWJpbGl0eTogaGlkZGVuOyINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIiB3aWR0aD0iMSIgaGVpZ2h0PSIwIj48IS0tICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLT48L2Rpdj4N CiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj48YnI+DQogICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2 IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPjxicj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gRnJpLCBKdW4gMjYsIDIwMjAgYXQgNzoyOQ0KICAgICAgICAgICAgICAgICAg QU0sIENocmlzdGlhbiBIdWl0ZW1hIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4mbHQ7PGEN CiAgICAgICAgICAgICAgICAgICAgICBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5l dCIgdGFyZ2V0PSJfYmxhbmsiDQogICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs8L3NwYW4+DQogICAgICAg ICAgICAgICAgICB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAg ICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KICAg ICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibnVs bCIgaWQ9Im51bGwiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9IiI+T24g Ni8yNS8yMDIwIDExOjExIFBNLCBNZWxpbmRhIFNob3JlDQogICAgICAgICAgICAgICAgICAg ICAgICAgIHdyb3RlOg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2tx dW90ZSBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9IiI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gNi8yNS8yMCAzOjI5IFBNLCBFcmlr IE55Z3JlbiB3cm90ZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PGJsb2NrcXVvdGUgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHAg Y2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPbmUgcXVpY2sgY29t bWVudCBpcyB0aGF0IGJpbmRpbmcgdG9rZW5zDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0byBJUCBhZGRyZXNzZXMgaXMgc3Ryb25nbHkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNvdW50ZXItcmVjb21tZW5kZWQuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJdCBkb2Vzbid0 IHN1cnZpdmUgTkFUcyBvciBwcm94aWVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbW9iaWxpdHksIGFuZCBpdCBpcyBlc3BlY2lhbGx5DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBwcm9ibGVtYXRpYyBpbiBJUHY2K0lQdjQgZHVhbC1zdGFjaw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZW52aXJvbm1lbnRzLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1 b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGVyZSdzIGJlZW4gYSBidW5jaCBvZiBwYXN0IHdvcmsg ZG9uZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRldmVsb3Bpbmcgc2ltaWxhciBz b3J0cyBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3RvY29scywgYW5kIGZv ciB3aGF0IGl0J3Mgd29ydGggSSB3cm90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IHVwIGEgbWVjaGFuaXNtIGZvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVzaW5n IGFkZHJlc3MgdGFncyBhbmQgYWRkcmVzcyByZXdyaXRlcywgYnV0DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgdW5mb3J0dW5hdGVseSBDaXNjbw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGRlY2lkZWQgdG8gcGF0ZW50IGl0LiBBbnl3YXksIHRoZXJlIGFyZSB3YXlz DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgZGVhbGluZyB3aXRoIHRoaXMNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9ibGVtIHRoYXQgZG9uJ3QgcmVxdWlyZSBi aW5kaW5nIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgdG8gdGhl IHRva2VuICgiYWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgdGVjaG5pY2FsIHBy b2JsZW1zIGNhbiBiZSBzb2x2ZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBp bnRyb2R1Y2luZyBhIGxheWVyIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5k aXJlY3Rpb24iKS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgIDwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxv Y2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBUaGVyZSBpcyBhbHNvIGFuIGludGVyZXN0aW5nIHByaXZh Y3kgaXNzdWUuDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSB0b2tlbiBpcyBtZWFu dCB0byBsZXQgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBwcm92aWRlciBpZGVudGlm eSBzb21lIHByb3BlcnRpZXMgb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgIGNv bm5lY3Rpb24uIEkgc3VwcG9zZSB0aGVyZSBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgd2F5cyB0byBkbyB0aGF0IHdpdGhvdXQgaGF2aW5nIGl0IGJlY29tZSBhDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHVuaXF1ZSBpZGVudGlmaWVyIHRoYXQgY2FuIGJlDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHRyYWNrZWQgYnksIHdlbGwsIHByZXR0eSBtdWNoIGV2 ZXJ5Ym9keS4gQnV0DQogICAgICAgICAgICAgICAgICAgICAgICAgIHlvdSBoYXZlIGJldHRl ciBzcGVsbCBvdXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlc2Ugd2F5cy4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8L2Rpdj4N CiAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAgICAgIDxkaXYgY2xhc3M9 IiI+PGJyPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgPGRpdiBjbGFzcz0iIj5Zb3UgYXJlIHJpZ2h0IHRoYXQgZm9yIHRoZSBkdXJh dGlvbiBvZiBhDQogICAgICAgICAgICAgIHRva2VuLCBvbmUgY291bGQgdXNlIGl0IHRvIGlk ZW50aWZ5IGFuIGVuZHBvaW50IChlaXRoZXINCiAgICAgICAgICAgICAgYXBwbGljYXRpb24g b3IgbW9zdCBsaWtlbHkgYSBjb21iaW5hdGlvbiBvZg0KICAgICAgICAgICAgICB1c2VyL2Fw cGxpY2F0aW9uKS4gVG9rZW5zIGV4cGlyZSBhbmQgaW50ZXJtZWRpYXJ5IG5vZGVzDQogICAg ICAgICAgICAgIGNhbm5vdCBjb3JyZWxhdGUgdG9rZW5zIHdpdGggZWFjaCBvdGhlciBhcyB0 aGV5IGFyZQ0KICAgICAgICAgICAgICBlbmNyeXB0ZWQuIFNvIHRyYWNraW5nIGNhbm5vdCBo YXBwZW4gYWNyb3NzIGRpZmZlcmVudA0KICAgICAgICAgICAgICB0b2tlbnMgKG9mIHRoZSBz YW1lIHVzZXIpLCBvciBiZXR3ZWVuIHRva2VuLWVuYWJsZWQgYW5kDQogICAgICAgICAgICAg IG5vbi10b2tlbi1lbmFibGVkIHRyYWZmaWMuIEkgZ3Vlc3Mgc2ltaWxhciB0eXBlIG9mDQog ICAgICAgICAgICAgIHRyYWNraW5nIGhhcHBlbnMgd2hlbiB1c2VycyBhcmUgbm90IGJlaGlu ZCBhIE5BVCBhbmQgdGhlaXINCiAgICAgICAgICAgICAgSVAgYWRkcmVzcyBjYW4gYmUgdXNl ZCB0byB0cmFjayB0aGVtLiBXb3VsZCBpdCBtYWtlIHNlbnNlDQogICAgICAgICAgICAgIHRv IGhhdmUgdGhlIHVzZXIgYWRkIGEgcmFuZG9tIHZhbHVlIHRvIGEgdG9rZW4sIGFuZCB0aGVu DQogICAgICAgICAgICAgIGVuY3J5cHQgaXQgd2l0aCB0aGUgbmV0d29yaydzIHB1YmxpYyBr ZXksIHNvIHRoYXQgZWFjaA0KICAgICAgICAgICAgICB0b2tlbiBiZWNvbWVzIHVuaXF1ZSBh bmQgY2Fubm90IGJlIHRyYWNrZWQuIFdvdWxkIHRoYXQNCiAgICAgICAgICAgICAgYWRkcmVz cyB0aGUgcHJpdmFjeSBjb25jZXJucyBiZXR0ZXI/PGJyPg0KICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgPC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAgICAgPC9kaXY+DQogICAg PC9ibG9ja3F1b3RlPg0KICAgIDxwPlRoYXQgd291bGQgY2VydGFpbmx5IGJlIGJldHRlci4g VGhlIGJhc2ljIHJ1bGUgaXMgdGhhdCBhbnkgc3VjaA0KICAgICAgaWRlbnRpZmllciBzaG91 bGQgYmUgdXNlZCBvbmx5IG9uY2UuIFByZXR0eSBtdWNoIHRoZSBzYW1lIGlzc3VlIGFzDQog ICAgICB0aGUgc2Vzc2lvbiByZXN1bWUgdGlja2V0cy48YnI+DQogICAgPC9wPg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiDQpjaXRlPSJtaWQ6a2J3Z2ppY3MuM2UzMjdjZTUtMWQ1 Yy00YmE0LTlkOGUtYWU5Y2I3OWYzMDAzQHdlLmFyZS5zdXBlcmh1bWFuLmNvbSI+DQogICAg ICA8ZGl2Pg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICA8 ZGl2IGNsYXNzPSIiPg0KICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPjxicj4NCiAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXYg Y2xhc3M9IiI+DQogICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAgICAg ICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KICAgICAgICAgICAgICAgICAgPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwDQogICAgICAg ICAgICAgICAgICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQogICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCiAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im51bGwiIGlkPSJudWxsIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICBUaGVuLCB0aGVyZSBhcmUgcG90ZW50 aWFsIGludGVyYWN0aW9ucyB3aXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgIEVTTkkv RUNILiBUaGUgd2hvbGUgcG9pbnQgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgRUNI IGlzIHRvIGtlZXAgcHJpdmF0ZSBleHRlbnNpb25zIHByaXZhdGUuIFRoZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICB0b2tlbiBleHRlbnNpb24gd291bGQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgbmVlZCB0byBiZSBwbGFjZWQgaW4gdGhlIG91dGVyIGVudmVsb3BlLCB3 aGljaA0KICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBwdWJsaWMgYnV0IGRvZXMgbm90 DQogICAgICAgICAgICAgICAgICAgICAgICAgIGV4cG9zZSBzZWVtaW5nbHkgaW1wb3J0YW50 IGluZm9ybWF0aW9uIGxpa2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIFNOSSBv ciB0aGUgQUxQTi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90 ZT4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPC9kaXY+DQogICAg ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgIDxkaXY+ PGJyPg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj5BaCwgSSB3 YXMgbm90IGF3YXJlIHRoYXQgRVNOSSBjYW4gbm93IGluY2x1ZGUgYWxsIENIDQogICAgICAg ICAgICAgICAgZXh0ZW5zaW9ucyAtIHRoYW5rcyBmb3IgdGhlIHBvaW50ZXIuIFllcywgdGhl IHRva2VuDQogICAgICAgICAgICAgICAgd291bGQgaGF2ZSB0byBzdGF5IG9uIHRoZSBvdXRl ciBlbnZlbG9wZSBzbyB0aGUgbmV0d29yaw0KICAgICAgICAgICAgICAgIGNhbiBwcm9jZXNz IGl0LiBUaGUgbWFpbiBpZGVhIGlzIHlvdSBjYW4gZW5jcnlwdA0KICAgICAgICAgICAgICAg IGV2ZXJ5dGhpbmcgdGhhdCBpcyBjbGllbnQtc2VydmVyIHNwZWNpZmljLCBhbmQganVzdCBr ZWVwDQogICAgICAgICAgICAgICAgYSB0b2tlbiB0byBleHBsaWNpdGx5IGV4Y2hhbmdlIGlu Zm9ybWF0aW9uIHdpdGggdHJ1c3RlZA0KICAgICAgICAgICAgICAgIG5ldHdvcmtzLsKgPGJy Pg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAg ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2 IGNsYXNzPSIiPg0KICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPg0KICAgICAgICAgICAg ICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgIDxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAg ICAgICAgICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJudWxsIiBpZD0ibnVsbCI+DQogICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlcmUgYXJlIGFsc28gaW1wbGlj YXRpb25zIGZvciBRVUlDLCBpbiB3aGljaA0KICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgVExTIGRhdGEgaXMgcGFydCBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICBhbiBl bmNyeXB0ZWQgcGF5bG9hZC4gVGhlIGVuY3J5cHRpb24ga2V5IG9mDQogICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBUTFMgY2FycnlpbmcgaW5pdGlhbA0KICAgICAgICAgICAgICAg ICAgICAgICAgICBwYWNrZXRzIGlzIG5vdCBzZWNyZXQgaW4gVjEsIGJ1dCBpdCBtaWdodCB3 ZWxsDQogICAgICAgICAgICAgICAgICAgICAgICAgIGJlY29tZSBzbyBpbiBhIGZ1dHVyZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICB2ZXJzaW9uLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICA8L3A+DQogICAgICAgICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPGRp dj4NCiAgICAgICAgICAgICAgPGRpdj48YnI+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICA8ZGl2PkhhdmVuJ3QgbG9va2VkIGludG8gUVVJQyB5ZXQsIGJ1dCBpcyBv biB0aGUgbGlzdCBvZg0KICAgICAgICAgICAgICAgIHRoaW5ncyB0byBkby4gSWYgYW55b25l IGlzIGludGVyZXN0ZWQgdG8gaGVscCB1cyBleHBsb3JlDQogICAgICAgICAgICAgICAgdGhp cywgcGxlYXNlIGxldCBtZSBrbm93LiA8YnI+DQogICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPC9kaXY+DQogICAgICAgIDwvZGl2Pg0KICAg ICAgPC9kaXY+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxwPllvdSBtYXkgd2FudCB0byBo YXZlIHRoYXQgZGlzY3Vzc2lvbiBpbiB0aGUgUVVJQyBXRy4gSWYgeW91IGFyZQ0KICAgICAg YnVpbGRpbmcgc29tZSBraW5kIG9mIFFvUyBzZXJ2aWNlLCB5b3UgcHJvYmFibHkgd2FudCBp dCB0byB3b3JrDQogICAgICB3aXRoIFFVSUMgdG9vLjxicj4NCiAgICA8L3A+DQogICAgPHA+ LS0gQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQogICAgPC9wPg0KICA8L2JvZHk+DQo8L2h0bWw+ DQo= --------------A1EF4775B662EB83EE14254E-- From nobody Fri Jun 26 15:29:59 2020 Return-Path: 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 9E6153A0CF1 for ; Fri, 26 Jun 2020 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tm0D_25YxAxx for ; Fri, 26 Jun 2020 15:29:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A443A0CEB for ; Fri, 26 Jun 2020 15:29:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 28441389A0; Fri, 26 Jun 2020 18:27:09 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HaSQLlMUX0ZV; Fri, 26 Jun 2020 18:27:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E01BA3899F; Fri, 26 Jun 2020 18:27:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54CE31D3; Fri, 26 Jun 2020 18:29:51 -0400 (EDT) From: Michael Richardson To: Nico Williams , Brian Campbell , ietf-http-wg@w3.org, tls@ietf.org In-Reply-To: <20200625234212.GV3100@localhost> References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:29:58 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote: >> Thus, a single header isn't enough, although there could be some degeneration >> that results in a single header. We need a few variables to update. >> >> I think we have a choice between: > HTTP/2 and, I imagine, /3, does header compression of the right sort > here. The front-end/back-end connection is not likely to be HTTP/2 soon, but maybe this would push it there. Right now, it's a often pseudo-binary-HTTP connection via uwsgi (across python/ruby/perl/npm) backends, fastcgi and passenger has a protocol that I don't recall. All avoid reparsing the HTTP headers excessively, while still letting the whole thing evolve. There are responses that allow the backend to ask the front to serve up static content and/or cached results as well. So it's not often pure HTTP/1, but it acts a bit like it. >> 2) assuming that state will be maintained by both ends, and simply updating >> the state appropriately. When it comes to this, I think of the >> HTTP PATCH methods, but I'm not sure I mean this literally. > Can TLS let a client authenticate multiple times? What has been pointed out is that TLS can renegotiate client authentication. (Also also server authentication, but that's not relevant here, I think). If I had a monolithic web server with application code, I think that I would have no idea what to do if such a thing happened: how I'd detect it, or what I'd do with it. I think it would look like an entirely new client identity. (This would be particularly difficult for J2EE environments which basically spin up a JVM per [authenticated] client) >> Alternately, the TLS front-end could maintain a RESTful interface on a >> per-connection basis that the back-end could interrogate. The header >> would just provide the right reference to that. The RESTful interface >> could even be pushed/updated into some other CPU on the TLS terminator. > Yes, this would also work. In this case Client-Cert: would carry just a > URI. This is nice because the backend can validate that the origin of > that URL is one it trusts. Yeah, URI rather than URL, as it could even be ni: telling the client to go look in a database/memcached/redis for the entire story. This is more than a baby step, as Brian has pointed out. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72dt4ACgkQgItw+93Q 3WUIKAgAiRR/t2xb9waCe1SQc8G/Egrxk4aZZ9b4gv/tucoTTb+t/jjzw/8S2iQr fIgPXAnlYpWdK1vc92qwTVjEkaZ2KwI/LhWYeIeqGRLk3MhmZ6UjnIb++gzobSBJ eiJwfCsUhhnk6A1+/UY1RXJynmARxfw1TCdcgJxmsQK08g0qOCG7jLFoE2avrEzi 0WDUJtPiWfe8d2UHDtkU/Gw5lg7qjnLUN7txtMIELjkJgqQd8Ef8CItM8g9zz8Q0 +y7K3+NbpkTHKf02fNCmF9OLTsudPWQu4Babhz8aYjIVlKkU8IHZDH6sw6m4gyNc VIuaH/o/SdLJpMhjJwkEpLt/sX8idw== =Tegy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 15:41:07 2020 Return-Path: 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 B840C3A0CFD for ; Fri, 26 Jun 2020 15:41:06 -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 xaVWKRSLfq7O for ; Fri, 26 Jun 2020 15:41:05 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 CA8DB3A0CE1 for ; Fri, 26 Jun 2020 15:41:05 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05QMXaQ2027916; Fri, 26 Jun 2020 23:41:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=IE672WXXPt8E6dowY6CXAVv4g5eW9SuFDBhSlPv6e1E=; b=AQLe8wXjoVwA4cIoPRuVb4sX+w1XsQ6daG83RurYRskQwdgwQtaf8VgtqqMNRGNPgwpf XHFI8BzGdCSPEzZVR6GAneeK50AzzATyOXUp9yRe2s2iJPK/gpQWPP/FhihixvS+DO1Q Mn7WPSwADw0UXn4PJ5RA27n/P06+FMSlUIHw6h9arSzeaxN7Uf4fOMdrRKKuMCvEcBq4 PGIbzLhzw1LkJFAaqBIab9TKePXflP5OO3T4HJWS4wDNqDjJ+M4o2GDXCye0WT7APli0 DEeYIYOueY9w8P/40KPAJDHXkC4A13SJ2anHpTulNcoy+FiCHt4WR6m/b6CnGZQCd2nw NQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 31uutqwsw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 23:41:04 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05QMa3Ke006670; Fri, 26 Jun 2020 18:41:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint8.akamai.com with ESMTP id 31uustjj29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 18:41:03 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Jun 2020 17:41:02 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 26 Jun 2020 17:41:02 -0500 From: "Salz, Rich" To: Michael Richardson , Nico Williams , Brian Campbell , "ietf-http-wg@w3.org" , "tls@ietf.org" Thread-Topic: [TLS] something something certificate --- boiling a small lake Thread-Index: AQHWRlncfXVqtw/tUEKYTRGg9YBW66jqW58AgAF+HID//8AQgA== Date: Fri, 26 Jun 2020 22:41:02 +0000 Message-ID: References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> In-Reply-To: <20929.1593210591@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.32] Content-Type: text/plain; charset="utf-8" Content-ID: <8979E4833D0CEF4AAD617FEE45459EAA@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-26_12:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxlogscore=727 suspectscore=0 phishscore=0 mlxscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006260158 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-26_12:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 bulkscore=0 cotscore=-2147483648 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxlogscore=685 clxscore=1011 phishscore=0 mlxscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006260158 Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:41:07 -0000 PiAgICBXaGF0IGhhcyBiZWVuIHBvaW50ZWQgb3V0IGlzIHRoYXQgVExTIGNhbiByZW5lZ290aWF0 ZSBjbGllbnQgYXV0aGVudGljYXRpb24uDQoNCk5vdCBpbiBUTFMgMS4zLiAgQW5kIHdpdGggVExT IDEuMCBhbmQgVExTIDEuMSBvbiB0aGVpciB3YXkgb3V0IHRoZSBkb29yIC4uLiANCg0KDQo= From nobody Fri Jun 26 15:43:49 2020 Return-Path: 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 2FA983A0D01 for ; Fri, 26 Jun 2020 15:43:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=cryptonector.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 TpVCw0HSLiQm for ; Fri, 26 Jun 2020 15:43:47 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 ED3C63A0CFD for ; Fri, 26 Jun 2020 15:43:46 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 100594017FB; Fri, 26 Jun 2020 22:43:46 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-1-7.trex.outbound.svc.cluster.local [100.96.1.7]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6E5864011B3; Fri, 26 Jun 2020 22:43:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 26 Jun 2020 22:43:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Grain-Hook: 7720d93a1c33550b_1593211425723_3222865382 X-MC-Loop-Signature: 1593211425722:126160701 X-MC-Ingress-Time: 1593211425722 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id 0F6227F08A; Fri, 26 Jun 2020 15:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=EX5Eqj0NR2U6xf r+1XeFGBaSUXk=; b=eXOjK4l/lXcxoP7wstFSWCTV7HRVy4z1xeVQg+OqKz8PzM w30QjN/XOmwU1fp8/Rze5QHMG2GK3gWJ5THrbjU9BcAtXRGsFWAethyhhV2x6cB0 OMc5NERUexuziyEcaw6mRXWQWc70tRLp0xUZOPD3nSiF9YCteRVdqM3BCWF3M= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 78DC17F088; Fri, 26 Jun 2020 15:43:40 -0700 (PDT) Date: Fri, 26 Jun 2020 17:43:37 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: "Salz, Rich" Cc: Michael Richardson , Brian Campbell , "ietf-http-wg@w3.org" , "tls@ietf.org" Message-ID: <20200626224336.GY3100@localhost> References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 22:43:48 -0000 On Fri, Jun 26, 2020 at 10:41:02PM +0000, Salz, Rich wrote: > > What has been pointed out is that TLS can renegotiate client > > authentication. > > Not in TLS 1.3. And with TLS 1.0 and TLS 1.1 on their way out the > door ... That's what I thought. So there's just the header compression issue. BTW, this also comes up with cookies, tokens, etc. Nico -- From nobody Fri Jun 26 16:47:45 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A81E53A0D21; Fri, 26 Jun 2020 16:47:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159321525062.3808.13538807790087957544@ietfa.amsl.com> Date: Fri, 26 Jun 2020 16:47:30 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 23:47:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-09.txt Pages : 18 Date : 2020-06-26 Abstract: The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 26 16:52:02 2020 Return-Path: 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 4D2C83A0D52 for ; Fri, 26 Jun 2020 16:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=cloudflare.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 FNYO5V_dyO_y for ; Fri, 26 Jun 2020 16:51:49 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E2A3A0D30 for ; Fri, 26 Jun 2020 16:51:49 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id x14so3568842uao.7 for ; Fri, 26 Jun 2020 16:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ioC5o+CWX20XZ2YFMUoHJa2IFtvlwxCVjhh+IHnApdk=; b=V1ZGrh6NRAAr1Dh4SKIluYaoMCmyzGGmSMKw5yylFNeiXo3cY8YstWuOEnEQqOprSD zKakZqKZUNXWgpv7ZhOZtEDrMzP04wKA4cichTRgtkPmi3YfwfYh65DkPVIgpn2eMVD/ i5fuT8EZR+QDTTul8IQ8nW614dDAy+JEJLW5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ioC5o+CWX20XZ2YFMUoHJa2IFtvlwxCVjhh+IHnApdk=; b=lxurtmdGsSJx9x6lajuddmOkpxa+IkFdDjlS5pGivGEQBDop/PVdAXx94K/m6Ci04+ VhRtmEt5GDSF69FRawAe1hYsEBTgHuS48pb9NnwMJAVNnR/+g6JgN7logpXpErqVOrap 9EHOLmuXp95u/PRfJK8BV58L+LKRj1MrurOY22cyckCRzXR+9WvI7ye3OnB7j20tOqJn wkSvM87eyfoqBAMbJUfhz3pttg3jd5kcxGxyPj39phzdZ7V/x8tvoxjF+U+ZzVxD763D 7IVylXFQtbTeT+R+AYs51bNjQmFG4wR4cwRGerCgRSqwSBN9/ybDEda4Elf4wvFxG6vF w+Vg== X-Gm-Message-State: AOAM532nkyKD+mSyybH1dY5/KpEiCnALdLDk1VCnos5lf8gxJP2gPGJe xO7IuTnBOM6t9ey6QDdQtpyzW4m/5/qZ4PLh9LXRL7KItrhqEg== X-Google-Smtp-Source: ABdhPJxNczIW2IOwC+Rw2ZT9S3wDjKh8T0phAOMcsmKN1GZqS17kqEsTK06iHQQ0N5c48xGeja9S0pgHlCkWJjddn0Y= X-Received: by 2002:a9f:3b18:: with SMTP id i24mr4287779uah.52.1593215507679; Fri, 26 Jun 2020 16:51:47 -0700 (PDT) MIME-Version: 1.0 References: <159321525091.3808.9987324221405950713@ietfa.amsl.com> In-Reply-To: <159321525091.3808.9987324221405950713@ietfa.amsl.com> From: Nick Sullivan Date: Fri, 26 Jun 2020 16:51:31 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000064400405a90564da" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 23:52:01 -0000 --00000000000064400405a90564da Content-Type: text/plain; charset="UTF-8" TLSWG, We have submitted draft-09 of the Delegated Credentials draft. This draft incorporates the reviews of -07 from the WGLC process as well as changes from draft-08 from the list that weren't covered during the WGLC. Here's a quick summary of the changes: draft-09 * Fix section bullets in 4.1.3. * Add operational considerations section for clock skew * Add text around using an oracle to forge DCs in the future and past * Add text about certificate extension vs EKU draft-08 * Include details about the impact of signature forgery attacks * Copy edits for readability * Fix section about DC reuse * Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the list Best, Nick ---------- Forwarded message --------- From: Date: Fri, Jun 26, 2020 at 4:47 PM Subject: New Version Notification for draft-ietf-tls-subcerts-09.txt To: Richard Barnes , Subodh Iyengar , Eric Rescorla , Nick Sullivan A new version of I-D, draft-ietf-tls-subcerts-09.txt has been successfully submitted by Nick Sullivan and posted to the IETF repository. Name: draft-ietf-tls-subcerts Revision: 09 Title: Delegated Credentials for TLS Document date: 2020-06-26 Group: tls Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ Htmlized: https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09 Abstract: The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000064400405a90564da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLSWG,

We have submitted draft-09 of th= e Delegated Credentials draft. This draft incorporates the reviews of -07 f= rom the WGLC process as well as changes from draft-08 from the list that we= ren't covered during the WGLC.

Here's a qu= ick summary of the changes:
=C2=A0 =C2=A0draft-09
=C2=A0 =C2= =A0* =C2=A0Fix section bullets in 4.1.3.
=C2=A0 =C2=A0* =C2=A0Add operat= ional considerations section for clock skew
=C2=A0 =C2=A0* =C2=A0Add tex= t around using an oracle to forge DCs in the future and
=C2=A0 =C2=A0 = =C2=A0 past
=C2=A0 =C2=A0* =C2=A0Add text about certificate extension vs= EKU
=C2=A0 =C2=A0draft-08
=C2=A0 =C2=A0* =C2=A0Include details about= the impact of signature forgery attacks
=C2=A0 =C2=A0* =C2=A0Copy edits= for readability
=C2=A0 =C2=A0* =C2=A0Fix section about DC reuse
=C2= =A0 =C2=A0* =C2=A0Incorporate feedback from Jonathan Hammell and Kevin Jaco= bs on the
=C2=A0 =C2=A0 =C2=A0 list

Best,
Nick

----= ------ Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Jun 26, 2020 at 4:47 PM
Subject: New Version Notificatio= n for draft-ietf-tls-subcerts-09.txt
To: Richard Barnes <rlb@ipv.sx&g= t;, Subodh Iyengar <subodh@fb.com&g= t;, Eric Rescorla <ekr@rtfm.com>,= Nick Sullivan <nick@cloudflare.c= om>



A new version of I-D, draft-ietf-tls-subcerts-09.txt
has been successfully submitted by Nick Sullivan and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-subcerts
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Delegated Credentials for TLS
Document date:=C2=A0 2020-06-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tls
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 18
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-tls-subcerts-0= 9.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-ietf-tls-subcerts-09
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09<= br>
Abstract:
=C2=A0 =C2=A0The organizational separation between the operator of a TLS en= dpoint
=C2=A0 =C2=A0and the certification authority can create limitations.=C2=A0 = For example,
=C2=A0 =C2=A0the lifetime of certificates, how they may be used, and the =C2=A0 =C2=A0algorithms they support are ultimately determined by the
=C2=A0 =C2=A0certification authority.=C2=A0 This document describes a mecha= nism by
=C2=A0 =C2=A0which operators may delegate their own credentials for use in = TLS,
=C2=A0 =C2=A0without breaking compatibility with peers that do not support = this
=C2=A0 =C2=A0specification.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--00000000000064400405a90564da-- From nobody Fri Jun 26 17:00:19 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A77023A0D27; Fri, 26 Jun 2020 17:00:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159321601762.22524.9473409515134510868@ietfa.amsl.com> Date: Fri, 26 Jun 2020 17:00:17 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-13.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:00:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-13.txt Pages : 14 Date : 2020-06-26 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-13 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 26 17:01:22 2020 Return-Path: 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 252BD3A0D77 for ; Fri, 26 Jun 2020 17:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=cloudflare.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 m6BH1zyuURQN for ; Fri, 26 Jun 2020 17:01:10 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51B73A0D6C for ; Fri, 26 Jun 2020 17:01:07 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id b13so3584363uav.3 for ; Fri, 26 Jun 2020 17:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hdrupInEjwHUQHwcurBVHs/P4V2R+zhfOxEo6S7NI0k=; b=YAGWxy5qBUQIF77Fx4O5ngGr04ozkDP9voIk2fpqyvcmC89LD956KclmJHHSVbXmR8 g6Uw5LdL40GNrU6Q7kvJGzrEKoaG/FqioSfh9EukwHXy3pM17i1f+sq1V9N+eCParIVs foeGLz3US1PJhWzl68oxNAiaPlzlpq6TEBbrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hdrupInEjwHUQHwcurBVHs/P4V2R+zhfOxEo6S7NI0k=; b=FZ9SSEsodkjKmHFJ5jNaP6dyIPtoqr787L0h+hkJC2HzKLcxyghnCVXXM2DJQaEqgf 77xVZpoMbofmVm4XhW5ZQLYs9S8Q/bx+q9h4/3IKddIdtirII4n1PcAZgbxqijEjhzO9 eg57raNe7SxGxmO+qUdibVOUd4bZVDUQrrjCh/AL9q66JbbmVPR7LvkTxJX6xO82BOw4 YpJ/k+RzmTLxhoWkqsVrukuhCE+S0bcFBy5qo4uH13m79NUgrEIX0MOi42lnf0mB7gXj InO6kPh/OMAn9bME83uAUZJJqGvhxuaDua0sppeXqgXFgFOxKBMR8d6QjV817nDyBw/I KsHQ== X-Gm-Message-State: AOAM531JOX9AoL3//pYS7Jgv4LWbEQ7b/b+A8bVWsQ3U5cdPxFER3KdS 34J0vJsSyx8IBztRH5kXCXa2i+DQ5j75nwE4O9G729dF+kM= X-Google-Smtp-Source: ABdhPJxQB1paBpZWtMDAAHQjlgdnPnvKMJ2TgP5OMG0kPW52djKeqpMPH133qGw8RYnvCcLHvgopYvJg/vq9vObWbec= X-Received: by 2002:ab0:3390:: with SMTP id y16mr4265777uap.58.1593216066822; Fri, 26 Jun 2020 17:01:06 -0700 (PDT) MIME-Version: 1.0 References: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> <600F08CB-490A-477E-B92F-AFDA8E1F0B69@sn3rd.com> In-Reply-To: <600F08CB-490A-477E-B92F-AFDA8E1F0B69@sn3rd.com> From: Nick Sullivan Date: Fri, 26 Jun 2020 17:00:50 -0700 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000b6dec705a90585e1" Archived-At: Subject: Re: [TLS] Closing WGLC (was Re: 3rd WGLC for draft-ietf-tls-exported-authenticators) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:01:20 -0000 --000000000000b6dec705a90585e1 Content-Type: text/plain; charset="UTF-8" TLSWG and Chairs, I've submitted draft -13 with the appropriate changes. Best, Nick On Tue, Jun 16, 2020 at 10:23 AM Sean Turner wrote: > Hi! > > This message closes out the 3rd WGLC for > draft-ietf-tls-exported-authenticators. I have created GH issues for the > two issues raised during WGLC: > https://github.com/tlswg/tls-exported-authenticator/issues/62 > https://github.com/tlswg/tls-exported-authenticator/issues/63 > Once addressed, and assuming the changes are not large, we will progress > this draft towards our AD. > > I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D needed > awaiting resolution of the two issues. > > spt (for the chairs) > > > On Jun 5, 2020, at 07:29, Watson Ladd wrote: > > > > On Thu, Jun 4, 2020 at 9:48 PM Sean Turner wrote: > >> > >> Another reminder ... > >> > >>> On May 22, 2020, at 09:23, Sean Turner wrote: > >>> > >>> This is the 3rd WGLC for "Exported Authenticators in TLS" draft > available at > https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. > The secdir review during IETF LC raised some issues and as a result there > have been a couple of new versions. Please respond to the list with any > comments by 2359 UTC on 8 June 2020. > > > > I've implemented earlier drafts. I do have a concern with the > > validate API as presented in the draft: it treats empty authenticators > > as valid, and then returns the identity as a certificate chain that > > must be validated by the application. Similar APIs have lead to easily > > foreseeable pwnage. Instead I would recommend the validate API carry > > out X509 validation against a trust store or validation function and > > treat the empty authenticator as invalid. That way someone has to > > think before not checking the certificate returned. > > > > Sincerely, > > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b6dec705a90585e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLSWG and Chairs,

I've submitted dr= aft -13 with the appropriate changes.

Best,
<= div>Nick

On Tue, Jun 16, 2020 at 10:23 AM Sean Turner <sean@sn3rd.com> wrote:
Hi!

This message closes out the 3rd WGLC for draft-ietf-tls-exported-authentica= tors. I have created GH issues for the two issues raised during WGLC:
https://github.com/tlswg/tls-exported-a= uthenticator/issues/62
https://github.com/tlswg/tls-exported-a= uthenticator/issues/63
Once addressed, and assuming the changes are not large, we will progress th= is draft towards our AD.

I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D needed = awaiting resolution of the two issues.

spt (for the chairs)

> On Jun 5, 2020, at 07:29, Watson Ladd <watsonbladd@gmail.com> wrote:
>
> On Thu, Jun 4, 2020 at 9:48 PM Sean Turner <sean@sn3rd.com> wrote:
>>
>> Another reminder ...
>>
>>> On May 22, 2020, at 09:23, Sean Turner <sean@sn3rd.com> wrote:
>>>
>>> This is the 3rd WGLC for "Exported Authenticators in TLS&= quot; draft available at http= s://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. Th= e secdir review during IETF LC raised some issues and as a result there hav= e been a couple of new versions. Please respond to the list with any commen= ts by 2359 UTC on 8 June 2020.
>
> I've implemented earlier drafts. I do have a concern with the
> validate API as presented in the draft: it treats empty authenticators=
> as valid, and then returns the identity as a certificate chain that > must be validated by the application. Similar APIs have lead to easily=
> foreseeable pwnage. Instead I would recommend the validate API carry > out X509 validation against a trust store or validation function and > treat the empty authenticator as invalid. That way someone has to
> think before not checking the certificate returned.
>
> Sincerely,
> Watson Ladd

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b6dec705a90585e1-- From nobody Fri Jun 26 17:22:24 2020 Return-Path: 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 8CBFC3A09B9 for ; Fri, 26 Jun 2020 17:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cJGtRoFbgmCB for ; Fri, 26 Jun 2020 17:22:17 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CE53A09A5 for ; Fri, 26 Jun 2020 17:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4083D389AC; Fri, 26 Jun 2020 20:19:32 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WZ8C9k0gTxiG; Fri, 26 Jun 2020 20:19:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7FF38389A5; Fri, 26 Jun 2020 20:19:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0267D1D3; Fri, 26 Jun 2020 20:22:15 -0400 (EDT) From: Michael Richardson To: "Salz\, Rich" , Nico Williams , Brian Campbell , "ietf-http-wg\@w3.org" , "tls\@ietf.org" In-Reply-To: References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:22:23 -0000 --=-=-= Content-Type: text/plain Salz, Rich wrote: >> What has been pointed out is that TLS can renegotiate client authentication. > Not in TLS 1.3. And with TLS 1.0 and TLS 1.1 on their way out the door ... okay, I thought that this was brought up as an issue as we move towards universal deployment of TLS 1.3. If that's not a concern, then it makes the whole problem. I guess I misunderstood the discussion. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72kTYACgkQgItw+93Q 3WUy4gf9FeJOT0Y7rFNVWq0QKdk6o4+IDyxPloQQ7Lg397W61ZG42umgi5iM7byX 3yIC76n5BkSareo/GmqX6c4VLksyGrF2XTJorqxEEaBZ9rcEcdfVWn1gFHWio3IM wfOCtCWZSQGOMegeqTUjrTx0GCiv2KRiQCZ6bbYt+p4aXD2EjJX7TfNn4aO6/K8B wVnhGhfI8oVxq4bxOt7+tQTzv8uJGkWdsQ6LPJeyjybqFkQMHdP4Rm231QLOJnK8 v2NO2FYztzRKQRWaMdHlyVK+jNEhPQksjhugoNMLTUCdmtQPMOjUQjz2E54pW2dZ eswmOAnroq+TQOIIIFNNgGAUm5ipkw== =UIWt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 17:28:26 2020 Return-Path: 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 335E53A08F3 for ; Fri, 26 Jun 2020 17:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.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 cLIUemtA_m47 for ; Fri, 26 Jun 2020 17:28:23 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E813A08ED for ; Fri, 26 Jun 2020 17:28:22 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id z63so10454876qkb.8 for ; Fri, 26 Jun 2020 17:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=KeV3fohDubHey7KL5pV7n6jrA5rBQvJmkh/E26xckrA=; b=UqhpKwFrju/Wc70FIT6dPfv9erxNFN9I9nyQ8zoJU+PmQMUtOe1K9V2zBwKFr1pnv0 khFZMT2z53f+US7UIiYzSQIcqqFeV8NeHgRuVlsZNL1D6IYwssLJzQMP21NfOVFoQ01C m2j0Yjcp24aEalkbGqTxYc6JI8yGVF4I1yOA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=KeV3fohDubHey7KL5pV7n6jrA5rBQvJmkh/E26xckrA=; b=Z+fKOpWxssQOtDt1SgH6CXeSjAsEFVIlkd8iG687gALrD1znM/QKglegX+Tf+gnleX RGyLFoGfXqVU3wW8nXeD0V4CgB0bNfKghI0D50ZHq4PeZG6prUUlDrEa4lVEbs8+gwc7 5SzoaGSRFZ0kuBBQ4O7nkPyA+gLVXPvFORRCxei9KzRZ19+Zx9U+pFnXx6bU2N27c0hL aUz9avwPV69jWzW9SbQ1ppRga8PuUJKLp7R1MHxkYb9gQT3F+XZx7ISgj4S6fz4x6vwR 3udx/FlmcOlQXMBtqll/piUokUfEbfsUNoYe/vHMWIqI5PMb/ViM6Zznfk7Qb04gDVMB Kqtg== X-Gm-Message-State: AOAM530u5VfXw8cPhDPg+tdtUQmSr6y2YrTUthyCcUTkhmeG6qxqjBv3 7tX+rfwnkqn/Ygzr8YJZFWRDePI68jE= X-Google-Smtp-Source: ABdhPJy7D5JVlLWmfDN2RHI+iKvS8z0z2gCo4zK446uWn8iXztV63RnpGBbpmdIeaRbke2fWBSrt2A== X-Received: by 2002:a05:620a:9dd:: with SMTP id y29mr5146562qky.220.1593217701679; Fri, 26 Jun 2020 17:28:21 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id i21sm10553473qke.9.2020.06.26.17.28.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 17:28:20 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 20:28:20 -0400 References: To: TLS List In-Reply-To: Message-Id: <7AC6C26C-3946-4039-89D9-F6742D93C122@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] consensus call: changing cTLS and ECH to standards track 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 00:28:24 -0000 We are going to close these out and request that the authors change the = track on these drafts to standards track. There are multiple = participants who expressed a willingness to implement. I will note that Rich is a bit skeptical, and I can add that to the = Shepherd write-up. spt > On May 21, 2020, at 22:10, Sean Turner wrote: >=20 > It looks like the intended status for both draft-ietf-tls-ctls (aka = cTLS) and draft-ietf-tls-esni (aka ECH) should be changed. It appears = that both should be set to standards track; cTLS is now Informational = and ECH is Experimental. If you object to changing the track for either = of these drafts please send an email to the list stating why by 2359 UTC = on 5 June 2020. >=20 > Cheers, > spt (for the Chairs) From nobody Fri Jun 26 18:46:18 2020 Return-Path: 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 11B6E3A08C0; Fri, 26 Jun 2020 18:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 4wpyGJIExiFm; Fri, 26 Jun 2020 18:46:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 61F2C3A08BE; Fri, 26 Jun 2020 18:46:13 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05R1gHdm018008; Sat, 27 Jun 2020 02:46:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=L1axif0zvy9YHWE4Fv9PYtpdMGW7DoZteOItvOxGVn0=; b=Al7IXOS7YeRSZEt8wT/QSsgC1s3Yly0yE8y5n6oYk14ngI6SwLgRtHI28VLROdg+QuMN pBxkeaZ3lOo44CLielYa6PtUqBJMEFVeVYcSrQs3ByxteeHQ3G0itA0KJ4ah/m0wF7Zm t4N2soMbcO2VKic9bu9aopZbWcBB3skmfGZFs49WO7CisZz+SZLdffOJ4c9g7onFm+WW 6S3xZsY/2vpTKB+hIDdiCUFi/+1/pdU36yfUSp8ekEPsPR4a2uCQ/pvKDfrdQqERD07t MpYvumQ0Oz+GPaa06sdsvOt/itBkc4S53bpPh3zaDkQb4ZhXdTbQ5bmWrqkQurb8Sf7C UA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 31uuu427k1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 02:46:12 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05R1708Q002176; Fri, 26 Jun 2020 21:46:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 31uus8udg4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 21:46:11 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Jun 2020 20:46:11 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 26 Jun 2020 20:46:11 -0500 From: "Salz, Rich" To: Nick Sullivan , "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt Thread-Index: AQHWTBUryUAm2aqF3ECsjTdcKZtgbKjrwg8A Date: Sat, 27 Jun 2020 01:46:10 +0000 Message-ID: <73995F29-4970-4F5A-9D9A-7637C5B86137@akamai.com> References: <159321525091.3808.9987324221405950713@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.32] Content-Type: multipart/alternative; boundary="_000_73995F2949704F5A9D9A7637C5B86137akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_01:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 suspectscore=0 phishscore=0 mlxscore=0 malwarescore=0 mlxlogscore=702 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_01:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 cotscore=-2147483648 adultscore=0 suspectscore=0 bulkscore=0 phishscore=0 priorityscore=1501 clxscore=1011 mlxlogscore=671 malwarescore=0 spamscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270010 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 01:46:16 -0000 --_000_73995F2949704F5A9D9A7637C5B86137akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW55IGNoYW5jZSBvZiBzYW1wbGUgREMsIGtleXMsIGV0Yz8NCg== --_000_73995F2949704F5A9D9A7637C5B86137akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <479C7231108E3246BB8842D03FD8C534@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFueSBjaGFuY2Ugb2Ygc2FtcGxlIERDLCBrZXlzLCBl dGM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_73995F2949704F5A9D9A7637C5B86137akamaicom_-- From nobody Fri Jun 26 18:52:35 2020 Return-Path: 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 6F2A23A08C0; Fri, 26 Jun 2020 18:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 gHUMu_uDkVny; Fri, 26 Jun 2020 18:52:31 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 41FA33A08BE; Fri, 26 Jun 2020 18:52:30 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05R1hZFv017169; Sat, 27 Jun 2020 02:52:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=LDa3BaNHqrhW92ikjCFkO5QpsNtOhH9GTmGGBwp4ug4=; b=hHMpBd/DH9tAWrGwQV7CFe4JHcEmF4woXKsh2jU+vpg/ISC1x3mw5se8Jyrxvgc2pVDM rBgxx4wnVJ+MP6olTI3PlIb1m39f6/0+ku0VabsHeCf9kikYKJW7XPqLxvwBTWq4EOzQ XGPmZ7VGloDjCpFGAycBTVtpJNxUXEQ4Kj7PT3Olek+qKuKiy6LjRlO5BxqGgb9QvejY vVdH7Qfbamr2k3pEI7Bna6oEQlLvpZvdP2UA25WFoTDNB2YnlPxZgDQvXt0GYF4pGqeH /9TPtKAMeWzortKnYWzfFtIs9ohCUPGHioG7tigLTX7miRhxQfX0O5z8WpQ8v6QHdAsL Dw== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 31uutr8vc8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 02:52:30 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05R1o3rC018938; Fri, 26 Jun 2020 21:52:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint8.akamai.com with ESMTP id 31uustkadd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 21:52:29 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Jun 2020 20:52:28 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Fri, 26 Jun 2020 20:52:28 -0500 From: "Salz, Rich" To: "Salz, Rich" , Nick Sullivan , "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt Thread-Index: AQHWTBUryUAm2aqF3ECsjTdcKZtgbKjrwg8AgAABwoA= Date: Sat, 27 Jun 2020 01:52:27 +0000 Message-ID: References: <159321525091.3808.9987324221405950713@ietfa.amsl.com> <73995F29-4970-4F5A-9D9A-7637C5B86137@akamai.com> In-Reply-To: <73995F29-4970-4F5A-9D9A-7637C5B86137@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.32] Content-Type: multipart/alternative; boundary="_000_DE521DD0383F49A6A587674296B7FB50akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_01:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 mlxlogscore=806 suspectscore=0 phishscore=0 mlxscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_01:2020-06-26, 2020-06-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 bulkscore=0 cotscore=-2147483648 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxlogscore=770 clxscore=1015 phishscore=0 mlxscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270010 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-subcerts-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 01:52:34 -0000 --_000_DE521DD0383F49A6A587674296B7FB50akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHVoLCBJIG1lYW4g4oCcdGVzdCB2ZWN0b3JzLuKAnQ0KDQpGcm9tOiAiU2FseiwgUmljaCIgPHJz YWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IEZyaWRheSwgSnVuZSAyNiwg MjAyMCBhdCA5OjQ2IFBNDQpUbzogTmljayBTdWxsaXZhbiA8bmljaz00MGNsb3VkZmxhcmUuY29t QGRtYXJjLmlldGYub3JnPiwgInRsc0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbVExTXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10 bHMtc3ViY2VydHMtMDkudHh0DQoNCkFueSBjaGFuY2Ugb2Ygc2FtcGxlIERDLCBrZXlzLCBldGM/ DQo= --_000_DE521DD0383F49A6A587674296B7FB50akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <051F1CF853E7C34DB0C0CFDCB329C26F@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHVoLCBJIG1lYW4g4oCcdGVzdCB2 ZWN0b3JzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1 b3Q7U2FseiwgUmljaCZxdW90OyAmbHQ7cnNhbHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEp1bmUgMjYsIDIwMjAgYXQgOTo0NiBQTTxi cj4NCjxiPlRvOiA8L2I+TmljayBTdWxsaXZhbiAmbHQ7bmljaz00MGNsb3VkZmxhcmUuY29tQGRt YXJjLmlldGYub3JnJmd0OywgJnF1b3Q7dGxzQGlldGYub3JnJnF1b3Q7ICZsdDt0bHNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVExTXSBGd2Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10bHMtc3ViY2VydHMtMDkudHh0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QW55IGNoYW5jZSBvZiBzYW1wbGUg REMsIGtleXMsIGV0Yz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DE521DD0383F49A6A587674296B7FB50akamaicom_-- From nobody Sat Jun 27 08:01:52 2020 Return-Path: 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 3BA013A0061 for ; Sat, 27 Jun 2020 08:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 N8cC8EwSInzx for ; Sat, 27 Jun 2020 08:01:48 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181263A00E0 for ; Sat, 27 Jun 2020 08:01:47 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jun 2020 08:01:40 -0700 From: Jim Schaad To: "'Salz, Rich'" , 'Michael Richardson' , 'Nico Williams' , 'Brian Campbell' , , References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> In-Reply-To: Date: Sat, 27 Jun 2020 08:01:23 -0700 Message-ID: <029501d64c93$de673ea0$9b35bbe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ4XH2ELPdvzTph3up1K5V04afl9wGu5fEDAiXXixIBYekcaKd9u85A X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 15:01:50 -0000 Ah - Post-Handshake Authentication? > -----Original Message----- > From: TLS On Behalf Of Salz, Rich > Sent: Friday, June 26, 2020 3:41 PM > To: Michael Richardson ; Nico Williams > ; Brian Campbell ; > ietf-http-wg@w3.org; tls@ietf.org > Subject: Re: [TLS] something something certificate --- boiling a small lake > > > What has been pointed out is that TLS can renegotiate client authentication. > > Not in TLS 1.3. And with TLS 1.0 and TLS 1.1 on their way out the door ... > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Jun 27 11:18:35 2020 Return-Path: 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 3463B3A0888 for ; Sat, 27 Jun 2020 11:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 rjq4pTbH5bGe for ; Sat, 27 Jun 2020 11:18:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 9BE2B3A0887 for ; Sat, 27 Jun 2020 11:18:31 -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 05RI7x3O029126; Sat, 27 Jun 2020 19:17:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=mbAG0qbwyFwp7fNAPp3Kxgh6wtaRyb1KESAZb3KPkVY=; b=IC8HqNGNQMdAd7p+hcNjjnIwmkW6jA1iPqeCxQ5NNvBoFmkNzQaS/5G6zPnpg/oFK7kd HXacLnCBv0hIfYsg9HS0a29AIqYa1oadJfkSLF20U+0sc5iChQGhbRMfrseUzNfNJySx yLGuIgdUOwZb7r3yUItB7yC4V43hqAq+M3KsGnXovF/zxZh0/8dT+fBBUn10sSvnchDl k+Y7egMTfojqNmC5bQLFYUvXENbNBcl/XHq69tiC/0MVrTNyhI6pytrrWHc1zYHJz/pN rH6lGflb/uOsVBOciIOMf3uR7yAf1eZ3fIi03OyPVJJvIa2uLbe7X5Oszvvz8V71vor0 yA== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31wwryptbe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 19:17:20 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05RHoxMd023727; Sat, 27 Jun 2020 14:17:20 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint4.akamai.com with ESMTP id 31x1ewtb5p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 14:17:19 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 27 Jun 2020 13:17:19 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Sat, 27 Jun 2020 13:17:18 -0500 From: "Salz, Rich" To: Jim Schaad , 'Michael Richardson' , 'Nico Williams' , "'Brian Campbell'" , "ietf-http-wg@w3.org" , "tls@ietf.org" Thread-Topic: [TLS] something something certificate --- boiling a small lake Thread-Index: AQHWRlncfXVqtw/tUEKYTRGg9YBW66jqW58AgAF+HID//8AQgIABVPiA///zrYA= Date: Sat, 27 Jun 2020 18:17:18 +0000 Message-ID: <357CB6BC-AF19-4121-896F-1BD46B570E25@akamai.com> References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> <029501d64c93$de673ea0$9b35bbe0$@augustcellars.com> In-Reply-To: <029501d64c93$de673ea0$9b35bbe0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.24] Content-Type: text/plain; charset="utf-8" Content-ID: <2D527B9ACF482B4B90947F7AC1AAD0CD@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-27_06:2020-06-26, 2020-06-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=729 suspectscore=0 malwarescore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_06:2020-06-26, 2020-06-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 impostorscore=0 phishscore=0 adultscore=0 priorityscore=1501 clxscore=1015 bulkscore=0 mlxlogscore=689 mlxscore=0 suspectscore=0 malwarescore=0 cotscore=-2147483648 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270132 Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 18:18:33 -0000 PiAgICBBaCAtIFBvc3QtSGFuZHNoYWtlIEF1dGhlbnRpY2F0aW9uPw0KDQpZZWFoLCB0aGF0LiAg DQoNCg0K From nobody Sat Jun 27 15:50:46 2020 Return-Path: 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 C37323A00C9 for ; Sat, 27 Jun 2020 15:50:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 (1024-bit key) header.d=cryptonector.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 7b3uMzNY76XI for ; Sat, 27 Jun 2020 15:50:43 -0700 (PDT) Received: from blue.elm.relay.mailchannels.net (blue.elm.relay.mailchannels.net [23.83.212.20]) (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 7DEB43A00C4 for ; Sat, 27 Jun 2020 15:50:43 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5DA5734045A; Sat, 27 Jun 2020 22:50:42 +0000 (UTC) Received: from pdx1-sub0-mail-a62.g.dreamhost.com (100-96-5-28.trex.outbound.svc.cluster.local [100.96.5.28]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 042A4340D7B; Sat, 27 Jun 2020 22:50:42 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a62.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Sat, 27 Jun 2020 22:50:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Madly-Language: 73cb1a8a50045ec5_1593298242160_1945893292 X-MC-Loop-Signature: 1593298242160:389371264 X-MC-Ingress-Time: 1593298242160 Received: from pdx1-sub0-mail-a62.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTP id 864387FFD0; Sat, 27 Jun 2020 15:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=d19dMpW4cH8jqI 4arf1EuFyw1NM=; b=jqciVGgkTW4hglH6cUXZjT9OaUumoe2zQqfQrZGm+ijB12 cfwocQ/e3aoaXKwRnyGDo1+JjQBwJi7zJDltVHoDzVvxGPk5MpEO7WsFXwOqgacu J7y8Z+WY+FsRevaMDUGHaRfD86sibaH4ppyxwN6DPmkDfl1keOgkAL5qk3d2c= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 448DF7FFBC; Sat, 27 Jun 2020 15:50:37 -0700 (PDT) Date: Sat, 27 Jun 2020 17:50:35 -0500 X-DH-BACKEND: pdx1-sub0-mail-a62 From: Nico Williams To: "Salz, Rich" Cc: Jim Schaad , 'Michael Richardson' , 'Brian Campbell' , "ietf-http-wg@w3.org" , "tls@ietf.org" Message-ID: <20200627204419.GC3100@localhost> References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> <029501d64c93$de673ea0$9b35bbe0$@augustcellars.com> <357CB6BC-AF19-4121-896F-1BD46B570E25@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <357CB6BC-AF19-4121-896F-1BD46B570E25@akamai.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgedgudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:50:45 -0000 On Sat, Jun 27, 2020 at 06:17:18PM +0000, Salz, Rich wrote: > > Ah - Post-Handshake Authentication? > > Yeah, that. There's no limit to how many of those there can be, correct? From nobody Sat Jun 27 16:16:21 2020 Return-Path: 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 51A343A0822 for ; Sat, 27 Jun 2020 16:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EXPVeA26Ys6o for ; Sat, 27 Jun 2020 16:16:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D6E3A0821 for ; Sat, 27 Jun 2020 16:16:18 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Jun 2020 16:16:12 -0700 From: Jim Schaad To: 'Nico Williams' , "'Salz, Rich'" CC: 'Michael Richardson' , 'Brian Campbell' , , References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost> <20929.1593210591@localhost> <029501d64c93$de673ea0$9b35bbe0$@augustcellars.com> <357CB6BC-AF19-4121-896F-1BD46B570E25@akamai.com> <20200627204419.GC3100@localhost> In-Reply-To: <20200627204419.GC3100@localhost> Date: Sat, 27 Jun 2020 16:16:11 -0700 Message-ID: <02d001d64cd8$f3d9c330$db8d4990$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ4XH2ELPdvzTph3up1K5V04afl9wGu5fEDAiXXixIBYekcaAIuF2QpAsANDkUBk3frE6dLNp+w X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] something something certificate --- boiling a small lake 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 23:16:20 -0000 > -----Original Message----- > From: Nico Williams > Sent: Saturday, June 27, 2020 3:51 PM > To: Salz, Rich > Cc: Jim Schaad ; 'Michael Richardson' > ; 'Brian Campbell' ; > ietf-http-wg@w3.org; tls@ietf.org > Subject: Re: [TLS] something something certificate --- boiling a small lake > > On Sat, Jun 27, 2020 at 06:17:18PM +0000, Salz, Rich wrote: > > > Ah - Post-Handshake Authentication? > > > > Yeah, that. > > There's no limit to how many of those there can be, correct? As far as I know there is no limit. There are going to be a large number of arguments about what it means. Jim From nobody Sun Jun 28 00:32:55 2020 Return-Path: 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 434E33A0BE6 for ; Sun, 28 Jun 2020 00:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=TyyPre/e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=goD6laLF 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 rdvvxxrQZqY7 for ; Sun, 28 Jun 2020 00:32:39 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D483A0BD7 for ; Sun, 28 Jun 2020 00:32:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C937E5C0090 for ; Sun, 28 Jun 2020 03:32:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 28 Jun 2020 03:32:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=oAsw04PceVmtoKjHcgyp+xwvlEynVfTTV4zIrVd5BHs=; b=TyyPre/e llzAQaYwfZSrDorQZ9aa3gR+CopYdBzRPYS/39Zx8X3hUlrbSAikWeXEQ5VZLy11 v33jXOXi0sUjhi344iHSH5u3RXFeI+CbuTuQX3wenM7T3LhjkYYPNUSiodMFQTf1 WfZKfb8sn5XVV3oWjg6oS3oC2ojTbTv4oubXuzm3DDc+9lD3tsGTM0hfqk6y4jLM v7HAA+UcsxXnSPGn9q05sEA/iLbZqWONSMCqhexxYNARGXuJI8IOW0FL/Ztvr83L uKR+iNGCt8QHa9WWaCcTjGmIjXBH3AmnSrmESoLHqNWyDoSpkgPo8xD6S0fArnQy PWr94qlZq3szLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=oAsw04PceVmtoKjHcgyp+xwvlEynV fTTV4zIrVd5BHs=; b=goD6laLFCYMn3Xuepym+b2jeGqOSHvyxsp/8+uPqpK5of zYhiCEO3Z1mXuXI1UoLL2LZStyYN5kQpGq77XPQMRAXLR4ECj2sCVhmp7ZZu7u6w A/8BQynYsZ6QfbOFC98u/T5ZI4vrqCWMLRL6DowHDwwaLi5wbb6zWdGmsIMjrqVZ bGL656zOX3f01jbS8Pm3XL3yBGmBpYBumY1G1VZQe1ZTl80Fv3x+T231ihZLR3x+ 3jLXxalcQKeGcz5uOnWyxrnIiXmpgh3cPpIJjTxnlwks080LNGOJQh3f6a1ODjES pHpyypldHTbM+Y1aFURgFpA2agc5j8X79M7KzqScw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelhedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheegrdefrddvvd eknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59.internal.cloudapp.net (unknown [52.254.3.228]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D0D03067AE1 for ; Sun, 28 Jun 2020 03:32:38 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7764968721226939140==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200628073238.8D0D03067AE1@mailuser.nyi.internal> Date: Sun, 28 Jun 2020 03:32:38 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 07:32:53 -0000 --===============7764968721226939140== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC3) 1 issues received 3 new comments: - #248 Decryption failure guidance could be more detailed for trial decry= ption (3 by chris-wood, ekr, raycoll) https://github.com/tlswg/draft-ietf-tls-esni/issues/248=20 1 issues closed: - Decryption failure guidance could be more detailed for trial decryption= https://github.com/tlswg/draft-ietf-tls-esni/issues/248=20 * tlswg/tls-subcerts (+0/-7/=F0=9F=92=AC7) 6 issues received 7 new comments: - #70 [WGLC] Nits (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/70=20 - #69 [WGLC] Note problems with DCs having lifetimes matching issuing cer= tificates (2 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/69=20 - #68 [WGLC] Address client clock skew (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/68=20 - #67 [WGLC] Clarify extension vs EKU usage (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/67=20 - #66 [WGLC] Clarify compromise text (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/66=20 - #65 [WGLC] Private vs secret key (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/65=20 7 issues closed: - [WGLC] Address client clock skew https://github.com/tlswg/tls-subcerts/= issues/68=20 - There is something wrong with the formatting of the numbered list in Se= ction 4.1.3. https://github.com/tlswg/tls-subcerts/issues/71=20 - [WGLC] Private vs secret key https://github.com/tlswg/tls-subcerts/issu= es/65=20 - [WGLC] Clarify extension vs EKU usage https://github.com/tlswg/tls-subc= erts/issues/67=20 - [WGLC] Note problems with DCs having lifetimes matching issuing certifi= cates https://github.com/tlswg/tls-subcerts/issues/69=20 - [WGLC] Clarify compromise text https://github.com/tlswg/tls-subcerts/is= sues/66=20 - [WGLC] Nits https://github.com/tlswg/tls-subcerts/issues/70=20 * tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #62 WGLC Issue: Russ (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/issues/62=20 1 issues closed: - WGLC Issue: Russ https://github.com/tlswg/tls-exported-authenticator/is= sues/62=20 Pull requests ------------- * tlswg/draft-ietf-tls-md5-sha1-deprecate (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - added IANA considerations (by jsalowey) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7=20 * tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Move to Standards track. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/249=20 1 pull requests merged: - Move to Standards track. https://github.com/tlswg/draft-ietf-tls-esni/pull/249=20 * tlswg/dtls13-spec (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - ROBUST: ePrint publication, typo fixes https://github.com/tlswg/dtls13-spec/pull/152=20 * tlswg/tls-subcerts (+4/-4/=F0=9F=92=AC1) 4 pull requests submitted: - Add sentence about EKUs. (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/76=20 - Secret to private (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/75=20 - Nick/69 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/74=20 - Address #68, #71 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/73=20 1 pull requests received 1 new comments: - #74 Nick/69 (1 by chris-wood) https://github.com/tlswg/tls-subcerts/pull/74=20 4 pull requests merged: - Address #68, #71 https://github.com/tlswg/tls-subcerts/pull/73=20 - Nick/69 https://github.com/tlswg/tls-subcerts/pull/74=20 - Secret to private https://github.com/tlswg/tls-subcerts/pull/75=20 - Add sentence about EKUs. https://github.com/tlswg/tls-subcerts/pull/76=20 * tlswg/tls-exported-authenticator (+2/-2/=F0=9F=92=AC1) 2 pull requests submitted: - Modify extension support text for clarity. (by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/65=20 - Address #63 (by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/64=20 1 pull requests received 1 new comments: - #64 Address #63 (1 by wbl) https://github.com/tlswg/tls-exported-authenticator/pull/64=20 2 pull requests merged: - Address #63 https://github.com/tlswg/tls-exported-authenticator/pull/64=20 - Modify extension support text for clarity. https://github.com/tlswg/tls-exported-authenticator/pull/65=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============7764968721226939140== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday June 28, 2020

Issues

tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC3)

1 issues received 3 new comments:

1 issues closed:

tlswg/tls-subcerts (+0/-7/=F0=9F=92=AC7)

6 issues received 7 new comments:

7 issues closed:

tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC1)

1 issues received 1 new comments:

1 issues closed:

Pull requests

tlswg/draft-ietf-tls-md5-sha1-deprecate (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

tlswg/dtls13-spec (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

tlswg/tls-subcerts (+4/-4/=F0=9F=92=AC1)

4 pull requests submitted:

1 pull requests received 1 new comments:

4 pull requests merged:

tlswg/tls-exported-authenticator (+2/-2/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============7764968721226939140==-- From nobody Mon Jun 29 08:59:15 2020 Return-Path: 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 C71EA3A03FF for ; Mon, 29 Jun 2020 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=salowey-net.20150623.gappssmtp.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 7UGd6fSKWjGZ for ; Mon, 29 Jun 2020 08:59:12 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E723A03F6 for ; Mon, 29 Jun 2020 08:59:12 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id k18so15685120qke.4 for ; Mon, 29 Jun 2020 08:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2+QIyI1X2fKboSZO+Fcc686Mr121wWJNuQ1qWe/PRy4=; b=TWrkVdT32T5GiVhuW48VCj3NSJOtxBrVxKsytyHT291FAmHmKrQYeZxVOMlR9gc7a+ HOo3Tp4l4bQrCzyR0zav4vzho8Z/4Ai85zZSOd3+X7xXsH12tqfULBKPC3fCtcWhzUE0 J6URJ72/9W88b5aOwceTWpnoNbprwQgAYjIc3567CzVywvzZrhHJNbt5eSN6glD+LgY4 /PGyN7bA2DCgVxiD4oFNiKN7Y3LVYZHNPqlIcmO3LYsTefhMq5JxZUVcbs8GQSkvJzyl 7SV0By/hlUEgJie5d1+kG4kii9LrazkOguV+AzRRaMDkqO2TNusYE2fnRvd4GarpOdy6 uBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2+QIyI1X2fKboSZO+Fcc686Mr121wWJNuQ1qWe/PRy4=; b=CBIZgdktXp5ZjrDIutR/VcjqqRLQY6tuH4Lhx7VeLeRvKPS+4p9m4Vq8UADZp9h8Xs nATDENG/SVDgpX24rUD9yVLxt/GmgZ3LZGA89LjfHaVfuDQ3bz31ADXkb4B1UHjPUOJu AnEf4ywSBSvOd4/ip7GO799UCpidEeuGbyPtrXWCg8mDm6ZQ9k87ZRQT3uO9fSkzkPgg P3MLwcXIJN6dlIZ+47St5+Vccjbl/7QkgYLsrERLNg9WHjtJO99lfPsIudYUHo6oIR4j K2+eGx6XghW3mCGlMNAzUpf5NZqH2zPhcmTui4EHWLGtj4FufZNlTJmHsJYGWw1BVxl5 7r+A== X-Gm-Message-State: AOAM531fcgYAn2n0kc5UisuzpzMZ6P+s9QC03/miJwefd7TAOPDhtk9w qwNZBqziJmIaLXJAXdbqsSOW0To2Ir5VxTxI/SrSIaNZ1Qc= X-Google-Smtp-Source: ABdhPJycZ2skP46eTY+i4TCH6/aoJSibYfcRQOghGQXitwIQSRCp7C7LN3ZX7vj+HVET/MKO0JEdPdSydDE3/zxRHog= X-Received: by 2002:a05:620a:1654:: with SMTP id c20mr9178100qko.138.1593446350945; Mon, 29 Jun 2020 08:59:10 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Mon, 29 Jun 2020 08:59:00 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000b7960b05a93b23ce" Archived-At: Subject: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 15:59:14 -0000 --000000000000b7960b05a93b23ce Content-Type: text/plain; charset="UTF-8" This is the second working group last call for Delegated Credentials for TLS. The latest draft can be found here: https://tools.ietf.org/html/draft-ietf-tls-subcerts-09. There have been 2 revisions since the last review. Draft 8 contains changes that were not committed in time for draft 7 and draft 9 contains revisions from the previous WGLC. Links to the Diffs between the draft 9 and draft 7 can be found at the end of this message. Please focus your review on the changes between draft 7 and draft 9. Please send your comments to the list by July 13, 2020. Thanks, Sean and Joe [Inline Diff] https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt [Side-by-side Diff] https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt --000000000000b7960b05a93b23ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the second working group last call for=C2=A0D= elegated Credentials for TLS.=C2=A0 The latest draft can be found here:=C2= =A0https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.=C2= =A0 There have been 2 revisions since the last review.=C2=A0 Draft 8 contai= ns changes that were not committed=C2=A0in time for draft 7 and draft 9 con= tains revisions from the previous WGLC.=C2=A0 Links to the Diffs between th= e draft 9 and draft 7 can be found at the end of this message.=C2=A0 =C2=A0= Please focus your review on the changes between draft 7 and draft 9.=C2=A0 = Please send your comments to the list by July 13, 2020.=C2=A0=C2=A0

Thanks,

Sean and Joe

[Side-by-side Diff]=C2=A0<= a href=3D"https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09.= txt&url1=3Ddraft-ietf-tls-subcerts-07.txt" target=3D"_blank">https://to= ols.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09.txt&url1=3Ddraft= -ietf-tls-subcerts-07.txt

--000000000000b7960b05a93b23ce-- From nobody Mon Jun 29 09:00:53 2020 Return-Path: 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 2FA2E3A076C for ; Mon, 29 Jun 2020 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 7w41FVNh3YKU for ; Mon, 29 Jun 2020 09:00:48 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 79D913A09BC for ; Mon, 29 Jun 2020 09:00:23 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05TFmkIc007029; Mon, 29 Jun 2020 17:00:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=oEmjc3PxU6sXg2FkVOZeTz+Kkhww4Bxin25P8iqmOT4=; b=P/coD4rkk6sN66TGkQ/RaC5G8PJP+h0yGfVaWYaSCufaT86nBzj+WcerW7aa3keZmLJ8 F9fxNsVj3Z+79s+cWYCtzS++Vk0bHrFbA5cXEvSmTxGl8TRgCxIwU5rYtfWlYxxhKpHY tTLVPR4/56K+pdsWU83edJU9dELIuEQXOwDpOyvaMOtdbZT7xtyAiNLuy4n7daCDDXET 18RbNm/GYGVXjTXh+n1s3/3WMjs1YyFvelBVpO3dzy1ClrHhJN/vgdhOVMlqAKxVitry 7Qq0HmsFOsP30ZoInXvKekgJmxMQbmHf9TFFVMQq0idRqJm/szc0vIJAINSMn2F3Xf5+ jg== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 31wwnc5vvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2020 17:00:22 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05TFaLUd012497; Mon, 29 Jun 2020 12:00:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 31x1ewvatp-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2020 12:00:21 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 11:00:20 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Mon, 29 Jun 2020 11:00:19 -0500 From: "Salz, Rich" To: Joseph Salowey , "" Thread-Topic: [TLS] 2nd WGLC for Delegated Credentials for TLS Thread-Index: AQHWTi5HKkj7iioHfEKS5uyLURUfD6jv0SsA Date: Mon, 29 Jun 2020 16:00:18 +0000 Message-ID: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.32] Content-Type: multipart/alternative; boundary="_000_31B75BDB8E6740C5AF704EAA9BC2E065akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-29_15:2020-06-29, 2020-06-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=777 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006290104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-29_15:2020-06-29, 2020-06-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=0 mlxscore=0 mlxlogscore=739 priorityscore=1501 phishscore=0 spamscore=0 lowpriorityscore=0 cotscore=-2147483648 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006290105 Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 16:00:52 -0000 --_000_31B75BDB8E6740C5AF704EAA9BC2E065akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgc3RpbGwgbGlrZSB0byBzZWUgdGVzdCB2ZWN0b3JzLg0K --_000_31B75BDB8E6740C5AF704EAA9BC2E065akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3A911B0FA060634A807F4756D2C3E3D1@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SeKAmWQgc3RpbGwgbGlrZSB0byBzZWUgdGVzdCB2ZWN0b3JzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_31B75BDB8E6740C5AF704EAA9BC2E065akamaicom_-- From nobody Mon Jun 29 14:33:44 2020 Return-Path: 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 617493A0D62 for ; Mon, 29 Jun 2020 14:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IFmYX5oFyFxC for ; Mon, 29 Jun 2020 14:33:42 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E207D3A0D61 for ; Mon, 29 Jun 2020 14:33:41 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id e15so14308443edr.2 for ; Mon, 29 Jun 2020 14:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=Njf4Bn0dovVqyVE2lxyrvxRDROkXafYu7yHKHqE3hjI=; b=b9Kke7SrZNyWjpHW/ztw2eYD76tZ1zjxh1eAR8o5Zn3V5h6UVriD1KCMUQut3OVMnO fLJ1a3VYL1G7LQzIWRK9cfy3TvfLd9QAC2XuNMzbdthmPZ0MgWM6V49TY5qA7i8zPIaL hr4cZ6RvKoVfCMmBgVt/KZk1HKoa1lFH76RZ2BSodf4zVU4RaslDxOaEGuB5/MPTNYGp 9pVJZK8VSy8gxYswdKOkGssTE+kVFPI6YBlOeIs3e3rIKp3P2Tnt3Q28pNuAbS49EksO d/ZtWazUMRtppey9uV2pjvkFjHJNkhgby6FB0ZI0vnSDdh/POS10Szwpgk5wzCH57spO AaCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Njf4Bn0dovVqyVE2lxyrvxRDROkXafYu7yHKHqE3hjI=; b=igYeQW+G6HJxiQgFy8I1z0gg/dSsry04JroCDfFmRJWGw3V+kyyr6VW6qlVC816NDM N/u7RX68YLdsK+g3FVbIr4BiVSBynGQFgTsHyeF9p7+ggm8yiXLQ/2HHTDMiKjGOb0hC iQ0s49xljqDYIJ59+GGxFe///Bg0ZRVpGCk5isdFKMc+zW6Hog8sF5wy03FSlysDxwUv 6Je1QZWRmA0xX6Fc7y9PlAKdN6bBgOGNvhd7cAWGtw0khS6P/El8V/qHuG0mR17u0xSM MiRDhX11Id65ET2KzEwzCH9u0tMrLFQ2gu+mAjCOx2puCU6KLODZk6horfj53FTqfpJU T2Ww== X-Gm-Message-State: AOAM532+l3MGWp8IWRLl1wzZw+7r2bCTeZqwqvu+LNN4yHh20zPQK7RB pMy6INS655z8oxlm8z5qg7rP1Bw0 X-Google-Smtp-Source: ABdhPJxHvwv2LYxWGfcsAh29Uk4m7MUlky2GA0Mfd/zPitlxvVILqK9fwWmej0RWeA4FuyRL8Dod4w== X-Received: by 2002:a50:fd12:: with SMTP id i18mr20176491eds.371.1593466419781; Mon, 29 Jun 2020 14:33:39 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p5sm753814edt.69.2020.06.29.14.33.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 14:33:39 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_650EDCA3-339C-44D3-87F7-6F1B9F086DD6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> Date: Tue, 30 Jun 2020 00:33:37 +0300 To: "" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] Proposed change in TLS-Flags 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 21:33:44 -0000 --Apple-Mail=_650EDCA3-339C-44D3-87F7-6F1B9F086DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi I=E2=80=99ve just submitted the following PR: https://github.com/tlswg/tls-flags/pull/4 = Three changes: It is no longer allowed to send an empty flags extension. If you = don=E2=80=99t support any flags, don=E2=80=99t send the extension. The server is no longer allowed to respond with flag types that the = client didn=E2=80=99t indicate support for first. I=E2=80=99ve split the extension description section into a format = section and a rules section Please comment. Barring any objections, I=E2=80=99ll merge the PR just = before the submission deadline. Yoav --Apple-Mail=_650EDCA3-339C-44D3-87F7-6F1B9F086DD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

I=E2=80=99= ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:
  • It is no longer = allowed to send an empty flags extension.  If you don=E2=80=99t = support any flags, don=E2=80=99t send the extension.
  • The server is no longer allowed to respond with flag types = that the client didn=E2=80=99t indicate support for first.
  • I=E2=80=99ve split the extension description section into a = format section and a rules section

Please comment. Barring any = objections, I=E2=80=99ll merge the PR just before the submission = deadline.

Yoav

= --Apple-Mail=_650EDCA3-339C-44D3-87F7-6F1B9F086DD6-- From nobody Mon Jun 29 17:47:46 2020 Return-Path: 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 0A89E3A0ED9 for ; Mon, 29 Jun 2020 17:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 U9_wPXYQzra6 for ; Mon, 29 Jun 2020 17:47:40 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2055.outbound.protection.outlook.com [40.107.94.55]) (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 B8F0D3A0EDA for ; Mon, 29 Jun 2020 17:47:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R9GWD1x8D9ODn5PdPHoBVqcTKooZvxrmkvJ8/NAQh2lGdgIQKtuxeNQ4wp2WY0Uk1Mq06zzTq9mtBAcJnw/eVtjaxHTWFFcUjoB2hxPgVwXFCc+1L+KVphNWfR0LTwnyfuzTMZmaiR1+ukhzu7MDWVfHS/6CvO0Itv9djU8H1qbjDh9VEoQ9oqnS7+JHRVa+WTA8+bbn4L37DEHL8ftcysydj+0NYqxRYv9aQJ++pkqwdyvHg/K+MB9vhGcr8aKQWFZPAncuvD1R+tkrjGPdBO0E3/thoGXWxKOh/Zx7ZObnGUi8+S/yzMxdcEJeDKbx7hzofwPt4MLnJOmgAhXFeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sw2iygDMFtQMJ5gVXu+RHNGqe+n88UJ1RsIG2Vyoc2U=; b=FnMFAemMmAbYROLe5vG1v6b8ARzjflOBAcc+UeU0+otXH8ii1n6vXPHoRl8nxwD3EGuftfIMpLiF33KvWxDu/GTRJAqEdoSTJx45s3mhmfHlDuNWFns4V8crdkk68N5HQGZy+wDytWzmyPoyGs4g8sVZyKz+8i0wq4jlJ/DmnGdXsepIPfYk4Rs9Ir4C9h3wnQqU6QjjOzqo++Gfs+qyYHVUWJvW3OFiTuuMu29E4gL0OWrrMPSd7nnmez2hOBe4GXHCS64sI4kwcMKDyMNYZtATOb4gaOe+dGoe+qbqWcXMTS/13tmAmcD+IENEzJZ8NZfy3PAbFGjkumiINa2lPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sw2iygDMFtQMJ5gVXu+RHNGqe+n88UJ1RsIG2Vyoc2U=; b=HsLCem4kp/hyQJ2c8zLOS1vLjFAMkh/N/8ac0i8aD6sLyaIjZpvorJc54rGbPHrtvSdR0JCM8E9oUGFjg+2EUcOSktw1ubrDybo2ZCB0ptSmCMVs4FFhBvvLRCBsigmSiJ/IgcDdYI1qtWMOnVMs5Uptl72MHkOBlUhC8gQwh0c= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SA0PR15MB3901.namprd15.prod.outlook.com (2603:10b6:806:8f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Tue, 30 Jun 2020 00:47:36 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%5]) with mapi id 15.20.3131.028; Tue, 30 Jun 2020 00:47:36 +0000 From: Daniel Migault To: "Salz, Rich" , Joseph Salowey , "" Thread-Topic: [TLS] 2nd WGLC for Delegated Credentials for TLS Thread-Index: AQHWTi5Wr1YqfsHMFk6cLyNi9MT+gajvwGgAgAA1zHM= Date: Tue, 30 Jun 2020 00:47:36 +0000 Message-ID: References: , <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> In-Reply-To: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18f5c3e1-4c70-4253-7471-08d81c8f2f15 x-ms-traffictypediagnostic: SA0PR15MB3901: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X6FQHdcumKCDSt/qne2CBFNY4ZcnkBxr8X28sYQmVLnELS8ea/AkEF1/TtTvCg8ZGIzDIIzDwbuLWySK2V4MarP3QzmxFfeCe1Hts9W0Cw5wQP78V/mP4vSZfxnQlPSyFBNPo5kHAndgMtKzwRgPRT+heFkEgw2LlPpDzt4jdixht6lXivd+gQyEahP453lIQKWkhYPklq48Su4K0EJa3998GYc6XFL6cHKJukfsjJrM71LNorzmLDs2jyVVr9Oj0+NKxi5TRYlz2HGfqhY3esp8dXs/gkuT5eJbX6JJ6vn7sEA8NJE+f0DoVMSORewECH4z6JDnX3h2VIFdRv/meP93izU4SdMrbppaIZkZ7O3T01fA7tPCvla0nL2Q0gWc x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(39860400002)(136003)(396003)(376002)(8936002)(44832011)(52536014)(19627405001)(478600001)(30864003)(26005)(186003)(316002)(19627235002)(5660300002)(110136005)(6506007)(53546011)(71200400001)(6486002)(2906002)(33656002)(8676002)(66574015)(86362001)(91956017)(66556008)(9686003)(76116006)(64756008)(66946007)(66446008)(6512007)(66476007)(83380400001)(491001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EwNC7GE5bmoRIVhh4jXWfkAt9n4XUJccJx9DvWVkX6qbDnI1hjqYrFLGKu/mIsMRT1tGWvjHQwGlLLe+naWu/SGO1O28qaD9OaaTkC/gPwEhHzdloKaodhm8kg9W78hZH18ovzck0Cd8WBbQmTJGSCTTwluEEuo4QRXmO/NrT6b9iYSGI78DlxDju/e5X3hUqUnDfKBBH54K+/gk42F+UrNtAgdFEZXuYVQN/kAsa10v2hb/GiLPgXV/cWZv2ggsDgagwZFqZSRl2IUIEVZXMtsjbYYdDBH1RsnGLfreZN1qgExUM1mUvgFGulkTS2iClNAs8GzqwTLJs/NhzwrRexwxc307SdpmOVYuNh6c/zKPL+HF/qzDBi4OXkjaWy3LEsbKhb/nD594SpvJ14DHfonRXf/p6xyRwTaxUGmDvTU635MEiLu4Tn0kRoE0KUsDk/zipGY7yLvJZF7RTl2QQcR05O604a4QjuJPLPQ57Sc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR15MB37855738A57E0192BBE7796CE36E0MW3PR15MB3785namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18f5c3e1-4c70-4253-7471-08d81c8f2f15 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 00:47:36.7138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mVhppy6CUs9kxRrG7Fl9ymIJANfEKaDWv1qbMRkdOukEumOtODTpmzbP65cwBmqBIPB0BlkwcsGLJltH5L17c1KjNsR02XnkV+z4v0WjyX0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR15MB3901 Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 00:47:44 -0000 --_000_MW3PR15MB37855738A57E0192BBE7796CE36E0MW3PR15MB3785namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The draft has a number of nits and errors. Among others: The related work section mentions KEYLESS and subcert being complementary t= hat is KEYLESS can perform the operations associated to the DC and/or those= associated to the cert key. I do not think that is correct. KEYLESS does n= ot support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for= TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was m= entioned during the adoption period and until version 05 that should not ca= use any issues. Technologies only available for TLS 1.2 may be mentioned in the related wor= k section. [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLES= S as it addresses the security concerns of KEYLESS. There are other places where the extensions is mentioned together with TLS = 1.2 that needs to be updated. I also think that test vectors would be good as well as a link to a formal = verification publication (if available). Please see all my comments inline, I hope they help. Yours, Daniel ---- Delegated Credentials for TLS draft-ietf-tls-subcerts-09 [...] 1. Introduction Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446] [RFC5280]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: * Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. * The server operator can only use TLS signature schemes for which the CA will issue credentials. These dependencies cause problems in practice. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. I believe it would be clearer to summarize the problem and link it to the use case. I would propose something around: These dependencies cause problems in practice, the management of key exposure necessarily requires an interaction with the CA. Typically server operators.... However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". >From the text it is unclear why the signature scheme appears to be a constraint as well how it does not opens to some sort of downgrade attacks if left to the operator. 3. Solution Overview [...] 3.1. Rationale Delegated credentials present a better alternative than other delegation mechanisms like proxy certificates [RFC3820] for several reasons: * There is no change needed to certificate validation at the PKI layer. * X.509 semantics are very rich. This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate. For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. * Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the server certificate. Since the certificate path building process is not cryptographically protected, it is possible that a proxy certificate could be bound to another certificate with the same public key, with different X.509 parameters. Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. * Each delegated credential is bound to a specific signature algorithm that may be used to sign the TLS handshake ([RFC8446] Barnes, et al. Expires 28 December 2020 [Page 6] Internet-Draft Delegated Credentials for TLS June 2020 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms. It is not clear to me why there is a "may be used". I suppose it concerns the use of the DC not the algorithm but that was confusing. I also believe that the specific signature algorithm to sign the delegated credential could be part of the rational. 3.2. Related Work Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to client behavior (e.g., a PKCS#11 interface or a remote signing mechanism [KEYLESS]). These mechanisms, however, incur per- transaction latency, since the front-end server has to interact with a back-end server that holds a private key. The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency. The figure below compares the message flows for these two mechanisms with TLS 1.3 [RFC8446]. Remote key signing: Client Front-End Back-End |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | | Delegated credentials: Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | | These two mechanisms can be complementary. A server could use credentials for clients that support them, while using [KEYLESS] to support legacy clients. I believe that this sentence does not show any complementary as subcert and KEYLESS are targeting different version of TLS, so they can hardly be complementary. However (and luckily) LURK provides an extension for TLS 1.3 [draft-mglt-lurk-tls13] which enable a complementary use of these mechanisms these mechanisms. I believe that would be good to indicate the reason they complement each other which is that LURK protects the credentials for its operations. These operations could be performed in the scope of subcert or TLS 1.3. Note also that in a related section it also worth mentioning that credentials may be managed in different ways and KEYLESS represents an valuable way to protect and manage these credentials in TLS 1.2. However, KEYLESS is known to presents some vulnerabilities (PFS, signing oracle) so the protection remains limited while the LURK extension for TLS 1.2 [draft-mglt-lurk-tls12] addressed these issues and as a result should provide a better protection. The private key for a delegated credential can be used in place of a certificate private key, so it is important that the Front-End and Back-End are parties that have a trusted relationship. Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Managment Environment (ACME) Management [RFC8555], reduces the risk of key compromise, but has several limitations. Specifically, it introduces an operationally-critical dependency on an external party. It also limits the types of Barnes, et al. Expires 28 December 2020 [Page 7] Internet-Draft Delegated Credentials for TLS June 2020 algorithms supported for TLS authentication to those the CA is willing to issue a certificate for. Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning delegated credentials. 4. Delegated Credentials While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is valid to use them to issue other signed objects as long as the certificate contains the digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a new signed object format that would encode only the semantics that are needed for this application. The credential has the following structure: struct { uint32 valid_time; SignatureScheme expected_cert_verify_algorithm; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; } Credential; valid_time: Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. This MUST NOT exceed 7 days. I believe the behavior of the "verifying peer" should also be specified maybe with a reference. expected_cert_verify_algorithm: The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in [RFC8446]. This is expected to be the same as CertificateVerify.algorithm sent by the server. Only signature algorithms allowed for use in CertificateVerify messages are allowed. When using RSA, the public key MUST NOT use the rsaEncryption OID, as a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. It is unclear whether the expected_cert_verify_algorithm and CertificateVerify.algorithm needs to be checked and what needs to be done in case of mismatch (with the RSA caveat). I believe that should be clarified. ASN1_subjectPublicKeyInfo: The credential's public key, a DER- encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. The delegated credential has the following structure: struct { Credential cred; SignatureScheme algorithm; opaque signature<0..2^16-1>; } DelegatedCredential; algorithm: The signature algorithm used to verify DelegatedCredential.signature. I am wondering if any checks should be performed with the CertificateVerify.algorithm or if any algorithm would be acceptable. Unless I am missing something it seems a weak algorithm can be used - assuming the registry contains such weak algorithms. Barnes, et al. Expires 28 December 2020 [Page 8] Internet-Draft Delegated Credentials for TLS June 2020 signature: The delegation, a signature that binds the credential to the end-entity certificate's public key as specified below. The signature scheme is specified by DelegatedCredential.algorithm. [...] 4.1.1. Server Authentication A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList: Barnes, et al. Expires 28 December 2020 [Page 9] Internet-Draft Delegated Credentials for TLS June 2020 struct { SignatureScheme supported_signature_algorithm<2..2^16-2>; } SignatureSchemeList; If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential. The server MUST ignore the extension unless TLS 1.3 or a later version is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. I am wondering what would prevent any downgrade attacks if the SignatureSchemeList and signature_algorithms have two different sets of lists. My current understanding is that these extensions are handled independently, but I might be missing something. I am wondering if that would be appropriated to specify the signature of the CertificateVerify depending on the presence of the delegated credential - I mean the key used to generate it. [...] 4.1.3. Validating a Delegated Credential On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity certificate to the peer's expected identity. It also takes the following steps: 1. Verify that the current time is within the validity interval of the credential. This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. 2. Verify that the credential's remaining validity time is no more than the maximum validity period. This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. 3. Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. I am wondering if a reference to specify what allowed would not be needed unless it means advertised in the extension. 4. Verify that the end-entity certificate satisfies the conditions in Section 4.2. 5. Use the public key in the peer's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm. If one or more of these checks fail, then the delegated credential is deemed invalid. Clients and servers that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. If successful, the participant receiving the Certificate message uses the public key in the credential to verify the signature in the peer's CertificateVerify message. [...] 7. Security Considerations [...] 7.6. The Impact of Signature Forgery Attacks When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a mitigation strategy requiring careful implementation of timing resistant countermeasures for preventing these attacks. Experience shows that in practice, server implementations may fail to fully stop these attacks due to the complexity of this mitigation [ROBOT]. For TLS 1.2 servers that support RSA key exchange using a DC-enabled end- entity certificate, a hypothetical signature forgery attack would allow forging a signature over a delegated credential. The forged credential could then be used by the attacker as the equivalent of a man-in-the-middle certificate, valid for 7 days. I do not see the relevance to TLS 1.3. Server operators should therefore minimize the risk of using DC- enabled end-entity certificates where a signature forgery oracle may be present. If possible, server operators may choose to use DC- enabled certificates only for signing credentials, and not for serving non-DC TLS traffic. Furthermore, server operators may use elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field. Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. ________________________________ From: TLS on behalf of Salz, Rich Sent: Monday, June 29, 2020 12:00 PM To: Joseph Salowey ; Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS I=92d still like to see test vectors. --_000_MW3PR15MB37855738A57E0192BBE7796CE36E0MW3PR15MB3785namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi, 

The draft has a number of nits and errors. Among= others: 

The related work section mentions KEYLESS and su= bcert being complementary that is KEYLESS can perform the operations associ= ated to the DC and/or those associated to the cert key. I do not think that= is correct. KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 1.3 [= draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned d= uring the adoption period and until version 05 that should not cause any is= sues. 

Technologies only available for TLS 1.2 may be m= entioned in the related work section.  [draft-mglt-lurk-tls12]&= nbsp;should be mentioned similarly to KEYLESS as it addresses the s= ecurity concerns of KEYLESS. 

There are other places where the extensions is m= entioned together with TLS 1.2 that needs to be updated.  

I also think that test vectors would be good as = well as a link to a formal verification publication (if available).

Please see all my comments inline, I hope they h= elp.

Yours, 
Daniel

----

             =        Delegated Credentials for TLS
             =          draft-ietf-tls-subcerts-09

[...]

1.  Introduction

   Typically, a TLS server uses a cert= ificate provided by some entity
   other than the operator of the serv= er (a "Certification Authority" or
   CA) [RFC8446] [RFC5280].  This= organizational separation makes the
   TLS server operator dependent on th= e CA for some aspects of its
   operations, for example:

   *  Whenever the server operato= r wants to deploy a new certificate, it
      has to interact with the CA= .

   *  The server operator can onl= y use TLS signature schemes for which
      the CA will issue credentia= ls.

   These dependencies cause problems i= n practice.  Server operators
   often deploy TLS termination servic= es in locations such as remote
   data centers or Content Delivery Ne= tworks (CDNs) where it may be
   difficult to detect key compromises= .  Short-lived certificates may be
   used to limit the exposure of keys = in these cases.

<mglt>
I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA. 

Typically server operators....
</mglt>

   However, short-lived certificates n= eed to be renewed more frequently
   than long-lived certificates.  = ;If an external CA is unable to issue a
   certificate in time to replace a de= ployed certificate, the server
   would no longer be able to present = a valid certificate to clients.
   With short-lived certificates, ther= e is a smaller window of time to
   renew a certificates and therefore = a higher risk that an outage at a
   CA will negatively affect the uptim= e of the service.

   To reduce the dependency on externa= l CAs, this document proposes a
   limited delegation mechanism that a= llows a TLS peer to issue its own
   credentials within the scope of a c= ertificate issued by an external
   CA.  These credentials only en= able the recipient of the delegation to
   speak for names that the CA has aut= horized.  For clarity, we will
   refer to the certificate issued by = the CA as a "certificate", or
   "delegation certificate",= and the one issued by the operator as a
   "delegated credential" or= "DC".

<mglt>
From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator.  
</mglt>


3.  Solution Overview

[...]

3.1.  Rationale

   Delegated credentials present a bet= ter alternative than other
   delegation mechanisms like proxy ce= rtificates [RFC3820] for several
   reasons:

   *  There is no change needed t= o certificate validation at the PKI
      layer.

   *  X.509 semantics are very ri= ch.  This can cause unintended
      consequences if a service o= wner creates a proxy certificate where
      the properties differ from = the leaf certificate.  For this reason,
      delegated credentials have = very restricted semantics that should
      not conflict with X.509 sem= antics.

   *  Proxy certificates rely on = the certificate path building process
      to establish a binding betw= een the proxy certificate and the
      server certificate.  S= ince the certificate path building process
      is not cryptographically pr= otected, it is possible that a proxy
      certificate could be bound = to another certificate with the same
      public key, with different = X.509 parameters.  Delegated
      credentials, which rely on = a cryptographic binding between the
      entire certificate and the = delegated credential, cannot.

   *  Each delegated credential i= s bound to a specific signature
      algorithm that may be used = to sign the TLS handshake ([RFC8446]




Barnes, et al.          = ;Expires 28 December 2020               =  [Page 6]

Internet-Draft        Delega= ted Credentials for TLS            June 2020<= br>


      section 4.2.3).  This = prevents them from being used with other,
      perhaps unintended signatur= e algorithms.

<mglt>
It is not clear to me why there is a
"may be used". I suppose it concerns t= he
use of the DC not the algorithm but that
was confusing. 

I also believe that the specific
signature algorithm to sign the
delegated credential could be part of
the rational.  
</mglt>

3.2.  Related Work

   Many of the use cases for delegated= credentials can also be addressed
   using purely server-side mechanisms= that do not require changes to
   client behavior (e.g., a PKCS#11 in= terface or a remote signing
   mechanism [KEYLESS]).  These m= echanisms, however, incur per-
   transaction latency, since the fron= t-end server has to interact with
   a back-end server that holds a priv= ate key.  The mechanism proposed
   in this document allows the delegat= ion to be done off-line, with no
   per-transaction latency.  The = figure below compares the message flows
   for these two mechanisms with TLS 1= .3 [RFC8446].

   Remote key signing:

   Client         =    Front-End            Back-End
     |----ClientHello--->| &nb= sp;                  |
     |<---ServerHello----| &nb= sp;                  |
     |<---Certificate----| &nb= sp;                  |
     |        = ;           |<---remote sign---->|
     |<---CertVerify-----| &nb= sp;                  |
     |        = ;...        |            =        |


   Delegated credentials:

   Client         =    Front-End            Back-End
     |        = ;           |<--DC distribution->|
     |----ClientHello--->| &nb= sp;                  |
     |<---ServerHello----| &nb= sp;                  |
     |<---Certificate----| &nb= sp;                  |
     |<---CertVerify-----| &nb= sp;                  |
     |        = ;...        |            =        |

   These two mechanisms can be complem= entary.  A server could use
   credentials for clients that suppor= t them, while using [KEYLESS] to
   support legacy clients. =

<mglt>
I believe that this sentence does not
show any complementary as subcert and
KEYLESS are targeting different version
of TLS, so they can hardly be
complementary.  However (and luckily)
LURK provides an extension for TLS 1.3
[draft-mglt-lurk-tls13] which enable a
complementary use of these mechanisms
these mechanisms. I believe that would
be good to indicate the reason they
complement each other which is that LURK
protects the credentials for its
operations. These operations could be
performed in the scope of subcert or TLS
1.3.

Note also that in a related section it
also worth mentioning that credentials
may be managed in different ways and
KEYLESS represents an valuable way to
protect and manage these credentials in
TLS 1.2. However, KEYLESS is known to
presents some vulnerabilities (PFS,
signing oracle) so the protection
remains limited while the LURK extension
for TLS 1.2 [draft-mglt-lurk-tls12]
addressed these issues and as a result
should provide a better protection.
</mglt>

The private key for a delegated credential
   can be used in place of a certifica= te private key, so it is important
   that the Front-End and Back-End are= parties that have a trusted
   relationship.


   Use of short-lived certificates wit= h automated certificate issuance,
   e.g., with Automated Certificate Ma= nagment Environment (ACME)
<mglt>
Management 
</mglt>
   [RFC8555], reduces the risk of key = compromise, but has several
   limitations.  Specifically, it= introduces an operationally-critical
   dependency on an external party. &n= bsp;It also limits the types of



Barnes, et al.          = ;Expires 28 December 2020               =  [Page 7]

Internet-Draft        Delega= ted Credentials for TLS            June 2020<= br>


   algorithms supported for TLS authen= tication to those the CA is
   willing to issue a certificate for.=  Nonetheless, existing automated
   issuance APIs like ACME may be usef= ul for provisioning delegated
   credentials.

4.  Delegated Credentials

   While X.509 forbids end-entity cert= ificates from being used as
   issuers for other certificates, it = is valid to use them to issue
   other signed objects as long as the= certificate contains the
   digitalSignature KeyUsage ([RFC5280= ] section 4.2.1.3).  We define a
   new signed object format that would= encode only the semantics that
   are needed for this application. &n= bsp;The credential has the following
   structure:

      struct {
        uint32 valid_time;
        SignatureScheme expe= cted_cert_verify_algorithm;
        opaque ASN1_subjectP= ublicKeyInfo<1..2^24-1>;
      } Credential;

   valid_time:  Time in seconds r= elative to the beginning of the
      delegation certificate's no= tBefore value after which the delegated
      credential is no longer val= id.  This MUST NOT exceed 7 days.
<mglt>
I believe the behavior of the "verifying
peer" should also be specified maybe
with a reference.

</mglt>

   expected_cert_verify_algorithm: &nb= sp;The signature algorithm of the
      credential key pair, where = the type SignatureScheme is as defined
      in [RFC8446].  This is= expected to be the same as
      CertificateVerify.algorithm= sent by the server.  Only signature
      algorithms allowed for use = in CertificateVerify messages are
      allowed.  When using R= SA, the public key MUST NOT use the
      rsaEncryption OID, as a res= ult, the following algorithms are not
      allowed for use with delega= ted credentials: rsa_pss_rsae_sha256,
      rsa_pss_rsae_sha384, rsa_ps= s_rsae_sha512.

<mglt>
It is unclear whether the
expected_cert_verify_algorithm and
CertificateVerify.algorithm needs to be
checked and what needs to be done in
case of mismatch (with the RSA caveat).
I believe that should be clarified.

</mglt>

   ASN1_subjectPublicKeyInfo:  Th= e credential's public key, a DER-
      encoded [X.690] SubjectPubl= icKeyInfo as defined in [RFC5280].

   The delegated credential has the fo= llowing structure:

      struct {
        Credential cred;
        SignatureScheme algo= rithm;
        opaque signature<= 0..2^16-1>;
      } DelegatedCredential;

   algorithm:  The signature algo= rithm used to verify
      DelegatedCredential.signatu= re.

<mglt>
I am wondering if any checks should be
performed with the
CertificateVerify.algorithm or if any
algorithm would be acceptable. Unless I
am missing something it seems a weak
algorithm can be used - assuming the
registry contains such weak algorithms.
</mglt>


Barnes, et al.          = ;Expires 28 December 2020               =  [Page 8]

Internet-Draft        Delega= ted Credentials for TLS            June 2020<= br>


   signature:  The delegation, a = signature that binds the credential to
      the end-entity certificate'= s public key as specified below.  The
      signature scheme is specifi= ed by DelegatedCredential.algorithm.

[...]

4.1.1.  Server Authentication

   A client which supports this specif= ication SHALL send a
   "delegated_credential" ex= tension in its ClientHello.  The body of the
   extension consists of a SignatureSc= hemeList:





Barnes, et al.          = ;Expires 28 December 2020               =  [Page 9]

Internet-Draft        Delega= ted Credentials for TLS            June 2020<= br>


      struct {
        SignatureScheme supp= orted_signature_algorithm<2..2^16-2>;
      } SignatureSchemeList;

   If the client receives a delegated = credential without indicating
   support, then the client MUST abort= with an "unexpected_message"
   alert.

   If the extension is present, the se= rver MAY send a delegated
   credential; if the extension is not= present, the server MUST NOT send
   a delegated credential.  The s= erver MUST ignore the extension unless
   TLS 1.3 or a later version is negot= iated.


   The server MUST send the delegated = credential as an extension in the
   CertificateEntry of its end-entity = certificate; the client SHOULD
   ignore delegated credentials sent a= s extensions to any other
   certificate.

   The expected_cert_verify_algorithm = field MUST be of a type advertised
   by the client in the SignatureSchem= eList and is considered invalid
   otherwise.  Clients that recei= ve invalid delegated credentials MUST
   terminate the connection with an &q= uot;illegal_parameter" alert.

<mglt>
I am wondering what would prevent any
downgrade attacks if the
SignatureSchemeList and
signature_algorithms have two different
sets of lists. My current understanding
is that these extensions are handled
independently, but I might be missing
something.

I am wondering if that would be
appropriated to specify the signature of
the CertificateVerify depending on the
presence of the delegated credential - I
mean the key used to generate it. 

</mglt>

[...]

4.1.3.  Validating a Delegated Credential

   On receiving a delegated credential= and a certificate chain, the peer
   validates the certificate chain and= matches the end-entity
   certificate to the peer's expected = identity.  It also takes the
   following steps:

   1.  Verify that the current ti= me is within the validity interval of
       the credential.  = ;This is done by asserting that the current time
       is no more than the d= elegation certificate's notBefore value plus
       DelegatedCredential.c= red.valid_time.

   2.  Verify that the credential= 's remaining validity time is no more
       than the maximum vali= dity period.  This is done by asserting that
       the current time is n= o more than the delegation certificate's
       notBefore value plus = DelegatedCredential.cred.valid_time plus the
       maximum validity peri= od.

   3.  Verify that expected_cert_= verify_algorithm matches the scheme
       indicated in the peer= 's CertificateVerify message and that the
       algorithm is allowed = for use with delegated credentials.

<mglt>
I am wondering if a reference to specify
what allowed would not be needed unless
it means advertised in the extension.  

</mglt>

   4.  Verify that the end-entity= certificate satisfies the conditions
       in Section 4.2.

   5.  Use the public key in the = peer's end-entity certificate to verify
       the signature of the = credential using the algorithm indicated by
       DelegatedCredential.a= lgorithm.

   If one or more of these checks fail= , then the delegated credential is
   deemed invalid.  Clients and s= ervers that receive invalid delegated
   credentials MUST terminate the conn= ection with an "illegal_parameter"
   alert.  If successful, the par= ticipant receiving the Certificate
   message uses the public key in the = credential to verify the signature
   in the peer's CertificateVerify mes= sage.

[...]

7.  Security Considerations

[...]

7.6.  The Impact of Signature Forgery Attac= ks

   When TLS 1.2 servers support RSA ke= y exchange, they may be vulnerable
   to attacks that allow forging an RS= A signature over an arbitrary
   message [BLEI].  TLS 1.2 [RFC5= 246] (Section 7.4.7.1.) describes a
   mitigation strategy requiring caref= ul implementation of timing
   resistant countermeasures for preve= nting these attacks.  Experience
   shows that in practice, server impl= ementations may fail to fully stop
   these attacks due to the complexity= of this mitigation [ROBOT].  For
   TLS 1.2 servers that support RSA ke= y exchange using a DC-enabled end-
   entity certificate, a hypothetical = signature forgery attack would
   allow forging a signature over a de= legated credential.  The forged
   credential could then be used by th= e attacker as the equivalent of a
   man-in-the-middle certificate, vali= d for 7 days.

<mglt>
I do not see the relevance to TLS 1.3.&nbs= p;
</mglt>

   Server operators should therefore m= inimize the risk of using DC-
   enabled end-entity certificates whe= re a signature forgery oracle may
   be present.  If possible, serv= er operators may choose to use DC-
   enabled certificates only for signi= ng credentials, and not for
   serving non-DC TLS traffic.  F= urthermore, server operators may use
   elliptic curve certificates for DC-= enabled traffic, while using RSA
   certificates without the Delegation= Usage certificate extension for
   non-DC traffic; this completely pre= vents such attacks.

   Note that if a signature can be for= ged over an arbitrary credential,
   the attacker can choose any value f= or the valid_time field.  Repeated
   signature forgeries therefore allow= the attacker to create multiple
   delegated credentials that can cove= r the entire validity period of
   the certificate.  Temporary ex= posure of the key or a signing oracle
   may allow the attacker to impersona= te a server for the lifetime of
   the certificate.


From: TLS <tls-bounces@i= etf.org> on behalf of Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org= >
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <joe@salowey.net>; <tls@ietf.org> <= ;tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
 

I=92d still like to see test vectors.

--_000_MW3PR15MB37855738A57E0192BBE7796CE36E0MW3PR15MB3785namp_-- From nobody Mon Jun 29 19:02:12 2020 Return-Path: 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 80F433A0F71 for ; Mon, 29 Jun 2020 19:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 GcJda-5kWCz7 for ; Mon, 29 Jun 2020 19:01:57 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1806A3A0F6B for ; Mon, 29 Jun 2020 19:01:57 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id h23so14532328qtr.0 for ; Mon, 29 Jun 2020 19:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wAZW8MlFk72IUBomT0FOk+ya+p+nLdqWuW4jlzSUZko=; b=ugqxT+ysuA6m9mErBIwEQPAk6xJehW3V9t4maQaHt3kICZXb10yCVzn13Wp8qBEuJj rH3yjFQaj6ayZPQGfq6Sj5So/P3iJAxJ097PImUPzrBorITYPHx9n7RVMH9vEEsjXcP3 I5kUR8b7ps3X7+MNqS2V6iFHddD3ANCh6bWIvPuDGSwrOe8CkKhKk8FsRcDIf/MhKu6J zTLH6se+/SmfzbAr97G30w0rqgsxN0L2Zz5utWpmjexEqHD0iek03LO/6Bu7XCrqloWC 4Z39OTfuZ+JLGcP8+Q/PIbGQzNxiTe1pMd4ein/MHwp4XOXQrkFVrzBcYuAIkfvycyda M40A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wAZW8MlFk72IUBomT0FOk+ya+p+nLdqWuW4jlzSUZko=; b=k77bkj3sBXciMvL6Ap5u/+h8q5st4+o416Zs//lv3VgpV4rmDzmz+4Gy+jvZu7SW83 LMjy4jdcFFDiSBtasjkzltjVMfYJ/qm5WuxghSCkAHuZOJu0YURox08JvCMOow4RjmFr an274p0sK/P/oL+Z/ZDiRlpukGC54dSOL778Ey3j9VzhYwsqw0SzglS+cJrmE6I+hpVE kMhE4efcN6rof+lwvBktfE/aLZImCg/+1p2qQUNMpT/I5EFwiBUPCuB8ZgyhOtFCJuoC aIDu38OI35xpxq1o1pWvRrNCgyGsUbktAbvo3AlKa4RYPGuXK53j3AOJvjTEpv29+Y9w CfpA== X-Gm-Message-State: AOAM532t6Xadg22k3Nclsqb0qBuTWedqoRO5LTAaBX+jPmXoWbdaluzj jjWo7dgePzs2n78esCfadIz86YtFZFBkY+hLmLXGBw== X-Google-Smtp-Source: ABdhPJxHW0Ds3vqAYEiEhG9DVBquzQ8Be5ismBi5BlWkvDfXVZPppp5gRIhJPGaCpcZxcuPxp0THqxc6i0yPkkwRC1M= X-Received: by 2002:ac8:1ac4:: with SMTP id h4mr19284162qtk.249.1593482515911; Mon, 29 Jun 2020 19:01:55 -0700 (PDT) MIME-Version: 1.0 References: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> In-Reply-To: From: Joseph Salowey Date: Mon, 29 Jun 2020 19:01:44 -0700 Message-ID: To: Daniel Migault Cc: "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="00000000000051299e05a9438fe0" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 02:02:11 -0000 --00000000000051299e05a9438fe0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Daniel Some comments inline below: On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault wrote: > Hi, > > The draft has a number of nits and errors. Among others: > > The related work section mentions KEYLESS and subcert being complementary > that is KEYLESS can perform the operations associated to the DC and/or > those associated to the cert key. I do not think that is correct. KEYLESS > does not support TLS 1.3 while DC only works with TLS 1.3. The LURK > extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead= . > As LURK was mentioned during the adoption period and until version 05 tha= t > should not cause any issues. > > Technologies only available for TLS 1.2 may be mentioned in the related > work section. [draft-mglt-lurk-tls12] should be mentioned similarly to > KEYLESS as it addresses the security concerns of KEYLESS. > > [Joe] KEYLESS is a deployed technology that is addressing some of the same use cases as Delegated credentials. I'm not sure of the status of draft-mglt-lurk-tls13. > There are other places where the extensions is mentioned together with TL= S > 1.2 that needs to be updated. > > [Joe] The only place I see TLS 1.2 mentioned is in the security consideration section in reference to the Bleichenbacher attack which is relevant if a server supports both TLS 1.3 and RSA key exchange with TLS 1.2. > I also think that test vectors would be good as well as a link to a forma= l > verification publication (if available). > > Please see all my comments inline, I hope they help. > > [Joe] Thanks, I didn't get through these yet. The authors should take a look. > Yours, > Daniel > > ---- > > Delegated Credentials for TLS > draft-ietf-tls-subcerts-09 > > [...] > > 1. Introduction > > Typically, a TLS server uses a certificate provided by some entity > other than the operator of the server (a "Certification Authority" or > CA) [RFC8446] [RFC5280]. This organizational separation makes the > TLS server operator dependent on the CA for some aspects of its > operations, for example: > > * Whenever the server operator wants to deploy a new certificate, it > has to interact with the CA. > > * The server operator can only use TLS signature schemes for which > the CA will issue credentials. > > These dependencies cause problems in practice. Server operators > often deploy TLS termination services in locations such as remote > data centers or Content Delivery Networks (CDNs) where it may be > difficult to detect key compromises. Short-lived certificates may be > used to limit the exposure of keys in these cases. > > > I believe it would be clearer to > summarize the problem and link it to the > use case. I would propose something > around: > > These dependencies cause problems in > practice, the management of key exposure > necessarily requires an interaction with > the CA. > > Typically server operators.... > > > However, short-lived certificates need to be renewed more frequently > than long-lived certificates. If an external CA is unable to issue a > certificate in time to replace a deployed certificate, the server > would no longer be able to present a valid certificate to clients. > With short-lived certificates, there is a smaller window of time to > renew a certificates and therefore a higher risk that an outage at a > CA will negatively affect the uptime of the service. > > To reduce the dependency on external CAs, this document proposes a > limited delegation mechanism that allows a TLS peer to issue its own > credentials within the scope of a certificate issued by an external > CA. These credentials only enable the recipient of the delegation to > speak for names that the CA has authorized. For clarity, we will > refer to the certificate issued by the CA as a "certificate", or > "delegation certificate", and the one issued by the operator as a > "delegated credential" or "DC". > > > From the text it is unclear why the > signature scheme appears to be a > constraint as well how it does not opens > to some sort of downgrade attacks if > left to the operator. > > > > 3. Solution Overview > > [...] > > 3.1. Rationale > > Delegated credentials present a better alternative than other > delegation mechanisms like proxy certificates [RFC3820] for several > reasons: > > * There is no change needed to certificate validation at the PKI > layer. > > * X.509 semantics are very rich. This can cause unintended > consequences if a service owner creates a proxy certificate where > the properties differ from the leaf certificate. For this reason, > delegated credentials have very restricted semantics that should > not conflict with X.509 semantics. > > * Proxy certificates rely on the certificate path building process > to establish a binding between the proxy certificate and the > server certificate. Since the certificate path building process > is not cryptographically protected, it is possible that a proxy > certificate could be bound to another certificate with the same > public key, with different X.509 parameters. Delegated > credentials, which rely on a cryptographic binding between the > entire certificate and the delegated credential, cannot. > > * Each delegated credential is bound to a specific signature > algorithm that may be used to sign the TLS handshake ([RFC8446] > > > > > Barnes, et al. Expires 28 December 2020 [Page 6] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > section 4.2.3). This prevents them from being used with other, > perhaps unintended signature algorithms. > > > It is not clear to me why there is a > "may be used". I suppose it concerns the > use of the DC not the algorithm but that > was confusing. > > I also believe that the specific > signature algorithm to sign the > delegated credential could be part of > the rational. > > > 3.2. Related Work > > Many of the use cases for delegated credentials can also be addressed > using purely server-side mechanisms that do not require changes to > client behavior (e.g., a PKCS#11 interface or a remote signing > mechanism [KEYLESS]). These mechanisms, however, incur per- > transaction latency, since the front-end server has to interact with > a back-end server that holds a private key. The mechanism proposed > in this document allows the delegation to be done off-line, with no > per-transaction latency. The figure below compares the message flows > for these two mechanisms with TLS 1.3 [RFC8446]. > > Remote key signing: > > Client Front-End Back-End > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > | |<---remote sign---->| > |<---CertVerify-----| | > | ... | | > > > Delegated credentials: > > Client Front-End Back-End > | |<--DC distribution->| > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > |<---CertVerify-----| | > | ... | | > > These two mechanisms can be complementary. A server could use > credentials for clients that support them, while using [KEYLESS] to > support legacy clients. > > > I believe that this sentence does not > show any complementary as subcert and > KEYLESS are targeting different version > of TLS, so they can hardly be > complementary. However (and luckily) > LURK provides an extension for TLS 1.3 > [draft-mglt-lurk-tls13] which enable a > complementary use of these mechanisms > these mechanisms. I believe that would > be good to indicate the reason they > complement each other which is that LURK > protects the credentials for its > operations. These operations could be > performed in the scope of subcert or TLS > 1.3. > > Note also that in a related section it > also worth mentioning that credentials > may be managed in different ways and > KEYLESS represents an valuable way to > protect and manage these credentials in > TLS 1.2. However, KEYLESS is known to > presents some vulnerabilities (PFS, > signing oracle) so the protection > remains limited while the LURK extension > for TLS 1.2 [draft-mglt-lurk-tls12] > addressed these issues and as a result > should provide a better protection. > > > The private key for a delegated credential > can be used in place of a certificate private key, so it is important > that the Front-End and Back-End are parties that have a trusted > relationship. > > > Use of short-lived certificates with automated certificate issuance, > e.g., with Automated Certificate Managment Environment (ACME) > > Management > > [RFC8555], reduces the risk of key compromise, but has several > limitations. Specifically, it introduces an operationally-critical > dependency on an external party. It also limits the types of > > > > Barnes, et al. Expires 28 December 2020 [Page 7] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > algorithms supported for TLS authentication to those the CA is > willing to issue a certificate for. Nonetheless, existing automated > issuance APIs like ACME may be useful for provisioning delegated > credentials. > > 4. Delegated Credentials > > While X.509 forbids end-entity certificates from being used as > issuers for other certificates, it is valid to use them to issue > other signed objects as long as the certificate contains the > digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a > new signed object format that would encode only the semantics that > are needed for this application. The credential has the following > structure: > > struct { > uint32 valid_time; > SignatureScheme expected_cert_verify_algorithm; > opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; > } Credential; > > valid_time: Time in seconds relative to the beginning of the > delegation certificate's notBefore value after which the delegated > credential is no longer valid. This MUST NOT exceed 7 days. > > I believe the behavior of the "verifying > peer" should also be specified maybe > with a reference. > > > > expected_cert_verify_algorithm: The signature algorithm of the > credential key pair, where the type SignatureScheme is as defined > in [RFC8446]. This is expected to be the same as > CertificateVerify.algorithm sent by the server. Only signature > algorithms allowed for use in CertificateVerify messages are > allowed. When using RSA, the public key MUST NOT use the > rsaEncryption OID, as a result, the following algorithms are not > allowed for use with delegated credentials: rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. > > > It is unclear whether the > expected_cert_verify_algorithm and > CertificateVerify.algorithm needs to be > checked and what needs to be done in > case of mismatch (with the RSA caveat). > I believe that should be clarified. > > > > ASN1_subjectPublicKeyInfo: The credential's public key, a DER- > encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. > > The delegated credential has the following structure: > > struct { > Credential cred; > SignatureScheme algorithm; > opaque signature<0..2^16-1>; > } DelegatedCredential; > > algorithm: The signature algorithm used to verify > DelegatedCredential.signature. > > > I am wondering if any checks should be > performed with the > CertificateVerify.algorithm or if any > algorithm would be acceptable. Unless I > am missing something it seems a weak > algorithm can be used - assuming the > registry contains such weak algorithms. > > > > Barnes, et al. Expires 28 December 2020 [Page 8] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > signature: The delegation, a signature that binds the credential to > the end-entity certificate's public key as specified below. The > signature scheme is specified by DelegatedCredential.algorithm. > > [...] > > 4.1.1. Server Authentication > > A client which supports this specification SHALL send a > "delegated_credential" extension in its ClientHello. The body of the > extension consists of a SignatureSchemeList: > > > > > > Barnes, et al. Expires 28 December 2020 [Page 9] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > struct { > SignatureScheme supported_signature_algorithm<2..2^16-2>; > } SignatureSchemeList; > > If the client receives a delegated credential without indicating > support, then the client MUST abort with an "unexpected_message" > alert. > > If the extension is present, the server MAY send a delegated > credential; if the extension is not present, the server MUST NOT send > a delegated credential. The server MUST ignore the extension unless > TLS 1.3 or a later version is negotiated. > > > The server MUST send the delegated credential as an extension in the > CertificateEntry of its end-entity certificate; the client SHOULD > ignore delegated credentials sent as extensions to any other > certificate. > > The expected_cert_verify_algorithm field MUST be of a type advertised > by the client in the SignatureSchemeList and is considered invalid > otherwise. Clients that receive invalid delegated credentials MUST > terminate the connection with an "illegal_parameter" alert. > > > I am wondering what would prevent any > downgrade attacks if the > SignatureSchemeList and > signature_algorithms have two different > sets of lists. My current understanding > is that these extensions are handled > independently, but I might be missing > something. > > I am wondering if that would be > appropriated to specify the signature of > the CertificateVerify depending on the > presence of the delegated credential - I > mean the key used to generate it. > > > > [...] > > 4.1.3. Validating a Delegated Credential > > On receiving a delegated credential and a certificate chain, the peer > validates the certificate chain and matches the end-entity > certificate to the peer's expected identity. It also takes the > following steps: > > 1. Verify that the current time is within the validity interval of > the credential. This is done by asserting that the current time > is no more than the delegation certificate's notBefore value plus > DelegatedCredential.cred.valid_time. > > 2. Verify that the credential's remaining validity time is no more > than the maximum validity period. This is done by asserting that > the current time is no more than the delegation certificate's > notBefore value plus DelegatedCredential.cred.valid_time plus the > maximum validity period. > > 3. Verify that expected_cert_verify_algorithm matches the scheme > indicated in the peer's CertificateVerify message and that the > algorithm is allowed for use with delegated credentials. > > > I am wondering if a reference to specify > what allowed would not be needed unless > it means advertised in the extension. > > > > 4. Verify that the end-entity certificate satisfies the conditions > in Section 4.2. > > 5. Use the public key in the peer's end-entity certificate to verify > the signature of the credential using the algorithm indicated by > DelegatedCredential.algorithm. > > If one or more of these checks fail, then the delegated credential is > deemed invalid. Clients and servers that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. If successful, the participant receiving the Certificate > message uses the public key in the credential to verify the signature > in the peer's CertificateVerify message. > > [...] > > 7. Security Considerations > > [...] > > 7.6. The Impact of Signature Forgery Attacks > > When TLS 1.2 servers support RSA key exchange, they may be vulnerable > to attacks that allow forging an RSA signature over an arbitrary > message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a > mitigation strategy requiring careful implementation of timing > resistant countermeasures for preventing these attacks. Experience > shows that in practice, server implementations may fail to fully stop > these attacks due to the complexity of this mitigation [ROBOT]. For > TLS 1.2 servers that support RSA key exchange using a DC-enabled end- > entity certificate, a hypothetical signature forgery attack would > allow forging a signature over a delegated credential. The forged > credential could then be used by the attacker as the equivalent of a > man-in-the-middle certificate, valid for 7 days. > > > I do not see the relevance to TLS 1.3. > > > Server operators should therefore minimize the risk of using DC- > enabled end-entity certificates where a signature forgery oracle may > be present. If possible, server operators may choose to use DC- > enabled certificates only for signing credentials, and not for > serving non-DC TLS traffic. Furthermore, server operators may use > elliptic curve certificates for DC-enabled traffic, while using RSA > certificates without the DelegationUsage certificate extension for > non-DC traffic; this completely prevents such attacks. > > Note that if a signature can be forged over an arbitrary credential, > the attacker can choose any value for the valid_time field. Repeated > signature forgeries therefore allow the attacker to create multiple > delegated credentials that can cover the entire validity period of > the certificate. Temporary exposure of the key or a signing oracle > may allow the attacker to impersonate a server for the lifetime of > the certificate. > > > ------------------------------ > *From:* TLS on behalf of Salz, Rich 40akamai.com@dmarc.ietf.org> > *Sent:* Monday, June 29, 2020 12:00 PM > *To:* Joseph Salowey ; > *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS > > > I=E2=80=99d still like to see test vectors. > --00000000000051299e05a9438fe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Daniel

Some comment= s inline below:

On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <daniel.migault@ericsson.com= > wrote:
Hi,=C2=A0

The draft has a number of nits and errors. Among = others:=C2=A0

The related work section mentions KEYLESS and sub= cert being complementary that is KEYLESS can perform the operations associa= ted to the DC and/or those associated to the cert key. I do not think that = is correct. KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 1.3 [= draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned d= uring the adoption period and until version 05 that should not cause any is= sues.=C2=A0

Technologies only available for TLS 1.2 may be me= ntioned in the related work section.=C2=A0=C2=A0[draft-mglt-lurk-tls12]=C2=A0should be mentioned=C2=A0similarly to KEYLESS as it addresses the s= ecurity concerns of KEYLESS.=C2=A0


[Joe] KEYLESS is a dep= loyed technology that is addressing some of the same use cases as Delegated= credentials.=C2=A0 I'm not sure of the status of draft-mglt-lurk-tls13= .=C2=A0
=C2=A0
There are other places where the= extensions is mentioned together with TLS 1.2 that needs to be updated. = =C2=A0


[Joe] The only place I see TLS 1.2 mentioned is in the security considera= tion section in reference to the=C2=A0Blei= chenbacher attack which is relevant if a server supports both TLS 1.3 and R= SA key exchange with TLS 1.2.=C2=A0=C2=A0
=C2=A0
I also think that test vectors w= ould be good as well as a link to a formal verification publication (if ava= ilable).

Please see all my comments inlin= e, I hope they help.

[Joe] Thanks,=C2=A0 I didn't get = through these yet.=C2=A0 The authors should take a look.=C2=A0
=

=C2=A0<= /div>
Yours,=C2=A0
Daniel

----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegated Credentials for TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-subcerts-09

[...]

1.=C2=A0 Introduction

=C2=A0 =C2=A0Typically, a TLS server uses a certi= ficate provided by some entity
=C2=A0 =C2=A0other than the operator of the serve= r (a "Certification Authority" or
=C2=A0 =C2=A0CA) [RFC8446] [RFC5280].=C2=A0 This = organizational separation makes the
=C2=A0 =C2=A0TLS server operator dependent on the= CA for some aspects of its
=C2=A0 =C2=A0operations, for example:

=C2=A0 =C2=A0* =C2=A0Whenever the server operator= wants to deploy a new certificate, it
=C2=A0 =C2=A0 =C2=A0 has to interact with the CA.=

=C2=A0 =C2=A0* =C2=A0The server operator can only= use TLS signature schemes for which
=C2=A0 =C2=A0 =C2=A0 the CA will issue credential= s.

=C2=A0 =C2=A0These dependencies cause problems in= practice.=C2=A0 Server operators
=C2=A0 =C2=A0often deploy TLS termination service= s in locations such as remote
=C2=A0 =C2=A0data centers or Content Delivery Net= works (CDNs) where it may be
=C2=A0 =C2=A0difficult to detect key compromises.= =C2=A0 Short-lived certificates may be
=C2=A0 =C2=A0used to limit the exposure of keys i= n these cases.

<mglt>
I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA.=C2=A0

Typically server operators....
</mglt>

=C2=A0 =C2=A0However, short-lived certificates ne= ed to be renewed more frequently
=C2=A0 =C2=A0than long-lived certificates.=C2=A0 = If an external CA is unable to issue a
=C2=A0 =C2=A0certificate in time to replace a dep= loyed certificate, the server
=C2=A0 =C2=A0would no longer be able to present a= valid certificate to clients.
=C2=A0 =C2=A0With short-lived certificates, there= is a smaller window of time to
=C2=A0 =C2=A0renew a certificates and therefore a= higher risk that an outage at a
=C2=A0 =C2=A0CA will negatively affect the uptime= of the service.

=C2=A0 =C2=A0To reduce the dependency on external= CAs, this document proposes a
=C2=A0 =C2=A0limited delegation mechanism that al= lows a TLS peer to issue its own
=C2=A0 =C2=A0credentials within the scope of a ce= rtificate issued by an external
=C2=A0 =C2=A0CA.=C2=A0 These credentials only ena= ble the recipient of the delegation to
=C2=A0 =C2=A0speak for names that the CA has auth= orized.=C2=A0 For clarity, we will
=C2=A0 =C2=A0refer to the certificate issued by t= he CA as a "certificate", or
=C2=A0 =C2=A0"delegation certificate", = and the one issued by the operator as a
=C2=A0 =C2=A0"delegated credential" or = "DC".

<mglt>
From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator. =C2=A0
</mglt>


3.=C2=A0 Solution Overview

[...]

3.1.=C2=A0 Rationale

=C2=A0 =C2=A0Delegated credentials present a bett= er alternative than other
=C2=A0 =C2=A0delegation mechanisms like proxy cer= tificates [RFC3820] for several
=C2=A0 =C2=A0reasons:

=C2=A0 =C2=A0* =C2=A0There is no change needed to= certificate validation at the PKI
=C2=A0 =C2=A0 =C2=A0 layer.

=C2=A0 =C2=A0* =C2=A0X.509 semantics are very ric= h.=C2=A0 This can cause unintended
=C2=A0 =C2=A0 =C2=A0 consequences if a service ow= ner creates a proxy certificate where
=C2=A0 =C2=A0 =C2=A0 the properties differ from t= he leaf certificate.=C2=A0 For this reason,
=C2=A0 =C2=A0 =C2=A0 delegated credentials have v= ery restricted semantics that should
=C2=A0 =C2=A0 =C2=A0 not conflict with X.509 sema= ntics.

=C2=A0 =C2=A0* =C2=A0Proxy certificates rely on t= he certificate path building process
=C2=A0 =C2=A0 =C2=A0 to establish a binding betwe= en the proxy certificate and the
=C2=A0 =C2=A0 =C2=A0 server certificate.=C2=A0 Si= nce the certificate path building process
=C2=A0 =C2=A0 =C2=A0 is not cryptographically pro= tected, it is possible that a proxy
=C2=A0 =C2=A0 =C2=A0 certificate could be bound t= o another certificate with the same
=C2=A0 =C2=A0 =C2=A0 public key, with different X= .509 parameters.=C2=A0 Delegated
=C2=A0 =C2=A0 =C2=A0 credentials, which rely on a= cryptographic binding between the
=C2=A0 =C2=A0 =C2=A0 entire certificate and the d= elegated credential, cannot.

=C2=A0 =C2=A0* =C2=A0Each delegated credential is= bound to a specific signature
=C2=A0 =C2=A0 =C2=A0 algorithm that may be used t= o sign the TLS handshake ([RFC8446]




Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 6]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0 =C2=A0 section 4.2.3).=C2=A0 This p= revents them from being used with other,
=C2=A0 =C2=A0 =C2=A0 perhaps unintended signature= algorithms.

<mglt>
It is not clear to me why there is a
"may be used". I suppose it concerns th= e
use of the DC not the algorithm but that
was confusing.=C2=A0

I also believe that the specific
signature algorithm to sign the
delegated credential could be part of
the rational. =C2=A0
</mglt>

3.2.=C2=A0 Related Work

=C2=A0 =C2=A0Many of the use cases for delegated = credentials can also be addressed
=C2=A0 =C2=A0using purely server-side mechanisms = that do not require changes to
=C2=A0 =C2=A0client behavior (e.g., a PKCS#11 int= erface or a remote signing
=C2=A0 =C2=A0mechanism [KEYLESS]).=C2=A0 These me= chanisms, however, incur per-
=C2=A0 =C2=A0transaction latency, since the front= -end server has to interact with
=C2=A0 =C2=A0a back-end server that holds a priva= te key.=C2=A0 The mechanism proposed
=C2=A0 =C2=A0in this document allows the delegati= on to be done off-line, with no
=C2=A0 =C2=A0per-transaction latency.=C2=A0 The f= igure below compares the message flows
=C2=A0 =C2=A0for these two mechanisms with TLS 1.= 3 [RFC8446].

=C2=A0 =C2=A0Remote key signing:

=C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Front-End =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Back-End
=C2=A0 =C2=A0 =C2=A0|----ClientHello--->| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---ServerHello----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---Certificate----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---remote sign---->|
=C2=A0 =C2=A0 =C2=A0|<---CertVerify-----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= ... =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|


=C2=A0 =C2=A0Delegated credentials:

=C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Front-End =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Back-End
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<--DC distribution->|
=C2=A0 =C2=A0 =C2=A0|----ClientHello--->| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---ServerHello----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---Certificate----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---CertVerify-----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= ... =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0These two mechanisms can be compleme= ntary.=C2=A0 A server could use
=C2=A0 =C2=A0credentials for clients that support= them, while using [KEYLESS] to
=C2=A0 =C2=A0support legacy clients.=C2=A0<= /span>

<mglt>
I believe that this sentence does not
show any complementary as subcert and
KEYLESS are targeting different version
of TLS, so they can hardly be
complementary.=C2=A0 However (and luckily)
LURK provides an extension for TLS 1.3
[draft-mglt-lurk-tls13] which enable a
complementary use of these mechanisms
these mechanisms. I believe that would
be good to indicate the reason they
complement each other which is that LURK
protects the credentials for its
operations. These operations could be
performed in the scope of subcert or TLS
1.3.

Note also that in a related section it
also worth mentioning that credentials
may be managed in different ways and
KEYLESS represents an valuable way to
protect and manage these credentials in
TLS 1.2. However, KEYLESS is known to
presents some vulnerabilities (PFS,
signing oracle) so the protection
remains limited while the LURK extension
for TLS 1.2 [draft-mglt-lurk-tls12]
addressed these issues and as a result
should provide a better protection.
</mglt>

The private key for a delegated credential
=C2=A0 =C2=A0can be used in place of a certificat= e private key, so it is important
=C2=A0 =C2=A0that the Front-End and Back-End are = parties that have a trusted
=C2=A0 =C2=A0relationship.


=C2=A0 =C2=A0Use of short-lived certificates with= automated certificate issuance,
=C2=A0 =C2=A0e.g., with Automated Certificate Man= agment Environment (ACME)
<mglt>
Management=C2=A0
</mglt>
=C2=A0 =C2=A0[RFC8555], reduces the risk of key c= ompromise, but has several
=C2=A0 =C2=A0limitations.=C2=A0 Specifically, it = introduces an operationally-critical
=C2=A0 =C2=A0dependency on an external party.=C2= =A0 It also limits the types of



Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 7]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0algorithms supported for TLS authent= ication to those the CA is
=C2=A0 =C2=A0willing to issue a certificate for.= =C2=A0 Nonetheless, existing automated
=C2=A0 =C2=A0issuance APIs like ACME may be usefu= l for provisioning delegated
=C2=A0 =C2=A0credentials.

4.=C2=A0 Delegated Credentials

=C2=A0 =C2=A0While X.509 forbids end-entity certi= ficates from being used as
=C2=A0 =C2=A0issuers for other certificates, it i= s valid to use them to issue
=C2=A0 =C2=A0other signed objects as long as the = certificate contains the
=C2=A0 =C2=A0digitalSignature KeyUsage ([RFC5280]= section 4.2.1.3).=C2=A0 We define a
=C2=A0 =C2=A0new signed object format that would = encode only the semantics that
=C2=A0 =C2=A0are needed for this application.=C2= =A0 The credential has the following
=C2=A0 =C2=A0structure:

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 valid_time;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme expec= ted_cert_verify_algorithm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque ASN1_subjectPu= blicKeyInfo<1..2^24-1>;
=C2=A0 =C2=A0 =C2=A0 } Credential;

=C2=A0 =C2=A0valid_time: =C2=A0Time in seconds re= lative to the beginning of the
=C2=A0 =C2=A0 =C2=A0 delegation certificate's= notBefore value after which the delegated
=C2=A0 =C2=A0 =C2=A0 credential is no longer vali= d.=C2=A0 This MUST NOT exceed 7 days.
<mglt>
I believe the behavior of the "verifying
peer" should also be specified maybe
with a reference.

</mglt>

=C2=A0 =C2=A0expected_cert_verify_algorithm: =C2= =A0The signature algorithm of the
=C2=A0 =C2=A0 =C2=A0 credential key pair, where t= he type SignatureScheme is as defined
=C2=A0 =C2=A0 =C2=A0 in [RFC8446].=C2=A0 This is = expected to be the same as
=C2=A0 =C2=A0 =C2=A0 CertificateVerify.algorithm = sent by the server.=C2=A0 Only signature
=C2=A0 =C2=A0 =C2=A0 algorithms allowed for use i= n CertificateVerify messages are
=C2=A0 =C2=A0 =C2=A0 allowed.=C2=A0 When using RS= A, the public key MUST NOT use the
=C2=A0 =C2=A0 =C2=A0 rsaEncryption OID, as a resu= lt, the following algorithms are not
=C2=A0 =C2=A0 =C2=A0 allowed for use with delegat= ed credentials: rsa_pss_rsae_sha256,
=C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha384, rsa_pss= _rsae_sha512.

<mglt>
It is unclear whether the
expected_cert_verify_algorithm and
CertificateVerify.algorithm needs to be
checked and what needs to be done in
case of mismatch (with the RSA caveat).
I believe that should be clarified.

</mglt>

=C2=A0 =C2=A0ASN1_subjectPublicKeyInfo: =C2=A0The= credential's public key, a DER-
=C2=A0 =C2=A0 =C2=A0 encoded [X.690] SubjectPubli= cKeyInfo as defined in [RFC5280].

=C2=A0 =C2=A0The delegated credential has the fol= lowing structure:

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Credential cred;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme algor= ithm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque signature<0= ..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 } DelegatedCredential;

=C2=A0 =C2=A0algorithm: =C2=A0The signature algor= ithm used to verify
=C2=A0 =C2=A0 =C2=A0 DelegatedCredential.signatur= e.

<mglt>
I am wondering if any checks should be
performed with the
CertificateVerify.algorithm or if any
algorithm would be acceptable. Unless I
am missing something it seems a weak
algorithm can be used - assuming the
registry contains such weak algorithms.
</mglt>


Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 8]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0signature: =C2=A0The delegation, a s= ignature that binds the credential to
=C2=A0 =C2=A0 =C2=A0 the end-entity certificate&#= 39;s public key as specified below.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 signature scheme is specifie= d by DelegatedCredential.algorithm.

[...]

4.1.1.=C2=A0 Server Authentication

=C2=A0 =C2=A0A client which supports this specifi= cation SHALL send a
=C2=A0 =C2=A0"delegated_credential" ext= ension in its ClientHello.=C2=A0 The body of the
=C2=A0 =C2=A0extension consists of a SignatureSch= emeList:





Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 9]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme suppo= rted_signature_algorithm<2..2^16-2>;
=C2=A0 =C2=A0 =C2=A0 } SignatureSchemeList;

=C2=A0 =C2=A0If the client receives a delegated c= redential without indicating
=C2=A0 =C2=A0support, then the client MUST abort = with an "unexpected_message"
=C2=A0 =C2=A0alert.

=C2=A0 =C2=A0If the extension is present, the ser= ver MAY send a delegated
=C2=A0 =C2=A0credential; if the extension is not = present, the server MUST NOT send
=C2=A0 =C2=A0a delegated credential.=C2=A0 The se= rver MUST ignore the extension unless
=C2=A0 =C2=A0TLS 1.3 or a later version is negoti= ated.


=C2=A0 =C2=A0The server MUST send the delegated c= redential as an extension in the
=C2=A0 =C2=A0CertificateEntry of its end-entity c= ertificate; the client SHOULD
=C2=A0 =C2=A0ignore delegated credentials sent as= extensions to any other
=C2=A0 =C2=A0certificate.

=C2=A0 =C2=A0The expected_cert_verify_algorithm f= ield MUST be of a type advertised
=C2=A0 =C2=A0by the client in the SignatureScheme= List and is considered invalid
=C2=A0 =C2=A0otherwise.=C2=A0 Clients that receiv= e invalid delegated credentials MUST
=C2=A0 =C2=A0terminate the connection with an &qu= ot;illegal_parameter" alert.

<mglt>
I am wondering what would prevent any
downgrade attacks if the
SignatureSchemeList and
signature_algorithms have two different
sets of lists. My current understanding
is that these extensions are handled
independently, but I might be missing
something.

I am wondering if that would be
appropriated to specify the signature of
the CertificateVerify depending on the
presence of the delegated credential - I
mean the key used to generate it.=C2=A0

</mglt>

[...]

4.1.3.=C2=A0 Validating a Delegated Credential

=C2=A0 =C2=A0On receiving a delegated credential = and a certificate chain, the peer
=C2=A0 =C2=A0validates the certificate chain and = matches the end-entity
=C2=A0 =C2=A0certificate to the peer's expect= ed identity.=C2=A0 It also takes the
=C2=A0 =C2=A0following steps:

=C2=A0 =C2=A01.=C2=A0 Verify that the current tim= e is within the validity interval of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the credential.=C2=A0 = This is done by asserting that the current time
=C2=A0 =C2=A0 =C2=A0 =C2=A0is no more than the de= legation certificate's notBefore value plus
=C2=A0 =C2=A0 =C2=A0 =C2=A0DelegatedCredential.cr= ed.valid_time.

=C2=A0 =C2=A02.=C2=A0 Verify that the credential&= #39;s remaining validity time is no more
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the maximum valid= ity period.=C2=A0 This is done by asserting that
=C2=A0 =C2=A0 =C2=A0 =C2=A0the current time is no= more than the delegation certificate's
=C2=A0 =C2=A0 =C2=A0 =C2=A0notBefore value plus D= elegatedCredential.cred.valid_time plus the
=C2=A0 =C2=A0 =C2=A0 =C2=A0maximum validity perio= d.

=C2=A0 =C2=A03.=C2=A0 Verify that expected_cert_v= erify_algorithm matches the scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicated in the peer&= #39;s CertificateVerify message and that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm is allowed f= or use with delegated credentials.

<mglt>
I am wondering if a reference to specify
what allowed would not be needed unless
it means advertised in the extension. =C2=A0

</mglt>

=C2=A0 =C2=A04.=C2=A0 Verify that the end-entity = certificate satisfies the conditions
=C2=A0 =C2=A0 =C2=A0 =C2=A0in Section 4.2.

=C2=A0 =C2=A05.=C2=A0 Use the public key in the p= eer's end-entity certificate to verify
=C2=A0 =C2=A0 =C2=A0 =C2=A0the signature of the c= redential using the algorithm indicated by
=C2=A0 =C2=A0 =C2=A0 =C2=A0DelegatedCredential.al= gorithm.

=C2=A0 =C2=A0If one or more of these checks fail,= then the delegated credential is
=C2=A0 =C2=A0deemed invalid.=C2=A0 Clients and se= rvers that receive invalid delegated
=C2=A0 =C2=A0credentials MUST terminate the conne= ction with an "illegal_parameter"
=C2=A0 =C2=A0alert.=C2=A0 If successful, the part= icipant receiving the Certificate
=C2=A0 =C2=A0message uses the public key in the c= redential to verify the signature
=C2=A0 =C2=A0in the peer's CertificateVerify = message.

[...]

7.=C2=A0 Security Considerations

[...]

7.6.=C2=A0 The Impact of Signature Forgery Attack= s

=C2=A0 =C2=A0When TLS 1.2 servers support RSA key= exchange, they may be vulnerable
=C2=A0 =C2=A0to attacks that allow forging an RSA= signature over an arbitrary
=C2=A0 =C2=A0message [BLEI].=C2=A0 TLS 1.2 [RFC52= 46] (Section 7.4.7.1.) describes a
=C2=A0 =C2=A0mitigation strategy requiring carefu= l implementation of timing
=C2=A0 =C2=A0resistant countermeasures for preven= ting these attacks.=C2=A0 Experience
=C2=A0 =C2=A0shows that in practice, server imple= mentations may fail to fully stop
=C2=A0 =C2=A0these attacks due to the complexity = of this mitigation [ROBOT].=C2=A0 For
=C2=A0 =C2=A0TLS 1.2 servers that support RSA key= exchange using a DC-enabled end-
=C2=A0 =C2=A0entity certificate, a hypothetical s= ignature forgery attack would
=C2=A0 =C2=A0allow forging a signature over a del= egated credential.=C2=A0 The forged
=C2=A0 =C2=A0credential could then be used by the= attacker as the equivalent of a
=C2=A0 =C2=A0man-in-the-middle certificate, valid= for 7 days.

<mglt>
I do not see the relevance to TLS 1.3.=C2= =A0
</mglt>

=C2=A0 =C2=A0Server operators should therefore mi= nimize the risk of using DC-
=C2=A0 =C2=A0enabled end-entity certificates wher= e a signature forgery oracle may
=C2=A0 =C2=A0be present.=C2=A0 If possible, serve= r operators may choose to use DC-
=C2=A0 =C2=A0enabled certificates only for signin= g credentials, and not for
=C2=A0 =C2=A0serving non-DC TLS traffic.=C2=A0 Fu= rthermore, server operators may use
=C2=A0 =C2=A0elliptic curve certificates for DC-e= nabled traffic, while using RSA
=C2=A0 =C2=A0certificates without the DelegationU= sage certificate extension for
=C2=A0 =C2=A0non-DC traffic; this completely prev= ents such attacks.

=C2=A0 =C2=A0Note that if a signature can be forg= ed over an arbitrary credential,
=C2=A0 =C2=A0the attacker can choose any value fo= r the valid_time field.=C2=A0 Repeated
=C2=A0 =C2=A0signature forgeries therefore allow = the attacker to create multiple
=C2=A0 =C2=A0delegated credentials that can cover= the entire validity period of
=C2=A0 =C2=A0the certificate.=C2=A0 Temporary exp= osure of the key or a signing oracle
=C2=A0 =C2=A0may allow the attacker to impersonat= e a server for the lifetime of
=C2=A0 =C2=A0the certificate.


From= : TLS <tls= -bounces@ietf.org> on behalf of Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf= .org>
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <joe@salowey.net>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
=C2=A0

I=E2=80=99d still like to see test vectors.

--00000000000051299e05a9438fe0-- From nobody Tue Jun 30 03:07:14 2020 Return-Path: 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 0F7703A1162; Tue, 30 Jun 2020 03:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8LV4VMvucOIC; Tue, 30 Jun 2020 03:07:10 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6E23A1160; Tue, 30 Jun 2020 03:07:09 -0700 (PDT) Received: from sogo13.sd4.0x35.net (sogo13.sd4.0x35.net [10.200.201.63]) (Authenticated sender: logan@cyberstorm.mu) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 800CA1C0006; Tue, 30 Jun 2020 10:07:05 +0000 (UTC) From: =?utf-8?q?logan=40cyberstorm=2Emu?= In-Reply-To: <300221E9-F91E-4910-B07D-6568E364B5D4@gmail.com> Content-Type: text/plain; charset="utf-8" X-Forward: 127.0.0.1 Date: Tue, 30 Jun 2020 12:07:05 +0200 Cc: "Joseph Salowey" , tls@ietf.org, tls@ietf.org, "Benjamin Kaduk" , draft-ietf-tls-md5-sha1-deprecate@ietf.org To: "Kathleen Moriarty" MIME-Version: 1.0 Message-ID: <3309-5efb0f00-7f-7dbee000@198899904> User-Agent: SOGoMail 4.3.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Moving_SHA-1_signature_schemes_to_not_recommende?= =?utf-8?q?d_in_draft-ietf-tls-md5-sha1-deprecate?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:07:12 -0000 Looks good to me. On Thursday, June 25, 2020 15:32 +04, Kathleen Moriarty wrote: > Thank you, Joe. > > Sent from my mobile device > > > On Jun 25, 2020, at 1:10 AM, Joseph Salowey wrote= : > > > > =EF=BB=BF > > Hi All, > > > > I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move = the recommended IANA registry entries for rsa=5Fpkcs1=5Fsha1 and ecdsa= =5Fsha1 in the Signature Scheme registry from Y to N. This change can= be incorporated with any updates from the AD review. > > > > Please post to this thread if you have any concerns with this chang= e. > > > > Cheers, > > > > Joe > > > > [1] https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull= /7 > > > > From nobody Tue Jun 30 09:10:13 2020 Return-Path: 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 40BE33A09C6 for ; Tue, 30 Jun 2020 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 GMmMkXYkz6sh for ; Tue, 30 Jun 2020 09:10:08 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2067.outbound.protection.outlook.com [40.107.220.67]) (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 8F4E33A0033 for ; Tue, 30 Jun 2020 09:10:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XHytGOGLCyLskykm5SG1SePbQ+A+hznZWnMmo61WOOMw2WRskGWv7TSZ/R1/ulSHwQ9Afc2dEuqG9z0ab7lwGUj/FssTJNY1twz03fDfb6UCpgjlO4XCkE2Z68uvUb7llpu+GPgGdoT3pjlvPeLwaWmViT8Wc/8/9YPsmM25bjRe8YScp/pB2DD6vNzTimCP38sOAik7igpM5eumOsAPMfpP5wRsgupc/58yA6PmuUpapMSm4JeePZXkYIi/MdcFFURZvdvV3wkRWQ1pAs8YpVRUP89+tMLbLnNZmcbsS0/kZs0BwlfAn1LJdRcIX+P8t1JUnnAPWDLIQmLuNQSG/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z56nO4e0V18R2ppKJpWgwZFAYz4b1pI1WSMVgcxaPUo=; b=BnNHNege+pq/qCL03AQxspJi+JVuRqPqaT7tQxn/F55ujz+FORYDcobYPbptRyKYUf1GX4XF5i+sJfKRsi4uLm2URN8YNRZg0KWj31SwrKcrXBU3u9Do6QocQxS30PDiIxwIdMqREpB3tHtWzLyNpQED7vgixAJPLRGnLzXl7UJ65u08/9WRdODMrI5+gJOpo8wZAKc3lubYKm5CTZdPTOspaqRprQVfOmJeoaud5TB0qswDNxq+8hFdH45aPm8dlIuJyKhzDOwU0O/A9N2YVJCggFVhje5MfhfDAiskCq9CcGTNEpJDRciRQ58TYdlhpXQCLVHMIdjRQAnuTL09vw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z56nO4e0V18R2ppKJpWgwZFAYz4b1pI1WSMVgcxaPUo=; b=ov9yD4ljvj4FDLPFFgy6YxezZqtKRF+Ei8obfZkYp6KkHdFlslt9GQsAQDknp9kvDGp2q3OBVzs5cSsqv/lekL7mOuwMjsa0Um+0j+8ChLdUcAVYuywDOXIqtOPumT0XKbNsTd0v1a8AnVrH1xwcFGSMQ5Lmm7/+qFZio10r3tE= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR1501MB2096.namprd15.prod.outlook.com (2603:10b6:805:9::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20; Tue, 30 Jun 2020 16:10:05 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%5]) with mapi id 15.20.3131.028; Tue, 30 Jun 2020 16:10:05 +0000 From: Daniel Migault To: Joseph Salowey CC: "Salz, Rich" , "" Thread-Topic: [TLS] 2nd WGLC for Delegated Credentials for TLS Thread-Index: AQHWTi5Wr1YqfsHMFk6cLyNi9MT+gajvwGgAgAA1zHOAAHI9AIAA58DS Date: Tue, 30 Jun 2020 16:10:05 +0000 Message-ID: References: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64a61e01-26db-43c1-36c6-08d81d100d4a x-ms-traffictypediagnostic: SN6PR1501MB2096: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a8Iar/tov5DJsrtfBFNESGH89RRXt+N4c1GhDzH3aOA5+0hv01Ir9c2/7ASdCkZ58A2F/DCQZNDpPF92zy5Dhe9FfK5eZ3DaNpNvzd29n/NXVQ6m4LsaNl2ZN3tyyw6rKSyXHjgrZgqMUVtTgbZ9LbZ96XFfyNLZGAUtw6febOmlSFoOitCtGNlXN4TntmoQ2bWO9YbXq/EQpdYyKD9dyx4ZShJGomr1m/eSq6Fx2CO6do9oJryVkTVHo7P+gtlGI6Rdxr5PC87hXuihBOLJnGJQAGxlEiC1Yzp9RFEdRBNs+dXLwXrWz6+LS88Q06xXvbBrxLn5cEhNVN1yEg7HuxTDFnmPcXnUIRLjROfmC7UASengt1cwK/P16cBuzTt68X+pM70OFy1djf5DLSM6ag== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39860400002)(376002)(396003)(136003)(166002)(9686003)(966005)(53546011)(6506007)(7696005)(71200400001)(478600001)(19627405001)(86362001)(316002)(54906003)(83380400001)(4326008)(186003)(30864003)(66574015)(8676002)(52536014)(8936002)(44832011)(5660300002)(66946007)(64756008)(66446008)(76116006)(91956017)(55016002)(66556008)(66476007)(33656002)(2906002)(26005)(6916009)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: q2vLb+rUHC0surl5vRr11fbJoA+dmZDdpr64feZ5jwJXlDVrv7AeW5OY1RLcUvv8Iq6e0sKTO2HzG9qJPKP8mWXB5IGvZ7UWgxLpMq02f5M/vpCEdrzR5ZSsguyOOdAzpDe+9JeiAM0QBb1qXgFbULTGE6pUNjBWXxZxPR0hhBy/f08Q6hBBhosI14dQwPUxckZo0h4ZMLd8cscWfToJAb/0nsytZgNQBbA/5uq/zpRUzz58ef18vNnx3NzBH7jUA8dwtKV+IX+VTOWz8wIBv6H09TPEBqRsehLymyakuXWGYOk9wHORzzuppulTPZv091AkKk3FK9hyvJMOAOXcwYDF9MsLaONV/oF8mFdTM793gqAuhf8IiNmvs+XruWMqt4+rXnYP8GAprmNxnCAuYAc9I3PhStkBS1T1MFjGcQpQdWzJNeOK2PwQF+QRbOccgihIkp+6Fh9V96CREmtfqSImYCllt8yXRPzfPaUihAU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB3791976C5184C780C56DEF35E36F0SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64a61e01-26db-43c1-36c6-08d81d100d4a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 16:10:05.0792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9frvCyby9WDRaUoOPzwQ3gRHESQUAZiioJz1807nw2OaIr3fMqfvjJy0n0tbmKXc0bVWWytNUSj542UOXlyrb4HhA0z+qSOsf9foMIcIbaw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2096 Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 16:10:12 -0000 --_000_SA0PR15MB3791976C5184C780C56DEF35E36F0SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for the feed back, please find my responses inline. Yours, Daniel ________________________________ From: Joseph Salowey Sent: Monday, June 29, 2020 10:01 PM To: Daniel Migault Cc: Salz, Rich ; Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS HI Daniel Some comments inline below: On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault > wrote: Hi, The draft has a number of nits and errors. Among others: The related work section mentions KEYLESS and subcert being complementary t= hat is KEYLESS can perform the operations associated to the DC and/or those= associated to the cert key. I do not think that is correct. KEYLESS does n= ot support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for= TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was m= entioned during the adoption period and until version 05 that should not ca= use any issues. Technologies only available for TLS 1.2 may be mentioned in the related wor= k section. [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLES= S as it addresses the security concerns of KEYLESS. [Joe] KEYLESS is a deployed technology that is addressing some of the same = use cases as Delegated credentials. I'm not sure of the status of draft-mg= lt-lurk-tls13. To respond to your question regarding the status of draft-mglt-lurk-tls13 i= t is a work in progress. That said, I am a bit upset by the comment, so let= me clarify my comment just in case I mis-interpreted something or I am com= pletely wrong. Firstly, I tried to briefly describe the type of errors I think I noticed, = so the co-authors do not need to parse all comments to get an idea of the t= ypes of errors. In this case, I had the impression that the subcert was ini= tially intended to be an extension for TLS 1.2 and TLS 1.3, and the scope o= f TLS 1.2 has been removed in version 02 while not all text have been updat= ed accordingly. It is a bit more than nits but I do not see this as a major= concern. The related work section positions KEYLESS and subcert and think that is us= eful. My understanding is that KEYLESS only work for TLS 1.2 and for the se= rver and subcert only works with TLS 1.3. When they shared a common TLS ver= sion, it was possible to use these 2 mechanisms together in a given TLS ses= sion. Typically KEYLESS could host the private key of the DC or the X509 c= ertificate and proceed to the appropriated cryptographic operations. This i= s at least my understanding of the text below: """ These two mechanisms can be complementary. A server could use credentials for clients that support them, while using [KEYLESS] to support legacy clients. The private key for a delegated credential can be used in place of a certificate private key, so it is important that the Front-End and Back-End are parties that have a trusted relationship. """ Given that KEYLESS and DC work with different versions it seems hard to me = that this could happen. I suspect there is an error and that KEYLESS is dep= loyed or not seems to me a bit orthogonal to the fact that it does not achi= eve what is being written - or at least what I am understanding from the re= ading. I believe the case of using KEYLESS-like technologies is important to be me= ntioned and I believe that draft-mglt-tls13 while being work in progress fi= ts the use case while KEYLESS does not. As mentioned in my text, I do not think adding LURK in the related work sec= tion represents a major update as the technology has been mentioned in the = related work section during the adoption, and was there until version 05, a= nd I do not recall this has raised any concerns at least on the mailing lis= t. Digging on github I could only find [1], though I might have missed some= discussions. For the sake of clarity and trying to address potential - and purely specul= ative - questions that may lie behind the initial question: * I think the related work section is useful as it clarifies concepts that = had been confusing in the past. In addition, I have the impression that del= egation may not be entirely deployed with DC and that complementary technol= ogy is needed - at least for the peer not supporting the extension. * I am not asking that KEYLESS be removed even if - as I understand - KEYLE= SS only address TLS 1.2. I think that is clearly stated. * I do not think the status of work in progress prevents soem work to be me= ntioned in a related work section. In some cases a draft status is sufficie= nt for the IANA to assign code points. * I also believe that [draft-mglt-lurk-tls12] should be mentioned as it add= resses some security concerns among others the signing oracle. It seems the= re are some misunderstanding around this [1]. If there is anything you would like me to clarify, feel free to let me kno= w. I also believe that clarifications are provided in the inline comments. [1] https://github.com/tlswg/tls-subcerts/issues/30 There are other places where the extensions is mentioned together with TLS = 1.2 that needs to be updated. [Joe] The only place I see TLS 1.2 mentioned is in the security considerati= on section in reference to the Bleichenbacher attack which is relevant if a= server supports both TLS 1.3 and RSA key exchange with TLS 1.2. That is at least one place I saw TLS 1.2 being mentioned. Note that the rel= ated work section also revealed some issue associated to TLS 1.2 without sp= ecifying the version. I suspected that these errors came from the initial s= upport of TLS 1.2 in the beginning and wanted the co-authors to carefully r= eview the draft in that perspective. I do not raise a comment to each of th= ese and leave the co-authors to look at this carefully. It is correct that some servers may support two versions of TLS but I am no= t very familiar on how this is handled and operated. As a result I am not a= ble to clearly mention if there is an error or not and this is why I kept t= he statement quite generic ( "Other places where the extension is mentioned= together with TLS 1.2" explicitly or not.. That said, I believe that if the section is entirely dedicated to the case = where two versions are being co-hosted, I believe that should be at least c= larified as well as other conditions such as (using the same key over the t= wo versions, supporting signing and encryption for that key...). Again I am= not very familiar with what is common practice in that scope. At least my = perception of the text below is that the section was considering the use of= DC in a context of TLS 1.2. I do not see this as a big issue either updati= ng this section """ When TLS 1.2 servers support RSA key exchange, .... """ """ For TLS 1.2 servers that support RSA key exchange using a DC-enabled end- entity certificate, a hypothetical signature forgery attack would allow forging a signature over a delegated credential. """ I also think that test vectors would be good as well as a link to a formal = verification publication (if available). Please see all my comments inline, I hope they help. [Joe] Thanks, I didn't get through these yet. The authors should take a l= ook. Going through the comments is not very easy, this is why I tried to provide= a brief overview. I am happy to do otherwise if that helps. Yours, Daniel ---- Delegated Credentials for TLS draft-ietf-tls-subcerts-09 [...] 1. Introduction Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446] [RFC5280]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: * Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. * The server operator can only use TLS signature schemes for which the CA will issue credentials. These dependencies cause problems in practice. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. I believe it would be clearer to summarize the problem and link it to the use case. I would propose something around: These dependencies cause problems in practice, the management of key exposure necessarily requires an interaction with the CA. Typically server operators.... However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. For clarity, we will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". >From the text it is unclear why the signature scheme appears to be a constraint as well how it does not opens to some sort of downgrade attacks if left to the operator. 3. Solution Overview [...] 3.1. Rationale Delegated credentials present a better alternative than other delegation mechanisms like proxy certificates [RFC3820] for several reasons: * There is no change needed to certificate validation at the PKI layer. * X.509 semantics are very rich. This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate. For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. * Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the server certificate. Since the certificate path building process is not cryptographically protected, it is possible that a proxy certificate could be bound to another certificate with the same public key, with different X.509 parameters. Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. * Each delegated credential is bound to a specific signature algorithm that may be used to sign the TLS handshake ([RFC8446] Barnes, et al. Expires 28 December 2020 [Page 6] Internet-Draft Delegated Credentials for TLS June 2020 section 4.2.3). This prevents them from being used with other, perhaps unintended signature algorithms. It is not clear to me why there is a "may be used". I suppose it concerns the use of the DC not the algorithm but that was confusing. I also believe that the specific signature algorithm to sign the delegated credential could be part of the rational. 3.2. Related Work Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to client behavior (e.g., a PKCS#11 interface or a remote signing mechanism [KEYLESS]). These mechanisms, however, incur per- transaction latency, since the front-end server has to interact with a back-end server that holds a private key. The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency. The figure below compares the message flows for these two mechanisms with TLS 1.3 [RFC8446]. Remote key signing: Client Front-End Back-End |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | | Delegated credentials: Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | | These two mechanisms can be complementary. A server could use credentials for clients that support them, while using [KEYLESS] to support legacy clients. I believe that this sentence does not show any complementary as subcert and KEYLESS are targeting different version of TLS, so they can hardly be complementary. However (and luckily) LURK provides an extension for TLS 1.3 [draft-mglt-lurk-tls13] which enable a complementary use of these mechanisms these mechanisms. I believe that would be good to indicate the reason they complement each other which is that LURK protects the credentials for its operations. These operations could be performed in the scope of subcert or TLS 1.3. Note also that in a related section it also worth mentioning that credentials may be managed in different ways and KEYLESS represents an valuable way to protect and manage these credentials in TLS 1.2. However, KEYLESS is known to presents some vulnerabilities (PFS, signing oracle) so the protection remains limited while the LURK extension for TLS 1.2 [draft-mglt-lurk-tls12] addressed these issues and as a result should provide a better protection. The private key for a delegated credential can be used in place of a certificate private key, so it is important that the Front-End and Back-End are parties that have a trusted relationship. Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Managment Environment (ACME) Management [RFC8555], reduces the risk of key compromise, but has several limitations. Specifically, it introduces an operationally-critical dependency on an external party. It also limits the types of Barnes, et al. Expires 28 December 2020 [Page 7] Internet-Draft Delegated Credentials for TLS June 2020 algorithms supported for TLS authentication to those the CA is willing to issue a certificate for. Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning delegated credentials. 4. Delegated Credentials While X.509 forbids end-entity certificates from being used as issuers for other certificates, it is valid to use them to issue other signed objects as long as the certificate contains the digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a new signed object format that would encode only the semantics that are needed for this application. The credential has the following structure: struct { uint32 valid_time; SignatureScheme expected_cert_verify_algorithm; opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; } Credential; valid_time: Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. This MUST NOT exceed 7 days. I believe the behavior of the "verifying peer" should also be specified maybe with a reference. expected_cert_verify_algorithm: The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in [RFC8446]. This is expected to be the same as CertificateVerify.algorithm sent by the server. Only signature algorithms allowed for use in CertificateVerify messages are allowed. When using RSA, the public key MUST NOT use the rsaEncryption OID, as a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. It is unclear whether the expected_cert_verify_algorithm and CertificateVerify.algorithm needs to be checked and what needs to be done in case of mismatch (with the RSA caveat). I believe that should be clarified. ASN1_subjectPublicKeyInfo: The credential's public key, a DER- encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. The delegated credential has the following structure: struct { Credential cred; SignatureScheme algorithm; opaque signature<0..2^16-1>; } DelegatedCredential; algorithm: The signature algorithm used to verify DelegatedCredential.signature. I am wondering if any checks should be performed with the CertificateVerify.algorithm or if any algorithm would be acceptable. Unless I am missing something it seems a weak algorithm can be used - assuming the registry contains such weak algorithms. Barnes, et al. Expires 28 December 2020 [Page 8] Internet-Draft Delegated Credentials for TLS June 2020 signature: The delegation, a signature that binds the credential to the end-entity certificate's public key as specified below. The signature scheme is specified by DelegatedCredential.algorithm. [...] 4.1.1. Server Authentication A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello. The body of the extension consists of a SignatureSchemeList: Barnes, et al. Expires 28 December 2020 [Page 9] Internet-Draft Delegated Credentials for TLS June 2020 struct { SignatureScheme supported_signature_algorithm<2..2^16-2>; } SignatureSchemeList; If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential. The server MUST ignore the extension unless TLS 1.3 or a later version is negotiated. The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate. The expected_cert_verify_algorithm field MUST be of a type advertised by the client in the SignatureSchemeList and is considered invalid otherwise. Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. I am wondering what would prevent any downgrade attacks if the SignatureSchemeList and signature_algorithms have two different sets of lists. My current understanding is that these extensions are handled independently, but I might be missing something. I am wondering if that would be appropriated to specify the signature of the CertificateVerify depending on the presence of the delegated credential - I mean the key used to generate it. [...] 4.1.3. Validating a Delegated Credential On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity certificate to the peer's expected identity. It also takes the following steps: 1. Verify that the current time is within the validity interval of the credential. This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. 2. Verify that the credential's remaining validity time is no more than the maximum validity period. This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. 3. Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. I am wondering if a reference to specify what allowed would not be needed unless it means advertised in the extension. 4. Verify that the end-entity certificate satisfies the conditions in Section 4.2. 5. Use the public key in the peer's end-entity certificate to verify the signature of the credential using the algorithm indicated by DelegatedCredential.algorithm. If one or more of these checks fail, then the delegated credential is deemed invalid. Clients and servers that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. If successful, the participant receiving the Certificate message uses the public key in the credential to verify the signature in the peer's CertificateVerify message. [...] 7. Security Considerations [...] 7.6. The Impact of Signature Forgery Attacks When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a mitigation strategy requiring careful implementation of timing resistant countermeasures for preventing these attacks. Experience shows that in practice, server implementations may fail to fully stop these attacks due to the complexity of this mitigation [ROBOT]. For TLS 1.2 servers that support RSA key exchange using a DC-enabled end- entity certificate, a hypothetical signature forgery attack would allow forging a signature over a delegated credential. The forged credential could then be used by the attacker as the equivalent of a man-in-the-middle certificate, valid for 7 days. I do not see the relevance to TLS 1.3. Server operators should therefore minimize the risk of using DC- enabled end-entity certificates where a signature forgery oracle may be present. If possible, server operators may choose to use DC- enabled certificates only for signing credentials, and not for serving non-DC TLS traffic. Furthermore, server operators may use elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field. Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate. Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. ________________________________ From: TLS > on behalf of = Salz, Rich > Sent: Monday, June 29, 2020 12:00 PM To: Joseph Salowey >; > > Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS I'd still like to see test vectors. --_000_SA0PR15MB3791976C5184C780C56DEF35E36F0SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Joe, 

Thanks for the feed back, please find my responses inline.

Yours, 
Daniel

From: Joseph Salowey <jo= e@salowey.net>
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org>; <tls@= ietf.org> <tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
 
HI Daniel

Some comments inline below:

On Mon, Jun 29, 2020 at 5:47 PM Dan= iel Migault <daniel.migau= lt@ericsson.com> wrote:
Hi, 

The draft has a number of nits and errors. Among = others: 

The related work section mentions KEYLESS and sub= cert being complementary that is KEYLESS can perform the operations associa= ted to the DC and/or those associated to the cert key. I do not think that = is correct. KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 1.3 [= draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned d= uring the adoption period and until version 05 that should not cause any is= sues. 

Technologies only available for TLS 1.2 may be me= ntioned in the related work section.  [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLESS as it addresses the s= ecurity concerns of KEYLESS. 


[Joe] KEYLESS is a deployed technology that is addres= sing some of the same use cases as Delegated credentials.  I'm not sur= e of the status of draft-mglt-lurk-tls13. 

 
<mglt>
To respond to your question regarding the status of draft-mglt-lu= rk-tls13 it is a work in progress. That said, I am a bit upset by the comme= nt, so let me clarify my comment just in case I mis-interpreted something o= r I am completely wrong. 
  
Firstly, I tried to briefly describe the type of errors I think I noti= ced, so the co-authors do not need to parse all comments to get an idea of = the types of errors. In this case, I had the impression that the subcert wa= s initially intended to be an extension for TLS 1.2 and TLS 1.3, and the scope of TLS 1.2 has been removed in vers= ion 02 while not all text have been updated accordingly. It is a bit more t= han nits but I do not see this as a major concern.

The related work section positions KEYLESS and subcert and think = that is useful. My understanding is that KEYLESS only work for TLS 1.2 and = for the server and subcert only works with TLS 1.3. When they shared a= common TLS version, it was possible to use these 2 mechanisms together in a given TLS session.  Typically KEYLES= S could host the private key of the DC or the X509 certificate and proceed = to the appropriated cryptographic operations. This is at least my understan= ding of the text below: 

"""
   These two mechanisms can be compl=
ementary.  A server could use=0A=
   credentials for clients that support them, while using [KEYLESS] to=0A=
   support legacy clients.  The private key for a delegated credential=0A=
   can be used in place of a certificate private key, so it is important=0A=
   that the Front-End and Back-End are parties that have a trusted=0A=
   relationship.
"""  

Given that KEYLESS and DC work with different versions it seems hard t= o me that this could happen. I suspect there is an error and that KEYLESS i= s deployed or not seems to me a bit orthogonal to the fact that it does not= achieve what is being written - or at least what I am understanding from the reading. 

I believe the case of using KEYLESS-like technologies is important to = be mentioned and I believe that draft-mglt-tls13 while being work in progre= ss fits the use case while KEYLESS does not. 
As mentioned in my text, I do not think adding LURK in the related wor= k section represents a major update as the technology has been mentioned in= the related work section during the adoption, and was there until version = 05, and I do not recall this has raised any concerns at least on the mailing list. Digging on github I coul= d only find [1], though I might have missed some discussions.

For the sake of clarity and trying to address potential - and purely s= peculative - questions that may lie behind the initial question: 
* I think the related work section is useful as it clarifies conc= epts that had been confusing in the past. In addition, I have the impressio= n that delegation may not be entirely deployed with DC and that complementa= ry technology is needed - at least for the peer not supporting the extension.  
* I am not asking that KEYLESS be removed even if - as I understand - = KEYLESS only address TLS 1.2. I think that is clearly stated. 
* I do not think the status of work in progress prevents soem work to = be mentioned in a related work section. In some cases a draft status i= s sufficient for the IANA to assign code points.     
* I also believe that [draft-mglt-lurk-tls12] should be mentioned= as it addresses some security concerns among others the signing oracl= e. It seems there are some misunderstanding around this [1].

If there is anything you would like me to clarify, feel free to let&nb= sp; me know. I also believe that clarifications are provided in the inline = comments.



</mglt> 
There are other places where the= extensions is mentioned together with TLS 1.2 that needs to be updated. &n= bsp;


[Joe] The only place I see TLS 1.2 mentioned is in th= e security consideration section in reference to the Bleichenbacher attack which is relevant if a server support= s both TLS 1.3 and RSA key exchange with TLS 1.2.  
 
<mglt>
That is at least one place I saw TLS 1.2 being mentioned. Note that th= e related work section also revealed some issue associated to TLS 1.2 witho= ut specifying the version. I suspected that these errors came from the init= ial support of TLS 1.2 in the beginning and wanted the co-authors to carefully review the draft in that perspectiv= e. I do not raise a comment to each of these and leave the co-authors to lo= ok at this carefully.

It is correct that some servers may support two versions of TLS but I = am not very familiar on how this is handled and operated. As a result I am = not able to clearly mention if there is an error or not and this is why I k= ept the statement quite generic ( "Other places where the extension is mentioned together with TLS 1.= 2" explicitly or not.. 

That said, I believe that if the section is entirely dedicated to the = case where two versions are being co-hosted, I believe that should be at le= ast clarified as well as other conditions such as (using the same key over = the two versions, supporting signing and encryption for that key...). Again I am not very familiar with wh= at is common practice in that scope. At least my perception of the tex= t below is that the section was considering the use of DC in a context of T= LS 1.2. I do not see this as a big issue either updating this section

"""
When TLS 1.2 servers support RSA key=
 exchange, ....
"""
"""
For=0A=
   TLS 1.2 servers that support RSA key exchange using a DC-enabled end-=0A=
   entity certificate, a hypothetical signature forgery attack would=0A=
   allow forging a signature over a delegated credential.
"""
</mglt> 

I also think that test vectors w= ould be good as well as a link to a formal verification publication (if ava= ilable).

Please see all my comments inlin= e, I hope they help.

[Joe] Thanks,  I didn't get through these yet.&n= bsp; The authors should take a look. 

<mglt>
Going through the comments is not very easy, this is why I tried to pr= ovide a brief overview. I am happy to do otherwise if that helps. 
</mglt> 
 
Yours, 
Daniel

----

              =        Delegated Credentials for TLS
              =          draft-ietf-tls-subcerts-09

[...]

1.  Introduction

   Typically, a TLS server uses a certi= ficate provided by some entity
   other than the operator of the serve= r (a "Certification Authority" or
   CA) [RFC8446] [RFC5280].  This = organizational separation makes the
   TLS server operator dependent on the= CA for some aspects of its
   operations, for example:

   *  Whenever the server operator= wants to deploy a new certificate, it
      has to interact with the CA.=

   *  The server operator can only= use TLS signature schemes for which
      the CA will issue credential= s.

   These dependencies cause problems in= practice.  Server operators
   often deploy TLS termination service= s in locations such as remote
   data centers or Content Delivery Net= works (CDNs) where it may be
   difficult to detect key compromises.=   Short-lived certificates may be
   used to limit the exposure of keys i= n these cases.

<mglt>
I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA. 

Typically server operators....
</mglt>

   However, short-lived certificates ne= ed to be renewed more frequently
   than long-lived certificates.  = If an external CA is unable to issue a
   certificate in time to replace a dep= loyed certificate, the server
   would no longer be able to present a= valid certificate to clients.
   With short-lived certificates, there= is a smaller window of time to
   renew a certificates and therefore a= higher risk that an outage at a
   CA will negatively affect the uptime= of the service.

   To reduce the dependency on external= CAs, this document proposes a
   limited delegation mechanism that al= lows a TLS peer to issue its own
   credentials within the scope of a ce= rtificate issued by an external
   CA.  These credentials only ena= ble the recipient of the delegation to
   speak for names that the CA has auth= orized.  For clarity, we will
   refer to the certificate issued by t= he CA as a "certificate", or
   "delegation certificate", = and the one issued by the operator as a
   "delegated credential" or = "DC".

<mglt>
From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator.  
</mglt>


3.  Solution Overview

[...]

3.1.  Rationale

   Delegated credentials present a bett= er alternative than other
   delegation mechanisms like proxy cer= tificates [RFC3820] for several
   reasons:

   *  There is no change needed to= certificate validation at the PKI
      layer.

   *  X.509 semantics are very ric= h.  This can cause unintended
      consequences if a service ow= ner creates a proxy certificate where
      the properties differ from t= he leaf certificate.  For this reason,
      delegated credentials have v= ery restricted semantics that should
      not conflict with X.509 sema= ntics.

   *  Proxy certificates rely on t= he certificate path building process
      to establish a binding betwe= en the proxy certificate and the
      server certificate.  Si= nce the certificate path building process
      is not cryptographically pro= tected, it is possible that a proxy
      certificate could be bound t= o another certificate with the same
      public key, with different X= .509 parameters.  Delegated
      credentials, which rely on a= cryptographic binding between the
      entire certificate and the d= elegated credential, cannot.

   *  Each delegated credential is= bound to a specific signature
      algorithm that may be used t= o sign the TLS handshake ([RFC8446]




Barnes, et al.          = Expires 28 December 2020               &= nbsp;[Page 6]

Internet-Draft        Delegat= ed Credentials for TLS            June 2020


      section 4.2.3).  This p= revents them from being used with other,
      perhaps unintended signature= algorithms.

<mglt>
It is not clear to me why there is a
"may be used". I suppose it concerns th= e
use of the DC not the algorithm but that
was confusing. 

I also believe that the specific
signature algorithm to sign the
delegated credential could be part of
the rational.  
</mglt>

3.2.  Related Work

   Many of the use cases for delegated = credentials can also be addressed
   using purely server-side mechanisms = that do not require changes to
   client behavior (e.g., a PKCS#11 int= erface or a remote signing
   mechanism [KEYLESS]).  These me= chanisms, however, incur per-
   transaction latency, since the front= -end server has to interact with
   a back-end server that holds a priva= te key.  The mechanism proposed
   in this document allows the delegati= on to be done off-line, with no
   per-transaction latency.  The f= igure below compares the message flows
   for these two mechanisms with TLS 1.= 3 [RFC8446].

   Remote key signing:

   Client         &= nbsp;  Front-End            Back-End
     |----ClientHello--->| &nbs= p;                  |
     |<---ServerHello----| &nbs= p;                  |
     |<---Certificate----| &nbs= p;                  |
     |        =           |<---remote sign---->|
     |<---CertVerify-----| &nbs= p;                  |
     |        = ...        |             =        |


   Delegated credentials:

   Client         &= nbsp;  Front-End            Back-End
     |        =           |<--DC distribution->|
     |----ClientHello--->| &nbs= p;                  |
     |<---ServerHello----| &nbs= p;                  |
     |<---Certificate----| &nbs= p;                  |
     |<---CertVerify-----| &nbs= p;                  |
     |        = ...        |             =        |

   These two mechanisms can be compleme= ntary.  A server could use
   credentials for clients that support= them, while using [KEYLESS] to
   support legacy clients. <= /span>

<mglt>
I believe that this sentence does not
show any complementary as subcert and
KEYLESS are targeting different version
of TLS, so they can hardly be
complementary.  However (and luckily)
LURK provides an extension for TLS 1.3
[draft-mglt-lurk-tls13] which enable a
complementary use of these mechanisms
these mechanisms. I believe that would
be good to indicate the reason they
complement each other which is that LURK
protects the credentials for its
operations. These operations could be
performed in the scope of subcert or TLS
1.3.

Note also that in a related section it
also worth mentioning that credentials
may be managed in different ways and
KEYLESS represents an valuable way to
protect and manage these credentials in
TLS 1.2. However, KEYLESS is known to
presents some vulnerabilities (PFS,
signing oracle) so the protection
remains limited while the LURK extension
for TLS 1.2 [draft-mglt-lurk-tls12]
addressed these issues and as a result
should provide a better protection.
</mglt>

The private key for a delegated credential
   can be used in place of a certificat= e private key, so it is important
   that the Front-End and Back-End are = parties that have a trusted
   relationship.


   Use of short-lived certificates with= automated certificate issuance,
   e.g., with Automated Certificate Man= agment Environment (ACME)
<mglt>
Management 
</mglt>
   [RFC8555], reduces the risk of key c= ompromise, but has several
   limitations.  Specifically, it = introduces an operationally-critical
   dependency on an external party.&nbs= p; It also limits the types of



Barnes, et al.          = Expires 28 December 2020               &= nbsp;[Page 7]

Internet-Draft        Delegat= ed Credentials for TLS            June 2020


   algorithms supported for TLS authent= ication to those the CA is
   willing to issue a certificate for.&= nbsp; Nonetheless, existing automated
   issuance APIs like ACME may be usefu= l for provisioning delegated
   credentials.

4.  Delegated Credentials

   While X.509 forbids end-entity certi= ficates from being used as
   issuers for other certificates, it i= s valid to use them to issue
   other signed objects as long as the = certificate contains the
   digitalSignature KeyUsage ([RFC5280]= section 4.2.1.3).  We define a
   new signed object format that would = encode only the semantics that
   are needed for this application.&nbs= p; The credential has the following
   structure:

      struct {
        uint32 valid_time;
        SignatureScheme expec= ted_cert_verify_algorithm;
        opaque ASN1_subjectPu= blicKeyInfo<1..2^24-1>;
      } Credential;

   valid_time:  Time in seconds re= lative to the beginning of the
      delegation certificate's not= Before value after which the delegated
      credential is no longer vali= d.  This MUST NOT exceed 7 days.
<mglt>
I believe the behavior of the "verifying
peer" should also be specified maybe
with a reference.

</mglt>

   expected_cert_verify_algorithm: &nbs= p;The signature algorithm of the
      credential key pair, where t= he type SignatureScheme is as defined
      in [RFC8446].  This is = expected to be the same as
      CertificateVerify.algorithm = sent by the server.  Only signature
      algorithms allowed for use i= n CertificateVerify messages are
      allowed.  When using RS= A, the public key MUST NOT use the
      rsaEncryption OID, as a resu= lt, the following algorithms are not
      allowed for use with delegat= ed credentials: rsa_pss_rsae_sha256,
      rsa_pss_rsae_sha384, rsa_pss= _rsae_sha512.

<mglt>
It is unclear whether the
expected_cert_verify_algorithm and
CertificateVerify.algorithm needs to be
checked and what needs to be done in
case of mismatch (with the RSA caveat).
I believe that should be clarified.

</mglt>

   ASN1_subjectPublicKeyInfo:  The= credential's public key, a DER-
      encoded [X.690] SubjectPubli= cKeyInfo as defined in [RFC5280].

   The delegated credential has the fol= lowing structure:

      struct {
        Credential cred;
        SignatureScheme algor= ithm;
        opaque signature<0= ..2^16-1>;
      } DelegatedCredential;

   algorithm:  The signature algor= ithm used to verify
      DelegatedCredential.signatur= e.

<mglt>
I am wondering if any checks should be
performed with the
CertificateVerify.algorithm or if any
algorithm would be acceptable. Unless I
am missing something it seems a weak
algorithm can be used - assuming the
registry contains such weak algorithms.
</mglt>


Barnes, et al.          = Expires 28 December 2020               &= nbsp;[Page 8]

Internet-Draft        Delegat= ed Credentials for TLS            June 2020


   signature:  The delegation, a s= ignature that binds the credential to
      the end-entity certificate's= public key as specified below.  The
      signature scheme is specifie= d by DelegatedCredential.algorithm.

[...]

4.1.1.  Server Authentication

   A client which supports this specifi= cation SHALL send a
   "delegated_credential" ext= ension in its ClientHello.  The body of the
   extension consists of a SignatureSch= emeList:





Barnes, et al.          = Expires 28 December 2020               &= nbsp;[Page 9]

Internet-Draft        Delegat= ed Credentials for TLS            June 2020


      struct {
        SignatureScheme suppo= rted_signature_algorithm<2..2^16-2>;
      } SignatureSchemeList;

   If the client receives a delegated c= redential without indicating
   support, then the client MUST abort = with an "unexpected_message"
   alert.

   If the extension is present, the ser= ver MAY send a delegated
   credential; if the extension is not = present, the server MUST NOT send
   a delegated credential.  The se= rver MUST ignore the extension unless
   TLS 1.3 or a later version is negoti= ated.


   The server MUST send the delegated c= redential as an extension in the
   CertificateEntry of its end-entity c= ertificate; the client SHOULD
   ignore delegated credentials sent as= extensions to any other
   certificate.

   The expected_cert_verify_algorithm f= ield MUST be of a type advertised
   by the client in the SignatureScheme= List and is considered invalid
   otherwise.  Clients that receiv= e invalid delegated credentials MUST
   terminate the connection with an &qu= ot;illegal_parameter" alert.

<mglt>
I am wondering what would prevent any
downgrade attacks if the
SignatureSchemeList and
signature_algorithms have two different
sets of lists. My current understanding
is that these extensions are handled
independently, but I might be missing
something.

I am wondering if that would be
appropriated to specify the signature of
the CertificateVerify depending on the
presence of the delegated credential - I
mean the key used to generate it. 

</mglt>

[...]

4.1.3.  Validating a Delegated Credential

   On receiving a delegated credential = and a certificate chain, the peer
   validates the certificate chain and = matches the end-entity
   certificate to the peer's expected i= dentity.  It also takes the
   following steps:

   1.  Verify that the current tim= e is within the validity interval of
       the credential.  = This is done by asserting that the current time
       is no more than the de= legation certificate's notBefore value plus
       DelegatedCredential.cr= ed.valid_time.

   2.  Verify that the credential'= s remaining validity time is no more
       than the maximum valid= ity period.  This is done by asserting that
       the current time is no= more than the delegation certificate's
       notBefore value plus D= elegatedCredential.cred.valid_time plus the
       maximum validity perio= d.

   3.  Verify that expected_cert_v= erify_algorithm matches the scheme
       indicated in the peer'= s CertificateVerify message and that the
       algorithm is allowed f= or use with delegated credentials.

<mglt>
I am wondering if a reference to specify
what allowed would not be needed unless
it means advertised in the extension.  

</mglt>

   4.  Verify that the end-entity = certificate satisfies the conditions
       in Section 4.2.

   5.  Use the public key in the p= eer's end-entity certificate to verify
       the signature of the c= redential using the algorithm indicated by
       DelegatedCredential.al= gorithm.

   If one or more of these checks fail,= then the delegated credential is
   deemed invalid.  Clients and se= rvers that receive invalid delegated
   credentials MUST terminate the conne= ction with an "illegal_parameter"
   alert.  If successful, the part= icipant receiving the Certificate
   message uses the public key in the c= redential to verify the signature
   in the peer's CertificateVerify mess= age.

[...]

7.  Security Considerations

[...]

7.6.  The Impact of Signature Forgery Attack= s

   When TLS 1.2 servers support RSA key= exchange, they may be vulnerable
   to attacks that allow forging an RSA= signature over an arbitrary
   message [BLEI].  TLS 1.2 [RFC52= 46] (Section 7.4.7.1.) describes a
   mitigation strategy requiring carefu= l implementation of timing
   resistant countermeasures for preven= ting these attacks.  Experience
   shows that in practice, server imple= mentations may fail to fully stop
   these attacks due to the complexity = of this mitigation [ROBOT].  For
   TLS 1.2 servers that support RSA key= exchange using a DC-enabled end-
   entity certificate, a hypothetical s= ignature forgery attack would
   allow forging a signature over a del= egated credential.  The forged
   credential could then be used by the= attacker as the equivalent of a
   man-in-the-middle certificate, valid= for 7 days.

<mglt>
I do not see the relevance to TLS 1.3. = ;
</mglt>

   Server operators should therefore mi= nimize the risk of using DC-
   enabled end-entity certificates wher= e a signature forgery oracle may
   be present.  If possible, serve= r operators may choose to use DC-
   enabled certificates only for signin= g credentials, and not for
   serving non-DC TLS traffic.  Fu= rthermore, server operators may use
   elliptic curve certificates for DC-e= nabled traffic, while using RSA
   certificates without the DelegationU= sage certificate extension for
   non-DC traffic; this completely prev= ents such attacks.

   Note that if a signature can be forg= ed over an arbitrary credential,
   the attacker can choose any value fo= r the valid_time field.  Repeated
   signature forgeries therefore allow = the attacker to create multiple
   delegated credentials that can cover= the entire validity period of
   the certificate.  Temporary exp= osure of the key or a signing oracle
   may allow the attacker to impersonat= e a server for the lifetime of
   the certificate.


Fr= om: TLS <t= ls-bounces@ietf.org> on behalf of Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org>
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <joe@salowey.net>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
 

I’d still like to see test vectors.

--_000_SA0PR15MB3791976C5184C780C56DEF35E36F0SA0PR15MB3791namp_-- From nobody Tue Jun 30 16:30:55 2020 Return-Path: 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 C96643A0403 for ; Tue, 30 Jun 2020 16:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 jIH2S4pmRku7 for ; Tue, 30 Jun 2020 16:30:52 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79B93A03FF for ; Tue, 30 Jun 2020 16:30:51 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id s1so24724848ljo.0 for ; Tue, 30 Jun 2020 16:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=modpIhN+doDtKQjjB4m3g96+DJ8TiO5D/YciwP8ETMk=; b=bF2zdISudn7XZwd6tI/kmC+IkuHXAMmfWx4dV4v+TlkSotFHruLnEOLpG12dDgg8Zo +7jYBiZHcP76dWT/R/5VMaRud6F0T/2WjWAv33uQUEwEDkw17IhSSX7nLJwRnElGQN23 W5Ou3ay2NMyWtn5q74lGymXQS3LIdel61iHsh15u54seWpZ97RFIuReYQVLKNv1EFDxA P7XqpNgRRrRJMillGHUww5YbnfXcJtStE4YUnnEZKzksH4AenAAmEz16i8fFbKyJJ4Ac KCAO1Qxo3znkbZ/KE4N7zfdQjZwUojsvK9zl0bM3FTRErBgdtrghycC23riF0yCWXQJC k4Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=modpIhN+doDtKQjjB4m3g96+DJ8TiO5D/YciwP8ETMk=; b=IGnO8KH497cfl0HxYsbMxONMUgO0H4Kx6l7PFi7Pxi8e+peQ3IkaF8522h8bgnhtNz wOV+kPaI+twSfBXtivsPSpUDNcugDCCfHDcbF7ktAONsAmG77FQne/rxe9CZyR38+vJc 4bnv0NnH89Wb4L1hGU+m39YoZqe4QcXG1sbMd7OWrL7HmxnuzXHcZiemTmYMz8UvaFte gL7EZ54BAIQwJFcwcsmg4tMe1CIfuhwRev9Xs7k7uAi0Ba1Jlyx8YvYkAQbv61/25tT6 Adqmr7RbVDfJa5e2uAAMVm+RXd8+BT9dN2QMDtpW4i4NHaNYiNscwdeztRdixCRi9dHW 5iKg== X-Gm-Message-State: AOAM530XW+RHqqIc2QYAwPG6X7g1aBfATJJWGT6+BNljzi6m9gjpJo7z ttvQRb1eGIQ+sPdK5MtIow/TQVxmXl/tKcsb/gHAeA== X-Google-Smtp-Source: ABdhPJy06J/qvg4Cg1gMI0GYhinYBJ3hn3Nm463W/kpwNopdJs1py9l4cqVaZOaTrqhjn2BWw+FfVnA1xe1C5QfifTg= X-Received: by 2002:a2e:858e:: with SMTP id b14mr12257850lji.301.1593559849727; Tue, 30 Jun 2020 16:30:49 -0700 (PDT) MIME-Version: 1.0 References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> In-Reply-To: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> From: David Schinazi Date: Tue, 30 Jun 2020 16:30:38 -0700 Message-ID: To: Yoav Nir Cc: "" Content-Type: multipart/alternative; boundary="000000000000c57a7205a95590f6" Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 23:30:54 -0000 --000000000000c57a7205a95590f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoav, Could you elaborate on the rationale for this change please? I was assuming that the ability for servers to send extensions not requested by clients was useful. Thanks, David On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir wrote: > Hi > > I=E2=80=99ve just submitted the following PR: > > https://github.com/tlswg/tls-flags/pull/4 > > Three changes: > > - It is no longer allowed to send an empty flags extension. If you > don=E2=80=99t support any flags, don=E2=80=99t send the extension. > - The server is no longer allowed to respond with flag types that the > client didn=E2=80=99t indicate support for first. > - I=E2=80=99ve split the extension description section into a format s= ection > and a rules section > > > Please comment. Barring any objections, I=E2=80=99ll merge the PR just be= fore the > submission deadline. > > Yoav > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c57a7205a95590f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoav,

Could you elaborate on the rat= ionale for this change please?
I was assuming that the ability fo= r servers to send extensions not requested by clients was useful.

Thanks,
David

On Mon, Jun 29, 2020 at 2:34 P= M Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi

I=E2=80=99ve = just submitted the following PR:


Three changes:
  • It is no longer allowed to send an empty flags extension.=C2=A0 If= you don=E2=80=99t support any flags, don=E2=80=99t send the extension.
  • The server is no longer allowed to respond with flag types that the cl= ient didn=E2=80=99t indicate support for first.
  • I=E2=80=99ve split = the extension description section into a format section and a rules section=

Please comment. Barring any objections,= I=E2=80=99ll merge the PR just before the submission deadline.
<= br>
Yoav

______________________________= _________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c57a7205a95590f6-- From nobody Tue Jun 30 16:45:26 2020 Return-Path: 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 C125D3A0778 for ; Tue, 30 Jun 2020 16:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JpbfxV0CwFz3 for ; Tue, 30 Jun 2020 16:45:23 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7F33A0775 for ; Tue, 30 Jun 2020 16:45:23 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id n6so20026894otl.0 for ; Tue, 30 Jun 2020 16:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4B/DL6hElxHm4a/VWMYZrIxHt547Re8fnrkMwW8YNU=; b=tHoLHV85pBkj/RgrFiYhqRCjB5pzeAZtqbuL22BvAdyA3Kk1LlWdPj3TKHiUikO7B/ Md1gfaPoBkW45Mhwo+OBFwPGLNkv/Xuk2EMC55rnUvUapC/kcUA9Jc5rcoMQu7781Xb7 tTlg/AhwAwf8sIExlfUNIwHZrSmllYdiqw0wcaU0GTkpPQe4zmx3C+e4N7t5qUI9fgWv BvI9ZG9a0TAyRGHRpq14V7Bcphr3U0AgSp+pURsN04khTuEnjHtXPdHVWCLTxntzPo6w tGjoPL5ejnqDQi4lHka0mhJvg19U083H0EcGn5Zco0SQXFqYVd75T9gDiPpU1+Nna2Me /DrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4B/DL6hElxHm4a/VWMYZrIxHt547Re8fnrkMwW8YNU=; b=CY8Zg1o0SiB0FdGnZ/XMA19I7t8ZXnUbQUearsLK03pTGXZkfvpD7Qimc78LxDjoSr ca3EbDMVqeuhlccGi6gveX7Yg9SevAqbBlAJ9x/n7OvOEJpOhoCMvGaRjX6iRl75uABP OLOdJ6P7L/2QJ56JQ06qfdfUAKMN8GEsTeNR7GIf8CZoOvs/Lw9Z7W0ZSa2TxjEG+2KI /CWDRlgV+wYdemzHQoiFhgsMFm+aui56U4aQwUiRhV2YfrIvk9x1QHB6QoAyRDATP9Sm DXO/PHD49aeOHgOD6M5eEE126q/DDLoDtlths8Xspltb6vxrgcahIHTjtbXL89YPFm+K MpHA== X-Gm-Message-State: AOAM533qezn0R2QAO9/qOHmchjqi8+ZNcdEK+rDD2P9/MRL6sF+0RaOO 0czA3SmetmsJcshUy7onfTWaFF7fudeI6GK9CE+eKQ== X-Google-Smtp-Source: ABdhPJxVFZNlqFH6SB7Dlx8XdyQ9mNCZHs8J85wAaAx5F5vFSC8FJ2aGYpyW4pIuM3SBpyJ2QUvvqCfOO5zRP8tsrmI= X-Received: by 2002:a9d:4d1a:: with SMTP id n26mr9470622otf.54.1593560722050; Tue, 30 Jun 2020 16:45:22 -0700 (PDT) MIME-Version: 1.0 References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> In-Reply-To: From: Nick Harper Date: Tue, 30 Jun 2020 16:45:11 -0700 Message-ID: To: David Schinazi Cc: Yoav Nir , "" Content-Type: multipart/alternative; boundary="000000000000c46d5105a955c4a7" Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 23:45:25 -0000 --000000000000c46d5105a955c4a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This was discussed in the WGLC thread ( https://mailarchive.ietf.org/arch/browse/tls/?gbt=3D1&index=3D973qdoi0PmJbJ= zNU7Y-eC_a-WaI). I haven't seen any proposals of when it would be useful for a server to send a flag unsolicited. On Tue, Jun 30, 2020 at 4:31 PM David Schinazi wrote: > Hi Yoav, > > Could you elaborate on the rationale for this change please? > I was assuming that the ability for servers to send extensions not > requested by clients was useful. > > Thanks, > David > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir wrote: > >> Hi >> >> I=E2=80=99ve just submitted the following PR: >> >> https://github.com/tlswg/tls-flags/pull/4 >> >> Three changes: >> >> - It is no longer allowed to send an empty flags extension. If you >> don=E2=80=99t support any flags, don=E2=80=99t send the extension. >> - The server is no longer allowed to respond with flag types that the >> client didn=E2=80=99t indicate support for first. >> - I=E2=80=99ve split the extension description section into a format = section >> and a rules section >> >> >> Please comment. Barring any objections, I=E2=80=99ll merge the PR just b= efore the >> submission deadline. >> >> Yoav >> >> _______________________________________________ >> 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 > --000000000000c46d5105a955c4a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This was discussed in the WGLC thread (https://mailarchive.ietf.org/arch/browse/tls/?gbt=3D1&index= =3D973qdoi0PmJbJzNU7Y-eC_a-WaI). I haven't seen any proposals of wh= en it would be useful for a server to send a flag unsolicited.

On Tue, Jun 3= 0, 2020 at 4:31 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi Yoav,

Could you elaborate on the rationale for this change please?
I= was assuming that the ability for servers to send extensions not requested= by clients was useful.

Thanks,
David

On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hi

I=E2=80=99ve just submitted the following PR:


Three chan= ges:
  • It is no longer allowed to send an empty flags exten= sion.=C2=A0 If you don=E2=80=99t support any flags, don=E2=80=99t send the = extension.
  • The server is no longer allowed to respond with flag typ= es that the client didn=E2=80=99t indicate support for first.
  • I=E2= =80=99ve split the extension description section into a format section and = a rules section

Please comment. Barring = any objections, I=E2=80=99ll merge the PR just before the submission deadli= ne.

Yoav

_______________= ________________________________
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
--000000000000c46d5105a955c4a7-- From nobody Tue Jun 30 21:03:55 2020 Return-Path: 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 1622E3A0B37 for ; Tue, 30 Jun 2020 21:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 795m3MqFYugK for ; Tue, 30 Jun 2020 21:03:51 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EBF3A0B33 for ; Tue, 30 Jun 2020 21:03:51 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id w6so22991730ejq.6 for ; Tue, 30 Jun 2020 21:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oMqFG9hINBSntuDZON/7pPJ3QGtgnPmbfzXBUiWgNnw=; b=E8findABwqF33lcpDkTSB7HYoBWyWE30bGjO/PVcogYGljiOHZDiKX9+Nw80b2EHpE 9xKdu6JJwl4/SNb/3XcDOGwgmYs4cXytrAHBpKoinTiDXTz8qx9KwBKYLMbpBdPtubOM 1p+4+X7wDcXhKMdqTZ4Lk4QQ0pEgaHcvNYIa1uUkbKKP2wsRx9UBIACJheRPOvwxqKiF dKyubPRjYbXJ42IWqARe7LkRlCUderZfWqJeWZN2g5CL5ur3gDhHp9JrfBlYchFfwCHo 0SWuD73KBahTZ9HP/cyiVqUMiQnMWXQLHBsOuc4Zfi0Vsd6gIbodOWyhHZhUwdJ805v3 GL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oMqFG9hINBSntuDZON/7pPJ3QGtgnPmbfzXBUiWgNnw=; b=TsiN3rbWBGgIdd9pdZNaPSjAxRDM9ZFEzB9doBMakB9Qjw1D1RAzT3nazjh/O0/AAz FDcnGkJwXgi9gi9b2icvPy3oB5AhA6xOSB5y1ZGoJH8eUwt3BzpTcKzlRfeUTkda/n24 EREeHqfTFw7sE7uATCxZ1OaUcUzYjwXnqqY8ZUlNG4hMxa2UFVROpG6vcJd6vDULPV8O dhR/pCukPDx1XAwCBrpH0SIY8Rfvdkoyzh89aFSXAhTtDo5M3zMlXuFgGtx2rOO59/oy BV5B1D3N2OttVnD8iPBUeMlChCW2Dl4kD7hrN9qtYC87t/kFo3B0zqWRT7vXhn78Rh8R ZWxA== X-Gm-Message-State: AOAM530RIS9BAW/W4jqzzZ9PiwaqO4HefWkhDSeafesQGCnZTaN+KNWm Pxzc1ZpYlGiz4wj3F1Qu5NM= X-Google-Smtp-Source: ABdhPJxi+P7etZwJ58Xn9K/Ax9/gkNMKH7X7EF1Il5mY8zaDE4qk0dRRK/2AMvUyBKqZE1xzkZ5/TA== X-Received: by 2002:a17:906:d92e:: with SMTP id rn14mr22341220ejb.314.1593576229792; Tue, 30 Jun 2020 21:03:49 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y22sm3565979ejj.67.2020.06.30.21.03.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 21:03:48 -0700 (PDT) From: Yoav Nir Message-Id: <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BAFF8F50-205C-4FC0-ADBB-6F6C3C931605" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Jul 2020 07:03:47 +0300 In-Reply-To: Cc: "" To: David Schinazi References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 04:03:53 -0000 --Apple-Mail=_BAFF8F50-205C-4FC0-ADBB-6F6C3C931605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yeah, the thread that Nick mentioned. Also, since there are no such extensions defined in the base TLS 1.3 = spec, the server can=E2=80=99t assume that the client knows what either = the specific flag means, or the entire flags extension means.=20 So suppose we invent some new client authentication scheme for TLS, it = does make sense for the server to signal that it supports this so that = the client can do. But I don=E2=80=99t think it=E2=80=99s too onerous to = require that the client indicate support first. Yoav > On 1 Jul 2020, at 2:30, David Schinazi = wrote: >=20 > Hi Yoav, >=20 > Could you elaborate on the rationale for this change please? > I was assuming that the ability for servers to send extensions not = requested by clients was useful. >=20 > Thanks, > David >=20 > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir > wrote: > Hi >=20 > I=E2=80=99ve just submitted the following PR: >=20 > https://github.com/tlswg/tls-flags/pull/4 = >=20 > Three changes: > It is no longer allowed to send an empty flags extension. If you = don=E2=80=99t support any flags, don=E2=80=99t send the extension. > The server is no longer allowed to respond with flag types that the = client didn=E2=80=99t indicate support for first. > I=E2=80=99ve split the extension description section into a format = section and a rules section >=20 > Please comment. Barring any objections, I=E2=80=99ll merge the PR just = before the submission deadline. >=20 > Yoav >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_BAFF8F50-205C-4FC0-ADBB-6F6C3C931605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yeah,= the thread that Nick mentioned.

Also, since there are no such extensions defined in the base = TLS 1.3 spec, the server can=E2=80=99t assume that the client knows what = either the specific flag means, or the entire flags extension = means. 

So = suppose we invent some new client authentication scheme for TLS, it does = make sense for the server to signal that it supports this so that the = client can do. But I don=E2=80=99t think it=E2=80=99s too onerous to = require that the client indicate support first.

Yoav

On 1 Jul = 2020, at 2:30, David Schinazi <dschinazi.ietf@gmail.com> wrote:

Hi Yoav,

Could you elaborate on the rationale for this change = please?
I was assuming that the ability for servers = to send extensions not requested by clients was useful.

Thanks,
David

On Mon, Jun 29, 2020 at 2:34 PM Yoav = Nir <ynir.ietf@gmail.com> wrote:
Hi

I=E2=80=99ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:
  • It is no longer allowed to send = an empty flags extension.  If you don=E2=80=99t support any flags, = don=E2=80=99t send the extension.
  • The server is no = longer allowed to respond with flag types that the client didn=E2=80=99t = indicate support for first.
  • I=E2=80=99ve split the = extension description section into a format section and a rules = section

Please comment. Barring any objections, I=E2=80=99ll merge = the PR just before the submission deadline.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_BAFF8F50-205C-4FC0-ADBB-6F6C3C931605-- From nobody Tue Jun 30 21:17:45 2020 Return-Path: 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 61A893A0C0F for ; Tue, 30 Jun 2020 21:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=ZFq+ZgJc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QT4QGUJ/ 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 flNj2CTSrDMu for ; Tue, 30 Jun 2020 21:17:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76F83A0C00 for ; Tue, 30 Jun 2020 21:17:42 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2587A5C0164 for ; Wed, 1 Jul 2020 00:17:42 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 01 Jul 2020 00:17:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=PGN3O D+38HmH/ecFkP/6qVcJ3exeXtrh5BnY/WijkmY=; b=ZFq+ZgJcF91TszvACC17i YJEiAVQT2SyZ0uS4uYcyq0OhqoCGjEpWt/IwlLm3lHjO7GyeGMPi+wT0ezSK8iBx j2C9Uz0H8LwiVL2GEWtbKtY/VZUMoXOTboJMPhAP/ZEFBxbKQJ3mAY2o7Dy3k8vj 4MbkaPD9XQlnOAZTfBSeUM9PoVDD1nRUNa2jwO5tHYZrq+J7dQKABO1UMKvRJ/n2 5mIqomycz/UPwKgeTPuVuCOPTBKQTeGuI0cin88Ou+tBHxP8hYAZ9ZyQ913RzbMO Kzu69V4h3EsJ3lHaSLwqd+8QcERwxRYibIcx0rOq26RjECCCPfg02Bl31wOlB7Vn g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=PGN3OD+38HmH/ecFkP/6qVcJ3exeXtrh5BnY/Wijk mY=; b=QT4QGUJ/5bmYwN9laP5j023lGMOxa3ZVOWRK4wdixJUH4NJMnExdX+0QX 7IbwB4+KJh4JrhNSUDUgvaCfdJFvPBprgTBr9ZWBumSgDeMzBlfS4oSRorQXo4b9 j3y15ttZQOrmsbviij8qw6a1mK0uRoYVqtHfSprJxMfFp9ic52LLjvLAyoU+7j6L hsBlVq62GKYwRTJ7mhZKQUZifUEo/LM4JapTVSmAZNPWBwaWMhFdeaEn3Y9hd6fO GahGetchsl3A5h+qS4awc9FZG03Oi/7VdHqDpiHaExzVtkYIgSEwZxLBaJmsSgHN wOeDy+I2QlqcdW9JGERLXvI2lReFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddugdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehhedvhfehvefggeejtd egjeduveetleejvdekjeejhfekieekudelffdvudefffenucffohhmrghinhepghhithhh uhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 993ADE00CE; Wed, 1 Jul 2020 00:17:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: In-Reply-To: <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com> References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com> Date: Wed, 01 Jul 2020 14:17:21 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 04:17:44 -0000 More to the point, this makes it more difficult to analyze relative to a= n empty "flag" extension of the likes we currently use. I haven't implemented this, but I imagine one strategy would be to rewri= te these flags and pretend that they were empty extensions. That would = allow implementations to reuse a lot of infrastructure, like the stuff w= e added for custom extensions. That would be more difficult if the serv= er can speak first. On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote: > Yeah, the thread that Nick mentioned. >=20 > Also, since there are no such extensions defined in the base TLS 1.3=20= > spec, the server can=E2=80=99t assume that the client knows what eithe= r the=20 > specific flag means, or the entire flags extension means.=20 >=20 > So suppose we invent some new client authentication scheme for TLS, it= =20 > does make sense for the server to signal that it supports this so that= =20 > the client can do. But I don=E2=80=99t think it=E2=80=99s too onerous = to require that=20 > the client indicate support first. >=20 > Yoav >=20 > > On 1 Jul 2020, at 2:30, David Schinazi wr= ote: > >=20 > > Hi Yoav, > >=20 > > Could you elaborate on the rationale for this change please? > > I was assuming that the ability for servers to send extensions not r= equested by clients was useful. > >=20 > > Thanks, > > David > >=20 > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir wrote= : > >> Hi > >>=20 > >> I=E2=80=99ve just submitted the following PR: > >>=20 > >> https://github.com/tlswg/tls-flags/pull/4 > >>=20 > >> Three changes: > >> * It is no longer allowed to send an empty flags extension. If you= don=E2=80=99t support any flags, don=E2=80=99t send the extension. > >> * The server is no longer allowed to respond with flag types that = the client didn=E2=80=99t indicate support for first. > >> * I=E2=80=99ve split the extension description section into a form= at section and a rules section > >>=20 > >> Please comment. Barring any objections, I=E2=80=99ll merge the PR j= ust before the submission deadline. > >>=20 > >> Yoav > >>=20 > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jun 30 22:24:44 2020 Return-Path: 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 AF4243A0D13 for ; Tue, 30 Jun 2020 22:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=salowey-net.20150623.gappssmtp.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 xI4BGs9UOwfF for ; Tue, 30 Jun 2020 22:24:39 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBC33A0D12 for ; Tue, 30 Jun 2020 22:24:38 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id o38so17538552qtf.6 for ; Tue, 30 Jun 2020 22:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xirfa+TJ8De0PdeKy+0iuU3QN/jqKB8IR32KlxU0oxw=; b=Lx2UqqYkWQwotBcom54Xu/tyZVl23LSpZYi3rmNgVU/Li+cJKHVSmRZDtMxd2AnmK5 2FGdOTcQ2Mbr2S+iNXdArsMHeUj0jmnrT8x8Ms6vjf/VAy4gphG+9Z6ZoE9FY4mSyiEW Rbgmw/kgDtNTTh5qIsAQqS5jmVZDZUUhW9KUm45ob+pBlm/GhR6eMXPokOSOggIBQ53L i4F5W7b3BIpp7VORBfVCr25rDGLdTaw5pzFVnLAjuiijmj7jcC6LgmzFo4KvzRE6DWgi 3IbQ/DGaUfPr7tiiomVnz0FV41DJgK9AOoqdxUlQ5rlHfBV0/tt1J8tKiHUOBT0fXVkj /GUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xirfa+TJ8De0PdeKy+0iuU3QN/jqKB8IR32KlxU0oxw=; b=GjbgG4w0sRB/qI3lCJgj4C2OHXH3LyIoayrz27gkgKUuwA3PANJ8Je1h95YoBrOP6Y 7ePp8ggnKwNvCRj2QF6JE9WXM04s2ngqX8DN2TNBQ4CMbmWhHtlbcb9O7I68L4vV76R4 PnH1LkP3oDNGk3xc0knHHZqnpto3F2tAN3btrIEUF6BHc/bx5s25cJ7LbuexcHxTzD0u gapaYz63YkqpDrJLW6gUSmmwGGVn5o17fbD8zhttX7o+LAHcdgM+MfxUEoJzDV3hqygO fp/JedoAtYKlEVGU/4SshCFnFBKxVnodjAqzm1+J6KXOcToW73bJqUVSUtB7oCaSDZhL JsvQ== X-Gm-Message-State: AOAM533S4MIWn2/2T3HBlky4BJzyqRVF6IGjWCEiaKE2WONVQv9r2WVn eQSgzdnb8Q5HkPZx7LT1ir3pC3CFrfFN1YKt/Mb9TA== X-Google-Smtp-Source: ABdhPJxG0p5xT8nkE99QPloK2HR6/WCF/TOdsm0M8GHpcgiSpG5tsqSOhbVjoYjKsB+ZcFQiSIE8tc0cHIUaeU413qw= X-Received: by 2002:ac8:22d2:: with SMTP id g18mr25140104qta.38.1593581077505; Tue, 30 Jun 2020 22:24:37 -0700 (PDT) MIME-Version: 1.0 References: <31B75BDB-8E67-40C5-AF70-4EAA9BC2E065@akamai.com> In-Reply-To: From: Joseph Salowey Date: Tue, 30 Jun 2020 22:24:26 -0700 Message-ID: To: Daniel Migault Cc: "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="0000000000000bbac005a95a82e2" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 05:24:43 -0000 --0000000000000bbac005a95a82e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2020 at 9:10 AM Daniel Migault wrote: > Hi Joe, > > Thanks for the feed back, please find my responses inline. > > Yours, > Daniel > > ------------------------------ > *From:* Joseph Salowey > *Sent:* Monday, June 29, 2020 10:01 PM > *To:* Daniel Migault > *Cc:* Salz, Rich ; < > tls@ietf.org> > *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS > > HI Daniel > > Some comments inline below: > > On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault < > daniel.migault@ericsson.com> wrote: > > Hi, > > The draft has a number of nits and errors. Among others: > > The related work section mentions KEYLESS and subcert being complementary > that is KEYLESS can perform the operations associated to the DC and/or > those associated to the cert key. I do not think that is correct. KEYLESS > does not support TLS 1.3 while DC only works with TLS 1.3. The LURK > extension for TLS 1.3 [draft-mglt-lurk-tls13] should be mentioned instead= . > As LURK was mentioned during the adoption period and until version 05 tha= t > should not cause any issues. > > Technologies only available for TLS 1.2 may be mentioned in the related > work section. [draft-mglt-lurk-tls12] should be mentioned similarly to > KEYLESS as it addresses the security concerns of KEYLESS. > > > [Joe] KEYLESS is a deployed technology that is addressing some of the sam= e > use cases as Delegated credentials. I'm not sure of the status of > draft-mglt-lurk-tls13. > > > > To respond to your question regarding the status of draft-mglt-lurk-tls13 > it is a work in progress. That said, I am a bit upset by the comment, so > let me clarify my comment just in case I mis-interpreted something or I a= m > completely wrong. > > [Joe] I apologize if my comment came off a bit brusk. I'm not sure if the paper referenced is just applicable to TLS 1.2 or not, but if it is I can see how the text could be misleading. I think the security considerations are reasonably clear since the extension is a 1.3 extension, however I wouldn't hurt to mention that the problem manifests itself in TLS 1.3 because of 1.2 usage. I'll let the authors take a crack at the comments inline since they have more context. I'm not sure if this document is the place to have a discussion about LURK. > Firstly, I tried to briefly describe the type of errors I think I noticed= , > so the co-authors do not need to parse all comments to get an idea of the > types of errors. In this case, I had the impression that the subcert was > initially intended to be an extension for TLS 1.2 and TLS 1.3, and the > scope of TLS 1.2 has been removed in version 02 while not all text have > been updated accordingly. It is a bit more than nits but I do not see > this as a major concern. > > The related work section positions KEYLESS and subcert and think that is > useful. My understanding is that KEYLESS only work for TLS 1.2 and for th= e > server and subcert only works with TLS 1.3. When they shared a common TLS > version, it was possible to use these 2 mechanisms together in a given TL= S > session. Typically KEYLESS could host the private key of the DC or the > X509 certificate and proceed to the appropriated cryptographic operations= . > This is at least my understanding of the text below: > > """ > > These two mechanisms can be complementary. A server could use > credentials for clients that support them, while using [KEYLESS ] to > support legacy clients. The private key for a delegated credential > can be used in place of a certificate private key, so it is important > that the Front-End and Back-End are parties that have a trusted > relationship. > > """ > > Given that KEYLESS and DC work with different versions it seems hard to m= e > that this could happen. I suspect there is an error and that KEYLESS is > deployed or not seems to me a bit orthogonal to the fact that it does not > achieve what is being written - or at least what I am understanding from > the reading. > > > I believe the case of using KEYLESS-like technologies is important to be > mentioned and I believe that draft-mglt-tls13 while being work in progres= s > fits the use case while KEYLESS does not. > As mentioned in my text, I do not think adding LURK in the related work > section represents a major update as the technology has been mentioned in > the related work section during the adoption, and was there until version > 05, and I do not recall this has raised any concerns at least on the > mailing list. Digging on github I could only find [1], though I might hav= e > missed some discussions. > > For the sake of clarity and trying to address potential - and purely > speculative - questions that may lie behind the initial question: > * I think the related work section is useful as it clarifies concepts tha= t > had been confusing in the past. In addition, I have the impression that > delegation may not be entirely deployed with DC and that complementary > technology is needed - at least for the peer not supporting the extension= . > * I am not asking that KEYLESS be removed even if - as I understand - > KEYLESS only address TLS 1.2. I think that is clearly stated. > * I do not think the status of work in progress prevents soem work to be > mentioned in a related work section. In some cases a draft status is > sufficient for the IANA to assign code points. > * I also believe that [draft-mglt-lurk-tls12] should be mentioned as it > addresses some security concerns among others the signing oracle. It seem= s > there are some misunderstanding around this [1]. > > If there is anything you would like me to clarify, feel free to let me > know. I also believe that clarifications are provided in the inline > comments. > > [1] https://github.com/tlswg/tls-subcerts/issues/30 > > > > > There are other places where the extensions is mentioned together with TL= S > 1.2 that needs to be updated. > > > [Joe] The only place I see TLS 1.2 mentioned is in the security > consideration section in reference to the Bleichenbacher attack which is > relevant if a server supports both TLS 1.3 and RSA key exchange with TLS > 1.2. > > > That is at least one place I saw TLS 1.2 being mentioned. Note that the > related work section also revealed some issue associated to TLS 1.2 witho= ut > specifying the version. I suspected that these errors came from the initi= al > support of TLS 1.2 in the beginning and wanted the co-authors to carefull= y > review the draft in that perspective. I do not raise a comment to each of > these and leave the co-authors to look at this carefully. > > It is correct that some servers may support two versions of TLS but I am > not very familiar on how this is handled and operated. As a result I am n= ot > able to clearly mention if there is an error or not and this is why I kep= t > the statement quite generic ( "Other places where the extension is > mentioned together with TLS 1.2" explicitly or not.. > > That said, I believe that if the section is entirely dedicated to the cas= e > where two versions are being co-hosted, I believe that should be at least > clarified as well as other conditions such as (using the same key over th= e > two versions, supporting signing and encryption for that key...). Again I > am not very familiar with what is common practice in that scope. At least > my perception of the text below is that the section was considering the u= se > of DC in a context of TLS 1.2. I do not see this as a big issue either > updating this section > > """ > > When TLS 1.2 servers support RSA key exchange, .... > > """ > """ > > For > TLS 1.2 servers that support RSA key exchange using a DC-enabled end- > entity certificate, a hypothetical signature forgery attack would > allow forging a signature over a delegated credential. > > """ > > > I also think that test vectors would be good as well as a link to a forma= l > verification publication (if available). > > Please see all my comments inline, I hope they help. > > [Joe] Thanks, I didn't get through these yet. The authors should take a > look. > > > Going through the comments is not very easy, this is why I tried to > provide a brief overview. I am happy to do otherwise if that helps. > > > > Yours, > Daniel > > ---- > > Delegated Credentials for TLS > draft-ietf-tls-subcerts-09 > > [...] > > 1. Introduction > > Typically, a TLS server uses a certificate provided by some entity > other than the operator of the server (a "Certification Authority" or > CA) [RFC8446] [RFC5280]. This organizational separation makes the > TLS server operator dependent on the CA for some aspects of its > operations, for example: > > * Whenever the server operator wants to deploy a new certificate, it > has to interact with the CA. > > * The server operator can only use TLS signature schemes for which > the CA will issue credentials. > > These dependencies cause problems in practice. Server operators > often deploy TLS termination services in locations such as remote > data centers or Content Delivery Networks (CDNs) where it may be > difficult to detect key compromises. Short-lived certificates may be > used to limit the exposure of keys in these cases. > > > I believe it would be clearer to > summarize the problem and link it to the > use case. I would propose something > around: > > These dependencies cause problems in > practice, the management of key exposure > necessarily requires an interaction with > the CA. > > Typically server operators.... > > > However, short-lived certificates need to be renewed more frequently > than long-lived certificates. If an external CA is unable to issue a > certificate in time to replace a deployed certificate, the server > would no longer be able to present a valid certificate to clients. > With short-lived certificates, there is a smaller window of time to > renew a certificates and therefore a higher risk that an outage at a > CA will negatively affect the uptime of the service. > > To reduce the dependency on external CAs, this document proposes a > limited delegation mechanism that allows a TLS peer to issue its own > credentials within the scope of a certificate issued by an external > CA. These credentials only enable the recipient of the delegation to > speak for names that the CA has authorized. For clarity, we will > refer to the certificate issued by the CA as a "certificate", or > "delegation certificate", and the one issued by the operator as a > "delegated credential" or "DC". > > > From the text it is unclear why the > signature scheme appears to be a > constraint as well how it does not opens > to some sort of downgrade attacks if > left to the operator. > > > > 3. Solution Overview > > [...] > > 3.1. Rationale > > Delegated credentials present a better alternative than other > delegation mechanisms like proxy certificates [RFC3820] for several > reasons: > > * There is no change needed to certificate validation at the PKI > layer. > > * X.509 semantics are very rich. This can cause unintended > consequences if a service owner creates a proxy certificate where > the properties differ from the leaf certificate. For this reason, > delegated credentials have very restricted semantics that should > not conflict with X.509 semantics. > > * Proxy certificates rely on the certificate path building process > to establish a binding between the proxy certificate and the > server certificate. Since the certificate path building process > is not cryptographically protected, it is possible that a proxy > certificate could be bound to another certificate with the same > public key, with different X.509 parameters. Delegated > credentials, which rely on a cryptographic binding between the > entire certificate and the delegated credential, cannot. > > * Each delegated credential is bound to a specific signature > algorithm that may be used to sign the TLS handshake ([RFC8446] > > > > > Barnes, et al. Expires 28 December 2020 [Page 6] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > section 4.2.3). This prevents them from being used with other, > perhaps unintended signature algorithms. > > > It is not clear to me why there is a > "may be used". I suppose it concerns the > use of the DC not the algorithm but that > was confusing. > > I also believe that the specific > signature algorithm to sign the > delegated credential could be part of > the rational. > > > 3.2. Related Work > > Many of the use cases for delegated credentials can also be addressed > using purely server-side mechanisms that do not require changes to > client behavior (e.g., a PKCS#11 interface or a remote signing > mechanism [KEYLESS]). These mechanisms, however, incur per- > transaction latency, since the front-end server has to interact with > a back-end server that holds a private key. The mechanism proposed > in this document allows the delegation to be done off-line, with no > per-transaction latency. The figure below compares the message flows > for these two mechanisms with TLS 1.3 [RFC8446]. > > Remote key signing: > > Client Front-End Back-End > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > | |<---remote sign---->| > |<---CertVerify-----| | > | ... | | > > > Delegated credentials: > > Client Front-End Back-End > | |<--DC distribution->| > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > |<---CertVerify-----| | > | ... | | > > These two mechanisms can be complementary. A server could use > credentials for clients that support them, while using [KEYLESS] to > support legacy clients. > > > I believe that this sentence does not > show any complementary as subcert and > KEYLESS are targeting different version > of TLS, so they can hardly be > complementary. However (and luckily) > LURK provides an extension for TLS 1.3 > [draft-mglt-lurk-tls13] which enable a > complementary use of these mechanisms > these mechanisms. I believe that would > be good to indicate the reason they > complement each other which is that LURK > protects the credentials for its > operations. These operations could be > performed in the scope of subcert or TLS > 1.3. > > Note also that in a related section it > also worth mentioning that credentials > may be managed in different ways and > KEYLESS represents an valuable way to > protect and manage these credentials in > TLS 1.2. However, KEYLESS is known to > presents some vulnerabilities (PFS, > signing oracle) so the protection > remains limited while the LURK extension > for TLS 1.2 [draft-mglt-lurk-tls12] > addressed these issues and as a result > should provide a better protection. > > > The private key for a delegated credential > can be used in place of a certificate private key, so it is important > that the Front-End and Back-End are parties that have a trusted > relationship. > > > Use of short-lived certificates with automated certificate issuance, > e.g., with Automated Certificate Managment Environment (ACME) > > Management > > [RFC8555], reduces the risk of key compromise, but has several > limitations. Specifically, it introduces an operationally-critical > dependency on an external party. It also limits the types of > > > > Barnes, et al. Expires 28 December 2020 [Page 7] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > algorithms supported for TLS authentication to those the CA is > willing to issue a certificate for. Nonetheless, existing automated > issuance APIs like ACME may be useful for provisioning delegated > credentials. > > 4. Delegated Credentials > > While X.509 forbids end-entity certificates from being used as > issuers for other certificates, it is valid to use them to issue > other signed objects as long as the certificate contains the > digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a > new signed object format that would encode only the semantics that > are needed for this application. The credential has the following > structure: > > struct { > uint32 valid_time; > SignatureScheme expected_cert_verify_algorithm; > opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; > } Credential; > > valid_time: Time in seconds relative to the beginning of the > delegation certificate's notBefore value after which the delegated > credential is no longer valid. This MUST NOT exceed 7 days. > > I believe the behavior of the "verifying > peer" should also be specified maybe > with a reference. > > > > expected_cert_verify_algorithm: The signature algorithm of the > credential key pair, where the type SignatureScheme is as defined > in [RFC8446]. This is expected to be the same as > CertificateVerify.algorithm sent by the server. Only signature > algorithms allowed for use in CertificateVerify messages are > allowed. When using RSA, the public key MUST NOT use the > rsaEncryption OID, as a result, the following algorithms are not > allowed for use with delegated credentials: rsa_pss_rsae_sha256, > rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. > > > It is unclear whether the > expected_cert_verify_algorithm and > CertificateVerify.algorithm needs to be > checked and what needs to be done in > case of mismatch (with the RSA caveat). > I believe that should be clarified. > > > > ASN1_subjectPublicKeyInfo: The credential's public key, a DER- > encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. > > The delegated credential has the following structure: > > struct { > Credential cred; > SignatureScheme algorithm; > opaque signature<0..2^16-1>; > } DelegatedCredential; > > algorithm: The signature algorithm used to verify > DelegatedCredential.signature. > > > I am wondering if any checks should be > performed with the > CertificateVerify.algorithm or if any > algorithm would be acceptable. Unless I > am missing something it seems a weak > algorithm can be used - assuming the > registry contains such weak algorithms. > > > > Barnes, et al. Expires 28 December 2020 [Page 8] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > signature: The delegation, a signature that binds the credential to > the end-entity certificate's public key as specified below. The > signature scheme is specified by DelegatedCredential.algorithm. > > [...] > > 4.1.1. Server Authentication > > A client which supports this specification SHALL send a > "delegated_credential" extension in its ClientHello. The body of the > extension consists of a SignatureSchemeList: > > > > > > Barnes, et al. Expires 28 December 2020 [Page 9] > > Internet-Draft Delegated Credentials for TLS June 2020 > > > struct { > SignatureScheme supported_signature_algorithm<2..2^16-2>; > } SignatureSchemeList; > > If the client receives a delegated credential without indicating > support, then the client MUST abort with an "unexpected_message" > alert. > > If the extension is present, the server MAY send a delegated > credential; if the extension is not present, the server MUST NOT send > a delegated credential. The server MUST ignore the extension unless > TLS 1.3 or a later version is negotiated. > > > The server MUST send the delegated credential as an extension in the > CertificateEntry of its end-entity certificate; the client SHOULD > ignore delegated credentials sent as extensions to any other > certificate. > > The expected_cert_verify_algorithm field MUST be of a type advertised > by the client in the SignatureSchemeList and is considered invalid > otherwise. Clients that receive invalid delegated credentials MUST > terminate the connection with an "illegal_parameter" alert. > > > I am wondering what would prevent any > downgrade attacks if the > SignatureSchemeList and > signature_algorithms have two different > sets of lists. My current understanding > is that these extensions are handled > independently, but I might be missing > something. > > I am wondering if that would be > appropriated to specify the signature of > the CertificateVerify depending on the > presence of the delegated credential - I > mean the key used to generate it. > > > > [...] > > 4.1.3. Validating a Delegated Credential > > On receiving a delegated credential and a certificate chain, the peer > validates the certificate chain and matches the end-entity > certificate to the peer's expected identity. It also takes the > following steps: > > 1. Verify that the current time is within the validity interval of > the credential. This is done by asserting that the current time > is no more than the delegation certificate's notBefore value plus > DelegatedCredential.cred.valid_time. > > 2. Verify that the credential's remaining validity time is no more > than the maximum validity period. This is done by asserting that > the current time is no more than the delegation certificate's > notBefore value plus DelegatedCredential.cred.valid_time plus the > maximum validity period. > > 3. Verify that expected_cert_verify_algorithm matches the scheme > indicated in the peer's CertificateVerify message and that the > algorithm is allowed for use with delegated credentials. > > > I am wondering if a reference to specify > what allowed would not be needed unless > it means advertised in the extension. > > > > 4. Verify that the end-entity certificate satisfies the conditions > in Section 4.2. > > 5. Use the public key in the peer's end-entity certificate to verify > the signature of the credential using the algorithm indicated by > DelegatedCredential.algorithm. > > If one or more of these checks fail, then the delegated credential is > deemed invalid. Clients and servers that receive invalid delegated > credentials MUST terminate the connection with an "illegal_parameter" > alert. If successful, the participant receiving the Certificate > message uses the public key in the credential to verify the signature > in the peer's CertificateVerify message. > > [...] > > 7. Security Considerations > > [...] > > 7.6. The Impact of Signature Forgery Attacks > > When TLS 1.2 servers support RSA key exchange, they may be vulnerable > to attacks that allow forging an RSA signature over an arbitrary > message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a > mitigation strategy requiring careful implementation of timing > resistant countermeasures for preventing these attacks. Experience > shows that in practice, server implementations may fail to fully stop > these attacks due to the complexity of this mitigation [ROBOT]. For > TLS 1.2 servers that support RSA key exchange using a DC-enabled end- > entity certificate, a hypothetical signature forgery attack would > allow forging a signature over a delegated credential. The forged > credential could then be used by the attacker as the equivalent of a > man-in-the-middle certificate, valid for 7 days. > > > I do not see the relevance to TLS 1.3. > > > Server operators should therefore minimize the risk of using DC- > enabled end-entity certificates where a signature forgery oracle may > be present. If possible, server operators may choose to use DC- > enabled certificates only for signing credentials, and not for > serving non-DC TLS traffic. Furthermore, server operators may use > elliptic curve certificates for DC-enabled traffic, while using RSA > certificates without the DelegationUsage certificate extension for > non-DC traffic; this completely prevents such attacks. > > Note that if a signature can be forged over an arbitrary credential, > the attacker can choose any value for the valid_time field. Repeated > signature forgeries therefore allow the attacker to create multiple > delegated credentials that can cover the entire validity period of > the certificate. Temporary exposure of the key or a signing oracle > may allow the attacker to impersonate a server for the lifetime of > the certificate. > > > ------------------------------ > *From:* TLS on behalf of Salz, Rich 40akamai.com@dmarc.ietf.org> > *Sent:* Monday, June 29, 2020 12:00 PM > *To:* Joseph Salowey ; > *Subject:* Re: [TLS] 2nd WGLC for Delegated Credentials for TLS > > > I=E2=80=99d still like to see test vectors. > > --0000000000000bbac005a95a82e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Jun 30, 2020 at 9:10 AM Daniel Migault <daniel.migault@ericsson.com= > wrote:
Hi Joe,=C2=A0

Thanks for the feed back, please find my responses inline.

Yours,=C2=A0
Daniel

From: Joseph Salowey <joe@salowey.net>
Sent: Monday, June 29, 2020 10:01 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
=C2=A0
HI Daniel

Some comments inline below:

On Mon, Jun 29, 2020 at 5:47 PM Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi,=C2=A0

The draft has a number of nits and errors. Among = others:=C2=A0

The related work section mentions KEYLESS and sub= cert being complementary that is KEYLESS can perform the operations associa= ted to the DC and/or those associated to the cert key. I do not think that = is correct. KEYLESS does not support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 1.3 [= draft-mglt-lurk-tls13] should be mentioned instead. As LURK was mentioned d= uring the adoption period and until version 05 that should not cause any is= sues.=C2=A0

Technologies only available for TLS 1.2 may be me= ntioned in the related work section.=C2=A0=C2=A0[draft-mglt-lurk-tls12]=C2=A0should be mentioned=C2=A0similarly to KEYLESS as it addresses the s= ecurity concerns of KEYLESS.=C2=A0


[Joe] KEYLESS is a deployed technology that is addres= sing some of the same use cases as Delegated credentials.=C2=A0 I'm not= sure of the status of draft-mglt-lurk-tls13.=C2=A0

=C2=A0
<mglt>
To respond to your question regarding the status of=C2=A0draft-mglt-lu= rk-tls13 it is a work in progress. That said, I am a bit upset by the comme= nt, so let me clarify my comment just in case I mis-interpreted something o= r I am completely wrong.=C2=A0
=C2=A0=C2=A0

[Joe] I apologiz= e if my comment came off a bit brusk.=C2=A0 I'm not sure if the paper r= eferenced is just applicable to TLS 1.2 or not,=C2=A0but if it is I can see= how the=C2=A0text could be misleading.=C2=A0 I think the security consider= ations are reasonably clear since the extension is a 1.3 extension, however= I wouldn't hurt to mention that the problem manifests itself in TLS 1.= 3 because of 1.2 usage.=C2=A0 I'll let the authors take a crack at the = comments inline since they have more context.=C2=A0 I'm not sure if thi= s document is the place to have a discussion about LURK.=C2=A0
=
=C2=A0
Firstly, I tried to briefly describe the type of errors I think I noti= ced, so the co-authors do not need to parse all comments to get an idea of = the types of errors. In this case, I had the impression that the subcert wa= s initially intended to be an extension for TLS 1.2 and TLS 1.3, and the scope of TLS 1.2 has been removed in vers= ion 02 while not all text have been updated accordingly. It is a bit more t= han nits but I do not see this=C2=A0as a major concern.

The related work section positions KEYLESS and subcert=C2=A0and think = that is useful. My understanding is that KEYLESS only work for TLS 1.2 and = for the server and subcert=C2=A0only works with TLS 1.3. When they shared a= common TLS version, it was possible to use these 2 mechanisms together in a given TLS session.=C2=A0 Typically KEYLES= S could host the private key of the DC or the X509 certificate and proceed = to the appropriated cryptographic operations. This is at least my understan= ding of the text below:=C2=A0

"""
"""=C2=A0=C2=A0

Given that KEYLESS and DC work with different versions it seems hard t= o me that this could happen. I suspect there is an error and that KEYLESS i= s deployed or not seems to me a bit orthogonal to the fact that it does not= achieve what is being written - or at least what I am understanding from the reading.=C2=A0

I believe the case of using KEYLESS-like technologies is important to = be mentioned and I believe that draft-mglt-tls13 while being work in progre= ss fits the use case while KEYLESS does not.=C2=A0
As mentioned in my text, I do not think adding LURK in the related wor= k section represents a major update as the technology has been mentioned in= the related work section during the adoption, and was there until version = 05, and I do not recall this has raised any concerns at least on the mailing list. Digging on github I coul= d only find [1], though I might have missed some discussions.

For the sake of clarity and trying to address potential - and purely s= peculative - questions that may lie behind the initial question:=C2=A0
* I think the=C2=A0related work section is useful as it clarifies conc= epts that had been confusing in the past. In addition, I have the impressio= n that delegation may not be entirely deployed with DC and that complementa= ry technology is needed - at least for the peer not supporting the extension.=C2=A0=C2=A0
* I am not asking that KEYLESS be removed even if - as I understand - = KEYLESS only address TLS 1.2. I think that is clearly stated.=C2=A0
* I do not think the status of work in progress prevents soem work to = be mentioned in a related work section. In some cases=C2=A0a draft status i= s sufficient for the IANA to assign code points.=C2=A0 =C2=A0 =C2=A0
* I also believe=C2=A0that [draft-mglt-lurk-tls12] should be mentioned= as it addresses some security concerns among others the signing=C2=A0oracl= e. It seems there are some misunderstanding around this=C2=A0[1].

If there is anything you would like me to clarify, feel free to let=C2= =A0 me know. I also believe that clarifications are provided in the inline = comments.


</mglt>=C2=A0
There are other places where the= extensions is mentioned together with TLS 1.2 that needs to be updated. = =C2=A0


[Joe] The only place I see TLS 1.2 mentioned is in th= e security consideration section in reference to the=C2=A0Bleichenbacher attack which is relevant if a server support= s both TLS 1.3 and RSA key exchange with TLS 1.2.=C2=A0=C2=A0
=C2=A0
<mglt>
That is at least one place I saw TLS 1.2 being mentioned. Note that th= e related work section also revealed some issue associated to TLS 1.2 witho= ut specifying the version. I suspected that these errors came from the init= ial support of TLS 1.2 in the beginning and wanted the co-authors to carefully review the draft in that perspectiv= e. I do not raise a comment to each of these and leave the co-authors to lo= ok at this carefully.

It is correct that some servers may support two versions of TLS but I = am not very familiar on how this is handled and operated. As a result I am = not able to clearly mention if there is an error or not and this is why I k= ept the statement quite generic ( "Other places where the extension is mentioned together with TLS 1.= 2" explicitly=C2=A0or not..=C2=A0

That said, I believe that if the section is entirely dedicated to the = case where two versions are being co-hosted, I believe that should be at le= ast clarified as well as other conditions such as (using the same key over = the two versions, supporting signing and encryption for that key...). Again I am not very familiar=C2=A0with wh= at is common practice=C2=A0in that scope. At least my perception of the tex= t below is that the section was considering the use of DC in a context of T= LS 1.2. I do not see this as a big issue either updating this section

"""
When TLS 1.2 servers support RSA key exchange, =
....
"""
"""
For
   TLS 1.2 servers that support RSA key exchange using a DC-enabled end-
   entity certificate, a hypothetical signature forgery attack would
   allow forging a signature over a delegated credential.
"""
</mglt>=C2=A0

I also think that test vectors w= ould be good as well as a link to a formal verification publication (if ava= ilable).

Please see all my comments inlin= e, I hope they help.

[Joe] Thanks,=C2=A0 I didn't get through these ye= t.=C2=A0 The authors should take a look.=C2=A0

<mglt>
Going through the comments is not very easy, this is why I tried to pr= ovide a brief overview. I am happy to do otherwise if that helps.=C2=A0
</mglt>=C2=A0
=C2=A0
Yours,=C2=A0
Daniel

----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegated Credentials for TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-subcerts-09

[...]

1.=C2=A0 Introduction

=C2=A0 =C2=A0Typically, a TLS server uses a certi= ficate provided by some entity
=C2=A0 =C2=A0other than the operator of the serve= r (a "Certification Authority" or
=C2=A0 =C2=A0CA) [RFC8446] [RFC5280].=C2=A0 This = organizational separation makes the
=C2=A0 =C2=A0TLS server operator dependent on the= CA for some aspects of its
=C2=A0 =C2=A0operations, for example:

=C2=A0 =C2=A0* =C2=A0Whenever the server operator= wants to deploy a new certificate, it
=C2=A0 =C2=A0 =C2=A0 has to interact with the CA.=

=C2=A0 =C2=A0* =C2=A0The server operator can only= use TLS signature schemes for which
=C2=A0 =C2=A0 =C2=A0 the CA will issue credential= s.

=C2=A0 =C2=A0These dependencies cause problems in= practice.=C2=A0 Server operators
=C2=A0 =C2=A0often deploy TLS termination service= s in locations such as remote
=C2=A0 =C2=A0data centers or Content Delivery Net= works (CDNs) where it may be
=C2=A0 =C2=A0difficult to detect key compromises.= =C2=A0 Short-lived certificates may be
=C2=A0 =C2=A0used to limit the exposure of keys i= n these cases.

<mglt>
I believe it would be clearer to
summarize the problem and link it to the
use case. I would propose something
around:

These dependencies cause problems in
practice, the management of key exposure
necessarily requires an interaction with
the CA.=C2=A0

Typically server operators....
</mglt>

=C2=A0 =C2=A0However, short-lived certificates ne= ed to be renewed more frequently
=C2=A0 =C2=A0than long-lived certificates.=C2=A0 = If an external CA is unable to issue a
=C2=A0 =C2=A0certificate in time to replace a dep= loyed certificate, the server
=C2=A0 =C2=A0would no longer be able to present a= valid certificate to clients.
=C2=A0 =C2=A0With short-lived certificates, there= is a smaller window of time to
=C2=A0 =C2=A0renew a certificates and therefore a= higher risk that an outage at a
=C2=A0 =C2=A0CA will negatively affect the uptime= of the service.

=C2=A0 =C2=A0To reduce the dependency on external= CAs, this document proposes a
=C2=A0 =C2=A0limited delegation mechanism that al= lows a TLS peer to issue its own
=C2=A0 =C2=A0credentials within the scope of a ce= rtificate issued by an external
=C2=A0 =C2=A0CA.=C2=A0 These credentials only ena= ble the recipient of the delegation to
=C2=A0 =C2=A0speak for names that the CA has auth= orized.=C2=A0 For clarity, we will
=C2=A0 =C2=A0refer to the certificate issued by t= he CA as a "certificate", or
=C2=A0 =C2=A0"delegation certificate", = and the one issued by the operator as a
=C2=A0 =C2=A0"delegated credential" or = "DC".

<mglt>
From the text it is unclear why the
signature scheme appears to be a
constraint as well how it does not opens
to some sort of downgrade attacks if
left to the operator. =C2=A0
</mglt>


3.=C2=A0 Solution Overview

[...]

3.1.=C2=A0 Rationale

=C2=A0 =C2=A0Delegated credentials present a bett= er alternative than other
=C2=A0 =C2=A0delegation mechanisms like proxy cer= tificates [RFC3820] for several
=C2=A0 =C2=A0reasons:

=C2=A0 =C2=A0* =C2=A0There is no change needed to= certificate validation at the PKI
=C2=A0 =C2=A0 =C2=A0 layer.

=C2=A0 =C2=A0* =C2=A0X.509 semantics are very ric= h.=C2=A0 This can cause unintended
=C2=A0 =C2=A0 =C2=A0 consequences if a service ow= ner creates a proxy certificate where
=C2=A0 =C2=A0 =C2=A0 the properties differ from t= he leaf certificate.=C2=A0 For this reason,
=C2=A0 =C2=A0 =C2=A0 delegated credentials have v= ery restricted semantics that should
=C2=A0 =C2=A0 =C2=A0 not conflict with X.509 sema= ntics.

=C2=A0 =C2=A0* =C2=A0Proxy certificates rely on t= he certificate path building process
=C2=A0 =C2=A0 =C2=A0 to establish a binding betwe= en the proxy certificate and the
=C2=A0 =C2=A0 =C2=A0 server certificate.=C2=A0 Si= nce the certificate path building process
=C2=A0 =C2=A0 =C2=A0 is not cryptographically pro= tected, it is possible that a proxy
=C2=A0 =C2=A0 =C2=A0 certificate could be bound t= o another certificate with the same
=C2=A0 =C2=A0 =C2=A0 public key, with different X= .509 parameters.=C2=A0 Delegated
=C2=A0 =C2=A0 =C2=A0 credentials, which rely on a= cryptographic binding between the
=C2=A0 =C2=A0 =C2=A0 entire certificate and the d= elegated credential, cannot.

=C2=A0 =C2=A0* =C2=A0Each delegated credential is= bound to a specific signature
=C2=A0 =C2=A0 =C2=A0 algorithm that may be used t= o sign the TLS handshake ([RFC8446]




Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 6]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0 =C2=A0 section 4.2.3).=C2=A0 This p= revents them from being used with other,
=C2=A0 =C2=A0 =C2=A0 perhaps unintended signature= algorithms.

<mglt>
It is not clear to me why there is a
"may be used". I suppose it concerns th= e
use of the DC not the algorithm but that
was confusing.=C2=A0

I also believe that the specific
signature algorithm to sign the
delegated credential could be part of
the rational. =C2=A0
</mglt>

3.2.=C2=A0 Related Work

=C2=A0 =C2=A0Many of the use cases for delegated = credentials can also be addressed
=C2=A0 =C2=A0using purely server-side mechanisms = that do not require changes to
=C2=A0 =C2=A0client behavior (e.g., a PKCS#11 int= erface or a remote signing
=C2=A0 =C2=A0mechanism [KEYLESS]).=C2=A0 These me= chanisms, however, incur per-
=C2=A0 =C2=A0transaction latency, since the front= -end server has to interact with
=C2=A0 =C2=A0a back-end server that holds a priva= te key.=C2=A0 The mechanism proposed
=C2=A0 =C2=A0in this document allows the delegati= on to be done off-line, with no
=C2=A0 =C2=A0per-transaction latency.=C2=A0 The f= igure below compares the message flows
=C2=A0 =C2=A0for these two mechanisms with TLS 1.= 3 [RFC8446].

=C2=A0 =C2=A0Remote key signing:

=C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Front-End =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Back-End
=C2=A0 =C2=A0 =C2=A0|----ClientHello--->| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---ServerHello----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---Certificate----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---remote sign---->|
=C2=A0 =C2=A0 =C2=A0|<---CertVerify-----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= ... =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|


=C2=A0 =C2=A0Delegated credentials:

=C2=A0 =C2=A0Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Front-End =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Back-End
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<--DC distribution->|
=C2=A0 =C2=A0 =C2=A0|----ClientHello--->| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---ServerHello----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---Certificate----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---CertVerify-----| =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0= ... =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0These two mechanisms can be compleme= ntary.=C2=A0 A server could use
=C2=A0 =C2=A0credentials for clients that support= them, while using [KEYLESS] to
=C2=A0 =C2=A0support legacy clients.=C2=A0<= /span>

<mglt>
I believe that this sentence does not
show any complementary as subcert and
KEYLESS are targeting different version
of TLS, so they can hardly be
complementary.=C2=A0 However (and luckily)
LURK provides an extension for TLS 1.3
[draft-mglt-lurk-tls13] which enable a
complementary use of these mechanisms
these mechanisms. I believe that would
be good to indicate the reason they
complement each other which is that LURK
protects the credentials for its
operations. These operations could be
performed in the scope of subcert or TLS
1.3.

Note also that in a related section it
also worth mentioning that credentials
may be managed in different ways and
KEYLESS represents an valuable way to
protect and manage these credentials in
TLS 1.2. However, KEYLESS is known to
presents some vulnerabilities (PFS,
signing oracle) so the protection
remains limited while the LURK extension
for TLS 1.2 [draft-mglt-lurk-tls12]
addressed these issues and as a result
should provide a better protection.
</mglt>

The private key for a delegated credential
=C2=A0 =C2=A0can be used in place of a certificat= e private key, so it is important
=C2=A0 =C2=A0that the Front-End and Back-End are = parties that have a trusted
=C2=A0 =C2=A0relationship.


=C2=A0 =C2=A0Use of short-lived certificates with= automated certificate issuance,
=C2=A0 =C2=A0e.g., with Automated Certificate Man= agment Environment (ACME)
<mglt>
Management=C2=A0
</mglt>
=C2=A0 =C2=A0[RFC8555], reduces the risk of key c= ompromise, but has several
=C2=A0 =C2=A0limitations.=C2=A0 Specifically, it = introduces an operationally-critical
=C2=A0 =C2=A0dependency on an external party.=C2= =A0 It also limits the types of



Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 7]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0algorithms supported for TLS authent= ication to those the CA is
=C2=A0 =C2=A0willing to issue a certificate for.= =C2=A0 Nonetheless, existing automated
=C2=A0 =C2=A0issuance APIs like ACME may be usefu= l for provisioning delegated
=C2=A0 =C2=A0credentials.

4.=C2=A0 Delegated Credentials

=C2=A0 =C2=A0While X.509 forbids end-entity certi= ficates from being used as
=C2=A0 =C2=A0issuers for other certificates, it i= s valid to use them to issue
=C2=A0 =C2=A0other signed objects as long as the = certificate contains the
=C2=A0 =C2=A0digitalSignature KeyUsage ([RFC5280]= section 4.2.1.3).=C2=A0 We define a
=C2=A0 =C2=A0new signed object format that would = encode only the semantics that
=C2=A0 =C2=A0are needed for this application.=C2= =A0 The credential has the following
=C2=A0 =C2=A0structure:

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 valid_time;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme expec= ted_cert_verify_algorithm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque ASN1_subjectPu= blicKeyInfo<1..2^24-1>;
=C2=A0 =C2=A0 =C2=A0 } Credential;

=C2=A0 =C2=A0valid_time: =C2=A0Time in seconds re= lative to the beginning of the
=C2=A0 =C2=A0 =C2=A0 delegation certificate's= notBefore value after which the delegated
=C2=A0 =C2=A0 =C2=A0 credential is no longer vali= d.=C2=A0 This MUST NOT exceed 7 days.
<mglt>
I believe the behavior of the "verifying
peer" should also be specified maybe
with a reference.

</mglt>

=C2=A0 =C2=A0expected_cert_verify_algorithm: =C2= =A0The signature algorithm of the
=C2=A0 =C2=A0 =C2=A0 credential key pair, where t= he type SignatureScheme is as defined
=C2=A0 =C2=A0 =C2=A0 in [RFC8446].=C2=A0 This is = expected to be the same as
=C2=A0 =C2=A0 =C2=A0 CertificateVerify.algorithm = sent by the server.=C2=A0 Only signature
=C2=A0 =C2=A0 =C2=A0 algorithms allowed for use i= n CertificateVerify messages are
=C2=A0 =C2=A0 =C2=A0 allowed.=C2=A0 When using RS= A, the public key MUST NOT use the
=C2=A0 =C2=A0 =C2=A0 rsaEncryption OID, as a resu= lt, the following algorithms are not
=C2=A0 =C2=A0 =C2=A0 allowed for use with delegat= ed credentials: rsa_pss_rsae_sha256,
=C2=A0 =C2=A0 =C2=A0 rsa_pss_rsae_sha384, rsa_pss= _rsae_sha512.

<mglt>
It is unclear whether the
expected_cert_verify_algorithm and
CertificateVerify.algorithm needs to be
checked and what needs to be done in
case of mismatch (with the RSA caveat).
I believe that should be clarified.

</mglt>

=C2=A0 =C2=A0ASN1_subjectPublicKeyInfo: =C2=A0The= credential's public key, a DER-
=C2=A0 =C2=A0 =C2=A0 encoded [X.690] SubjectPubli= cKeyInfo as defined in [RFC5280].

=C2=A0 =C2=A0The delegated credential has the fol= lowing structure:

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Credential cred;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme algor= ithm;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque signature<0= ..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 } DelegatedCredential;

=C2=A0 =C2=A0algorithm: =C2=A0The signature algor= ithm used to verify
=C2=A0 =C2=A0 =C2=A0 DelegatedCredential.signatur= e.

<mglt>
I am wondering if any checks should be
performed with the
CertificateVerify.algorithm or if any
algorithm would be acceptable. Unless I
am missing something it seems a weak
algorithm can be used - assuming the
registry contains such weak algorithms.
</mglt>


Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 8]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0signature: =C2=A0The delegation, a s= ignature that binds the credential to
=C2=A0 =C2=A0 =C2=A0 the end-entity certificate&#= 39;s public key as specified below.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 signature scheme is specifie= d by DelegatedCredential.algorithm.

[...]

4.1.1.=C2=A0 Server Authentication

=C2=A0 =C2=A0A client which supports this specifi= cation SHALL send a
=C2=A0 =C2=A0"delegated_credential" ext= ension in its ClientHello.=C2=A0 The body of the
=C2=A0 =C2=A0extension consists of a SignatureSch= emeList:





Barnes, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires 28 December 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[Page 9]

Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegat= ed Credentials for TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2020


=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SignatureScheme suppo= rted_signature_algorithm<2..2^16-2>;
=C2=A0 =C2=A0 =C2=A0 } SignatureSchemeList;

=C2=A0 =C2=A0If the client receives a delegated c= redential without indicating
=C2=A0 =C2=A0support, then the client MUST abort = with an "unexpected_message"
=C2=A0 =C2=A0alert.

=C2=A0 =C2=A0If the extension is present, the ser= ver MAY send a delegated
=C2=A0 =C2=A0credential; if the extension is not = present, the server MUST NOT send
=C2=A0 =C2=A0a delegated credential.=C2=A0 The se= rver MUST ignore the extension unless
=C2=A0 =C2=A0TLS 1.3 or a later version is negoti= ated.


=C2=A0 =C2=A0The server MUST send the delegated c= redential as an extension in the
=C2=A0 =C2=A0CertificateEntry of its end-entity c= ertificate; the client SHOULD
=C2=A0 =C2=A0ignore delegated credentials sent as= extensions to any other
=C2=A0 =C2=A0certificate.

=C2=A0 =C2=A0The expected_cert_verify_algorithm f= ield MUST be of a type advertised
=C2=A0 =C2=A0by the client in the SignatureScheme= List and is considered invalid
=C2=A0 =C2=A0otherwise.=C2=A0 Clients that receiv= e invalid delegated credentials MUST
=C2=A0 =C2=A0terminate the connection with an &qu= ot;illegal_parameter" alert.

<mglt>
I am wondering what would prevent any
downgrade attacks if the
SignatureSchemeList and
signature_algorithms have two different
sets of lists. My current understanding
is that these extensions are handled
independently, but I might be missing
something.

I am wondering if that would be
appropriated to specify the signature of
the CertificateVerify depending on the
presence of the delegated credential - I
mean the key used to generate it.=C2=A0

</mglt>

[...]

4.1.3.=C2=A0 Validating a Delegated Credential

=C2=A0 =C2=A0On receiving a delegated credential = and a certificate chain, the peer
=C2=A0 =C2=A0validates the certificate chain and = matches the end-entity
=C2=A0 =C2=A0certificate to the peer's expect= ed identity.=C2=A0 It also takes the
=C2=A0 =C2=A0following steps:

=C2=A0 =C2=A01.=C2=A0 Verify that the current tim= e is within the validity interval of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the credential.=C2=A0 = This is done by asserting that the current time
=C2=A0 =C2=A0 =C2=A0 =C2=A0is no more than the de= legation certificate's notBefore value plus
=C2=A0 =C2=A0 =C2=A0 =C2=A0DelegatedCredential.cr= ed.valid_time.

=C2=A0 =C2=A02.=C2=A0 Verify that the credential&= #39;s remaining validity time is no more
=C2=A0 =C2=A0 =C2=A0 =C2=A0than the maximum valid= ity period.=C2=A0 This is done by asserting that
=C2=A0 =C2=A0 =C2=A0 =C2=A0the current time is no= more than the delegation certificate's
=C2=A0 =C2=A0 =C2=A0 =C2=A0notBefore value plus D= elegatedCredential.cred.valid_time plus the
=C2=A0 =C2=A0 =C2=A0 =C2=A0maximum validity perio= d.

=C2=A0 =C2=A03.=C2=A0 Verify that expected_cert_v= erify_algorithm matches the scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicated in the peer&= #39;s CertificateVerify message and that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm is allowed f= or use with delegated credentials.

<mglt>
I am wondering if a reference to specify
what allowed would not be needed unless
it means advertised in the extension. =C2=A0

</mglt>

=C2=A0 =C2=A04.=C2=A0 Verify that the end-entity = certificate satisfies the conditions
=C2=A0 =C2=A0 =C2=A0 =C2=A0in Section 4.2.

=C2=A0 =C2=A05.=C2=A0 Use the public key in the p= eer's end-entity certificate to verify
=C2=A0 =C2=A0 =C2=A0 =C2=A0the signature of the c= redential using the algorithm indicated by
=C2=A0 =C2=A0 =C2=A0 =C2=A0DelegatedCredential.al= gorithm.

=C2=A0 =C2=A0If one or more of these checks fail,= then the delegated credential is
=C2=A0 =C2=A0deemed invalid.=C2=A0 Clients and se= rvers that receive invalid delegated
=C2=A0 =C2=A0credentials MUST terminate the conne= ction with an "illegal_parameter"
=C2=A0 =C2=A0alert.=C2=A0 If successful, the part= icipant receiving the Certificate
=C2=A0 =C2=A0message uses the public key in the c= redential to verify the signature
=C2=A0 =C2=A0in the peer's CertificateVerify = message.

[...]

7.=C2=A0 Security Considerations

[...]

7.6.=C2=A0 The Impact of Signature Forgery Attack= s

=C2=A0 =C2=A0When TLS 1.2 servers support RSA key= exchange, they may be vulnerable
=C2=A0 =C2=A0to attacks that allow forging an RSA= signature over an arbitrary
=C2=A0 =C2=A0message [BLEI].=C2=A0 TLS 1.2 [RFC52= 46] (Section 7.4.7.1.) describes a
=C2=A0 =C2=A0mitigation strategy requiring carefu= l implementation of timing
=C2=A0 =C2=A0resistant countermeasures for preven= ting these attacks.=C2=A0 Experience
=C2=A0 =C2=A0shows that in practice, server imple= mentations may fail to fully stop
=C2=A0 =C2=A0these attacks due to the complexity = of this mitigation [ROBOT].=C2=A0 For
=C2=A0 =C2=A0TLS 1.2 servers that support RSA key= exchange using a DC-enabled end-
=C2=A0 =C2=A0entity certificate, a hypothetical s= ignature forgery attack would
=C2=A0 =C2=A0allow forging a signature over a del= egated credential.=C2=A0 The forged
=C2=A0 =C2=A0credential could then be used by the= attacker as the equivalent of a
=C2=A0 =C2=A0man-in-the-middle certificate, valid= for 7 days.

<mglt>
I do not see the relevance to TLS 1.3.=C2= =A0
</mglt>

=C2=A0 =C2=A0Server operators should therefore mi= nimize the risk of using DC-
=C2=A0 =C2=A0enabled end-entity certificates wher= e a signature forgery oracle may
=C2=A0 =C2=A0be present.=C2=A0 If possible, serve= r operators may choose to use DC-
=C2=A0 =C2=A0enabled certificates only for signin= g credentials, and not for
=C2=A0 =C2=A0serving non-DC TLS traffic.=C2=A0 Fu= rthermore, server operators may use
=C2=A0 =C2=A0elliptic curve certificates for DC-e= nabled traffic, while using RSA
=C2=A0 =C2=A0certificates without the DelegationU= sage certificate extension for
=C2=A0 =C2=A0non-DC traffic; this completely prev= ents such attacks.

=C2=A0 =C2=A0Note that if a signature can be forg= ed over an arbitrary credential,
=C2=A0 =C2=A0the attacker can choose any value fo= r the valid_time field.=C2=A0 Repeated
=C2=A0 =C2=A0signature forgeries therefore allow = the attacker to create multiple
=C2=A0 =C2=A0delegated credentials that can cover= the entire validity period of
=C2=A0 =C2=A0the certificate.=C2=A0 Temporary exp= osure of the key or a signing oracle
=C2=A0 =C2=A0may allow the attacker to impersonat= e a server for the lifetime of
=C2=A0 =C2=A0the certificate.


From: TLS <tls-bounces@ietf.org> on behalf of Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org>
Sent: Monday, June 29, 2020 12:00 PM
To: Joseph Salowey <joe@salowey.net>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS
=C2=A0

I=E2=80=99d still like to see test vectors.

--0000000000000bbac005a95a82e2--