From nobody Tue Jan 2 09:07:07 2018 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 0714D124319 for ; Tue, 2 Jan 2018 09:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 7MHf7Uj1z2cQ for ; Tue, 2 Jan 2018 09:07:04 -0800 (PST) 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 2E31E124207 for ; Tue, 2 Jan 2018 09:07:04 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w02H72Ev006060 for ; Tue, 2 Jan 2018 17:07:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=goD8eT7tBqdKhp9n0D/A65nhDLZFI0d6px/td/H+zK4=; b=a+7631nPBiafKZZWy0jID7a+rhGJGRmDp4Q0PlTDwA1x8GARvDsKlsx3Xa8OoAgkGtJ9 Po99VSAqw3h28gb8i+w3UyDnROoOqZFdqptrTDOtMJmAPalIuWKV60ToANNRWVktkPzs 7pW9s7RoUCTZWnu+eG4jZQBrsYACHgsad5WJJZVDLvowCjCn68FQpXhIUDC0D1T1lriH 4mE/B6rXIwjxuiRSVIj+nJUyqvgk4fkliXEYEn5hAVZT4FPyul9HbE01J+yvr05X8v/d zqTWrJROh+snMRBnZx67a8T+lIBpV23rasSGcLTU30yxSvcc6dpFOQ0OljGB1sGDakO2 bg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2f62x8yv48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 02 Jan 2018 17:07:02 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w02H5lct023434 for ; Tue, 2 Jan 2018 12:07:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f670ytaf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 02 Jan 2018 12:07:01 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 2 Jan 2018 12:07:00 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 2 Jan 2018 12:07:00 -0500 From: "Short, Todd" To: "" Thread-Topic: Draft-22 and Post-Handshake Authentication Thread-Index: AQHTg+wZTzn40m8IekqCxE+bMFdDSw== Date: Tue, 2 Jan 2018 17:06:59 +0000 Message-ID: <401F3672-AF80-464B-9348-D91196E85E54@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.203] Content-Type: multipart/alternative; boundary="_000_401F3672AF80464B9348D91196E85E54akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020246 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020247 Archived-At: Subject: [TLS] Draft-22 and Post-Handshake Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 17:07:06 -0000 --_000_401F3672AF80464B9348D91196E85E54akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UXVlc3Rpb24gb24gUG9zdC1IYW5kc2hha2UgQXV0aGVudGljYXRpb24gKFBIQSk6DQoNClBIQSBj YW4gb2NjdXIgbXVsdGlwbGUgdGltZXMgb3ZlciBhIGNvbm5lY3Rpb24uIFRoZSBkZXNjcmlwdGlv biBmb3IgdGhlICJIYW5kc2hha2UgQ29udGV4dOKAnSBpcyBhcyBmb2xsb3dzICg0LjQpOg0KDQoN CiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgfCBQb3N0LSAgICAgfCBDbGllbnRIZWxsbyAuLi4gY2xpZW50 ICAgICB8IGNsaWVudF9hcHBsaWNhdGlvbl90cmFmZiB8DQogICB8IEhhbmRzaGFrZSB8IEZpbmlz aGVkICsgICAgICAgICAgICAgICAgIHwgaWNfc2VjcmV0X04gICAgICAgICAgICAgIHwNCiAgIHwg ICAgICAgICAgIHwgQ2VydGlmaWNhdGVSZXF1ZXN0ICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCk5vdywgUEhBIGNvc3RzIG9mOg0KDQpTPkM6 IENlcnRpZmljYXRlUmVxdWVzdA0KDQpmb2xsb3dlZCBieToNCg0KQz5TOiBDZXJ0aWZpY2F0ZStD ZXJ0aWZpY2F0ZVZlcmlmeStjbGllbnQgRmluaXNoZWQNCg0KVGhpcyBjb3VsZCBiZSBpbnRlcnBy ZXRlZCB0byBtZWFuIHRoYXQgdGhlc2UgUEhBIG1lc3NhZ2VzIGFyZSBpbmNsdWRlZCBpbiB0aGUg SGFuZHNoYWtlIENvbnRleHQuIEhvd2V2ZXIsIFNlY3Rpb24gNC40LjEgc3RhdGVzOg0KDQoNCiAg IEZvciBjb25jcmV0ZW5lc3MsIHRoZSB0cmFuc2NyaXB0IGhhc2ggaXMgYWx3YXlzIHRha2VuIGZy b20gdGhlDQogICBmb2xsb3dpbmcgc2VxdWVuY2Ugb2YgaGFuZHNoYWtlIG1lc3NhZ2VzLCBzdGFy dGluZyBhdCB0aGUgZmlyc3QNCiAgIENsaWVudEhlbGxvIGFuZCBpbmNsdWRpbmcgb25seSB0aG9z ZSBtZXNzYWdlcyB0aGF0IHdlcmUgc2VudDoNCiAgIENsaWVudEhlbGxvLCBIZWxsb1JldHJ5UmVx dWVzdCwgQ2xpZW50SGVsbG8sIFNlcnZlckhlbGxvLA0KICAgRW5jcnlwdGVkRXh0ZW5zaW9ucywg c2VydmVyIENlcnRpZmljYXRlUmVxdWVzdCwgc2VydmVyIENlcnRpZmljYXRlLA0KDQoNCiAgIHNl cnZlciBDZXJ0aWZpY2F0ZVZlcmlmeSwgc2VydmVyIEZpbmlzaGVkLCBFbmRPZkVhcmx5RGF0YSwg Y2xpZW50DQogICBDZXJ0aWZpY2F0ZSwgY2xpZW50IENlcnRpZmljYXRlVmVyaWZ5LCBjbGllbnQg RmluaXNoZWQuDQoNCg0KSSB3YW50IHRvIGNvbmZpcm0gdGhhdCB0aGUgUEhBIGhhbmRzaGFrZSBj b250ZXh0IGNvbnNpc3RzIG9ubHkgb2YgdGhlIG1lc3NhZ2VzIGxpc3RlZCBpbiBzZWN0aW9uIDQu NC4xIGZyb20gdGhlIGluaXRpYWwgaGFuZHNoYWtlLCBhbmQgZG8gbm90IGluY2x1ZGUgYW55IG9m IHRoZSBtZXNzYWdlcyBmcm9tIGludGVybWVkaWF0ZSBQSEEgZXhjaGFuZ2VzLg0KDQpUaGFuayB5 b3UsDQoNCi0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFpbHRvOnRzaG9y dEBha2FtYWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBp ZiBieSB0aGUgSW50ZXJuZXQuIg0KDQo= --_000_401F3672AF80464B9348D91196E85E54akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <924F1B48EEDB864987791AA009520591@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KUXVlc3Rpb24gb24gUG9zdC1IYW5k c2hha2UgQXV0aGVudGljYXRpb24gKFBIQSk6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QSEEgY2FuIG9jY3VyIG11bHRpcGxlIHRpbWVzIG92ZXIg YSBjb25uZWN0aW9uLiBUaGUgZGVzY3JpcHRpb24gZm9yIHRoZSAmcXVvdDtIYW5kc2hha2UgQ29u dGV4dOKAnSBpcyBhcyBmb2xsb3dzICg0LjQpOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHls ZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBicmVhay1iZWZvcmU6IHBhZ2U7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsg b3JwaGFuczogMjsgd2lkb3dzOiAyOyI+ICAgfCAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8IFBvc3QtICAgICB8 IENsaWVudEhlbGxvIC4uLiBjbGllbnQgICAgIHwgY2xpZW50X2FwcGxpY2F0aW9uX3RyYWZmIHwN CiAgIHwgSGFuZHNoYWtlIHwgRmluaXNoZWQgJiM0MzsgICAgICAgICAgICAgICAgIHwgaWNfc2Vj cmV0X04gICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgIHwgQ2VydGlmaWNhdGVSZXF1ZXN0 ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgJiM0MzstLS0tLS0tLS0t LSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOzwvcHJlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Tm93LCBQSEEgY29zdHMgb2Y6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TJmd0O0M6IENlcnRpZmljYXRlUmVx dWVzdDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Zm9sbG93ZWQgYnk6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5DJmd0O1M6IENlcnRpZmljYXRlJiM0MztDZXJ0aWZpY2F0ZVZl cmlmeSYjNDM7Y2xpZW50IEZpbmlzaGVkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGNvdWxkIGJlIGludGVycHJldGVkIHRvIG1l YW4gdGhhdCB0aGVzZSBQSEEgbWVzc2FnZXMgYXJlIGluY2x1ZGVkIGluIHRoZSBIYW5kc2hha2Ug Q29udGV4dC4gSG93ZXZlciwgU2VjdGlvbiA0LjQuMSBzdGF0ZXM6PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwcmUgY2xhc3M9Im5l d3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDEzLjMzMzNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IGJyZWFrLWJlZm9yZTogcGFnZTsgZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij4gICBGb3IgY29uY3JldGVuZXNzLCB0 aGUgdHJhbnNjcmlwdCBoYXNoIGlzIGFsd2F5cyB0YWtlbiBmcm9tIHRoZQ0KICAgZm9sbG93aW5n IHNlcXVlbmNlIG9mIGhhbmRzaGFrZSBtZXNzYWdlcywgc3RhcnRpbmcgYXQgdGhlIGZpcnN0DQog ICBDbGllbnRIZWxsbyBhbmQgaW5jbHVkaW5nIG9ubHkgdGhvc2UgbWVzc2FnZXMgdGhhdCB3ZXJl IHNlbnQ6DQogICBDbGllbnRIZWxsbywgSGVsbG9SZXRyeVJlcXVlc3QsIENsaWVudEhlbGxvLCBT ZXJ2ZXJIZWxsbywNCiAgIEVuY3J5cHRlZEV4dGVuc2lvbnMsIHNlcnZlciBDZXJ0aWZpY2F0ZVJl cXVlc3QsIHNlcnZlciBDZXJ0aWZpY2F0ZSwNCjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9ImZvbnQtc2l6ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDBweDsgYnJlYWstYmVmb3JlOiBwYWdlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPiAgIHNlcnZlciBDZXJ0aWZpY2F0ZVZlcmlmeSwg c2VydmVyIEZpbmlzaGVkLCBFbmRPZkVhcmx5RGF0YSwgY2xpZW50DQogICBDZXJ0aWZpY2F0ZSwg Y2xpZW50IENlcnRpZmljYXRlVmVyaWZ5LCBjbGllbnQgRmluaXNoZWQuPC9wcmU+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J IHdhbnQgdG8gY29uZmlybSB0aGF0IHRoZSBQSEEgaGFuZHNoYWtlIGNvbnRleHQgY29uc2lzdHMg b25seSBvZiB0aGUgbWVzc2FnZXMgbGlzdGVkIGluIHNlY3Rpb24gNC40LjEgZnJvbSB0aGUgaW5p dGlhbCBoYW5kc2hha2UsIGFuZCBkbyBub3QgaW5jbHVkZSBhbnkgb2YgdGhlIG1lc3NhZ2VzIGZy b20gaW50ZXJtZWRpYXRlIFBIQSBleGNoYW5nZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFuayB5b3UsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1Ub2RkIFNob3J0PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi8vIDxhIGhyZWY9Im1haWx0bzp0c2hvcnRAYWthbWFpLmNvbSIgY2xhc3M9IiI+dHNob3J0QGFr YW1haS5jb208L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi8vICZxdW90O09uZSBpZiBieSBsYW5k LCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuJnF1b3Q7PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_401F3672AF80464B9348D91196E85E54akamaicom_-- From nobody Tue Jan 2 09:23:36 2018 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 0749E124239 for ; Tue, 2 Jan 2018 09:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5CTmmondXnB1 for ; Tue, 2 Jan 2018 09:23:32 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 DEB1F1241FC for ; Tue, 2 Jan 2018 09:23:31 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v187so12095122ywc.2 for ; Tue, 02 Jan 2018 09:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ubm2E2ovphP60ZkV9s2XiyRJR79edP+PACos5Qro8sI=; b=Qi3u4+j5BjmYMK60ymhM4cgijg30tBDVL1Kt8wbELzTvozXx6t1L93l/8CWLe7mQ2O leRSXhrituaDvYvbKO4vOOtmWdCA22klkXVNgwbPRNJvaiyPxN8DTlB2vePU00EaVhRR GLq4XWCt50TusabhPA6ONv8wRIjABarFmanlczTcuwRq6dNKYJo/CJba080lieF/8OaJ SfPhF551ac+Fdns4q6Opdh6ZyhZMviJuhV+6P2yWKzvWqRIC7Kdjqbuppamfcyn94GfB 0e/Ubc4PD0w83RdY1IWSTfAjira1mGWVcaIidHTko6J4KJ/d6bGfg984A5+z9MtWAqsP GspQ== 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:references:from:date :message-id:subject:to:cc; bh=Ubm2E2ovphP60ZkV9s2XiyRJR79edP+PACos5Qro8sI=; b=XtooE25H7b8rNK0JJnvrJ5/Z65iGoDVJFCc1Ys7xXEJB64h45/C9bHnZSRb86vfNmA Ng9aHqQuCQ+ItVnf8/hW/A1KDLA9kSJTGHiT4hzBfV9ITqm65QUGXpQrQPfsgpOaW0R+ ztqOg7KLAoJ7fR51KoCekJxcQwoVSzflcdk4MHrYq64oF23oEac66YS2PN8bkaZlAPhI DoNt/qhmFkbIpwFoUJqukQaZU+wJSsBg990YiToF5ALA01wuvhXcJr/3H5YOWD3BETBn KASdabTtP4k78Q2KpRthyJQDQTAk48sLzAfxxfkDxkdAWPiu6q+Z8QVYpOqjk7Lb1uI0 xrnA== X-Gm-Message-State: AKGB3mIx7XQtfaeE0meJgFlGYZescog46H1XcrR8/blvJDhi84qLP+Xt YX1fpVtJ+jq46BG1Thpy2RXwuqhZ5OSgR99KNo2ldw== X-Google-Smtp-Source: ACJfBosE3vQTMR3DNI6CDuuWLljmehTrgosIWCC40Nn6tyVh5Xen988VaxQGWyPDSD3RzCsgqeMeEct3oabIOBC6ACY= X-Received: by 10.129.206.7 with SMTP id t7mr1310315ywi.47.1514913810929; Tue, 02 Jan 2018 09:23:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 09:22:50 -0800 (PST) In-Reply-To: <401F3672-AF80-464B-9348-D91196E85E54@akamai.com> References: <401F3672-AF80-464B-9348-D91196E85E54@akamai.com> From: Eric Rescorla Date: Tue, 2 Jan 2018 09:22:50 -0800 Message-ID: To: "Short, Todd" Cc: "" Content-Type: multipart/alternative; boundary="94eb2c1a8dda9121b10561ce5b20" Archived-At: Subject: Re: [TLS] Draft-22 and Post-Handshake Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 17:23:34 -0000 --94eb2c1a8dda9121b10561ce5b20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that is correct On Tue, Jan 2, 2018 at 9:06 AM, Short, Todd wrote: > Question on Post-Handshake Authentication (PHA): > > PHA can occur multiple times over a connection. The description for the > "Handshake Context=E2=80=9D is as follows (4.4): > > | | | | > | Post- | ClientHello ... client | client_application_traff | > | Handshake | Finished + | ic_secret_N | > | | CertificateRequest | | > +-----------+----------------------------+--------------------------+ > > > Now, PHA costs of: > > S>C: CertificateRequest > > followed by: > > C>S: Certificate+CertificateVerify+client Finished > > This could be interpreted to mean that these PHA messages are included in > the Handshake Context. However, Section 4.4.1 states: > > For concreteness, the transcript hash is always taken from the > following sequence of handshake messages, starting at the first > ClientHello and including only those messages that were sent: > ClientHello, HelloRetryRequest, ClientHello, ServerHello, > EncryptedExtensions, server CertificateRequest, server Certificate, > > server CertificateVerify, server Finished, EndOfEarlyData, client > Certificate, client CertificateVerify, client Finished. > > > > I want to confirm that the PHA handshake context consists only of the > messages listed in section 4.4.1 from the initial handshake, and do not > include any of the messages from intermediate PHA exchanges. > > Thank you, > > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c1a8dda9121b10561ce5b20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that is correct

<= div class=3D"gmail_quote">On Tue, Jan 2, 2018 at 9:06 AM, Short, Todd <tsh= ort@akamai.com> wrote:
Question on Post-Handshake Authentication (PHA):

PHA can occur multiple times over a connection. The description for th= e "Handshake Context=E2=80=9D is as follows (4.4):

   |        =
   |                            |                          |
   | Post-     | ClientHello ... client     | client_application_traff |
   | Handshake | Finished +                 | ic_secret_N              |
   |           | CertificateRequest         |                          |
   +-----------+----------------------------+--------------------=
------+

Now, PHA costs of:

S>C: CertificateRequest

followed by:

C>S: Certificate+CertificateVerify+client Finished

This could be interpreted to mean that these PHA messages are included= in the Handshake Context. However, Section 4.4.1 states:

   For concr=
eteness, the transcript hash is always taken from the
   following sequence of handshake messages, starting at the first
   ClientHello and including only those messages that were sent:
   ClientHello, HelloRetryRequest, ClientHello, ServerHello,
   EncryptedExtensions, server CertificateRequest, server Certificate,

   server Ce=
rtificateVerify, server Finished, EndOfEarlyData, client
   Certificate, client CertificateVerify, client Finished.


I want to confirm that the PHA handshake context consists only of the = messages listed in section 4.4.1 from the initial handshake, and do not inc= lude any of the messages from intermediate PHA exchanges.

Thank you,
=C2=A0
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;


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


--94eb2c1a8dda9121b10561ce5b20-- From nobody Tue Jan 2 11:15:17 2018 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 4353B126CF6 for ; Tue, 2 Jan 2018 11:15:16 -0800 (PST) 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, FREEMAIL_FROM=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 ajSUEGGr1odO for ; Tue, 2 Jan 2018 11:15:13 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.175]) (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 8394C124207 for ; Tue, 2 Jan 2018 11:15:13 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 23804 invoked from network); 2 Jan 2018 20:15:10 +0100 Received: from ceh60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.30.183.60]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 2 Jan 2018 20:15:10 +0100 To: tls@ietf.org From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> Date: Tue, 2 Jan 2018 20:15:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 841395dc81bd6b9daff8caef58f0a7cd X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [AdMU] Archived-At: Subject: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:15:16 -0000 Hello, OpenDNS by default blocks websites that are used for phishing and optionally other sites as configured by the deployer. It does this by DNS poisoning: it responds with a forged A or AAAA response that redirects to their server. An example website blocked by OpenDNS in this manner is https://internetbadguys.com/. When OpenDNS blocks a website that is served by HTTPS, the user is presented with a "Certificate Error" message. To see what happened, she then has to accept the incorrect certificate or visit the plain HTTP version of the webpage. This creates some problems: aside from a bad user experience, it makes users accustomed to ignoring certificate errors. Another problem is created by captive portals: networks that use "a web page which is displayed to newly connected users before they are granted broader access to network resources." (Wikipedia). This could be solved by specifying two new values of AlertDescription: access_administratively_disabled and captive_portal as well as a new field to struct Alert: alert_message. Let alert_message be a fixed-length UTF-8-encoded string. It would be only valid for (description == access_administratively_disabled || description == captive_portal) and otherwise a client would HAVE TO ignore it. It would be plain-text for simplicity, shortness and security. It would be null-terminated and then randomly padded to a size of perhaps 100 bytes. A TLS client would HAVE TO filter the message for any odd characters, invalid UTF-8 sequences, etc. as will be specified in the standard. Greetings, Mateusz Jończyk From nobody Tue Jan 2 11:38:46 2018 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 8766612D834 for ; Tue, 2 Jan 2018 11:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 upH_O8SNGcvK for ; Tue, 2 Jan 2018 11:38:40 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 AAE201200C1 for ; Tue, 2 Jan 2018 11:38:40 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id g191so12224229ywe.7 for ; Tue, 02 Jan 2018 11:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F6Shi2PeTIZOdIsCpNTIM3wzXdg9ZyIGUJScVd51R1k=; b=NvBM0GzUniUgD3jUC+vh5ff4jF63sNDr1V9fYC2jBBjdVQMF8hzJ1sYYOQtiAxdxfY +7VIw8zGGRZOFchhbgPpEQYKFrPHLNox/1RMEWgQfClw5y1L+uns5Oe3V7co0eGpcp0W Z4My4z/7saEHYmK1iGd1cCaPnKzpr6My3rUCLcBQ096mBMkkG06Ohgps+iHg6bHtH+lI 0pX2s5qIzzXN4dNM+kDfNwCRfnlUTRyMv1fKE+7y3aFoym38IAA7pNx2jVu/SFuQwa98 GIxDkj7keGUW7OIplpXIoXh/GVHmlGzDiJuoHY9ct+t9gNgot4WhczxsTCAs77aGkUtP vh9w== 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:references:from:date :message-id:subject:to:cc; bh=F6Shi2PeTIZOdIsCpNTIM3wzXdg9ZyIGUJScVd51R1k=; b=YpMSuR/zMOVywDd4tYzBYjLqkHpm7PqpZarc6ld3gGH5A4tDDcUpjl0W6MBpI1ebzn APY6OERNbdhW3d+RJ7LsblEk8z+8HgntOcZ8YG9vWfn5l2XhZABSXwHhYbLLnO4EYAwM R9O2Mlp9HZpnACETTh7fkFcfmou9z6yiXZOyRdjjx9vdf1Qm1Q7B7jLW5JC1RdtIOZxc 31wJMBwum01wGUJtbgCfC7JHq+FbSAOoipXaUGu/EQcOpUO87QO4oXH2rj2FTRPOl0VN najdHFggVW1cOKzvHwS2n1QYzOAmG81b0QTlLuP6JNzehUPieye+FFfZuxnlBz3iTCEv f8pQ== X-Gm-Message-State: AKGB3mJzxAV/ZAGszkwyTs3HWlz0Cn7vzqzX8jgO/DSG6AZf6B+/Jwm9 ui4B9emG1P5CSUaRASq/5QaPOS+WI9mvfpd9bNxRUg== X-Google-Smtp-Source: ACJfBotFYmEbekp3J2ybDjBxVsah3HV9OQcTklPHf3mSRiRpMJkAjjhkjkqnDPIoybXSGCpgkEHu1Y9V/iSjNgaV5z4= X-Received: by 10.129.154.22 with SMTP id r22mr33049670ywg.296.1514921919799; Tue, 02 Jan 2018 11:38:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 11:37:59 -0800 (PST) In-Reply-To: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> From: Eric Rescorla Date: Tue, 2 Jan 2018 11:37:59 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0bb4e8e473e40561d03e8a" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:38:44 -0000 --94eb2c0bb4e8e473e40561d03e8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A similar idea was proposed a while back, albeit with simpler semantics: https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 Discussion here: https://www.ietf.org/mail-archive/web/tls/current/msg20264.html I'm not really enthusiastic about any of these ideas for any of the administratively prohibited use cases because the information being provided to the user is unverifiable. I.e., this just tells you that someone on the network didn't like it, but the message itself is just an assertion (this is different from 451 in that that's provided inside the TLS channel if TLS is used). It's not like, for instance, the browser should display the string to the user as if it were true. The captive portal case seems a bit more plausible, in that it can be machine processed by the client to do some sort of captive portal detection thingy (e.g., connect to a site over HTTP). However, the right place to bring this kind of proposal would probably be CAPPORT (https://tools.ietf.org/wg/capport/). However, I see that they are pursuing a different direction based on HTTP. -Ekr On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jo=C5=84czyk w= rote: > Hello, > OpenDNS by default blocks websites that are used for phishing and > optionally > other sites as configured by the deployer. It does this by DNS poisoning: > it > responds with a forged A or AAAA response that redirects to their server. > An > example website blocked by OpenDNS in this manner is > https://internetbadguys.com/. > > When OpenDNS blocks a website that is served by HTTPS, the user is > presented > with a "Certificate Error" message. To see what happened, she then has to > accept > the incorrect certificate or visit the plain HTTP version of the webpage. > This > creates some problems: aside from a bad user experience, it makes users > accustomed to ignoring certificate errors. > > Another problem is created by captive portals: networks that use "a web > page > which is displayed to newly connected users before they are granted broad= er > access to network resources." (Wikipedia). > > This could be solved by specifying two new values of AlertDescription: > access_administratively_disabled and captive_portal as well as a new > field to > struct Alert: alert_message. > > Let alert_message be a fixed-length UTF-8-encoded string. It would be onl= y > valid > for > (description =3D=3D access_administratively_disabled > || > description =3D=3D captive_portal) > and otherwise a client would HAVE TO ignore it. It would be plain-text fo= r > simplicity, shortness and security. It would be null-terminated and then > randomly padded to a size of perhaps 100 bytes. A TLS client would HAVE T= O > filter the message for any odd characters, invalid UTF-8 sequences, etc. > as will > be specified in the standard. > > Greetings, > Mateusz Jo=C5=84czyk > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0bb4e8e473e40561d03e8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A similar idea was proposed a while back, albeit with= simpler semantics:


Disc= ussion here:


I'm= not really enthusiastic about any of these ideas for any of the administra= tively prohibited
use cases because the information being provide= d to the user is unverifiable. I.e., this
just tells you that som= eone on the network didn't like it, but the message itself is just
an assertion (this is different from 451 in that that's provided = inside the TLS channel
if TLS is used). It's not like, for in= stance, the browser should display the string to the
user as if i= t were true.

The captive portal case seems a bit m= ore plausible, in that it can be machine processed
by the client = to do some sort of captive portal detection thingy (e.g., connect to
<= div>a site over HTTP). However, the right place to bring this kind of propo= sal would probably be
CAPPORT (https://tools.ietf.org/wg/capport/). However, I see that t= hey are pursuing
a different direction based on HTTP.
<= br>
-Ekr



<= /div>

On Tue= , Jan 2, 2018 at 11:15 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl>= wrote:
Hello,
OpenDNS by default blocks websites that are used for phishing and optionall= y
other sites as configured by the deployer. It does this by DNS poisoning: i= t
responds with a forged A or AAAA response that redirects to their server. A= n
example website blocked by OpenDNS in this manner is https://internetbad= guys.com/.

When OpenDNS blocks a website that is served by HTTPS, the user is presente= d
with a "Certificate Error" message. To see what happened, she the= n has to accept
the incorrect certificate or visit the plain HTTP version of the webpage. T= his
creates some problems: aside from a bad user experience, it makes users
accustomed to ignoring certificate errors.

Another problem is created by captive portals: networks that use "a we= b page
which is displayed to newly connected users before they are granted broader=
access to network resources." (Wikipedia).

This could be solved by specifying two new values of AlertDescription:
access_administratively_disabled and captive_portal as well as a new f= ield to
struct Alert: alert_message.

Let alert_message be a fixed-length UTF-8-encoded string. It would be only = valid
for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (description =3D=3D access_administratively_disabled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ||
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description =3D=3D captive_portal)
and otherwise a client would HAVE TO ignore it. It would be plain-text for<= br> simplicity, shortness and security. It would be null-terminated and then randomly padded to a size of perhaps 100 bytes. A TLS client would HAVE TO<= br> filter the message for any odd characters, invalid UTF-8 sequences, etc. as= will
be specified in the standard.

Greetings,
Mateusz Jo=C5=84czyk

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

--94eb2c0bb4e8e473e40561d03e8a-- From nobody Tue Jan 2 12:02:00 2018 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 BB7B012D82F for ; Tue, 2 Jan 2018 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sYW5Uv5LSy6t for ; Tue, 2 Jan 2018 12:01:55 -0800 (PST) Received: from atl4mhob19.registeredsite.com (atl4mhob19.registeredsite.com [209.17.115.112]) (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 DC97212D80E for ; Tue, 2 Jan 2018 12:01:54 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id w02K1pF4013734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Jan 2018 15:01:52 -0500 Message-Id: <201801022001.w02K1pF4013734@atl4mhob19.registeredsite.com> Received: (qmail 27972 invoked by uid 0); 2 Jan 2018 20:01:51 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 2 Jan 2018 20:01:51 -0000 SavedFromEmail: jw@pcthink.com Date: Tue, 02 Jan 2018 15:01:48 -0500 In-Reply-To: Importance: normal From: JW To: Eric Rescorla , =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: jw@pcthink.com, tls@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_6924514054049550" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 20:01:58 -0000 ----_com.samsung.android.email_6924514054049550 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksCk15IGNvbGxlYWd1ZXMgYW5kIEkgYXJlIGN1cnJlbnRseSBwdXJzdWluZyBhIFRMUyBleHRl bnNpb24gdG8gYWRkcmVzcyBhIHZlcnkgc2ltaWxhciBzY2VuYXJpby7CoCBJdCBpcyBnb29kIHRv IHNlZSB3ZSBhcmUgbm90IGFsb25lIGluIHRoaXMgcHVyc3VpdC4KV2UgYXJlIHN0aWxsIHdvcmtp bmcgb3V0IGRldGFpbHMgYXQgYSBzb21ld2hhdCBoaWdoIGxldmVsIGJ1dCBleHBlY3QgdG8gaGF2 ZSBhIGRyYWZ0IG91dCBzaG9ydGx5LsKgIFBsZWFzZSBmZWVsIGZyZWUgdG8gY29udGFjdCBtZSBp ZiB5b3Ugd291bGQgbGlrZSB0byBiZSBpbmNsdWRlZCBpbiBvdXIgZGlzY3Vzc2lvbnMuCgpUaGFu a3MsSm9obiBXb29kd29ydGgKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206 IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gRGF0ZTogMS8yLzE4ICAyOjM3IFBNICAoR01U LTA1OjAwKSBUbzogTWF0ZXVzeiBKb8WEY3p5ayA8bWF0LmpvbmN6eWtAbzIucGw+IENjOiB0bHNA aWV0Zi5vcmcgU3ViamVjdDogUmU6IFtUTFNdIENhcHRpdmUgcG9ydGFscywgImFjY2VzcyBhZG1p bmlzdHJhdGl2ZWx5IGRpc2FibGVkIiBhbmQgYWxlcnQgbWVzc2FnZXMgCkEgc2ltaWxhciBpZGVh IHdhcyBwcm9wb3NlZCBhIHdoaWxlIGJhY2ssIGFsYmVpdCB3aXRoIHNpbXBsZXIgc2VtYW50aWNz OgrCoCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVtb24tdGxzLWJsb2NraW5n LWFsZXJ0LTAwCgpEaXNjdXNzaW9uIGhlcmU6CsKgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMjAyNjQuaHRtbAoKSSdtIG5vdCByZWFsbHkgZW50 aHVzaWFzdGljIGFib3V0IGFueSBvZiB0aGVzZSBpZGVhcyBmb3IgYW55IG9mIHRoZSBhZG1pbmlz dHJhdGl2ZWx5IHByb2hpYml0ZWR1c2UgY2FzZXMgYmVjYXVzZSB0aGUgaW5mb3JtYXRpb24gYmVp bmcgcHJvdmlkZWQgdG8gdGhlIHVzZXIgaXMgdW52ZXJpZmlhYmxlLiBJLmUuLCB0aGlzanVzdCB0 ZWxscyB5b3UgdGhhdCBzb21lb25lIG9uIHRoZSBuZXR3b3JrIGRpZG4ndCBsaWtlIGl0LCBidXQg dGhlIG1lc3NhZ2UgaXRzZWxmIGlzIGp1c3RhbiBhc3NlcnRpb24gKHRoaXMgaXMgZGlmZmVyZW50 IGZyb20gNDUxIGluIHRoYXQgdGhhdCdzIHByb3ZpZGVkIGluc2lkZSB0aGUgVExTIGNoYW5uZWxp ZiBUTFMgaXMgdXNlZCkuIEl0J3Mgbm90IGxpa2UsIGZvciBpbnN0YW5jZSwgdGhlIGJyb3dzZXIg c2hvdWxkIGRpc3BsYXkgdGhlIHN0cmluZyB0byB0aGV1c2VyIGFzIGlmIGl0IHdlcmUgdHJ1ZS4K VGhlIGNhcHRpdmUgcG9ydGFsIGNhc2Ugc2VlbXMgYSBiaXQgbW9yZSBwbGF1c2libGUsIGluIHRo YXQgaXQgY2FuIGJlIG1hY2hpbmUgcHJvY2Vzc2VkYnkgdGhlIGNsaWVudCB0byBkbyBzb21lIHNv cnQgb2YgY2FwdGl2ZSBwb3J0YWwgZGV0ZWN0aW9uIHRoaW5neSAoZS5nLiwgY29ubmVjdCB0b2Eg c2l0ZSBvdmVyIEhUVFApLiBIb3dldmVyLCB0aGUgcmlnaHQgcGxhY2UgdG8gYnJpbmcgdGhpcyBr aW5kIG9mIHByb3Bvc2FsIHdvdWxkIHByb2JhYmx5IGJlQ0FQUE9SVCAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy93Zy9jYXBwb3J0LykuIEhvd2V2ZXIsIEkgc2VlIHRoYXQgdGhleSBhcmUgcHVyc3Vp bmdhIGRpZmZlcmVudCBkaXJlY3Rpb24gYmFzZWQgb24gSFRUUC4KLUVrcgoKCgpPbiBUdWUsIEph biAyLCAyMDE4IGF0IDExOjE1IEFNLCBNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5w bD4gd3JvdGU6CkhlbGxvLAoKT3BlbkROUyBieSBkZWZhdWx0IGJsb2NrcyB3ZWJzaXRlcyB0aGF0 IGFyZSB1c2VkIGZvciBwaGlzaGluZyBhbmQgb3B0aW9uYWxseQoKb3RoZXIgc2l0ZXMgYXMgY29u ZmlndXJlZCBieSB0aGUgZGVwbG95ZXIuIEl0IGRvZXMgdGhpcyBieSBETlMgcG9pc29uaW5nOiBp dAoKcmVzcG9uZHMgd2l0aCBhIGZvcmdlZCBBIG9yIEFBQUEgcmVzcG9uc2UgdGhhdCByZWRpcmVj dHMgdG8gdGhlaXIgc2VydmVyLiBBbgoKZXhhbXBsZSB3ZWJzaXRlIGJsb2NrZWQgYnkgT3BlbkRO UyBpbiB0aGlzIG1hbm5lciBpcyBodHRwczovL2ludGVybmV0YmFkZ3V5cy5jb20vLgoKCgpXaGVu IE9wZW5ETlMgYmxvY2tzIGEgd2Vic2l0ZSB0aGF0IGlzIHNlcnZlZCBieSBIVFRQUywgdGhlIHVz ZXIgaXMgcHJlc2VudGVkCgp3aXRoIGEgIkNlcnRpZmljYXRlIEVycm9yIiBtZXNzYWdlLiBUbyBz ZWUgd2hhdCBoYXBwZW5lZCwgc2hlIHRoZW4gaGFzIHRvIGFjY2VwdAoKdGhlIGluY29ycmVjdCBj ZXJ0aWZpY2F0ZSBvciB2aXNpdCB0aGUgcGxhaW4gSFRUUCB2ZXJzaW9uIG9mIHRoZSB3ZWJwYWdl LiBUaGlzCgpjcmVhdGVzIHNvbWUgcHJvYmxlbXM6IGFzaWRlIGZyb20gYSBiYWQgdXNlciBleHBl cmllbmNlLCBpdCBtYWtlcyB1c2VycwoKYWNjdXN0b21lZCB0byBpZ25vcmluZyBjZXJ0aWZpY2F0 ZSBlcnJvcnMuCgoKCkFub3RoZXIgcHJvYmxlbSBpcyBjcmVhdGVkIGJ5IGNhcHRpdmUgcG9ydGFs czogbmV0d29ya3MgdGhhdCB1c2UgImEgd2ViIHBhZ2UKCndoaWNoIGlzIGRpc3BsYXllZCB0byBu ZXdseSBjb25uZWN0ZWQgdXNlcnMgYmVmb3JlIHRoZXkgYXJlIGdyYW50ZWQgYnJvYWRlcgoKYWNj ZXNzIHRvIG5ldHdvcmsgcmVzb3VyY2VzLiIgKFdpa2lwZWRpYSkuCgoKClRoaXMgY291bGQgYmUg c29sdmVkIGJ5IHNwZWNpZnlpbmcgdHdvIG5ldyB2YWx1ZXMgb2YgQWxlcnREZXNjcmlwdGlvbjoK CmFjY2Vzc19hZG1pbmlzdHJhdGl2ZWx5X2Rpc2FibGVkIGFuZCBjYXB0aXZlX3BvcnRhbCBhcyB3 ZWxsIGFzIGEgbmV3IGZpZWxkIHRvCgpzdHJ1Y3QgQWxlcnQ6IGFsZXJ0X21lc3NhZ2UuCgoKCkxl dCBhbGVydF9tZXNzYWdlIGJlIGEgZml4ZWQtbGVuZ3RoIFVURi04LWVuY29kZWQgc3RyaW5nLiBJ dCB3b3VsZCBiZSBvbmx5IHZhbGlkCgpmb3IKCsKgIMKgIMKgIMKgIChkZXNjcmlwdGlvbiA9PSBh Y2Nlc3NfYWRtaW5pc3RyYXRpdmVseV9kaXNhYmxlZAoKwqAgwqAgwqAgwqAgfHwKCsKgIMKgIMKg IMKgIGRlc2NyaXB0aW9uID09IGNhcHRpdmVfcG9ydGFsKQoKYW5kIG90aGVyd2lzZSBhIGNsaWVu dCB3b3VsZCBIQVZFIFRPIGlnbm9yZSBpdC4gSXQgd291bGQgYmUgcGxhaW4tdGV4dCBmb3IKCnNp bXBsaWNpdHksIHNob3J0bmVzcyBhbmQgc2VjdXJpdHkuIEl0IHdvdWxkIGJlIG51bGwtdGVybWlu YXRlZCBhbmQgdGhlbgoKcmFuZG9tbHkgcGFkZGVkIHRvIGEgc2l6ZSBvZiBwZXJoYXBzIDEwMCBi eXRlcy4gQSBUTFMgY2xpZW50IHdvdWxkIEhBVkUgVE8KCmZpbHRlciB0aGUgbWVzc2FnZSBmb3Ig YW55IG9kZCBjaGFyYWN0ZXJzLCBpbnZhbGlkIFVURi04IHNlcXVlbmNlcywgZXRjLiBhcyB3aWxs CgpiZSBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLgoKCgpHcmVldGluZ3MsCgpNYXRldXN6IEpv xYRjenlrCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CgpUTFMgbWFpbGluZyBsaXN0CgpUTFNAaWV0Zi5vcmcKCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzCgoKCg== ----_com.samsung.android.email_6924514054049550 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5IaSw8ZGl2Pjxicj48L2Rpdj48ZGl2 Pk15IGNvbGxlYWd1ZXMgYW5kIEkgYXJlIGN1cnJlbnRseSBwdXJzdWluZyBhIFRMUyBleHRlbnNp b24gdG8gYWRkcmVzcyBhIHZlcnkgc2ltaWxhciBzY2VuYXJpby4mbmJzcDsgSXQgaXMgZ29vZCB0 byBzZWUgd2UgYXJlIG5vdCBhbG9uZSBpbiB0aGlzIHB1cnN1aXQuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5XZSBhcmUgc3RpbGwgd29ya2luZyBvdXQgZGV0YWlscyBhdCBhIHNvbWV3aGF0IGhp Z2ggbGV2ZWwgYnV0IGV4cGVjdCB0byBoYXZlIGEgZHJhZnQgb3V0IHNob3J0bHkuJm5ic3A7IFBs ZWFzZSBmZWVsIGZyZWUgdG8gY29udGFjdCBtZSBpZiB5b3Ugd291bGQgbGlrZSB0byBiZSBpbmNs dWRlZCBpbiBvdXIgZGlzY3Vzc2lvbnMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGFua3MsPC9kaXY+PGRpdj5Kb2huIFdvb2R3b3J0aDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2lu YWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2 PjxkaXY+RnJvbTogRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OyA8L2Rpdj48ZGl2 PkRhdGU6IDEvMi8xOCAgMjozNyBQTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogTWF0ZXVz eiBKb8WEY3p5ayAmbHQ7bWF0LmpvbmN6eWtAbzIucGwmZ3Q7IDwvZGl2PjxkaXY+Q2M6IHRsc0Bp ZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbVExTXSBDYXB0aXZlIHBvcnRhbHMsICJh Y2Nlc3MgYWRtaW5pc3RyYXRpdmVseSBkaXNhYmxlZCIgYW5kIGFsZXJ0IG1lc3NhZ2VzIDwvZGl2 PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXY+QSBzaW1pbGFyIGlkZWEg d2FzIHByb3Bvc2VkIGEgd2hpbGUgYmFjaywgYWxiZWl0IHdpdGggc2ltcGxlciBzZW1hbnRpY3M6 PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxlbW9uLXRscy1ibG9ja2luZy1hbGVydC0wMCI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlbW9uLXRscy1ibG9ja2luZy1hbGVydC0wMDwvYT48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EaXNjdXNzaW9uIGhlcmU6PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj4mbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyMDI2NC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3Rscy9jdXJyZW50L21zZzIwMjY0Lmh0bWw8L2E+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSdtIG5vdCByZWFsbHkgZW50aHVzaWFzdGljIGFib3V0IGFu eSBvZiB0aGVzZSBpZGVhcyBmb3IgYW55IG9mIHRoZSBhZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0 ZWQ8L2Rpdj48ZGl2PnVzZSBjYXNlcyBiZWNhdXNlIHRoZSBpbmZvcm1hdGlvbiBiZWluZyBwcm92 aWRlZCB0byB0aGUgdXNlciBpcyB1bnZlcmlmaWFibGUuIEkuZS4sIHRoaXM8L2Rpdj48ZGl2Pmp1 c3QgdGVsbHMgeW91IHRoYXQgc29tZW9uZSBvbiB0aGUgbmV0d29yayBkaWRuJ3QgbGlrZSBpdCwg YnV0IHRoZSBtZXNzYWdlIGl0c2VsZiBpcyBqdXN0PC9kaXY+PGRpdj5hbiBhc3NlcnRpb24gKHRo aXMgaXMgZGlmZmVyZW50IGZyb20gNDUxIGluIHRoYXQgdGhhdCdzIHByb3ZpZGVkIGluc2lkZSB0 aGUgVExTIGNoYW5uZWw8L2Rpdj48ZGl2PmlmIFRMUyBpcyB1c2VkKS4gSXQncyBub3QgbGlrZSwg Zm9yIGluc3RhbmNlLCB0aGUgYnJvd3NlciBzaG91bGQgZGlzcGxheSB0aGUgc3RyaW5nIHRvIHRo ZTwvZGl2PjxkaXY+dXNlciBhcyBpZiBpdCB3ZXJlIHRydWUuPC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5UaGUgY2FwdGl2ZSBwb3J0YWwgY2FzZSBzZWVtcyBhIGJpdCBtb3JlIHBsYXVzaWJsZSwg aW4gdGhhdCBpdCBjYW4gYmUgbWFjaGluZSBwcm9jZXNzZWQ8L2Rpdj48ZGl2PmJ5IHRoZSBjbGll bnQgdG8gZG8gc29tZSBzb3J0IG9mIGNhcHRpdmUgcG9ydGFsIGRldGVjdGlvbiB0aGluZ3kgKGUu Zy4sIGNvbm5lY3QgdG88L2Rpdj48ZGl2PmEgc2l0ZSBvdmVyIEhUVFApLiBIb3dldmVyLCB0aGUg cmlnaHQgcGxhY2UgdG8gYnJpbmcgdGhpcyBraW5kIG9mIHByb3Bvc2FsIHdvdWxkIHByb2JhYmx5 IGJlPC9kaXY+PGRpdj5DQVBQT1JUICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3dn L2NhcHBvcnQvIj5odHRwczovL3Rvb2xzLmlldGYub3JnL3dnL2NhcHBvcnQvPC9hPikuIEhvd2V2 ZXIsIEkgc2VlIHRoYXQgdGhleSBhcmUgcHVyc3Vpbmc8L2Rpdj48ZGl2PmEgZGlmZmVyZW50IGRp cmVjdGlvbiBiYXNlZCBvbiBIVFRQLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LUVrcjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gVHVlLCBKYW4gMiwgMjAxOCBhdCAxMToxNSBBTSwgTWF0ZXVzeiBKb8WEY3p5ayA8c3Bh biBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzptYXQuam9uY3p5a0BvMi5wbCIgdGFyZ2V0 PSJfYmxhbmsiPm1hdC5qb25jenlrQG8yLnBsPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5IZWxsbyw8YnI+Ck9wZW5E TlMgYnkgZGVmYXVsdCBibG9ja3Mgd2Vic2l0ZXMgdGhhdCBhcmUgdXNlZCBmb3IgcGhpc2hpbmcg YW5kIG9wdGlvbmFsbHk8YnI+Cm90aGVyIHNpdGVzIGFzIGNvbmZpZ3VyZWQgYnkgdGhlIGRlcGxv eWVyLiBJdCBkb2VzIHRoaXMgYnkgRE5TIHBvaXNvbmluZzogaXQ8YnI+CnJlc3BvbmRzIHdpdGgg YSBmb3JnZWQgQSBvciBBQUFBIHJlc3BvbnNlIHRoYXQgcmVkaXJlY3RzIHRvIHRoZWlyIHNlcnZl ci4gQW48YnI+CmV4YW1wbGUgd2Vic2l0ZSBibG9ja2VkIGJ5IE9wZW5ETlMgaW4gdGhpcyBtYW5u ZXIgaXMgPGEgaHJlZj0iaHR0cHM6Ly9pbnRlcm5ldGJhZGd1eXMuY29tLyIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pbnRlcm5ldGJhZGd1eXMuY29tLzwvYT4uPGJy Pgo8YnI+CldoZW4gT3BlbkROUyBibG9ja3MgYSB3ZWJzaXRlIHRoYXQgaXMgc2VydmVkIGJ5IEhU VFBTLCB0aGUgdXNlciBpcyBwcmVzZW50ZWQ8YnI+CndpdGggYSAiQ2VydGlmaWNhdGUgRXJyb3Ii IG1lc3NhZ2UuIFRvIHNlZSB3aGF0IGhhcHBlbmVkLCBzaGUgdGhlbiBoYXMgdG8gYWNjZXB0PGJy Pgp0aGUgaW5jb3JyZWN0IGNlcnRpZmljYXRlIG9yIHZpc2l0IHRoZSBwbGFpbiBIVFRQIHZlcnNp b24gb2YgdGhlIHdlYnBhZ2UuIFRoaXM8YnI+CmNyZWF0ZXMgc29tZSBwcm9ibGVtczogYXNpZGUg ZnJvbSBhIGJhZCB1c2VyIGV4cGVyaWVuY2UsIGl0IG1ha2VzIHVzZXJzPGJyPgphY2N1c3RvbWVk IHRvIGlnbm9yaW5nIGNlcnRpZmljYXRlIGVycm9ycy48YnI+Cjxicj4KQW5vdGhlciBwcm9ibGVt IGlzIGNyZWF0ZWQgYnkgY2FwdGl2ZSBwb3J0YWxzOiBuZXR3b3JrcyB0aGF0IHVzZSAiYSB3ZWIg cGFnZTxicj4Kd2hpY2ggaXMgZGlzcGxheWVkIHRvIG5ld2x5IGNvbm5lY3RlZCB1c2VycyBiZWZv cmUgdGhleSBhcmUgZ3JhbnRlZCBicm9hZGVyPGJyPgphY2Nlc3MgdG8gbmV0d29yayByZXNvdXJj ZXMuIiAoV2lraXBlZGlhKS48YnI+Cjxicj4KVGhpcyBjb3VsZCBiZSBzb2x2ZWQgYnkgc3BlY2lm eWluZyB0d28gbmV3IHZhbHVlcyBvZiBBbGVydERlc2NyaXB0aW9uOjxicj4KYWNjZXNzX2FkbWlu aXN0cmF0aXZlbHlfPHdicj5kaXNhYmxlZCBhbmQgY2FwdGl2ZV9wb3J0YWwgYXMgd2VsbCBhcyBh IG5ldyBmaWVsZCB0bzxicj4Kc3RydWN0IEFsZXJ0OiBhbGVydF9tZXNzYWdlLjxicj4KPGJyPgpM ZXQgYWxlcnRfbWVzc2FnZSBiZSBhIGZpeGVkLWxlbmd0aCBVVEYtOC1lbmNvZGVkIHN0cmluZy4g SXQgd291bGQgYmUgb25seSB2YWxpZDxicj4KZm9yPGJyPgombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgKGRlc2NyaXB0aW9uID09IGFjY2Vzc19hZG1pbmlzdHJhdGl2ZWx5Xzx3YnI+ZGlzYWJs ZWQ8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8fDxicj4KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGRlc2NyaXB0aW9uID09IGNhcHRpdmVfcG9ydGFsKTxicj4KYW5kIG90aGVy d2lzZSBhIGNsaWVudCB3b3VsZCBIQVZFIFRPIGlnbm9yZSBpdC4gSXQgd291bGQgYmUgcGxhaW4t dGV4dCBmb3I8YnI+CnNpbXBsaWNpdHksIHNob3J0bmVzcyBhbmQgc2VjdXJpdHkuIEl0IHdvdWxk IGJlIG51bGwtdGVybWluYXRlZCBhbmQgdGhlbjxicj4KcmFuZG9tbHkgcGFkZGVkIHRvIGEgc2l6 ZSBvZiBwZXJoYXBzIDEwMCBieXRlcy4gQSBUTFMgY2xpZW50IHdvdWxkIEhBVkUgVE88YnI+CmZp bHRlciB0aGUgbWVzc2FnZSBmb3IgYW55IG9kZCBjaGFyYWN0ZXJzLCBpbnZhbGlkIFVURi04IHNl cXVlbmNlcywgZXRjLiBhcyB3aWxsPGJyPgpiZSBzcGVjaWZpZWQgaW4gdGhlIHN0YW5kYXJkLjxi cj4KPGJyPgpHcmVldGluZ3MsPGJyPgpNYXRldXN6IEpvxYRjenlrPGJyPgo8YnI+Cl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+ClRMUyBtYWls aW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwv YT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuLzx3YnI+bGlzdGluZm8vdGxzPC9hPjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48 L2Rpdj4KPC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_6924514054049550-- From nobody Tue Jan 2 12:08:47 2018 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 2C42D12D82D for ; Tue, 2 Jan 2018 12:08:46 -0800 (PST) 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, FREEMAIL_FROM=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 lr-8Ku5MOyOw for ; Tue, 2 Jan 2018 12:08:44 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.175]) (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 45F7012D810 for ; Tue, 2 Jan 2018 12:08:43 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 2444 invoked from network); 2 Jan 2018 21:08:41 +0100 Received: from ceh60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.30.183.60]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 2 Jan 2018 21:08:41 +0100 To: Eric Rescorla References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> Cc: tls@ietf.org From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> Date: Tue, 2 Jan 2018 21:08:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 33865c68abc9f8a649d6c38483856c97 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [gXOU] Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 20:08:46 -0000 Hello, Thank You for reviewing my email. W dniu 02.01.2018 o 20:37, Eric Rescorla pisze: > A similar idea was proposed a while back, albeit with simpler semantics: > > https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 > > Discussion here: > > https://www.ietf.org/mail-archive/web/tls/current/msg20264.html > > I'm not really enthusiastic about any of these ideas for any of the > administratively prohibited > use cases because the information being provided to the user is unverifiable. > I.e., this > just tells you that someone on the network didn't like it, but the message > itself is just > an assertion (this is different from 451 in that that's provided inside the TLS > channel > if TLS is used). It's not like, for instance, the browser should display the > string to the > user as if it were true. Then the browser should display a message inside the warning screen that the string cannot be trusted. This is no less secure then an alternative: a TLS certificate error that conveys no message to the user whatsoever. The message could theoretically be signed by some filtering party, but this is out of scope here. Additionally, error 451 is / could be currently typically delivered by network intermediaries. It is much more common that network intermediaries / ISPs block content than website providers do so. When the whole world will use HTTPS, there will be almost no use of error 451 whatsoever (apart from SSL MITM). > > The captive portal case seems a bit more plausible, in that it can be machine > processed > by the client to do some sort of captive portal detection thingy (e.g., connect to > a site over HTTP). However, the right place to bring this kind of proposal would > probably be > CAPPORT (https://tools.ietf.org/wg/capport/). However, I see that they are pursuing > a different direction based on HTTP. > > -Ekr Responding to a message from Brian Smith, > Standardizing and implementing things like this signals, politically, that we > accept and even encourage censorship like we see in China and many other > places already in the world. That, on its own, makes this a non-starter. If so, then the document should specify that filtering is discouraged or something similar. Greetings, Mateusz Jończyk > > > > > On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jończyk > wrote: > > Hello, > OpenDNS by default blocks websites that are used for phishing and optionally > other sites as configured by the deployer. It does this by DNS poisoning: it > responds with a forged A or AAAA response that redirects to their server. An > example website blocked by OpenDNS in this manner is > https://internetbadguys.com/. > > When OpenDNS blocks a website that is served by HTTPS, the user is presented > with a "Certificate Error" message. To see what happened, she then has to accept > the incorrect certificate or visit the plain HTTP version of the webpage. This > creates some problems: aside from a bad user experience, it makes users > accustomed to ignoring certificate errors. > > Another problem is created by captive portals: networks that use "a web page > which is displayed to newly connected users before they are granted broader > access to network resources." (Wikipedia). > > This could be solved by specifying two new values of AlertDescription: > access_administratively_disabled and captive_portal as well as a new field to > struct Alert: alert_message. > > Let alert_message be a fixed-length UTF-8-encoded string. It would be only valid > for > (description == access_administratively_disabled > || > description == captive_portal) > and otherwise a client would HAVE TO ignore it. It would be plain-text for > simplicity, shortness and security. It would be null-terminated and then > randomly padded to a size of perhaps 100 bytes. A TLS client would HAVE TO > filter the message for any odd characters, invalid UTF-8 sequences, etc. as will > be specified in the standard. > > Greetings, > Mateusz Jończyk > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > From nobody Tue Jan 2 12:18:49 2018 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 0413D12D7EF for ; Tue, 2 Jan 2018 12:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, T_SPF_TEMPERROR=0.01] 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 qU8l83yqUzWb for ; Tue, 2 Jan 2018 12:18:45 -0800 (PST) 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 A808812422F for ; Tue, 2 Jan 2018 12:18:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70B28BE4D; Tue, 2 Jan 2018 20:18:44 +0000 (GMT) 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 iFOKP8e-vjr9; Tue, 2 Jan 2018 20:18:43 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE5D8BE49; Tue, 2 Jan 2018 20:18:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1514924323; bh=KnHTdne8zZBZF9BqP1OKimL/p1QWmuoDf8qphHsfhVk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UYX6xsghlOGUo0C1mzfLG4wvcgGNI7d5SqBdq40aiSrfIR6qjSVrZUeUCTIQbgSAQ n8kThGcjq3Ttfw00O517yKjJOoz0sTVrn/kAg0+gqJiB3EbrIFeMbTPr7IckRstos5 fI+bth4vIMRzmbbbPUau8Ot9D6a3fAeO3p6fjP+Y= To: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= , Eric Rescorla Cc: tls@ietf.org References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Tue, 2 Jan 2018 20:18:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9HEruOzIMpcmYm3ysW7gg41hGigQygk8G" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 20:18:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9HEruOzIMpcmYm3ysW7gg41hGigQygk8G Content-Type: multipart/mixed; boundary="sH7DwnQslMOcPVsaNth3MJxd65oi8Fj05"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= , Eric Rescorla Cc: tls@ietf.org Message-ID: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> In-Reply-To: <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> --sH7DwnQslMOcPVsaNth3MJxd65oi8Fj05 Content-Type: multipart/mixed; boundary="------------281A829FCD5DDCF0A025E656" Content-Language: en-GB This is a multi-part message in MIME format. --------------281A829FCD5DDCF0A025E656 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/01/18 20:08, Mateusz Jo=C5=84czyk wrote: >> I'm not really enthusiastic about any of these ideas for any of the >> administratively prohibited >> use cases because the information being provided to the user is unveri= fiable. >> I.e., this >> just tells you that someone on the network didn't like it, but the mes= sage >> itself is just >> an assertion (this is different from 451 in that that's provided insid= e the TLS >> channel >> if TLS is used). It's not like, for instance, the browser should displ= ay the >> string to the >> user as if it were true. > Then the browser should display a message inside the warning screen tha= t the > string cannot be trusted.=20 There isn't always a browser. I'd say caldav was responsible for nearly as many cert warnings for me, but I only know that 'cause I delved into detail to find out. And the same'd be true of any application that regularly pulls from somewhere. I think that's another reason to handle this in the capport wg - I'd guess folks there are more aware of the full range of cases that may need handling and of how to try interpose the portal web page stuff before other applications see the n/w as active (or whatever it is they're doing with HTTP:-). > This is no less secure then an alternative: a TLS > certificate error that conveys no message to the user whatsoever. That's true. OTOH, I'm not sure a different error is any more secure either. S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------281A829FCD5DDCF0A025E656 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------281A829FCD5DDCF0A025E656-- --sH7DwnQslMOcPVsaNth3MJxd65oi8Fj05-- --9HEruOzIMpcmYm3ysW7gg41hGigQygk8G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaS+kiAAoJEFqy+vF7FyvqR4kP/RlFz7m890W/Yz7917Sv7UHf DjmdcP4WCEp/fyGzp9JlTjSYLJFDVcFJcmvKxSu7zqCW0CPz0a+GHHlR4elEHJZC jxz5IojDYXYREslCcM5iG4GD4XyuHLySetHdWK9q5sdUPwZPUf7sspkqM9ElaemD sUHnkeWfWfx4YS5aj91CWZwQKYpI85cvRJZ/mR+mO+/KlZEeGIwiswgyEAQmmz+m a1HSNLOckSZzZ9FaQiCnUZmz4Ay185kZT59KBAMHdpCov5hh9jKHb8ZEtZsW4xYa eWCAG0zQBa7c6S61i3cTqCJw1siRBbOvZIaAOofeKiKl1y29HU2LoLIIJ60dp1RN kxjzwvxPRKvX3BFJ0+HVZRaaTAutwPrBBd+hq32IFJ/ttvYMs/AjUsSkPYNuE/hu pcnk0nb0vjm/KueYWnhalpOseb75LJ4jrBW1mn7qn6XSwSg2ltgg0/m+Z+YkMHu3 jbiTAT/M4LHuT2gLFjSclSTBPBtm+jTsDHqwBbnVFtJrKjWfnGTB2y/luVvEc+6Z qqc+w3djaPORzLLpMTdY6tBJ0aqdAV9X8d2sjFPj35CBaD1vl0J3vv/iq9i7i3ES 9YlbTCfGFeBNZKK+47tXMs8xiMnwqADAWWh0m2EC2GVbjclQIXsBX0xcyDdP2T/i y2JNze6eX5rAhT4wWPG8 =7Y7W -----END PGP SIGNATURE----- --9HEruOzIMpcmYm3ysW7gg41hGigQygk8G-- From nobody Tue Jan 2 12:21:29 2018 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 15A6E127077 for ; Tue, 2 Jan 2018 12:21:28 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 awH-nVWByf2z for ; Tue, 2 Jan 2018 12:21:25 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 A9445127076 for ; Tue, 2 Jan 2018 12:21:25 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id w1so19119640ybe.10 for ; Tue, 02 Jan 2018 12:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DzwmzM4zLpDWK8QZMzKoChrnYHTNSUj3yBj0hrV5O/o=; b=mlzM7fsGgwrCjZs5AAsD27+5mQCpN39owOJbG3WBGBIMCBu0p0Q7f3aGFYHb+DeUMP jN9X4/xZ0zeB0F1fYyK8qRNS3CK/iOMz86rzpYf6yGagQf8lxxSo9ciaXHQwrhLXO7h8 wKaUEA+VYaEsjaSkyJK31rzpRweTHSrNNdq0Wbd4FY9fwqGbCxwkW93D7QpjeXWJdNVF MEU1nQN6Yd+Rs3sGyCcJmOQg5za89Wo9GY8wxsvFRwg2KPOQA5dvKigUorqOcFFSKnu3 Ndl9pQtm3LGDqDwvlaMQINZmItEb5cZcdgNu9dB7F1DgOJ2B+JE1SfPeChLIHfFgwUR1 PitQ== 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:references:from:date :message-id:subject:to:cc; bh=DzwmzM4zLpDWK8QZMzKoChrnYHTNSUj3yBj0hrV5O/o=; b=lWXMMDKjnW1qcjH791+SHpbm+sZ1OwEDZ+MplRQkZlzIXc00OE5pPcGQ5U8sUl74yQ dOstbpMkVNd65F0GMVWJSwBTn5Fgmdb1+wFUb0EWf2Kk6SKUkP9oGetEhljNf2BQZR4Y 5EELuj8scSuVOmP/GqxGjU2dpnGPgNvuCMTwsUpqG8Rmch6yX55ttnu8PNfnse0em8lR B2UaEf8yyuDVhs/FpRWvHZgHYgmsIc/LCgSNYhQDhKMR7g3qFDGG9UR/tboPGqeH7TIf kyqpKk9aMDB9yBUWKdyhN5YV7JiWb5CMmqhH/X57dEj+Nlty7xjzXXVzXZu+2YC0IjsC 074A== X-Gm-Message-State: AKGB3mIGn1rs9Jw4yYA/2i/CgGvVadi7xeh1S5obdcGNude99N79OzFz s2e8+vNU1ypYonP1+Rb2+BeKFwPE/8yGz3q5GbXRZA== X-Google-Smtp-Source: ACJfBovlJinsDwSyWhK4bMA3pxsY4iPzl+n7e9WYzY5tr3zXlP63xYjpm0hzcMLo/J5Qbj+dxcxHrAI6xCV8I7Hf79w= X-Received: by 10.37.78.212 with SMTP id c203mr17344175ybb.423.1514924484739; Tue, 02 Jan 2018 12:21:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 12:20:44 -0800 (PST) In-Reply-To: <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> From: Eric Rescorla Date: Tue, 2 Jan 2018 12:20:44 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "" Content-Type: multipart/alternative; boundary="001a113e7f86c65abc0561d0d790" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 20:21:28 -0000 --001a113e7f86c65abc0561d0d790 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk w= rote: > Hello, > Thank You for reviewing my email. > > W dniu 02.01.2018 o 20:37, Eric Rescorla pisze: > > A similar idea was proposed a while back, albeit with simpler semantics= : > > > > https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 > > > > Discussion here: > > > > https://www.ietf.org/mail-archive/web/tls/current/msg20264.html > > > > I'm not really enthusiastic about any of these ideas for any of the > > administratively prohibited > > use cases because the information being provided to the user is > unverifiable. > > I.e., this > > just tells you that someone on the network didn't like it, but the > message > > itself is just > > an assertion (this is different from 451 in that that's provided inside > the TLS > > channel > > if TLS is used). It's not like, for instance, the browser should displa= y > the > > string to the > > user as if it were true. > > Then the browser should display a message inside the warning screen that > the > string cannot be trusted. Users tend to ignore that kind of warning. > This is no less secure then an alternative: a TLS > certificate error that conveys no message to the user whatsoever. > No, I don't believe that that's correct, because the certificate warning does not contain attacker-controlled information. > Additionally, error 451 is / could be currently typically delivered by > network > intermediaries. It is much more common that network intermediaries / ISPs > block > content than website providers do so. When the whole world will use HTTPS= , > there > will be almost no use of error 451 whatsoever (apart from SSL MITM). > The point of the comparison to 451 is to examine the security properties, not to say that 451 works particularly well. -Ekr > > The captive portal case seems a bit more plausible, in that it can be > machine > > processed > > by the client to do some sort of captive portal detection thingy (e.g., > connect to > > a site over HTTP). However, the right place to bring this kind of > proposal would > > probably be > > CAPPORT (https://tools.ietf.org/wg/capport/). However, I see that they > are pursuing > > a different direction based on HTTP. > > > > -Ekr > > > Responding to a message from Brian Smith, > > > Standardizing and implementing things like this signals, politically, > that we > > accept and even encourage censorship like we see in China and many othe= r > > places already in the world. That, on its own, makes this a non-starter= . > > If so, then the document should specify that filtering is discouraged or > something similar. > > Greetings, > Mateusz Jo=C5=84czyk > > > > > > > > > > > On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jo=C5=84czyk > > wrote: > > > > Hello, > > OpenDNS by default blocks websites that are used for phishing and > optionally > > other sites as configured by the deployer. It does this by DNS > poisoning: it > > responds with a forged A or AAAA response that redirects to their > server. An > > example website blocked by OpenDNS in this manner is > > https://internetbadguys.com/. > > > > When OpenDNS blocks a website that is served by HTTPS, the user is > presented > > with a "Certificate Error" message. To see what happened, she then > has to accept > > the incorrect certificate or visit the plain HTTP version of the > webpage. This > > creates some problems: aside from a bad user experience, it makes > users > > accustomed to ignoring certificate errors. > > > > Another problem is created by captive portals: networks that use "a > web page > > which is displayed to newly connected users before they are granted > broader > > access to network resources." (Wikipedia). > > > > This could be solved by specifying two new values of > AlertDescription: > > access_administratively_disabled and captive_portal as well as a > new field to > > struct Alert: alert_message. > > > > Let alert_message be a fixed-length UTF-8-encoded string. It would > be only valid > > for > > (description =3D=3D access_administratively_disabled > > || > > description =3D=3D captive_portal) > > and otherwise a client would HAVE TO ignore it. It would be > plain-text for > > simplicity, shortness and security. It would be null-terminated and > then > > randomly padded to a size of perhaps 100 bytes. A TLS client would > HAVE TO > > filter the message for any odd characters, invalid UTF-8 sequences, > etc. as will > > be specified in the standard. > > > > Greetings, > > Mateusz Jo=C5=84czyk > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > --001a113e7f86c65abc0561d0d790 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.= pl> wrote:
Hello,
Thank You for reviewing my email.

W dniu 02.01.2018 o 20:37, Eric Rescorla pisze:
> A similar idea was proposed a while back, albeit with= simpler semantics:
>
>=C2=A0 =C2=A0https://tools.ietf.org= /html/draft-lemon-tls-blocking-alert-00
>
> Discussion here:
>
>=C2=A0 =C2=A0https://www.ietf.org= /mail-archive/web/tls/current/msg20264.html
>
> I'm not really enthusiastic about any of these ideas for any of th= e
> administratively prohibited
> use cases because the information being provided to the user is unveri= fiable.
> I.e., this
> just tells you that someone on the network didn't like it, but the= message
> itself is just
> an assertion (this is different from 451 in that that's provided i= nside the TLS
> channel
> if TLS is used). It's not like, for instance, the browser should d= isplay the
> string to the
> user as if it were true.

Then the browser should display a message inside the warning screen = that the
string cannot be trusted.

Users tend to ign= ore that kind of warning.
=C2=A0
This is no less secure then an alternative: a TLS
certificate error that conveys no message to the user whatsoever.

No, I don't believe that that's correct,= because the certificate warning does not
contain attacker-contro= lled information.

=C2=A0
Additionally, error 451 is / could be currently typically delivered by netw= ork
intermediaries. It is much more common that network intermediaries / ISPs b= lock
content than website providers do so. When the whole world will use HTTPS, = there
will be almost no use of error 451 whatsoever (apart from SSL MITM).

The point of the comparison to 451 is to exam= ine the security properties,
not to say that 451 works particular= ly well.

-Ekr
=C2=A0
> The captive portal case seems a bit more plausible, in that it can be = machine
> processed
> by the client to do some sort of captive portal detection thingy (e.g.= , connect to
> a site over HTTP). However, the right place to bring this kind of prop= osal would
> probably be
> CAPPORT (https://tools.ietf.org/wg/capport/). Howeve= r, I see that they are pursuing
> a different direction based on HTTP.
>
> -Ekr


Responding to a message from Brian Smith,
<https://www.ietf.org/mail-ar= chive/web/tls/current/msg20276.html>
> Standardizing and implementing things like this signals, politically, = that we
> accept and even encourage censorship like we see in China and many oth= er
> places already in the world. That, on its own, makes this a non-starte= r.

If so, then the document should specify that filtering is discouraged or something similar.

Greetings,
Mateusz Jo=C5=84czyk

>
>
>
>
> On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hello,
>=C2=A0 =C2=A0 =C2=A0OpenDNS by default blocks websites that are used fo= r phishing and optionally
>=C2=A0 =C2=A0 =C2=A0other sites as configured by the deployer. It does = this by DNS poisoning: it
>=C2=A0 =C2=A0 =C2=A0responds with a forged A or AAAA response that redi= rects to their server. An
>=C2=A0 =C2=A0 =C2=A0example website blocked by OpenDNS in this manner i= s
>=C2=A0 =C2=A0 =C2=A0https://internetbadguys.com/.
>
>=C2=A0 =C2=A0 =C2=A0When OpenDNS blocks a website that is served by HTT= PS, the user is presented
>=C2=A0 =C2=A0 =C2=A0with a "Certificate Error" message. To se= e what happened, she then has to accept
>=C2=A0 =C2=A0 =C2=A0the incorrect certificate or visit the plain HTTP v= ersion of the webpage. This
>=C2=A0 =C2=A0 =C2=A0creates some problems: aside from a bad user experi= ence, it makes users
>=C2=A0 =C2=A0 =C2=A0accustomed to ignoring certificate errors.
>
>=C2=A0 =C2=A0 =C2=A0Another problem is created by captive portals: netw= orks that use "a web page
>=C2=A0 =C2=A0 =C2=A0which is displayed to newly connected users before = they are granted broader
>=C2=A0 =C2=A0 =C2=A0access to network resources." (Wikipedia).
>
>=C2=A0 =C2=A0 =C2=A0This could be solved by specifying two new values o= f AlertDescription:
>=C2=A0 =C2=A0 =C2=A0access_administratively_disabled and captive_p= ortal as well as a new field to
>=C2=A0 =C2=A0 =C2=A0struct Alert: alert_message.
>
>=C2=A0 =C2=A0 =C2=A0Let alert_message be a fixed-length UTF-8-encoded s= tring. It would be only valid
>=C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(description =3D=3D acc= ess_administratively_disabled
>=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=A0description =3D=3D capt= ive_portal)
>=C2=A0 =C2=A0 =C2=A0and otherwise a client would HAVE TO ignore it. It = would be plain-text for
>=C2=A0 =C2=A0 =C2=A0simplicity, shortness and security. It would be nul= l-terminated and then
>=C2=A0 =C2=A0 =C2=A0randomly padded to a size of perhaps 100 bytes. A T= LS client would HAVE TO
>=C2=A0 =C2=A0 =C2=A0filter the message for any odd characters, invalid = UTF-8 sequences, etc. as will
>=C2=A0 =C2=A0 =C2=A0be specified in the standard.
>
>=C2=A0 =C2=A0 =C2=A0Greetings,
>=C2=A0 =C2=A0 =C2=A0Mateusz Jo=C5=84czyk
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0TLS@iet= f.org <mailto:TLS@ietf.org> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/tls
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/tls>
>
>


--001a113e7f86c65abc0561d0d790-- From nobody Tue Jan 2 13:40:14 2018 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 5666C1276AF for ; Tue, 2 Jan 2018 13:40:12 -0800 (PST) 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, FREEMAIL_FROM=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 T6HjtNJpt485 for ; Tue, 2 Jan 2018 13:40:10 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 E701C126CBF for ; Tue, 2 Jan 2018 13:40:09 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 20984 invoked from network); 2 Jan 2018 22:40:07 +0100 Received: from ceh60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.30.183.60]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 2 Jan 2018 22:40:07 +0100 To: Eric Rescorla References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> Cc: "" , Ted Lemon From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl> Date: Tue, 2 Jan 2018 22:40:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 82c83d3f094f26830790cac9155d319f X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [sXPk] Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 21:40:12 -0000 CCing Ted Lemon as the author of previous proposition. W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk > wrote: > > Then the browser should display a message inside the warning screen that the > string cannot be trusted. > > Users tend to ignore that kind of warning. Not any more then they ignore certificate warnings [2]. > > This is no less secure then an alternative: a TLS > certificate error that conveys no message to the user whatsoever. > > No, I don't believe that that's correct, because the certificate warning does not > contain attacker-controlled information. > But when the user will ignore the certificate warning (which many users will do [2]), they will see a site with attacker-controlled information anyway. And it is better not to make users used to ignoring certificate warnings. An attacker that can perform full MITM can always try to phish the user. Even a captive portal detection could be fraudulent (and redirect the user to a fraudulent site). There was an attack [1] that changed DNS settings on a router and then redirected all websites to a site that claimed that a "router upgrade" is required. This fraudulent site than phished the users to download and run an .exe file to "upgrade the router". Needless to say that this .exe file contained a virus (in this case a keylogger). In this case, how could the absence or presence of the proposed feature change anything? Greetings, Mateusz [1] https://zaufanatrzeciastrona.pl/post/uwaga-na-niebezpieczne-ataki-na-uzytkownikow-ruterow-tp-link/ (in Polish, this attack was limited to Poland so there is no English version AFAIK) [2] http://adrifelt.github.io/sslinterstitial-chi.pdf From nobody Tue Jan 2 13:56:18 2018 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 8217812D851 for ; Tue, 2 Jan 2018 13:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wHuQF36CEVFT for ; Tue, 2 Jan 2018 13:56:16 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 2D14012D852 for ; Tue, 2 Jan 2018 13:56:13 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id o64so34106385oia.9 for ; Tue, 02 Jan 2018 13:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eT9kOS+BHwXqP1lSTJKUneBIT0TvCPhdx8jIGE5be/4=; b=jbkUKTzcrCceinrUIfu5uUC3ycX6GQ8F3zhmpat3kFRFlANiDW6b6AjU6TbTVHh95M p91LCTY8ZuKUgo8+Hv17BPThubwunaeGlEQR6SUhnvW9I1LZ9GRpGkgO5c4OoQSdlzZZ 7LVD31f2m2GkRc5H27bk5YQcm9tlPwna4Qto9tZHClIHuxEv3S4qxkg8FwSBJ/QvqgVN Z+ZGKxYB3EF4SNFMympDnWwpnu9sqKIkk1rhUTpRN1NSWsR4+kBBm1G5MEGd/scc1k22 9oPegTGiK0ULFYaDcO532P3exC/9gP1OlFKbuGMiYzotpeWOccTZVc3MkZ3PVF1XZsYj oiSQ== 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:references:from:date :message-id:subject:to:cc; bh=eT9kOS+BHwXqP1lSTJKUneBIT0TvCPhdx8jIGE5be/4=; b=nTULIwRlB89CQAlinIbp/n70yF6nf+RaF3n+cuN0hcfjK5k44cNN1jjq/FpkFI5Gn3 f2TXB44yOc/NgrHEfK/BSk64LaZRyxzx9DRbeDwneff9Ns9NY+gkMqWpXAanshe815sT sSKQGhZke1nQ41Jfu8x2yc6APWpPaf1QMOTikgXoT6JI5HhL6jPhnsvnWT3Xf2/ZVT+g apOkldMv7SM/f5iGOrdemq9zAz1QICjRTNpL3dJcSEWaL4Thg2TwHwlu/nPGKHBgQun0 aMs1sSpV7gCp4l8LMoobyU3Q56qvkK1/EYhkAA0Qy9cBwC27avEG58K7TBAmoL3ZNw2M /mEw== X-Gm-Message-State: AKGB3mKuTOWuUhmiXpIZ/PhKmF0AR0pPvfzTk1u7wro/PqEHrTwFjeHD 4xEtdJkYFH2+6iUXuXXUdIxfoONJCmyqkwUg/nk= X-Google-Smtp-Source: ACJfBotm7Nt3N0VjgYVy2yzMWhXgqLrABhGtJ0Gg6KA2DttogJqI2yWDv9reujisA2t4SU1XAKotMJ6nf7+8mdcIOOo= X-Received: by 10.202.48.8 with SMTP id w8mr31368569oiw.284.1514930172426; Tue, 02 Jan 2018 13:56:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Tue, 2 Jan 2018 13:56:11 -0800 (PST) In-Reply-To: References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> From: Martin Thomson Date: Wed, 3 Jan 2018 08:56:11 +1100 Message-ID: To: Stephen Farrell Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , Eric Rescorla , tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 21:56:17 -0000 On Wed, Jan 3, 2018 at 7:18 AM, Stephen Farrell wrote: > [...] the capport wg - I'd guess folks > there are more aware of the full range of cases that may need > handling and of how to try interpose the portal web page stuff > before other applications see the n/w as active (or whatever it > is they're doing with HTTP:-). As chair of capport, this is definitely something for that group. The current approach we are taking there avoids having user equipment attempt to connect to anything at all, which avoids this class of problem. If you look at modern devices, they all probe a network before making the interface available to applications, and most of what we would be doing exists at that probing phase. We are additionally considering a network-based signal for those cases where the attempt is made anyway, but I don't think that is firm yet. Captive portal cases are separate to those related to selective blocking of names or destinations, which is essentially a censorship mechanism. We've been careful to avoid creating mechanisms to support that sort of discrimination. From nobody Tue Jan 2 13:57:05 2018 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 F396F126BF7 for ; Tue, 2 Jan 2018 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 sBku-ik0rzFT for ; Tue, 2 Jan 2018 13:57:01 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 59ED61242F7 for ; Tue, 2 Jan 2018 13:57:01 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id k80so12351888ywe.0 for ; Tue, 02 Jan 2018 13:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+nx0kKyaCciuRFBeUBKjl9w8o5hsC7HrdBR8fPRCJ18=; b=bsxuSkfc+ojaKMGCldsD83Jm+npmjE9VhqpM5zKoVatjuBZS1EV0NdtspMLZ7FgEuK mIKTkee6fRJiI+ZqN9mvuWAbt0B1YOIyvT3xvPTufQZY3moFxg8oR3cdCRKzVpWaRDRk cnvmqGV2l5DHRoynCY8WLivjC+nV+BZXZR9XMv0fManIIcozX8UWP2qbgy6wEqAbZ+zx AyhcnE0PvZxEeyHDNWQ/iM/q2nV+/KNqJoHfZ4eCXtJYZRScW8E/fQsTAYi4XGrAnI4i Awn6crVGvsOJ9VUQoWxcasxyXuuGnjxSz5IbJQdX+eUwyQDeI/44MSJ/Pgna3GHRkDm+ n4aA== 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:references:from:date :message-id:subject:to:cc; bh=+nx0kKyaCciuRFBeUBKjl9w8o5hsC7HrdBR8fPRCJ18=; b=UOCs6Dk1d1uk7eaNVSOpH4T1aBrjBT7ESsaswcNAP3BvbmQZDEpXKnVBRuUyEsYOLZ fK39mXwUjdgaDrTFGabci7MlLF71afeldl2FZJyS/61jjlRSfc+YPVb+sV/We+p33BQS CdbvWOoHd1DlyFrMAvupE51le2HYZZrq9bCu2/usJnuE3BXAVsRPY1cPX8yJ7C/i1+N2 m3lcY4h/5+2azc0jrPVTCOgmHtixoes3FgV08/piOBob9dvW4Sd7+1x8qo4xzQxz/i19 6rMAQqG9gFF2X6U6p/vdBh8uyvd9yivzshX7u95aXlKZ4xpoetLweXBa0Pkwri4ohef7 VQ/w== X-Gm-Message-State: AKGB3mJg8gbdFkh7bF3KBYaJuZImh3RfAzKWyF5K7LCzL9jwYsajIu47 TAqnLkuX7ekbZNysTImiUU/M3OPxKof9/C4c5bGQ5L1v X-Google-Smtp-Source: ACJfBosrfkf8onaFM9klowhAnMXEVZNwNTehhiqpApNSanwAisoIDlH7nlEr2vzk0opKzDlbAJSKMk+TqSPmVp3d2UU= X-Received: by 10.129.58.1 with SMTP id h1mr34344473ywa.2.1514930220465; Tue, 02 Jan 2018 13:57:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 13:56:19 -0800 (PST) In-Reply-To: <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl> References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl> From: Eric Rescorla Date: Tue, 2 Jan 2018 13:56:19 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "" , Ted Lemon Content-Type: multipart/alternative; boundary="001a1137abdca694910561d22df4" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 21:57:03 -0000 --001a1137abdca694910561d22df4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jo=C5=84czyk wr= ote: > CCing Ted Lemon as the author of previous > proposition. > > W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: > > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk > > wrote: > > > > Then the browser should display a message inside the warning screen > that the > > string cannot be trusted. > > > > Users tend to ignore that kind of warning. > Not any more then they ignore certificate warnings [2]. That's not clear. We would be providing some sort of attacker-controlled text to the user with a warning that says "you can't trust this". That's difficult to pull off. Moreover, the certificate warnings are under control of the browser, but we actively work to discourage the user from ignoring them. Moreover, for HSTS sites, the browser doesn't allow the user to override them, so providing some attacker-controlled information would make the situation materially worse. And given that a lot of the sites which people are likely to hit with captive portals are in fact HSTS sites (because HSTS is common in big sites) instead showing attacker controlled information would make things materially worse. -Ekr --001a1137abdca694910561d22df4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
CCing Ted Lemon &= lt;mellon at fugue.com> as the author of previous proposition.

W dniu 02.01.2018 o 21:20, Eric Rescorla pisze:
> On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk= <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Then the browser should display a message inside th= e warning screen that the
>=C2=A0 =C2=A0 =C2=A0string cannot be trusted.
>
> Users tend to ignore that kind of warning.
Not any more then they ignore certificate warnings [2].
=

That's not clear. We would be providing some sort o= f attacker-controlled text to the user with a warning that says "you c= an't trust this". That's difficult to pull off.

=
Moreover, the certificate warnings are under control of the brow= ser, but we actively work to discourage the user from ignoring them. Moreov= er, for HSTS sites, the browser doesn't allow the user to override them= , so providing some attacker-controlled information would make the situatio= n materially worse. And given that a lot of the sites which people are like= ly to hit with captive portals are in fact HSTS sites (because HSTS is comm= on in big sites) instead showing attacker controlled information would make= things materially worse.

-Ekr


--001a1137abdca694910561d22df4-- From nobody Tue Jan 2 14:06:35 2018 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 A6B7412D84A for ; Tue, 2 Jan 2018 14:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 q6IW5E-ROWmK for ; Tue, 2 Jan 2018 14:06:31 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 8C4AC1242F7 for ; Tue, 2 Jan 2018 14:06:31 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id a16so64887471qtj.3 for ; Tue, 02 Jan 2018 14:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yK2ECUVx10NIGNk7ftCztKpGg5f9WF3GEgEV/iT+Ta4=; b=AvZZKgnei+yHCqV4toBM3c/WBtRTuA7MtyKu/AJq3oYvJ/09M2Exz59BlJkFXWO7G5 34qPZebfnV3ENBGMakLru37dlFErqhiZnM1ze+Q+JoKDAi+Ia3Dt2oV7mTtH/xqI5rCf JRJ9vPy3dHvNJmAjhJcPkqy3nlpD69jAsirVCrGkn/jMeZHIDcgZNst6ClCWS2k3ge0T O4ZnqUTb+f1f0D/wu360bpPUuasUSpu7Jmrre7pV97CIgn1aTaM4ZOB6H/4ySoQD+UmH Pt4PSw5Ac8VP/OhJzibs1VrlKLNQtZnidWL5qc09V9KgoGU/Doyvmrfxv1/0Ks1oioIV bqPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yK2ECUVx10NIGNk7ftCztKpGg5f9WF3GEgEV/iT+Ta4=; b=UgW54FnwRP9/pdLfgs/WV4it2uGRwQkw7aL5YNGxYyfeI54VNEk3dD0qZDY4eMMoFz Hnf3ZMBmRsYDBMKVPzWz4ICVMeZil5Lug5hWWmU6GP7Ztft8Ewtqj4dLd4I4IIWrnfDR Cblukm8b0R0P671IiM+bNvMhqH23lWItaDnNyV1+NAHMzTdxa6iv0OX8r8xqTV/19ZYg nTIYkZA7Y1RPiZeaDJPV50nKo9+eYbiWkOSlF9Pl0Alj5aIWZ3a1fzS4mzO+kF7hjJpV jQ400uEiRxcQYvmeIDM4EM/TBZRCXFK7TaArWT4Zfa0/1rJQWyqcKe4JHEomek0gGpOn TGXQ== X-Gm-Message-State: AKGB3mJ62HEN/Wy3anHCiTPJNMDwE7AINoZNLFdRYtFnMonOO0fbbIAo g1ywxS87ZFmKmsBl/AiG7lSrwA== X-Google-Smtp-Source: ACJfBov4/DeKMnAdaIoeYIce4G/QUgc71G0luQCEnumxQpO6sJRMxodqUnbdiWynqV1DKmTJgGBjKw== X-Received: by 10.55.24.148 with SMTP id 20mr62431354qky.348.1514930790535; Tue, 02 Jan 2018 14:06:30 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id h21sm29392441qte.44.2018.01.02.14.06.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 14:06:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Ted Lemon In-Reply-To: Date: Tue, 2 Jan 2018 17:06:28 -0500 Cc: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= , "" Content-Transfer-Encoding: quoted-printable Message-Id: <0C149C8D-6B81-4DB0-A359-AFC2373189E9@fugue.com> References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 22:06:34 -0000 We had a conversation about this at a Boston IETF meetup last year; the = consensus, with which I agree, is that simply adding TLS alerts isn't = good enough, for (essentially) the reason you stated earlier: we have no = way to know that the attacker here is a good guy. E.g., in the case of = the OpenDNS behavior being described here, we don't know if OpenDNS is = protecting us or attacking us. A solution to this problem would require that there be a way for the = MITM to signal that in this particular case, the connection is being = blocked, and to sign that assertion with a cert that the application is = configured to trust. This establishes a trust relationship with the = protecting party (the operator of the OpenDNS server) that the user can = agree to or refuse to agree to, and if the UI is done well, the user can = be reminded that this intercept is the result of them agreeing = previously to such intercepts. This avoids presenting the user with something to click through, but = also provides a way to attribute the intercept to a specific, authorized = entity, so that if that entity decides to censor something I didn't = agree to have censored, there's a way for the service provider to help = me to understand why I can't access their service. I'm responding in detail here because I want to make it clear that I am = no longer a proponent of the original proposal, not because I'm = specifically advocating what I describe above. Another way to deal = with this problem is to simply not provide the "bad cert" popup in the = first place=E2=80=94that's a very bad UI design, and I've noticed that = modern browsers are starting to abandon it (yay). From nobody Tue Jan 2 14:29:42 2018 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 A3C8212D82D for ; Tue, 2 Jan 2018 14:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 P-qgOgkgVd_P for ; Tue, 2 Jan 2018 14:29:39 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45571270AB for ; Tue, 2 Jan 2018 14:29:39 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 66A2E33D21B; Tue, 2 Jan 2018 22:29:39 +0000 (UTC) Sender: geoffk@localhost.localdomain To: =?utf-8?b?TWF0ZXVzeiBKb8WEY3p5aw==?= , tls@ietf.org References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> From: Geoffrey Keating Date: 02 Jan 2018 14:29:39 -0800 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 22:29:41 -0000 Two problems with this proposal, that don't occur with the proposal the capport WG is working on, are: - What do you do if you get one of these alerts over multipath TCP? - What happens if some site far away on the Internet sends you one of these alerts? Perhaps because DNS was forged and hasn't timed out yet? From nobody Tue Jan 2 20:05:16 2018 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 32C631270A3 for ; Tue, 2 Jan 2018 20:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 mXoN9ZkGP8r1 for ; Tue, 2 Jan 2018 20:05:13 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 879C81200FC for ; Tue, 2 Jan 2018 20:05:13 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id r78so501413wme.5 for ; Tue, 02 Jan 2018 20:05:13 -0800 (PST) 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=+BIQ0H1f4xokkaV1WIaz/5yAgDNq3zS1Gvf7NhDElFE=; b=h16l6TKMvVjqABSZHKeWnMwU9MkZDscLcBLllJIafq4vi0PryTMu9qGH7x6XT0eJcv ARjandJF/7aIy2EvB4lajtRwTdqswq+QZKzhty5rlOikn2UY8x0e/3IRFt1ITrHSp/xi IqRNhYysE3Vx6y0wgqcHxouxh9QVE+IJwG/hSOdHKQ2vUUs9wsXFrhGGj9eoO1V1YO9Z ZkwT86366YfAxaysiWuoffHVRBCrWCBKaVZmNvHD4QyrKmAWPQKWu9R2MKwqq3vDqal6 JBHAqLTHzLO3EWR8YAH5dNMljlirK1duksVPX/w6QOOaSkzrgjz2r86IH3kH2/gBGOhC 5+cA== 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=+BIQ0H1f4xokkaV1WIaz/5yAgDNq3zS1Gvf7NhDElFE=; b=MJuOKmLj+is5AqiBDfR3nDcZarmgmqLtJvG+/IbIGKCqGZ1u3+irqbRT/3Fyx8cWfY o1oFnpd89tv1shK3OAcwa/QZgEUuF2TNFoNfdoDEOP3qWuKqJObVW+QaW0c4lTx0xf9c b/xuZEMV+Id6LvkLxCkB4JAcreqvS6rHTXtuW0WoPTmVZpTMSh1cGSif0Mmnnu0jk0aH GvEJaIh/CaQwBKfSi1y+0hdlPYIgdEjFW/3AefI1danin+GSpS0+LIG0+OG2WaLPxU58 1umEKIYwXE/8/uwg7RVqaWwDD7xxQyaBLf4VtVEs6hFBpRuNmTb6pBisEb2dbaDIyd+R 965w== X-Gm-Message-State: AKGB3mIIwn/cNUyWc+BvB60B6yujv9UtV9EmyOgOGg+EiCTg0ksHA1jp VVvNRkzeSDAArmy9duo0w0a+vZ1qk1xlQQxAndU= X-Google-Smtp-Source: ACJfBovsxN3seSzfV6I/HPEXqmP9/jcGgdLLt4/fMuleZauaqwn23IcjJMEBONGZK50tarXtZyooBvgVAEEoJR32E54= X-Received: by 10.80.177.250 with SMTP id n55mr794316edd.30.1514952311858; Tue, 02 Jan 2018 20:05:11 -0800 (PST) MIME-Version: 1.0 References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl> In-Reply-To: From: Lanlan Pan Date: Wed, 03 Jan 2018 04:05:01 +0000 Message-ID: To: Eric Rescorla Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , "" Content-Type: multipart/alternative; boundary="f403045c4308666bb50561d752d3" Archived-At: Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 04:05:15 -0000 --f403045c4308666bb50561d752d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eric Rescorla =E4=BA=8E2018=E5=B9=B41=E6=9C=883=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8A=E5=8D=885:57=E5=86=99=E9=81=93=EF=BC=9A > On Tue, Jan 2, 2018 at 1:40 PM, Mateusz Jo=C5=84czyk = wrote: > >> CCing Ted Lemon as the author of previous >> proposition. >> >> W dniu 02.01.2018 o 21:20, Eric Rescorla pisze: >> > On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk > > > wrote: >> > >> > Then the browser should display a message inside the warning scree= n >> that the >> > string cannot be trusted. >> > >> > Users tend to ignore that kind of warning. >> Not any more then they ignore certificate warnings [2]. > > > That's not clear. We would be providing some sort of attacker-controlled > text to the user with a warning that says "you can't trust this". That's > difficult to pull off. > > Moreover, the certificate warnings are under control of the browser, but > we actively work to discourage the user from ignoring them. Moreover, for > HSTS sites, the browser doesn't allow the user to override them, so > providing some attacker-controlled information would make the situation > materially worse. And given that a lot of the sites which people are like= ly > to hit with captive portals are in fact HSTS sites (because HSTS is commo= n > in big sites) instead showing attacker controlled information would make > things materially worse. > providing some attacker-controlled information would make the situation materially worse. +1 Although some browsers support HSTS, but also offer a "user friendly" configure item to ignore all ssl warnings. > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c4308666bb50561d752d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eric R= escorla <ekr@rtfm.com>=E4=BA=8E20= 18=E5=B9=B41=E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D=885:57=E5= =86=99=E9=81=93=EF=BC=9A
On Tue, Jan = 2, 2018 at 1:40 PM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl>= wrote:
CCing Ted Lemon <mellon at fugue.com> as the author of previous proposition.

W dniu 02.01.2018 o 21:20, Eric Rescorla pisze:
> On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Then the browser should display a message inside th= e warning screen that the
>=C2=A0 =C2=A0 =C2=A0string cannot be trusted.
>
> Users tend to ignore that kind of warning.
Not any more then they ignore certificate warnings [2].
=

That's not clear. We would be providi= ng some sort of attacker-controlled text to the user with a warning that sa= ys "you can't trust this". That's difficult to pull off.<= /div>

Moreover, the certificate warnings are under contr= ol of the browser, but we actively work to discourage the user from ignorin= g them. Moreover, for HSTS sites, the browser doesn't allow the user to= override them, so providing some attacker-controlled information would mak= e the situation materially worse. And given that a lot of the sites which p= eople are likely to hit with captive portals are in fact HSTS sites (becaus= e HSTS is common in big sites) instead showing attacker controlled informat= ion would make things materially worse.

providing some attacker-controlled information would m= ake the situation materially worse.=C2=A0 +1

Altho= ugh some browsers support HSTS, but also offer a "user friendly" = configure item to ignore all ssl warnings.


-Ekr


<= /div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--
= =E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2= =A0 Pan Lanlan
--f403045c4308666bb50561d752d3-- From nobody Wed Jan 3 03:45:26 2018 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 0CCBB126CD6 for ; Wed, 3 Jan 2018 03:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BxmFoIv_mRXI for ; Wed, 3 Jan 2018 03:45:23 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D099126579 for ; Wed, 3 Jan 2018 03:45:23 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A79CE13AAB; Wed, 3 Jan 2018 11:45:22 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B49C60177; Wed, 3 Jan 2018 11:45:22 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 03 Jan 2018 12:45:14 +0100 Message-ID: <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2083121.HPee8E1sgr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 03 Jan 2018 11:45:22 +0000 (UTC) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 11:45:25 -0000 --nextPart2083121.HPee8E1sgr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 14 December 2017 23:20:54 CET Colm MacC=C3=A1rthaigh wrote: > Based on our experiences with all of this over the last few weeks, I'd li= ke > to summarize and throw out a few suggestions for making TLS stacks more > defensive and robust against problems of this class. One or two may be ev= en > worth considering as small additions to the forthcoming TLS RFC, and I'd > love to get feedback on that. >=20 > *Second: hide all alerts in suspicious error cases* > Next, when the handshake does fail, we do two non-standard things. The > first is that we don't return an alert message, we just close the > connection.=20 >=20 > *Third: mask timing side-channels with a massive delay* > The second non-standard thing we do is that in all error cases, s2n behav= es > as if something suspicious is going on and in case timing is involved, we > add a random delay. It's well known that random delays are only partially > effective against timing attacks, but we add a very very big one. We wait= a > random amount of time between a minimum of 10 seconds, and a maximum of 30 > seconds. Note that both of those things only _possibly_ frustrate attackers while th= ey=20 definitely frustrate researchers trying to characterise your implementation= as=20 vulnerable or not. In effect making it seem secure while in reality it may = not=20 be. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2083121.HPee8E1sgr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpMwkoACgkQkqjRuAHS 9fWfmg//RFHGp9s7Owt+WcgWD8bW1ZE3cv25bZ4FDc4ybvZyhTRyimzsBeMPSPNx xPuk3KcPy8CtmKJu2uYPK8OrSeFQer6n4X7ndQ5GrGy0mCX9uaU0z4UDxERmxxCX vsIC0QmLWO5KqywFAXYvrJxICQLKN7wxL07cNr2TlEB6QigotLBUXIp7nr4Jt1T4 Vi/w3H0oejcuioLLGUzUUHy8Q6UoyxERpy/68lYcozgBO7uoQW1XuJT+8Eqotyof 605A5mUBm2MLP6aYcIVlODme8LCOHYamtcnypUkvNptLh4zBGlnAQ21waNreKRa0 iIdilvX1oL0e29IUrqLr52VSjbJJymgSFoXF/Ib3aH7BUWQ19wi8jXE48VaVbMRw F6sTvetW5Id2Pves0rS4XbZiEQnXi0QmtbljXn9uyUoPvyuZC7zRz3uFfGwRJoBB uNr6Nt+ei8tnx3fp9TrXan2pS0bAdHMAy0n29IUC3CZIFZxXungHEhXv38teyqgs YDejs/U+IqNJhQ0ZoF3wAUY6vcV6kvH38Pbk1x3IGLlcjUQQjDWc4Ut5qyfYJige yZFDF3JU+Yc+3LvrK52FnA93JnnQeU7l64g4R3KfX6faWBHb6DkDARBSxX7tTBX3 hyoNRXtk5qD648tUEoxnH94CKVgpDE8Nufu288tdYe5qwAhZ0SU= =pNk7 -----END PGP SIGNATURE----- --nextPart2083121.HPee8E1sgr-- From nobody Wed Jan 3 03:51:59 2018 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 BB964126C19 for ; Wed, 3 Jan 2018 03:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4zuhQA_Ua_ag for ; Wed, 3 Jan 2018 03:51:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20571126579 for ; Wed, 3 Jan 2018 03:51:56 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B43BD80473; Wed, 3 Jan 2018 11:51:55 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 262D662464; Wed, 3 Jan 2018 11:51:55 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 03 Jan 2018 12:51:53 +0100 Message-ID: <2027630.VgSAhlQKlv@pintsize.usersys.redhat.com> In-Reply-To: References: <20171215174628.GA17601@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5434996.xpMQ27Dy48"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 03 Jan 2018 11:51:55 +0000 (UTC) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 11:51:58 -0000 --nextPart5434996.xpMQ27Dy48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 15 December 2017 19:07:16 CET Eric Rescorla wrote: > I'm not quite following how this helps. It's true that if SHA-256 is > broken, we're in serious trouble, but that's largely because of the fact > that that's what people's certificates have, so clients really can't refu= se > to support SHA-256 certificates. So, how does adding new algorithms help? > (That's why I would argue that the existing SHA-384 support doesn't help). >=20 we are in the process of standardising Ed25519 for X.509 and TLS which does= n't=20 use SHA-256 or SHA-384, so the fact that TLS will still use SHA-256 PRF wit= h=20 such certificates is a liability. > On Fri, Dec 15, 2017 at 9:46 AM, Ilari Liusvaara >=20 > wrote: > > On Fri, Dec 15, 2017 at 02:57:33PM +0000, Andrei Popov wrote: > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara > > >=20 > > > > Even nastier dependency: SHA-2. If that breaks, currently both TLS > > > > 1.2 and 1.3 break. There are no alternatives defined. > > >=20 > > > Here's an attempt to define a SHA-2 alternative: > > https://tools.ietf.org/html/draft-wconner-blake2sigs-01 > >=20 > > Also would need TLS ciphersuite codepoints with alternative handshake > > hash algorithms. > >=20 > >=20 > > -Ilari > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart5434996.xpMQ27Dy48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpMw9kACgkQkqjRuAHS 9fWedRAAg8kD7bCGZhoYQptRsfJyA1OkXDlIDsNkwMJWbzNSPdSUjxpPFRiaEHoD 2J3NysBseLORl1LhTrmwusyKPGrPhb5MvYHUg0K0oYtaP/fDQM+lB3N1YQUxOUf+ UKSpv0zukC5ATOQUOpvPcKiGC4dE9YMoNkLXnuSS0+uRKJhc3yDYwq8Od1qxSJTj OmY/G/EZsGI/otnG5+lSTXwyvrm/EV04ZUMFAQGwsLS49bw7+L4oVqS3o0FxNfjE JSVBhvV01/bd0VeqlB2bqFt4AYvjxs4ACOSUZW+EqL2fPRrN9N5zucfA0FuXTVNX Rpo7PpJRNTS/j1UQBljSiFKooBvnicYZQKVEj5kVviFZ1ovBDNbQjTQoOKBceYVh r7xluNzxwpAapXD7IdIzkMCaCZhaYLUnViHsyALEWb75zWwwkOSfREAImcPUb44A KkYrXRAInhrkh2CqjjCe6b8JveUaUS2wpZdOqJYzx1H+Bu6gEM62c8OyuSqLxV0z DvSrxNQ/3fNr/skfEPboW1lH6WwxTatONeCr1hwdqnUapC+RhJSknD4qrhUC8Ucg JH1WkPV1euCwACE5lUgvI07qI80ewqyqrYZZQAqOvNo2bwgK/YEacQtt8Z17FIG8 7r7OY5XUVWx/O/33aadNQwEGjDFql4nN6OtMaUCUl2clurg14eQ= =/Rlx -----END PGP SIGNATURE----- --nextPart5434996.xpMQ27Dy48-- From nobody Wed Jan 3 04:48:45 2018 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 38EB2127023 for ; Wed, 3 Jan 2018 04:48:43 -0800 (PST) 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, FREEMAIL_FROM=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 68ssXbaWFufd for ; Wed, 3 Jan 2018 04:48:41 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 A7420126579 for ; Wed, 3 Jan 2018 04:48:40 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 19765 invoked from network); 3 Jan 2018 13:48:38 +0100 Received: from ceh60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.30.183.60]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 3 Jan 2018 13:48:38 +0100 To: tls@ietf.org From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> Date: Wed, 3 Jan 2018 13:48:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 1a286d6b68bd08d39a3ac81a9461433c X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [cbPE] Archived-At: Subject: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 12:48:43 -0000 Hello, Based on Your feedback (for which I am grateful) I have designed a new version of the access_administratively_disabled mechanism. 1. One new AlertDescription value should be specified: access_administratively_disabled. 2. The information why the webpage is blocked is specified at the URL https://access_administratively_disabled.net?d=${domain_name} as a simple string. 3. Certificates for access_administratively_disabled.net are assigned in a non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a certificate for access_administratively_disabled.net provided that their identity is validated (i.e. in an Extended-Validation way). The list of entities that received certificates for this domain would be made public and managed by IANA. This way the risk of phishing would be eliminated. 4. Any entity that is blocking some websites would redirect traffic for access_administratively_disabled.net to their own servers. 5. After getting an access_administratively_disabled warning a browser would open https://access_admininistratively_disabled.net?d=${domain_name} , validate its certificate and display to the user information: what get blocked, by whom and why. 6. If https://access_administratively_disabled.net would not have a valid certificate, the browser would only display that the website is being blocked, without giving any reason. 7. IANA or someone else would provide a default https://access_administratively_disabled.net service for the public internet. This mechanism would provide blocking transparency without affecting security. Greetings, Mateusz Jończyk From nobody Wed Jan 3 05:19:47 2018 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 441FB127023 for ; Wed, 3 Jan 2018 05:19:46 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dQpRwaYmHVTf for ; Wed, 3 Jan 2018 05:19:44 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 EBDEC1201F8 for ; Wed, 3 Jan 2018 05:19:43 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id w1so558601ybe.10 for ; Wed, 03 Jan 2018 05:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aSc7klvTAG1OaynTxFGl17XED6RUv5dJ0k4v3d2aaNs=; b=M5ftXRsL/LgfdbjI4pBrFWc4IlenxfIql3EfkCUZaYifsxUvbY0ZGe6XF4SXj8z15U qXB8zH9Y1l+CCJhu43y64IhstdUuMMXKwdPU+1uL06WdjlrFMe3HCT7vdnYO2susoe7y CL4AYvrfIXEup2JSA3j2fnrf7Krrm5Iwmk+rZ1HYRW5RniYgjVR0Oj8i+T2FgzOXVb0y l5GPebzTvrTbtuN9T0dHmRekxZXCgAD0R3IBxBmbAcKl+sLoAkpMC1zl+NM/3Ji8Gc8H m/AGFLj2VADZDo0K8iyUhCXuuPCKUqe2AH/w5+Hj5/Lp9BMX8y7wajAhPXhyPwlK9gXj tR6g== 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:references:from:date :message-id:subject:to:cc; bh=aSc7klvTAG1OaynTxFGl17XED6RUv5dJ0k4v3d2aaNs=; b=rTtJ/e+rl9TdvraABRh7mbJiR++vowZUqU9i6XFA5EjPUeZOETztY+p/qSgiUyM/dm eLTggl8Iq52rWDunQwlaTKrKMc7fGjVmRBb37HfD0T6+mV4bnm0ZyTYgRXCzvoLlDLO/ l2LZIcCoVp9Kj4ck/RBXlDDSG0C7SV6svVVcTHGAqqXyal1aovySlQMHU349wWpO5UgU /NVhUVKFdc36RXilWsGnyPBWiD86npzGFPSNyhT8ZU47MjvWPb1mDIQYMPeN1cIa8MDg vmq3bwdCI/cwo/2/wjZgBA8byknZ8l34xt0tLh9LcjQRIot1s8wyYMAAEzTv5EMGJ7LJ MhLw== X-Gm-Message-State: AKGB3mIiqTrCWAjn2VPDs1ORRefQ88+ySY1jDJfiUmprLaM7fhINaCMD uC5NUEF/+C3sT1P/a+pEHI8wK6y6s13EIcqbDHWzXg== X-Google-Smtp-Source: ACJfBosbkS52kHjWUfo4ZqhtnA1QzzXPkCV5pdTUEM86oLKT8j1IcsmISzAQkha82nBRT9uht5Bh4uYwZSGEaomqr6o= X-Received: by 10.37.134.137 with SMTP id z9mr1287728ybk.497.1514985583112; Wed, 03 Jan 2018 05:19:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 05:19:02 -0800 (PST) In-Reply-To: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> From: Eric Rescorla Date: Wed, 3 Jan 2018 05:19:02 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "" , Martin Thomson , abbypan@gmail.com, Ted Lemon , JW , Stephen Farrell Content-Type: multipart/alternative; boundary="089e082608f08587d40561df1116" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 13:19:46 -0000 --089e082608f08587d40561df1116 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have several comments: - This is almost entirely out of scope for TLS, so you should start with CAPPORT. If they're interested, then we can discuss the code point assignment in TLS. - You point #2 would effectively require either changes to the browser or CA issuance policies (the BRs would prohibit issuing to an entity under these conditions). I'm not sure that browser manufacturers would be excited about either set of changes. Resolving this seems like a threshold question for this proposal. It seems like there are going to be rather a large number of such entities (every Firewall in the world?) so it may not be practical. -Ekr -Ekr On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5=84czyk wr= ote: > Hello, > Based on Your feedback (for which I am grateful) I have designed a new > version > of the access_administratively_disabled mechanism. > > 1. One new AlertDescription value should be specified: > access_administratively_disabled. > > 2. The information why the webpage is blocked is specified at the URL > https://access_administratively_disabled.net?d=3D${domain_name} as a simp= le > string. > > 3. Certificates for access_administratively_disabled.net are assigned in = a > non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get= a > certificate for access_administratively_disabled.net provided that their > identity is validated (i.e. in an Extended-Validation way). The list of > entities > that received certificates for this domain would be made public and > managed by > IANA. This way the risk of phishing would be eliminated. > > 4. Any entity that is blocking some websites would redirect traffic for > access_administratively_disabled.net to their own servers. > > 5. After getting an access_administratively_disabled warning a browser > would > open https://access_admininistratively_disabled.net?d=3D${domain_name} , > validate > its certificate and display to the user information: what get blocked, by > whom > and why. > > 6. If https://access_administratively_disabled.net would not have a valid > certificate, the browser would only display that the website is being > blocked, > without giving any reason. > > 7. IANA or someone else would provide a default > https://access_administratively_disabled.net service for the public > internet. > > This mechanism would provide blocking transparency without affecting > security. > > Greetings, > Mateusz Jo=C5=84czyk > --089e082608f08587d40561df1116 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have several comments:

- This is almo= st entirely out of scope for TLS, so you should start with CAPPORT. If they= 're interested, then we can discuss the code point assignment in TLS.

- You point #2 would effectively require either cha= nges to the browser or CA issuance policies (the BRs would prohibit issuing= to an entity under these conditions). I'm not sure that browser manufa= cturers would be excited about either set of changes. Resolving this seems = like a threshold question for this proposal. It seems like there are going = to be rather a large number of such entities (every Firewall in the world?)= so it may not be practical.

-Ekr




-E= kr



=
On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5=84= czyk <mat.jonczyk@o2.pl> wrote:
Hello,
Based on Your feedback (for which I am grateful) I have designed a new vers= ion
of the access_administratively_disabled mechanism.

1. One new AlertDescription value should be specified:
access_administratively_disabled.

2. The information why the webpage is blocked is specified at the URL
https://access_administratively_= disabled.net?d=3D${domain_name} as a simple string.

3. Certificates for access_administratively_disabled= .net are assigned in a
non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a=
certificate for access_administratively_disabled.net= provided that their
identity is validated (i.e. in an Extended-Validation way). The list of ent= ities
that received certificates for this domain would be made public and managed= by
IANA. This way the risk of phishing would be eliminated.

4. Any entity that is blocking some websites would redirect traffic for
access_administratively_disabled.net to their ow= n servers.

5. After getting an access_administratively_disabled warning a browser= would
open https://access_admininist= ratively_disabled.net?d=3D${domain_name} , validate
its certificate and display to the user information: what get blocked, by w= hom
and why.

6. If https://access_administratively_disabled.net<= /a> would not have a valid
certificate, the browser would only display that the website is being block= ed,
without giving any reason.

7. IANA or someone else would provide a default
https://access_administratively_disabled.net se= rvice for the public internet.

This mechanism would provide blocking transparency without affecting securi= ty.

Greetings,
Mateusz Jo=C5=84czyk

--089e082608f08587d40561df1116-- From nobody Wed Jan 3 05:57:30 2018 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 9BF1E1201F8; Wed, 3 Jan 2018 05:57:28 -0800 (PST) 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: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151498784861.30913.14397405953795919592@ietfa.amsl.com> Date: Wed, 03 Jan 2018 05:57:28 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 13:57:28 -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 : IANA Registry Updates for TLS and DTLS Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-03.txt Pages : 16 Date : 2018-01-03 Abstract: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03 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 Jan 3 06:45:18 2018 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 5589B126B7F for ; Wed, 3 Jan 2018 06:45:16 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 mOLdsFbBUjVe for ; Wed, 3 Jan 2018 06:45:14 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 325DF1205D3 for ; Wed, 3 Jan 2018 06:45:14 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 31499 invoked from network); 3 Jan 2018 15:45:11 +0100 Received: from agsa196.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.78.196]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 3 Jan 2018 15:45:11 +0100 To: Eric Rescorla References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> Cc: "" , Martin Thomson , abbypan@gmail.com, Ted Lemon , JW , Stephen Farrell From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <3685a850-03ec-5162-414b-c2676022d661@o2.pl> Date: Wed, 3 Jan 2018 15:45:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 690e656efd6b635687d9134f7f052f7d X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [wTO0] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 14:45:16 -0000 W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > I have several comments: > > - This is almost entirely out of scope for TLS, so you should start with > CAPPORT. If they're interested, then we can discuss the code point assignment in > TLS. > > - You point #2 would effectively require either changes to the browser or CA > issuance policies (the BRs would prohibit issuing to an entity under these > conditions). I'm not sure that browser manufacturers would be excited about > either set of changes. Resolving this seems like a threshold question for this > proposal. It could be possible for providers to obtain certifiates for subdomains such as opendns.access_administratively_disabled.net. Then the server reachable at access_administratively_disabled.net would provide a certificate for opendns.access_administratively_disabled.net, which would be incorrect but browsers would in this special case trust it. > It seems like there are going to be rather a large number of such > entities (every Firewall in the world?) so it may not be practical. Firewall and blocking list providers would deploy their own access_administratively_disabled.net servers. For example, Microsoft is providing their own filtering solution (which is called Microsoft Forefront Threat Management Gateway) [1] and it could deploy one access_administratively_disabled.net server globally. [1] http://msdn.microsoft.com/en-us/library/ff827462(v=vs.85).aspx Greetings, Mateusz Jończyk > > > > > -Ekr > > > > On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jończyk > wrote: > > Hello, > Based on Your feedback (for which I am grateful) I have designed a new version > of the access_administratively_disabled mechanism. > > 1. One new AlertDescription value should be specified: > access_administratively_disabled. > > 2. The information why the webpage is blocked is specified at the URL > https://access_administratively_disabled.net?d=${domain_name} > as a simple > string. > > 3. Certificates for access_administratively_disabled.net > are assigned in a > non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a > certificate for access_administratively_disabled.net > provided that their > identity is validated (i.e. in an Extended-Validation way). The list of entities > that received certificates for this domain would be made public and managed by > IANA. This way the risk of phishing would be eliminated. > > 4. Any entity that is blocking some websites would redirect traffic for > access_administratively_disabled.net > to their own servers. > > 5. After getting an access_administratively_disabled warning a browser would > open https://access_admininistratively_disabled.net?d=${domain_name} > , validate > its certificate and display to the user information: what get blocked, by whom > and why. > > 6. If https://access_administratively_disabled.net > would not have a valid > certificate, the browser would only display that the website is being blocked, > without giving any reason. > > 7. IANA or someone else would provide a default > https://access_administratively_disabled.net > service for the public internet. > > This mechanism would provide blocking transparency without affecting security. > > Greetings, > Mateusz Jończyk > > From nobody Wed Jan 3 07:29:30 2018 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 2A3CB127241 for ; Wed, 3 Jan 2018 07:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vCO_w6WxeDBa for ; Wed, 3 Jan 2018 07:29:27 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 BFE4B1205D3 for ; Wed, 3 Jan 2018 07:29:26 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v190so664781ywg.4 for ; Wed, 03 Jan 2018 07:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Nr9LYS6430zKvXhzcg6Ag/lDeT4OeuCww0AcpAsrFQ=; b=q0cIvSi76uZmlIhuMMvdWcKe/ipC1QnXkN5/2h4RICtgCqA4U94plaXZbOv4Ru8CNe VRtP53kwTZzgBlQhtSoT4sL52FKfLWTDMhUJ5SzE08am8gbf0TrEKi/YMd5jqJwKa3Dn FpKt7qq7fHsDVNcE8cvf2APKTubjg9rZwFBEy1c35EubmsNsplKa69jc9B8+fi2g9fUV fEp/BrDsZXNuVfT4LAjIaxZBfsH9oEoaaDiYIcci/+FJy7lZK+1lQG4yEyCb0MEecTUZ QWNMjji2wMNedy3iS1DTDXjzgObwdZoHS8N18pQbwWz3/v1bvczEg4g2lPJo4BUDBi9l dY4A== 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:references:from:date :message-id:subject:to:cc; bh=7Nr9LYS6430zKvXhzcg6Ag/lDeT4OeuCww0AcpAsrFQ=; b=kZ2Fj//aMt6aGLSOJidNebavyqippVqslbMddmLTLtYhIOYBEZX5lbja8DN23ccXFr hAAP5tCIp9gabW/7Ldww9V0Y/LIzuwg3fqJTsBemrj/BNoZsZtTuQKMPW7jH+RfreXua vQ4TEKxCIQzJl9EdzYVA2R8AFmAJQBQ6QvQ9sq1vG/ntfSB2NZqTGWzo91skfsaKJyg8 1xENtZORyemWPlp1WXw68vjx76Su+a2K3TKwgOF/IlMqLEA9igFBkHyXvnWIpwFnFllq zG8YPn5wFPF00NAyp9a9wdz8hO7Xx/yPoI8dzICk4XboqMft4rxIthj5CxegqQj0U9eJ NvDg== X-Gm-Message-State: AKGB3mJA4yy+gyaLyg5jIw/xp09VnXF7i1sl/GXfQYE1gi6LpBtq6XRV QwfiOmqWJkvtLW+6qsrnIzH9j9yz4ij5hhROI7nE0g== X-Google-Smtp-Source: ACJfBovf6L+vL6zW3MNo2UCNdqzwR12scB4a/lUGD8tGmgbD34mO2MGHj6ruJGbYKNii4fZnl1Vwu8061wsU8NNXF4c= X-Received: by 10.129.154.22 with SMTP id r22mr1605384ywg.296.1514993365864; Wed, 03 Jan 2018 07:29:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 07:28:45 -0800 (PST) In-Reply-To: <3685a850-03ec-5162-414b-c2676022d661@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> From: Eric Rescorla Date: Wed, 3 Jan 2018 07:28:45 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "" , Martin Thomson , abbypan@gmail.com, Ted Lemon , JW , Stephen Farrell Content-Type: multipart/alternative; boundary="94eb2c0bb4e868eabb0561e0e1b0" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 15:29:29 -0000 --94eb2c0bb4e868eabb0561e0e1b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so you should start wit= h > > CAPPORT. If they're interested, then we can discuss the code point > assignment in > > TLS. > > > > - You point #2 would effectively require either changes to the browser > or CA > > issuance policies (the BRs would prohibit issuing to an entity under > these > > conditions). I'm not sure that browser manufacturers would be excited > about > > either set of changes. Resolving this seems like a threshold question > for this > > proposal. > > It could be possible for providers to obtain certifiates for subdomains > such as > opendns.access_administratively_disabled.net. Then the server reachable a= t > access_administratively_disabled.net would provide a certificate for > opendns.access_administratively_disabled.net, which would be incorrect bu= t > browsers would in this special case trust it. > Well, this seems like the first arm, in which you change the browser, so the question then becomes whether the browsers wish to do so. Are you aware of any browser vendor which is interested? > It seems like there are going to be rather a large number of such > > entities (every Firewall in the world?) so it may not be practical. > > Firewall and blocking list providers would deploy their own > access_administratively_disabled.net servers. For example, Microsoft is > providing their own filtering solution (which is called Microsoft Forefro= nt > Threat Management Gateway) [1] and it could deploy one > access_administratively_disabled.net server globally. > And how would this work if the firewall admin wants to add their own list of sites to be blocked? -Ekr > > [1] http://msdn.microsoft.com/en-us/library/ff827462(v=3Dvs.85).aspx > > Greetings, > Mateusz Jo=C5=84czyk > > > > > > > > > > > -Ekr > > > > > > > > On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5=84czyk > > wrote: > > > > Hello, > > Based on Your feedback (for which I am grateful) I have designed a > new version > > of the access_administratively_disabled mechanism. > > > > 1. One new AlertDescription value should be specified: > > access_administratively_disabled. > > > > 2. The information why the webpage is blocked is specified at the U= RL > > https://access_administratively_disabled.net?d=3D${domain_name} > > a= s > a simple > > string. > > > > 3. Certificates for access_administratively_disabled.net > > are assigned in a > > non-usual way: any big entity that blocks websites (e.g. OpenDNS) > may get a > > certificate for access_administratively_disabled.net > > provided that their > > identity is validated (i.e. in an Extended-Validation way). The lis= t > of entities > > that received certificates for this domain would be made public and > managed by > > IANA. This way the risk of phishing would be eliminated. > > > > 4. Any entity that is blocking some websites would redirect traffic > for > > access_administratively_disabled.net > > to their own servers. > > > > 5. After getting an access_administratively_disabled warning a > browser would > > open https://access_admininistratively_disabled.net?d=3D${domain_na= me} > > = , > validate > > its certificate and display to the user information: what get > blocked, by whom > > and why. > > > > 6. If https://access_administratively_disabled.net > > would not have a > valid > > certificate, the browser would only display that the website is > being blocked, > > without giving any reason. > > > > 7. IANA or someone else would provide a default > > https://access_administratively_disabled.net > > service for the > public internet. > > > > This mechanism would provide blocking transparency without affectin= g > security. > > > > Greetings, > > Mateusz Jo=C5=84czyk > > > > > > --94eb2c0bb4e868eabb0561e0e1b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
W dniu 03.01.2018= o 14:19, Eric Rescorla pisze:
> I have several comments:
>
> - This is almost entirely out of scope for TLS, so you should start wi= th
> CAPPORT. If they're interested, then we can discuss the code point= assignment in
> TLS.
>
> - You point #2 would effectively require either changes to the browser= or CA
> issuance policies (the BRs would prohibit issuing to an entity under t= hese
> conditions). I'm not sure that browser manufacturers would be exci= ted about
> either set of changes. Resolving this seems like a threshold question = for this
> proposal.

It could be possible for providers to obtain certifiates for subdoma= ins such as
opendns.access_administratively_disabled.net= . Then the server reachable at
access_administratively_disabled.net would provi= de a certificate for
opendns.access_administratively_disabled.net= , which would be incorrect but
browsers would in this special case trust it.

Well, this seems like the first arm, in which you change the browser= , so the question
then becomes whether the browsers wish to do so= . Are you aware of any
browser vendor which is interested?
<= div>

> It seems like there are going to be rather a large number of such
> entities (every Firewall in the world?) so it may not be practical.
Firewall and blocking list providers would deploy their own
access_administratively_disabled.net servers. Fo= r example, Microsoft is
providing their own filtering solution (which is called Microsoft Forefront=
Threat Management Gateway) [1] and it could deploy one
access_administratively_disabled.net server glob= ally.

And how would this work if the fi= rewall admin wants to add their own list
of sites to be blocked?<= /div>

-Ekr
=C2=A0

[1] http://msdn.microsoft.com/en-us/library/ff827462(v=3Dvs.85).aspx

Greetings,
Mateusz Jo=C5=84czyk

>
>
>
>
> -Ekr
>
>
>
> On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hello,
>=C2=A0 =C2=A0 =C2=A0Based on Your feedback (for which I am grateful) I = have designed a new version
>=C2=A0 =C2=A0 =C2=A0of the access_administratively_disabled mechan= ism.
>
>=C2=A0 =C2=A0 =C2=A01. One new AlertDescription value should be specifi= ed:
>=C2=A0 =C2=A0 =C2=A0access_administratively_disabled.
>
>=C2=A0 =C2=A0 =C2=A02. The information why the webpage is blocked is sp= ecified at the URL
>=C2=A0 =C2=A0 =C2=A0https://acces= s_administratively_disabled.net?d=3D${domain_name}
>=C2=A0 =C2=A0 =C2=A0<https://a= ccess_administratively_disabled.net?d=3D${domain_name}> as= a simple
>=C2=A0 =C2=A0 =C2=A0string.
>
>=C2=A0 =C2=A0 =C2=A03. Certificates for access_admini= stratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_adm= inistratively_disabled.net> are assigned in a
>=C2=A0 =C2=A0 =C2=A0non-usual way: any big entity that= blocks websites (e.g. OpenDNS) may get a
>=C2=A0 =C2=A0 =C2=A0certificate for access_administra= tively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_adm= inistratively_disabled.net> provided that their
>=C2=A0 =C2=A0 =C2=A0identity is validated (i.e. in an = Extended-Validation way). The list of entities
>=C2=A0 =C2=A0 =C2=A0that received certificates for this domain would be= made public and managed by
>=C2=A0 =C2=A0 =C2=A0IANA. This way the risk of phishing would be elimin= ated.
>
>=C2=A0 =C2=A0 =C2=A04. Any entity that is blocking some websites would = redirect traffic for
>=C2=A0 =C2=A0 =C2=A0access_administratively_disa= bled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_adm= inistratively_disabled.net> to their own servers.
>
>=C2=A0 =C2=A0 =C2=A05. After getting an access_administratively_di= sabled warning a browser would
>=C2=A0 =C2=A0 =C2=A0open https:= //access_admininistratively_disabled.net?d=3D${domain_name} >=C2=A0 =C2=A0 =C2=A0<https:/= /access_admininistratively_disabled.net?d=3D${domain_name}>= ; , validate
>=C2=A0 =C2=A0 =C2=A0its certificate and display to the user information= : what get blocked, by whom
>=C2=A0 =C2=A0 =C2=A0and why.
>
>=C2=A0 =C2=A0 =C2=A06. If https://access_admini= stratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net> would not have a valid
>=C2=A0 =C2=A0 =C2=A0certificate, the browser would only display that th= e website is being blocked,
>=C2=A0 =C2=A0 =C2=A0without giving any reason.
>
>=C2=A0 =C2=A0 =C2=A07. IANA or someone else would provide a default
>=C2=A0 =C2=A0 =C2=A0https://access_administrati= vely_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net> service for the public internet.
>
>=C2=A0 =C2=A0 =C2=A0This mechanism would provide blocking transparency = without affecting security.
>
>=C2=A0 =C2=A0 =C2=A0Greetings,
>=C2=A0 =C2=A0 =C2=A0Mateusz Jo=C5=84czyk
>
>


--94eb2c0bb4e868eabb0561e0e1b0-- From nobody Wed Jan 3 08:08:05 2018 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 1A3D01275F4 for ; Wed, 3 Jan 2018 08:08:04 -0800 (PST) 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, 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 vbO_UFhCiwPq for ; Wed, 3 Jan 2018 08:08:02 -0800 (PST) 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 3BFF4126CD8 for ; Wed, 3 Jan 2018 08:08:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A3E8B3009FF for ; Wed, 3 Jan 2018 11:08:01 -0500 (EST) 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 NHgjh3UTbLq8 for ; Wed, 3 Jan 2018 11:08:00 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C6DAE300265; Wed, 3 Jan 2018 11:07:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> Date: Wed, 3 Jan 2018 11:08:03 -0500 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <8FDABBC5-98C2-4353-88B5-FB553C5DE387@vigilsec.com> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:08:04 -0000 Mateusz: How do you see IANA controlling which parties get certificates for the = access_administratively_disabled.net domain? Russ P.S. If I recall RFC 1034 and 1035 correctly, domain name labels may = contain only letters, digits, and hyphen. Underscore is not allowed. > On Jan 3, 2018, at 7:48 AM, Mateusz Jo=C5=84czyk = wrote: >=20 > Hello, > Based on Your feedback (for which I am grateful) I have designed a new = version > of the access_administratively_disabled mechanism. >=20 > 1. One new AlertDescription value should be specified: > access_administratively_disabled. >=20 > 2. The information why the webpage is blocked is specified at the URL > https://access_administratively_disabled.net?d=3D${domain_name} as a = simple string. >=20 > 3. Certificates for access_administratively_disabled.net are assigned = in a > non-usual way: any big entity that blocks websites (e.g. OpenDNS) may = get a > certificate for access_administratively_disabled.net provided that = their > identity is validated (i.e. in an Extended-Validation way). The list = of entities > that received certificates for this domain would be made public and = managed by > IANA. This way the risk of phishing would be eliminated. >=20 > 4. Any entity that is blocking some websites would redirect traffic = for > access_administratively_disabled.net to their own servers. > =09 > 5. After getting an access_administratively_disabled warning a browser = would > open https://access_admininistratively_disabled.net?d=3D${domain_name} = , validate > its certificate and display to the user information: what get blocked, = by whom > and why. >=20 > 6. If https://access_administratively_disabled.net would not have a = valid > certificate, the browser would only display that the website is being = blocked, > without giving any reason. >=20 > 7. IANA or someone else would provide a default > https://access_administratively_disabled.net service for the public = internet. >=20 > This mechanism would provide blocking transparency without affecting = security. >=20 > Greetings, > Mateusz Jo=C5=84czyk >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jan 3 08:17:34 2018 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 6DD0B124D68 for ; Wed, 3 Jan 2018 08:17:32 -0800 (PST) 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, FREEMAIL_FROM=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 nUJyrG_uQn2A for ; Wed, 3 Jan 2018 08:17:29 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 5C8391200B9 for ; Wed, 3 Jan 2018 08:17:29 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 18865 invoked from network); 3 Jan 2018 17:17:26 +0100 Received: from agsa196.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.78.196]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 3 Jan 2018 17:17:26 +0100 To: Eric Rescorla References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> Cc: "" , Martin Thomson , abbypan@gmail.com, Ted Lemon , JW , Stephen Farrell From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 3 Jan 2018 17:17:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: c0ac067198e60938e81b60b842198008 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [4RNE] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:17:32 -0000 W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > I have several comments: > > > > - This is almost entirely out of scope for TLS, so you should start with > > CAPPORT. If they're interested, then we can discuss the code point assignment in > > TLS. > > > > - You point #2 would effectively require either changes to the browser or CA > > issuance policies (the BRs would prohibit issuing to an entity under these > > conditions). I'm not sure that browser manufacturers would be excited about > > either set of changes. Resolving this seems like a threshold question for this > > proposal. > > It could be possible for providers to obtain certifiates for subdomains such as > opendns.access_administratively_disabled.net > . Then the server > reachable at > access_administratively_disabled.net > would provide a certificate for > opendns.access_administratively_disabled.net > , which would be > incorrect but > browsers would in this special case trust it. > > > Well, this seems like the first arm, in which you change the browser, so the > question > then becomes whether the browsers wish to do so. Are you aware of any > browser vendor which is interested? I'm not exactly sure what You understand by "the first arm". Of course it would have to be implemented in browsers, by me or somebody else. Microsoft may wish to deploy this in their Forefront TMG, so browser support in Internet Explorer / Edge would follow. Judging from TLS1.3's problems with middleboxes, content filtering isn't so rare, especially in the corporate world. The provider of filtering services (for example OpenDNS) / middlebox manufacturer would have to recognize if the client supports this mechanism. Having support for TLS1.3 could be one such flag. > > > > It seems like there are going to be rather a large number of such > > entities (every Firewall in the world?) so it may not be practical. > DNS already handles a large number of such entities and it somehow works and is practical. Having a subdomain of access_administratively_disabled.net registered would be expensive because a physical validation would have to be followed - it would probably be no less expensive than EV certificates currently are. > Firewall and blocking list providers would deploy their own > access_administratively_disabled.net > servers. For example, Microsoft is > providing their own filtering solution (which is called Microsoft Forefront > Threat Management Gateway) [1] and it could deploy one > access_administratively_disabled.net > server globally. > > > And how would this work if the firewall admin wants to add their own list > of sites to be blocked? > Then access_administratively_disabled.net would respond with a generic "site blocked by administrator". It could also modify response according to a source IP address, but this would not be necessary. OpenDNS currently does exactly this. It recognizes its users by incoming IP addresses. It even provides administrator contact data on the "access denied" page. Greetings, Mateusz Jończyk > -Ekr > > > > [1] http://msdn.microsoft.com/en-us/library/ff827462(v=vs.85).aspx > > > Greetings, > Mateusz Jończyk > > > > > > > > > > > -Ekr > > > > > > > > On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jończyk > > >> wrote: > > > > Hello, > > Based on Your feedback (for which I am grateful) I have designed a new version > > of the access_administratively_disabled mechanism. > > > > 1. One new AlertDescription value should be specified: > > access_administratively_disabled. > > > > 2. The information why the webpage is blocked is specified at the URL > > https://access_administratively_disabled.net?d=${domain_name} > > > > as a simple > > string. > > > > 3. Certificates for access_administratively_disabled.net > > > > are assigned in a > > non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a > > certificate for access_administratively_disabled.net > > > > provided that their > > identity is validated (i.e. in an Extended-Validation way). The list of entities > > that received certificates for this domain would be made public and managed by > > IANA. This way the risk of phishing would be eliminated. > > > > 4. Any entity that is blocking some websites would redirect traffic for > > access_administratively_disabled.net > > > > to their own servers. > > > > 5. After getting an access_administratively_disabled warning a browser > would > > open https://access_admininistratively_disabled.net?d=${domain_name} > > > > , validate > > its certificate and display to the user information: what get blocked, > by whom > > and why. > > > > 6. If https://access_administratively_disabled.net > > > > would not have a valid > > certificate, the browser would only display that the website is being > blocked, > > without giving any reason. > > > > 7. IANA or someone else would provide a default > > https://access_administratively_disabled.net > > > > service for the public internet. > > > > This mechanism would provide blocking transparency without affecting > security. > > > > Greetings, > > Mateusz Jończyk > > > > > > From nobody Wed Jan 3 08:31:57 2018 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 BF53C124D68 for ; Wed, 3 Jan 2018 08:31:53 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zMiSycG8xEFP for ; Wed, 3 Jan 2018 08:31:50 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 6311C120046 for ; Wed, 3 Jan 2018 08:31:50 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id q3so786620ybg.9 for ; Wed, 03 Jan 2018 08:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tDqCdHOC3YzEGt8ycc4v/3Knp5huOVZLN4qhbOMzKDo=; b=zb8Ca9AtzFifZ2rJAkbpb3Pk4pwekNCrJlaIYEVEQ8z6sCNwrWjGiSJldR8BpP609a VHsraYLCIwBUn+qQ1MVfctDnHMu1I9ogKkXmOu8uhRCJbhaRD9TszxCU6lPEoL1q/vCv E8SBAxH+9dLBJy/7BXRWkHCzH1MuBpYxtvBANRhsk0OI1WeopSXMDq9mlIGwSE52fOn4 898c2vsRD1YHk1ae+gEsFiA+xE/VzzxyPWEyJmZslLnQKpHXLni0st5J+3YMLvOMAI4T mMSPw7/Ai6n9FJP2tq56UvYXtqOhG4NIPfURmUbDInXjhIAfhdK+cQw4YBO0urfAiMse dZFQ== 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:references:from:date :message-id:subject:to:cc; bh=tDqCdHOC3YzEGt8ycc4v/3Knp5huOVZLN4qhbOMzKDo=; b=YXi4fWBOZUHO0wwmVfCrcX4h7vXJ23giwCMAglrwLnIuuCDO10zBTUCROuP646Tlrl /ChJQLFR31sIVStdJtKv9NoIGmmCVe9Fd/UZdcapuSEiK+9xvFZYdRKy9UGxJWSrtVNV mAyMbZS1c2gr93KZs7cqwvWwtrsIxzL/FSygIoICeEV76NidRwKCi8GwURPS2kQaEn1d JISPgUY77wyRw1Y0dZ1XD85MVosJc3ZSbYx+ctAZIhLR956Ft6ym7MsImQN9Yc1VAMRf NDXXFEqKxYzXpba4zCmEp/gc/sXsRKOSm7SqTM8R1fVBRDPls9Zq3HE9Y0KQMv6cBzVs yRrA== X-Gm-Message-State: AKGB3mIiALDQRUBcFKHO7+UCbRcy5v7hn3ZX4cVnSUmJCPNyd+SXKBjx +vSD/mUEBGA7Hx42+YeGxYx4VB/yhZ5s5vyuMmJfWA== X-Google-Smtp-Source: ACJfBosF0zweAqyiLW3Prh/ZfNWcU6Mj3puVqJnPpNhLXMY+/P1yT6jKEuFV/MrrZQhXJjXHEMJc4UObbOpgLfcsr8E= X-Received: by 10.37.239.17 with SMTP id g17mr1881698ybd.474.1514997109442; Wed, 03 Jan 2018 08:31:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 08:31:08 -0800 (PST) In-Reply-To: References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> From: Eric Rescorla Date: Wed, 3 Jan 2018 08:31:08 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "" , Martin Thomson , Lanlan Pan , Ted Lemon , JW , Stephen Farrell Content-Type: multipart/alternative; boundary="089e08289ed88b5e770561e1c008" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:31:54 -0000 --089e08289ed88b5e770561e1c008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > > > > > On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jo=C5=84czyk > > wrote: > > > > W dniu 03.01.2018 o 14:19, Eric Rescorla pisze: > > > I have several comments: > > > > > > - This is almost entirely out of scope for TLS, so you should > start with > > > CAPPORT. If they're interested, then we can discuss the code poin= t > assignment in > > > TLS. > > > > > > - You point #2 would effectively require either changes to the > browser or CA > > > issuance policies (the BRs would prohibit issuing to an entity > under these > > > conditions). I'm not sure that browser manufacturers would be > excited about > > > either set of changes. Resolving this seems like a threshold > question for this > > > proposal. > > > > It could be possible for providers to obtain certifiates for > subdomains such as > > opendns.access_administratively_disabled.net > > . Then the > server > > reachable at > > access_administratively_disabled.net > > would provide a > certificate for > > opendns.access_administratively_disabled.net > > , which would > be > > incorrect but > > browsers would in this special case trust it. > > > > > > Well, this seems like the first arm, in which you change the browser, s= o > the > > question > > then becomes whether the browsers wish to do so. Are you aware of any > > browser vendor which is interested? > > I'm not exactly sure what You understand by "the first arm". > Of course it would have to be implemented in browsers, by me or somebody > else. > Microsoft may wish to deploy this in their Forefront TMG, so browser > support in > Internet Explorer / Edge would follow. > My question is whether any browser has indicated interest in doing so. > > It seems like there are going to be rather a large number of such > > > entities (every Firewall in the world?) so it may not be practica= l. > > > DNS already handles a large number of such entities and it somehow works > and is > practical. Having a subdomain of access_administratively_disabled.net > registered > would be expensive because a physical validation would have to be followe= d > - it > would probably be no less expensive than EV certificates currently are. > It's not a matter of scaling. It's a matter of having this many certificates that can all generate an acceptable message undermines the value of the signature because you now have a distributed single point of failure. -Ekr > Greetings, > Mateusz Jo=C5=84czyk > > > -Ekr > > > > > > > > [1] http://msdn.microsoft.com/en-us/library/ff827462(v=3Dvs.85).asp= x > > > > > > Greetings, > > Mateusz Jo=C5=84czyk > > > > > > > > > > > > > > > > > -Ekr > > > > > > > > > > > > On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5=84czyk > > > >> wrote: > > > > > > Hello, > > > Based on Your feedback (for which I am grateful) I have > designed a new version > > > of the access_administratively_disabled mechanism. > > > > > > 1. One new AlertDescription value should be specified: > > > access_administratively_disabled. > > > > > > 2. The information why the webpage is blocked is specified at > the URL > > > https://access_administratively_disabled.net?d=3D${domain_nam= e} > > > > > > > = as > a simple > > > string. > > > > > > 3. Certificates for access_administratively_disabled.net > > > > > > > are assigned in a > > > non-usual way: any big entity that blocks websites (e.g. > OpenDNS) may get a > > > certificate for access_administratively_disabled.net > > > > > > > provided that their > > > identity is validated (i.e. in an Extended-Validation way). > The list of entities > > > that received certificates for this domain would be made > public and managed by > > > IANA. This way the risk of phishing would be eliminated. > > > > > > 4. Any entity that is blocking some websites would redirect > traffic for > > > access_administratively_disabled.net > > > > > > > to their own servers= . > > > > > > 5. After getting an access_administratively_disabled warning > a browser > > would > > > open https://access_admininistratively_disabled. > net?d=3D${domain_name} > > > > > net?d=3D${domain_name} > > = > > , validate > > > its certificate and display to the user information: what get > blocked, > > by whom > > > and why. > > > > > > 6. If https://access_administratively_disabled.net > > > > > > > would not have a > valid > > > certificate, the browser would only display that the website > is being > > blocked, > > > without giving any reason. > > > > > > 7. IANA or someone else would provide a default > > > https://access_administratively_disabled.net > > > > > > > service for the > public internet. > > > > > > This mechanism would provide blocking transparency without > affecting > > security. > > > > > > Greetings, > > > Mateusz Jo=C5=84czyk > > > > > > > > > > > > --089e08289ed88b5e770561e1c008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
W dniu 03.01.2018= o 16:28, Eric Rescorla pisze:
>
>
> On Wed, Jan 3, 2018 at 6:45 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0W dniu 03.01.2018 o 14:19, Eric Rescorla pisze:
>=C2=A0 =C2=A0 =C2=A0> I have several comments:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - This is almost entirely out of scope for TLS= , so you should start with
>=C2=A0 =C2=A0 =C2=A0> CAPPORT. If they're interested, then we ca= n discuss the code point assignment in
>=C2=A0 =C2=A0 =C2=A0> TLS.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - You point #2 would effectively require eithe= r changes to the browser or CA
>=C2=A0 =C2=A0 =C2=A0> issuance policies (the BRs would prohibit issu= ing to an entity under these
>=C2=A0 =C2=A0 =C2=A0> conditions). I'm not sure that browser man= ufacturers would be excited about
>=C2=A0 =C2=A0 =C2=A0> either set of changes. Resolving this seems li= ke a threshold question for this
>=C2=A0 =C2=A0 =C2=A0> proposal.
>
>=C2=A0 =C2=A0 =C2=A0It could be possible for providers to obtain certif= iates for subdomains such as
>=C2=A0 =C2=A0 =C2=A0opendns.access_admin= istratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://opendns= .access_administratively_disabled.net>. Then the server >=C2=A0 =C2=A0 =C2=A0reachable at
>=C2=A0 =C2=A0 =C2=A0access_administratively_disa= bled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_administra= tively_disabled.net> would provide a certificate for
>=C2=A0 =C2=A0 =C2=A0opendns.access_admin= istratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://opendns.access= _administratively_disabled.net>, which would be
>=C2=A0 =C2=A0 =C2=A0incorrect but
>=C2=A0 =C2=A0 =C2=A0browsers would in this special case trust it.
>
>
> Well, this seems like the first arm, in which you change the browser, = so the
> question
> then becomes whether the browsers wish to do so. Are you aware of any<= br> > browser vendor which is interested?

I'm not exactly sure what You understand by "the first arm&= quot;.
Of course it would have to be implemented in browsers, by me or somebody el= se.
Microsoft may wish to deploy this in their Forefront TMG, so browser suppor= t in
Internet Explorer / Edge would follow.

= My question is whether any browser has indicated interest in doing so.


>=C2=A0 =C2=A0 =C2=A0> It seems like there are going to be rath= er a large number of such
>=C2=A0 =C2=A0 =C2=A0> entities (every Firewall in the world?) so it = may not be practical.
>
DNS already handles a large number of such entities and it somehow w= orks and is
practical. Having a subdomain of access_administratively_= disabled.net registered
would be expensive because a physical validation would have to be followed = - it
would probably be no less expensive than EV certificates currently are.
=

It's not a matter of scaling. It's= a matter of having this many certificates that can
all generate = an acceptable message undermines the value of the signature
becau= se you now have a distributed single point of failure.=C2=A0

=
-Ekr
=C2=A0
Greetings,
Mateusz Jo=C5=84czyk

> -Ekr
>
>
>
>=C2=A0 =C2=A0 =C2=A0[1] http://m= sdn.microsoft.com/en-us/library/ff827462(v=3Dvs.85).aspx
>=C2=A0 =C2=A0 =C2=A0<http://msdn.microsoft.com/en-us/library/ff827462(v=3Dvs.85).<= wbr>aspx>
>
>=C2=A0 =C2=A0 =C2=A0Greetings,
>=C2=A0 =C2=A0 =C2=A0Mateusz Jo=C5=84czyk
>
>=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> -Ekr
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Wed, Jan 3, 2018 at 4:48 AM, Mateusz Jo=C5= =84czyk <mat.jonczyk@o2.pl <= mailto:mat.jonczyk@o2.pl>
>=C2=A0 =C2=A0 =C2=A0> <mailto:mat.jonczyk@o2.pl <mailto:mat.jonczyk@o2.pl>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Hello,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Based on Your feedback (for= which I am grateful) I have designed a new version
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0of the access_administrativ= ely_disabled mechanism.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A01. One new AlertDescription= value should be specified:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0access_administratively_disabled.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A02. The information why the = webpage is blocked is specified at the URL
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://access_administratively_disabled.net?d=3D${do= main_name}
>=C2=A0 =C2=A0 =C2=A0<https://a= ccess_administratively_disabled.net?d=3D${domain_name}> >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https://access_administratively_disabled.net?d=3D$= {domain_name}
>=C2=A0 =C2=A0 =C2=A0<https://a= ccess_administratively_disabled.net?d=3D${domain_name}>>= ; as a simple
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0string.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A03. Certificates for access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_administra= tively_disabled.net>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://acces= s_administratively_disabled.net>> are assigned in a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0non-usual way: any big enti= ty that blocks websites (e.g. OpenDNS) may get a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0certificate for access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_administra= tively_disabled.net>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://acces= s_administratively_disabled.net>> provided that their >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0identity is validated (i.e.= in an Extended-Validation way). The list of entities
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0that received certificates = for this domain would be made public and managed by
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0IANA. This way the risk of = phishing would be eliminated.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A04. Any entity that is block= ing some websites would redirect traffic for
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0access_ad= ministratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_administra= tively_disabled.net>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<http://access_administratively_disabled.net>&g= t; to their own servers.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A05. After getting an access_= administratively_disabled warning a browser
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0open https://access_admininistratively_disabled.net?= d=3D${domain_name}
>=C2=A0 =C2=A0 =C2=A0<https:/= /access_admininistratively_disabled.net?d=3D${domain_name}>= ;
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<https://access_admininistratively_disabled.net?d= =3D${domain_name}
>=C2=A0 =C2=A0 =C2=A0<https:/= /access_admininistratively_disabled.net?d=3D${domain_name}>= ;> , validate
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0its certificate and display= to the user information: what get blocked,
>=C2=A0 =C2=A0 =C2=A0by whom
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0and why.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A06. If ht= tps://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http= s://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net>> would not have a valid
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0certificate, the browser wo= uld only display that the website is being
>=C2=A0 =C2=A0 =C2=A0blocked,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0without giving any reason.<= br> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A07. IANA or someone else wou= ld provide a default
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0https://= access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http= s://access_administratively_disabled.net
>=C2=A0 =C2=A0 =C2=A0<https://access_administ= ratively_disabled.net>> service for the public internet.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0This mechanism would provid= e blocking transparency without affecting
>=C2=A0 =C2=A0 =C2=A0security.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Greetings,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Mateusz Jo=C5=84czyk
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>


--089e08289ed88b5e770561e1c008-- From nobody Wed Jan 3 08:49:01 2018 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 3E066124D68 for ; Wed, 3 Jan 2018 08:49:00 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 OESBvm_UgUWm for ; Wed, 3 Jan 2018 08:48:58 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 27C6A1241F5 for ; Wed, 3 Jan 2018 08:48:57 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 12405 invoked from network); 3 Jan 2018 17:48:55 +0100 Received: from agsa196.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.78.196]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 3 Jan 2018 17:48:55 +0100 To: Eric Rescorla References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> Cc: "" , Martin Thomson , Lanlan Pan , Ted Lemon , JW , Stephen Farrell From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 3 Jan 2018 17:48:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: b45eff8574abcc21a228e6de4c49b86c X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [8TNk] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:49:00 -0000 W dniu 03.01.2018 o 17:31, Eric Rescorla pisze: > > > On Wed, Jan 3, 2018 at 8:17 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 16:28, Eric Rescorla pisze: > > Well, this seems like the first arm, in which you change the browser, so the > > question > > then becomes whether the browsers wish to do so. Are you aware of any > > browser vendor which is interested? > > I'm not exactly sure what You understand by "the first arm". > Of course it would have to be implemented in browsers, by me or somebody else. > Microsoft may wish to deploy this in their Forefront TMG, so browser support in > Internet Explorer / Edge would follow. > > My question is whether any browser has indicated interest in doing so. No, I didn't contact any browser vendors. If an AlertDescription will be allocated, they will have to implement this at least halfway - display some warning to the user, without necessarily contacting access_administratively_disabled.net at all. > DNS already handles a large number of such entities and it somehow works and is > practical. Having a subdomain of access_administratively_disabled.net > registered > would be expensive because a physical validation would have to be followed - it > would probably be no less expensive than EV certificates currently are. > > > It's not a matter of scaling. It's a matter of having this many certificates > that can > all generate an acceptable message undermines the value of the signature > because you now have a distributed single point of failure. Just like CAs. I don't think that there will be more access_administratively_disabled.net subdomains than there are CAs currently. After all, the failure won't be very catastrophic: it will only enable someone who already is able to intercept all traffic to slightly phish the users. If some key will leak publicly, it will be simply revoked. Greetings, Mateusz > > -Ekr > From nobody Wed Jan 3 08:54:03 2018 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 5D750124D68 for ; Wed, 3 Jan 2018 08:54:02 -0800 (PST) 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, FREEMAIL_FROM=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 qDDCuy4SLJjH for ; Wed, 3 Jan 2018 08:54:00 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 4DCCF1241F5 for ; Wed, 3 Jan 2018 08:54:00 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 15267 invoked from network); 3 Jan 2018 17:53:58 +0100 Received: from agsa196.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.78.196]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 3 Jan 2018 17:53:58 +0100 To: Russ Housley References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <8FDABBC5-98C2-4353-88B5-FB553C5DE387@vigilsec.com> Cc: IETF TLS From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 3 Jan 2018 17:53:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8FDABBC5-98C2-4353-88B5-FB553C5DE387@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 4db3ecbdc5024abb5960953901c725d4 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [QbOU] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 16:54:02 -0000 W dniu 03.01.2018 o 17:08, Russ Housley pisze: > Mateusz: > > How do you see IANA controlling which parties get certificates for the access_administratively_disabled.net domain? IANA is just an example, there could be some other provider controlling the access_administratively_disabled.net domain - possibly even OpenDNS. Subdomains [1] would be given out just like EV certificates are today - only proof of identity (and of payment) would be required. > > Russ > > P.S. If I recall RFC 1034 and 1035 correctly, domain name labels may contain only letters, digits, and hyphen. Underscore is not allowed. Yup, I also thought so. access_administratively_disabled.net is only a placeholder, the final domain name would be different. Greetings, Mateusz [1] For a slight modification of the proposal, see https://www.ietf.org/mail-archive/web/tls/current/msg25226.html > >> On Jan 3, 2018, at 7:48 AM, Mateusz Jończyk wrote: >> >> Hello, >> Based on Your feedback (for which I am grateful) I have designed a new version >> of the access_administratively_disabled mechanism. >> >> 1. One new AlertDescription value should be specified: >> access_administratively_disabled. >> >> 2. The information why the webpage is blocked is specified at the URL >> https://access_administratively_disabled.net?d=${domain_name} as a simple string. >> >> 3. Certificates for access_administratively_disabled.net are assigned in a >> non-usual way: any big entity that blocks websites (e.g. OpenDNS) may get a >> certificate for access_administratively_disabled.net provided that their >> identity is validated (i.e. in an Extended-Validation way). The list of entities >> that received certificates for this domain would be made public and managed by >> IANA. This way the risk of phishing would be eliminated. >> >> 4. Any entity that is blocking some websites would redirect traffic for >> access_administratively_disabled.net to their own servers. >> >> 5. After getting an access_administratively_disabled warning a browser would >> open https://access_admininistratively_disabled.net?d=${domain_name} , validate >> its certificate and display to the user information: what get blocked, by whom >> and why. >> >> 6. If https://access_administratively_disabled.net would not have a valid >> certificate, the browser would only display that the website is being blocked, >> without giving any reason. >> >> 7. IANA or someone else would provide a default >> https://access_administratively_disabled.net service for the public internet. >> >> This mechanism would provide blocking transparency without affecting security. >> >> Greetings, >> Mateusz Jończyk >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Jan 3 09:05:45 2018 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 3BCBE1241F5 for ; Wed, 3 Jan 2018 09:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 OT-FH5Ok6GvQ for ; Wed, 3 Jan 2018 09:05:41 -0800 (PST) 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 80257124D68 for ; Wed, 3 Jan 2018 09:05:41 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w03GcqlS020308; Wed, 3 Jan 2018 17:05:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=2J6cXx89LpsX1c3oZIpWuD0/HgIfSUOjetzKgX27tB0=; b=hb0UNtO73roa1l1/Iklb9Vhzeshn5aN07gVm8Ouj5Yl6dXmQ3X7hZnLBlpMOqLvd10fc z8p5zBqmt8Qj+PACdjYxP4Yhoymvu64/+/b+MMO13TJUy2be594IabRYzS4p4keN/0EH E3NTHNf5PTMNiwrqBcQ9Iu9Tih8WasoOj7eGcWDHzBUKAwzeP7N8CihLtp0j48b32HfP c1+1wKeZ40oWfOY9ekW31t5uwarBiF4+2dOGrISet67BSPtqUI3kb7ubQjCDNCsTZFbh UE6qWTGJlfXjOPs5jhtIpe4UeYr8/JN1WZrPmDaD+/coDS1JmcMRlII7TJAWKV4L4994 HA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2f63awhwxu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Jan 2018 17:05:38 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w03GuNqZ027364; Wed, 3 Jan 2018 12:05:37 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f670yx663-1; Wed, 03 Jan 2018 12:05:37 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2C4D52417E; Wed, 3 Jan 2018 17:05:37 +0000 (GMT) To: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Cc: "" References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> From: Benjamin Kaduk Message-ID: <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> Date: Wed, 3 Jan 2018 11:05:36 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-03_12:, , 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=596 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030236 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-03_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=586 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030233 Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 17:05:43 -0000 On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > Judging from TLS1.3's problems with middleboxes, content filtering isn't so > rare, especially in the corporate world. > > The provider of filtering services (for example OpenDNS) / middlebox > manufacturer would have to recognize if the client supports this mechanism. > Having support for TLS1.3 could be one such flag. Cherry-picking this one part just for enhanced clarity: I do not think support for TLS 1.3 can or should be such a flag -- there does not seem sufficient reason to block TLS 1.3 finalization for this proposal. -Ben From nobody Wed Jan 3 09:23:08 2018 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 562B71241F5 for ; Wed, 3 Jan 2018 09:23:07 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 zBGqvFoxLoLK for ; Wed, 3 Jan 2018 09:23:05 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 396001270B4 for ; Wed, 3 Jan 2018 09:23:05 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id w1so849850ybe.10 for ; Wed, 03 Jan 2018 09:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AZ30OQTBz0AYa92TnuoyJ9OFjNmaTxo5X7yLpbouPvs=; b=h07/Y2ESxW4w/SIUov0ZkfPrX27ovUHQ7ljMc/PdWqUVV9CsezZCWpQYbNcziFwoRv e86ryn/cWOS4DIEv5pwYgL5Qz4eoSn3nBUv6eEiwHyc/HRYhJ0qhYjLTT188qoacNN3N EFUcTHmp4I6hYVDI2t1pScDt09/I7bvNMFOrJlGoNXVjPN/7aQnBQpWzGQKNi63nAK+B LGFCO3rRzh2d+M9VVSV/MEGlu0k4goCBMmjtW5ahgMfEidLE8H2lc6BC7R2T22pegLNX /7EY3ljuiNpBrXmJejkllGsFlkfBx99T3+Y9qvZpc4jQ7y90j4ezWMUzr3zEd3uxNk0Y UccA== 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:references:from:date :message-id:subject:to:cc; bh=AZ30OQTBz0AYa92TnuoyJ9OFjNmaTxo5X7yLpbouPvs=; b=nkGVzEVYOOyOH7Um3S7dMgehLRC10/JB+OEaZ/Bv34quFI5oxcA1TDtxCe0OkikO+Q LuUxGfQ9MFF/T41dzLIWjHRY6R+gNW2aa7RVS/KoZ1c/KqD4/G2po3K37KzQ0WkVUAhN RJutbNjklyu7pZ4W2FY2UQBj8IEhWcTqzVZ0CCL9gBgMLJyYkyCvJlL0vAjstQ10TtFN F+NPcKGTXkym4KTGQCof7M0ZMVlrKUjEFIa7/Y9A+N2qAhWczDZgcchh6tdkU+yL+lLS 4kXbkQSStWvkI5qLnuHkzdqYjVEDbIyWorD7AGhoMtdgdBGwRF7v8Y37PDUw2eNlm2iJ DDPA== X-Gm-Message-State: AKGB3mITTNlxCpbfWTNtVXM2OLacVsqk3XjQDB6vtAhPih7pCyQ8Xcwx AlM9t1sO68/5UQmMvEEVbvsI0sJcjvLWO08XN+e8+g== X-Google-Smtp-Source: ACJfBouXbkECUKBbV2dZLscrh8t5txO+j+S9YBJdM2xN/gax9RY2CSH4bPHQj6aU4NxAvN/UwXvnmvzxXBtxJgxaCE8= X-Received: by 10.37.252.16 with SMTP id v16mr1969766ybd.425.1515000184147; Wed, 03 Jan 2018 09:23:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.70 with HTTP; Wed, 3 Jan 2018 09:23:03 -0800 (PST) In-Reply-To: <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> References: <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 3 Jan 2018 09:23:03 -0800 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="f403045d3304cfa6320561e27755" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 17:23:07 -0000 --f403045d3304cfa6320561e27755 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario wrote: > > > *Second: hide all alerts in suspicious error cases* > > Next, when the handshake does fail, we do two non-standard things. The > > first is that we don't return an alert message, we just close the > > connection. > > > > *Third: mask timing side-channels with a massive delay* > > The second non-standard thing we do is that in all error cases, s2n > behaves > > as if something suspicious is going on and in case timing is involved, we > > add a random delay. It's well known that random delays are only partially > > effective against timing attacks, but we add a very very big one. We > wait a > > random amount of time between a minimum of 10 seconds, and a maximum of > 30 > > seconds. > > Note that both of those things only _possibly_ frustrate attackers while > they > definitely frustrate researchers trying to characterise your > implementation as > vulnerable or not. In effect making it seem secure while in reality it may > not > be. > No, I strongly disagree here. Firstly, frustrating attackers is a good definition of what the goal of security is. Some times increasing costs for attackers does come at the cost of making things harder to analyze or debug, but we shouldn't make the latter easier at the expense of the former. In practical terms; it's not that big a deal. For the purposes of research it's usually easy to remove the delays or masking - I did it myself recently to test various ROBOT detection scripts; turning off the delay was a one line code patch and I was up and running, it hardly hindered research at all. Similarly, we've already had to reduce the granularity of TLS alerts, so TLS experts and analysts are used to having to dive into code, step-throughs, to debug some kinds of problems. I can't how many hours I've spent walking through why a big opaque blob didn't precisely match another big opaque blob. We could make all of that easier by logging and alerting all sorts of intermediate states, but it would be a terrible mistake because it would leak so much information to attackers. As for delays possibly making an attackers job harder; I'm working on some more firm, signal-analysis based, grounding for the approach as the impact varies depending on the amount of noise present, as well as the original distribution of measurement due to ordinary scheduling and network jitter, but the approach certainly makes timing attacks take millions to trillions more attempts, and can push real-world timing leaks well into unexploitable in the real world. -- Colm --f403045d3304cfa6320561e27755 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
> *Second: hide all alerts= in suspicious error cases*
> Next, when the handshake does fail, we do two non-sta= ndard things. The
> first is that we don't return an alert message, we just close the<= br> > connection.
>
> *Third: mask timing side-channels with a massive delay*
> The second non-standard thing we do is that in all er= ror cases, s2n behaves
> as if something suspicious is going on and in case timing is involved,= we
> add a random delay. It's well known that random delays are only pa= rtially
> effective against timing attacks, but we add a very very big one. We w= ait a
> random amount of time between a minimum of 10 seconds, and a maximum o= f 30
> seconds.

Note that both of those things only _possibly_ frustrate attackers w= hile they
definitely frustrate researchers trying to characterise your implementation= as
vulnerable or not. In effect making it seem secure while in reality it may = not
be.

No, I strongly disagree here. First= ly, frustrating attackers is a good definition of what the goal of security= is. Some times increasing costs for attackers does come at the cost of mak= ing things harder to analyze or debug, but we shouldn't make the latter= easier at the expense of the former.=C2=A0

In pra= ctical terms; it's not that big a deal. For the purposes of research it= 's usually easy to remove the delays or masking - I did it myself recen= tly to test various ROBOT detection scripts; turning off the delay was a on= e line code patch and I was up and running, it hardly hindered research at = all.=C2=A0

Similarly, we've already had to red= uce the granularity of TLS alerts, so TLS experts and analysts are used to = having to dive into code, step-throughs, to debug some kinds of problems. I= can't how many hours I've spent walking through why a big opaque b= lob didn't precisely match another big opaque blob. We could make all o= f that easier by logging and alerting all sorts of intermediate states, but= it would be a terrible mistake because it would leak so much information t= o attackers.=C2=A0

As for delays possibly making a= n attackers job harder; I'm working on some more firm, signal-analysis = based, grounding for the approach as the impact varies depending on the amo= unt of noise present, as well as the original distribution of measurement d= ue to ordinary scheduling and network jitter, but the approach certainly ma= kes timing attacks take millions to trillions more attempts, and can push r= eal-world timing leaks well into unexploitable in the real world.=C2=A0

--
Colm
--f403045d3304cfa6320561e27755-- From nobody Wed Jan 3 17:05:03 2018 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 7EE6812D7F7 for ; Wed, 3 Jan 2018 17:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 x08LjwcoMrv9 for ; Wed, 3 Jan 2018 17:04:59 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 DC6AA12D7F3 for ; Wed, 3 Jan 2018 17:04:58 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id q5so141732oth.2 for ; Wed, 03 Jan 2018 17:04:58 -0800 (PST) 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=4yC3cmuDXyzB3+ljdqWc2DuXsMK2QpHK70RxdKYWzFI=; b=bRnjsqgyVlcjSAcptnvd6Ek50gCF4Af6pzXswrILUD41NJI0dldOXUWl1lmX+KZwlt SEnw1WrACaDDxqbXqGzRUx7XhW0ZX0Jq52UMhpxiEagSAINX6RrBEDoqLetc+ni40UJo S7r2QuuwsnV+ZC/qeYzXajsM5+BNFp4k3G0sDagsHBnsOxWXuia/biqJQRUE1oUy4EOp 4FgkVYQBMxeS4bGirDkKk5VwNuYG2paIz9OdlUGd+IfdVfgiildy0PEhLCxOjk/6PjC9 NYgjuJ9CeT4kT/OMjj+ZoIDLuXhrna1bs1N6dWNTzkTN7zr0jBCpQ91sNnZMZSBhuVOH r+qA== 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=4yC3cmuDXyzB3+ljdqWc2DuXsMK2QpHK70RxdKYWzFI=; b=YO8/r3IAhkor0CUti9m8NhADRmN43o7NHIfVf6Eq2/0gEBXe4/us7BySnvrcwJs2i9 +7jqagTA2rOeEL6eUZIoS0gn0DrD74PcNga3XFxQIPr3OnNgpClL2naBpk+DWCrxKP5/ uz+VWE0gFksASFHODdY4C9wJ71tOqdQdh8In/m/SPsmGCzgeqmQlQoDgLzstHuCJ4kb2 MO3ihkeBP3Dxkd4srpqBihliJ9guO4mNcnapW24k2xi4fBiwgnAlcfJscIANbOrNee80 8+KaHy70rHGcvxvaIwqi+lk3sfTf4aXB+87tSkuKfzdS+UFGKy0SnLNicFglMyzPPV5J mXSw== X-Gm-Message-State: AKGB3mINiLIOvRp3Pt0oAlhd0f/Z8psi6fSp25mFroVQxAhMRxUXll2v l/y2GvcFKMZar5f+YwPCWeSm3561L47A/7VepCo9Xc15 X-Google-Smtp-Source: ACJfBouPVc0uKgVyou5Upg/056O7H4/pM7crvspmfYybWgKmL6oSanwuo0uRsKoog48OztNRo/xN7uOzNvYwatawybk= X-Received: by 10.157.74.52 with SMTP id h49mr1894249otf.308.1515027898065; Wed, 03 Jan 2018 17:04:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Wed, 3 Jan 2018 17:04:57 -0800 (PST) From: Martin Thomson Date: Thu, 4 Jan 2018 12:04:57 +1100 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Was the numbering of rsa_pss_pss_sha384 intentional? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 01:05:01 -0000 rsa_pss_pss_sha256(0x0809), rsa_pss_pss_sha384(0x0810), rsa_pss_pss_sha512(0x0811), 0x080a is the next value... From nobody Wed Jan 3 17:33:14 2018 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 2594F12D7EC for ; Wed, 3 Jan 2018 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 s_jaDe_mr5Si for ; Wed, 3 Jan 2018 17:33:10 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 5BD78127137 for ; Wed, 3 Jan 2018 17:33:10 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l23so75366ywb.13 for ; Wed, 03 Jan 2018 17:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ix7L9gK7BfgJIvw9YvMMovG6zZNJ1OV2ORQ2cemvWew=; b=gefIExQxprQ88rgk45sjsIyWhN3n8MGGFxZWGIbZ4vdYO42+qH33Z6HSmxvH50xdw8 4+42tqt3cv0FwCYFAKCYv/AbbVJUVyq85OiXGNDnoUNOO9fb4oULP5p2Cyf+lA9O26zn 11JwUYPKPUBWq8B8KsuUXIngK9I7I/Qw/h00a+w8/RYK7GOBAkwaumxlcDMOZFOGjlhQ hRPO2qt1ziBciNZUpRkhZ3fr9MGPSTL1W1G62+0qeG2lVllMBlVOkswEV8a0dki+DPSj 2sEXGjWJXQsnPuKhF5iS8WbX+bGDgUrODxzdCcOU4YdT4j+xrQjuCl1/lbEqu/4gxox/ lS1Q== 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:references:from:date :message-id:subject:to:cc; bh=ix7L9gK7BfgJIvw9YvMMovG6zZNJ1OV2ORQ2cemvWew=; b=JKlWLxWVcxkdnt5GKUm46xjfyF6pXaYd28KgQB2hytE0N1eEo8naUR8nP80x6URmAm a4gp4HHQo0YzVodpQdEeXTh8IGYguLjuHPcRvISsfO8oi9FcUjq1mVLpe9CIgaatnC3I Ze5A/awdH94HnHFInj7+tn49NPUJfVNW7U/z2/bXgKMIAoOZHNIzA+YUxXC4QUKRQFs9 DLqnrx5Ufpy1D4YQbWGzcdfgTOwvjzM7YazDKIuFj+31Ifw8u3ALQEiQnMpaa+pSiEyC 931yYwoe4h1iSm1rBqDH7co0U+Vt/Mso6JHM1ZDdna6WHIZMDiF3fHOpYLUfSkKVyqOZ emeA== X-Gm-Message-State: AKGB3mIBHa7j7F5dK+U7Jj3eMvW3KSnzQiarNaYkxeES8Cn4hJDa4HpY BrictEzc3n04aPzYsDZ+yx/Hh4hKAYJ1ZBzDeGkNjw== X-Google-Smtp-Source: ACJfBouZI+wNxc4LqHznubAiua2AlVUdDRzftX+CJS9KS/Cye43qn6bpVDuhxHE1t2NRIUeLYrO6BB0PyA4do7DKOBY= X-Received: by 10.129.48.202 with SMTP id w193mr3001953yww.378.1515029589419; Wed, 03 Jan 2018 17:33:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 3 Jan 2018 17:32:28 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 3 Jan 2018 17:32:28 -0800 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="001a11409cfa8085a70561e9509c" Archived-At: Subject: Re: [TLS] Was the numbering of rsa_pss_pss_sha384 intentional? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 01:33:12 -0000 --001a11409cfa8085a70561e9509c Content-Type: text/plain; charset="UTF-8" No, just forgetting we were working in hex I think it would be fine to change. -Ekr On Wed, Jan 3, 2018 at 5:04 PM, Martin Thomson wrote: > rsa_pss_pss_sha256(0x0809), > rsa_pss_pss_sha384(0x0810), > rsa_pss_pss_sha512(0x0811), > > 0x080a is the next value... > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11409cfa8085a70561e9509c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, just forgetting we were working in hex I think it woul= d be fine to change.

-Ekr


On Wed, Jan 3, 2018 at 5:04 PM, M= artin Thomson <martin.thomson@gmail.com> wrote:
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x0810),
rsa_pss_pss_sha512(0x0811),

0x080a is the next value...

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

--001a11409cfa8085a70561e9509c-- From nobody Wed Jan 3 21:22:41 2018 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 6FBE71270AB for ; Wed, 3 Jan 2018 21:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UQW7zOuDOeIl for ; Wed, 3 Jan 2018 21:22:38 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 7BA0A12426E for ; Wed, 3 Jan 2018 21:22:38 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id p31so474710ota.4 for ; Wed, 03 Jan 2018 21:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xwZIkakjfAN+ROgCVLcP1jwU4VJYm+PNmJEawPrqanc=; b=TfRwngOnNQ+xADJbYpuV9LNBBjHvECDQ+mPa6fDHUXwYLVMaOiXx/c04d40yGsMy/C EuDc3U1gUSikjSoiPYinbGEHekmDjjI1syU+vf14++Ycj84dmmkT/but9K7TG1+qRUzq E7rDCI6E6n8qLzlONxDUj3U1rnkcn+5tMayz65F/gcntOCpWN/LOZn/UO4doHnFKuPOo mE09rCnzMHKYPBCZbu7tWOCtisw17DLcp3N9s/SscEic0aHZIhW9ScS38YI76BncHpiM PI34fIepqaD+0g0WgzgBz436khNkxdy8g0E2rkp1zezDQVLMV1T80VMQGzgU9Gj9gCin iv1Q== 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:references:from:date :message-id:subject:to:cc; bh=xwZIkakjfAN+ROgCVLcP1jwU4VJYm+PNmJEawPrqanc=; b=kSVfUNyr2vWzwJJBw7xIoUJwnyeJ651749MIh95MQKEFlyTrT1pRlOw5Blw1/md+MN PYqiShCPS9xmYZuvX4zvtYw0tRbgWTX05mCKSuR/Ix8gMuOmzYBJkPHhUWNQhVuiw7pj /U4r3QsuI/pQ3NLfqtzFVIpr3Jn/EGGJCRucM/2i4qtGoWOX4L5MBLHqenEh0NHQCgGt RgjxbTdoN3z2xInLc5BhMSb88ZR4jOGcIUS3ul5NTsl0c87UIfXFhJ47PPBuZq8OA++T BveS19NZAPSnhF9+dB+ZGKKO7l8VNi1Shd+qtYGDwFxeSBxyg2EfZ4vsmAiSrA+FbHC4 CUaw== X-Gm-Message-State: AKGB3mK9ATujmpSomA5aEZzUVe63PMT3GitIUpimoRbmcC5AujJ89DV+ uXaWN7Dy/8Cagvh0myz9adBfSNh5auFAR3xJ9TO5Zk72 X-Google-Smtp-Source: ACJfBotfC5Y8dT9fT7mJ/PQDyNf28lIqWrBgFlr5pWRqAHvPQWfgjdWyzHOwtgaVMOW8UiXClby9XMA23PQLp0Yha7k= X-Received: by 10.157.88.42 with SMTP id r42mr2578070oth.71.1515043357678; Wed, 03 Jan 2018 21:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Wed, 3 Jan 2018 21:22:37 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 4 Jan 2018 16:22:37 +1100 Message-ID: To: Eric Rescorla Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Was the numbering of rsa_pss_pss_sha384 intentional? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 05:22:40 -0000 https://github.com/tlswg/tls13-spec/pull/1133 On Thu, Jan 4, 2018 at 12:32 PM, Eric Rescorla wrote: > No, just forgetting we were working in hex I think it would be fine to > change. > > -Ekr > > > On Wed, Jan 3, 2018 at 5:04 PM, Martin Thomson > wrote: >> >> rsa_pss_pss_sha256(0x0809), >> rsa_pss_pss_sha384(0x0810), >> rsa_pss_pss_sha512(0x0811), >> >> 0x080a is the next value... >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Jan 4 02:46:22 2018 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 81E801205F0 for ; Thu, 4 Jan 2018 02:46:20 -0800 (PST) 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, FREEMAIL_FROM=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 DyviZ8p0LngR for ; Thu, 4 Jan 2018 02:46:18 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 DD9931200C5 for ; Thu, 4 Jan 2018 02:46:17 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 1636 invoked from network); 4 Jan 2018 11:46:15 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 11:46:15 +0100 To: Benjamin Kaduk References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> Cc: "" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> Date: Thu, 4 Jan 2018 11:46:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: d8db661f80b5aa9d346f3c4e96e8c219 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [gZME] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 10:46:20 -0000 W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: >> Judging from TLS1.3's problems with middleboxes, content filtering isn't so >> rare, especially in the corporate world. >> >> The provider of filtering services (for example OpenDNS) / middlebox >> manufacturer would have to recognize if the client supports this mechanism. >> Having support for TLS1.3 could be one such flag. > > Cherry-picking this one part just for enhanced clarity: I do not think > support for TLS 1.3 can or should be such a flag -- there does not seem > sufficient reason to block TLS 1.3 finalization for this proposal. I would like to ask You to add just this one flag: access_administratively_disabled to TLS 1.3. This will allow graceful upgrade to full proposed functionality of the access_administratively_disabled mechanism. I will try to submit an Internet Draft for the full mechanism till the end of this week. Greetings, Mateusz Jończyk > > -Ben > From nobody Thu Jan 4 04:17:34 2018 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 53E24127275 for ; Thu, 4 Jan 2018 04:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.931 X-Spam-Level: X-Spam-Status: No, score=-6.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hHG5GDKYB8xA for ; Thu, 4 Jan 2018 04:17:30 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71321127010 for ; Thu, 4 Jan 2018 04:17:30 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F3455B2F4; Thu, 4 Jan 2018 12:17:30 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26BB3608EE; Thu, 4 Jan 2018 12:17:30 +0000 (UTC) Received: from zmail21.collab.prod.int.phx2.redhat.com (zmail21.collab.prod.int.phx2.redhat.com [10.5.83.24]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 1EDE5410AE; Thu, 4 Jan 2018 12:17:30 +0000 (UTC) Date: Thu, 4 Jan 2018 07:17:30 -0500 (EST) From: Hubert Kario To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: tls@ietf.org Message-ID: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com> In-Reply-To: References: <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [78.102.32.78, 10.4.196.25, 10.4.195.10] Thread-Topic: A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS Thread-Index: nJGMiP3BxD9y3Z4mW0dHtDzRFUOVdA== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 04 Jan 2018 12:17:30 +0000 (UTC) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 12:17:32 -0000 ----- Original Message -----=20 > From: "Colm MacC=C3=A1rthaigh" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Wednesday, January 3, 2018 6:23:03 PM > Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in > general, and what we can do in TLS > On Wed, Jan 3, 2018 at 3:45 AM, Hubert Kario < hkario@redhat.com > wrote: > > > *Second: hide all alerts in suspicious error cases* >=20 > > > Next, when the handshake does fail, we do two non-standard things. Th= e >=20 > > > first is that we don't return an alert message, we just close the >=20 > > > connection. >=20 > > > >=20 > > > *Third: mask timing side-channels with a massive delay* >=20 > > > The second non-standard thing we do is that in all error cases, s2n > > > behaves >=20 > > > as if something suspicious is going on and in case timing is involved= , we >=20 > > > add a random delay. It's well known that random delays are only parti= ally >=20 > > > effective against timing attacks, but we add a very very big one. We = wait > > > a >=20 > > > random amount of time between a minimum of 10 seconds, and a maximum = of > > > 30 >=20 > > > seconds. >=20 > > Note that both of those things only _possibly_ frustrate attackers whil= e > > they >=20 > > definitely frustrate researchers trying to characterise your implementa= tion > > as >=20 > > vulnerable or not. In effect making it seem secure while in reality it = may > > not >=20 > > be. >=20 > No, I strongly disagree here. Firstly, frustrating attackers is a good > definition of what the goal of security is. Some times increasing costs f= or > attackers does come at the cost of making things harder to analyze or deb= ug, > but we shouldn't make the latter easier at the expense of the former. No, the goal of security is to stop attacks from being successful, not make= them harder. Making attack harder is security through obscurity. Something= that definitely doesn't work for open source software.=20 > In practical terms; it's not that big a deal. For the purposes of researc= h > it's usually easy to remove the delays or masking - I did it myself recen= tly > to test various ROBOT detection scripts; turning off the delay was a one > line code patch and I was up and running, it hardly hindered research at > all. now multiply that by 20 different libraries and as a researcher you will gi= ve up on the third one. Or rather on the first one as the 18.5 other do sen= d alerts and implement RFC recommended behavior.=20 > Similarly, we've already had to reduce the granularity of TLS alerts, so = TLS > experts and analysts are used to having to dive into code, step-throughs,= to > debug some kinds of problems. I can't how many hours I've spent walking > through why a big opaque blob didn't precisely match another big opaque > blob. We could make all of that easier by logging and alerting all sorts = of > intermediate states, but it would be a terrible mistake because it would > leak so much information to attackers. "the dose makes the poison". Yes, we need to strike a balance between enoug= h and not enough information. One thing is for sure, the correct solution d= oes not lie in the extremes.=20 > As for delays possibly making an attackers job harder; I'm working on som= e > more firm, signal-analysis based, grounding for the approach as the impac= t > varies depending on the amount of noise present, as well as the original > distribution of measurement due to ordinary scheduling and network jitter= , > but the approach certainly makes timing attacks take millions to trillion= s > more attempts, and can push real-world timing leaks well into unexploitab= le > in the real world. honestly, I consider this approach completely misguided. If you are OK with= tying up a socket for 30 seconds, simply start a timer once you get the or= iginal client hello (or the first message of second flight, in TLS 1.2), cl= ose the socket if the handshake is not successful in 30 seconds. In case of= errors, send nothing, let it timeout. The only reason why this approach to= constant time error handling is not used is because most people are not ok= with tying up resources for so long.=20 --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Thu Jan 4 04:48:45 2018 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 58C37129C5D for ; Thu, 4 Jan 2018 04:48:43 -0800 (PST) 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, FREEMAIL_FROM=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 QCKC0ZMkYbaq for ; Thu, 4 Jan 2018 04:48:41 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 1B47D1270FC for ; Thu, 4 Jan 2018 04:48:40 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 28447 invoked from network); 4 Jan 2018 13:48:39 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 13:48:39 +0100 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Benjamin Kaduk , "" References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> Message-ID: <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> Date: Thu, 4 Jan 2018 13:48:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: e0f5e739137d2b35e35172ef0a891dce X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [UbP0] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 12:48:43 -0000 W dniu 04.01.2018 o 11:46, Mateusz Jończyk pisze: > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: >> On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: >>> Judging from TLS1.3's problems with middleboxes, content filtering isn't so >>> rare, especially in the corporate world. >>> >>> The provider of filtering services (for example OpenDNS) / middlebox >>> manufacturer would have to recognize if the client supports this mechanism. >>> Having support for TLS1.3 could be one such flag. >> >> Cherry-picking this one part just for enhanced clarity: I do not think >> support for TLS 1.3 can or should be such a flag -- there does not seem >> sufficient reason to block TLS 1.3 finalization for this proposal. > > I would like to ask You to add just this one flag: > access_administratively_disabled to TLS 1.3. This will allow graceful upgrade to > full proposed functionality of the access_administratively_disabled mechanism. > > I will try to submit an Internet Draft for the full mechanism till the end of > this week. > I have sent a pull request: https://github.com/tlswg/tls13-spec/pull/1134 Added access_denied_by_intermediary AlertDescription Network intermediaries (for example ISPs) may always block traffic by using e.g. access_denied. Make it more explicit by adding access_denied_by_intermediary. This will make censorship more transparent. Greetings, Mateusz Jończyk From nobody Thu Jan 4 05:32:30 2018 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 1F3F612D82F for ; Thu, 4 Jan 2018 05:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 StpRVieellUz for ; Thu, 4 Jan 2018 05:32:27 -0800 (PST) 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 27A65126CD6 for ; Thu, 4 Jan 2018 05:32:27 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w04DMDXx014994; Thu, 4 Jan 2018 13:32:25 GMT 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=ttpu2sslHe8JL5NMNZDfmGTYLnfzGdVu41odWRJ9j0k=; b=K27vfCtlFadooGFK6qgXuL6hAnKgx+EEMHLeAn1AW2sOfp6V/LRE8+jgX107Dvmlgy0w d0czOCiD7JyfYDlM7aToYA6yQ7JQ7SIgNkM8AMaOLHSA4TCcAuJ0ETOB7saX0CAfI3lb dBxpafaaHgfnDcLVqxDvaqeD3cTiGvUuZt/0oZXzdDc/qQoDIS9oJPq0PaWeK2oW6Sp8 GpCn6BKOcgFTWEoaMHJEUCUctnI04bvIbYmPfdvqdcuF5lq+zfwBoPlAOLDqV/rNzpph QevA7oY/qi5zLp8EstJ0tFrnzYYZhtdrfGN24q5K/npEhwrxErDYUN8q4YKazOrlbOUp 9g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2f6377e44q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 13:32:25 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w04DTO46031325; Thu, 4 Jan 2018 08:32:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f67102gxq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 08:32:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 Jan 2018 05:32:23 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 4 Jan 2018 08:32:23 -0500 From: "Salz, Rich" To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= , "Kaduk, Ben" , "" Thread-Topic: [TLS] access_administratively_disabled v2 Thread-Index: AQHThJE18kfuuXwokkOCgTG+nMQX5aNidYcAgAAYEACAAAwugIAADZcAgAANeACAAShWAIAAIjMAgAAMOAA= Date: Thu, 4 Jan 2018 13:32:22 +0000 Message-ID: <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> In-Reply-To: <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.199] 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.10432:, , definitions=2018-01-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=934 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040185 Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:32:29 -0000 4p6iICAgaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvcHVsbC8xMTM0DQrigKYN CiAgICAJVGhpcyB3aWxsIG1ha2UgY2Vuc29yc2hpcCBtb3JlIHRyYW5zcGFyZW50Lg0KICANCk9u bHkgaWYgdGhlIGNlbnNvciBhZ3JlZXMgdG8gdXNlIHRoYXQgYWxlcnQgdG8gaW5kaWNhdGUgd2hh dCB0aGV5IGFyZSBkb2luZy4gIERvIHlvdSByZWFsbHkgdGhpbmsgdGhhdCB3aWxsIGhhcHBlbj8N Cg0K From nobody Thu Jan 4 05:45:07 2018 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 4F2B312D7ED for ; Thu, 4 Jan 2018 05:45:06 -0800 (PST) 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, FREEMAIL_FROM=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 775aKtEO_o99 for ; Thu, 4 Jan 2018 05:45:03 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 39F65126CD6 for ; Thu, 4 Jan 2018 05:45:03 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 13890 invoked from network); 4 Jan 2018 14:45:01 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 14:45:01 +0100 To: "Salz, Rich" , "Kaduk, Ben" , "" References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 4 Jan 2018 14:45:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: b2122d90a75d8763413cc0eb8f1bc93c X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [0VMU] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:45:06 -0000 W dniu 04.01.2018 o 14:32, Salz, Rich pisze: > ➢ https://github.com/tlswg/tls13-spec/pull/1134 > … > This will make censorship more transparent. > > Only if the censor agrees to use that alert to indicate what they are doing. Do you really think that will happen? > Yes, at least in corporate environments, parental control solutions, etc. This will give a more understandable message to the user. Greetings, Mateusz Jończyk From nobody Thu Jan 4 06:23:42 2018 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 45CD712D862 for ; Thu, 4 Jan 2018 06:23:40 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ksBeXMQ3ZR_1 for ; Thu, 4 Jan 2018 06:23:38 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 19EF9127023 for ; Thu, 4 Jan 2018 06:23:38 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id j7so662653ybl.3 for ; Thu, 04 Jan 2018 06:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mX0RyyrIRll7KORBRW+cV1G1j7/PpjQYzh8LP5ARPNY=; b=cxzR9nGXZg210kY+YiDWKhb8YDC7hUtr6hynznJhlAiPS5cl2p4ZqKJlQNWQjd7HrO 0E/x3DxJhQpMJbAeWQNATC2RP3bhPCVgkHX4ItsI1FMNwvmaXXhypWsShWXljy/9iKWV omRu67NeoH2uYGdmhx9kNSbTtCSlrGuCg5Oec9RoOINXqHnp45fG/cp/FWmkl8OCRhSp DvNeip07Sc+WkIYVorOwXDNmyvfeECssnYMnIR162wVnCTRtQiTm5ELaJO5vdf8/JLRw D+pXiJrWLwLLGEg/4S+yxJaBkX6pFMZu3amRQNlWmz3V09XPn3T+Si1JrPHQY81sSz7/ BaJQ== 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:references:from:date :message-id:subject:to:cc; bh=mX0RyyrIRll7KORBRW+cV1G1j7/PpjQYzh8LP5ARPNY=; b=h+8RJ+0StTULOaSmOdpvpIR+/tMDdm7MqPmksoNR28Rc6EoQfKP20edF4BMfF4NSps F4WXVoumvy+UoH8hdLKxFdhnImzWlaA23AD2Y9kEITB9FfYXkmizdZf/ZkCG4JIIR5rp njBn2JrK031HGDElsVmO7Ieo7b6e3EAUETqAOSkpRp5ntusJvIca2CfKdc0a4b9P3wHJ GuZuXNT/SGdmCLduX6+IbiMNu7lN7O+Eal7cjdhU0baS8JawnYN7r2zeruVEg31lk54g 80of0jF48JvYW1A4lZtThkjfHCZpiAZtGPC+xpbhsNjoG+KPoPq1GkrqaQU1d5/vO7MQ yqEg== X-Gm-Message-State: AKGB3mKxnCtd2uiToz9SqLyloLoQQ2cb3zVhdGmgubb4US+upzeCDQqy R7HSErtDB8XM93ZyiXSaLrOcbhgnR3kPiBTchwFk5g== X-Google-Smtp-Source: ACJfBovW9CCxFsDXSyL4Z8hf8vhpy78Bvn8nzD8gyk+zX6UdhW+WxukvOPoRzRJdEOegy8VexCMCIFarZTG8969bi00= X-Received: by 10.37.239.17 with SMTP id g17mr4413868ybd.474.1515075817149; Thu, 04 Jan 2018 06:23:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 4 Jan 2018 06:22:56 -0800 (PST) In-Reply-To: <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> From: Eric Rescorla Date: Thu, 4 Jan 2018 06:22:56 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="089e08289ed8e3aae80561f413d1" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:23:40 -0000 --089e08289ed8e3aae80561f413d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > On 01/03/2018 10:17 AM, Mateusz Jo=C5=84czyk wrote: > >> Judging from TLS1.3's problems with middleboxes, content filtering > isn't so > >> rare, especially in the corporate world. > >> > >> The provider of filtering services (for example OpenDNS) / middlebox > >> manufacturer would have to recognize if the client supports this > mechanism. > >> Having support for TLS1.3 could be one such flag. > > > > Cherry-picking this one part just for enhanced clarity: I do not think > > support for TLS 1.3 can or should be such a flag -- there does not seem > > sufficient reason to block TLS 1.3 finalization for this proposal. > > I would like to ask You to add just this one flag: > access_administratively_disabled to TLS 1.3. This will allow graceful > upgrade to > full proposed functionality of the access_administratively_disabled > mechanism. > I am not in favor of this change at this time. I suspect I'm not in favor of the mechanism, but i'm definitely not in favor of adding a placeholder alert for some mechanism which isn't specified. -Ekr I will try to submit an Internet Draft for the full mechanism till the end > of > this week. > > Greetings, > Mateusz Jo=C5=84czyk > > > > > -Ben > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e08289ed8e3aae80561f413d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
W dniu 03.01.2018= o 18:05, Benjamin Kaduk pisze:
> On 01/03/2018 10:17 AM, Mateusz Jo=C5=84czyk wrote: >> Judging from TLS1.3's problems with middleboxes, content filte= ring isn't so
>> rare, especially in the corporate world.
>>
>> The provider of filtering services (for example OpenDNS) / middleb= ox
>> manufacturer would have to recognize if the client supports this m= echanism.
>> Having support for TLS1.3 could be one such flag.
>
> Cherry-picking this one part just for enhanced clarity: I do not think=
> support for TLS 1.3 can or should be such a flag -- there does not see= m
> sufficient reason to block TLS 1.3 finalization for this proposal.

I would like to ask You to add just this one flag:
access_administratively_disabled to TLS 1.3. This will allow graceful = upgrade to
full proposed functionality of the access_administratively_disabled me= chanism.

I am not in favor of this chan= ge at this time.

I suspect I'm not in favor of= the mechanism, but i'm definitely not in favor of
adding a p= laceholder alert for some mechanism which isn't specified.
-Ekr

I will try to submit an Internet Draft for the full mechanism till the end = of
this week.

Greetings,
Mateusz Jo=C5=84czyk

>
> -Ben
>

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

--089e08289ed8e3aae80561f413d1-- From nobody Thu Jan 4 06:43:36 2018 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 E5C7E12D876 for ; Thu, 4 Jan 2018 06:43:33 -0800 (PST) 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, FREEMAIL_FROM=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 4tKQp038Xt9k for ; Thu, 4 Jan 2018 06:43:32 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 D667112D86C for ; Thu, 4 Jan 2018 06:43:31 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 24621 invoked from network); 4 Jan 2018 15:43:29 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 15:43:29 +0100 To: Eric Rescorla References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> Cc: Benjamin Kaduk , "" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <466bac48-539e-a651-2edd-c8d4006c89fe@o2.pl> Date: Thu, 4 Jan 2018 15:43:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: d7757ea91c3e0ed1e175660100ea7d1a X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [cSOk] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:43:34 -0000 W dniu 04.01.2018 o 15:22, Eric Rescorla pisze: > > > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jończyk > wrote: > > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > On 01/03/2018 10:17 AM, Mateusz Jończyk wrote: > >> Judging from TLS1.3's problems with middleboxes, content filtering isn't so > >> rare, especially in the corporate world. > >> > >> The provider of filtering services (for example OpenDNS) / middlebox > >> manufacturer would have to recognize if the client supports this mechanism. > >> Having support for TLS1.3 could be one such flag. > > > > Cherry-picking this one part just for enhanced clarity: I do not think > > support for TLS 1.3 can or should be such a flag -- there does not seem > > sufficient reason to block TLS 1.3 finalization for this proposal. > > I would like to ask You to add just this one flag: > access_administratively_disabled to TLS 1.3. This will allow graceful upgrade to > full proposed functionality of the access_administratively_disabled mechanism. > > > I am not in favor of this change at this time. > > I suspect I'm not in favor of the mechanism, but i'm definitely not in favor of > adding a placeholder alert for some mechanism which isn't specified. > OK, but what about this change considered separately? I have changed the semantics slightly: +access_denied_by_intermediary +: The access was denied by a network intermediary - i.e. a server other + than the client or the desired server, for example by an Internet Sevice + Provider. Justification: Network intermediaries (for example ISPs) may block traffic by using e.g. access_denied anyway. Make it more explicit by adding access_denied_by_intermediary. This will make censorship more transparent. Greetings, Mateusz > -Ekr > > I will try to submit an Internet Draft for the full mechanism till the end of > this week. > > Greetings, > Mateusz Jończyk > > > > > -Ben > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > From nobody Thu Jan 4 06:46:56 2018 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 120DF12D877 for ; Thu, 4 Jan 2018 06:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QY-GylX7Vgr0 for ; Thu, 4 Jan 2018 06:46:52 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 D404212D86C for ; Thu, 4 Jan 2018 06:46:51 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id k80so650739ywe.0 for ; Thu, 04 Jan 2018 06:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pP4SqxalqRvLwEffmugcQGuikbSdr+W36SOVi3SkQ8c=; b=xCRZL30Tt1qe4asi6yAVRL0ZvMs4eVvYZb6K9vkv9ZYQRgB4S+4z5ai5LpVuIf9sM5 26tZQOXSLOdrSrURHvkUFzu5Fd5f7cJ06fS4pkH2jwzWLiO80Wx7iHOlARQ1w2PaVg9P KGXIFc33kTayC8mb8mnxquBjaWj7R3j2TaXMUcW3NcrJ1MB1VXME8DvdY2KE9k3Dk/8e 1mrx3ho9P0Ev05+ZsWjz4zIGZjh2wt4Ovc7GK8SszLTeVXQj2t0Zso+0v7sETJkZFBR1 aMWpXVXqF002SRalZK12KXw4H2CqLW9q+ZgmvmeVAiYCw03yJtHK/5jqPKgIalxn54H5 70Ow== 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:references:from:date :message-id:subject:to:cc; bh=pP4SqxalqRvLwEffmugcQGuikbSdr+W36SOVi3SkQ8c=; b=HSp7ZU2HPCtsk2VYKr9usBKiwuVYB4F4LySS/m9su0u/FF1x22F5TZF4qVCtbHMPtN KtecKYOjLwOKyGUiqbLYrT/9epbDY9Yiygyzb2hsU86C/ude5vhaMp46Wr/fWcbo8k0V tDyWvyDrnKinU33eVj67ygrbx/aQuflMtSSFUvyrCc+qwZgRA6waVARKt06PLMXPdaRJ WpIMGNdAvUJvdsBSDehaAETRXMQ9oUO4lbrtrewRENgWO/jhNNffm1ykCUWhURmyfLfw intiuW0c4Zv0/hbwHEqt4UGKVKHdMI6SXpB3kSL620xg4NSImhy4SmB6Tdffl5TdVQ0m nKPQ== X-Gm-Message-State: AKGB3mJwSaJH4EpAo0IUCfKRsv+4tfvU501CUYg0FiP5AhFfU5Bfvbvk 9xQJsjANKZ1knQczprxkmhtEXeKaU/5cGjGy0v4M5++H X-Google-Smtp-Source: ACJfBotJP7SHR4ISS87gYPiCjcMYKWPyc/jth7MBI4CB0CwBXJsnETofDq9Xs9Yay+sG88SUVUVAhpNpMwkSLiu2uv8= X-Received: by 10.129.154.22 with SMTP id r22mr4238816ywg.296.1515077211024; Thu, 04 Jan 2018 06:46:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 4 Jan 2018 06:46:10 -0800 (PST) In-Reply-To: <466bac48-539e-a651-2edd-c8d4006c89fe@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <466bac48-539e-a651-2edd-c8d4006c89fe@o2.pl> From: Eric Rescorla Date: Thu, 4 Jan 2018 06:46:10 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="94eb2c0bb4e8f876d50561f4669e" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 14:46:54 -0000 --94eb2c0bb4e8f876d50561f4669e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 4, 2018 at 6:43 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 04.01.2018 o 15:22, Eric Rescorla pisze: > > > > > > On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jo=C5=84czyk > > wrote: > > > > W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: > > > On 01/03/2018 10:17 AM, Mateusz Jo=C5=84czyk wrote: > > >> Judging from TLS1.3's problems with middleboxes, content > filtering isn't so > > >> rare, especially in the corporate world. > > >> > > >> The provider of filtering services (for example OpenDNS) / > middlebox > > >> manufacturer would have to recognize if the client supports this > mechanism. > > >> Having support for TLS1.3 could be one such flag. > > > > > > Cherry-picking this one part just for enhanced clarity: I do not > think > > > support for TLS 1.3 can or should be such a flag -- there does no= t > seem > > > sufficient reason to block TLS 1.3 finalization for this proposal= . > > > > I would like to ask You to add just this one flag: > > access_administratively_disabled to TLS 1.3. This will allow > graceful upgrade to > > full proposed functionality of the access_administratively_disabled > mechanism. > > > > > > I am not in favor of this change at this time. > > > > I suspect I'm not in favor of the mechanism, but i'm definitely not in > favor of > > adding a placeholder alert for some mechanism which isn't specified. > > > OK, but what about this change considered separately? I have changed the > semantics slightly: > > +access_denied_by_intermediary > +: The access was denied by a network intermediary - i.e. a server other > + than the client or the desired server, for example by an Internet Sevi= ce > + Provider. > > Justification: > Network intermediaries (for example ISPs) may block traffic by > using > e.g. access_denied anyway. Make it more explicit by adding > access_denied_by_intermediary. > > This will make censorship more transparent. > Sorry, no, I'm not persuaded. It's not clear to me that this is a benefit, and certainly not clear enough to merit a last minute change to 1.3. -Ekr > Greetings, > Mateusz > > > > -Ekr > > > > I will try to submit an Internet Draft for the full mechanism till > the end of > > this week. > > > > Greetings, > > Mateusz Jo=C5=84czyk > > > > > > > > -Ben > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > --94eb2c0bb4e8f876d50561f4669e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 4, 2018 at 6:43 AM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
W dniu 04.01.2018= o 15:22, Eric Rescorla pisze:
>
>
> On Thu, Jan 4, 2018 at 2:46 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0W dniu 03.01.2018 o 18:05, Benjamin Kaduk pisze: >=C2=A0 =C2=A0 =C2=A0> On 01/03/2018 10:17 AM, Mateusz Jo=C5=84czyk w= rote:
>=C2=A0 =C2=A0 =C2=A0>> Judging from TLS1.3's problems with mi= ddleboxes, content filtering isn't so
>=C2=A0 =C2=A0 =C2=A0>> rare, especially in the corporate world. >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> The provider of filtering services (for ex= ample OpenDNS) / middlebox
>=C2=A0 =C2=A0 =C2=A0>> manufacturer would have to recognize if th= e client supports this mechanism.
>=C2=A0 =C2=A0 =C2=A0>> Having support for TLS1.3 could be one suc= h flag.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Cherry-picking this one part just for enhanced= clarity: I do not think
>=C2=A0 =C2=A0 =C2=A0> support for TLS 1.3 can or should be such a fl= ag -- there does not seem
>=C2=A0 =C2=A0 =C2=A0> sufficient reason to block TLS 1.3 finalizatio= n for this proposal.
>
>=C2=A0 =C2=A0 =C2=A0I would like to ask You to add just this one flag:<= br> >=C2=A0 =C2=A0 =C2=A0access_administratively_disabled to TLS 1.3. T= his will allow graceful upgrade to
>=C2=A0 =C2=A0 =C2=A0full proposed functionality of the access_administr= atively_disabled mechanism.
>
>
> I am not in favor of this change at this time.
>
> I suspect I'm not in favor of the mechanism, but i'm definitel= y not in favor of
> adding a placeholder alert for some mechanism which isn't specifie= d.
>
OK, but what about this change considered separately? I have changed= the
semantics slightly:

+access_denied_by_intermediary
+: The access was denied by a network intermediary - i.e. a server other +=C2=A0 than the client or the desired server, for example by an Internet S= evice
+=C2=A0 Provider.

Justification:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network intermediaries (for example ISPs) may b= lock traffic by using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e.g. access_denied anyway. Make it more explici= t by adding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 access_denied_by_intermediary.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This will make censorship more transparent.
=

Sorry, no, I'm not persuaded. I= t's not clear to me that this is a benefit, and certainly
not= clear enough to merit a last minute change to 1.3.

-Ekr


Greetings,
Mateusz


> -Ekr
>
>=C2=A0 =C2=A0 =C2=A0I will try to submit an Internet Draft for the full= mechanism till the end of
>=C2=A0 =C2=A0 =C2=A0this week.
>
>=C2=A0 =C2=A0 =C2=A0Greetings,
>=C2=A0 =C2=A0 =C2=A0Mateusz Jo=C5=84czyk
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> -Ben
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0TLS@ietf.org= <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/tls
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/tls>
>
>


--94eb2c0bb4e8f876d50561f4669e-- From nobody Thu Jan 4 07:00:28 2018 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 A728912D876 for ; Thu, 4 Jan 2018 07:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 uTE8X2hkWVGS for ; Thu, 4 Jan 2018 07:00:24 -0800 (PST) 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 D829E1201F8 for ; Thu, 4 Jan 2018 07:00:24 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w04EuJCu018914; Thu, 4 Jan 2018 15:00:23 GMT 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=5CfwUN6pft6KxmJALTh+deeyiFQkCpO5BI+NKD78veY=; b=aVLQCh1n656i+if+lB6vITaDaYtichZJmwIWSfDuMrWMzMdfiJVF8GzZf2E08E5jNSLB VU+Ihd1QODEV9wB7BIrgkpbgU4ySBliwhKjX/rYllV195oU4QA2nLdYdStXwQN3/LH5g VFrBCi/voH0gUlIu+JEUmlt+ZiB+XD9Yv0HFySQqYRvhcPaH5OWAvHxm1UyG5B7Sgx1w a7cEoPvamPXZGXNULoel21XcwVCj51Z4PQLWuXCEz8AQBjDkl4NfCMtsHNdSSuJMxLNr jeo2k/lvoCCoTxGmzE2pBuKdl3Oz9oUwh9pK3s8qfbB0FPUV9yqklDDtEWG1hy3nqkAi ew== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2f6377ebnu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 15:00:22 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w04Ex7Lh022922; Thu, 4 Jan 2018 10:00:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f9pej812d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 10:00:20 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 4 Jan 2018 10:00:20 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 4 Jan 2018 10:00:20 -0500 From: "Salz, Rich" To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= , "Kaduk, Ben" , "" Thread-Topic: [TLS] access_administratively_disabled v2 Thread-Index: AQHThJE18kfuuXwokkOCgTG+nMQX5aNidYcAgAAYEACAAAwugIAADZcAgAANeACAAShWAIAAIjMAgAAMOACAAAOIAIAAFO0A Date: Thu, 4 Jan 2018 15:00:19 +0000 Message-ID: <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> <495C6A3F-D05A-432F-924E-B75D7754F10D@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/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.151] Content-Type: text/plain; charset="utf-8" Content-ID: <63ECFAE79005BB4793F39B35A1E93D44@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=938 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040206 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=869 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040207 Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:00:27 -0000 DQo+ICAgIFllcywgYXQgbGVhc3QgaW4gY29ycG9yYXRlIGVudmlyb25tZW50cywgcGFyZW50YWwg Y29udHJvbCBzb2x1dGlvbnMsIGV0Yy4NCiAgICBUaGlzIHdpbGwgZ2l2ZSBhIG1vcmUgdW5kZXJz dGFuZGFibGUgbWVzc2FnZSB0byB0aGUgdXNlci4NCiAgDQoNCkJ1dCBhcyBvdGhlcnMgaGF2ZSBw b2ludGVkIG91dCwgdGhlIGFsZXJ0IGlzIG5vdCBzaWduZWQgYnkgdGhlIHRhcmdldCBvcmlnaW4u ICBTbyBhbnlvbmUgYWxvbmcgdGhlIHBhdGggY2FuIGluamVjdCB0aGlzIGFsZXJ0LiAgU28gYnJv d3NlcnMgY2Fubm90IHRydXN0IGl0LCBhbmQgdGhleSBjZXJ0YWlubHkgY2Fubm90IGRpc3BsYXkg YW55IHBvc3NpYmxlIHRleHQgYXNzb2NpYXRlZCB3aXRoIGl0Lg0KDQpIb3cgY2FuIHlvdSBkaXN0 aW5ndWlzaCB2YWxpZCBhbmQgcHJvcGVyIHVzZSwgZnJvbSBub3QgdmFsaWQgYW5kIGltcHJvcGVy IHVzZSBpbmNsdWRpbmcgRG9TPyAgV2l0aG91dCB0aGF0IGFsZ29yaXRobSBzcGVjaWZpZWQsIEkg ZG91YnQgYW55IGJyb3dzZXIgd291bGQgaW1wbGVtZW50IHRoaXMuICAoQW5kIElNTyBJIGRvdWJ0 IHRoZXkgd2lsbCBkbyBzbyBhbnl3YXkuKQ0KDQoNCg== From nobody Thu Jan 4 07:22:49 2018 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 9CC9112D879 for ; Thu, 4 Jan 2018 07:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 jdQP_-Q_heDw for ; Thu, 4 Jan 2018 07:22:45 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 4AD3012D882 for ; Thu, 4 Jan 2018 07:22:42 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 17181 invoked from network); 4 Jan 2018 16:22:40 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 16:22:40 +0100 To: "Salz, Rich" , "Kaduk, Ben" , "" References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= X-Enigmail-Draft-Status: N1110 Message-ID: <1cee37b1-eef9-9b6f-97d0-09b340751015@o2.pl> Date: Thu, 4 Jan 2018 16:22:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: 2844ebfb3ca9bad2ff1f69abd135ac98 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [QQOk] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:22:47 -0000 W dniu 04.01.2018 o 16:00, Salz, Rich pisze: > >> Yes, at least in corporate environments, parental control solutions, etc. > This will give a more understandable message to the user. > > > But as others have pointed out, the alert is not signed by the target origin. > So anyone along the path can inject this alert. Yup, just as anyone along the path can block the website. > So browsers cannot trust it, > and they certainly cannot display any possible text associated with it. In the version being discussed there is no associated text. > > How can you distinguish valid and proper use, from not valid and improper use > including DoS? Any intermediary (ISP, etc.) can block a website and this way cause a DoS. TLS changes nothing in this regard. This solution only makes it obvious that the DoS is introduced intentionally. > Without that algorithm specified, I doubt any browser > would implement this. (And IMO I doubt they will do so anyway.) > In the version being discussed it is just another error value. I think browsers would implement it just like they will implement access_denied. Greetings, Mateusz Jończyk From nobody Thu Jan 4 07:53:04 2018 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 D849D12D851 for ; Thu, 4 Jan 2018 07:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6WwwVTBsp6vA for ; Thu, 4 Jan 2018 07:52:58 -0800 (PST) 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 E0AFF12D879 for ; Thu, 4 Jan 2018 07:52:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F379BDD8; Thu, 4 Jan 2018 15:52:51 +0000 (GMT) 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 os8UE0mhebaj; Thu, 4 Jan 2018 15:52:49 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8FA76BE56; Thu, 4 Jan 2018 15:52:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515081168; bh=Va9Zdr74cXQO5ye0jgI9cZX2qURwNIi/py9poG/kjtE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CuAs8aYF+bPHRj5XYyP4VQ9I3b++SFmO3hPbTdfJLEJSikVaaRrSkoVAUrcBbZ8xL rYBuhCvxiUWinOeNER4NmS6CfQ+iGfPnrfDWvl3guouiRIpup+bnpFxyKMdnySz3Fm 9ZW+uvSEvueKHLL4IuudLnlmJ9NH8weHEqkKaAIE= To: Eric Rescorla , =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Cc: "" References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> Date: Thu, 4 Jan 2018 15:52:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FLkuFgTh6v4lqBERTwWoRZSNJJlQtQT92" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:53:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FLkuFgTh6v4lqBERTwWoRZSNJJlQtQT92 Content-Type: multipart/mixed; boundary="hcGdKK5wlOuSXqwDlxWvdDCbSpvlElhIL"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Cc: "" Message-ID: <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> Subject: Re: [TLS] access_administratively_disabled v2 References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> In-Reply-To: --hcGdKK5wlOuSXqwDlxWvdDCbSpvlElhIL Content-Type: multipart/mixed; boundary="------------22409771FD55B4ED6D828285" Content-Language: en-GB This is a multi-part message in MIME format. --------------22409771FD55B4ED6D828285 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/18 14:22, Eric Rescorla wrote: > I am not in favor of this change at this time. Same here. >=20 > I suspect I'm not in favor of the mechanism, but i'm definitely not in > favor of > adding a placeholder alert for some mechanism which isn't specified. I'm fairly sure I'm against attempting to handle captive portal issues at the TLS layer. Any changes to TLS needed for captive portals ought really garner consensus within the capport wg and then be discussed here. (It looks from the archive of that wg that this topic hasn't even been raised there despite a few people suggesting that, which is IMO another reason to reject this proposal now.) I don't find the more-transparent-censorship argument offered convincing. If DNS-based censorship is offered as the motivation (as opposed to or in addition to captive portals) then I think that'd require chatting with the dnsop folks, who are already discussing DNS-RPZ. I'd guess, (but not sure as it's not my fav. idea;-), that might throw up a requirement that censorship might only be done for a few minutes while some previously unseen name was checked out, or a name might be censored for days or weeks, if it's newly registered and some censor considers that a threat. IOW, if any changes to TLS are warranted based on DNS-based censorship, then those are likely more complex than has been seen in this discussion, and also aren't things where this list has the right expertise AFAIK. S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------22409771FD55B4ED6D828285 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------22409771FD55B4ED6D828285-- --hcGdKK5wlOuSXqwDlxWvdDCbSpvlElhIL-- --FLkuFgTh6v4lqBERTwWoRZSNJJlQtQT92 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaTk3QAAoJEFqy+vF7Fyvqg/0P/3dxeVS2iVlbQcUyy1s1OG8T RIdaIcjsm/dlp9SEtwqPVDNikKMJxQXQriAvBc29Kcj38PikLC6VXIwByXCfU6vt xhybH+UJC79FeU7GONh6+SQmNa/0MBjDXiKsrGpdA8pbWm8tx3zuoiVYrjIpzqkI dDXfk93aSOJzvxFDbxfXoRRbI+hfjU49L9FNA/cBkehCMEdP7m+nYRLvYM+UCzq6 GMmVwmZgvemp0XaNhZ6+R9dKH8X41xAOuoGXlRvhZa2t8NDcn03kKZo2nXnt1QWQ WjMW9qoNZXjmy2YmB7bG9vd+CTREADsH99vqjgUkqZYZkLv3OZM5qS6EYTqLD/xX ZaYIJXTxuVy6nE4c8G37jyjstn4qfRpp+Bt4OUSceWRqeZFTXuSADHJRMclx2TOJ b+5EL8cxzaEnr4WsxC6lpx/k4up2chiRs3HTW9ioTpV3/d0igRMLxBQS5+z0wDAN Xc2ccO4gGE9bTY4S7HuL+EsXsBo3Qe3DEBfl7PFpzXj8ngUymX43CgZp3MYucp2U 8aCD4pmoT4gPZySz3iv2S7uR8aHIl2L0BTi959LXbMvVRHbytjGly+5L8iap4n9C 3U58MuBIS0ahs4W16L689M7nfxiVABZ/SSP5UXLQ8Cm5GT79ThQMV3HzQTY2oK/R vOm9+s51Pz0dcsU9zgtP =UmQj -----END PGP SIGNATURE----- --FLkuFgTh6v4lqBERTwWoRZSNJJlQtQT92-- From nobody Thu Jan 4 07:59:14 2018 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 765CC12D7EE for ; Thu, 4 Jan 2018 07:59:12 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 QHNFCvVe6uvN for ; Thu, 4 Jan 2018 07:59:10 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 5C6BD12704A for ; Thu, 4 Jan 2018 07:59:10 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id a82so778943ybg.1 for ; Thu, 04 Jan 2018 07:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l3sr2nQOb5Xaw3w1KMOvBVmtBzxaZ+X0bcYkswXzOUg=; b=lbMXpMD/YHHbEgNns8H4/3bUXjL3zHCfoYnXdbNtGH76mym5gy1z+VxL+OH1DOMYZc sRGo96AcmBJt9nHstKNKEdbtRFxTg8MgGKHdyZtG5/V9Bp/ZG8VYWn8VZd66mQe2f4yA kuu0HaaC2l0zT5kEACM0SFMuC1iY+NHhxL1ofxnSUCuRdI0NpVQ0KoAxS90pbYODkUId mxoiJGHr89pA7veOMr2Bk4MUIT+gsWVQP9NsUmhs/U8cfDnO8f9pwpDpCHeJm6n+5FgY 2UW2WtY6Z8fuV09MTN2hwWfCMpVGT9fkher5svw04PubKXh/we4AgHglXbf7C824vO8Y zd9w== 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:references:from:date :message-id:subject:to:cc; bh=l3sr2nQOb5Xaw3w1KMOvBVmtBzxaZ+X0bcYkswXzOUg=; b=cuzlsWCrXiuuYai6UFcn8Of47wPH/B6EuLOmJoeQcScv2mYRNHpyQ/78ZPkjWorAaH 7vaOhzYj467Ivk/fe4SrCgTs2FHCUlRUmYdM1TE9P2QXWadWGu6IqhihSyfusei+ISdn WCwXfkZTqFI5WRu9c5Deiv5Nap2qJmAQS0ZnUXM8Li+xwzVT+BeklEaYIqYReMWwZrC/ vCcJ7k3Sd1xrFNZxEBsl5D+KJuAuUsGXzut5oUczhgfEwQC2XrtT7cOG0IM9I7S7pHby bjR+bzpobYlFYU7Opuwc0JBG21zBAoOUX7TtTCRbKBpIqvA1CQ1b0KiLNf5bQhIwANtv gnGQ== X-Gm-Message-State: AKGB3mLnTNEL3JC75D+JKEMEbYSXnUjD2MbwxEeVApLXv8216922zn9Y kE4aYW99oBKaT9XXKEkAqpmzz85sB1xfBL6L63toKA== X-Google-Smtp-Source: ACJfBouR5hLG57zGmaOggYpdAawSMVSF4tYq6RiQtTP+ksTzaNPYKyPcpL7XL1CqAZFXEzJFND0eHONwUqtdB2HhHbk= X-Received: by 10.37.45.28 with SMTP id t28mr17668ybt.200.1515081549348; Thu, 04 Jan 2018 07:59:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Thu, 4 Jan 2018 07:58:28 -0800 (PST) In-Reply-To: <1cee37b1-eef9-9b6f-97d0-09b340751015@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <8360a74c-7e8f-b23d-2bf8-879cb0d5c895@o2.pl> <495C6A3F-D05A-432F-924E-B75D7754F10D@akamai.com> <1CF1CE13-8015-4A69-9303-BEC0BF7C4860@akamai.com> <1cee37b1-eef9-9b6f-97d0-09b340751015@o2.pl> From: Eric Rescorla Date: Thu, 4 Jan 2018 07:58:28 -0800 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: "Salz, Rich" , "Kaduk, Ben" , "" Content-Type: multipart/alternative; boundary="94eb2c1b27ca8e18b70561f56950" Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:59:12 -0000 --94eb2c1b27ca8e18b70561f56950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 4, 2018 at 7:22 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 04.01.2018 o 16:00, Salz, Rich pisze: > > > >> Yes, at least in corporate environments, parental control solutions= , > etc. > > This will give a more understandable message to the user. > > > > > > But as others have pointed out, the alert is not signed by the target > origin. > > So anyone along the path can inject this alert. > Yup, just as anyone along the path can block the website. > > So browsers cannot trust it, > > and they certainly cannot display any possible text associated with it. > In the version being discussed there is no associated text. > > > > How can you distinguish valid and proper use, from not valid and > improper use > > including DoS? > Any intermediary (ISP, etc.) can block a website and this way cause a DoS= . > TLS > changes nothing in this regard. > This solution only makes it obvious that the DoS is introduced > intentionally. > > > Without that algorithm specified, I doubt any browser > > would implement this. (And IMO I doubt they will do so anyway.) > > > In the version being discussed it is just another error value. > I think browsers would implement it just like they will implement > access_denied. > Well, support for access_denied is pretty minimal. I just tested in Chrome and Firefox, and they both generate pretty much generic error pages for both access_denied and some unknown alert number. Chrome provides a pretty opaque error code (ERR_SSL_PROTOCOL_ERROR) and Firefox just provides a confusing error about how it couldn't complete the connection. -Ekr > Greetings, > Mateusz Jo=C5=84czyk > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1b27ca8e18b70561f56950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 4, 2018 at 7:22 AM, Mateusz Jo=C5=84czyk = <mat.jonczyk@o2.p= l> wrote:
>
>>=C2=A0 =C2=A0 Yes, at least in corporate environments, parental con= trol solutions, etc.
>=C2=A0 =C2=A0 =C2=A0This will give a more understandable message to the= user.
>
>
> But as others have pointed out, the alert is not signed by the target = origin.
> So anyone along the path can inject this alert.
Yup, just as anyone along the path can block the website.
> So browsers cannot trust it,
> and they certainly cannot display any possible text associated with it= .
In the version being discussed there is no associated text.
>
> How can you distinguish valid and proper use, from not valid and impro= per use
> including DoS?
Any intermediary (ISP, etc.) can block a website and this way cause = a DoS. TLS
changes nothing in this regard.
This solution only makes it obvious that the DoS is introduced intentionall= y.

> Without that algorithm specified, I doubt any browser
> would implement this.=C2=A0 (And IMO I doubt they will do so anyway.)<= br> >
In the version being discussed it is just another error value.
I think browsers would implement it just like they will implement access_de= nied.

Well, support for access_denied i= s pretty minimal. I just tested in Chrome and Firefox,
and they b= oth generate pretty much generic error pages for both access_denied
and some unknown alert number. Chrome provides a pretty opaque error cod= e
(ERR_SSL_PROTOCOL_ERROR) and Firefox just provides a confusing = error
about how it couldn't complete the connection.

-Ekr








Greetings,
Mateusz Jo=C5=84czyk

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

--94eb2c1b27ca8e18b70561f56950-- From nobody Thu Jan 4 08:39:14 2018 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 6DD07127AD4 for ; Thu, 4 Jan 2018 08:39:12 -0800 (PST) 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, FREEMAIL_FROM=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 F3Yo0VFFGFUj for ; Thu, 4 Jan 2018 08:39:10 -0800 (PST) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 3B491126B7F for ; Thu, 4 Jan 2018 08:39:10 -0800 (PST) Received: (wp-smtpd smtp.tlen.pl 14571 invoked from network); 4 Jan 2018 17:39:08 +0100 Received: from acpn5.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.219.5]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 4 Jan 2018 17:39:08 +0100 To: Stephen Farrell , Eric Rescorla References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> Cc: "" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Message-ID: <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl> Date: Thu, 4 Jan 2018 17:39:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-WP-MailID: d07ff0efae169d6d2220381975234699 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [4YMk] Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 16:39:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 04.01.2018 o 16:52, Stephen Farrell pisze: > I'm fairly sure I'm against attempting to handle captive portal issues at > the TLS layer. Any changes to TLS needed for captive portals ought really > garner consensus within the capport wg and then be discussed here. (It > looks from the archive of that wg that this topic hasn't even been raised > there despite a few people suggesting that, which is IMO another reason to > reject this proposal now.) Captive portals != filtering, these are AFAIK different problems and need mostly different solutions. I just integrated them under the same umbrella because they initially both used to seem to benefit from adding alert messages to TLS (but that idea is dead now). I am not certain whether adding captive_portal AlertDescription to TLS would be of benefit. It seems to me that possibly yes, but haven't reviewed this. > > I don't find the more-transparent-censorship argument offered convincing. > If DNS-based censorship is offered as the motivation (as opposed to or in > addition to captive portals) then I think that'd require chatting with the > dnsop folks, who are already discussing DNS-RPZ. Thanks for mentioning DNS-RPZ, I wasn't aware of it. It isn't only about DNS-based filtering, but also about blocking access to specific IPs: iptables -t nat -A OUTPUT --destination sex.com \ --jump DNAT --to-destination banned-page-server.local as well as filtering packets on the HTTPS layer without MITM (the dreaded middleboxes). > I'd guess, (but not sure as it's not my fav. idea;-), that might throw up a > requirement that censorship might only be done for a few minutes while some > previously unseen name was checked out, or a name might be censored for > days or weeks, if it's newly registered and some censor considers that a > threat. I was thinking more about filtering for sex, obscenity and such. That was my primary motivation when pushing for access_administratively_disabled. > IOW, if any changes to TLS are warranted based on DNS-based censorship, > then those are likely more complex than has been seen in this discussion, > and also aren't things where this list has the right expertise AFAIK. > > S. > Greetings, Mateusz Jończyk -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: My public key: 0x2C64C488 on hkp://pool.sks-keyservers.net Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJaTlipAAoJELLT9LcsZMSIX9YIAKHh5kcWPzSUsn6I5kIVIIna CRwvxFVL933e7h99mi7D4/mSifUsFCOAsna3YLMzBjsKgABNTivLyGU8iUuQu+B0 4tq0vxHRUnuVy4OmwJrvl2IT42rTXqUP6GAjhh1HLPoEAiDL5WlthQi7AaKkYiBu baPGCKjNZaPTT0+B+/OCp9IZW84BkcW4rwzWweynLZgDQd74CIEb2SiWqA+SAPxs OtzClEIjdnRSPhsTcwA7G1aBqStNQAhgP/O/K+FTuqK2+n6vJhwkQLGwo0B+SXlz nBVBI2MTEqx6K7ngLE/7UEibqyPIIJZ/i9H11/EAk3pJ19+IGnuXgix1zM30vqA= =GJXR -----END PGP SIGNATURE----- From nobody Thu Jan 4 08:52:07 2018 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 E9A3C12711B for ; Thu, 4 Jan 2018 08:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 FLob-O8h-ipw for ; Thu, 4 Jan 2018 08:52:02 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 8E218126B7F for ; Thu, 4 Jan 2018 08:52:02 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id w10so2581482qtb.10 for ; Thu, 04 Jan 2018 08:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EBzEFrct11xOU4Frj871KN6LuPAQhymOjcwkZNWQPE=; b=JsHpIlUpE5YfOm8FCfGvnaG7kvzSSlTX4V1ot1ByijOGCNfzRXBncPAlBYHT9OS8SI y8r2h6FJngw2d8pJM7/+L8AWSakWlC2x7jcU0EP9vx7rnJ2cSuE/XzgSF0ek/BCGivnC /2YgyOYpN9j2dJpittDrmEeEFJt1CJxquNr+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EBzEFrct11xOU4Frj871KN6LuPAQhymOjcwkZNWQPE=; b=g8cqUVi2nqER436EgRjONVMesIg+JRAP7tRMrWU5fpzkzPPvAJKlORlrX4diyHBTDf 8zcRCagjzNKTRH6hw5bjO1NnllzjX7hNpt9EfBhMy1R7fpwWaFoCoyWdNJQJXWX85fck ZqS5KYMXk4BHMmX+VrAZ2+uzwIXmneE0hkRkYboFlgbuhH8Jx7AlzVZgdmstANX6OfR8 T4L0x5fhbQXn3zZGjqEessknwFGMpKpMM2/5F4SwlINxn1XunPJ+sYVFnhKE5mJaq7jL TxMmetvt0D635+vk4vGV+pLhedmyZXvEpe0ilZ05Rr1iSuNl9fpOc/QHj2cgiz0UPZmG cxGA== X-Gm-Message-State: AKwxytc5sn4bo1BI2eLKTPx0DQ+m5eXwp33C3hbJ9+TG8V7Zq4DaFqNR YSyZCCLN4IKK/3jdDVXrirwqrbrRSmk= X-Google-Smtp-Source: ACJfBosVNvj3IE8QT3ueUmjE2mpJ72xTiwsTLWZqLd6RYiXzyhqGDW8B0FAxrw/+f7MHyTeDp1KpnQ== X-Received: by 10.200.51.3 with SMTP id t3mr260194qta.33.1515084721560; Thu, 04 Jan 2018 08:52:01 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id o64sm2217221qte.62.2018.01.04.08.52.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 08:52:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151498784861.30913.14397405953795919592@ietfa.amsl.com> Date: Thu, 4 Jan 2018 11:51:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72C80E8C-EC02-4202-B9C0-AF7E36C92E93@sn3rd.com> References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> To: "" , Kathleen Moriarty X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 16:52:06 -0000 This draft addresses the remaining outstanding issues: - text to transition for recommended Yes->No - orphaning user_mapping and cert_type This draft also addresses comments received by Ron Tse. gh repo likewise updated: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates As we discussed in Singapore, Stephen Farrell has graciously offered to = Shepherd this draft; write-up can be found at: = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shep= herdwriteup/ Kathleen is going to run the WGLC for us. Over to you Kathleen ;) spt > On Jan 3, 2018, at 08:57, 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 : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-03.txt > Pages : 16 > Date : 2018-01-03 >=20 > Abstract: > This document describes a number of changes to (D)TLS IANA = registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 3 >=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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jan 4 08:59:02 2018 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 32B02127342 for ; Thu, 4 Jan 2018 08:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 oT1YJsvAgRZ0 for ; Thu, 4 Jan 2018 08:58:58 -0800 (PST) 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 BF8B5126D3F for ; Thu, 4 Jan 2018 08:58:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 088C1BE4C; Thu, 4 Jan 2018 16:58:55 +0000 (GMT) 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 r4SSsmx2bsz2; Thu, 4 Jan 2018 16:58:53 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B800BE51; Thu, 4 Jan 2018 16:58:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515085133; bh=Pt2hu0vXPkOBC3fUiIXHzKxzXFpZ1qW1iYcScxUSCcY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bKynhY1Xk9gDsZ3Dm4D58+pKfIMo2s9XCI7KEBOUrS0XkLS+YE+mE6uoZ99Pzif+9 4YcUWtV7ltNarTfmYIzaw76Js/eCgYYSe1c0Bsn8o7ku2f0+kNPn/ZuuBfIp7n3SkV HHUAhGqnAK/XY3QXDBj3wSPFRhygxqsgLTxh25mU= To: Sean Turner , "" , Kathleen Moriarty References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <72C80E8C-EC02-4202-B9C0-AF7E36C92E93@sn3rd.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <4ac67317-bf49-7437-7133-67c110b09e96@cs.tcd.ie> Date: Thu, 4 Jan 2018 16:58:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <72C80E8C-EC02-4202-B9C0-AF7E36C92E93@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d3YDkPplIXu62RUlPxvixohtIHvbKWYgl" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 16:59:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d3YDkPplIXu62RUlPxvixohtIHvbKWYgl Content-Type: multipart/mixed; boundary="k520hnror1H567XoVOWZJSrU8nINJVPek"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , "" , Kathleen Moriarty Message-ID: <4ac67317-bf49-7437-7133-67c110b09e96@cs.tcd.ie> Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-03.txt References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <72C80E8C-EC02-4202-B9C0-AF7E36C92E93@sn3rd.com> In-Reply-To: <72C80E8C-EC02-4202-B9C0-AF7E36C92E93@sn3rd.com> --k520hnror1H567XoVOWZJSrU8nINJVPek Content-Type: multipart/mixed; boundary="------------297E8ED5E467789A87C7D7A0" Content-Language: en-GB This is a multi-part message in MIME format. --------------297E8ED5E467789A87C7D7A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/18 16:51, Sean Turner wrote: >=20 > As we discussed in Singapore, Stephen Farrell has graciously offered to= Shepherd this draft; write-up can be found at: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/s= hepherdwriteup/ Gracious? Me? Well, I guess given the time of year it's ok to pretend:-) For those good at identifying folks based on writing style, you'll quickly detect that Sean did the initial write-up and I just did some edits. (Thanks Sean:-) I do however fully agree with the content and did re-read the draft etc. And I'm also convinced this is ready to go. Cheers, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------297E8ED5E467789A87C7D7A0 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------297E8ED5E467789A87C7D7A0-- --k520hnror1H567XoVOWZJSrU8nINJVPek-- --d3YDkPplIXu62RUlPxvixohtIHvbKWYgl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIbBAEBCAAGBQJaTl1MAAoJEFqy+vF7Fyvq8k8P+J93fmeoScne9vUAGbPQIkpq BZ8TChsPv3+9uYgxYqzLoHPCsDCceY0gl9Adnm+n//iihwXzp6mUDPtyZpxHhzc5 +D/b3NjZLrMjlFl2C4JZZmp3Ct5/wm/Lcc6tapf177SqUoJjiAMpEu/2pz3o+1vw fNHCLM6WDLrdz8k0tUYw/JeqnEqaotHq2iEgzVR7M/X8iDPMGla4gMGkaUz5TNB5 pIpG4LA9diSZ1u/g5pgKI1vUmY3cPs32ocERxndQmYmPiccO9DEwmtiuhkNzcuXk 42wSRJGYNXp/l4G7IVUNU4Pj8982QkIft2LkH8EeEy6j93CESMuyAujLnAkKiLPt xygcQvFyGj+EDst27xBsn3fgb1BDULGAv7y0iKGaZe5BVmNlyL1w+b8Oo8U1+7wV 0gW9mZX44RtX4UFXqQ2cqFHJgjJidOrOhHtOlOb+5zwvjjbpomrXRx7JDxZVLfhN zAUYu7M8tyT310A4GaHGeiEGjRo6w5z1zClbCWzW7DAeDpbYmIJ0diLUrSAfMcxK CYLBCLzjr9daSLmeBif8NoOAXKxItx35/93sJOnfLewlgoFDxWIUBvFecz+giUsa IQX7tlRo+VcuJQLVH0et/T9GkR7Paewm4ZdBhxmkeYOMhvD8qeQPuef+W05bw5H8 0d0W0DAtdtf7mC9VxzI= =8NzP -----END PGP SIGNATURE----- --d3YDkPplIXu62RUlPxvixohtIHvbKWYgl-- From nobody Thu Jan 4 11:01:13 2018 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 292D71275C5 for ; Thu, 4 Jan 2018 11:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 RkJsnWqBYF7A for ; Thu, 4 Jan 2018 11:01:05 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 2BA8F1241FC for ; Thu, 4 Jan 2018 11:01:05 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id w128so944855ywa.1 for ; Thu, 04 Jan 2018 11:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zZsBWjW9H90Kk4uP9ahJDo35szV4b8NUHSTdxmSnwNI=; b=LtviApQBMXmDMqmK3gpYH4IyMed6ETrMxKMYWuHeBYc9D2K9AYAWoPb614owg9qF+Y k142wuxkVJJ5hI0zGMD3V05nkln/cLfhNmSLnl4bBZNGwdUAO0V5SMRQug/9Z85Rr5la F5UttaGWaiI7bKLq8xLrenedcue/Pd0XzpYwkKB7v4JpL+meInQF7vG/oPJaCA1ucHFA jsZFRkoWIlyJ/VdpFiVDos8ADCG7jG93OMN35FgrJT0AO0UFded3Yq3bhGLka1+u9dzh BIjqlF2hS1gBkq0i6+qxiL0wJ5SVWvi40YlGAchnr+LdEAWrAKfqLWpz9XY5F5hHgcrn XrCA== 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:references:from:date :message-id:subject:to:cc; bh=zZsBWjW9H90Kk4uP9ahJDo35szV4b8NUHSTdxmSnwNI=; b=FnD2deHIHa2OihGMlPYTN6ETRbIV0AI/TwyrQB335htyyIjCZ9j/NPCiNbe4HUk02A AvudsbwNjTHVMOClqwoB8wSxhQYWadOMe3qy8cbS+n12U/OC7ypqY8brFV1Hy6iBmjsz LX3dEi/gzWrSsgZUWJocaUuI7Qs3SRAaGD7mfP5mf0N0ZbZd6EOvyUtq3tYDr8V30jCV 3a2elVx5tZynT5kFxPwkZB1OklnMEbD7u1nLD81yroKkwI0GDIA/zUVONJ+8TlKNPx44 /kiI8l1IViVic8mv1YNAZSC2hnTylouM3rahmTiaGytuXinsVia2D8zZymdoRgqCdEli r6ag== X-Gm-Message-State: AKGB3mLrOoJ4IR7Yo2TBUeEjF/mGuNU2YW78ARfmBz0RJWkjgALCAPbE TDUbMqiUGVOJ7ssP9qthrAMneMSi3k66t737Y8kAmA== X-Google-Smtp-Source: ACJfBosTnrSpgAVsPocwhMqQnCTSnX7+14PrhY58Dogsi7TgmRHU/ADBEr3vRvWfTOcqsgQa/bTRpOGu94sho1Y2EEQ= X-Received: by 10.129.154.22 with SMTP id r22mr527838ywg.418.1515092464069; Thu, 04 Jan 2018 11:01:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.70 with HTTP; Thu, 4 Jan 2018 11:01:03 -0800 (PST) In-Reply-To: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com> References: <3291250.UCJXXru3mW@pintsize.usersys.redhat.com> <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 4 Jan 2018 11:01:03 -0800 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0bb4e81f86370561f7f4d3" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 19:01:12 -0000 --94eb2c0bb4e81f86370561f7f4d3 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario wrote: > > No, I strongly disagree here. Firstly, frustrating attackers is a good > > definition of what the goal of security is. Some times increasing costs > for > > attackers does come at the cost of making things harder to analyze or > debug, > > but we shouldn't make the latter easier at the expense of the former. > > No, the goal of security is to stop attacks from being successful, not > make them harder. Making attack harder is security through obscurity. > Something that definitely doesn't work for open source software. > Unless you're shipping one-time-pads around, cryptography is founded on making successful attacks highly improbable, but not impossible. There are measures of likelihood of key and plaintext recovery for all of the established algorithms. The delay approach is no different, and risk can be expressed in mathematical ways. The numbers are lower, for sure, delays can add a security factor of maybe up to 2^40, but that's still very very effective and unlike encryption or hashes, do not have to withstand longterm attacks. This bears repeating: attempting to make OpenSSL rigorously constant time made it *less* secure. The LuckyMinus20 bug was much worse than the Lucky13 bug the code was trying to fix. It would have been better to leave it un-patched (at least for TLS, maybe not DTLS). A delay in the error case on the other hand, would have made either issue un-exploitable in the real world. Evaluating that trade-off takes a lots of "grey area" analysis though; one has to have a sense of judgement for how much risk a complex code change is "worth", being mindful that complex code changes come with their own risks. honestly, I consider this approach completely misguided. If you are OK with > tying up a socket for 30 seconds, simply start a timer once you get the > original client hello (or the first message of second flight, in TLS 1.2), > close the socket if the handshake is not successful in 30 seconds. In case > of errors, send nothing, let it timeout. The only reason why this approach > to constant time error handling is not used is because most people are not > ok with tying up resources for so long. > This is real code we use in production; thankfully errors are very uncommon, but connections also cost very little, in part due to work done for DDOS and trickle attacks, a different kind of security problem. Delaying to a fixed interval is a great approach, and emulates how clocking protects hardware implementations, but I haven't yet been able to succeed in making it reliable. It's easy to start a timer when the connection is accepted and to trigger the error 30 seconds after that, but it's hard to rule out that a leaky timing side-channel may influence the subsequent timing of the interrupt or scheduler systems and hence exactly when the trigger happens. If it does influence it, then a relatively clear signal shows up again, just offset by 30 seconds, which is no use. -- Colm --94eb2c0bb4e81f86370561f7f4d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
&g= t; No, I strongly disagree here. Firstly, frustrating attackers is a good > definition of what the goal of security is. Some times increasing cost= s for
> attackers does come at the cost of making things harder to analyze or = debug,
> but we shouldn't make the latter easier at the expense of the form= er.

No, the goal of security is to stop attacks from being successf= ul, not make them harder. Making attack harder is security through obscurit= y. Something that definitely doesn't work for open source software.
=

Unless you're shipping one-time-pads a= round, cryptography is founded on making successful attacks highly improbab= le, but not impossible. There are measures of likelihood of key and plainte= xt recovery for all of the established algorithms. The delay approach is no= different, and risk can be expressed in mathematical ways.=C2=A0 The numbe= rs are lower, for sure, delays can add a security factor of maybe up to 2^4= 0, but that's still very very effective and unlike encryption or hashes= , do not have to withstand longterm attacks.

This = bears repeating: attempting to make OpenSSL rigorously constant time made i= t *less* secure. The LuckyMinus20 bug was much worse than the Lucky13 bug t= he code was trying to fix. It would have been better to leave it un-patched= (at least for TLS, maybe not DTLS). A delay in the error case on the other= hand, would have made either issue un-exploitable in the real world. Evalu= ating that trade-off takes a lots of "grey area" analysis though;= one has to have a sense of judgement for how much risk a complex code chan= ge is "worth", being mindful that complex code changes come with = their own risks.=C2=A0

h= onestly, I consider this approach completely misguided. If you are OK with = tying up a socket for 30 seconds, simply start a timer once you get the ori= ginal client hello (or the first message of second flight, in TLS 1.2), clo= se the socket if the handshake is not successful in 30 seconds. In case of = errors, send nothing, let it timeout. The only reason why this approach to = constant time error handling is not used is because most people are not ok = with tying up resources for so long.

Th= is is real code we use in production; thankfully errors are very uncommon, = but connections also cost very little, in part due to work done for DDOS an= d trickle attacks, a different kind of security problem.=C2=A0
Delaying to a fixed interval is a great approach, and emulates= how clocking protects hardware implementations, but I haven't yet been= able to succeed in making it reliable. It's easy to start a timer when= the connection is accepted and to trigger the error 30 seconds after that,= but it's hard to rule out that a leaky timing side-channel may influen= ce the subsequent timing of the interrupt or scheduler systems and hence ex= actly when the trigger happens. If it does influence it, then a relatively = clear signal shows up again, just offset by 30 seconds, which is no use.

--
Colm
--94eb2c0bb4e81f86370561f7f4d3-- From nobody Thu Jan 4 14:29:23 2018 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 0710F126D85 for ; Thu, 4 Jan 2018 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HCat9tSpVsJn for ; Thu, 4 Jan 2018 14:29:13 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 3545F126FB3 for ; Thu, 4 Jan 2018 14:29:13 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id r63so2021003oia.6 for ; Thu, 04 Jan 2018 14:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BLB6WWTEMEub1V3nDBqdSDPlsl9jzTCOnVaay1gOvI8=; b=ewsfmYg1KZSHbiYnaTu8Pl62O4Z9CyYdFUtwKXNKI+GGNQSuURLnAD7G/8BJCv+juJ oo+35lfaA0ukt+MU7e3eczCoI2nh/qLJe4R/OI5fiCGTbnarN4Zp6jasdIn5zOc+n6J3 QqF/DYVjuXoRShFd3POL0Gvm7fMD3Jz3NJPa6AS5uNrYn3hyaVUdE86MGmzdAw30fWFk yZIR/BAthU6KRJhhka+cnYwleqq4vVx/2nzUyg4XcbU63eA1tY1/ZZ4tg9MGHOtJGlNh 32g1SmwYfMGiX5vrlHu9F5wXwsh8Xwau0nfK55j0g5utWmgPCmd1oH9+XbajVMjkK60w lTkw== 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:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BLB6WWTEMEub1V3nDBqdSDPlsl9jzTCOnVaay1gOvI8=; b=lS8j2OoKUOz27hm9eYGjuznMhOJWofGOst1AMXTKDVMtqVr2DcrLvwzyFpJDrk/sli NVfdbarlakGne+bLvKjogllOvRVYYwCPP5GXG8zEJ+h3BtVFs8W7gMgZqnbk39katxlT kwbnQRnZptpDqoLhVkVGWp+jWh45vH/uAs6xNsZqbpeRXGPyaz88CCB+T5PV4HK+0ZCJ gIkkopnGJv/QlEDNdDLdTbJKIDNqjYsNHrDMV7B60MTZ6STsOB86YqlX6phQGAGCSAn3 pLUT28kSUscHm6OZ6Hd3/41fon9K9d85vsbrTQTpuivoA8+cqgC9pq2Ge8f216+e4RgW Bi7Q== X-Gm-Message-State: AKGB3mLCJayf37uC6hBuWR1NcbtFBmf/0ti6dxT7uAqK9cgBeFL4lJ61 un5RDyECMl7OpPmTyxPcks5T3lQ3LTXAWuWRxxc= X-Google-Smtp-Source: ACJfBov9TyQFf3kef01OX5xtbsYtU5KuO4R4phVhOD6uc9IQCRODB+qbV5ppnUFZYmJNitXslqMW5nXl0bjqVx1Oc6I= X-Received: by 10.202.232.21 with SMTP id f21mr624744oih.50.1515104952448; Thu, 04 Jan 2018 14:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.7.110 with HTTP; Thu, 4 Jan 2018 14:29:11 -0800 (PST) In-Reply-To: <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl> From: Martin Thomson Date: Fri, 5 Jan 2018 09:29:11 +1100 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Stephen Farrell , Eric Rescorla , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 22:29:21 -0000 On Fri, Jan 5, 2018 at 3:39 AM, Mateusz Jo=C5=84czyk wr= ote: > W dniu 04.01.2018 o 16:52, Stephen Farrell pisze: >> I'm fairly sure I'm against attempting to handle captive portal issues a= t >> the TLS layer. Any changes to TLS needed for captive portals ought reall= y >> garner consensus within the capport wg and then be discussed here. (It >> looks from the archive of that wg that this topic hasn't even been raise= d >> there despite a few people suggesting that, which is IMO another reason = to >> reject this proposal now.) > > Captive portals !=3D filtering, these are AFAIK different problems and ne= ed > mostly different solutions. I just integrated them under the same umbrell= a > because they initially both used to seem to benefit from adding alert mes= sages > to TLS (but that idea is dead now). > > I am not certain whether adding captive_portal AlertDescription to TLS wo= uld > be of benefit. It seems to me that possibly yes, but haven't reviewed thi= s. Please take that discussion to the capport WG (captive-portals@ietf.org). However, it seems like you want to address filtering/censorship more than you want to address the captive portal case. I can say that the capport WG isn't interested in anything that might improve filtering or censorship and are explicitly designing mechanisms that avoid doing so. I won't say that you can't raise the issue, but you should be aware that this topic has been discussed quite a bit already and unless you have new information, I doubt you will change the conclusions. From nobody Fri Jan 5 06:33:45 2018 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 B79EE129C5D for ; Fri, 5 Jan 2018 06:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 AzTU8dnd8tzg for ; Fri, 5 Jan 2018 06:33:41 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 8A335124217 for ; Fri, 5 Jan 2018 06:33:41 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id a8so6109445qkb.8 for ; Fri, 05 Jan 2018 06:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P2ljP+ek8x7d//96CCzw3q7ew1EFYIK9ciW6K/zvGqI=; b=LfuOukDme6j8KfNN8nHvUOmYIsUb1vE5J1XwcVObigPGy/V6P2cKoN7RUEi83Zhwn5 kYNnXj8lHBOC9gFyCV4fxKOOAIPEsOaUnBa+a/0oEpYGrEGtrxMIEt5SvvwhBOjZp4Tf AIsUby7k1Kt+xcrLoQ4gokrYl+cS0Y+CNMwGY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P2ljP+ek8x7d//96CCzw3q7ew1EFYIK9ciW6K/zvGqI=; b=OuK9uS09OdnMdNJp+DmY73JagLndheXT+qQ9QVTTPqt7rHselBa8TZfb5jUz5EsR4s o2cqP3UifGIGLlzubR+BLOdoXjmmnJtZkdX8mP/RHG/W+On30mUhkfSiCLjFdigorlCM 8qGbMgdwOaQxyiuSh2+UXC+0mUPCifJEcCy6swkQtoSwPYL1iqu7rVzicP+WQXDz9QpC B6SBjO1s6kUvVtKYzxlpObw6+42nepj1URtJU4Q3JyPdXn1YU6Nk4t2LAIkEsBu288xZ u7HVYjQ8HJijEu0gCNtTbRk9ulha1Gsci/JVVVEJL96hLbX+qW99XPfo5B9Yp22XxHG0 GTjw== X-Gm-Message-State: AKwxytdCnLsnuheOjjkbZ+80vGGmR1B7y7mCjYWEgheelaOEtDzk4RWl dUnmJ72sqanDeyc49XB6d86O5g== X-Google-Smtp-Source: ACJfBotLyFiAL9I0Hxvn1hJVUtVNcCgtFE7FKMhK1czxSiUXzHB4GQ4Hk/s73lFfQPXCymRfy7kQsQ== X-Received: by 10.55.142.66 with SMTP id q63mr4530777qkd.346.1515162820482; Fri, 05 Jan 2018 06:33:40 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id g9sm3596120qtg.2.2018.01.05.06.33.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 06:33:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Fri, 5 Jan 2018 09:33:37 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <7AB77AD3-0739-4E02-8568-B74167A834CB@sn3rd.com> References: <60555d44-340d-8aa7-eb45-3a23b758e5d2@o2.pl> <3685a850-03ec-5162-414b-c2676022d661@o2.pl> <5afdbc7f-30bb-4de2-6a72-588b8edc55d8@akamai.com> <235782bf-c26b-12c4-391a-26b654a8b9af@o2.pl> <384cbf47-e41d-9372-c8b4-ba9b5788fdbe@cs.tcd.ie> <6c2052fc-a43a-10e3-d6c6-0a212d17b5ed@o2.pl> To: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] access_administratively_disabled v2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 14:33:44 -0000 Mateusz, It appears that the way forward is to document the mechanism you have in = mind in an Internet-Draft. That I-D should include the mechanism as = well as the new alert you want.* It is better that the alert be in a = separate I-D (i.e., not in the TLS 1.3 specification) because including = an alert in the TLS 1.3 draft that refers to a yet-to-be standardized = mechanism is pretty much not going to work with the IETF publication = process; we are near the finish line for TLS 1.3 and having a reference = of this sort will no doubt add some delay possibly a lot of delay.** The other issue here is that there is an existing WG chartered (capport) = to work on this particular problem or some part of it; the TLS WG would = be stepping on their toes if we picked up the work. For the two reasons listed above, I=E2=80=99m asking ekr to close the = PR#1134. spt * Please do not include a value for the alert use "(TBD)". ** The reference would be a normative reference to another specification = that was not at the same =E2=80=9Cmaturity" level. The TLS 1.3 = specification would have to wait while this new I-D gets to the same = maturity - but there=E2=80=99s no guarantee that the I-D will in fact = get to the same maturity level. > On Jan 4, 2018, at 17:29, Martin Thomson = wrote: >=20 > On Fri, Jan 5, 2018 at 3:39 AM, Mateusz Jo=C5=84czyk = wrote: >> W dniu 04.01.2018 o 16:52, Stephen Farrell pisze: >>> I'm fairly sure I'm against attempting to handle captive portal = issues at >>> the TLS layer. Any changes to TLS needed for captive portals ought = really >>> garner consensus within the capport wg and then be discussed here. = (It >>> looks from the archive of that wg that this topic hasn't even been = raised >>> there despite a few people suggesting that, which is IMO another = reason to >>> reject this proposal now.) >>=20 >> Captive portals !=3D filtering, these are AFAIK different problems = and need >> mostly different solutions. I just integrated them under the same = umbrella >> because they initially both used to seem to benefit from adding alert = messages >> to TLS (but that idea is dead now). >>=20 >> I am not certain whether adding captive_portal AlertDescription to = TLS would >> be of benefit. It seems to me that possibly yes, but haven't reviewed = this. >=20 > Please take that discussion to the capport WG = (captive-portals@ietf.org). >=20 > However, it seems like you want to address filtering/censorship more > than you want to address the captive portal case. I can say that the > capport WG isn't interested in anything that might improve filtering > or censorship and are explicitly designing mechanisms that avoid doing > so. I won't say that you can't raise the issue, but you should be > aware that this topic has been discussed quite a bit already and > unless you have new information, I doubt you will change the > conclusions. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jan 5 14:02:20 2018 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 6E1A4120227; Fri, 5 Jan 2018 14:02:14 -0800 (PST) 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: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151518973440.32411.5552831558342067093@ietfa.amsl.com> Date: Fri, 05 Jan 2018 14:02:14 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-23.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 22:02:14 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-23.txt Pages : 154 Date : 2018-01-05 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-23 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-23 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 Jan 8 04:29:37 2018 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 1806A12778E for ; Mon, 8 Jan 2018 04:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c18gs0EUqvny for ; Mon, 8 Jan 2018 04:29:34 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54671243FE for ; Mon, 8 Jan 2018 04:29:34 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 09EA54667D; Mon, 8 Jan 2018 12:29:34 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-24.brq.redhat.com [10.40.200.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81C685C1A1; Mon, 8 Jan 2018 12:29:33 +0000 (UTC) From: Hubert Kario To: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= Cc: tls@ietf.org Date: Mon, 08 Jan 2018 13:29:26 +0100 Message-ID: <2864671.ZroJSGrFQg@pintsize.usersys.redhat.com> In-Reply-To: References: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart168384795.TJ92X92gWc"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 08 Jan 2018 12:29:34 +0000 (UTC) Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 12:29:37 -0000 --nextPart168384795.TJ92X92gWc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 4 January 2018 20:01:03 CET Colm MacC=C3=A1rthaigh wrote: > On Thu, Jan 4, 2018 at 4:17 AM, Hubert Kario wrote: > > > No, I strongly disagree here. Firstly, frustrating attackers is a good > > > definition of what the goal of security is. Some times increasing cos= ts > >=20 > > for > >=20 > > > attackers does come at the cost of making things harder to analyze or > >=20 > > debug, > >=20 > > > but we shouldn't make the latter easier at the expense of the former. > >=20 > > No, the goal of security is to stop attacks from being successful, not > > make them harder. Making attack harder is security through obscurity. > > Something that definitely doesn't work for open source software. >=20 > Unless you're shipping one-time-pads around, cryptography is founded on > making successful attacks highly improbable, but not impossible. There are > measures of likelihood of key and plaintext recovery for all of the > established algorithms. The delay approach is no different, and risk can = be > expressed in mathematical ways. The numbers are lower, for sure, delays > can add a security factor of maybe up to 2^40, but that's still very very > effective and unlike encryption or hashes, do not have to withstand > longterm attacks. except that what we call "sufficiently hard plaintext recovery" is over tri= ple=20 of the security margin you're proposing as a workaround here 2^40 is doable on a smartphone, now 2^120 is not doable on a supercomputer, and won't be for a very long time =20 > This bears repeating: attempting to make OpenSSL rigorously constant time > made it *less* secure. yes, on one specific hardware type, because of a bug in implementation I really hope you're not suggesting "we shouldn't ever build bridges becaus= e=20 this one collapsed"... also, for how long was it *less* secure? and for how long was it vulnerable= to=20 Lucky13? > The LuckyMinus20 bug was much worse than the Lucky13 > bug the code was trying to fix. It would have been better to leave it > un-patched (at least for TLS, maybe not DTLS). A delay in the error case = on > the other hand, would have made either issue un-exploitable in the real > world.=20 I'm sorry, you're saying that you're able to prove a negative? Or to put it other way: "Anyone can invent a security system that he himsel= f=20 cannot break." > Evaluating that trade-off takes a lots of "grey area" analysis > though; one has to have a sense of judgement for how much risk a complex > code change is "worth", being mindful that complex code changes come with > their own risks. "we shouldn't fix it because it's not completely broken" is how we get=20 million+ strong botnets of systems that never got updated and any issue with known exploit needs to be fixed =20 > > honestly, I consider this approach completely misguided. If you are OK > > with > > tying up a socket for 30 seconds, simply start a timer once you get the > > original client hello (or the first message of second flight, in TLS 1.= 2), > > close the socket if the handshake is not successful in 30 seconds. In c= ase > > of errors, send nothing, let it timeout. The only reason why this appro= ach > > to constant time error handling is not used is because most people are = not > > ok with tying up resources for so long. >=20 > This is real code we use in production; thankfully errors are very > uncommon, but connections also cost very little, in part due to work done > for DDOS and trickle attacks, a different kind of security problem. >=20 > Delaying to a fixed interval is a great approach, and emulates how clocki= ng > protects hardware implementations, but I haven't yet been able to succeed > in making it reliable. It's easy to start a timer when the connection is > accepted and to trigger the error 30 seconds after that, but it's hard to > rule out that a leaky timing side-channel may influence the subsequent > timing of the interrupt or scheduler systems and hence exactly when the > trigger happens. If it does influence it, then a relatively clear signal > shows up again, just offset by 30 seconds, which is no use. *if* in other words, this solution _may_ leak information (something which you c= an=20 actually test), or the other solution that _does_ leak information, just=20 slowly so it's "acceptable risk" =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart168384795.TJ92X92gWc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpTZCYACgkQkqjRuAHS 9fXN0w/8C0UcPNAvH8qRcelnTFIni11wCBhZ/OvvejVrcgnVe2m0eOw8eNKip0Z1 /g3y6wAOeLqj+MtCC4PoT7zLqlbyYFFXdBCJNx0pmMZ0xXi9IxHoR3C3bU9IrRHM cQrmlvxpKxq7d6Lw1u1ygQC96jEW8nyAW1UcaWDkajjWCyeH1ZO3U6ymdYiOa/U2 zfYcTwBDMaPlZxnackse2uF/UujjQyMp7ae73yh9KYmINMD/L7FWDqmFEffjWuOk O69TtMOEWvJVv/odMwlDXOPcOVzN6zje47CpCn5KUqyfEStBzJqAJzVY00fhq3ys gpXsLxn3spAMf8ME7Qj0bEY0KkGO8i+XGON4VH9cf08FivBxhTaJMHETd5coKegO BbbEv2T8jG1f6MYbeGAprbrtCYfZwxOwcjyvOWrOKoi2uDNl/JWTx1igUHqjI9la 413whQQ2vU16ek34UJ2g1XAVJNFXpaPiZtvGsLPuqhNlcQYy+V51TycEwxK5zqDS 0r1Vnb7noN6HkAXRmXXX8vwuT/aqAVQsRJVlfBuK5HRMKwJgUpxppHx/wPSwk3JU pQDwL6sxAV6TKM5t5s0s4mkK8Wgvyck5CvYCs8c2Zcp5p56qtFUPSUwZAPdC1M+C XtY9qEUKjLqsnJmmDSxuOqGSa9RPmvKL8l10kO6CZ+X988OscWY= =2Xue -----END PGP SIGNATURE----- --nextPart168384795.TJ92X92gWc-- From nobody Mon Jan 8 07:45:39 2018 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 70C4B126579 for ; Mon, 8 Jan 2018 07:45:37 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 wQddLYpQNbBQ for ; Mon, 8 Jan 2018 07:45:35 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 E0FF8126C25 for ; Mon, 8 Jan 2018 07:45:34 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id z132so4439098ywd.9 for ; Mon, 08 Jan 2018 07:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PaCsAiC7IkTVsPF3m43+cetpR/DNOisNDe2l3KiGJZ8=; b=auSBbkJnWC0fHQAAVf5JuX6z3ZAvzi6p3ioNMvxTDa8W/mTBb5+7ZBxdwKPpIRVO71 QcYmigMxjhPMq1nzIGp9kU1Gfn9R2GnwxCskL7QVexzvMx48NCtMUbp26Gzf/u+FvCiq 1zlD2jadL8GCcnCs4GC0afy/PP6vmmOCg1dUe/LXWP7Zd9XBJOroMJc0SkBVmH092bwg VBr6gkucsBF3jP4FJCW2l1i/iP6OIiPUJ1ca6frkoSCjFug8Cv6DB+jCgPFzCI+gMals JKLbBJXSHwnEzjZsEucLv/Bs34138awWjLZlgpVXizcs+Y1ZZISkUW1Gnxe0ggtkGHH5 wClw== 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:references:from:date :message-id:subject:to:cc; bh=PaCsAiC7IkTVsPF3m43+cetpR/DNOisNDe2l3KiGJZ8=; b=bUJWNrP/COrxJJLfGvSCTmWiJeWlx8qktbObb4j4M2zyXI6GQelXGnJeLzZdlVmmg4 pWBN/i9UymcTKtANA7nbjLWZLPmJ+AF5EsrPFBB6hO4atWpOjqyBdlyPwv1aWdxXNqga avjANIRKQknbsHnwcxysqT1lfZCRSUKlEFzXqS+SbfQnMykvcXORcRq+BjmQDc4L/XvB ozyywG5otaib/zyhTvkqthNV9Ybz1ptgJzi6WQ/m6ab9GNlejTiY+g/k5hvDYYSlUWxr 2bjxdDlX/Rnx1yG4lai507BoxuwmfOiTwztFkTt4rDoDm6lvl/9hEN2zx/iEKP5+BRQy qFjg== X-Gm-Message-State: AKGB3mJ+ngM9GJAxQcXBXCBgtv/q6bGB/lX6lQwIclnZgfCk67dc7TyG hqaS/LmelBQ79kCnA2l54PvviiQFqC+7yxEQY8dQzQ== X-Google-Smtp-Source: ACJfBosUvOCMdcAdotXUPqZmbsxshgdtPp+05ssVrWin4EI5wSUTjav6L5s5KG4R182n/BKEHs8Pp3Zpc+q41b6Z80o= X-Received: by 10.129.124.67 with SMTP id x64mr6497852ywc.418.1515426333964; Mon, 08 Jan 2018 07:45:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.42.6 with HTTP; Mon, 8 Jan 2018 07:45:32 -0800 (PST) In-Reply-To: <2864671.ZroJSGrFQg@pintsize.usersys.redhat.com> References: <323483915.3215386.1515068250003.JavaMail.zimbra@redhat.com> <2864671.ZroJSGrFQg@pintsize.usersys.redhat.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 8 Jan 2018 09:45:32 -0600 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="001a1149459651d464056245b0e9" Archived-At: Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 15:45:37 -0000 --001a1149459651d464056245b0e9 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 8, 2018 at 6:29 AM, Hubert Kario wrote: > > except that what we call "sufficiently hard plaintext recovery" is over > triple > of the security margin you're proposing as a workaround here > > 2^40 is doable on a smartphone, now > 2^120 is not doable on a supercomputer, and won't be for a very long time > This isn't how these kinds of attacks work. 2^40 would be small for something that could be attacked in parallel by a very large computing system. But it's an absolutely massive difficulty factor against a live on-line attack. Can you propose a credible mechanism where an attacker would be able to mount say billions (to use the low end) of repeated connections, without detection? And that's before they wean the signal out. And since the delay can't be avoided, the attack also costs thousands of years of attacker-controlled computer time. I have much much more confidence in that simple kind of defense giving me real-world security than I do in my code being absolutely perfect, which I've never achieved. I'm being stubborn and replying here because I want to argue against a common set of biases I've seen that I think are harmful to real-world security, Making attacks billions to trillions of times harder absolutely does protect real-world users, and we shouldn't be biasing simply for what we think the research community will take seriously or not scoff at, but for what will actually protect users. Those aren't the same. I'll give another example: over the last few years we have significantly *regressed* on the real-world security of TLS by moving to AES-GCM and ChaCha20. Both of their cipher suites leak the exact content-length and make content-fingerprinting attacks far easier than they were previously (CBC blocks made this kind attack exponentially more expensive). The current state is that passive tappers with relatively unsophisticated databases can de-cloak a high percent of HTTPS connections. This compromises secrecy, the main user benefit of TLS. That is staggering me, but it's also an uninteresting attack to the research community, it's long known about and isn't going to result in much publication or research grants. > > This bears repeating: attempting to make OpenSSL rigorously constant time > > made it *less* secure. > > yes, on one specific hardware type, because of a bug in implementation > > I really hope you're not suggesting "we shouldn't ever build bridges > because > this one collapsed"... > > also, for how long was it *less* secure? and for how long was it > vulnerable to > Lucky13? I'm saying that trade-offs are complicated and that constant-time "rigor" isn't worth it sometimes. Adding ~500 lines of hard-to-follow hard-to-maintain code with no systematic way to confirm that it stays correct was a mistake and it led to a worse bug. Other implementations chose more simple approaches; code-balancing, that were close-to-constant-time but not rigorously so. I think the latter was ultimately smarter, all code is dangerous because bugs can be lurking in its midst, and those bugs can be really really serious like memory disclosure and remote execution, so leaning towards simple and easy to follow should be heavily weighted. So when we see the next bug like Lucky13, which was un-exploitable against TLS, but still publishable and research-worthy, we should lean towards simpler fixes rather than complex ones, while also just abandoning whatever algorithm is effected and replacing it. > > Delaying to a fixed interval is a great approach, and emulates how > clocking > > protects hardware implementations, but I haven't yet been able to succeed > > in making it reliable. It's easy to start a timer when the connection is > > accepted and to trigger the error 30 seconds after that, but it's hard to > > rule out that a leaky timing side-channel may influence the subsequent > > timing of the interrupt or scheduler systems and hence exactly when the > > trigger happens. If it does influence it, then a relatively clear signal > > shows up again, just offset by 30 seconds, which is no use. > > *if* > > in other words, this solution _may_ leak information (something which you > can > actually test), or the other solution that _does_ leak information, just > slowly so it's "acceptable risk" > Sorry, I'll try to be more clear: A leak in a fixed-interval delay would be catastrophic, because it will result in a very clean signal, merely offset by the delay. A leak in a random-interval delay will still benefit from the random distribution and require many samples. -- Colm --001a1149459651d464056245b0e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 8, 2018 at 6:29 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
except that what we call &quo= t;sufficiently hard plaintext recovery" is over triple
of the security margin you're proposing as a workaround here

2^40 is doable on a smartphone, now
2^120 is not doable on a supercomputer, and won't be for a very long ti= me

This isn't how these kinds of at= tacks work. 2^40 would be small for something that could be attacked in par= allel by a very large computing system. But it's an absolutely massive = difficulty factor against a live on-line attack. Can you propose a credible= mechanism where an attacker would be able to mount say billions (to use th= e low end) of repeated connections, without detection? And that's befor= e they wean the signal out. And since the delay can't be avoided, the a= ttack also costs thousands of years of attacker-controlled computer time.= =C2=A0 I have much much more confidence in that simple kind of defense givi= ng me real-world security than I do in my code being absolutely perfect, wh= ich I've never achieved.=C2=A0

I'm being s= tubborn and replying here because I want to argue against a common set of b= iases I've seen that I think are harmful to real-world security, Making= attacks billions to trillions of times harder absolutely does protect real= -world users, and we shouldn't be biasing simply for what we think the = research community will take seriously or not scoff at, but for what will a= ctually protect users.=C2=A0 Those aren't the same.

I'll give another example: over the last few years we have signif= icantly *regressed* on the real-world security of TLS by moving to AES-GCM = and ChaCha20. Both of their cipher suites leak the exact content-length and= make content-fingerprinting attacks far easier than they were previously (= CBC blocks made this kind attack exponentially more expensive). The current= state is that passive tappers with relatively unsophisticated databases ca= n de-cloak a high percent of HTTPS connections. This compromises secrecy, t= he main user benefit of TLS. That is staggering me, but it's also an un= interesting attack to the research community, it's long known about and= isn't going to result in much publication or research grants.=C2=A0

=C2=A0
> This bears repeating: attempting to make OpenSSL rigorously constant t= ime
> made it *less* secure.

yes, on one specific hardware type, because of a bug in implementati= on

I really hope you're not suggesting "we shouldn't ever build b= ridges because
this one collapsed"...

also, for how long was it *less* secure? and for how long was it vulnerable= to
Lucky13?

I'm saying that trade-offs are= complicated and that constant-time "rigor" isn't worth it so= metimes. Adding ~500 lines of hard-to-follow hard-to-maintain code with no = systematic way to confirm that it stays correct was a mistake and it led to= a worse bug. Other implementations chose more simple approaches; code-bala= ncing, that were close-to-constant-time but not rigorously so.=C2=A0 I thin= k the latter was ultimately smarter, all code is dangerous because bugs can= be lurking in its midst, and those bugs can be really really serious like = memory disclosure and remote execution, so leaning towards simple and easy = to follow should be heavily weighted.=C2=A0 So when we see the next bug lik= e Lucky13, which was un-exploitable against TLS, but still publishable and = research-worthy, we should lean towards simpler fixes rather than complex o= nes, while also just abandoning whatever algorithm is effected and replacin= g it.
=C2=A0
> Delaying to a fixed interval is a great approach, and emulates how clo= cking
> protects hardware implementations, but I haven't yet been able to = succeed
> in making it reliable. It's easy to start a timer when the connect= ion is
> accepted and to trigger the error 30 seconds after that, but it's = hard to
> rule out that a leaky timing side-channel may influence the subsequent=
> timing of the interrupt or scheduler systems and hence exactly when th= e
> trigger happens. If it does influence it, then a relatively clear sign= al
> shows up again, just offset by 30 seconds, which is no use.

*if*

in other words, this solution _may_ leak information (something which you c= an
actually test), or the other solution that _does_ leak information, just slowly so it's "acceptable risk"

Sorry, I'll try to be more clear: A leak in a fixed-interval de= lay would be catastrophic, because it will result in a very clean signal, m= erely offset by the delay. A leak in a random-interval delay will still ben= efit from the random distribution and require many samples.

--
Colm
--001a1149459651d464056245b0e9-- From jmitchell@ticketsauce.com Tue Jan 9 08:52:29 2018 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 1CC6F12D865 for ; Tue, 9 Jan 2018 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.061 X-Spam-Level: X-Spam-Status: No, score=-1.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_IMAGE_ONLY_32=0.001, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ticketsauce-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 rlutLSRcrr0H for ; Tue, 9 Jan 2018 08:52:27 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 8E06B129C53 for ; Tue, 9 Jan 2018 08:52:27 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id p144so9788316vke.11 for ; Tue, 09 Jan 2018 08:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ticketsauce-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9HYvpg4oLpA+Gf2Y9DrLEBZf89ioXHZ9nEwF83iaKtQ=; b=J5Dte3XjqKB/NbRfu/TssY/+FxzJe4dW1zMqnFDvU7vMjiq28EojHnt8FliZ+1pSDv kkzKhfK9aL3ljxtecJuz7sWx5beXB+HauUIobgFSIROSNJSEGk0RGh+RGnPFKLJ9aVKC Z8n0DM0T2NkSJxiwmhJX/5orFk99lr9WoNSVmg38syyWHA+e5Jf6l1TWOaYlEhvNNScz uPzSD0ZgIkTT3LQmLPCvqxKRDl0lJkuSM+Yu6vKr/H1PqLQ77rnlLyDMbfI4d7w3eQyv SoPjrVsp25WKi1CNxNUSIOcuhuyjXblIwNQ48vIDY5toOB2x5gKateUmoPsMbTvX2sQ7 3+Uw== 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=9HYvpg4oLpA+Gf2Y9DrLEBZf89ioXHZ9nEwF83iaKtQ=; b=V8uHE+cSX9GtWAPH9n14+fJV1QysAqPEMWA4oAYZeK5O4pPUkw4XfDtBcrG1GBPxqe cybPL4FNg+Tt64Uufk83NqUwjS8MuFVvS1dbWo0bJ8Omxx5tL+dzb/nlpvU66qGQ0cKH 60Gc+3LOjRd9PoabzVxAZkhYtE44rUBz3h16x+SnXFcPrJdJdmzdTBoRh4G5i/8WDQK1 r9b/dr3pNIraWa6xKJ/OKBwCxzhqyx29fKlkH6WP2gtFB43XB4/rihcaL6OyWycf/G7D 8TIf4i6j3ugtw0Rivdo9DHFH3e6OIzGcjQ5/DSdu7RaRYWGTx8Bv/UGJCdEsoHsjIbtW TpDQ== X-Gm-Message-State: AKwxytdvSa4MwSNmrIr79ZoGnpx7MT/b+wbaKbLoxwzGd9nZiPeSypD/ 2Yu6XoeWV53n8JX0zLB1Gcs5T7hsQBTLZdSF+Aifq9Ittp0= X-Google-Smtp-Source: ACJfBov5WA/vnBeW5uw1p8gGAU39DVHVfkZYnf/K+jWdZMtbZd/panu72cvXj/fByqg/S/RcpkbhqaPCdH6/duRWPJI= X-Received: by 10.31.7.193 with SMTP id 184mr14623255vkh.47.1515516746397; Tue, 09 Jan 2018 08:52:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.134 with HTTP; Tue, 9 Jan 2018 08:52:25 -0800 (PST) From: Jason Mitchell Date: Tue, 9 Jan 2018 08:52:25 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="001a1143d97a520f1705625abdc7" Archived-At: X-Mailman-Approved-At: Tue, 09 Jan 2018 10:56:55 -0800 Subject: [TLS] TLS 1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 16:54:11 -0000 --001a1143d97a520f1705625abdc7 Content-Type: text/plain; charset="UTF-8" Hello, I'm actually looking for a list of browsers that still support TLS 1.0. Any information that you can provide would be greatly appreciated. Thank you! JASON MITCHELL Director of Client Services jmitchell@ticketsauce.com - --001a1143d97a520f1705625abdc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Hello,

I'm actually looking f= or a list of browsers that still support TLS 1.0.=C2=A0 Any information tha= t you can provide would be greatly appreciated.

Thank you!<= /div>

JASON=C2=A0MITCHELL
Director of Client Services
jmitchell@ticketsauce.com


--001a1143d97a520f1705625abdc7-- From nobody Tue Jan 9 11:48:37 2018 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 8C89812D77A for ; Tue, 9 Jan 2018 11:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SUBJ_ALL_CAPS=1.506, T_RP_MATCHES_RCVD=-0.01] 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 M2EAGspZQoF8 for ; Tue, 9 Jan 2018 11:48:34 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFA912D7EC for ; Tue, 9 Jan 2018 11:48:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B346453D1B; Tue, 9 Jan 2018 21:48:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id F7rVtGxHgSYO; Tue, 9 Jan 2018 21:48:31 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 67EBD2308; Tue, 9 Jan 2018 21:48:29 +0200 (EET) Date: Tue, 9 Jan 2018 21:48:29 +0200 From: Ilari Liusvaara To: Jason Mitchell Cc: tls@ietf.org Message-ID: <20180109194829.GA31961@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] TLS 1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 19:48:36 -0000 On Tue, Jan 09, 2018 at 08:52:25AM -0800, Jason Mitchell wrote: > Hello, > > I'm actually looking for a list of browsers that still support TLS 1.0. > Any information that you can provide would be greatly appreciated. I think all browsers (outside some research stuff) support TLS 1.0. After all, TLS 1.0 is still the most widely implemented TLS version in the web serverside (TLS 1.2 is projected to overtake it in a few months). Basically, not supporting TLS 1.0 would cause horrible failure rates (and this also goes for some other very broken stuff like static RSA). This certainly includes the newest versions of (the full list would be pretty much the same as list of browsers): - Firefox (and its derivates) - Chrome (and Chromium) - Internet Explorer - Opera - Edge - Safari - Konqueror And many lesser-known browsers. On the positive side, even semi-recent versions of all the listed browsers do support TLS 1.2. (Debian unstable a few months ago was such that if you installed Konqueror from the repository, TLS 1.0 was hard-disabled in it). -Ilari From nobody Tue Jan 9 12:47:22 2018 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 CFC281205F0 for ; Tue, 9 Jan 2018 12:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ticketsauce-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 qJym2k2RSn21 for ; Tue, 9 Jan 2018 12:20:51 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 92ABA127023 for ; Tue, 9 Jan 2018 12:20:51 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id u2so1798092uad.13 for ; Tue, 09 Jan 2018 12:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ticketsauce-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UWoWT8+Sb162lSbV+Ng6KKYwz4X0WhSUCla1KRdkwIg=; b=xLtPkDqh4qSyvpssKaQlRxiRliFjceYWZpvIrBO4gf2Pl1O+sPYFd0Ipd1x2QDSCT+ 5oYdkbQ3o+anhf73NCHAzSCdiXhVyZ1atGJY11oYIpRK7RfujqD3qh4krJPG3FFV9Bmf Z3rQ4BNf6L17Dlns1Jcd8iUCDGgEjC3RysEHDb6Kg4pEz1PUXifQiAhIwo5xlfwi7RvG 9TZsWPjGwArW7M12FaFVWQ7hzi24Gvom9eAh4MYBbyq1ImjwvmBP4Nn0PiMYfZaZpPZv xhgupL/yNQ4ShahIzd85aqYccV3WPvw264iUZUX+kBcHbPiQ9xCsypeWdyAJIE+Nw75e 4DjQ== 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:references:from:date :message-id:subject:to:cc; bh=UWoWT8+Sb162lSbV+Ng6KKYwz4X0WhSUCla1KRdkwIg=; b=mWnD3N4UMCBU3hr3uIAKRhEuGeWZlLcDHP6nOLeJ+UuYQ59Kr4w0S6sTa3jGW/YJtY z3Jahki8ejiKp340a+TbhEBvll1iR631UUAkOXCebdYgo0m9CyvT+qv7TkqvtNpnu6dD NASaZPGmUIsNa7pYIK7YZNJwHTjgMhKppIhbzUlssd7YEXEt78JXri0qw67jDvsKVntn 4h3v29DywPRW5Eumn0to7ghOEw6+UtTSK1o3d9bempfrHuy0DEV0rNXpMt+tSuvk1stx fCWhDsNg+4U//ILDefEbTasdqVkTtmYuISdM2TXf55JeRKD/QLU1W55lFF1RNI3wJEEI IdzQ== X-Gm-Message-State: AKwxytfZLBv1IwjEwkFdyl6Y27bEC4yqMx6F3a4hSj97cpFeI1jTiOAt T93HZvxjH9LzK+ST4tT2+991kugq7zjBFpNHSVJX2g== X-Google-Smtp-Source: ACJfBosKjfjs1R8FooSA291a1v25i1UrfOLowBW+5byGEhRT2ImmTCr/AiJAyM9V2PbJbxQJtOS4SJYNH1FGTwd/UaQ= X-Received: by 10.159.51.74 with SMTP id a10mr6274347uac.102.1515529250576; Tue, 09 Jan 2018 12:20:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.134 with HTTP; Tue, 9 Jan 2018 12:20:50 -0800 (PST) In-Reply-To: <20180109194829.GA31961@LK-Perkele-VII> References: <20180109194829.GA31961@LK-Perkele-VII> From: Jason Mitchell Date: Tue, 9 Jan 2018 12:20:50 -0800 Message-ID: To: Ilari Liusvaara Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="f403043efc04a0bb0a05625da60b" Archived-At: X-Mailman-Approved-At: Tue, 09 Jan 2018 12:47:21 -0800 Subject: Re: [TLS] TLS 1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 20:20:54 -0000 --f403043efc04a0bb0a05625da60b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you! JASON MITCHELL Director of Client Services jmitchell@ticketsauce.com [image: Ticket Sauce] WWW.TICKETSAUCE.COM - For immediate Support: support@ticketsauce.com On Tue, Jan 9, 2018 at 11:48 AM, Ilari Liusvaara wrote: > On Tue, Jan 09, 2018 at 08:52:25AM -0800, Jason Mitchell wrote: > > Hello, > > > > I'm actually looking for a list of browsers that still support TLS 1.0. > > Any information that you can provide would be greatly appreciated. > > I think all browsers (outside some research stuff) support TLS 1.0. > After all, TLS 1.0 is still the most widely implemented TLS version > in the web serverside (TLS 1.2 is projected to overtake it in a few > months). > > Basically, not supporting TLS 1.0 would cause horrible failure rates > (and this also goes for some other very broken stuff like static RSA). > > > This certainly includes the newest versions of (the full list would be > pretty much the same as list of browsers): > > - Firefox (and its derivates) > - Chrome (and Chromium) > - Internet Explorer > - Opera > - Edge > - Safari > - Konqueror > > And many lesser-known browsers. > > > On the positive side, even semi-recent versions of all the listed > browsers do support TLS 1.2. > > > (Debian unstable a few months ago was such that if you installed > Konqueror from the repository, TLS 1.0 was hard-disabled in it). > > > -Ilari > --f403043efc04a0bb0a05625da60b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you!

JASON=C2=A0MITCHELL
<= /div>
Director of Client Services
=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=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
3D"Tic==C2=A0
=C2=A0WWW.TICKETSAUCE.COM

On Tue, Jan 9, 2018 at 11:48 AM, Ilari Liusv= aara <ilariliusvaara@welho.com> wrote:
On Tue, Jan 09, 2018 at 08:52:25AM -08= 00, Jason Mitchell wrote:
>=C2=A0 Hello,
>
> I'm actually looking for a list of browsers that still support TLS= 1.0.
> Any information that you can provide would be greatly appreciated.

I think all browsers (outside some research stuff) support TLS 1.0.<= br> After all, TLS 1.0 is still the most widely implemented TLS version
in the web serverside (TLS 1.2 is projected to overtake it in a few
months).

Basically, not supporting TLS 1.0 would cause horrible failure rates
(and this also goes for some other very broken stuff like static RSA).


This certainly includes the newest versions of (the full list would be
pretty much the same as list of browsers):

- Firefox (and its derivates)
- Chrome (and Chromium)
- Internet Explorer
- Opera
- Edge
- Safari
- Konqueror

And many lesser-known browsers.


On the positive side, even semi-recent versions of all the listed
browsers do support TLS 1.2.


(Debian unstable a few months ago was such that if you installed
Konqueror from the repository, TLS 1.0 was hard-disabled in it).


-Ilari

--f403043efc04a0bb0a05625da60b-- From nobody Wed Jan 10 05:50:32 2018 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 743D51275AB for ; Wed, 10 Jan 2018 05:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.405 X-Spam-Level: X-Spam-Status: No, score=-5.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506, T_RP_MATCHES_RCVD=-0.01] 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 MXozn0gaHXiI for ; Wed, 10 Jan 2018 05:50:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7966127058 for ; Wed, 10 Jan 2018 05:50:27 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C11735BEB3; Wed, 10 Jan 2018 13:50:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-35.brq.redhat.com [10.40.200.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 260AC626D1; Wed, 10 Jan 2018 13:50:26 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Ilari Liusvaara , Jason Mitchell Date: Wed, 10 Jan 2018 14:50:19 +0100 Message-ID: <3993270.A1ar6zFAzh@pintsize.usersys.redhat.com> In-Reply-To: <20180109194829.GA31961@LK-Perkele-VII> References: <20180109194829.GA31961@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1675864.SU8jXV2uZd"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 10 Jan 2018 13:50:27 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 13:50:29 -0000 --nextPart1675864.SU8jXV2uZd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 9 January 2018 20:48:29 CET Ilari Liusvaara wrote: > On Tue, Jan 09, 2018 at 08:52:25AM -0800, Jason Mitchell wrote: > > Hello, > >=20 > > I'm actually looking for a list of browsers that still support TLS 1.0. > > Any information that you can provide would be greatly appreciated. >=20 > I think all browsers (outside some research stuff) support TLS 1.0. > After all, TLS 1.0 is still the most widely implemented TLS version > in the web serverside (TLS 1.2 is projected to overtake it in a few > months). >=20 > Basically, not supporting TLS 1.0 would cause horrible failure rates > (and this also goes for some other very broken stuff like static RSA). >=20 >=20 > This certainly includes the newest versions of (the full list would be > pretty much the same as list of browsers): >=20 > - Firefox (and its derivates) > - Chrome (and Chromium) > - Internet Explorer > - Opera > - Edge > - Safari > - Konqueror >=20 > And many lesser-known browsers. >=20 >=20 > On the positive side, even semi-recent versions of all the listed > browsers do support TLS 1.2. >=20 >=20 > (Debian unstable a few months ago was such that if you installed > Konqueror from the repository, TLS 1.0 was hard-disabled in it). There is plan to disable TLS 1.0 and TLS 1.1 in Fedora 28: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings Debian unstable did that for OpenSSL already: https://lists.debian.org/debian-devel-announce/2017/08/msg00004.html So 2018 may be the first year we see at least some major browsers deployed= =20 with TLS 1.0 support disabled by default. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1675864.SU8jXV2uZd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpWGhsACgkQkqjRuAHS 9fVAEhAAleOpyaFPju922zXTzu/6xl+xKDq8HJT6wu0tUuFhDPKA4+LlwIzUahiU fjmDXYpVvWizLKLYmJEjZqXqT89KZ9gZkx9hwgIyRf0UJvsSmaajPW6gk6BQ83kT TiqLnEgiT/KGk0k5NMXp9qLYcuIONJhcyClygjS9zNc33MdirwdZMHQGmga2NHOf pcXSNaMTiwcFZDqcfjcV7QRfMS86WcCqVVO+66r5pj7miKYhWUNcGWKrcOnGIRTN M+++uTzb+OFBhsqW1noYQ4ykm/sHzPtEzQUML6GgBD7RFVzW4uP69RGxgSyBMszz BxNWk2P0Xx7BWdPzpa/VLdTyA5S81s/TkjR38nMedbi1si5Z3s+nsfRDmiF7IXgT hdcn/WAi/8G3moKZrb5ZlWOfPx1jvlX4t5wc4raiFLyM1vSLJfVI3iUG2IXe6bqc P34Vea0OSRqig5yLXci1+9bIsXZXvnSnn8jvT8wDFJ08itL490WtFMOlnnL5jn92 8BKnpQeTO3a1PL85tQXkYlJREonU43mILObere/TEjcYNAWahLowmiH5vhMCpNuw VW70iiz9a1ED3IVdsObVjWuBLRx/23NSB9DvLrpIVkFvKFHRtb96sCjjSqimj7Y4 RZrtBKlNkPqfLdgGaYIx/+bJd5hT4rHb3lBgKkmVmIaRcwYRZQU= =x0AI -----END PGP SIGNATURE----- --nextPart1675864.SU8jXV2uZd-- From nobody Fri Jan 12 12:10:43 2018 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 7C7DD1242F5 for ; Fri, 12 Jan 2018 12:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 KK3_i_Uo6_An for ; Fri, 12 Jan 2018 12:10:40 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B7E311241F8 for ; Fri, 12 Jan 2018 12:10:40 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id 33so7464155qtv.1 for ; Fri, 12 Jan 2018 12:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=XUo1lAaUPP8hIDMfFYsxx5gvnagPBim5+tlFrFkhaF0=; b=ln9n8MSyQAA10RHhp02U6cYEm4Wq5RJ27QiXcubDQNaAiYSWX7tACgV/8mL/IkHREY lEyC3QB2aXZxnuI5zXctwBA03L9xB/GCKaZvn8attZW3+VJX9Ze8qpQNXFVAuzsXLzcb 39F9L9zMGM0dqxun77d3qaSDRHqBb9sE/TpMs= 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:message-id:date:to; bh=XUo1lAaUPP8hIDMfFYsxx5gvnagPBim5+tlFrFkhaF0=; b=f0IB4Jh037c/hItB0xVJSIMX+Q3RgbV+r6PMj5LKa8nVjnYOuMCyPcP66kFiAgrOl0 G/bwjZ3W943AUWm5Xu30+kJET8bVHvh3wr/n87S4d2JdiSPgQN3R8Fmw44Vqv3+QgBgE hzL9nLqZpDTmzjYO92VBFd7LdgitA/SDKrH7up88qMDPD0QDIVt++kC//boRd7GsQ//8 /zmGtk9xlPV4mvxSl+rsUxjo4eF1V2sM/z+ADkEy7J8zvSDZAEELcqFRZ38/q6KlzMmJ qZ9LgGjNu8K+Dj2jKh6+zAEojnDagbLwysUeJISocprc74vzG2Nvi8AX0PuHDnhPSmEP BXSA== X-Gm-Message-State: AKwxytfLrYgYt8nOKG5NeaxHzwnhZFP9K868KE2oTazRT21QlwOmaads 8s6O0TzueCPAlZXDd8EY9oSc4TIE1dc= X-Google-Smtp-Source: ACJfBot6svMibo8r4rbpDRpJEuc0ok/RzlQ7T5QQhbiocbFrHt1aylF8t6QUrZ9ejTcNqQKtyX44mg== X-Received: by 10.237.38.71 with SMTP id z65mr38235165qtc.114.1515787839603; Fri, 12 Jan 2018 12:10:39 -0800 (PST) Received: from [172.16.0.18] ([96.231.216.163]) by smtp.gmail.com with ESMTPSA id q12sm14256791qtk.32.2018.01.12.12.10.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 12:10:38 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Fri, 12 Jan 2018 15:10:37 -0500 To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 20:10:42 -0000 All, This is the 3rd working group last call (WGLC) announcement for = draft-ietf-tls-tls13; it will run through January 26th. This time the = WGLC is for version -23 = (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). This WGLC is = a targeted WGLC because it only address changes introduced since the 2nd = WGLC on version -21, i.e., changes introduced in versions -22 and -23. = Note that the editor has kindly included a change log in s1.2 and the = datatracker can also produce diffs = (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&url2=3Ddraft-= ietf-tls-tls13-23). In general, we are considering all other material = to have WG consensus, so only critical issues should be raised about = that material at this time. Cheers, spt= From nobody Fri Jan 12 15:02:25 2018 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 68D01127342 for ; Fri, 12 Jan 2018 15:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 at-NpfUqFd7S for ; Fri, 12 Jan 2018 15:02:10 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8FE12711B for ; Fri, 12 Jan 2018 15:02:09 -0800 (PST) Received: from pc1 (178-83-154-183.dynamic.hispeed.ch [::ffff:178.83.154.183]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 13 Jan 2018 00:03:09 +0100 id 0000000000000028.000000005A593EAD.0000305F Date: Sat, 13 Jan 2018 00:02:06 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20180113000206.6bc36af6@pc1> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 23:02:18 -0000 Hi, This working group just went through a painful process of realizing that deploying a new TLS version on the Internet is a hard task due to broken devices. If you're not aware David Benjamin just gave a great talk summarizing the issues: https://www.youtube.com/watch?v=3D_mE_JmwFi1Y Today I found this article: https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encrypt= ed_traffic/ tl;dr Cisco now says they can identify malware in TLS traffic by carefully looking at it. (For context: devices from Cisco were responsible for many of the issues that made deploying TLS 1.3 hard, e.g. version intolerance on load balancers and recently by not correctly terminating TLS in a firewall.) I'll dare to have a look into the future and make this imho very plausible claim: Cisco won't be the only vendor selling such things. We will see more products that magically can identify "bad things" in TLS traffic by applying everything from AI to Blockchain. We will almost certainly see a whole new generation of devices doing weirdness with TLS and who will drop or manipulate packages that contain things they don't know (like... a version negotiation field with TLS 1.4 or a large post quantum key exchange message). The question I want to ask: What can we do *now* to stop this from happening when TLS 1.4 will be deployed? I have the feeling GREASE won't be enough... --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Fri Jan 12 15:53:11 2018 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 E48C5124E15 for ; Fri, 12 Jan 2018 15:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KsBuON4ZRkPk for ; Fri, 12 Jan 2018 15:53:09 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 15A4D120725 for ; Fri, 12 Jan 2018 15:53:09 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 136so5020397pgd.8 for ; Fri, 12 Jan 2018 15:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYNCcJA244ki/Q3J7G2bkIe5SlKu3JqML2ImTpwzlhg=; b=b0qjABFFsD0t1IgT7BdXJlMVNfIbHSmZqtcaRIQIofcSSPJqieVO+77D/DjA6+y6t3 HLotfXryo+59eNkQJdnU7LH0XxcIUKFNKxFvyixETdkdaVNK3QHYZ7RExtUqJyLxv0tW MpICRdPPL5hoCkIdEYLD3+6CphGcvrDjgkiBbos6qraBlsDr2ZXd3DYBjFJRNGPjs/9f 86q+oVOt6lO5UNcPiS6fj8wVDGG9cpxzH4chC9SuFE90GhfXhw8fD5njisuZ8HVQ+5wM keupi7XhRqB3omF+tLyHs6cSb/iLQAd4Nk+4gfDIYQ7I7hvWg0QlrULDzalIqYVlhVXX kcbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYNCcJA244ki/Q3J7G2bkIe5SlKu3JqML2ImTpwzlhg=; b=ch6VjXSWEcPmtn6S+cwAPjiJfycGrdJYcPxQoaCcaVpRrOd/ooGfdRBSPUxDICblKe +g08PPWgiFRtX1q46NCKYbRP0WsotY+EkthCns4gdWCSS7wsOLpgl3B22sUTS4ug79gP ViWpogPNN7a/sljqOipH7+K3NRfH766fisqGlogStluBLqmwbGAkP8UXsIVKgIvg6zqZ ZBqYDLLH+M6bTZnfl7GmrKeWrnU0BVzkhvchy81XLa+sWXCcC5ohKgl6NgDPVePJFNuU wJVtDfjvZjzIEZ5DppfeZdda4Tep6/IOed4/6tUQFTJVy7ASvKe6yt1gdTUghmonaREd OGTw== X-Gm-Message-State: AKGB3mJ/LH436t8AthaukaC0kTiwkQ0skTbG0rKcDCVHt6IkHIKZI0vw ISrI3pZFOi7mu8mSjkhwk9+/0OqE X-Google-Smtp-Source: ACJfBosUO7xchKYUM4MWg2MOX241HeCPIw++jgX3DA4bmeRidRsGuSrr9WH92hirC2oIRYlh/PBFGA== X-Received: by 10.159.252.197 with SMTP id o5mr17087081pls.67.1515801188452; Fri, 12 Jan 2018 15:53:08 -0800 (PST) Received: from [192.168.86.82] (c-24-4-202-234.hsd1.ca.comcast.net. [24.4.202.234]) by smtp.gmail.com with ESMTPSA id r13sm38958384pgq.25.2018.01.12.15.53.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 15:53:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dan Wing In-Reply-To: <20180113000206.6bc36af6@pc1> Date: Fri, 12 Jan 2018 15:53:05 -0800 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> References: <20180113000206.6bc36af6@pc1> To: =?utf-8?Q?Hanno_B=C3=B6ck?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 23:53:11 -0000 On Jan 12, 2018, at 3:02 PM, Hanno B=C3=B6ck wrote: >=20 > Hi, >=20 > This working group just went through a painful process of realizing > that deploying a new TLS version on the Internet is a hard task due to > broken devices. If you're not aware David Benjamin just gave a great > talk summarizing the issues: > https://www.youtube.com/watch?v=3D_mE_JmwFi1Y >=20 > Today I found this article: > = https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encryp= ted_traffic/ >=20 > tl;dr Cisco now says they can identify malware in TLS traffic by > carefully looking at it. > (For context: devices from Cisco were responsible for many of the > issues that made deploying TLS 1.3 hard, e.g. version intolerance on > load balancers and recently by not correctly terminating TLS in a > firewall.) Those bugs that interfere with TLS handshakes are un-related to Cisco's = Encrypted Traffic Analytics ("ETA"). Different technologies. -d > I'll dare to have a look into the future and make this imho very > plausible claim: > Cisco won't be the only vendor selling such things. We will see more > products that magically can identify "bad things" in TLS traffic by > applying everything from AI to Blockchain. > We will almost certainly see a whole new generation of devices doing > weirdness with TLS and who will drop or manipulate packages that = contain > things they don't know (like... a version negotiation field with TLS > 1.4 or a large post quantum key exchange message). >=20 > The question I want to ask: What can we do *now* to stop this from > happening when TLS 1.4 will be deployed? I have the feeling GREASE > won't be enough... >=20 > --=20 > Hanno B=C3=B6ck > https://hboeck.de/ >=20 > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jan 12 16:11:22 2018 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 7A6AF120725 for ; Fri, 12 Jan 2018 16:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 P-3VNnAhf5Zs for ; Fri, 12 Jan 2018 16:11:19 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B0A1204DA for ; Fri, 12 Jan 2018 16:11:18 -0800 (PST) Received: from pc1 (178-83-154-183.dynamic.hispeed.ch [::ffff:178.83.154.183]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sat, 13 Jan 2018 01:12:19 +0100 id 000000000000006F.000000005A594EE3.0000279A Date: Sat, 13 Jan 2018 01:11:15 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Dan Wing Cc: tls@ietf.org Message-ID: <20180113011115.765a3fc9@pc1> In-Reply-To: <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 00:11:21 -0000 On Fri, 12 Jan 2018 15:53:05 -0800 Dan Wing wrote: > Those bugs that interfere with TLS handshakes are un-related to > Cisco's Encrypted Traffic Analytics ("ETA"). Different technologies. I haven't claimed that. I just think it's very plausible to assume that a company that already created two independent problems for TLS 1.3 will do the same in future products that mess with TLS in "new and exciting ways". And for the unlikely case that Cisco is able to learn from past mistakes I'm absolutely sure there will be others creating similar products that won't. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Fri Jan 12 16:34:40 2018 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 3CC6F1242F5 for ; Fri, 12 Jan 2018 16:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 5W7kwnuVvIJO for ; Fri, 12 Jan 2018 16:34:36 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010090.outbound.protection.outlook.com [40.92.10.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BAF81241FC for ; Fri, 12 Jan 2018 16:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PD+dNCdlFlEsAd0pciet/6Il3HAsSv5PNS291JVXqvQ=; b=WFvVcvfbYZe83zPKp+49E/X8ngBf9st0qaElVVM7XA50boCMIUdAge4XO3rU8DOlWjxkPaL6Dhq9WA4fhfqud+exTgB5MlOyPWRUOEEHHc0+Mp+R4qE37f5+AePi1YiQQkWePJqS34QtifeyNjaOKaq/IH5JyE1BTNGl9r6TDI6vF5JFmhjv5OGDmEP4fDDRC7qHIR45uikz771tB8LC6AmzoqNHmwfIb0jRNYceAPQY+woHXYlR1xFwKHvd/V18RhOKTu8wBOurvE37X1AhFTZk9KaR/JC7zlinJgUaiHkXHPJ5SmA4YhfUf4l0Pzepohly/FOjQdUd7ijXIq5uaA== Received: from CO1NAM04FT055.eop-NAM04.prod.protection.outlook.com (10.152.90.51) by CO1NAM04HT117.eop-NAM04.prod.protection.outlook.com (10.152.91.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.345.12; Sat, 13 Jan 2018 00:34:35 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.90.51) by CO1NAM04FT055.mail.protection.outlook.com (10.152.91.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.345.12 via Frontend Transport; Sat, 13 Jan 2018 00:34:35 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0386.009; Sat, 13 Jan 2018 00:34:35 +0000 From: Yuhong Bao To: =?iso-8859-1?Q?Hanno_B=F6ck?= , Dan Wing CC: "tls@ietf.org" Thread-Topic: [TLS] The future devices that will break TLS 1.4 Thread-Index: AQHTi/lrAD74E5jR80q8p2qaPVAj8aNw6QeAgAAFE4CAAAZ3eQ== Date: Sat, 13 Jan 2018 00:34:35 +0000 Message-ID: References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com>, <20180113011115.765a3fc9@pc1> In-Reply-To: <20180113011115.765a3fc9@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F78C73FFFB9593A4F74B63E3F904EC9628505EB8033E13CFD8C3DD091AE3808F; UpperCasedChecksum:A3E902D75B9CAA1E67229171C28119E7B9650E2F5EF71B86D93ED6E5B2A18944; SizeAsReceived:7258; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [DZiL7KlMVEFf3eF/x/+mtiaclGK1k9aT4Tm67A0TjOH/4ItXWSCq0+CgQYg6xKb9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT117; 6:M+xcBhHGE3ZStZjbHAD/NDnNvDpnu9toU3VqB5GN7Z75lybVR2yQYnfhhg3BBu9+9AX6Fi3MoInyOg8VusJHN/bn6O7johcx1BU40N/t4RusDf2MvL5qBf8jKMWxBvvYhOWs8gU1aeoCyVZ6wBdGXLgYYaeLhA6ULPjSw+2KX+IqFjt2oMa0x5jv3eGYynfpU81kmsdVY3/qPBTlMzpVpwyuvzBZczjDuR/ItEjmlgQvyDZspnOJ/AF9Rd2JKgpjJ0ydokxaDUhQha9tk/dDmJYq0r/VcHw+rFbg34Vxa/9Qrr5vo+5Nr2JzPPYGksix6hp7GM2rPHDaMN82PWE1MrYsM7VHa3vuqacCH2xwvks=; 5:I9rbdwnX2H9Cp1598Ol+RefE+9G0b5xhM60gx41WZrYiZyEYrk7SKc5gd3kv9PwHDaoecmL3tRDzx4+fA9VEAmmmOJNuBI4HRZe6Fs6AHu2Z4/1n9bzFCd13ujU25zizvuXO5Q4ThmNM6Jg9HYUsI/RJOnmS1hAnjX3Us0OmlOQ=; 24:3sfjkWSw3CAccIKBtytxPxo2Ub6hHXO9zuAjM+wxdikKVwjxwbxgKMIcunLXNExWiOwYdgoG3fayrkI/tOfMKzquvJ4pgJV0wCTRyXddNsg=; 7:Dxe2e3K/wqBvQHc36QCOMau2BDBk+XyDA35uEJ3ZVbI6JwdPfc68KVDTsL+4GmyFftXtf0mO6nKkdszjBSz9OvEJUj3S93rjcz3V5Qfd1gOy1FQelvId38VNVJmJUQDma1hptJ/mUqRXaFwYLogrudsH1omNaOA+284N6kW7KCmT3yM4EIOPdL/axnlteETjmBC7YJZU+v1BXS6F58F+gLu7ZafB8iI6sXsvJ7km36Ebe1ffkLvKqV4HTfjAITPI x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020089)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:CO1NAM04HT117; x-ms-traffictypediagnostic: CO1NAM04HT117: x-ms-office365-filtering-correlation-id: 34291f88-90f4-4a76-9ff0-08d55a1d6bf4 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:CO1NAM04HT117; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO1NAM04HT117; x-forefront-prvs: 05514B7026 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT117; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34291f88-90f4-4a76-9ff0-08d55a1d6bf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2018 00:34:35.4225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT117 Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 00:34:38 -0000 Is that arms race really worth fighting? ________________________________________ From: TLS on behalf of Hanno B=F6ck Sent: Friday, January 12, 2018 4:11:15 PM To: Dan Wing Cc: tls@ietf.org Subject: Re: [TLS] The future devices that will break TLS 1.4 On Fri, 12 Jan 2018 15:53:05 -0800 Dan Wing wrote: > Those bugs that interfere with TLS handshakes are un-related to > Cisco's Encrypted Traffic Analytics ("ETA"). Different technologies. I haven't claimed that. I just think it's very plausible to assume that a company that already created two independent problems for TLS 1.3 will do the same in future products that mess with TLS in "new and exciting ways". And for the unlikely case that Cisco is able to learn from past mistakes I'm absolutely sure there will be others creating similar products that won't. -- Hanno B=F6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jan 12 16:50:06 2018 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 8D1C5126C23 for ; Fri, 12 Jan 2018 16:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 vnmynO6e5F9J for ; Fri, 12 Jan 2018 16:50:03 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005011.outbound.protection.outlook.com [40.92.5.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC81126C25 for ; Fri, 12 Jan 2018 16:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=do3Ak6KyqlRDYjgS1BNu9l9Uk8WyZMB87/HFalHuTDs=; b=FDMPufCkZix+xJjL+FppI7QcceV/3ywofFQdk+WKk/VLCpFyfE92ryaYb58xP0ft8SCpvAShmc+lBrWFS/n0iwQnwtxn1NrDAw5aIZSjJQVrXOyLyu3BP/uLHsoFlUakn7G/7agMmM28Zo46sImdVqSElwp0moGqiJHAIMoAp4DP7LKtCIBssDu/6+oHyIiBkVXbC9ovnxbqviZag3TAcDsJ0tRA2sg45Y0Vn+8G3CnOdRdAblf/0kGux+JzX8Yh2Xws3lBjF243w5BAn+Mp+bXObkVZVCkf/lZ3wJQi+CAx3/zyeUKWUAO0xUhmbcFW7zTIpeFFV17LNEdJLfpDOA== Received: from SN1NAM02FT006.eop-nam02.prod.protection.outlook.com (10.152.72.57) by SN1NAM02HT110.eop-nam02.prod.protection.outlook.com (10.152.73.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.345.12; Sat, 13 Jan 2018 00:50:00 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.72.58) by SN1NAM02FT006.mail.protection.outlook.com (10.152.72.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.345.12 via Frontend Transport; Sat, 13 Jan 2018 00:50:00 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0386.009; Sat, 13 Jan 2018 00:50:00 +0000 From: Yuhong Bao To: =?iso-8859-1?Q?Hanno_B=F6ck?= , Dan Wing CC: "tls@ietf.org" Thread-Topic: [TLS] The future devices that will break TLS 1.4 Thread-Index: AQHTi/lrAD74E5jR80q8p2qaPVAj8aNw6QeAgAAFE4CAAAZ3eYAABCUN Date: Sat, 13 Jan 2018 00:50:00 +0000 Message-ID: References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com>, <20180113011115.765a3fc9@pc1>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:443743D66FB5EBC2C6C64C45113DAF20086DA1B9FFE5BED828E59F18E6C26F47; UpperCasedChecksum:8AD304CB081927BD7E28302D7B5D27F13B4DB1AF0E11B6CF55DDA8A04CFC4A49; SizeAsReceived:7416; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [/QaWk8/taZlJrNJEsX2pDSaPaIADvSaCqqZke1/7JJW8UJfeTCMsnojxoVULlwmX] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT110; 6:aNYXoBz60LEKTTT+mUsqlsx0MesRUct6HQPusUyTnV281VN5unx4VZYD8NpLoemRbqebySDSzQP3RvrWOVfHFzPsgGFfNVjTk3ITvc1KhcOjAFbPJ3sRG7N2JtnUaidzXW3s9c9vMVvE0ML21O6Gj7XFsIXRU4bAAA+3GaLIUTVycNCrxOtppIGkLQLOT6cS9nV9vTiYXKnn0T2AZ7DS4HORKS+gCYrVgOE8t8Gwus/hEKwua6vl+RiZvxdZpiz7vfwdH4r6Y2JYzer3UUPX1WvBc6azAUWbna5mmrx/1d8sA0tTPh++MBGfisAGtZrPo3vuoqlc7tiLf60FZ8z0lRlgX/Ipd/tYP2SzoB1KOL8=; 5:dhra0SocNSdfIReO6zdH+fVdyUvW9Gqnk2VX/cqSOqZJBs1m+eMRQ81MaePPpRzDPenQ5AYu45BFuZ2nn4tX7aqtrkdxSjfI1PLrh7S5v/zoi93pf1tCsM72Z4aOgVTcBN6ymjilM5aNXe48DsvMnbcA7pysMAwjjv7YpAQLuPs=; 24:OzBzlTpoPLjHQYqtSh8eQRD4OxE7jKEKR+xAclyCJiqOpfa4sOUPDaR5Uas6ZaJDc5fe9zsR2LTxBgkF8P+PnpcexryQHVrKyBzUrgJAL0Y=; 7:+20Wr8doXK0xl8q9S3saXpK9rA6WpMDhbc2p6YmrvhI26he6S20oxNhomGLeMK9aoLLFaJLr16pwyzb/tUm7FxMGnEI4Z5/BKlyWh8ivifXvLYPnaF9n1T6mNV1TuxAmfYUrKFuQ96ORmVUsjesVk0PYJ+k8S6xMwf+KjIcYnOFhUVQ9HHeCkDeyfuAxhBik1uJ33jl4mtIGPgb40yImwDC+31yhCuU+LYy410KS6WftVf7lgioazJtN/jXYS2QB x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020089)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:SN1NAM02HT110; x-ms-traffictypediagnostic: SN1NAM02HT110: x-ms-office365-filtering-correlation-id: 655b9227-3459-4def-1554-08d55a1f9342 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM02HT110; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1NAM02HT110; x-forefront-prvs: 05514B7026 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT110; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 655b9227-3459-4def-1554-08d55a1f9342 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2018 00:50:00.3392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT110 Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 00:50:05 -0000 This also applies to TLS 1.3 BTW, not just a future TLS 1.4. ________________________________________ From: TLS on behalf of Yuhong Bao Sent: Friday, January 12, 2018 4:34:35 PM To: Hanno B=F6ck; Dan Wing Cc: tls@ietf.org Subject: Re: [TLS] The future devices that will break TLS 1.4 Is that arms race really worth fighting? ________________________________________ From: TLS on behalf of Hanno B=F6ck Sent: Friday, January 12, 2018 4:11:15 PM To: Dan Wing Cc: tls@ietf.org Subject: Re: [TLS] The future devices that will break TLS 1.4 On Fri, 12 Jan 2018 15:53:05 -0800 Dan Wing wrote: > Those bugs that interfere with TLS handshakes are un-related to > Cisco's Encrypted Traffic Analytics ("ETA"). Different technologies. I haven't claimed that. I just think it's very plausible to assume that a company that already created two independent problems for TLS 1.3 will do the same in future products that mess with TLS in "new and exciting ways". And for the unlikely case that Cisco is able to learn from past mistakes I'm absolutely sure there will be others creating similar products that won't. -- Hanno B=F6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ 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 Fri Jan 12 18:31:35 2018 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 01F52127201 for ; Fri, 12 Jan 2018 18:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JCqqqp8EGGAl for ; Fri, 12 Jan 2018 18:31:32 -0800 (PST) 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 15FCE1200F1 for ; Fri, 12 Jan 2018 18:31:32 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eaBbV-00017X-Uk for tls@ietf.org; Sat, 13 Jan 2018 03:31:30 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eaBbS-00060B-MD for tls@ietf.org; Fri, 12 Jan 2018 21:31:27 -0500 Received: (qmail 31239 invoked from network); 13 Jan 2018 02:31:25 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Jan 2018 02:31:25 -0000 To: tls@ietf.org References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> From: Christian Huitema Message-ID: <249425c3-780f-5850-366b-9d87d3b31af4@huitema.net> Date: Fri, 12 Jan 2018 16:31:23 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> Content-Type: multipart/alternative; boundary="------------A7AF6E4B80A7E28D71700A06" X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.34) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pfYl1fUtXrjLu44MmH8zRsXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4ad0MPP4nln6TksW2sQiSBALB67TLnlh9i6Dr2tTQ7u+oqs y1PKTVoO8Zj6z/ewaDOZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyavGztmOtIaM+D1rj/L7c8XBe6u0CoZukxEZzyzt1OR snzfTtng4rHS/8LBixaHDG3h9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/L5 uD5BFwUsLzoxNE3Df89qzrjq4Hfr4ZhSwhJ40urz5XLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 02:31:34 -0000 This is a multi-part message in MIME format. --------------A7AF6E4B80A7E28D71700A06 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/12/2018 1:53 PM, Dan Wing wrote: > I'll dare to have a look into the future and make this imho very > plausible claim: > Cisco won't be the only vendor selling such things. We will see more > products that magically can identify "bad things" in TLS traffic by > applying everything from AI to Blockchain. Well, of course we will see such products. We know that it is possible to do a lot of pattern recognition based on properties of the encrypted traffic, as well as clear text parts of the headers. And we also know that there are lots of network managers that want to understand what's happening in their networks. The kind of products shown here seems rather preferable to the previous generation of products that required breaking the encryption. > We will almost certainly see a whole new generation of devices doing > weirdness with TLS and who will drop or manipulate packages that contai= n > things they don't know (like... a version negotiation field with TLS > 1.4 or a large post quantum key exchange message). That's the general problem with machine learning. The attackers will be learning too, and will try to tweak their traffic until it looks innocuous. As attackers do that, filters will try to catch them, and the chances for "false positive" are going to increase. > The question I want to ask: What can we do *now* to stop this from > happening when TLS 1.4 will be deployed? I have the feeling GREASE > won't be enough... Data sets. Machine learning algorithms are trained with data sets. If we produce reference data sets showing what TLS 1.4 looks like, the vendors can retrain their AI and start recognizing the new version for what it is, rather than some unknown attack. -- Christian Huitema --------------A7AF6E4B80A7E28D71700A06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 1/12/2018 1:53 PM, Dan Wing wrote:
I'll dare to have a look into the future and make this imho very
plausible claim:
Cisco won't be the only vendor selling such things. We will see more
products that magically can identify "bad things" in TLS traffic by
applying everything from AI to Blockchain.

Well, of course we will see such products. We know that it is possible to do a lot of pattern recognition based on properties of the encrypted traffic, as well as clear text parts of the headers. And we also know that there are lots of network managers that want to understand what's happening in their networks. The kind of products shown here seems rather preferable to the previous generation of products that required breaking the encryption.

We will almost certainly see a whole new generation of devices doing
weirdness with TLS and who will drop or manipulate packages that contain
things they don't know (like... a version negotiation field with TLS
1.4 or a large post quantum key exchange message).

That's the general problem with machine learning. The attackers will be learning too, and will try to tweak their traffic until it looks innocuous. As attackers do that, filters will try to catch them, and the chances for "false positive" are going to increase. 

The question I want to ask: What can we do *now* to stop this from
happening when TLS 1.4 will be deployed? I have the feeling GREASE
won't be enough...

Data sets. Machine learning algorithms are trained with data sets. If we produce reference data sets showing what TLS 1.4 looks like, the vendors can retrain their AI and start recognizing the new version for what it is, rather than some unknown attack.

-- Christian Huitema


--------------A7AF6E4B80A7E28D71700A06-- From nobody Sun Jan 14 05:34:48 2018 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 2173912D7E9 for ; Sun, 14 Jan 2018 05:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 E7KY53m2fQqB for ; Sun, 14 Jan 2018 05:34:44 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 2C40912D7E8 for ; Sun, 14 Jan 2018 05:34:44 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id x10so6918843ual.8 for ; Sun, 14 Jan 2018 05:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jraf6qhHd3r1iZL2ipNY4G+11fT4WQszeeLdx7cWem4=; b=dgqfSM8aKkdNoz1Gp7fWW8duQV/mtyUXdKGrSO+MNb/dNDv5WypaqkLNbMdP6qhYsW rrFXC5RVz4n3PT3CUOV72v3uKLKsF54bNAvVP+TTl83Lck+1HuGaPafpUoQCq+LS618a RJEgCYDRe5m/1QHqg6VOdneH3iq3J5PUSiWtq4ocjMgzaxSlGG1QFLgDaIERjQerkgsf bTchHCC7IMsNYHHf2VpaneadjZZtZNx1DRPMPdWp0+3K8Bn3Zy7qQ+IXKYC2YR+QGcWw Vsj4YT9djUwKKDIr7vI2KH+WViYf5dseq7fDExgLTUBfa3cetOl33niu8/wrVNHkaXbE Atpw== 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:references:from:date :message-id:subject:to:cc; bh=jraf6qhHd3r1iZL2ipNY4G+11fT4WQszeeLdx7cWem4=; b=bpxfKeKcbmawl8UhyynzyxAn2IxIoveSjjwl42OaFU/hMlmV6zUSxGupa3UBqSC/jG 9guCJrN4JNuzC/+f5xix5FoYaCyBz7mW/WDB8TrVMO8aX4OpL5RnGoNPVqisJGLZQSNX 1tuk0fKre1MWPoDwXNJwAmKzh7eME3oYMQRzzQksrczhtJrlJShZsRNjzmRnHaz/G5WV qhOhg7QHmsSkokWNiiGZ+JW0DxvA0oMvQlRVt+r52egHHyi6yjfv7qZhefq6NN3DILMQ zbiWfIgTONnNR6JdiAX2jRYVqRkps7OE0R8xTOX1i90PA2suMUf10+u+iHd+KbysDE8w Asvw== X-Gm-Message-State: AKwxytcV17eu9ftYFlv3Ce1YLHUo3m0Z+8j2tHhHZLAGi0g3A3JTIUAb cenMJLsaS1p6kkGRlXr4qJXsHWtFwiJyvvH492FmLg== X-Google-Smtp-Source: ACJfBosyHHU/NzvGdTyr4gaIvvjs8kMi8GAb7bctRzHAjhMdxgaO5EeNaHaIGFB7Eew3sqPFcLfWeBvKkEQbBNLOUQ8= X-Received: by 10.176.49.222 with SMTP id e30mr9934895uan.145.1515936883118; Sun, 14 Jan 2018 05:34:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.3.197 with HTTP; Sun, 14 Jan 2018 05:34:22 -0800 (PST) In-Reply-To: <20180113000206.6bc36af6@pc1> References: <20180113000206.6bc36af6@pc1> From: Tony Arcieri Date: Sun, 14 Jan 2018 14:34:22 +0100 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "" Content-Type: multipart/alternative; boundary="089e08e5af4b6b998a0562bc8f29" Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 13:34:46 -0000 --089e08e5af4b6b998a0562bc8f29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 13, 2018 at 12:02 AM, Hanno B=C3=B6ck wrote: > > The question I want to ask: What can we do *now* to stop this from > happening when TLS 1.4 will be deployed? I have the feeling GREASE > won't be enough... Sidebar: TLS 4 ;) --=20 Tony Arcieri --089e08e5af4b6b998a0562bc8f29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jan 13, 2018 at 12:02 AM, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
The question I want to ask: What can we do *now* to stop this from
happening when TLS 1.4 will be deployed? I have the feeling GREASE
won't be enough...

Sidebar: TLS 4 ;)=C2= =A0

--
Tony Arcieri
--089e08e5af4b6b998a0562bc8f29-- From nobody Sun Jan 14 05:36:09 2018 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 1E55112D7F2 for ; Sun, 14 Jan 2018 05:36:08 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iNzmoc5S9sRm for ; Sun, 14 Jan 2018 05:36:06 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 B71B612D7EC for ; Sun, 14 Jan 2018 05:36:03 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id a25so6933995uak.3 for ; Sun, 14 Jan 2018 05:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZcTqAMYABiaW+d/Ko5+1i5W+orFbcZjjqVUBU3t3pJY=; b=KMUEWMkIA3QYWRBCyd5+haVueyfYjzsu+nWXaDhMFNRw19WlI2NPjgqmSf8nYnigc0 Ej+YWsTyvqrchqhdUKd7vxPlvdJr4CV/YwYKOCb2MEpfiZXDRKRCjvHJ3rJa7xECvGMt MwuIOhITupguiNC3wuQ5vxBCbAbfxTUDNFrmT4g2Zux+5fME2k/3xmy5vnG+94eOL5XT PyzxKonsOziLus+18uM2egwCqjUPo4ZZinPN0KqMhEyNC9de/ztBUu5grHF0q/SSqlNk 09T8PSS7SzySS2q+/G6wcdL0zqtGsNyPveFRA2MSbzh6YLof7nJgK0XkeGO2//xFe5x6 ajPg== 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:references:from:date :message-id:subject:to:cc; bh=ZcTqAMYABiaW+d/Ko5+1i5W+orFbcZjjqVUBU3t3pJY=; b=kx4v99xqOH45oMi7OF1b9O4mhiclIW+EEpHUtQZQmWtzV3nuTyHXaxwiLbLxjCNgam w0YW6niPGvMA1vwUJRAnjw/QiWVFhw5wvO7SVthyVZndkqV+YTzjsN2scE9Zldz5Ffdh THzhgndaoaCORcx9oq2FNw73dt1Zf+y5QleWY5I9PzOZhPKENpbEvmTzDazlKWqc4VSQ A6Nz9jyIOHsH1CTz0DdZStE9hbzURsH17LAI8lh7sLHTW/BwlJ0G8+il0VkxzktOIbxw 8ut9GCjNmRoatSxqY02WLk6k8jU5+mPCx0HGF4y8CgO9bZGWfTViU2ZJ4HlXu16zxmQy Sjww== X-Gm-Message-State: AKwxytd9lsUsUG2VzbS3PQjz+aM9ar6Uiw0LGqCFA4FugQLLz7o15RBJ y7eQbHXIu12gJmFT7pPihAIM24O5yntkp/P6CDvYsA== X-Google-Smtp-Source: ACJfBottsS6/5EdYPeQnD+mEpqfdRdLiuyVlhrNsuYiAbsvKcAhYJhnBVC+knATpwO4xFqw9ijskznmuVWiO6dqPa+E= X-Received: by 10.159.51.74 with SMTP id a10mr20827359uac.102.1515936962785; Sun, 14 Jan 2018 05:36:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.3.197 with HTTP; Sun, 14 Jan 2018 05:35:42 -0800 (PST) In-Reply-To: References: From: Tony Arcieri Date: Sun, 14 Jan 2018 14:35:42 +0100 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="f403043efc042b37720562bc9430" Archived-At: Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 13:36:08 -0000 --f403043efc042b37720562bc9430 Content-Type: text/plain; charset="UTF-8" Ship it -- Tony Arcieri --f403043efc042b37720562bc9430 Content-Type: text/html; charset="UTF-8"
Ship it

--
Tony Arcieri
--f403043efc042b37720562bc9430-- From nobody Sun Jan 14 12:15:26 2018 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 7FC1A12D853 for ; Sun, 14 Jan 2018 12:15:24 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 1jeS7dSMRfQB for ; Sun, 14 Jan 2018 12:15:22 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 5A69E12D82C for ; Sun, 14 Jan 2018 12:15:22 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id k189so4940143ybc.12 for ; Sun, 14 Jan 2018 12:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IUpWFJEt2LL5ZtXmdRAzCDFvv8XFiCJBSbcxEFe+wCY=; b=rpiBV2vzywCmMq0WoKTPXeIK77ru6UmLy109WGEOZB/i3z3ZZIpCQAU1gCs5YTy6ob pWMq6Bxr+K3cA/+OuPUw1N172u8UUkgvOBXSN9QZhx6YvCnQ15L8+YnDdrHISqtiAkeK VoOClJZmwDw4fMwzS7WZafyC/vGaWKQp60kqIT3b4j5SfCMk9FFNvnkzP+wOsyYDANPM MktjYhG8Bsha1fmqhMzkBk77kM/43xHoruJVIltgIYOKDoRqzv/czpbilHP3pMBFWFgw qAueA8jz6ScsmcUxMeYVEy3I4349R4xDVQre74OB1bDvMbkPy5HMx4eZgMTn4GNLBZQx ll8g== 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:references:from:date :message-id:subject:to:cc; bh=IUpWFJEt2LL5ZtXmdRAzCDFvv8XFiCJBSbcxEFe+wCY=; b=XFB17rlq/Ezz7Y7jKTkpChVbY3Tv0yIw0BQBqFzEbgOVlLbsFyNnGJ1J5zWSD/cjRt E3hMJPdgiZ/pkMsbU506ISxZOTyL1eBIZhGM269AhQylGxq0iISq1hxTk19OHuX8Zldo CxsKFnNLJaaZ80K+0cFlU38TRolGdj8/PZXiZ6khH1pdaAlY9MN3uq1qvmNHVXXUpd3t bxIGYLdb6EUceJ3+d+pJFuR1c3LETotb9FDROYhI7AsHMSddJEa8qsQsSD3VzLnhAey7 7Z1v15i1ot6VJ8kL2HqRqD7fu09Ozigw5Mq7IGFd90/gJ6x9aDn0wWjjLLlEj9qy2G3E 83+g== X-Gm-Message-State: AKGB3mKmDgtjK0AIF1tNKgUY1RAaKNycBtkUhCpKIiwiI2ktYydUNR+n oYff3R2hNDi7V/kzEM3fsfnoloA69mYHJbYYxok+4A== X-Google-Smtp-Source: ACJfBosZz07e2NLcufoXUR+DoXaxj0C7XrD4V1CwqYxdqO69Fv/N+HwDE04LcygrwYhmAYeSzYplmYRV5d7BIPwe0Ao= X-Received: by 10.37.201.71 with SMTP id z68mr29948975ybf.140.1515960921309; Sun, 14 Jan 2018 12:15:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.42.6 with HTTP; Sun, 14 Jan 2018 12:15:20 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 14 Jan 2018 21:15:20 +0100 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="001a114d74f83559bc0562c22837" Archived-At: Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 20:15:24 -0000 --001a114d74f83559bc0562c22837 Content-Type: text/plain; charset="UTF-8" Back during the previous last call, I felt really guilty about bringing up the 0-RTT stuff so late. Even though it turned out that middle boxes turned out to be a bigger problem to deal with anyway, I just want to say that I'm really grateful for the 0-RTT related changes in the document and for the time and effort that went into all that. I think those changes are sufficient to make a TLS1.3 implementation that handles 0-RTT in a forward-secret, secure and safe way. The changes represent a good compromise between having a secure state and supporting vendors who want to be a bit more loose because their application environment can tolerate it and forward secrecy is not as valuable to their users. Thanks especially to ekr for inventing the fixes, for stewarding the clarifications, and for being awesome about it. At the same time, I just want to add a small note of caution to vendors; if you're going to accept 0-RTT, trying to cut corners by tolerating replays - even a little, is really likely to bite you! I've found even more examples of application protocols and web protocols that implement transactions. Also, if the secrecy of trillions and trillions of users web requests are going to rest on how well session ticket encryption keys are managed, protected, rotated and revoked, we really owe it to users to come up with some collective guidance for vendors on how to do that well. On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner wrote: > All, > > This is the 3rd working group last call (WGLC) announcement for > draft-ietf-tls-tls13; it will run through January 26th. This time the WGLC > is for version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). > This WGLC is a targeted WGLC because it only address changes introduced > since the 2nd WGLC on version -21, i.e., changes introduced in versions -22 > and -23. Note that the editor has kindly included a change log in s1.2 and > the datatracker can also produce diffs (https://www.ietf.org/rfcdiff? > url1=draft-ietf-tls-tls13-21&url2=draft-ietf-tls-tls13-23). In general, > we are considering all other material to have WG consensus, so only > critical issues should be raised about that material at this time. > > Cheers, > > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm --001a114d74f83559bc0562c22837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Back during the previous last call, I = felt really guilty about bringing up the 0-RTT stuff so late. Even though i= t turned out that middle boxes turned out to be a bigger problem to deal wi= th anyway, I just want to say that I'm really grateful for the 0-RTT re= lated changes in the document and for the time and effort that went into al= l that. I think those changes are sufficient to make a TLS1.3 implementatio= n that handles 0-RTT in a forward-secret, secure and safe way. The changes = represent a good compromise between having a secure state and supporting ve= ndors who want to be a bit more loose because their application environment= can tolerate it and forward secrecy is not as valuable to their users. Tha= nks especially to ekr for inventing the fixes, for stewarding the clarifica= tions, and for being awesome about it.=C2=A0

At th= e same time, I just want to add a small note of caution to vendors; if you&= #39;re going to accept 0-RTT, trying to cut corners by tolerating replays -= even a little, is really likely to bite you! I've found even more exam= ples of application protocols and web protocols that implement transactions= . Also, if the secrecy of trillions and trillions of users web requests are= going to rest on how well session ticket encryption keys are managed, prot= ected, rotated and revoked, we really owe it to users to come up with some = collective guidance for vendors on how to do that well.


On Fri, Jan 12, 2018 at 9:1= 0 PM, Sean Turner <sean@sn3rd.com> wrote:
All,

This is the 3rd working group last call (WGLC) announcement for draft-ietf-= tls-tls13; it will run through January 26th.=C2=A0 This time the WGLC is fo= r version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).=C2=A0 This WGLC is a targeted WGLC becau= se it only address changes introduced since the 2nd WGLC on version -21, i.= e., changes introduced in versions -22 and -23.=C2=A0 Note that the editor = has kindly included a change log in s1.2 and the datatracker can also produ= ce diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&url2=3Ddraft-ietf-tls-tls13-23).=C2=A0 In general, we are considerin= g all other material to have WG consensus, so only critical issues should b= e raised about that material at this time.

Cheers,

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



--
Colm
--001a114d74f83559bc0562c22837-- From nobody Sun Jan 14 12:48:15 2018 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 96E6712D887 for ; Sun, 14 Jan 2018 12:48:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 exKI42Fo7mlZ for ; Sun, 14 Jan 2018 12:48:08 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 8CFDC12D87D for ; Sun, 14 Jan 2018 12:48:04 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id a82so4971851ybg.1 for ; Sun, 14 Jan 2018 12:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9xlf/PKEZJFJxI3Ktq16ky9wgnxCP5ZjtFcBZgTT9WQ=; b=f83IZFo270VrD/a71KYeNUQZNA+xOA+lND4V8QXrWVajxOK7qXqWegl3+lGJ/YOVV4 g1V5Ax9q1g9Z23EbX3DIxVvfDi5diQCqpQSHMCeWVAIviO0bM8n4vVrQFRObhIDA25Bs dq8bdwPDzwM2Y3fGAAfZC1AFX7cJP9BZtPe1LKdT3yIobwntLfRpHzufZPnADdMpMHAt O17wN47GwrixZ7bcxkRLMzsHnlAuuPWWmWcQBe4Z0DFgy38nBWvLohS31lpM57ppsvQh bsRqU5W2FaznW1X/DFPJ2MJ9LeM8bnq2f/+dwF056k9TkAXDtYP1HTdJP7kH06t+aJTG UVNQ== 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:references:from:date :message-id:subject:to:cc; bh=9xlf/PKEZJFJxI3Ktq16ky9wgnxCP5ZjtFcBZgTT9WQ=; b=ft3ORgwUH6RLKqAZeLiNu8h/0U/uB+wKUBm84mNFBGZMq07kaJI8tpRy57PRYwRltF i3OAu+q/gbxxuHF+IEcBeR3rUcN7CPoqU3CtaZWBF5QA1wV4Yk3a/sdrU9PFyZ8BPG6Y 99mPR2lQz8iPBtcOn602WywZwdjw0uGRfei0VWkrbaktvpUg/2vIG08hC6TeGBPIFqSL zg0xY4p5X+4oH1Tvxoi+Zuem/RMX1TxShhpalXHIdqJw4DbSdfDSG7oQ4cDyya0XX1iH q2k2d3l6w4y34Cz9KHM+D7kkRTVPuwjacFumZPz4AJpJahdev6eOATKfGuD617Bf50PL 8MOA== X-Gm-Message-State: AKGB3mIydBtGdItXWiv8mIEOqSR4H8SlRYue2LWBWl8iFn21ZEguO4vc Vn66dpnDdGyQHW7idrMeUdkie9L+OuCuCz3iDHec8Q== X-Google-Smtp-Source: ACJfBosUTh5j6C4w/sFvfQaGkaH9YrhakRnygGehLS7TE75ZWwPjofadTxvtsh618wNXdResHMYCPanW5Y+ZWD+x9gM= X-Received: by 10.37.239.79 with SMTP id w15mr24603482ybm.293.1515962883683; Sun, 14 Jan 2018 12:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.66 with HTTP; Sun, 14 Jan 2018 12:47:23 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 14 Jan 2018 12:47:23 -0800 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="089e0828a13c2cd07d0562c29d61" Archived-At: Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 20:48:11 -0000 --089e0828a13c2cd07d0562c29d61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Colm, Thanks for your note. This seems straightforward to handle before IETF-LC. Maybe something like: "Note: many application layer protocols implicitly assume that replays are handled at lower levels. Tailure to observe these precautions may exposes your application to serious risks which are difficult to assess without a thorough top-to-bottom analysis of the application stack"? -Ekr On Sun, Jan 14, 2018 at 12:15 PM, Colm MacC=C3=A1rthaigh wrote: > > Back during the previous last call, I felt really guilty about bringing u= p > the 0-RTT stuff so late. Even though it turned out that middle boxes turn= ed > out to be a bigger problem to deal with anyway, I just want to say that I= 'm > really grateful for the 0-RTT related changes in the document and for the > time and effort that went into all that. I think those changes are > sufficient to make a TLS1.3 implementation that handles 0-RTT in a > forward-secret, secure and safe way. The changes represent a good > compromise between having a secure state and supporting vendors who want = to > be a bit more loose because their application environment can tolerate it > and forward secrecy is not as valuable to their users. Thanks especially = to > ekr for inventing the fixes, for stewarding the clarifications, and for > being awesome about it. > > At the same time, I just want to add a small note of caution to vendors; > if you're going to accept 0-RTT, trying to cut corners by tolerating > replays - even a little, is really likely to bite you! I've found even mo= re > examples of application protocols and web protocols that implement > transactions. Also, if the secrecy of trillions and trillions of users we= b > requests are going to rest on how well session ticket encryption keys are > managed, protected, rotated and revoked, we really owe it to users to com= e > up with some collective guidance for vendors on how to do that well. > > > On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner wrote: > >> All, >> >> This is the 3rd working group last call (WGLC) announcement for >> draft-ietf-tls-tls13; it will run through January 26th. This time the W= GLC >> is for version -23 (https://datatracker.ietf.org/ >> doc/draft-ietf-tls-tls13/). This WGLC is a targeted WGLC because it >> only address changes introduced since the 2nd WGLC on version -21, i.e., >> changes introduced in versions -22 and -23. Note that the editor has >> kindly included a change log in s1.2 and the datatracker can also produc= e >> diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&u >> rl2=3Ddraft-ietf-tls-tls13-23). In general, we are considering all othe= r >> material to have WG consensus, so only critical issues should be raised >> about that material at this time. >> >> Cheers, >> >> spt >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0828a13c2cd07d0562c29d61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Colm,

Thanks for your note. This see= ms straightforward to handle before IETF-LC.

Maybe= something like:
"Note: many application layer protocols imp= licitly assume that replays are handled at lower levels. Tailure to observe= these precautions may exposes your application to serious risks which are = difficult to assess without a thorough top-to-bottom analysis of the applic= ation stack"?

-Ekr

=

On Sun, Jan 14, 2= 018 at 12:15 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> = wrote:

Back during the previous last call, I felt really guilty about bringing = up the 0-RTT stuff so late. Even though it turned out that middle boxes tur= ned out to be a bigger problem to deal with anyway, I just want to say that= I'm really grateful for the 0-RTT related changes in the document and = for the time and effort that went into all that. I think those changes are = sufficient to make a TLS1.3 implementation that handles 0-RTT in a forward-= secret, secure and safe way. The changes represent a good compromise betwee= n having a secure state and supporting vendors who want to be a bit more lo= ose because their application environment can tolerate it and forward secre= cy is not as valuable to their users. Thanks especially to ekr for inventin= g the fixes, for stewarding the clarifications, and for being awesome about= it.=C2=A0

At the same time, I just want to add a = small note of caution to vendors; if you're going to accept 0-RTT, tryi= ng to cut corners by tolerating replays - even a little, is really likely t= o bite you! I've found even more examples of application protocols and = web protocols that implement transactions. Also, if the secrecy of trillion= s and trillions of users web requests are going to rest on how well session= ticket encryption keys are managed, protected, rotated and revoked, we rea= lly owe it to users to come up with some collective guidance for vendors on= how to do that well.


On Fri, Jan 12, 2018 at 9:10 PM, Sea= n Turner <sean@sn3rd.com> wrote:
All,

This is the 3rd working group last call (WGLC) announcement for draft-ietf-= tls-tls13; it will run through January 26th.=C2=A0 This time the WGLC is fo= r version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).=C2=A0 This WGLC is a targeted WGLC becau= se it only address changes introduced since the 2nd WGLC on version -21, i.= e., changes introduced in versions -22 and -23.=C2=A0 Note that the editor = has kindly included a change log in s1.2 and the datatracker can also produ= ce diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&u<= wbr>rl2=3Ddraft-ietf-tls-tls13-23).=C2=A0 In general, we are considerin= g all other material to have WG consensus, so only critical issues should b= e raised about that material at this time.

Cheers,

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



--
Colm

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


--089e0828a13c2cd07d0562c29d61-- From nobody Sun Jan 14 14:09:44 2018 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 6172712D777 for ; Sun, 14 Jan 2018 14:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ReZZ5ViuiW4O for ; Sun, 14 Jan 2018 14:09:41 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 01919127076 for ; Sun, 14 Jan 2018 14:09:30 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id 37so9183982otv.6 for ; Sun, 14 Jan 2018 14:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aTs/EoYSk3Sccu28yN3DstmmCM9bs0/O2HZjEjyzleg=; b=UMDHD16jZZ9nLRNU2jIcYYHV3FGf7JHSKshPHSx/qDtUwIYS0fwzLtmttUmJ4RZags Tob+PlAYs+mFoU6LD8eyNf+DZGlgi/V6XKlMsKSft0DX+0FJ/zULKlG8uf9GXkKYsbIU gtam8JuDoGLRXWL3cT7DCNkPx4l9Dbtuu58DDr5NBm1hBsih5pY9CpNTYoXCbvdf9Mqp UMfGj6K5ZuI4wvvrDEtQBPwNtHyNVCFWYUsOiScqhv+H0PxrSUDcYQJTAQycWB0VRK05 k1SpAHwDt+YxyRgtqVmQpmUmY2/3J2ymBg0HHfcWiRN7afJK5uZ1Z8JVgPf0kDbYsZ5a 4cqw== 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:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aTs/EoYSk3Sccu28yN3DstmmCM9bs0/O2HZjEjyzleg=; b=q4lWO47e5F7v4mz+wSrUjzRBX2BC2gMafO5/ijYKYZxtUfYTcVXZsDnFL8YjJvg42M +m3uOOENO5kn2uFKTaABLPq9n/0gdPqh1Eqz2z+3md47+ZG92JNt5RO3ZLhGHBfE6hJY rnl72jFEkakZASM50MmMo6LIzKLbGe1rgCpB8O0F8B9hM+szdD1QTbxmrTbR7rlicErq l5DfuEb3nN128ZuacroHyz7QWGNl1cOFvyNds4Yxioup2OFuSuDakrGkS4LvicE2+Rtw rIUdEZHJVwbeZyuVL7Ej8mi74aj7t/xV0r+SJzuUJAg/txN+U1/Mye9OoZkVRtlmJIre 2lsw== X-Gm-Message-State: AKwxytec7IfQwWQu6oIoXtQtZoyKL8LuhfBuEdrUvkP3LAhMICTKrWe6 e/eMxXAGrZAB5B+IHJAVQU5dRSVe8r4ylHBKE40H0S+u X-Google-Smtp-Source: ACJfBou5Wx0UZdvMNJ2hoUES+2CrzWMUApkFutQa02JA6PPR8xfBbjLFIuMXtQktw/fC7GKVOaNloFLXDBsH7j75xnA= X-Received: by 10.157.16.120 with SMTP id o53mr5345350oto.103.1515967769101; Sun, 14 Jan 2018 14:09:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Sun, 14 Jan 2018 14:09:28 -0800 (PST) In-Reply-To: <20180113000206.6bc36af6@pc1> References: <20180113000206.6bc36af6@pc1> From: Martin Thomson Date: Mon, 15 Jan 2018 09:09:28 +1100 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 22:09:43 -0000 The research that this is built on isn't especially new: https://arxiv.org/abs/1607.01639 The interesting observation in that paper is that the results are obtained only from the subset of malware that uses its own TLS configuration. Those that used the Windows stack in a default configuration were removed from consideration. Now, it's possible that things have improved since that paper, but it suggests the presence of a gap that we might exploit. So I'm not so down on GREASE. On Sat, Jan 13, 2018 at 10:02 AM, Hanno B=C3=B6ck wrote: > Hi, > > This working group just went through a painful process of realizing > that deploying a new TLS version on the Internet is a hard task due to > broken devices. If you're not aware David Benjamin just gave a great > talk summarizing the issues: > https://www.youtube.com/watch?v=3D_mE_JmwFi1Y > > Today I found this article: > https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encry= pted_traffic/ > > tl;dr Cisco now says they can identify malware in TLS traffic by > carefully looking at it. > (For context: devices from Cisco were responsible for many of the > issues that made deploying TLS 1.3 hard, e.g. version intolerance on > load balancers and recently by not correctly terminating TLS in a > firewall.) > > > I'll dare to have a look into the future and make this imho very > plausible claim: > Cisco won't be the only vendor selling such things. We will see more > products that magically can identify "bad things" in TLS traffic by > applying everything from AI to Blockchain. > We will almost certainly see a whole new generation of devices doing > weirdness with TLS and who will drop or manipulate packages that contain > things they don't know (like... a version negotiation field with TLS > 1.4 or a large post quantum key exchange message). > > The question I want to ask: What can we do *now* to stop this from > happening when TLS 1.4 will be deployed? I have the feeling GREASE > won't be enough... > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Jan 14 14:41:51 2018 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 56A7E12D882 for ; Sun, 14 Jan 2018 14:41:49 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-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 QquK42F-UyhL for ; Sun, 14 Jan 2018 14:41:47 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 E299E12D890 for ; Sun, 14 Jan 2018 14:41:46 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id h62so3753711ybi.11 for ; Sun, 14 Jan 2018 14:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H0ICI05lvj7HtI08N2FaKXsW4OxlOugFRTrT6e2y7wU=; b=OYnOm8LQ3mBa/3dGKki/X1ze4OxW1uwEFUVLVRKxrNvWqFdkiOhTT30kwXPJQiJA5g NUUUd/pfZXnGl8aB2AXoBwUh4MaaEbx5KSffRv6l1sVcNZv+nkXJ46PmEG40DobyR/sK VsY2TNTFxtxIexbIGl0Hu/DQGJJVRfT8PW21EmeZg4cO6I2oJH0tBtfyw9N6j7FkNgdC c77SOIcU2oMfUdlga7yESOlUzWzbM4lVTIIVM6Mwz2KTjRp8lx+Y4fEM5ODuLAyY461J qs5gO4gE++u9DdEFBUp6Ec/saXVv/7mS/aBRhztoXky/s+zHfUprAW0DXFSFvZs0CLcm XkFw== 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:references:from:date :message-id:subject:to:cc; bh=H0ICI05lvj7HtI08N2FaKXsW4OxlOugFRTrT6e2y7wU=; b=AKLqRzIdilW+PBdgHKWJKcgyOjxBZF/ha//7+v+/ynEbVOZQU+BpZl5eps1my40LTT ggfn/6aHwlH+LOfUWiqPBmW7iP899rBuAH/EqpIuOrPd/8iRtzNmcO96+FDZvS2AfRss nkesfsmftr75OTqW3h0UZ9W/nWE0eA/Zg83wSskTZgI3cPp1steWMKaG6GQhw5yIMVVu HTwU6CE5MuwZuKkZ204rx46IXTHfgCNVm1WKF9I2v0beX6y00BvbetlU4aqyjdaG19jY lANf7AmUzPpso839o/knJCeiSPFDh+BXzHmnKOh/vC6JsDHvNBgf4umc6eGu69MTdTPg PwPw== X-Gm-Message-State: AKGB3mIk7pNwZxktyQN7cBem6dvX0JVFR9++G57vtTsgOEeLBpjceWvv vcxTNVRSR0g5lWtAF4ppmyAVDPeqTpdCj/yLzjk1xg== X-Google-Smtp-Source: ACJfBotGUq6EWO/Mg5RaJZvvGKy2oORAXzRZmUQURRRMrpc3cIGzjbfd39vPKPOhVFy1yGaDXiwXdSqb7rCxqP1rCi0= X-Received: by 10.37.10.65 with SMTP id 62mr30548978ybk.300.1515969706005; Sun, 14 Jan 2018 14:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.42.6 with HTTP; Sun, 14 Jan 2018 14:41:45 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 14 Jan 2018 23:41:45 +0100 Message-ID: To: Eric Rescorla Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="001a113db54ad127b60562c4335d" Archived-At: Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 22:41:49 -0000 --001a113db54ad127b60562c4335d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the abundant generosity of patience, but I didn't mean that I wanted to add a note to the text of the I-D, there's been enough delay and I'm excited to see this progress. I just meant "add a note" in my e-mail ;-) Though I do like your terse note, it's right to the point. On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla wrote: > Hi Colm, > > Thanks for your note. This seems straightforward to handle before IETF-LC= . > > Maybe something like: > "Note: many application layer protocols implicitly assume that replays ar= e > handled at lower levels. Tailure to observe these precautions may exposes > your application to serious risks which are difficult to assess without a > thorough top-to-bottom analysis of the application stack"? > > -Ekr > > > On Sun, Jan 14, 2018 at 12:15 PM, Colm MacC=C3=A1rthaigh > wrote: > >> >> Back during the previous last call, I felt really guilty about bringing >> up the 0-RTT stuff so late. Even though it turned out that middle boxes >> turned out to be a bigger problem to deal with anyway, I just want to sa= y >> that I'm really grateful for the 0-RTT related changes in the document a= nd >> for the time and effort that went into all that. I think those changes a= re >> sufficient to make a TLS1.3 implementation that handles 0-RTT in a >> forward-secret, secure and safe way. The changes represent a good >> compromise between having a secure state and supporting vendors who want= to >> be a bit more loose because their application environment can tolerate i= t >> and forward secrecy is not as valuable to their users. Thanks especially= to >> ekr for inventing the fixes, for stewarding the clarifications, and for >> being awesome about it. >> >> At the same time, I just want to add a small note of caution to vendors; >> if you're going to accept 0-RTT, trying to cut corners by tolerating >> replays - even a little, is really likely to bite you! I've found even m= ore >> examples of application protocols and web protocols that implement >> transactions. Also, if the secrecy of trillions and trillions of users w= eb >> requests are going to rest on how well session ticket encryption keys ar= e >> managed, protected, rotated and revoked, we really owe it to users to co= me >> up with some collective guidance for vendors on how to do that well. >> >> >> On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner wrote: >> >>> All, >>> >>> This is the 3rd working group last call (WGLC) announcement for >>> draft-ietf-tls-tls13; it will run through January 26th. This time the = WGLC >>> is for version -23 (https://datatracker.ietf.org/ >>> doc/draft-ietf-tls-tls13/). This WGLC is a targeted WGLC because it >>> only address changes introduced since the 2nd WGLC on version -21, i.e.= , >>> changes introduced in versions -22 and -23. Note that the editor has >>> kindly included a change log in s1.2 and the datatracker can also produ= ce >>> diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&u >>> rl2=3Ddraft-ietf-tls-tls13-23). In general, we are considering all oth= er >>> material to have WG consensus, so only critical issues should be raised >>> about that material at this time. >>> >>> Cheers, >>> >>> spt >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> >> -- >> Colm >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --=20 Colm --001a113db54ad127b60562c4335d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks for the abundant generosity of = patience, but I didn't mean that I wanted to add a note to the text of = the I-D, there's been enough delay and I'm excited to see this prog= ress. I just meant "add a note" in my e-mail ;-) Though I do like= your terse note, it's right to the point.=C2=A0

On Sun, Jan 14, 2018 at 9:47 PM, E= ric Rescorla <ekr@rtfm.com> wrote:
Hi Colm,

Thanks for your note. Th= is seems straightforward to handle before IETF-LC.

Maybe something like:
"Note: many application layer protoco= ls implicitly assume that replays are handled at lower levels. Tailure to o= bserve these precautions may exposes your application to serious risks whic= h are difficult to assess without a thorough top-to-bottom analysis of the = application stack"?

-Ekr

=
On Sun, Jan 14, 2018 at 12:15 PM, Colm MacC=C3= =A1rthaigh <colm@allcosts.net> wrote:

Back during the previous= last call, I felt really guilty about bringing up the 0-RTT stuff so late.= Even though it turned out that middle boxes turned out to be a bigger prob= lem to deal with anyway, I just want to say that I'm really grateful fo= r the 0-RTT related changes in the document and for the time and effort tha= t went into all that. I think those changes are sufficient to make a TLS1.3= implementation that handles 0-RTT in a forward-secret, secure and safe way= . The changes represent a good compromise between having a secure state and= supporting vendors who want to be a bit more loose because their applicati= on environment can tolerate it and forward secrecy is not as valuable to th= eir users. Thanks especially to ekr for inventing the fixes, for stewarding= the clarifications, and for being awesome about it.=C2=A0

At the same time, I just want to add a small note of caution to ve= ndors; if you're going to accept 0-RTT, trying to cut corners by tolera= ting replays - even a little, is really likely to bite you! I've found = even more examples of application protocols and web protocols that implemen= t transactions. Also, if the secrecy of trillions and trillions of users we= b requests are going to rest on how well session ticket encryption keys are= managed, protected, rotated and revoked, we really owe it to users to come= up with some collective guidance for vendors on how to do that well.
=

On Fri, Jan 12, 2018 at 9:10 PM, Sean Turne= r <sean@sn3rd.com> wrote:
All= ,

This is the 3rd working group last call (WGLC) announcement for draft-ietf-= tls-tls13; it will run through January 26th.=C2=A0 This time the WGLC is fo= r version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).=C2=A0 This WGLC is a targeted WGLC becau= se it only address changes introduced since the 2nd WGLC on version -21, i.= e., changes introduced in versions -22 and -23.=C2=A0 Note that the editor = has kindly included a change log in s1.2 and the datatracker can also produ= ce diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&u<= wbr>rl2=3Ddraft-ietf-tls-tls13-23).=C2=A0 In general, we are considerin= g all other material to have WG consensus, so only critical issues should b= e raised about that material at this time.

Cheers,

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



--
Colm

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





--
=
Colm
--001a113db54ad127b60562c4335d-- From nobody Mon Jan 15 04:37:30 2018 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 9B4EF1275C5 for ; Mon, 15 Jan 2018 04:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CXh8n8nTcfNH for ; Mon, 15 Jan 2018 04:37:28 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A081126E3A for ; Mon, 15 Jan 2018 04:37:28 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E8064883C4; Mon, 15 Jan 2018 12:37:27 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19DAA5D6A6; Mon, 15 Jan 2018 12:37:26 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 15 Jan 2018 13:37:20 +0100 Message-ID: <1831387.ULqcxPagE8@pintsize.usersys.redhat.com> In-Reply-To: <249425c3-780f-5850-366b-9d87d3b31af4@huitema.net> References: <20180113000206.6bc36af6@pc1> <57CA48F7-CC49-42A3-AF9B-BCB4778264B2@gmail.com> <249425c3-780f-5850-366b-9d87d3b31af4@huitema.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1567765.pWrhdgLdZ2"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 15 Jan 2018 12:37:27 +0000 (UTC) Archived-At: Subject: Re: [TLS] The future devices that will break TLS 1.4 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 12:37:29 -0000 --nextPart1567765.pWrhdgLdZ2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 13 January 2018 03:31:23 CET Christian Huitema wrote: > On 1/12/2018 1:53 PM, Dan Wing wrote: > > The question I want to ask: What can we do *now* to stop this from > > happening when TLS 1.4 will be deployed? I have the feeling GREASE > > won't be enough... >=20 > Data sets. Machine learning algorithms are trained with data sets. If we > produce reference data sets showing what TLS 1.4 looks like, the vendors > can retrain their AI and start recognizing the new version for what it > is, rather than some unknown attack. doesn't help with already deployed gear, and we really can't predict how TL= S=20 1.4 will look like to give examples of it to them right now =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1567765.pWrhdgLdZ2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpcoIAACgkQkqjRuAHS 9fVMvQ//QEW1TL24K70z74sxODnjWeWtvtTE2g3qr20ENpCe+ErGO7qotKiyKT8B V/RgcfPOyGwwkqTiOq9TZI8XPQN22rLzU22AM8cpQY971S7BcyxC0QWNN75oBYKK bO1JJcI3MXwGHGijlgkGi4OQqvFH5rX+GjdOTOHUIyu/fWh6I/rO8HC770FRBbV2 Skoj28Nv9JVBTLQcaiu5MsX/mD3ULuYT4jeT2JTNL5zi95oy/Lo1q59++UV+DuGl /26kP0CVvlFDAml0XaR6eaNQKKL3X4RheG754g3RfdAbAZj4i9gFddO6CJldxx6q kkZF2uILO0MVLQhmJUkZYGRUn4OsMtKunN7hdzkaC2G0nfufNk2tZponkKI+tLIe dYDBhJWkyOYHUzmz9zOy+TRe/2HzUZ5ApS1VNjRG7qr3eVp7AJKLT6yd/N/AlnD7 Bwu1KNvzYNL7nkcV21iaUDFfr1lCppOEFM+jeKY1faL99OCax7xz1vQkehov76tN U7txBBMl497ymgKHD2KKXcm8P0DjhaNUd3Bvz92zTgdfbdtxU1+D23ro5zbDeLDm NJu+2f/bTlgxnq/B6TKCRKTCEGwEdExcg8ERatR5d/UEwjQmzlKgmdtgZP9NBled o66UL1wt8n7VF3z7oKXDvZOM1Y+T8vvJSROo45mg9DS4LDVGiDM= =s3tM -----END PGP SIGNATURE----- --nextPart1567765.pWrhdgLdZ2-- From nobody Mon Jan 15 13:03:13 2018 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 8A3C312EBE8 for ; Mon, 15 Jan 2018 13:03:11 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=mobileironinc.onmicrosoft.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 blFKMRuN8swe for ; Mon, 15 Jan 2018 13:03:08 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0067.outbound.protection.outlook.com [104.47.33.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBF812D853 for ; Mon, 15 Jan 2018 13:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4UP/Uwc3A5rrG8VvBpfv9amEhlVrLUSlRc5wW83oKT4=; b=BEVsDhOV5NLMlIWngxt+s0IdW1SW48798HgtkUBUR9b9fNFPNEKUg/Jzt5XWIGKLJUY0TcxnKSC9rBJefxsd8bmOqXDKXB8hoLOixmdyeU7LDN6LZcTGp1XNQSFVye5aX1+dOkjV+HVd8+A0lBIV+fyEuBdSBMcZHgkIbzIarzg= Received: from BY2PR10MB0630.namprd10.prod.outlook.com (10.163.158.151) by BY2PR10MB0630.namprd10.prod.outlook.com (10.163.158.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Mon, 15 Jan 2018 21:03:05 +0000 Received: from BY2PR10MB0630.namprd10.prod.outlook.com ([10.163.158.151]) by BY2PR10MB0630.namprd10.prod.outlook.com ([10.163.158.151]) with mapi id 15.20.0407.009; Mon, 15 Jan 2018 21:03:05 +0000 From: Tim Jackson To: =?Windows-1252?Q?Colm_MacC=E1rthaigh?= , Eric Rescorla CC: "" Thread-Topic: [TLS] 3rd WGLC: draft-ietf-tls-tls13 Thread-Index: AQHTi+FzrAwCbfjaykaSbsEjUKnPxaNz0QoAgAAI9ICAAB/0gIABdsOB Date: Mon, 15 Jan 2018 21:03:04 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tjackson@mobileiron.com; x-originating-ip: [204.8.168.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR10MB0630; 7:m9R6CWu+VnkvlIweepO5+Lkj0hcEbeb/1zpXaf/py/+NW9cToGVa0p7acoBXFVwomtHO47yvMlWdxCwBOu7gkvcALt1o40qDY+NDqpIRmLyhUd5AALW7mkA6dbyT54Wt4V+5jBZ9d6iNZcBHLQ/n0j8rJk6os2UlZ1yzxLrYQvob0nqkOS9R8CaV4Xy4oyHegMKRpO6hvAAW4NVxfd3miVDwhaG3ljTCNiNNLUWSVCgaqy2IbRbQSb5CSy3AgVet x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6c653149-a488-4e6a-2481-08d55c5b5f1e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR10MB0630; x-ms-traffictypediagnostic: BY2PR10MB0630: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(3231023)(944501161)(93006095)(93001095)(3002001)(6041268)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR10MB0630; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR10MB0630; x-forefront-prvs: 0553CBB77A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39850400004)(39380400002)(376002)(366004)(52314003)(24454002)(199004)(189003)(54534003)(51914003)(6246003)(95246002)(966005)(478600001)(8936002)(81166006)(105586002)(68736007)(106356001)(66066001)(81156014)(25786009)(2900100001)(7736002)(4326008)(5660300001)(8676002)(230783001)(6116002)(3280700002)(3846002)(102836004)(6512007)(6506007)(6486002)(97736004)(236005)(77096006)(606006)(3660700001)(53546011)(51650200002)(2906002)(76176011)(229853002)(93886005)(316002)(54896002)(2950100002)(110136005)(14454004)(6436002)(53936002)(59450400001)(6306002)(86362001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR10MB0630; H:BY2PR10MB0630.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mobileiron.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: v2KtmJ1fwo3E7nXSUO7pkgHXCPaBWDoi5C0bJBhY8MypMuSEHcItKV+jD3EPSWKw8qMFCsZeOeYrzUQD89o0hw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_jjan5b2l9sb3158i182c3pbp1516050184016emailplusmobileiro_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c653149-a488-4e6a-2481-08d55c5b5f1e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 21:03:04.8352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR10MB0630 Archived-At: Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 21:03:11 -0000 --_000_jjan5b2l9sb3158i182c3pbp1516050184016emailplusmobileiro_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable EKR, If you are going to add this (seems like a reasonable idea to me) please no= te the minor typo of =93tailure=94, which I presume should be failure. Tim Sent from Email+ secured by MobileIron ________________________________ From: "Colm MacC=E1rthaigh" > Date: Sunday, January 14, 2018 at 2:42:04 PM To: "Eric Rescorla" > Cc: "" > Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 Thanks for the abundant generosity of patience, but I didn't mean that I wa= nted to add a note to the text of the I-D, there's been enough delay and I'= m excited to see this progress. I just meant "add a note" in my e-mail ;-) = Though I do like your terse note, it's right to the point. On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla > wrote: Hi Colm, Thanks for your note. This seems straightforward to handle before IETF-LC. Maybe something like: "Note: many application layer protocols implicitly assume that replays are = handled at lower levels. Tailure to observe these precautions may exposes y= our application to serious risks which are difficult to assess without a th= orough top-to-bottom analysis of the application stack"? -Ekr On Sun, Jan 14, 2018 at 12:15 PM, Colm MacC=E1rthaigh > wrote: Back during the previous last call, I felt really guilty about bringing up = the 0-RTT stuff so late. Even though it turned out that middle boxes turned= out to be a bigger problem to deal with anyway, I just want to say that I'= m really grateful for the 0-RTT related changes in the document and for the= time and effort that went into all that. I think those changes are suffici= ent to make a TLS1.3 implementation that handles 0-RTT in a forward-secret,= secure and safe way. The changes represent a good compromise between havin= g a secure state and supporting vendors who want to be a bit more loose bec= ause their application environment can tolerate it and forward secrecy is n= ot as valuable to their users. Thanks especially to ekr for inventing the f= ixes, for stewarding the clarifications, and for being awesome about it. At the same time, I just want to add a small note of caution to vendors; if= you're going to accept 0-RTT, trying to cut corners by tolerating replays = - even a little, is really likely to bite you! I've found even more example= s of application protocols and web protocols that implement transactions. A= lso, if the secrecy of trillions and trillions of users web requests are go= ing to rest on how well session ticket encryption keys are managed, protect= ed, rotated and revoked, we really owe it to users to come up with some col= lective guidance for vendors on how to do that well. On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner > wrote: All, This is the 3rd working group last call (WGLC) announcement for draft-ietf-= tls-tls13; it will run through January 26th. This time the WGLC is for ver= sion -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/). This WG= LC is a targeted WGLC because it only address changes introduced since the = 2nd WGLC on version -21, i.e., changes introduced in versions -22 and -23. = Note that the editor has kindly included a change log in s1.2 and the data= tracker can also produce diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-i= etf-tls-tls13-21&url2=3Ddraft-ietf-tls-tls13-23). In general, we are consi= dering all other material to have WG consensus, so only critical issues sho= uld be raised about that material at this time. Cheers, spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Colm _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Colm --_000_jjan5b2l9sb3158i182c3pbp1516050184016emailplusmobileiro_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
EKR,

If you are going to add this (seems like a reasonable idea to me) please no= te the minor typo of =93tailure=94, which I presume should be failure.

Tim

Sent from Email+ secured by MobileIron



From: "Colm MacC=E1rthaigh" <colm@allcosts.net>
Date: Sunday, January 14, 2018 at 2:42:04 PM
To: "Eric Rescorla" <ek= r@rtfm.com>
Cc: "" <tls@ietf.org>
Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13


Thanks for the abundant generosity of patience, but I didn't mean that= I wanted to add a note to the text of the I-D, there's been enough delay a= nd I'm excited to see this progress. I just meant "add a note" in= my e-mail ;-) Though I do like your terse note, it's right to the point. 

On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla <= span dir=3D"ltr"> <ekr@rtfm.com><= /span> wrote:
Hi Colm,

Thanks for your note. This seems straightforward to handle before IETF= -LC.

Maybe something like:
"Note: many application layer protocols implicitly assume that re= plays are handled at lower levels. Tailure to observe these precautions may= exposes your application to serious risks which are difficult to assess wi= thout a thorough top-to-bottom analysis of the application stack"?

-Ekr


On Sun, Jan 14, 2018 at 12:15 PM, Colm MacC=E1rt= haigh <colm@allcosts.ne= t> wrote:

Back during the previous last call, I felt really guilty about bringin= g up the 0-RTT stuff so late. Even though it turned out that middle boxes t= urned out to be a bigger problem to deal with anyway, I just want to say th= at I'm really grateful for the 0-RTT related changes in the document and for the time and effort that went into= all that. I think those changes are sufficient to make a TLS1.3 implementa= tion that handles 0-RTT in a forward-secret, secure and safe way. The chang= es represent a good compromise between having a secure state and supporting vendors who want to be a bit more loo= se because their application environment can tolerate it and forward secrec= y is not as valuable to their users. Thanks especially to ekr for inventing= the fixes, for stewarding the clarifications, and for being awesome about it. 

At the same time, I just want to add a small note of caution to vendor= s; if you're going to accept 0-RTT, trying to cut corners by tolerating rep= lays - even a little, is really likely to bite you! I've found even more ex= amples of application protocols and web protocols that implement transactions. Also, if the secrecy of tri= llions and trillions of users web requests are going to rest on how well se= ssion ticket encryption keys are managed, protected, rotated and revoked, w= e really owe it to users to come up with some collective guidance for vendors on how to do that well.


On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner <sean@sn3rd.com&= gt; wrote:
All,

This is the 3rd working group last call (WGLC) announcement for draft-ietf-= tls-tls13; it will run through January 26th.  This time the WGLC is fo= r version -23 (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/).  This WGLC is a targeted WGLC because it only address changes introduced si= nce the 2nd WGLC on version -21, i.e., changes introduced in versions -22 a= nd -23.  Note that the editor has kindly included a change log in s1.2= and the datatracker can also produce diffs (https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-tls13-21&url2=3Ddraft-ietf-tls-tls13-23).  In general, we are considering all other material to have WG consensus, so only critical = issues should be raised about that material at this time.

Cheers,

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



--
= Colm

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





--
Colm
--_000_jjan5b2l9sb3158i182c3pbp1516050184016emailplusmobileiro_-- From nobody Mon Jan 15 13:34:54 2018 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 8A1B512EC6D for ; Mon, 15 Jan 2018 13:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9k-lXm5vBg95 for ; Mon, 15 Jan 2018 13:34:50 -0800 (PST) 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 183A912EC6E for ; Mon, 15 Jan 2018 13:34:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A940ABE3E; Mon, 15 Jan 2018 21:34:46 +0000 (GMT) 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 DwLU9sgWCe20; Mon, 15 Jan 2018 21:34:42 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D140BBE38; Mon, 15 Jan 2018 21:34:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1516052082; bh=uS4NJTqSUah2X2BJUcP1y3guRG3sNsAG/QsDEdjRMfA=; h=Subject:References:To:Cc:From:Date:In-Reply-To:From; b=VXX7EqZ1lGSBbHliwuNycUt8PeWFhbz4/StLaLqHmtjZrCVPiw+LPHEt9ExtnuJmv q634wpzvdIkliXIzxE9lyBWqsU60x7FSuPOAvhIAWqavXPo0TKRE+ylsBykYpyJPxy zgVfBhhJ4KS4lL2+Ok3cMOZIsUozvK/GzriVty+8= References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> To: tls@ietf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> Date: Mon, 15 Jan 2018 21:34:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151498784861.30913.14397405953795919592@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ihBF9s7wo99XPQccA18hlxYiweDoqz9wH" Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 21:34:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ihBF9s7wo99XPQccA18hlxYiweDoqz9wH Content-Type: multipart/mixed; boundary="i9TAWv9vPo4xTnBd2IDTI8bAhkmf6CHL2"; protected-headers="v1" From: Stephen Farrell To: tls@ietf.org Cc: Kathleen Moriarty Message-ID: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> Subject: WGLC for draft-ietf-tls-iana-registry-updates-03.txt References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> In-Reply-To: <151498784861.30913.14397405953795919592@ietfa.amsl.com> --i9TAWv9vPo4xTnBd2IDTI8bAhkmf6CHL2 Content-Type: multipart/mixed; boundary="------------2728B9F31B769DBA89D04778" Content-Language: en-GB This is a multi-part message in MIME format. --------------2728B9F31B769DBA89D04778 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Kathleen's a bit busy at the moment so asked that, as shepherd, I kick off the WGLC for this one (as the two chairs are authors). The idea is that I'll summarise the WGLC thread to her and she can then decide if this is ready to move forward. So this starts a 2-week WGLC, ending on January 29th. Cheers, Shepherdy Stephen. On 03/01/18 13:57, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-03.txt > Pages : 16 > Date : 2018-01-03 >=20 > Abstract: > This document describes a number of changes to (D)TLS IANA registrie= s > that range from adding notes to the registry all the way to changing= > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-upda= tes-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-update= s-03 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------2728B9F31B769DBA89D04778 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------2728B9F31B769DBA89D04778-- --i9TAWv9vPo4xTnBd2IDTI8bAhkmf6CHL2-- --ihBF9s7wo99XPQccA18hlxYiweDoqz9wH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaXR5xAAoJEFqy+vF7FyvqVasP/0Ry+uEgjqZ4bZswV/N+Sacc 6vVv+lTrR5kmmL77csnCmY15rMC+pRjnZIMmlWGQY8ogTbBHMnuLmCjV6pR+ca59 X4vsmE+E/rL8DZagE9whgA+Aq0PqEJE9Dc+9xbm927qKElFfIRAvrBa9EmAKcVv3 2UIaBPlf9z/zGYhTSY0PmNA9zHEaGCmTaxtsqdNRbSTYXY7BQSGqq5T4yNpO0EHu /lwBgB9k3D9F1FjOKZeEJ48CH88i2vC35iJgFqvvx7scLY20Qrw19hZaVPj06WzG bDZRU8UFo5wk5Pg1ODs4512Yo4sr3xJHIZIyDZOcC0BWdyq12oodJx1IE6bEphKX uU4sKkCy1NPNxBFyZc0mIvBvs/TdmIJv3X7UKSCV96UICDgvuBcC1CvJuPMTo6T+ se3wMzrrC3No4/0Oe16wAZ2KzLomx4mxMqMifFa1UxcBZ07C6eeDFQJVF65s5bp0 FVPQ/N10BO5mEZT7ZXkTyd7bR2s6LLuPKNeCGN6uKoqRwDx64Dn9UnwFCznsrbea dogYZz7AU6I+tePoqj8XQEAR3pcFTYTr6MJ/f6GTtRf82/RfLlsMvWoBqBfHEtu3 fsUZbVlXeoO6zfMTMonav8+5gJKzP0SA9gNzUmObNI3zBvd/x3Shm/qbHk91UtKI 5nozRusUNCtqSNroMWDO =pjmE -----END PGP SIGNATURE----- --ihBF9s7wo99XPQccA18hlxYiweDoqz9wH-- From nobody Mon Jan 15 14:38:33 2018 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 CA86412EC93 for ; Mon, 15 Jan 2018 14:38:31 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uPO02Nh_ugLV for ; Mon, 15 Jan 2018 14:38:30 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 4E419124BAC for ; Mon, 15 Jan 2018 14:38:30 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 53so11969140otj.2 for ; Mon, 15 Jan 2018 14:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3zTQeFw7wgh8n0BVqF/O71md4w5/RTCqYnrJFFL2Jmc=; b=KVRuUTwacOCXABBlQn2ES/020isNiblmtKh43sNy/dHRViOs7ArJlMDdS70pWnN4Ph 5tPfWTgPCZXV/EvcE3eAcXlcsfIrGCWS0M5fuBnzmzOVQGUBJdZEJJ3Ee9Ib//z6nXkU S4oMJXFcU+1X8+ww0HBUy5PqcbW/P5cxfUUa7Ckcv5xzvw4m/pavHMrdK5tORQ2qXQZi iZ2eJIZP3xrh5m/aYlK9q3Zq6n/jxWwc/leWmK/yAKDByeW4zPdJ7AndolFbAZd02ofW /doz0f9EwcYRiNoGEgkq/IFa5M9g74bQ/Q5TV/N/NWA3V0GaeH0PgLFMLonapYB7bkZp glNw== 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:references:from:date :message-id:subject:to:cc; bh=3zTQeFw7wgh8n0BVqF/O71md4w5/RTCqYnrJFFL2Jmc=; b=jeybjK3WIj14C4H82Q1BHcnTNsQtFJJgxXbnU+WKYPrWRWK4goZaAtQ5cv/UY04oSk po69DJYd08gnEe1mXjThrYWeJ1TPW4xB9QGROV1Die+C8Yx2LNwIlK+LBSjhcTr+VxQN lHvi9ZwOVEPGgr4frCiXqyEOonXuWfmuet4XWBno8wftjZTxeZ5pYvt03sgdLb3Ntfr7 gD78/aL/BlUp0qzc/kW50noBXJWBj4UIJwPZ6MIPczS8KT45neCahnRMzkiQpw2DL1BO bvsLx3wzWL5nXyWgrE1vwm2LZf6aJyhhegYxXLzaQk46IHE6PV1TgY6jkQKU/sqitp8j 40BA== X-Gm-Message-State: AKwxytfZn2GPYzfUvpOvcvtezytRSCgoei704oeFhtMyEMtxA5p2OQ4R 19eodEx5vANJoht0AnStoD2Jm44Hru/eyEirXw632qIT X-Google-Smtp-Source: ACJfBotBvd2OAZax38tEyZMQyr93bseHqzf7Cp5q41RHzsoF0WxE1mWNRD5yBtuAUtWkQnM7tLSpU++I42ZX8QJQC+U= X-Received: by 10.157.16.120 with SMTP id o53mr7425631oto.103.1516055909568; Mon, 15 Jan 2018 14:38:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Mon, 15 Jan 2018 14:38:29 -0800 (PST) In-Reply-To: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> From: Martin Thomson Date: Tue, 16 Jan 2018 09:38:29 +1100 Message-ID: To: Stephen Farrell Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 22:38:32 -0000 On Tue, Jan 16, 2018 at 8:34 AM, Stephen Farrell wrote: > So this starts a 2-week WGLC, ending on January 29th. Ship it! Nits: 6. Adding recommended Column <- capital R, consider "Recommended" to match later text. 8. TLS ExtensionType Values <- TLS 1.3 adds more columns to this table; this document should align with that (particularly since it already depends on TLS 1.3) I'm almost comfortable with this statement, though I'd like to confirm that others are also: "Despite the following behavior being crazy, [...]" From nobody Mon Jan 15 20:13:12 2018 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 E944112F2AD for ; Mon, 15 Jan 2018 20:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 4DG3Fg1GYkoJ for ; Mon, 15 Jan 2018 20:13:09 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 383BD126C26 for ; Mon, 15 Jan 2018 20:13:09 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id i141so19410219qke.0 for ; Mon, 15 Jan 2018 20:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JKs23A7GSwGWaup0LxT81/+ItzBl5u4Ti8bMfenWn2Q=; b=P/SsNfXOyUWLe3aJEG2timP47NeSB3BXqSHuJX/BvAEC50zhmbCBlIC2Jx8r9gBU8y gKJvC4vtW2UbzAKDa82Oo2NQ31d1FfoJxzhSvw46QS7aaV6XyfaD48ofaMjr8grLoSu4 XYkkK4NmgysV+rBW3BKdMZ8S/A4Pap9rEfnCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JKs23A7GSwGWaup0LxT81/+ItzBl5u4Ti8bMfenWn2Q=; b=gN/E6vpoJsJ/PrQxnNq2zAu7Mml3w0fYlHeaclrUAGmmp1dLOBaMg6jXoO3+EvTqOg V8SOdaCH69hYhKwFG5AnLJjFcnObKDeVDmxtZ7Tv+ce46PWQA+u9eui/5H4zYWsSyXCN Nu0CKyepuH1m5wB6sBVRbrJCHLa7ottuOM2JJOoBGYUUlGnFIoytTus4aUE4iI1wD5jq npZJerOBbMrSehfCWnjXkAR9w8TQ1bqpWCrlPibAqF0/4TrWnAipxr3dG6kD1dDc9Hw4 DL/1i1nfGkTMScO/3JGAEsJ5Cb7lGeBjENfgsTb1pLJiz+RSIt3MlQzs0i2c6IySUy3O vDcg== X-Gm-Message-State: AKwxytc5Iw+IEPo524f6jKsJGCoCQQ18wKTnZJNj68ZJyQYO7FZf7P/f nJR/odLreH0KUB3FieN7HuxE3li19AA= X-Google-Smtp-Source: ACJfBotoIYj722W6PsilmATFYTTNv5XBb498jgHiLl8LThMImBApbDEXQEBQepBfmW2TpHIQhpU3og== X-Received: by 10.55.105.194 with SMTP id e185mr53091948qkc.192.1516075988261; Mon, 15 Jan 2018 20:13:08 -0800 (PST) Received: from [172.16.0.18] ([96.231.222.30]) by smtp.gmail.com with ESMTPSA id v11sm815083qtg.6.2018.01.15.20.13.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jan 2018 20:13:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> Date: Mon, 15 Jan 2018 23:13:06 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <910FC587-952F-461F-A544-1CAF32A9ECAE@sn3rd.com> References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 04:13:12 -0000 I=E2=80=99ll set the datatracker status. spt > On Jan 15, 2018, at 16:34, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Kathleen's a bit busy at the moment so asked that, as shepherd, > I kick off the WGLC for this one (as the two chairs are authors). > The idea is that I'll summarise the WGLC thread to her and she > can then decide if this is ready to move forward. >=20 > So this starts a 2-week WGLC, ending on January 29th. >=20 > Cheers, > Shepherdy Stephen. >=20 > On 03/01/18 13:57, internet-drafts@ietf.org wrote: >>=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 : IANA Registry Updates for TLS and DTLS >> Authors : Joe Salowey >> Sean Turner >> Filename : draft-ietf-tls-iana-registry-updates-03.txt >> Pages : 16 >> Date : 2018-01-03 >>=20 >> Abstract: >> This document describes a number of changes to (D)TLS IANA = registries >> that range from adding notes to the registry all the way to = changing >> the registration policy. These changes were mostly motivated by WG >> review of the (D)TLS-related registries undertaken as part of the >> TLS1.3 development process. This document updates many (D)TLS RFCs >> (see updates header). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -03 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 3 >>=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 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > --=20 > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > <0x7B172BEA.asc>_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jan 18 03:30:04 2018 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 18CBA12D880 for ; Thu, 18 Jan 2018 03:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 C0PL6nj0Htmr for ; Thu, 18 Jan 2018 03:30:01 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEAE12D80F for ; Thu, 18 Jan 2018 03:30:00 -0800 (PST) Received: from [10.56.10.6] (ip-45-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 80FFEE790B for ; Thu, 18 Jan 2018 11:29:57 +0000 (UTC) From: Matt Caswell To: "tls@ietf.org" Message-ID: <50eb8f92-b0b2-faab-6f48-14d820480f7d@openssl.org> Date: Thu, 18 Jan 2018 11:29:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] signature_algorithms_cert extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 11:30:03 -0000 The specification of the new signature_algorithms_cert seems somewhat lacking to me. There is very little description about how it should be interpreted. About the best I can get from the spec is this: The "signature_algorithms_cert" extension applies to signatures in certificates and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages. But in section 4.4.2.2 we see this: All certificates provided by the server MUST be signed by a signature algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. Is this an oversight? Should this reference "signature_algorithms_cert" as well/instead? Some questions: - Is "signature_algorithms_cert" mandatory to implement for servers? It does not appear in 9.2 so I am assuming not. There is some text in 4.2.3 which says what to do if "signature_algorithms_cert" is not present - which seems to confirm that it is not mandatory for clients at least. - Are we allowed to ignore "signature_algorithms_cert" if we can't build a chain and honour its contents? Matt From nobody Thu Jan 18 05:17:05 2018 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 1B9B912700F for ; Thu, 18 Jan 2018 05:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 I0VvgjF6udzK for ; Thu, 18 Jan 2018 05:17:01 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 450D512421A for ; Thu, 18 Jan 2018 05:17:01 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id t201so11162834ywf.1 for ; Thu, 18 Jan 2018 05:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o55SAbx+OOHSYtMvzHRuqhNUVb6FCjigR7I5H/qHjvg=; b=zV7EOKOMKTjwWaFseDfIkd7NHmEwnkPh8evNY9pWe/dEhaNqTTLo3ANn7bRpPZ2h54 r7IbZun6A1eXfrDvp53DuqlbNjo8ah/Xk1H/2Rv/qbS34pksMykdoJp7McV2YzIn4QoD PQ0OzJ4zrIWOv78yl3tehYYP+WBk5aMsatmoyFwpZRBH5M2AoePtej3IzONSMySaWKKP GsWnFNqTn9gAO8xD6OeNUiP2Hib40gmtvKZl8SzkH/BJ4cbwqyJ+7qxf+5VpSzxua4NP Tx4HR1vgCBNaqwHL1+xwCqSLCWN4ax+7um0v9Cjki7XgQaun0QcLs4i4Mph6Kbn5Nl7v /u9w== 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:references:from:date :message-id:subject:to:cc; bh=o55SAbx+OOHSYtMvzHRuqhNUVb6FCjigR7I5H/qHjvg=; b=BBcYBO6Sc8y5wAlvc07+Nec6KGdQm97EsiOIWpOxgVfQuRohXmkSfXUHorDoLYD4GY UK7U3UymSKlXkzvHBVNMUi3wBtH+ew2fM0Ae4/tMdlStQHXZNwLE0w22YPpAha2vOzn3 hUiaNPhIUSj722YNiLIf1cyT2pcrSUPRjIvnPetvij5YdU5rp1d/xfGIm4QoRgDVhhVl ASfUMqsyTfn/eg8a+CDr3OXyge2fp1ExtL6mltKsiIKKldhtxhoEVEU0bdrqX3xVsYQC a6vc0BVzS2UMJamP0QDh6Ufu7nfQF1pATukL01ZLlJOqUEK4ZcbbUcKLIOZP90vGNh6q Yq3Q== X-Gm-Message-State: AKwxytdCF/iL6ipxJdcWWcLSN0mOgVDuXGy/e8tv042qOqNocB0NBngm TjV7Pphw5Nr4WHrwa2BgkWDNsckCkJSaQNX1mb8e2pylrQ0= X-Google-Smtp-Source: ACJfBosf+9RtUZxssqUs72M2hZRNXuSiUStV71Dzv2VZn5/BWVhMDvmnnnu01iAEObyokVnuw3J21mEq/RzDCzyyc4w= X-Received: by 10.37.174.72 with SMTP id g8mr13155365ybe.474.1516281420156; Thu, 18 Jan 2018 05:17:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.66 with HTTP; Thu, 18 Jan 2018 05:16:19 -0800 (PST) In-Reply-To: <50eb8f92-b0b2-faab-6f48-14d820480f7d@openssl.org> References: <50eb8f92-b0b2-faab-6f48-14d820480f7d@openssl.org> From: Eric Rescorla Date: Thu, 18 Jan 2018 05:16:19 -0800 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045ecec06da61505630cc7c4" Archived-At: Subject: Re: [TLS] signature_algorithms_cert extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 13:17:03 -0000 --f403045ecec06da61505630cc7c4 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 18, 2018 at 3:29 AM, Matt Caswell wrote: > The specification of the new signature_algorithms_cert seems somewhat > lacking to me. There is very little description about how it should be > interpreted. About the best I can get from the spec is this: > > The "signature_algorithms_cert" extension applies to signatures in > certificates and the "signature_algorithms" extension, which > originally appeared in TLS 1.2, applies to signatures in > CertificateVerify messages. > > But in section 4.4.2.2 we see this: > > All certificates provided by the server MUST be signed by a signature > algorithm that appears in the "signature_algorithms" extension > provided by the client, if they are able to provide such a chain (see > Section 4.2.3). Certificates that are self-signed or certificates > that are expected to be trust anchors are not validated as part of > the chain and therefore MAY be signed with any algorithm. > > > Is this an oversight? Should this reference "signature_algorithms_cert" > as well/instead? > Yes, it's an oversight that it didn't get added here. Some questions: > > - Is "signature_algorithms_cert" mandatory to implement for servers? It > does not appear in 9.2 so I am assuming not. There is some text in 4.2.3 > which says what to do if "signature_algorithms_cert" is not present - > which seems to confirm that it is not mandatory for clients at least. > Both sides need to implement it for the purposes of filtering the certificates they send. Neither side need send it if it has a consistent policy for CertVerify and chain validation. - Are we allowed to ignore "signature_algorithms_cert" if we can't build > a chain and honour its contents? > Same rules as signature_algorithms. I have filed https://github.com/tlswg/tls13-spec/pull/1142 to clarify these points. -Ekr > > Matt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045ecec06da61505630cc7c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 18, 2018 at 3:29 AM, Matt Caswell <matt@openssl.org>= wrote:
The spe= cification of the new signature_algorithms_cert seems somewhat
lacking to me. There is very little description about how it should be
interpreted. About the best I can get from the spec is this:

=C2=A0 =C2=A0The "signature_algorithms_cert" extension applies to= signatures in
=C2=A0 =C2=A0certificates and the "signature_algorithms" extensio= n, which
=C2=A0 =C2=A0originally appeared in TLS 1.2, applies to signatures in
=C2=A0 =C2=A0CertificateVerify messages.

But in section 4.4.2.2 we see this:

=C2=A0 =C2=A0All certificates provided by the server MUST be signed by a si= gnature
=C2=A0 =C2=A0algorithm that appears in the "signature_algorithms"= extension
=C2=A0 =C2=A0provided by the client, if they are able to provide such a cha= in (see
=C2=A0 =C2=A0Section 4.2.3).=C2=A0 Certificates that are self-signed or cer= tificates
=C2=A0 =C2=A0that are expected to be trust anchors are not validated as par= t of
=C2=A0 =C2=A0the chain and therefore MAY be signed with any algorithm.


Is this an oversight? Should this reference "signature_algorithms_cert= "
as well/instead?

Yes, it's an overs= ight that it didn't get added here.


=
Some questions:

- Is "signature_algorithms_cert" mandatory to implement for serve= rs? It
does not appear in 9.2 so I am assuming not. There is some text in 4.2.3 =C2=A0which says what to do if "signature_algorithms_cert" is not= present -
which seems to confirm that it is not mandatory for clients at least.

Both sides need to implement it for the purp= oses of filtering the certificates
they send. Neither side need s= end it if it has a consistent policy for CertVerify
and chain val= idation.


- Are we allowed to ignore "signature_algorithms_cert" if we can&= #39;t build
a chain and honour its contents?

Same r= ules as signature_algorithms.

I have filed=C2=A0https://github.com/= tlswg/tls13-spec/pull/1142 to clarify these points.

-Ekr




Matt

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

--f403045ecec06da61505630cc7c4-- From nobody Thu Jan 18 10:21:23 2018 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 48F4A12895E for ; Thu, 18 Jan 2018 10:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 o-u1xRpZ5zBJ for ; Thu, 18 Jan 2018 10:21:20 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61249129C53 for ; Thu, 18 Jan 2018 10:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1516299674; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=5277; bh=Ij99CF8ebxTX8MTyOe5NSaycGDg+QGOAto7ySUfqLj4=; b=atoNbRleT6IRJfz6vnoQMvBJBZc5cGaOyiE3dvdZzJAHYtg2rzBGLgZHAU/qIvJb OqDL67QwUGDkxEo5fFg+nodvn9hs2YwNyfCggUWwxasM8xIeMF9YiFrZVEFw3iiocbi Kg9Nrw4hMr253eJuHfabQCL/YMibMYcw7/fr/O5k= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1516299673481570.4428154151128; Thu, 18 Jan 2018 10:21:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 18 Jan 2018 13:21:11 -0500 From: R du Toit To: "tls@ietf.org" Message-ID: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> Thread-Topic: ServerHello extensions Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3599126473_1111136330" X-ZohoMailClient: External Archived-At: Subject: [TLS] ServerHello extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 18:21:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3599126473_1111136330 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Issue#1: Section "4.1.3 Server Hello" currently states: extensions=C2=A0=C2=A0 A list of extensions. The ServerHello MUST only include exte= nsions which are required to establish the cryptographic context. Currently = the only such extensions are =E2=80=9Ckey_share=E2=80=9D and =E2=80=9Cpre_shared_key=E2=80=9D. All c= urrent TLS 1.3 ServerHello messages will contain one of these two extensions= , or both when using a PSK with (EC)DHE key establishment. The remaining ext= ensions are sent separately in the EncryptedExtensions message. =20 "supported_versions" should be added to the list of required extensions for= a session that negotiates TLS 1.3. =20 =20 Issue#2: Section "4.1.4 Hello Retry Request" currently states: Upon receiving the ServerHello, clients MUST check that the cipher suite su= pplied in the ServerHello is the same as that in the HelloRetryRequest and o= therwise abort the handshake with an =E2=80=9Cillegal_parameter=E2=80=9D alert. =20 There is no rule about checking that SH.supported_versions.selected_version= matches HRR.supported_versions.selected_version.=C2=A0=C2=A0 I am currently adding = draft 23 support, and want to enforce that rule to make sure the protocol st= ate machine does not have to jump back and forth between TLS 1.2 and TLS 1.3= . =20 I can add a PR for both issues, if you agree. =20 --Roelof =20 --B_3599126473_1111136330 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Issue#1: Section "4.1.3= Server Hello" currently states:

extensions=C2=A0=C2= =A0 A list of extensions. The ServerHello MUST only include extensions which a= re required to establish the cryptographic context. Currently the only such = extensions are “key_share” and “pre_shared_key”. All= current TLS 1.3 ServerHello messages will contain one of these two extensio= ns, or both when using a PSK with (EC)DHE key establishment. The remaining e= xtensions are sent separately in the EncryptedExtensions message.=

 

"sup= ported_versions" should be added to the list of required extensions for= a session that negotiates TLS 1.3.

 <= /p>

 

Issue#2: Secti= on "4.1.4 Hello Retry Request" currently states:

Upon receiving the ServerHello, clients MUST check that the cipher s= uite supplied in the ServerHello is the same as that in the HelloRetryReques= t and otherwise abort the handshake with an “illegal_parameter” = alert.

 

There is no rule about checking that SH.supported_versions.select= ed_version matches HRR.supported_versions.selected_version.=C2=A0=C2=A0 I= am currently adding draft 23 support, and want to enforce that rule to make= sure the protocol state machine does not have to jump back and forth betwee= n TLS 1.2 and TLS 1.3.

 

I can add a PR for both issues, if you agree.

 

--Roelof

 

--B_3599126473_1111136330-- From nobody Thu Jan 18 10:24:27 2018 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 EFA4F12895E for ; Thu, 18 Jan 2018 10:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 IItdE_rrZpjB for ; Thu, 18 Jan 2018 10:24:24 -0800 (PST) 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 6AFAA126C25 for ; Thu, 18 Jan 2018 10:24:24 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0IIMs0C004660; Thu, 18 Jan 2018 18:24:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=OUn1jtrSaG2owrwnPh0+qeoZ7ZwdAF2nRFqE42lceE4=; b=fKeZ/kXsA1JlC1NC7PgvYMFVaeKoktzbmZBIhOuYIwY7/4nZbDJVcpWAf0xV5EeTnYoe RPQJStv0KjShRsl6WCL0/tQaCkvic4a8kesx/wkdfZfG0nIlVBtevf09qBjYTd3TbcEp 3StCD/MJ9WED+FF0oh1W1vFv3vMzheU/OZeAQiTQ/GKvchxLVTLzBsz0tECBUnHXxxWS r9MIajQSn2BHBNBohLgR/ECxFYMSQnxDguekNz55ToKzpzaIvV57fJpjjpIszH5VT6cx y9NA4jkEQt+ueRoeBxAt0Xs/Jis6R4o0SjaJwEG9nIQr7Xb05sWJMU5zy8jSssJzJT6+ cw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2fhpsd49sy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jan 2018 18:24:22 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0IILmr5022497; Thu, 18 Jan 2018 13:24:21 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ffebfecdc-1; Thu, 18 Jan 2018 13:24:21 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 74BF383192; Thu, 18 Jan 2018 11:24:21 -0700 (MST) To: R du Toit , "tls@ietf.org" References: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> From: Benjamin Kaduk Message-ID: Date: Thu, 18 Jan 2018 12:24:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_08:, , 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=615 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180244 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=587 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180244 Archived-At: Subject: Re: [TLS] ServerHello extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 18:24:26 -0000 On 01/18/2018 12:21 PM, R du Toit wrote: > I can add a PR for both issues, if you agree. Please do. -Ben From nobody Thu Jan 18 10:26:11 2018 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 56A8C12895E for ; Thu, 18 Jan 2018 10:26:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 V_d2wUxRZOoK for ; Thu, 18 Jan 2018 10:26:09 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 C14B0126C25 for ; Thu, 18 Jan 2018 10:26:08 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v196so213756ywc.6 for ; Thu, 18 Jan 2018 10:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Muz+/g1DRUEA/DdxjVLUM2dCMzmJ8gfRGY2XdAJma9s=; b=0qstEnPIB81jNZ88RMS5dyQEwlB0W8fx7GvVRnqi5Di8hS60juQugdphyWTituBQjZ eGmS+60Gc+Cc5urawP9HdVUA6U51G1NdU+8vUjQqfMdMHTNCRwoMMgh+6uxtr70L4+4Q k+icLCql6qJTGAt/CiMxVkfnp2b36saNJw2QqlaCLhAv3craLahM+CxNDx/3RX87xHrO 9atgN1CFedroK7md50p7mdurOBQfd6TIBNyTSKlMR1BO9DeZpa+I9X3S1r6/CJmtbgNE R03B+LlcWoqKDk+2If6G7XjI6mOR10AosFA3kZ2oxN7xzccVwvJdTxvZohXb2feIK0QG hF4Q== 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:references:from:date :message-id:subject:to:cc; bh=Muz+/g1DRUEA/DdxjVLUM2dCMzmJ8gfRGY2XdAJma9s=; b=HiAoJRZ8trEYcvU6glJvWeN876GnTtJ+Rcj9q0kx5/c5fjwzNa/iPeS35AKiFo/lDn /R6UyK5Vxrzqy1axc8SMZBrMRrnEI4FkHX2G9TfF4yvXuV0Sm+K7ZDpEe2EOHFCZTCib 6pj66UHxBHYN3em/tIv5vEZV9FEZcpdeBxG/M1V1WaTlv+z3wyiNxwNQQgdgpZSOj9T6 m2EUstT8q5KG8IXU0rFYmagD4jclJwWK79IroyTwkX6i4GT7lyHgXcSOtPconVkdAb39 nXv/udg3OrpTJ/ZyStmPKkIYqN94hDMPoyqSXAcH4nBcFpAohVYuGi3dqziMnTnW7kYJ 2+8A== X-Gm-Message-State: AKwxytd/Hhx4oXwkAhpVbwALdMJg0i0Ofth9OzQaCX3X8HUK/nuLbYBy 6yh1hWFtoGoasWtBaFQvGBeIuw1qD6ngZlizkwtw4AgA X-Google-Smtp-Source: ACJfBosNvTPGHmb9aqCFCNNgvmdyY10YQAN/lXOYVaB5StK2p+sg/DeYoTcB7THLlOlCSY4Rrj/vJzGh8Tw862Q1jCw= X-Received: by 10.37.185.134 with SMTP id r6mr10177747ybg.423.1516299967994; Thu, 18 Jan 2018 10:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.66 with HTTP; Thu, 18 Jan 2018 10:25:27 -0800 (PST) In-Reply-To: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> References: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> From: Eric Rescorla Date: Thu, 18 Jan 2018 10:25:27 -0800 Message-ID: To: R du Toit Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403043d4ad0f731870563111863" Archived-At: Subject: Re: [TLS] ServerHello extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 18:26:10 -0000 --f403043d4ad0f731870563111863 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. These are good points. I would welcome a PR. On Thu, Jan 18, 2018 at 10:21 AM, R du Toit wrote: > Issue#1: Section "4.1.3 Server Hello" currently states: > > *extensions A list of extensions. The ServerHello MUST only include > extensions which are required to establish the cryptographic context. > Currently the only such extensions are =E2=80=9Ckey_share=E2=80=9D and = =E2=80=9Cpre_shared_key=E2=80=9D. > All current TLS 1.3 ServerHello messages will contain one of these two > extensions, or both when using a PSK with (EC)DHE key establishment. The > remaining extensions are sent separately in the EncryptedExtensions > message.* > > > > "supported_versions" should be added to the list of required extensions > for a session that negotiates TLS 1.3. > > > > > > Issue#2: Section "4.1.4 Hello Retry Request" currently states: > > *Upon receiving the ServerHello, clients MUST check that the cipher suite > supplied in the ServerHello is the same as that in the HelloRetryRequest > and otherwise abort the handshake with an =E2=80=9Cillegal_parameter=E2= =80=9D alert.* > > > > There is no rule about checking that > *SH.supported_versions.selected_version* matches > *HRR.supported_versions.selected_version*. I am currently adding draft > 23 support, and want to enforce that rule to make sure the protocol state > machine does not have to jump back and forth between TLS 1.2 and TLS 1.3. > > > > I can add a PR for both issues, if you agree. > > > > --Roelof > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f403043d4ad0f731870563111863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. These are good points. I would welcome a PR.
=

On Thu, Jan 18, 2= 018 at 10:21 AM, R du Toit <r@nerd.ninja> wrote:

Issue#1: Section "4.1.3 Server Hello" currently st= ates:

extensions=C2=A0=C2=A0 A list of extensi= ons. The ServerHello MUST only include extensions which are required to est= ablish the cryptographic context. Currently the only such extensions are = =E2=80=9Ckey_share=E2=80=9D and =E2=80=9Cpre_shared_key=E2=80=9D. All curre= nt TLS 1.3 ServerHello messages will contain one of these two extensions, o= r both when using a PSK with (EC)DHE key establishment. The remaining exten= sions are sent separately in the EncryptedExtensions message.=

=C2=A0

"supported_versions" should be added to the list of required e= xtensions for a session that negotiates TLS 1.3.

= =C2=A0

=C2=A0

Issue#2: Section "4.1.4 Hello Retry Request" c= urrently states:

Upon receiving the ServerHell= o, clients MUST check that the cipher suite supplied in the ServerHello is = the same as that in the HelloRetryRequest and otherwise abort the handshake= with an =E2=80=9Cillegal_parameter=E2=80=9D alert.

=C2=A0

There i= s no rule about checking that SH.supported_versions.selected_versio= n matches HRR.supported_versions.selected_version.=C2=A0=C2= =A0 I am currently adding draft 23 support, and want to enforce that rule t= o make sure the protocol state machine does not have to jump back and forth= between TLS 1.2 and TLS 1.3.

=C2=A0

I can add a PR for both issues, if you agree.

=C2=A0

--R= oelof

=C2=A0


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


--f403043d4ad0f731870563111863-- From nobody Thu Jan 18 14:07:07 2018 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 0BC9812D7F0 for ; Thu, 18 Jan 2018 14:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 xmwOYPPIbv8g for ; Thu, 18 Jan 2018 14:07:05 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8775D12D7E5 for ; Thu, 18 Jan 2018 14:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1516313222; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:CC:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=9145; bh=hZm162GDixjJg9nOVHcky5SNbRb10KqvGdYo0LjGR6M=; b=VJI1AF6wAh8NUl1RXN564oimK+iLuDEat3ZkIL3QMprh3LSf32nS509zlcf5kY5H 7QXiTM4Dh4RmgjcNfw2lyZgvtkgZrA7BLfMPzmyWyNZY3jdUar0QzCFFD4ziYnhCCYI 92ZvJKnN1thbap8bHGtG/zXR68PhHkvx+mpbrGgs= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1516313222296667.3506158664442; Thu, 18 Jan 2018 14:07:02 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 18 Jan 2018 17:06:59 -0500 From: R du Toit To: Eric Rescorla CC: "tls@ietf.org" Message-ID: Thread-Topic: [TLS] ServerHello extensions References: <5F13FB38-A2F5-4B9E-A9BF-BBA107FB2EE8@nerd.ninja> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3599140022_1319248582" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: Re: [TLS] ServerHello extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 22:07:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3599140022_1319248582 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable https://github.com/tlswg/tls13-spec/pull/1143 =20 =20 From: Eric Rescorla Date: Thursday, January 18, 2018 at 1:25 PM To: R du Toit Cc: "tls@ietf.org" Subject: Re: [TLS] ServerHello extensions =20 Thanks. These are good points. I would welcome a PR. =20 On Thu, Jan 18, 2018 at 10:21 AM, R du Toit wrote: Issue#1: Section "4.1.3 Server Hello" currently states: extensions A list of extensions. The ServerHello MUST only include extens= ions which are required to establish the cryptographic context. Currently th= e only such extensions are =E2=80=9Ckey_share=E2=80=9D and =E2=80=9Cpre_shared_key=E2=80=9D. All cur= rent TLS 1.3 ServerHello messages will contain one of these two extensions, = or both when using a PSK with (EC)DHE key establishment. The remaining exten= sions are sent separately in the EncryptedExtensions message. =20 "supported_versions" should be added to the list of required extensions for= a session that negotiates TLS 1.3. =20 =20 Issue#2: Section "4.1.4 Hello Retry Request" currently states: Upon receiving the ServerHello, clients MUST check that the cipher suite su= pplied in the ServerHello is the same as that in the HelloRetryRequest and o= therwise abort the handshake with an =E2=80=9Cillegal_parameter=E2=80=9D alert. =20 There is no rule about checking that SH.supported_versions.selected_version= matches HRR.supported_versions.selected_version. I am currently adding dr= aft 23 support, and want to enforce that rule to make sure the protocol stat= e machine does not have to jump back and forth between TLS 1.2 and TLS 1.3. =20 I can add a PR for both issues, if you agree. =20 --Roelof =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 --B_3599140022_1319248582 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

https= ://github.com/tlswg/tls13-spec/pull/1143

 

 

From: Eric Rescorla <ekr@rtfm.com&g= t;
Date: Thursday, January 18, 2018 at 1:25 PM
To: R du = Toit <r@nerd.ninja>
Cc: "tls@ietf.org" <tls@iet= f.org>
Subject: Re: [TLS] ServerHello extensions

 

Thanks. These = are good points. I would welcome a PR.

 

On Thu, Jan 18, 2018 at 10:21 AM, R du Toit <r@nerd.ninja> wrote:=

Issue#1: Section "4.1.3 Server Hello" currently states= :

extensions   A list of exten= sions. The ServerHello MUST only include extensions which are required to es= tablish the cryptographic context. Currently the only such extensions are &#= 8220;key_share” and “pre_shared_key”. All current TLS 1.3 = ServerHello messages will contain one of these two extensions, or both when = using a PSK with (EC)DHE key establishment. The remaining extensions are sen= t separately in the EncryptedExtensions message.

 

"supported_versions&q= uot; should be added to the list of required extensions for a session that n= egotiates TLS 1.3.

 

 

Issue#2: Section &qu= ot;4.1.4 Hello Retry Request" currently states:

Upon receiving the ServerHello, clients MUST check that the cip= her suite supplied in the ServerHello is the same as that in the HelloRetryR= equest and otherwise abort the handshake with an “illegal_parameter= 221; alert.

 

There is no rule about checking that SH.supported_versions.s= elected_version matches HRR.supported_versions.selected_version.&= nbsp;  I am currently adding draft 23 support, and want to enforce that= rule to make sure the protocol state machine does not have to jump back and= forth between TLS 1.2 and TLS 1.3.

 <= o:p>

I can add a PR for both issues, if you agre= e.

 

= --Roelof

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:0in;margin-bott= om:12.0pt;margin-left:.5in'>
____________________________________________= ___
TLS mailing list
TLS@ietf.orghttps:/= /www.ietf.org/mailman/listinfo/tls

 

--B_3599140022_1319248582-- From nobody Sun Jan 21 21:12:42 2018 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 288A512704A for ; Sun, 21 Jan 2018 21:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 LzSNWXdrLYzt for ; Sun, 21 Jan 2018 21:12:39 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 6D6431241F8 for ; Sun, 21 Jan 2018 21:12:39 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id s9so6230446pgq.13 for ; Sun, 21 Jan 2018 21:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=CD06JWhjmA4MfTybwD8fFRXnKnbD3ptCqwsCKyctIsQ=; b=cZMAVoWofJQ4EjrsS8GGihRv8v/yeIU4dkVJ6MRnbRuhvr1DvFlR2J4j2OU8FE8m/B OR90jT8O6kd5iIJOBZN1p5TFZggvQCO3SL4LOH/xGXFbBhdpUfBdAziONIxpjI2o+L1Q uToz11Yr+hfBKMUVb94HX+PjQmH5ruxzxemDQ= 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:message-id:date:to; bh=CD06JWhjmA4MfTybwD8fFRXnKnbD3ptCqwsCKyctIsQ=; b=TcvIhI5s1csq6v/1M+Nvt/8iOrRnBGEbYx76ysU80wevepQErnR3EFgNYfL/2cuTj6 KmyUMNnH1IVJzF/9fUGUyxC4ueeGd6IMbTB40U0twcnsYfXTyLnqf/aHsVynh3i+z1GD yCCLzNeLGhshki0+zIU79E5rja203UjNlScpvVwn3LcdCI1mI7mO0FC+kLnRVnJDFTOI dA9Uu7AknVAj44dIJTqPGtu2eMKIHtnAmLuWv99nGkLXVgtsqmrGKqSTw4IAyx99dlO4 XyrLsHypPsujPNws399MmtHtp92iY8MqBv7lz6RHuxEXSkyLop+Gg6cwhYFtzo54LRDU 9K3g== X-Gm-Message-State: AKwxyteXe+5MOWWW4JVKWyjxP2M812IRE+/Be01AezUGZGO4eUAd4vel 0fuoQSIlPQ9vEnhgF9h9HAhkymCxh8Q= X-Google-Smtp-Source: AH8x2265pplYbNIrlhEFEr8PZI9sfjLrsJovnICEnaPdC0Ecx1OqGzJmCVCUlJmYFesgEJdIzfPqTg== X-Received: by 10.98.36.132 with SMTP id k4mr5163436pfk.161.1516597958838; Sun, 21 Jan 2018 21:12:38 -0800 (PST) Received: from [5.5.33.22] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id r24sm27803527pfg.51.2018.01.21.21.12.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jan 2018 21:12:38 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Mon, 22 Jan 2018 16:12:30 +1100 To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 05:12:41 -0000 All,=E2=80=99 This is the working group last call for the "Record Size Limit Extension = for TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please = review the document and send your comments to the list by 6 February = 2018. Thanks your chairs: J&S= From nobody Mon Jan 22 05:39:45 2018 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 63119126D05 for ; Mon, 22 Jan 2018 05:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MIbKFkQBkQUL for ; Mon, 22 Jan 2018 05:39:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7A71273E2 for ; Mon, 22 Jan 2018 05:39:38 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 74B528B112; Mon, 22 Jan 2018 13:39:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id D60477A2FA; Mon, 22 Jan 2018 13:39:37 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 22 Jan 2018 14:39:31 +0100 Message-ID: <3309920.DNvjjoKCYV@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2690017.zjfs78mHhl"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 22 Jan 2018 13:39:38 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 13:39:43 -0000 --nextPart2690017.zjfs78mHhl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 22 January 2018 06:12:30 CET Sean Turner wrote: > All,=E2=80=99 >=20 > This is the working group last call for the "Record Size Limit Extension = for > TLS" draft available at > http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please > review the document and send your comments to the list by 6 February 2018. I don't see description of expected behaviour during session resumption. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2690017.zjfs78mHhl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpl6ZMACgkQkqjRuAHS 9fU3KxAAjwzg5P7GMRiXuMgSPkK/a0yMCSMjE7UJK8H5K9ci2z1D+T6w7twKX4Ts BkmxV0wVovuhaDpheZo9XP3zi8xviq+VIm3QCC98l4qJoFQj7CRu6Npr2wEtCQsN yeFbuiI5SAAxViQNyEPESwGPfxaXAccr5ssL+Nqx/a2FSGkQuV82eY+fNsQlEN0o RLHcsaU817G/sas+ySPvSp29y0Dy4pB+tOTyW8i+Gjl5LdAW5JxqBqIlj6YKzz13 eHWmd+1G15H52ZolRiuF/Ht6X6rlYOD15dmYVn8NXO+uq7e3oCDbD7uAXIRi2GYN sTM6VLn4XI8MH2VTvWBhRSQKLqUt1CQRoKKNW5OyA1GxPrV28jdnMDT5AEN6kq49 qyxnsbsr+pgAOLGISAiDJWREA1Kqw9vVQkBYCL2cD2vxxIb1nTNQbsM+dR8jxrNH M+eGrA/WEp+U9XIpc1Ew3t17AIxOF4U/fE+UGPA+JvLQbMk/w+AjDSZNo8vTqkAC 7gcSyve8nT7t0Q7798HllM9GRjnMhxegoLrm1liC9gcRowcLjHpcDH3XMc+0Vim2 zSWoVWmtfV93pWN5cyyTLnsrZULcJm4mXAKL8gRk3mY2zl0RpI/AYThBoI4L2Y9w 9gi30rSUVn4lY4kXUDwEARIjLdGycqbN0zmwoaTf+ZNhnNQEiZQ= =vUSo -----END PGP SIGNATURE----- --nextPart2690017.zjfs78mHhl-- From nobody Mon Jan 22 06:52:15 2018 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 597E1124207 for ; Mon, 22 Jan 2018 06:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CGf7fstQqViR for ; Mon, 22 Jan 2018 06:52:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 2F2021200E5 for ; Mon, 22 Jan 2018 06:52:11 -0800 (PST) Received: from [192.168.91.213] ([97.105.200.130]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNZ9u-1ekkzK3tt4-007D2u for ; Mon, 22 Jan 2018 15:52:09 +0100 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <96b5a963-ecf5-c9a5-6514-a515460de420@gmx.net> Date: Mon, 22 Jan 2018 15:52:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:J2HZ+f5tRDmnZupOdEvXiPZ7aE2fTVWq7ScdvKV41+1u1lQFeAo ALQbrdhsZhtV+jFk2yxIfb32xP7Sl+An/zdQFMywhBki/b2ZW9MXY8yFj1ScWHeYs0fAUcR GR+iPueLZ5pjFOALWw0WM3+J88PUBG6cFSQJfRoY99ztaFuiNTrAlpLmmUXrrStx/52q9ZH VnCaJynMY2h/lUfUFEbfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:s2YdkKsZu9Q=:egeunATXe+BnySxpZab3OY DeN4dQRuxHWcKCjo2SaPlGFnH8B1bsbmGycljaaLQFqdKRYFlsPRqY8lwXJ/NTGeGdNIcbnMb 8jD6wSW2bShnI7ZF3J64HBKIwe9konQ2SeQ26LXhRdeGT45ABITptvQbS+IfuWeqyM86REDii O99Q7x689hAo8nIKMRccP22Qszg9EMAi4oMLxxUIVe5GggIsxSaTb4pl04kiqEOlknp9uyO63 bUEcxWKF0UoaH+bFQe7Ogcf9q2l03f2C7j3yQl08bAaKyCkOHnQ/OiQtgfEZINbcVCxhXixbS pbmj1G+N5BuxKu2iTtXubUxPKIxIaVkv3fJBvvL9W5ifnAT3Ma8J7GKDjJiXxvpZnY3qoKnMx lYvfZxz2JXWdkQHDUVjcJzS/i77X6YxeRElOGER+yF7060yb0wtU8I05WKS9nGc2fxwvU/wJt Uj4PftIrDuJ5qTABh8qaCEwwwch2+DqvR0/h4/+acrqmKfSmPJPcK6ggjmwIiCu8A0BQMPE7D /PgUoMZDizVQQAOQKOQfyQ4PbiBZX/UCDiKa7ORSkNf5RVcyUv9xNx6/0CJH8VQ2Q3//eUnD1 RmmJPxwSiqwTViTA/D02ivnaQTd80cMas9aG5SKkmw+Q9GXo90YJaL0No8ZOlhRL8iqEUkP4j a0jY6qGkCCzHTmLtOXRUMOc4xDP2BpF13TOfZT/QZdQuKE4yCJ10m3Q+5TTOwA7VzBQDF/1OL 2enciN/WNH7fy89Cq2P83qNNbj06tUh3lHOfV+5b9Nv8eX350y+B2RBXTqiG+ZRulwQCgPBwq z7Tx2yPVnD1FTGOr+N2eQArncFzjRXzjhTOi3OaCS4ISyL6Sp0= Archived-At: Subject: [TLS] Application Transport LAyer Security (ATLAS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 14:52:13 -0000 Hi all, around the last IETF meeting we had a good discussion on the list regarding application layer TLS, as proposed in draft-friel-tls-over-http-00 and various other drafts. For the next IETF meeting we are planning to request a BOF to have a dedicated timeslot allocated. For upfront discussions we have created a new mailing list, see https://www.ietf.org/mailman/listinfo/atlas We are planning to distribute a strawman charter proposal to that list in the next few days. Ciao Hannes From nobody Mon Jan 22 08:43:19 2018 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 4FFCD12762F for ; Mon, 22 Jan 2018 08:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 Ftm630pByalP for ; Mon, 22 Jan 2018 08:43:02 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5E6127444 for ; Mon, 22 Jan 2018 08:42:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id E5B4021531; Mon, 22 Jan 2018 18:42:56 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id w6r0Het5wwux; Mon, 22 Jan 2018 18:42:56 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7D02D79; Mon, 22 Jan 2018 18:42:54 +0200 (EET) Date: Mon, 22 Jan 2018 18:42:54 +0200 From: Ilari Liusvaara To: Sean Turner Cc: "" Message-ID: <20180122164254.GA25745@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 16:43:18 -0000 On Mon, Jan 22, 2018 at 04:12:30PM +1100, Sean Turner wrote: > All,’ > > This is the working group last call for the "Record Size Limit > Extension for TLS" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. > Please review the document and send your comments to the list > by 6 February 2018. "An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size. For TLS 1.3 and earlier, that limit is 2^14 octets. Higher values are currently reserved for future versions of the protocol that may allow larger records; an endpoint MUST NOT send a value higher than the protocol- defined maximum record size unless explicitly allowed by such a future version or extension." Since the count includes the content type byte in TLS 1.3, the maximum value for TLS 1.3 is 16385 bytes, not 2^14=16384. -Ilari From nobody Mon Jan 22 10:06:20 2018 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 ACB60129511 for ; Mon, 22 Jan 2018 10:06:19 -0800 (PST) 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] 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 Oq7AunyL8rVw for ; Mon, 22 Jan 2018 10:06:16 -0800 (PST) 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 B79C1127698 for ; Mon, 22 Jan 2018 10:06:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1005F300A02 for ; Mon, 22 Jan 2018 13:06:16 -0500 (EST) 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 YlJ3XdnAYOhw for ; Mon, 22 Jan 2018 13:06:14 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A7A32300426; Mon, 22 Jan 2018 13:06:14 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 22 Jan 2018 13:06:19 -0500 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <7F6F2B92-61DF-4CFC-9E5A-B861B81B27CB@vigilsec.com> References: To: Sean Turner X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 18:06:19 -0000 > This is the working group last call for the "Record Size Limit = Extension for TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please = review the document and send your comments to the list by 6 February = 2018. Section 2: Please update the paragraph to reference RFC 8174 in addition to RFC 2119, as follows:=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Otherwise, I think the document is ready to go. Russ From nobody Mon Jan 22 11:12:48 2018 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 D235912700F for ; Mon, 22 Jan 2018 11:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 G86Nq04XjtEn for ; Mon, 22 Jan 2018 11:12:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EA1126D73 for ; Mon, 22 Jan 2018 11:12:44 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8790925C2C; Mon, 22 Jan 2018 19:12:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id D931F5D9CB; Mon, 22 Jan 2018 19:12:43 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 22 Jan 2018 20:12:42 +0100 Message-ID: <1952636.oF6OJhxSDU@pintsize.usersys.redhat.com> In-Reply-To: <3309920.DNvjjoKCYV@pintsize.usersys.redhat.com> References: <3309920.DNvjjoKCYV@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3045094.SxzYXEescM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 22 Jan 2018 19:12:44 +0000 (UTC) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 19:12:47 -0000 --nextPart3045094.SxzYXEescM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 22 January 2018 14:39:31 CET Hubert Kario wrote: > On Monday, 22 January 2018 06:12:30 CET Sean Turner wrote: > > All,=E2=80=99 > >=20 > > This is the working group last call for the "Record Size Limit Extension > > for TLS" draft available at > > http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please > > review the document and send your comments to the list by 6 February 20= 18. >=20 > I don't see description of expected behaviour during session resumption. but then it's part of current master and was added in September last year: https://github.com/tlswg/tls-record-limit/commit/a20d965a will we get another version of this I-D? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3045094.SxzYXEescM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpmN6oACgkQkqjRuAHS 9fWc2A//dK7HyZ2O0Z2VjYIFCySbX2sqkqWs/jzHOwOHrGF1ECohbQhiz04nIZJx uWuVzRxQvF2jb9tQcHoVmhPfZWzAgpIPNxJozTk+Q7JDeu1v6iK7vuqQjt7RIpK8 VbjmJHk2AnowtZCHQXlkqbPTJ4d57LSFKanLgjNykVndNJCSIW3cCY9NOr5bVc/n 1xwTbonI+bIZYWPemAbv2DYQ1Qb/C1SQOOHNetuZNDDEvHrI8bsZAvC9Zw86SL4u FVSVKuEA1zwAqd7sGB0gCUBZ/wiTzPGhkJxPnCsYJ2UkR1qet8DYPUK8AF/wbOwl 1w1BVfK7mD68ZDmkI0PTwrESSr2GivtQohA1OkHon4BSTNIlOfSUfjQgjMquXhzT EWsMjbWGgDYiOOPIFBnUZXD2RjxgLBVefdi5+5t2wGFlCkPhi8BCHlc95IH25LLP NNCLygZ485RqGjgch04Q2X3zaxYW/9Phalf0Pup6og9MmoBTN0/LOiOk42xjj6gM 7FZNRlYCMDZLfVyyyJdpqiu3oBG9LtudOJnHMe1JhMkhu1pHmxitEDE1nVfIqQi9 7V7DZDWtfLA9HCu5Q6G967zwIK1ehEEe2+Mlhlc5hYByWGBRAg70oujuJHYTZRLq f4YnMBImhF+wMfsMt4E0pJVPZObcIp39MHEXSWT/ZyLNAMVcFNU= =MdY6 -----END PGP SIGNATURE----- --nextPart3045094.SxzYXEescM-- From nobody Mon Jan 22 14:43:12 2018 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 DAB0312D831 for ; Mon, 22 Jan 2018 14:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dnAy3YDiilx1 for ; Mon, 22 Jan 2018 14:43:09 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 D651812D82F for ; Mon, 22 Jan 2018 14:43:08 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id y5so8197735pff.13 for ; Mon, 22 Jan 2018 14:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C0y3t0p0yHelhbQ9uSMpsd2FtMLi4omognMFnJk4mmA=; b=QY/TmuVYOZdXDX6TAkt++29qH6cuOF/LQ6tiGEcwUhgAyMBRTXz5GL8Iuts1Xq23uh 3+wRvjuTYcZalZ2bMzZ3hwGNFeMeHhz7FDEyD9mYg5kuYs1IRXSsGmifj9Hhsq/MGJJb waXsH2soiHPkb2IyTrwWKKLbfxcEE7gDG5emM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C0y3t0p0yHelhbQ9uSMpsd2FtMLi4omognMFnJk4mmA=; b=ILs+MxmL7FksYtEcQuXpX8kEobcSUCs+X0wvYM9l0xvqguVrQPKG4t0ZXB+wCHqMav OL4r6VXHVBu/L862HWDU1Yg9c12QoUsDdmuvXAx3Iv7VSPDSXgq7Pv+iaHuoAz54/vAI RqOZW7Rty1pFGMVBzDN49O3nNrmORSoh6fWI60a7u295aj4GaNuRifyGO1gigKkUdfXD a9hfF/E0emYazEjSFG0Awa/PI2Ak2EBiUaZvH8dOoRmcv1T7QzIYMOx4oidChajpniGF SBFT3JvllmUt3WioYDh488tKWYrObRkvb62mXbVw6CeGi9QOilkuCj7bCCAkZkDZy/j9 IRCA== X-Gm-Message-State: AKwxytcNBuIFKbEdiziH6Fsqxwpl/miX3cKzVjSmL21zHqYulLXuaJsY f8oY974Lz5+hO2LZ7OeSAE3eHYCetKw= X-Google-Smtp-Source: AH8x227BbJAKqSKH/I5dCWEiiJdF9aMOQOh248LirFjStBlDlGxmkqslgBY+Mkwlco5grgJ55xx7Kg== X-Received: by 10.101.85.138 with SMTP id j10mr7905219pgs.144.1516660988508; Mon, 22 Jan 2018 14:43:08 -0800 (PST) Received: from [5.5.33.21] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id c184sm2089255pfg.57.2018.01.22.14.43.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 14:43:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <7F6F2B92-61DF-4CFC-9E5A-B861B81B27CB@vigilsec.com> Date: Tue, 23 Jan 2018 09:42:59 +1100 Cc: IETF TLS Content-Transfer-Encoding: 7bit Message-Id: <8BF5153D-351B-491A-973A-323ABA50D291@sn3rd.com> References: <7F6F2B92-61DF-4CFC-9E5A-B861B81B27CB@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 22:43:11 -0000 > On Jan 23, 2018, at 05:06, Russ Housley wrote: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. https://github.com/tlswg/tls-record-limit/pull/13 spt From nobody Mon Jan 22 15:39:47 2018 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 8EF9F12D852 for ; Mon, 22 Jan 2018 15:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 L90hnJJHiTdS for ; Mon, 22 Jan 2018 15:39:44 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 BAD7612D82D for ; Mon, 22 Jan 2018 15:39:44 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id m83so4772433oik.8 for ; Mon, 22 Jan 2018 15:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5yAb3dm24qz3mdvzKciyXCKES3B/l+FsJCURviWm+X0=; b=N3ItoR5C9LE/E6UsXNX7r8vVEFTImqZj39CnuAXKah6/jZtqk3hX5IpfM1ucnSKUBf vDeGZiFFV/bnpo4SZJjH+U2GG67CpAW8cGqVfHAAI1s37vCL3N3e57HfqiC+HuOFrv1p unGo+vSVaAPUa8pQgOEigxuS3vIyxFk41dv7adKgK1cSDQJk1x673DT7MF8mJExCTsyr bviFkjFi8T/1z9UfMl7uLUwlZqaPMWsKMNIH2wasWeHewSM9CPgOtWka6WDA7mQYSMK4 h+hB5JT91RXUGLE0NWeEpUMRl7Bb1w0SllPJQ+GsnbHtdgYFImk/edgTg4F/bvehAmu1 IUvA== 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:references:from:date :message-id:subject:to:cc; bh=5yAb3dm24qz3mdvzKciyXCKES3B/l+FsJCURviWm+X0=; b=qEv0vLLfSsXNh7E6moTpa+xVl7wWkgmqiP8apgPQ8NzdU10pCMvsrq1GMdgWGMSZoW lBE2RYAVnyr/OPodTJ5UtxCQso9hDE/kWDzH+xwF13eYVuLNzpOkfLofhYs9heULz8Gd K2cV+5+8j6mlsV9MNAnKHofQ0mBOB0RNeGRSDLfD2JfCdC/bO4otmxCLVJzgjSoFMnsP SRn0wZsGW3kHQROFil8K8vZcLxOqtUYWH3q+OEIIFjDUCvRJV62R4BmupYrLWdMkpAE1 s1OHcxtFuJ16xO/MuPhAYLnHpu7fDjFgKCtX7T2mJD0t4HZM/tOtPesPhwLz7E0zXLeT 60bg== X-Gm-Message-State: AKwxytdD5BXrKAMPA/bBTC5MVapVowRHKaBNxhLc/RbCQP7pnEdbYYkF G9sCTN2tb9FZZfrBLONM6uUBlIgog3Xg6BhLTSI= X-Google-Smtp-Source: AH8x227Nnk/Iue0VLxMa59CYAfZ0MnMOGqywfQZkSfCwi+syGVf2mMkLKm2VlBgL+umb+QiwbVjKPAAy6jazlGLObS4= X-Received: by 10.202.192.214 with SMTP id q205mr5370494oif.313.1516664383926; Mon, 22 Jan 2018 15:39:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Mon, 22 Jan 2018 15:39:43 -0800 (PST) In-Reply-To: <3309920.DNvjjoKCYV@pintsize.usersys.redhat.com> References: <3309920.DNvjjoKCYV@pintsize.usersys.redhat.com> From: Martin Thomson Date: Tue, 23 Jan 2018 10:39:43 +1100 Message-ID: To: Hubert Kario Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 23:39:46 -0000 On Tue, Jan 23, 2018 at 12:39 AM, Hubert Kario wrote: > I don't see description of expected behaviour during session resumption. The editor's copy says: During renegotiation or resumption, the record size limit is renegotiated. Records are subject to the limits that were set in the handshake that produces the keys that are used to protect those records. This admits the possibility that the extension might not be negotiated when a connection is renegotiated or resumed. From nobody Mon Jan 22 15:41:20 2018 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 077CB12D852 for ; Mon, 22 Jan 2018 15:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wAbTBOKlQuhL for ; Mon, 22 Jan 2018 15:41:17 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 5DB4812D850 for ; Mon, 22 Jan 2018 15:41:17 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id d7so5783951oti.0 for ; Mon, 22 Jan 2018 15:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2kIG0K/vt5AAaFHksxnSMgG07pBxbf3hONE3kkTtISM=; b=OOZGdj3pnIGWrkCNeN3k0JYNH5szY1qSnlwrAuwm2HlJ7UyR9yW6OGadY8PMY+r9cF p05+4PYKmCI2mqbARw2FghdhldcpuBh+FnUCXbhjGg317lpnMN41Zv7F/BveH8hYWYKK 63D0VC4WRj3sqynNs8h3aOvxqrc4rqx/WOORwZOoI77e4f+0e/QSxk/mS/7mVelh7gVr YyqmZW3bKPodPtI27iGypwHUJoZyqnubNK1joW+AL5VX0W454TFLgYRbCSFD0Ohoma3O 89V9jNUdztNj1Z+P27KVaR9+NojAUCBfJC6n3PJuxfvkEdURAYCvy8epx4ko2ZHEogua W7Gg== 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:references:from:date :message-id:subject:to:cc; bh=2kIG0K/vt5AAaFHksxnSMgG07pBxbf3hONE3kkTtISM=; b=ozBjCya4+3RO7lwLJ3mxKelRje2IBvRLBW8XfNq8VoHQZ8QtA3hgBAv6w0fDQ8hPSE /Q3hFVjoJY+iOPB7flY9vVimr/v2vIfsLuiEyYq8JhaA0PvibQN8i63ZMOqUZUYGkWWT n3rfJqoeOLuZaPhezcc7lYAyDv4Iovs3/fUIT5awLA2t8AOcA03i7Wcsfa0BsejVxFrm jWymIc0wZKzVoMC/Ri+MaSk4F2SZuR4SX7CLMvtgfsHlCDHvf+B46ouZ2ym01/kpJxob GxijyhsGMKRWEnZ7kj/yQE2GovtmCh+skQrOfAqgTCwTyLPnxMlkqWKyn5HNZKpn5pZt oPsQ== X-Gm-Message-State: AKwxytf267bpNIj6/gaU8iWWKJEon3riyhV11X5sTW0AYhNousnd7Y08 Ui9sodHuQ/UzDrTyaUH3SSaF0mVVUSjg4x0AyLY= X-Google-Smtp-Source: AH8x227mwq4yYXJ55oY13PZVXUHRtB8ztwT3sbZwfnkLYxIi019rX4dfGyiiBhqxNzkvzxLDWBUyRICt06iV8oFI9sA= X-Received: by 10.157.52.162 with SMTP id g31mr6924802otc.71.1516664476465; Mon, 22 Jan 2018 15:41:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Mon, 22 Jan 2018 15:41:16 -0800 (PST) In-Reply-To: <20180122164254.GA25745@LK-Perkele-VII> References: <20180122164254.GA25745@LK-Perkele-VII> From: Martin Thomson Date: Tue, 23 Jan 2018 10:41:16 +1100 Message-ID: To: Ilari Liusvaara Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 23:41:19 -0000 On Tue, Jan 23, 2018 at 3:42 AM, Ilari Liusvaara wrote: > Since the count includes the content type byte in TLS 1.3, the maximum > value for TLS 1.3 is 16385 bytes, not 2^14=16384. Yes, the editor's copy says: For TLS 1.2 and earlier, that limit is 2^14 octets. TLS 1.3 uses a limit of 2^14+1 octets. From nobody Mon Jan 22 21:26:06 2018 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 B26A112D956 for ; Mon, 22 Jan 2018 21:25:58 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bXDOi4hXQRXm for ; Mon, 22 Jan 2018 21:25:56 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 9EF6E12D955 for ; Mon, 22 Jan 2018 21:25:52 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id a88so8905237pfe.12 for ; Mon, 22 Jan 2018 21:25:52 -0800 (PST) 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=ctGiDx5PcK+v/yiWSQDPOGaMyDHXHNoD/+5E7QXm5wg=; b=LU+O7Ht92wpay7kErujOElgWnhUULDXNRTS+iBz4UQMNYMG4lETWSaZyrzx9+xUXqo zSJg0j4l8EnLiOYCFdYb1H/PCtToz/J+SjDN0vhtF8iReK/4o5c5+0epYf2D6cCIoCQu 6O9SIVlvAhWUMj3//qJWkV+xwtW3ManHIRyjq/1VLviwacJ0tWiyhLEo8FFBsIofARQ4 Wd8G56a7Pq8uHUUmyKRaPbWxW316CvT80J/4o7eBiSc32xbfP7fGL0Llprn5xqGj1fLA R28Pd86O/pJxa3GXmowhfUTA5suvkkO9CdMCsfy4kB7Pt48jzgK5G56ucH3WjvJrUT5g 2kFQ== 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=ctGiDx5PcK+v/yiWSQDPOGaMyDHXHNoD/+5E7QXm5wg=; b=i/DAKgfyFD/FTzhBelr4TW672KOgN6ewrIS7gmjK5pJZiEbcnNdWI/Z+B1XqOkhbcc SkWjLGb+p+IluiOGkpTtK+z4gx745lB4oOHsOWRTvUysGVOmjVn2rhJG+c1n6N0kQEZb 0T5wn21wehsuE1anqgm+FRv72R2lmu1mWhjXj2hYTy/zdXS+GSyWbGyIsp/+x5F4Ijoq Xy/LKyaMxS3EOaSMX4OzduOjtyqZoP8SjAOfCPK3rND67lhi1gHG6g5pFOZ3wC6TFn4l iscz2OLpFvHovQ/6HhmJmRhnGEkHH2H0qvsjEKXJqS8AwjduNKtEisoLv4GZLSqfe0uj Ec7g== X-Gm-Message-State: AKwxytdZ6Pxs0nFEBfhTCs8wot8ChNJAQGZ9CQ8VRCNiEgMhBYpXqHrH 2lYBizVvDWQyNWxSMMrBDWi1C3HVAcJAXAr2UVBjxg== X-Google-Smtp-Source: AH8x226IafTMtr4FQ0l31DI56RPguymgPCYXtQODbovRWuHijqqWTJHcXrpvbz3zZ4OwhVe6X2bK+TGjBd2ovLSbNEg= X-Received: by 2002:a17:902:bd8e:: with SMTP id q14-v6mr1536985pls.253.1516685151897; Mon, 22 Jan 2018 21:25:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.170.9 with HTTP; Mon, 22 Jan 2018 21:25:31 -0800 (PST) From: Joseph Salowey Date: Mon, 22 Jan 2018 21:25:31 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000b71f7405636ac7f5" Archived-At: Subject: [TLS] Update on draft-ietf-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 05:26:06 -0000 --000000000000b71f7405636ac7f5 Content-Type: text/plain; charset="UTF-8" The authors will be posting a new version (-06) that replaces some text that was missed in the previous version that addressed the WGLC comments. The -06 version will be sent to the IESG for publication. Cheers, Joe --000000000000b71f7405636ac7f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The authors will be posting a new version (-06) that repla= ces some text that was missed in the previous version that addressed the WG= LC comments.=C2=A0 The -06 version will be sent to the IESG for publication= .=C2=A0

Cheers,

Joe
--000000000000b71f7405636ac7f5-- From nobody Tue Jan 23 06:32:48 2018 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 334AA126BF0; Tue, 23 Jan 2018 06:32:43 -0800 (PST) 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: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151671796314.13982.18348251488871932376@ietfa.amsl.com> Date: Tue, 23 Jan 2018 06:32:43 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 14:32:43 -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 : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename : draft-ietf-tls-dnssec-chain-extension-06.txt Pages : 20 Date : 2018-01-23 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-06 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-06 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 Jan 24 06:32:02 2018 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 182F51243F3 for ; Wed, 24 Jan 2018 06:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 kwC2ROn5Jje9 for ; Wed, 24 Jan 2018 06:31:56 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20138.outbound.protection.outlook.com [40.107.2.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6CF12422F for ; Wed, 24 Jan 2018 06:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q4NM3tixxngIZ3HD01YOcBognTy18F5txKekvZjOQmY=; b=qzr/+0VgNY/Q9jVNpm5cIdoKv4dAYXltbXnjgxVFwUegge1awOL4Mfvxo3S7BSCNxsCMiAgFSNT56LrzWtxOMYWPIEwJEfUhaE0ac2hnXAg+DUdj9BD4T8sgnNOJHTWnorSPIFair2BrHnwdFwyS1rAVKkd0MPhsmlM5HdDJtV8= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1231.eurprd07.prod.outlook.com (10.164.87.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 14:31:53 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79%14]) with mapi id 15.20.0444.008; Wed, 24 Jan 2018 14:31:53 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "tls@ietf.org" Thread-Topic: extended headers for (D)TLS (and their use with connection-id) Thread-Index: AQHTlSAUob9oS1qMyUeJYNzjTrRhzQ== Date: Wed, 24 Jan 2018 14:31:53 +0000 Message-ID: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.107.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1231; 7:b/ranF7IE9gPtbb5UgkVtWzgZzL9tAmrjUlh97FXQJV/417r4uLALvjbfkjIH/tGXwQ3KbzkP4f4NeJ8r6xLCf0sWcn7J0SODghR599pyCepkLTTnpS6rZdxbMOQjitQb1OBf6k3NlXECdxmtjV5yeW76/3qDVmFourkh3K1pEnFXmrSSpC5vTj4bjPZ7bxORKCz79t13/XkZJueeWL7GuKz7tnXOBPGle/1EzWRR6FafipMZU22Tazmzw19MA4+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: af01b972-71e5-491e-3903-08d5633736d8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR07MB1231; x-ms-traffictypediagnostic: VI1PR07MB1231: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231023)(11241501184)(806099)(2400081)(944501161)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR07MB1231; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1231; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(39380400002)(366004)(396003)(346002)(199004)(189003)(25786009)(3660700001)(102836004)(6436002)(316002)(5640700003)(7736002)(36756003)(6306002)(6486002)(83716003)(82746002)(3280700002)(6916009)(6512007)(478600001)(2501003)(86362001)(305945005)(5250100002)(5660300001)(59450400001)(33656002)(6506007)(3846002)(14454004)(6116002)(106356001)(105586002)(2900100001)(26005)(68736007)(8676002)(1730700003)(8936002)(66066001)(81166006)(81156014)(99286004)(97736004)(2351001)(2906002)(53936002)(83506002)(58126008)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1231; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: uYreTNukMKXbSV56Of/+gMizQFtkfd68IGyMYJh+8a16Z0uMy1qbFoKcFBA1C85Rz2q7UOFqM2Panp83idRu3dEomRXkJrqx7n5pr+Baw7vIrBu4O6CSMKRzI5xo7NeL spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: af01b972-71e5-491e-3903-08d5633736d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 14:31:53.6034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1231 Archived-At: Subject: [TLS] extended headers for (D)TLS (and their use with connection-id) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 14:31:59 -0000 SG93IHRvIG1ha2UgdGhlIGV4aXN0ZW5jZSBvZiBhIGNvbm5lY3Rpb24gaWQgZXhwbGljaXQgb24g dGhlIHdpcmU/DQoNCldlIGhhdmUgbG9va2VkIGF0IGEgZmV3IGRpZmZlcmVudCBhcHByb2FjaGVz IC0gaW4gcmV2ZXJzZSBoYWNrZXJ5IG9yZGVyOg0KZGVmaW5pbmcgbmV3IGNvbnRlbnQgdHlwZXMs IHVzaW5nIGFuIGludmFsaWQgbGVuZ3RoIGFuZCBidW1waW5nIHRoZQ0KdmVyc2lvbiBudW1iZXIu DQoNCkVhY2ggb2YgdGhlbSBjb21lcyB3aXRoIGl0cyBzbWFsbCBvciBiaWcgY29tcGxpY2F0aW9u cyBidXQsIGlycmVzcGVjdGl2ZQ0Kb2YgdGhhdCwgdGhlIGJhc2ljIHRyb3VibGUgd2UgaGF2ZSBo ZXJlIGlzIHRoYXQgdGhlIGxhY2sgb2Ygc3BhcmUgYml0cw0KaW4gdGhlIHJlY29yZCBoZWFkZXIg Zm9yY2VzIHVzIHRvIG92ZXJyaWRlIHNlbWFudGljcyBvZiBleGlzdGluZyBmaWVsZHMNCmluIGEg d2F5IHRoYXQgc21lbGxzIHdyb25nLg0KDQpBIGZldyBtb250aHMgYWdvLCBOaWtvcyAoY2FuJ3Qg cmVtZW1iZXIgaWYgb24gdGhpcyBsaXN0IG9yIG9uIGEgc2lkZQ0KY29udmVyc2F0aW9uKSBjYW1l IHVwIHdpdGggdGhpcyB0aG91Z2h0IG9mIGEgZ2VuZXJpYyB3YXkgdG8gZXh0ZW5kIHRoZQ0KVExT L0RUTFMgcmVjb3JkIGhlYWRlci4gIFNvLCBJJ3ZlIHN0b2xlbiBoaXMgaWRlYSBhbmQgd3JpdHRl biBpdCB1cCBpbg0KWzFdIHdpdGggdGhlIGludGVudGlvbiBvZiB1c2luZyBpdCB0byBtYWtlIHJv b20gZm9yIHRoZSBjb25uZWN0aW9uLWlkLg0KDQpBdCBhIGZpcnN0IGdsYW5jZSwgaXQgc2VlbXMg dG8gd29yayBxdWl0ZSBzbW9vdGhseSBhbmQgaGFzIGEgcHJldHR5DQpjb21wYWN0IGVuY29kaW5n IChzZWUgWzJdIGZvciB0aGUgZGV0YWlscyksIHdoaWNoIHdvdWxkIG1ha2UgaXQgbXkgZmlyc3QN CmNob2ljZSBvdmVyIGFsbCBvdGhlciBjYW5kaWRhdGVzLg0KDQpQbGVhc2UgaGF2ZSBhIGxvb2sg KHRoZSBkcmFmdCBzaG91bGRuJ3QgdGFrZSBtb3JlIHRoYW4gNS0xMCBtaW51dGVzIG9mDQp5b3Vy IHRpbWUpIGFuZCBwcm92aWRlIGZlZWRiYWNrIGlmIHlvdSBmZWVsIGxpa2UuDQoNClRoYW5rcywg Y2hlZXJzDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZm9zc2F0aS10 bHMtZXh0LWhlYWRlci0wMA0KWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1m b3NzYXRpLXRscy1leHQtaGVhZGVyLTAwI3NlY3Rpb24tMy40DQoNCg== From nobody Wed Jan 24 07:53:48 2018 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 25E5112DA4F for ; Wed, 24 Jan 2018 07:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 OqdeTxb67GA1 for ; Wed, 24 Jan 2018 07:53:45 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 776C9126D46 for ; Wed, 24 Jan 2018 07:53:45 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i66so3369358pfd.7 for ; Wed, 24 Jan 2018 07:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6P2wawxeV40vi1/yG1whfUFmv5zDJHqpVDE9EeoB6Ec=; b=SjxfWtAx8jHpX0ndB2H1pz7dvUxxuqtubrrksEC3zcQeAK6gJKiDO30PtTvcqb0OKQ +X2CigLoCkBPFq0U7/TkcMEAPoc48vqvuVm1Xd5ZCIsAv3JHMLQVCdz2VTei7yidDmum aAls5QKZuwQXQIFkDhLyQTPQ1Yb2d+M9CC0DCPsnG5YCY8LTN88UQaECkE1Dk2WPjdyS I6xYNon12vEGwhNeMXxMrHWnpmaCi782oARORm85QqO3jwpE7Dkt+L7HWZhOIW9OQPm3 jPnNMnkWKX5dTi5QnK+bSx5EgPtJpzPkJve55U+kRkWI7ZG0Twq6x3YscFxkyv5LQWLp V38w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6P2wawxeV40vi1/yG1whfUFmv5zDJHqpVDE9EeoB6Ec=; b=HrtbXJopf0oK3t/QuQk1tgHYQ4ZE8/gKyC4uKw2S9a4TzVqaQcv+DpJFAlUzypuUR7 8AQ8ycNaJoQmThvrRQdteLXH8mASvh08pE9Ai//H/LMjhgVS5bEqUlrNzMq64OxMhgeP 7nsq1EyFlbyfOwMlFzaWEoFPgfzSceltSt9k4hgmc6izPOdBe+z2k91zhD7tLXhIOJPC QJ1nfOeeu7n2i0q6/a3DBzLGdIRlxSJZaBDX3PoWuLJ99EKAHVZYy3ukM7Fz8WFm6WNU fHlDpL9w4j+ylkWM1v0qNgiJiSsfiEw4KnSBEjMBUsURRN3HHPbII3fCJycu7opBqheH ZpYg== X-Gm-Message-State: AKwxytf3ORMRgS9Mxi/9axpvIJdeO9Q6A+53MKrSATTtB0nrDSJvElWz 7r4/o6Yj9uibk7nsD/uC7IJLBWqtKdV9AlaUQcs= X-Google-Smtp-Source: AH8x227e2SVh7ZSy3Xkcd0AwBnmR9dEEXVjKnlmKqyg/Y1yzLmA+qZ6Kgn0XyTr+uWMwXA1jx8IS8ZaMcUaXPtX/0TQ= X-Received: by 10.98.226.24 with SMTP id a24mr13518363pfi.192.1516809224786; Wed, 24 Jan 2018 07:53:44 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.100.186.200 with HTTP; Wed, 24 Jan 2018 07:53:43 -0800 (PST) In-Reply-To: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> References: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> From: Adam Langley Date: Wed, 24 Jan 2018 07:53:43 -0800 X-Google-Sender-Auth: O7Tr79hg38_KLT2Xs4O3aF86PtU Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] extended headers for (D)TLS (and their use with connection-id) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 15:53:47 -0000 On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > > A few months ago, Nikos (can't remember if on this list or on a side > conversation) came up with this thought of a generic way to extend the > TLS/DTLS record header. So, I've stolen his idea and written it up in > [1] with the intention of using it to make room for the connection-id. Our experience with middleboxes suggests that this is likely to fault afoul of many flaws in these products if deployed with TLS on the wider internet. DTLS might survive, though, and the cited motivation (https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00) is DTLS-only. Probably this draft needs to be too. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Jan 24 08:26:04 2018 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 97F54126C26 for ; Wed, 24 Jan 2018 08:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 wGeshpNaO--y for ; Wed, 24 Jan 2018 08:25:59 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA27F1205D3 for ; Wed, 24 Jan 2018 08:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NC2Pol3HnnUGNGOey/iNtTbPv24hysCoa2mU4ZBKNLA=; b=IdlDglYD1AJHmj9IESdHczgFeoILPrNgOUj3DODD4oNLDM8arS5k1GE1c0JD8O5gf4CYKrD0tDS6AWROywIMbbh5d41ULV+yrPVKTO9rqQzNiUvI9Od3MPpRqGbGahHJM3HXaU580zDAaSV7HqgOxkmbsY/8zciOCfBlKE5PCDo= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1SPR8PMB111.eurprd07.prod.outlook.com (10.163.248.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 16:25:56 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79%14]) with mapi id 15.20.0444.008; Wed, 24 Jan 2018 16:25:56 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Adam Langley CC: "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] extended headers for (D)TLS (and their use with connection-id) Thread-Index: AQHTlSAUob9oS1qMyUeJYNzjTrRhzaODLMSAgAAJAIA= Date: Wed, 24 Jan 2018 16:25:56 +0000 Message-ID: <07A11133-DD81-458D-A0A6-113CBB25FD55@nokia.com> References: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [88.111.107.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB111; 7:NxglY7oAv/yAzz2BEdQfmUpfuvhPpEEI0VR9Rp9Yo8p083MgmJ586jNdIkBB0kawE/mbrjipRLeP1o8+fe8QjULnXR2u7Zwdu6EBg+v60WIYk0OQr521/hB+gHHJMlWGToSkJeLcKLoRJRi9kwdVa7y/9REIwUctzuUiuPwjMyOhjRwIm7AhoUczxSf2ZktOLu/SUf+cFTsuiBvmFVeySu4YwxI5K4ExK4vxmARXp0lF/ScpxOf7uPOk1fHoc49p x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(346002)(39380400002)(396003)(51914003)(189003)(199004)(36756003)(97736004)(316002)(6512007)(83716003)(53936002)(86362001)(6346003)(26005)(229853002)(4326008)(6506007)(53546011)(14454004)(6436002)(99286004)(107886003)(76176011)(83506002)(6246003)(3660700001)(25786009)(3280700002)(82746002)(66066001)(5250100002)(102836004)(59450400001)(2950100002)(2900100001)(6916009)(54906003)(33656002)(6116002)(3846002)(81156014)(81166006)(8676002)(2906002)(105586002)(68736007)(6486002)(106356001)(5660300001)(305945005)(478600001)(58126008)(8936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1SPR8PMB111; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 203199bb-a517-41f9-8a57-08d563472550 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1SPR8PMB111; x-ms-traffictypediagnostic: VI1SPR8PMB111: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231046)(11241501184)(806099)(2400081)(944501161)(6055026)(6041288)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1SPR8PMB111; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB111; x-forefront-prvs: 056297E276 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: ojGJO7OqSas2+94A+XMDrhlMvkQRUp/3xtoxpVVTZVE2dspbKhh6YVGq6zpT0o7Dm05xU4ZNeb+BtNtMst0ewTtF0BsLTU6FLB5c1ZQ7VxduxBW03OUnRv1aJ1/IMaB3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1B3C30FB20A97F4683CA43FFBB4EDF91@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 203199bb-a517-41f9-8a57-08d563472550 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 16:25:56.2031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB111 Archived-At: Subject: Re: [TLS] extended headers for (D)TLS (and their use with connection-id) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 16:26:02 -0000 T24gMjQvMDEvMjAxOCwgMTU6NTMsICJhbGFuZ2xleUBnbWFpbC5jb20gb24gYmVoYWxmIG9mIEFk YW0gTGFuZ2xleSIgPGFsYW5nbGV5QGdtYWlsLmNvbSBvbiBiZWhhbGYgb2YgYWdsQGltcGVyaWFs dmlvbGV0Lm9yZz4gd3JvdGU6DQo+IE9uIFdlZCwgSmFuIDI0LCAyMDE4IGF0IDY6MzEgQU0sIEZv c3NhdGksIFRob21hcyAoTm9raWEgLQ0KPiBHQi9DYW1icmlkZ2UsIFVLKSA8dGhvbWFzLmZvc3Nh dGlAbm9raWEuY29tPiB3cm90ZToNCj4gPg0KPiA+IEEgZmV3IG1vbnRocyBhZ28sIE5pa29zIChj YW4ndCByZW1lbWJlciBpZiBvbiB0aGlzIGxpc3Qgb3Igb24gYSBzaWRlDQo+ID4gY29udmVyc2F0 aW9uKSBjYW1lIHVwIHdpdGggdGhpcyB0aG91Z2h0IG9mIGEgZ2VuZXJpYyB3YXkgdG8gZXh0ZW5k DQo+ID4gdGhlIFRMUy9EVExTIHJlY29yZCBoZWFkZXIuwqAgU28sIEkndmUgc3RvbGVuIGhpcyBp ZGVhIGFuZCB3cml0dGVuIGl0DQo+ID4gdXAgaW4gWzFdIHdpdGggdGhlIGludGVudGlvbiBvZiB1 c2luZyBpdCB0byBtYWtlIHJvb20gZm9yIHRoZQ0KPiA+IGNvbm5lY3Rpb24taWQuDQo+IA0KPiBP dXIgZXhwZXJpZW5jZSB3aXRoIG1pZGRsZWJveGVzIHN1Z2dlc3RzIHRoYXQgdGhpcyBpcyBsaWtl bHkgdG8gZmF1bHQNCj4gYWZvdWwgb2YgbWFueSBmbGF3cyBpbiB0aGVzZSBwcm9kdWN0cyBpZiBk ZXBsb3llZCB3aXRoIFRMUyBvbiB0aGUNCj4gd2lkZXIgaW50ZXJuZXQuDQoNClRoYW5rcyBmb3Ig dGhlIGluc2lnaHQuDQoNCkkgaGF2ZSB0aG91Z2h0IGEgYml0IGFib3V0IHRoaXMgcG9zc2liaWxp dHkgd2hlbiBkb2luZyB0aGUgd3JpdGUtdXAgYW5kDQp0aGUgIk1VU1QgTk9UIGJlIHVzZWQgZHVy aW5nIGhhbmRzaGFrZSIgd2FzIG1lYW50IGV4YWN0bHkgdG8gbWluaW1pc2UNCnRoZSBwb3NzaWJs ZSBpbXBhY3Qgb2YgbWlkZGxlLWJveGVzIGR1cmluZyBzZXNzaW9uIGVzdGFibGlzaG1lbnQuDQoN ClNvLCB0aGUgY2hhbmNlcyB0byBzdXJ2aXZlIGhhbmRzaGFrZSBzaG91bGQgYmUgdGhlIHNhbWUg YXMgdXN1YWwuDQoNCkFmdGVyIHNlc3Npb24gZXN0YWJsaXNobWVudCwgdGhlIG9ubHkgdGhpbmcg dGhhdCBtaWdodCBsb29rIHN1c3BpY2lvdXMNCnRvIGFuIG9uLXBhdGggYm94IGlzIHRoZSBpbnZh bGlkIGxlbmd0aC4NCg0KRG8geW91IHRoaW5rIHRoaXMgaXMgbGlrZWx5IHRvIGNhdXNlIGhhdm9j PyAgT3IsIGluIHlvdXIgZXhwZXJpZW5jZSwNCm1pZGRsZS1ib3hlcyB0ZW5kIHRvIG5vdCBpbnRl cmZlcmUgYWZ0ZXIgdGhlIFRMUyBjaGFubmVsIGlzIHVwPw0KDQpjaGVlcnMNCg0K From nobody Wed Jan 24 10:13:35 2018 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 36F8C127275; Wed, 24 Jan 2018 10:13:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, tls-chairs@ietf.org, Joseph Salowey , shuque@gmail.com, joe@salowey.net, tls@ietf.org Message-ID: <151681761421.22541.12520135684545141599.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 10:13:34 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-dnssec-chain-extension-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jan 2018 18:13:34 -0000 Joseph Salowey has requested publication of draft-ietf-tls-dnssec-chain-extension-06 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ From nobody Wed Jan 24 13:40:32 2018 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 BF22A129966; Wed, 24 Jan 2018 13:40:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-dnssec-chain-extension@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Joseph Salowey , tls-chairs@ietf.org, shuque@gmail.com, joe@salowey.net, tls@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151683002366.22578.2050443994406940009.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 13:40:23 -0800 Archived-At: Subject: [TLS] Last Call: (A DANE Record and DNSSEC Authentication Chain Extension for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jan 2018 21:40:24 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'A DANE Record and DNSSEC Authentication Chain Extension for TLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 24 16:55:13 2018 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 0663912D881 for ; Wed, 24 Jan 2018 16:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 uzaJL8nFGINv for ; Wed, 24 Jan 2018 16:55:10 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 0E49212D878 for ; Wed, 24 Jan 2018 16:55:09 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id y5so4508938pff.13 for ; Wed, 24 Jan 2018 16:55:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QDB8zm05hRSjpjuLLowhMJXUy33fVggBOTEqzr8hfSQ=; b=L2zumZxWjmVvo6IqgdJ6Cyc0OiMy0xWKVWJnopf4BL1yQSgyW+FxBu/7XNBtugVv9K 5EcRSP97TpVPQd2AyHOBygro4GOegehc4WtkjM9yhfaAU/tSVpfPsfDxUgW6flCkAgpc wmKbNeI1IaowdWKJLfakqYav5MPThnzxerXYs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QDB8zm05hRSjpjuLLowhMJXUy33fVggBOTEqzr8hfSQ=; b=NvvbOsCZ0+B9KvtWAhObKN8cnCqOVHkLsqQD0JKfdycCtwJbG4fJKou1VCVIlsHvOg 76J/h4Z0ewNBXZM4hINQCZz6plBSFx1pxL4CA8dQoGfNYBD2wgCy3SBPUu1mbDE351G8 Zi7EO4JQXItJosyK54MrtFalzHeiUqy1YPqkmsEZ/WR5ORUe+yqXR6F+RjAfH17FucCE 86uOWk0ne0r2nvIVwsn74FlJOF+msbtq9szq4UDrWmgmWBOvCAqYau4mDjlmZ9xKJlCm viWXmRK4tvU+Yvg0wMXYIPjjKw7uF4M4DqcxX5UWiuLsTXC+fFwNJoyBpoM6IJ7A4+rO yOIw== X-Gm-Message-State: AKwxytcWkkgANBK9TxwBqmaTYLkjxa0nFQgp5t6EgIRu9NgnTASpb8xM AJM8uzL5D5bqdtDCGlLanSVTwQ== X-Google-Smtp-Source: AH8x2257TMCTvBpmDD5zXUiCKhlm1/awdjD2MjD0GNyw4T4spPAaDYsveiv+6JPjxxdKP1INiEwvow== X-Received: by 2002:a17:902:208:: with SMTP id 8-v6mr9713103plc.359.1516841709367; Wed, 24 Jan 2018 16:55:09 -0800 (PST) Received: from [5.5.33.36] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m65sm14926775pfc.150.2018.01.24.16.55.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 16:55:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Thu, 25 Jan 2018 11:54:59 +1100 Cc: Stephen Farrell , "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> To: Martin Thomson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 00:55:12 -0000 > On Jan 16, 2018, at 09:38, Martin Thomson = wrote: >=20 > On Tue, Jan 16, 2018 at 8:34 AM, Stephen Farrell > wrote: >> So this starts a 2-week WGLC, ending on January 29th. >=20 > Ship it! >=20 > Nits: >=20 > 6. Adding recommended Column <- capital R, consider "Recommended" to > match later text. Okay can do. > 8. TLS ExtensionType Values <- TLS 1.3 adds more columns to this > table; this document should align with that (particularly since it > already depends on TLS 1.3) I guess what I=E2=80=99ll do is note that I=E2=80=99m copying that text = from the base spec and see how it goes. > I'm almost comfortable with this statement, though I'd like to confirm > that others are also: "Despite the following behavior being crazy, > [=E2=80=A6]" You should have seen my 1st draft. I=E2=80=99ll tone it down to = "Despite the following behavior being misguided,=E2=80=9D PR follows: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 spt= From nobody Wed Jan 24 21:09:20 2018 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 53DC212DA6A for ; Wed, 24 Jan 2018 21:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yIG8TK_6LI5C for ; Wed, 24 Jan 2018 21:09:16 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 9430312E86C for ; Wed, 24 Jan 2018 21:09:07 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id c6so4985724pfi.8 for ; Wed, 24 Jan 2018 21:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zSvOU5zFVazGDB/poGp4go5NrOp23T5Ps02SHh1Xzlw=; b=GH1i7ebvCVRQ6yvuqK1TdLM5k1JyhDp6kaeF+fXXLK1Cx6Pdp7YMkJ3uV7XdKZaRmE ubnBJxEiW6MKr9f801f4y81PeY9Jely8xbA2kS6dNk5jgKV9Sm+xv8UT/LpOtAlaeJFU 2pPpV2XtVTHFqCv8Qr2sTlmaKsAHIYQYeuCwsEsMAo703M+lIBUAHtNlcCnp/lAFmhSh FrkHmeN+cNQkdW5e1bwXktZpNuqZqvGQVtBqVebk9Pnq4B/ZCdlC2Cqw6Q/OPwJSxJNe Qev/rjL+4dJ7oj0Vhmw+ABroyuXOG3yz/0N1fqZBubHgaAxYSpHrNGuGk9+EJNSLpSjN pLOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zSvOU5zFVazGDB/poGp4go5NrOp23T5Ps02SHh1Xzlw=; b=ilugwsX4opWBnm+FHKd8NCuKiOZSJCbIDQM7mj1XNLzD0sLgqNVmRr3o3RBsiyD8nq NCEwy0cg6P96lxolnp9MKRMA8VN+O7+MdEaUmKrIgOxk4gyQo4C7btV9eNgZ0Yq/1EJR nhW4uNKAISKXYLmbYHyQhg223gHla1IVGBcX4DLs4+TC2LtR7PofxvLmokoy5TSgMA9Y tpbNDLFUyeQ0tfDs46Fmxw3M0Yl8hssITGlwoEniI5KkuqEtOcd3KJJ+7XCJ+6gZu1/Z cVp2vJineT2wHfh45DxNwJEoBtUjPV28MlZjy9Y4LjM9b9RNWU+UVcXrQIxHchkmhghV 77Ig== X-Gm-Message-State: AKwxytfMJRE0TB8P2/ihpW3Z5GIZbvE5xPRQYhONAN56MbNo7zrJEAbn kKTLjslAM7iTifdeWQO1bT2o6khgf5xxkTgNcfg= X-Google-Smtp-Source: AH8x226f81Y31g2uIPo50lmejffIBp/B0RDvFBHiIeVvmfvNczwG0wOMvJKH3P79fUB1PORClxKHk6w3KEAEUlGvq+Y= X-Received: by 10.99.4.216 with SMTP id 207mr12223202pge.45.1516856946980; Wed, 24 Jan 2018 21:09:06 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.100.186.200 with HTTP; Wed, 24 Jan 2018 21:09:06 -0800 (PST) In-Reply-To: <07A11133-DD81-458D-A0A6-113CBB25FD55@nokia.com> References: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> <07A11133-DD81-458D-A0A6-113CBB25FD55@nokia.com> From: Adam Langley Date: Wed, 24 Jan 2018 21:09:06 -0800 X-Google-Sender-Auth: mNls06v0h4VxAZTWTNuFddL5E-c Message-ID: To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] extended headers for (D)TLS (and their use with connection-id) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 05:09:18 -0000 On Wed, Jan 24, 2018 at 8:25 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > Do you think this is likely to cause havoc? Or, in your experience, > middle-boxes tend to not interfere after the TLS channel is up? I expect so. There was a move, early in TLS 1.3, to drop the superfluous version in the record header. I think that was reverted for the same reason, although I don't recall exactly what data that was based on. (I'm also assuming that this is much more useful for DTLS than TLS since you know that each packet will have a record header in it. With TLS, the kernel might keep retransmitting some part of the half-connection's data that doesn't include the connection id at all.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Jan 26 02:18:26 2018 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 1EDCB12D962; Fri, 26 Jan 2018 02:18:21 -0800 (PST) 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: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151696190108.24397.6150515497869897080@ietfa.amsl.com> Date: Fri, 26 Jan 2018 02:18:21 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 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 Jan 2018 10:18:21 -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 : Transport Layer Security (TLS) Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-02.txt Pages : 7 Date : 2018-01-26 Abstract: In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-02 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 Jan 26 02:27:05 2018 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 0669F12D962 for ; Fri, 26 Jan 2018 02:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me 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 sXD9g-aLH238 for ; Fri, 26 Jan 2018 02:27:02 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (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 902B512D779 for ; Fri, 26 Jan 2018 02:27:02 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:0:b438:3849:a6c:eeb7]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 85153DF2F3 for ; Fri, 26 Jan 2018 10:27:00 +0000 (UTC) Date: Fri, 26 Jan 2018 10:26:59 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20180126102659.GA5204@pinky> Mail-Followup-To: tls@ietf.org References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151696190108.24397.6150515497869897080@ietfa.amsl.com> User-Agent: Mutt/1.9.2 (2017-12-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1516962420; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; bh=vmyWb0JVcE3jdTO3xa6QihN6ZeU/ucWa5NtDT5Qj+fg=; b=PRTG4kzy8msOn4wtcOT/gQzIj+1q98JIyPTfAY2ia3I56RZxeulnm4r89wTWW+PLox8MPU rZkwv81gWXdhVK6oZihLQd+aLxp+1B6M19a7QBVuXA91K0K4Ch+12fP148rk9tYRrGXdLI DpenVOKW/X71yKPCBCkHPbUfK7otHTo= Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 10:27:05 -0000 Hello, Here's a fresh new update based on the latest round of discussion. On Fri, Jan 26, 2018 at 02:18:21AM -0800, 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 : Transport Layer Security (TLS) Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-02.txt > Pages : 7 > Date : 2018-01-26 > > Abstract: > In Transport Layer Security (TLS) handshakes, certificate chains > often take up the majority of the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-02 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-02 The main changes are: * The CompressedCertificate message itself now carries the selected compression algorithm, rather than it being specified in a ServerHello extension. This means that client and server can independently select an algorithm for their own certificates (or none at all as in the previous version) rather than using the one picked by the server. * The server now advertises support for compressed client certitificates as an extension in the CertificateRequest message (so different sets of algorithms can be used for client compression). * The feature is now TLS >= 1.3 only, due to the dependency on extensions in CertificateRequest and to avoid middlebox interference. Me and Victor would like to ask for early codepoints assignment again, if you think we are ready now. Cheers From nobody Sat Jan 27 08:30:11 2018 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 BC3FB124234 for ; Sat, 27 Jan 2018 08:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nokia.onmicrosoft.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 ByrL99d02e_p for ; Sat, 27 Jan 2018 08:30:07 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0108.outbound.protection.outlook.com [104.47.2.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DC61241F8 for ; Sat, 27 Jan 2018 08:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+gjgpNkARNhlqVNjFgfx2nP5Jo+HpnHAsa80D5vk/aQ=; b=CWqMdd5QXIGqY7l+FpNoKa1pVsrwlAqkn2IR/klhpmp4SjMsjqwZfFzcDVO1HXWBliFNe7FNcvKgeKVFCQXKXcuONgIsBufT2LCt+GmVPv2GGM2cEQ3wsmQjte9qsvVtSnyHe3RpvWAQahxYp1yu/J3YV07/3lgsZvPA4JE781Y= Received: from DB5PR07MB1094.eurprd07.prod.outlook.com (10.163.103.148) by DB5PR07MB0919.eurprd07.prod.outlook.com (10.161.200.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Sat, 27 Jan 2018 16:30:04 +0000 Received: from DB5PR07MB1094.eurprd07.prod.outlook.com ([fe80::a5f5:9a87:94aa:58da]) by DB5PR07MB1094.eurprd07.prod.outlook.com ([fe80::a5f5:9a87:94aa:58da%13]) with mapi id 15.20.0464.008; Sat, 27 Jan 2018 16:30:04 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "tls@ietf.org" Thread-Topic: A question for TLS middle-box/middleware vendors/implementers Thread-Index: AQHTl4wVsEsS32ldTEGo2Z4sXyi6/Q== Date: Sat, 27 Jan 2018 16:30:04 +0000 Message-ID: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.107.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0919; 7:rCAOgZqIqp2LlHfQZGEUZPgRgfZSR7goLN/++c61nfbpn6PptYLA527rj4a6i0J1PdtOOESO/J4moeXfBLgRl47O0ROEE1/BIVYXMZOkpgtcGq62RQjV3x3MoKylRqKx04JpzxfodJYHBFbaw+7QWqSHHD4VFK2OSoDedEbaMvyNMGvmC22XdjVzJDNH8vftMKoA911OF6kvi/dszyvkaI6oTqDFmmhxKd+DpI0C2dvjrj/6C0F4ONr813ybpTn0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a0e2f143-99af-4c48-2c36-08d565a3384f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB5PR07MB0919; x-ms-traffictypediagnostic: DB5PR07MB0919: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231089)(11241501184)(806099)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DB5PR07MB0919; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0919; x-forefront-prvs: 056544FBEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(366004)(39860400002)(376002)(51874003)(189003)(199004)(8936002)(86362001)(106356001)(66066001)(82746002)(36756003)(5660300001)(14454004)(2900100001)(2501003)(8676002)(5640700003)(25786009)(83716003)(1730700003)(186003)(81156014)(81166006)(6436002)(966005)(83506002)(99286004)(478600001)(105586002)(26005)(33656002)(68736007)(2906002)(6506007)(97736004)(102836004)(3280700002)(3660700001)(58126008)(53936002)(3846002)(2351001)(6306002)(316002)(6916009)(305945005)(7736002)(6512007)(5250100002)(6486002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0919; H:DB5PR07MB1094.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hGn3iWV6SYeBptGlG/3YePoSqBDXn4ReBjhGwq+coOOGrkIgGELs39SQCjuaQV5ZxAI5yAqt//o3uNKcpvDYyshzcPEi9GmvLjIYjDEW5p8/5O11R8vnsrw22yqTX3UA spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9D7A84C97A0DD94BA26AAFCDBB01DBFB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0e2f143-99af-4c48-2c36-08d565a3384f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2018 16:30:04.0643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0919 Archived-At: Subject: [TLS] A question for TLS middle-box/middleware vendors/implementers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 16:30:10 -0000 SGkgVExTIG1pZGRsZS1ib3gvbWlkZGxld2FyZSBmb2xrcywNCg0KSWYgbGVuZ3RoJ3MgTVNCIGlu IGEgRD9UTFN7Q2lwaGVydGV4dCxQbGFpbnRleHQsQ29tcHJlc3NlZH0gcmVjb3JkIGlzDQpzZXQs IGhvdyBkb2VzIHlvdXIgc29mdHdhcmUgcmVhY3Q/DQoNCklzIGl0IGdvaW5nIHRvIGRyb3AgdGhl IHNlc3Npb24vcmVjb3JkIG9yIG5vdCBib3RoZXJpbmcgYXQgYWxsPw0KDQpJJ20gdHJ5aW5nIHRv IHVuZGVyc3RhbmQgYSBiaXQgYmV0dGVyIHdoZXRoZXIgYW5kIHdoZW4gaXQnZCBiZSBzYWZlIHRv DQpncmFiIHRoYXQgYml0IGFuZCBnaXZlIGl0IG5ldyBzZW1hbnRpY3MgKGUuZy4sIGZvciBzaWdu YWxsaW5nIHRoZQ0KcHJlc2VuY2Ugb2YgYSBEVExTIGNvbm5lY3Rpb24taWQsIGFuIGV4dC1oZWFk ZXIsIG9yIGFueXRoaW5nIGVsc2UNCnJlYWxseSkgYW5kIHlvdXIgYW5zd2VycyB3b3VsZCBoZWxw IHNoZWRkaW5nIHNvbWUgKCopIGxpZ2h0IG9uIHRoZQ0KbWF0dGVyLg0KDQpCYXNlZCBvbiBwcmV2 aW91cyBleHBlcmllbmNlIG9uIHNpbWlsYXIgKGJ1dCBub3QgaWRlbnRpY2FsKSBjaGFuZ2VzIHRv DQp0aGUgcmVjb3JkIGZvcm1hdCwgQWRhbSAoWzFdLCBbMl0pIHN1Z2dlc3RlZCB0aGF0IHRoaXMg Yml0IGlzIGxpa2VseSB0bw0KaGF2ZSBhbHJlYWR5IG9zc2lmaWVkIGluIFRMUywgd2hlcmVhcyBE VExTIG1pZ2h0IGJlIHN0aWxsIE9LLiAgU28sIEknbQ0KY3VyaW91cyB0byBoZWFyIGZyb20gdGhv c2Ugd2hvIG93biB0aGUgYm94ZXMnIGxvZ2ljcyBpZiB0aGV5IHNoYXJlIHRoZQ0Kc2FtZSBvcGlu aW9uIC0gaW4gcGFydGljdWxhciBpZiBEVExTIGlzIGluIGJldHRlciBzaGFwZSB0aGFuIFRMUz8N Cg0KVGhhbmtzIGluIGFkdmFuY2UgZm9yIHlvdXIgdGltZS4NCg0KKCopIEknbSBwcmV0dHkgc3Vy ZSBub3QgZXZlcnkgVExTIG1pZGRsZS1ib3ggdmVuZG9yIG9uIGVhcnRoIGlzDQpzdWJzY3JpYmVk IHRvIHRoaXMgbGlzdCBhbmQsIGV2ZW4gYW1vbmcgdGhvc2Ugd2hvIGFyZSwgbm90IGV2ZXJ5b25l DQptaWdodCBiZSB3aWxsaW5nIG9yIGFibGUgdG8gc2hhcmUgdGhpcyBpbmZvcm1hdGlvbiB3aXRo IHRoZSB3aWRlcg0KY29tbXVuaXR5LiAgVGhpcyBpcyB0byBzYXkgdGhhdCBJJ20gYXdhcmUgb2Yg dGhlIGxpbWl0ZWQgdmFsdWUgYSBwb2xsDQpsaWtlIHRoaXMgaGFzLCBidXQgSSdtIG5vdCBpbiBh IHBvc2l0aW9uIHRvIGRvIGEgbGFyZ2Utc2NhbGUgbWVhc3VyZW1lbnQNCmNhbXBhaWduIGF0IHRo ZSBtb21lbnQsIHNvIGJldHRlciBzdGFydCBmcm9tIHNvbWV3aGVyZS4uLiBPVE9ILCBJIHRoaW5r DQp0aGVyZSBpcyBhIHZhbHVhYmxlIGRpc2N1c3Npb24gdG8gYmUgaGFkIGluIGNhc2VzIGxpa2Ug dGhpcyB3aXRoIGZvbGtzDQp0aGF0IGRvbid0IG93biB0aGUgZW5kcG9pbnRzIGJ1dCBhcmUgZ29p bmcgdG8gKG9yIGhhdmUgYWxyZWFkeSkgcHV0DQp0aGVpciBsb2dpY3Mgb24gdGhlIGUyZSBwYXRo LCBzbyBob3BlZnVsbHkgSSdtIG5vdCB3YXN0aW5nIGV2ZXJ5b25lJ3MNCnRpbWUgOi0pDQoNCmNo ZWVycywgdA0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMv Y3VycmVudC9tc2cyNTI5OS5odG1sDQpbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi90bHMvY3VycmVudC9tc2cyNTMwNC5odG1sDQoNCg== From nobody Sat Jan 27 11:31:45 2018 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 306CA126BF0 for ; Sat, 27 Jan 2018 11:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 J2fE6_178vg5 for ; Sat, 27 Jan 2018 11:31:41 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 7FC631200B9 for ; Sat, 27 Jan 2018 11:31:41 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id v71so26855148wmv.2 for ; Sat, 27 Jan 2018 11:31:41 -0800 (PST) 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=rYbsruFfmPIC59fot+xuzlUVRreS8wVlw9i3nSdVzBw=; b=aWGiORy18cE6DaJrP4TIHz2zV3w5HXuUSWjLaHxGFtEvZnrlyj5x8osK0tK0Nu/BpI jcqKRvfpynUlzQjmFLUxBJHgi2TrG19I8oQcwvvZ0KqOq4Q1fVP3cipDNvWQBkhMUbvI +RCtTPlKdkA6kXTkdYSlZeawYDDz71la0xoUVDNb4kGSwbgkzmfypXYT5Ko834/Beq59 OctQgYhv6Xoe0lbPC+UzFIR1RJQpVRdlE+pmmI8IIaU3jpT3ewK5wLjQcFwqoh85Nm3R T5DJqINxEP23TUSwwilHf+/a5RirQ5trPga2kULXT87L/twC+/PARCDekRVHQpBxdsAi bFhg== 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=rYbsruFfmPIC59fot+xuzlUVRreS8wVlw9i3nSdVzBw=; b=g9Z9qlPRMPvx52eNfLES5CDtq1HH1WhTrTgoq2SZ7QIcW58Fxd4fr5uo+RjrC7RYbI RAoz+j/QkoJ/pI7W5zWeUSDWyc7mdlNF1vbp/EuJWAQK45GAgJhreLCo6WieVrwmbHVc vn1HoQLJV/simX0XU0PUtKRZH2MUeF+augSCiOo8nmlekwr5Lm5MUT/ITQi2RUSmncM7 FKPeOwC0WXIUE+52vCG+Zb2v1l0qEvHFHSMuQfAUOwcSUTAc6ZJQpuDE/GWG3UNAJ4AK /MzIFodpNRx6tc0m+W7XfBU9hqHFGU9s6JJdK2CMHO5DtjpykjwCSjupFLat1G/Vyhl+ CQXQ== X-Gm-Message-State: AKwxytdh//D5v5zpjQoW+NOg/y+8kvssP1j9ZkJ91WdRr407bWT0bj5K HD4qOc+qUfJ0wxK3XpJYs08= X-Google-Smtp-Source: AH8x224rfibpF1L9fSOxRNcubBAVlvMeOacfpE4fYwiYHkDAqtweZ5NUvfegk4h4+TwOeE2BqndTBw== X-Received: by 10.28.154.141 with SMTP id c135mr15442707wme.82.1517081499947; Sat, 27 Jan 2018 11:31:39 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id w7sm9535846wra.90.2018.01.27.11.31.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jan 2018 11:31:38 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0600F6A7-46B0-407B-A768-D184B7EAC801" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 27 Jan 2018 21:31:36 +0200 In-Reply-To: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> Cc: "tls@ietf.org" To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" References: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] A question for TLS middle-box/middleware vendors/implementers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 19:31:44 -0000 --Apple-Mail=_0600F6A7-46B0-407B-A768-D184B7EAC801 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) = wrote: >=20 > Hi TLS middle-box/middleware folks, >=20 > If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is > set, how does your software react? >=20 > Is it going to drop the session/record or not bothering at all? >=20 > I'm trying to understand a bit better whether and when it'd be safe to > grab that bit and give it new semantics (e.g., for signalling the > presence of a DTLS connection-id, an ext-header, or anything else > really) and your answers would help shedding some (*) light on the > matter. >=20 > Based on previous experience on similar (but not identical) changes to > the record format, Adam ([1], [2]) suggested that this bit is likely = to > have already ossified in TLS, whereas DTLS might be still OK. So, I'm > curious to hear from those who own the boxes' logics if they share the > same opinion - in particular if DTLS is in better shape than TLS? >=20 > Thanks in advance for your time. >=20 > (*) I'm pretty sure not every TLS middle-box vendor on earth is > subscribed to this list and, even among those who are, not everyone > might be willing or able to share this information with the wider > community. This is to say that I'm aware of the limited value a poll > like this has, but I'm not in a position to do a large-scale = measurement > campaign at the moment, so better start from somewhere... OTOH, I = think > there is a valuable discussion to be had in cases like this with folks > that don't own the endpoints but are going to (or have already) put > their logics on the e2e path, so hopefully I'm not wasting everyone's > time :-) >=20 > cheers, t >=20 > [1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html > [2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html = Hi, Thomas. I don=E2=80=99t work for a middlebox vendor anymore, although I did only = 8 months ago. This answer is not based on recently looking at code. The length field is byte-aligned. So any implementation of a TLS parser = or TLS proxy will do one of two things: 1. Consider the MSB to be a must-be-zero bit and drop any length field = that has it set as faulty. 2. Ignore text about limits on length and assume the record is that big. = Depending on what field that is, this may cause a drop on some other = sanity check. As always there=E2=80=99s option #3 (crash), but the industry is getting = better at avoiding that. You seem to want the behaviour that the middlebox masks out the = must-be-zero bits and considers only the relevant length bits. I don=E2=80= =99t think that would pass code review at my former employer. HTH Yoav --Apple-Mail=_0600F6A7-46B0-407B-A768-D184B7EAC801 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

Hi = TLS middle-box/middleware folks,

If = length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
set, how does your software react?

Is it going to drop the session/record or not bothering at = all?

I'm trying to understand a bit better = whether and when it'd be safe to
grab that bit and give it = new semantics (e.g., for signalling the
presence of a DTLS = connection-id, an ext-header, or anything else
really) and = your answers would help shedding some (*) light on the
matter.

Based on previous = experience on similar (but not identical) changes to
the = record format, Adam ([1], [2]) suggested that this bit is likely to
have already ossified in TLS, whereas DTLS might be still OK. =  So, I'm
curious to hear from those who own the = boxes' logics if they share the
same opinion - in = particular if DTLS is in better shape than TLS?

Thanks in advance for your time.

(*) I'm pretty sure not every TLS middle-box vendor on earth = is
subscribed to this list and, even among those who are, = not everyone
might be willing or able to share this = information with the wider
community.  This is to say = that I'm aware of the limited value a poll
like this has, = but I'm not in a position to do a large-scale measurement
campaign at the moment, so better start from somewhere... = OTOH, I think
there is a valuable discussion to be had in = cases like this with folks
that don't own the endpoints = but are going to (or have already) put
their logics on the = e2e path, so hopefully I'm not wasting everyone's
time = :-)

cheers, t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html=
[2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html=

Hi, Thomas.

I don=E2=80=99t work for a middlebox vendor anymore, although = I did only 8 months ago. This answer is not based on recently looking at = code.

The = length field is byte-aligned. So any implementation of a TLS parser or = TLS proxy will do one of two things:

1. Consider the MSB to be a = must-be-zero bit and drop any length field that has it set as = faulty.

2. = Ignore text about limits on length and assume the record is that big. = Depending on what field that is, this may cause a drop on some other = sanity check.

As= always there=E2=80=99s option #3 (crash), but the industry is getting = better at avoiding that.

You seem to want the behaviour that the middlebox masks out = the must-be-zero bits and considers only the relevant length bits. I = don=E2=80=99t think that would pass code review at my former = employer.

HTH

Yoav

= --Apple-Mail=_0600F6A7-46B0-407B-A768-D184B7EAC801-- From nobody Sun Jan 28 02:19:40 2018 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 1EB9F12E91F for ; Sun, 28 Jan 2018 02:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 UWC4ezJa8jsQ for ; Sun, 28 Jan 2018 02:19:37 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0128.outbound.protection.outlook.com [104.47.1.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B3312E87C for ; Sun, 28 Jan 2018 02:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z71SB+JUeHpD4MpYpMhJhLTk6vAexAe1HWGDrBmiuqA=; b=OzjHcrJyxLF/TkpIJQE1FoUKT44LUJ8sKS/BLdIN5drkQWJYQABC/cCm1q0aoV8RtLLa2eOQmFlW7K7+BOhCkYWEvnwZV+vg5RzZwRillWHHhyZ8HyB5MYJ8DOyyGLMhiRN1C6l2Ov4Ds4AOMVS7LafMyqCmDvKDd+F3sXNxEqM= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0524.eurprd07.prod.outlook.com (10.160.44.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Sun, 28 Jan 2018 10:19:33 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.008; Sun, 28 Jan 2018 10:19:32 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Yoav Nir CC: "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] A question for TLS middle-box/middleware vendors/implementers Thread-Index: AQHTl4wVsEsS32ldTEGo2Z4sXyi6/aOIG8sAgAD4FYA= Date: Sun, 28 Jan 2018 10:19:32 +0000 Message-ID: References: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.107.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0524; 7:AdztY99vJ4NadJzV76x6PvoeMt1W9xlTqTixKGEoqXhqevpDGhnWT+1T7D2U3xVkD6ywS0qfYPRbK+N8cP/XVsNy82aVF+SJdFTeDUQh02QoDEame2Gt/nQvD75AMCBaT5UeZkqoU44KU7J83fEnj3Xs1GfDzYC5usKdQdTtCk0JfsZTdeRWWDRgmNbR+OdyiDMi/+zv2UodIzNHyOAYP2kkovgY1phpqGKWvi8ttD3TDBM0+OG9DHAT3/G3ODda x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(366004)(39380400002)(376002)(51914003)(189003)(199004)(2906002)(478600001)(97736004)(14454004)(102836004)(53546011)(6506007)(59450400001)(76176011)(7736002)(305945005)(26005)(3846002)(82746002)(86362001)(6116002)(5660300001)(83716003)(105586002)(81166006)(8676002)(8936002)(2900100001)(6436002)(6512007)(53936002)(5250100002)(6486002)(68736007)(33656002)(4326008)(6916009)(66066001)(2950100002)(81156014)(106356001)(36756003)(58126008)(229853002)(316002)(3660700001)(107886003)(3280700002)(54906003)(83506002)(186003)(25786009)(99286004)(6246003)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0524; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dad3e91e-1971-423b-357c-08d566389fe0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB0524; x-ms-traffictypediagnostic: DB3PR07MB0524: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(11241501184)(806099)(2400081)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0524; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0524; x-forefront-prvs: 05669A7924 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4mNPOC5OKskr5cYFJODQHa67rkiIqQZYp5xi5oUN/cCUIKz+6/GpNDSuLUO83eP7YoRLbN6mGGqoOkNq/eagZJUeJdFgyvqPcCq22NG4zfJm5RQcc7aH1oY4ouApyhUO spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <36B08D6A4BB72445944C30671A1D28F8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: dad3e91e-1971-423b-357c-08d566389fe0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2018 10:19:32.8172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0524 Archived-At: Subject: Re: [TLS] A question for TLS middle-box/middleware vendors/implementers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 10:19:39 -0000 SGkgWW9hdiwNCg0KVGhhbmtzIGZvciB0aGUgYW5zd2VycyAtIG11Y2ggYXBwcmVjaWF0ZWQuDQoN Ck9uIDI3LzAxLzIwMTgsIDE5OjMxLCAiWW9hdiBOaXIiIDx5bmlyLmlldGZAZ21haWwuY29tPiB3 cm90ZToNCj4gVGhlIGxlbmd0aCBmaWVsZCBpcyBieXRlLWFsaWduZWQuIFNvIGFueSBpbXBsZW1l bnRhdGlvbiBvZiBhIFRMUw0KPiBwYXJzZXIgb3IgVExTIHByb3h5IHdpbGwgZG8gb25lIG9mIHR3 byB0aGluZ3M6DQo+IA0KPiAxLiBDb25zaWRlciB0aGUgTVNCIHRvIGJlIGEgbXVzdC1iZS16ZXJv IGJpdCBhbmQgZHJvcCBhbnkgbGVuZ3RoIGZpZWxkDQo+IHRoYXQgaGFzIGl0IHNldCBhcyBmYXVs dHkuDQo+IA0KPiAyLiBJZ25vcmUgdGV4dCBhYm91dCBsaW1pdHMgb24gbGVuZ3RoIGFuZCBhc3N1 bWUgdGhlIHJlY29yZCBpcyB0aGF0DQo+IGJpZy4gRGVwZW5kaW5nIG9uIHdoYXQgZmllbGQgdGhh dCBpcywgdGhpcyBtYXkgY2F1c2UgYSBkcm9wIG9uIHNvbWUNCj4gb3RoZXIgc2FuaXR5IGNoZWNr Lg0KPiANCj4gQXMgYWx3YXlzIHRoZXJl4oCZcyBvcHRpb24gIzMgKGNyYXNoKSwgYnV0IHRoZSBp bmR1c3RyeSBpcyBnZXR0aW5nDQo+IGJldHRlciBhdCBhdm9pZGluZyB0aGF0Lg0KPiANCj4gWW91 IHNlZW0gdG8gd2FudCB0aGUgYmVoYXZpb3VyIHRoYXQgdGhlIG1pZGRsZWJveCBtYXNrcyBvdXQg dGhlDQo+IG11c3QtYmUtemVybyBiaXRzIGFuZCBjb25zaWRlcnMgb25seSB0aGUgcmVsZXZhbnQg bGVuZ3RoIGJpdHMuIEkgZG9u4oCZdA0KPiB0aGluayB0aGF0IHdvdWxkIHBhc3MgY29kZSByZXZp ZXcgYXQgbXkgZm9ybWVyIGVtcGxveWVyLg0KDQpXaGF0IEkgd2FzIHRoaW5raW5nIHdhcyByYXRo ZXIgIm9uY2UgaGFuZHNoYWtlIGlzIGRvbmUgYW5kIGNsaWVudCBoYXMNCnN1Y2Nlc3NmdWxseSBw YXNzZWQgdGhlIFNOSSBjaGVja3MsIGp1c3QgYmxpbmRseSBjb3B5IHRoZSBieXRlIHN0cmVhbQ0K YWNyb3NzLiIgSSBoYWQgdGhpcyBzcGVjaWZpYyBtZW50YWwgbW9kZWwgKHRoYXQgb2YgYW4gSFRU UFMgZmlsdGVyKSBpbg0KbXkgaGVhZCwgd2hpY2ggb2YgY291cnNlIGlzIGp1c3Qgb25lIG9mIG1h bnkuDQoNCklmIHRoZSB1c2UgY2FzZSBpcyAiY2hlY2sgZm9yIGRhdGEgZXhmaWx0cmF0aW9uIG9y IGNvdmVydCBjaGFubmVscyIsDQp0aGVuIHRoZSBib3ggaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUg YSBmdWxseS1mbGVkZ2VkIGludGVyY2VwdGlvbiBwcm94eS4NCkluIHRoYXQgY2FzZSB0aGUgcGFy c2VyIGNhbid0IGJlIHNsb3BweSwgYW5kIHRoZSBiaXQgd2lsbCBub3QgZ28gdGhyb3VnaA0KdW5u b3RpY2VkIChhcyB5b3UgY29ycmVjdGx5IG5vdGUgYWJvdmUpLg0KDQpCdXQgLSBwYXJkb24gYSBu YWl2ZSBtaW5kIC0gIHRoZXNlIGxvb2sgbGlrZSB0aGUga2luZCBvZiBib3hlcyB0aGF0IHlvdQ0K Y2FuJ3QganVzdCBzd2l0Y2ggb24gYW5kIGZvcmdldCBhYm91dC4gIEluc3RlYWQsIEknZCBpbWFn aW5lIHlvdSBuZWVkIHRvDQprZWVwIHRoZWlyIHJlbGVhc2UgY3ljbGUgYWxpZ25lZCB3aXRoIHRo YXQgb2YgdGhlIGVuZHBvaW50cywgZXNwZWNpYWxseQ0KYnJvd3NlcnMsIHdoaWNoIHRlbmRzIHRv IGJlIHByZXR0eSBhZ2dyZXNzaXZlLiAgKEJ1dCB5ZXMsIG9uZSB0aGluZyBpcw0KdGhlIHZlbmRv ciByZWxlYXNlIGN5Y2xlLCBhbmQgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBvbmUgaXMgdGhlIG5l dHdvcmsNCm9wZXJhdG9yJ3MgdXBncmFkZSBzY2hlZHVsZS4uLikNCg0KU2luY2UgeW91IGFyZSBo ZXJlLCBhbmQgeW91IGhhdmUgYW1hc3NlZCBhIGNvbnNpZGVyYWJsZSBhbW91bnQgb2Ygd2lzZG9t DQppbiB0aGlzIHNwYWNlLCBJIGhhdmUgYSBmdXJ0aGVyIHF1ZXN0aW9uOiBJcywgaW4geW91ciBv cGluaW9uLCBEVExTIGluIGENCmJldHRlciBzcG90IHRoYW4gVExTIFdSVCB0aGUgdXNlIG9mIHRo YXQgYml0Pw0KDQpDaGVlcnMgYW5kIHRoYW5rcyBhZ2Fpbg0KDQo= From nobody Sun Jan 28 11:38:13 2018 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 DC8E012FB3A for ; Sun, 28 Jan 2018 11:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0OjryZAwCYKY for ; Sun, 28 Jan 2018 11:38:10 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 BEA1E12FB38 for ; Sun, 28 Jan 2018 11:38:09 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id g21so4933636wrb.13 for ; Sun, 28 Jan 2018 11:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ff+Os4hSfwdnbgBGUBIcnMLdu9OF2LH4T7meHqcz/L0=; b=kIBwMLZX3vcMWXTonHqQj49+UOEH9lcI5ORHE2DSYsJnJ6JAinbl6qCbs1ErTM64tE fqm3B6HHK992lN+UMq53iXyRXFGRLqRIHwbORLraL5x5CD0sO86eR+vOrk/ubyfPkN4A nTCK/0vbgSeYm6SuHTxEzYcxlhFCAKqSFGCtea17PenGQV6gUJaNn04Nid0r1iYQE5TI vSN83ZxoKK55CYOas3dcZNHI4jap3mgkNf93rslJR/kWfEWdEFN6oZY/j+bj447i/EuP leWDaPA6YK/FDfjBH1mMQUDLX+OgASX8EB+/yrOqC2s3/Oh+p3j+Imk/IZKkN5qCtNQ1 BW7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ff+Os4hSfwdnbgBGUBIcnMLdu9OF2LH4T7meHqcz/L0=; b=Rle5gsnAsHna3TMkc/LIFBJiVUN4MEf0ODTOLP08Kf40qU6MhAVRF/o8anHUcStFpG 2gAr3dcd5zY+Tmv61g/Y3WAavFdyjWbTs1ySdS+VohO97lodRF1ivhVKfyk28ajlPbVc +pXr6vVPZ4rZ+yLk5xy2TiOKTRPdetqI4WoijjPRfEo0G81B/VolBMia/85u/AkfyQ+S 3fXNGkjexDctF/hsLmbLP0uKbg7XLOiyBCAnLFE1ttUfLxQLv+07ZO2j5tX7sUrdQCp/ ZDJHqu3kmrBtnLx4uMkXpJRagF7b4NAeUT1ZRmczWT639z3HNn5a9qB9hI+jutMiil1k PQxQ== X-Gm-Message-State: AKwxytdP4yFiOt3ef9G8bX9quN+EENaaLE5j33JzOPV8D/uo9f4EWMn/ 4U0E4Pzq1CnHUtVVlVnWDqw= X-Google-Smtp-Source: AH8x225H2pwpIJQcxb96pi4royjYVPaL1y7H9yVCyfnfl05Lj5NKI5/P6VC9UhxAJlg3dmk6ru/unw== X-Received: by 10.223.186.194 with SMTP id w2mr16161181wrg.154.1517168288273; Sun, 28 Jan 2018 11:38:08 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p9sm11935810wra.76.2018.01.28.11.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jan 2018 11:38:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Yoav Nir In-Reply-To: Date: Sun, 28 Jan 2018 21:38:04 +0200 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] A question for TLS middle-box/middleware vendors/implementers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 19:38:12 -0000 Hi, Thomas Inline > On 28 Jan 2018, at 12:19, Fossati, Thomas (Nokia - GB/Cambridge, UK) = wrote: >=20 > Hi Yoav, >=20 > Thanks for the answers - much appreciated. >=20 > On 27/01/2018, 19:31, "Yoav Nir" wrote: >> The length field is byte-aligned. So any implementation of a TLS >> parser or TLS proxy will do one of two things: >>=20 >> 1. Consider the MSB to be a must-be-zero bit and drop any length = field >> that has it set as faulty. >>=20 >> 2. Ignore text about limits on length and assume the record is that >> big. Depending on what field that is, this may cause a drop on some >> other sanity check. >>=20 >> As always there=E2=80=99s option #3 (crash), but the industry is = getting >> better at avoiding that. >>=20 >> You seem to want the behaviour that the middlebox masks out the >> must-be-zero bits and considers only the relevant length bits. I = don=E2=80=99t >> think that would pass code review at my former employer. >=20 > What I was thinking was rather "once handshake is done and client has > successfully passed the SNI checks, just blindly copy the byte stream > across." I had this specific mental model (that of an HTTPS filter) in > my head, which of course is just one of many. When middleboxes just classify and route (at Check Point we called that = =E2=80=9Cpassive inspection=E2=80=9D as opposed to =E2=80=9Cactive = inspection=E2=80=9D which was a TLS proxy) then yes - as soon as the = data becomes encrypted you either drop it or let it through. As this is = much higher performance (a given piece of hardware can handle much more = passive inspection that it can active inspection), it was preferred for = domains that were considered low-risk.=20 TLS 1.3 means that a passive proxy needs to make the decision earlier. > If the use case is "check for data exfiltration or covert channels", > then the box is probably going to be a fully-fledged interception = proxy. > In that case the parser can't be sloppy, and the bit will not go = through > unnoticed (as you correctly note above). >=20 > But - pardon a naive mind - these look like the kind of boxes that = you > can't just switch on and forget about. Instead, I'd imagine you need = to > keep their release cycle aligned with that of the endpoints, = especially > browsers, which tends to be pretty aggressive. (But yes, one thing is > the vendor release cycle, and a completely different one is the = network > operator's upgrade schedule=E2=80=A6) Vendors release updates at a good pace, some through software upgrades = and some through updating data files. An upgrade from supporting TLS 1.2 = to supporting TLS 1.3 as a proxy usually requires a software upgrade. = But the changes for passive proxy can be done through issuing an update = to some regular expression or other rule. Typically customers buy a = piece of software and subscribe to updates.=20 The Internet is full of old versions because the administrators don=E2=80=99= t don=E2=80=99t want to rock the boat or are content with a good, stable = release, the same way that Windows 7 is still so popular. In some cases = the middlebox vendor has gone out of business. The Internet is also full of middleboxes where the subscription was = allowed to lapse. It seems like carelessness.=20 > Since you are here, and you have amassed a considerable amount of = wisdom > in this space, I have a further question: Is, in your opinion, DTLS in = a > better spot than TLS WRT the use of that bit? With a firewall that doesn=E2=80=99t know about DTLS, there are three = choices: 1. Allow all the DTLS 2. Block all the DTLS 3. Write a regular expression (or equivalent) that will check the DTLS = handshake for sanity. If DTLS becomes popular, newer versions of firewalls will be able to = handle them the same as they do TLS. For now, DTLS is seeing little use. Yoav From nobody Mon Jan 29 02:04:09 2018 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 D3E9112DA50 for ; Mon, 29 Jan 2018 02:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 7y8UNKguLnkn for ; Mon, 29 Jan 2018 02:04:05 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10092.outbound.protection.outlook.com [40.107.1.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B2B12D871 for ; Mon, 29 Jan 2018 02:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DqKaXUnSz+5dEsUMpuC6508jVF1zsU6mKZIIwiqXRyY=; b=O5UdFDxIw3P0e4AAuWN2wnaJjjtCziaQ6YSvowaWQISOHxCxD69f95ioyIVV6AUeMQVD0GxSRenUlK/P618rCNSkVQB7jRzbz1BImssN+FfXkjZpt+lq8O91RVVq24yQYIJOmd/TfiVOuXl3rm4FeSDC3KY9jGKTgIQi6g8M5Y8= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB137.eurprd07.prod.outlook.com (10.242.132.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Mon, 29 Jan 2018 10:04:02 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.008; Mon, 29 Jan 2018 10:04:01 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Yoav Nir CC: "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] A question for TLS middle-box/middleware vendors/implementers Thread-Index: AQHTl4wVsEsS32ldTEGo2Z4sXyi6/aOIG8sAgAD4FYCAAJwOAIAA8fEA Date: Mon, 29 Jan 2018 10:04:01 +0000 Message-ID: References: <7CC4F5F0-DCC1-420E-B91A-A4D5B9FC5D53@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB137; 7:Z81hHjsIxCY0MJZRjkZ6nslS1T7+cbY7Xx+yu+GHh+sOcDOsxt340VN6EsLhMrMswzqnK3n9iv+Qc7DE3bnZbmv7mAPqA8gGWxWNfuhSJrqpKsZdqleAp/JBXD96sRPsdGKXLPevSi8FqRGJyT4KfrBqcVmwVCm/eXYZCRo28Hv78mmDUMVgB+U8ZZpAGnlz/U7D7zdPNJP3/x5YyOYtzIz+1Z0d+1OejV/ClKDmWm5s873jUAXzU7rKlV/84RL5 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(979002)(376002)(366004)(346002)(39380400002)(39860400002)(396003)(189003)(199004)(107886003)(6916009)(3280700002)(186003)(105586002)(39060400002)(4326008)(25786009)(3660700001)(68736007)(93886005)(53546011)(2950100002)(106356001)(6506007)(58126008)(102836004)(36756003)(59450400001)(316002)(83506002)(54906003)(76176011)(229853002)(99286004)(3846002)(2900100001)(7736002)(82746002)(86362001)(6512007)(6436002)(6486002)(53936002)(6116002)(26005)(5660300001)(8936002)(81166006)(81156014)(8676002)(33656002)(6246003)(5250100002)(305945005)(2906002)(83716003)(97736004)(478600001)(66066001)(14454004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB137; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b0bbbbb3-b666-419b-ebe8-08d566ff9f49 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB137; x-ms-traffictypediagnostic: DB3PR07MB137: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231101)(11241501184)(806099)(944501161)(6055026)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DB3PR07MB137; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB137; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4/07OjUS1qhV+NChWVQZYL6XQFzBnLvERyiBHP/HoTreU+08V+bgL3a9s9meHS46955t7tPJFI6Qme9jIs92iENjeKv5+l1AgL/XeJVO31n1mG8K7NlIIm+ByDiFU+A3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0bbbbb3-b666-419b-ebe8-08d566ff9f49 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2018 10:04:01.6502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB137 Archived-At: Subject: Re: [TLS] A question for TLS middle-box/middleware vendors/implementers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 10:04:08 -0000 SGkgWW9hdiwNCg0KT24gMjgvMDEvMjAxOCwgMTk6MzgsICJZb2F2IE5pciIgPHluaXIuaWV0ZkBn bWFpbC5jb20+IHdyb3RlOg0KPiA+IFdoYXQgSSB3YXMgdGhpbmtpbmcgd2FzIHJhdGhlciAib25j ZSBoYW5kc2hha2UgaXMgZG9uZSBhbmQgY2xpZW50IGhhcw0KPiA+IHN1Y2Nlc3NmdWxseSBwYXNz ZWQgdGhlIFNOSSBjaGVja3MsIGp1c3QgYmxpbmRseSBjb3B5IHRoZSBieXRlIHN0cmVhbQ0KPiA+ IGFjcm9zcy4iIEkgaGFkIHRoaXMgc3BlY2lmaWMgbWVudGFsIG1vZGVsICh0aGF0IG9mIGFuIEhU VFBTIGZpbHRlcikgaW4NCj4gPiBteSBoZWFkLCB3aGljaCBvZiBjb3Vyc2UgaXMganVzdCBvbmUg b2YgbWFueS4NCj4gDQo+IFdoZW4gbWlkZGxlYm94ZXMganVzdCBjbGFzc2lmeSBhbmQgcm91dGUg KGF0IENoZWNrIFBvaW50IHdlIGNhbGxlZA0KPiB0aGF0IOKAnHBhc3NpdmUgaW5zcGVjdGlvbuKA nSBhcyBvcHBvc2VkIHRvIOKAnGFjdGl2ZSBpbnNwZWN0aW9u4oCdIHdoaWNoIHdhcw0KPiBhIFRM UyBwcm94eSkgdGhlbiB5ZXMgLSBhcyBzb29uIGFzIHRoZSBkYXRhIGJlY29tZXMgZW5jcnlwdGVk IHlvdQ0KPiBlaXRoZXIgZHJvcCBpdCBvciBsZXQgaXQgdGhyb3VnaC4gQXMgdGhpcyBpcyBtdWNo IGhpZ2hlciBwZXJmb3JtYW5jZQ0KPiAoYSBnaXZlbiBwaWVjZSBvZiBoYXJkd2FyZSBjYW4gaGFu ZGxlIG11Y2ggbW9yZSBwYXNzaXZlIGluc3BlY3Rpb24NCj4gdGhhdCBpdCBjYW4gYWN0aXZlIGlu c3BlY3Rpb24pLCBpdCB3YXMgcHJlZmVycmVkIGZvciBkb21haW5zIHRoYXQgd2VyZQ0KPiBjb25z aWRlcmVkIGxvdy1yaXNrLiANCj4gDQo+IFRMUyAxLjMgbWVhbnMgdGhhdCBhIHBhc3NpdmUgcHJv eHkgbmVlZHMgdG8gbWFrZSB0aGUgZGVjaXNpb24gZWFybGllci4NCj4gDQo+ID4gSWYgdGhlIHVz ZSBjYXNlIGlzICJjaGVjayBmb3IgZGF0YSBleGZpbHRyYXRpb24gb3IgY292ZXJ0IGNoYW5uZWxz IiwNCj4gPiB0aGVuIHRoZSBib3ggaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgYSBmdWxseS1mbGVk Z2VkIGludGVyY2VwdGlvbg0KPiA+IHByb3h5LiAgSW4gdGhhdCBjYXNlIHRoZSBwYXJzZXIgY2Fu J3QgYmUgc2xvcHB5LCBhbmQgdGhlIGJpdCB3aWxsDQo+ID4gbm90IGdvIHRocm91Z2ggdW5ub3Rp Y2VkIChhcyB5b3UgY29ycmVjdGx5IG5vdGUgYWJvdmUpLg0KPiA+IA0KPiA+IEJ1dCAtIHBhcmRv biBhIG5haXZlIG1pbmQgLcKgdGhlc2UgbG9vayBsaWtlIHRoZSBraW5kIG9mIGJveGVzIHRoYXQN Cj4gPiB5b3UgY2FuJ3QganVzdCBzd2l0Y2ggb24gYW5kIGZvcmdldCBhYm91dC7CoCBJbnN0ZWFk LCBJJ2QgaW1hZ2luZSB5b3UNCj4gPiBuZWVkIHRvIGtlZXAgdGhlaXIgcmVsZWFzZSBjeWNsZSBh bGlnbmVkIHdpdGggdGhhdCBvZiB0aGUgZW5kcG9pbnRzLA0KPiA+IGVzcGVjaWFsbHkgYnJvd3Nl cnMsIHdoaWNoIHRlbmRzIHRvIGJlIHByZXR0eSBhZ2dyZXNzaXZlLsKgIChCdXQgeWVzLA0KPiA+ IG9uZSB0aGluZyBpcyB0aGUgdmVuZG9yIHJlbGVhc2UgY3ljbGUsIGFuZCBhIGNvbXBsZXRlbHkg ZGlmZmVyZW50DQo+ID4gb25lIGlzIHRoZSBuZXR3b3JrIG9wZXJhdG9yJ3MgdXBncmFkZSBzY2hl ZHVsZeKApikNCj4gDQo+IFZlbmRvcnMgcmVsZWFzZSB1cGRhdGVzIGF0IGEgZ29vZCBwYWNlLCBz b21lIHRocm91Z2ggc29mdHdhcmUgdXBncmFkZXMNCj4gYW5kIHNvbWUgdGhyb3VnaCB1cGRhdGlu ZyBkYXRhIGZpbGVzLiBBbiB1cGdyYWRlIGZyb20gc3VwcG9ydGluZyBUTFMNCj4gMS4yIHRvIHN1 cHBvcnRpbmcgVExTIDEuMyBhcyBhIHByb3h5IHVzdWFsbHkgcmVxdWlyZXMgYSBzb2Z0d2FyZQ0K PiB1cGdyYWRlLiBCdXQgdGhlIGNoYW5nZXMgZm9yIHBhc3NpdmUgcHJveHkgY2FuIGJlIGRvbmUg dGhyb3VnaCBpc3N1aW5nDQo+IGFuIHVwZGF0ZSB0byBzb21lIHJlZ3VsYXIgZXhwcmVzc2lvbiBv ciBvdGhlciBydWxlLiBUeXBpY2FsbHkNCj4gY3VzdG9tZXJzIGJ1eSBhIHBpZWNlIG9mIHNvZnR3 YXJlIGFuZCBzdWJzY3JpYmUgdG8gdXBkYXRlcy4gDQo+IA0KPiBUaGUgSW50ZXJuZXQgaXMgZnVs bCBvZiBvbGQgdmVyc2lvbnMgYmVjYXVzZSB0aGUgYWRtaW5pc3RyYXRvcnMgZG9u4oCZdA0KPiBk b27igJl0IHdhbnQgdG8gcm9jayB0aGUgYm9hdCBvciBhcmUgY29udGVudCB3aXRoIGEgZ29vZCwg c3RhYmxlDQo+IHJlbGVhc2UsIHRoZSBzYW1lIHdheSB0aGF0IFdpbmRvd3MgNyBpcyBzdGlsbCBz byBwb3B1bGFyLiBJbiBzb21lDQo+IGNhc2VzIHRoZSBtaWRkbGVib3ggdmVuZG9yIGhhcyBnb25l IG91dCBvZiBidXNpbmVzcy4NCj4gDQo+IFRoZSBJbnRlcm5ldCBpcyBhbHNvIGZ1bGwgb2YgbWlk ZGxlYm94ZXMgd2hlcmUgdGhlIHN1YnNjcmlwdGlvbiB3YXMNCj4gYWxsb3dlZCB0byBsYXBzZS4g SXQgc2VlbXMgbGlrZSBjYXJlbGVzc25lc3MuIA0KCQ0KVGhhbmtzIGEgbG90IGZvciB0aGUgdmVy eSBpbnN0cnVjdGl2ZSBpbmZvLg0KDQo+ID4gU2luY2UgeW91IGFyZSBoZXJlLCBhbmQgeW91IGhh dmUgYW1hc3NlZCBhIGNvbnNpZGVyYWJsZSBhbW91bnQgb2YNCj4gPiB3aXNkb20gaW4gdGhpcyBz cGFjZSwgSSBoYXZlIGEgZnVydGhlciBxdWVzdGlvbjogSXMsIGluIHlvdXINCj4gPiBvcGluaW9u LCBEVExTIGluIGEgYmV0dGVyIHNwb3QgdGhhbiBUTFMgV1JUIHRoZSB1c2Ugb2YgdGhhdCBiaXQ/ DQo+IA0KPiBXaXRoIGEgZmlyZXdhbGwgdGhhdCBkb2VzbuKAmXQga25vdyBhYm91dCBEVExTLCB0 aGVyZSBhcmUgdGhyZWUgY2hvaWNlczoNCj4gMS4gQWxsb3cgYWxsIHRoZSBEVExTDQo+IDIuIEJs b2NrIGFsbCB0aGUgRFRMUw0KPiAzLiBXcml0ZSBhIHJlZ3VsYXIgZXhwcmVzc2lvbiAob3IgZXF1 aXZhbGVudCkgdGhhdCB3aWxsIGNoZWNrIHRoZSBEVExTDQo+ICAgIGhhbmRzaGFrZSBmb3Igc2Fu aXR5Lg0KPiANCj4gSWYgRFRMUyBiZWNvbWVzIHBvcHVsYXIsIG5ld2VyIHZlcnNpb25zIG9mIGZp cmV3YWxscyB3aWxsIGJlIGFibGUgdG8NCj4gaGFuZGxlIHRoZW0gdGhlIHNhbWUgYXMgdGhleSBk byBUTFMuIEZvciBub3csIERUTFMgaXMgc2VlaW5nIGxpdHRsZQ0KPiB1c2UuDQoNClNvLCBpZiBJ IHJlYWQgeW91IGNvcnJlY3RseSwgaW4gdGVybXMgb2Ygb3ZlcnJpZGluZyBsZW5ndGgncyBNU0Ig Ym90aCAxDQphbmQgMyBhcmUgc2FmZSBwbGFjZXMgLSBhcyBsb25nIGFzIHdlIGFwcGx5IHRoZSBu ZXcgc2VtYW50aWNzIG9ubHkgYWZ0ZXINCmhhbmRzaGFrZSBoYXMgY29tcGxldGVkLg0KDQoyLCBp cyBlaXRoZXIgImVhc2lseSIgZml4YWJsZSB2aWEgYSBjb25maWd1cmF0aW9uIGNoYW5nZSB0byBm YWxsIGJhY2sgdG8NCm9uZSBvZiAxIG9yIDMsIG9yIGNvbXBsZXRlbHkgdW5maXhhYmxlIC0gdGhl IHBhdGggaXMgdG90YWxseSBicm9rZW4gZm9yDQpEVExTIGFueXdheSBiZWNhdXNlIHRoaXMgaXMg aG93IHRoZSBwb2xpY3kgbWFrZXIgaGFzIGRlY2lkZWQuDQoNCkNoZWVycywgdA0KDQoNCg0KDQoN Cg== From nobody Mon Jan 29 07:24:36 2018 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 78D9912EB01 for ; Mon, 29 Jan 2018 07:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 MWdrAsCdioTi for ; Mon, 29 Jan 2018 07:24:32 -0800 (PST) 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 42BBF12EC75 for ; Mon, 29 Jan 2018 07:22:43 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0TFHg7S011023 for ; Mon, 29 Jan 2018 15:22:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=Aisg+fJnXt3ECq5VUWHVGx/81Kn/JugldJ7dZRvDIfU=; b=Lme25t5386R6QbWJrNSt+ItI7u3auyOqq7jh2LInV7mUYJp2sV8JsmjhSHJgNxE+WLKy OHhleuBoQmRi/SdcwkCssaJHbOkdRzYEpGf+4d7WkcOIcYyt2iCF2hHUh61op+uy3ug9 Xu3EeYp/+dK0tJTRwsQVC8l6KY39l59Isy5dPgTt107rEqG1xwHfoA5wX99VcFGfCFew kP+7fZDa1UPS6StoyABMqf+/R4WXdi2rkcG9Fbo5U2IWFdqdMy5zFY3z3pFW56Bu9ynU n85aUl29k1Erbr7vpjiJVrQrvabsyIgUlgampHQQfZEzpN9UH3WIbPy6Pd+GqNSBUowo Wg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2frhjr1epb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 29 Jan 2018 15:22:42 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0TFL4Q8028723 for ; Mon, 29 Jan 2018 10:22:41 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2frnn154qn-1 for ; Mon, 29 Jan 2018 10:22:41 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id F296682ED9 for ; Mon, 29 Jan 2018 08:22:40 -0700 (MST) To: tls@ietf.org References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> From: Benjamin Kaduk Message-ID: <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> Date: Mon, 29 Jan 2018 09:22:40 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180126102659.GA5204@pinky> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-29_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=869 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-29_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=866 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290202 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 15:24:35 -0000 On 01/26/2018 04:26 AM, Alessandro Ghedini wrote: > Hello, > > Here's a fresh new update based on the latest round of discussion. > Thanks, the changes look good. The new note about "no ServerHello extension to echo back" makes me wonder if (not) echoing back in Certificate should also be mentioned, since the TLS 1.3 paradigm is that CertificateRequest extensions are also "requests" that can get "responses" in the Certificate message. I also wondered whether there was any sense in reserving codepoint 0 (of CertificateCompressionAlgorithm) for "uncompressed".  I guess not, since support for uncompressed certificates is implicit by means of not using the extension.  But sometimes keeping value 0 (basically) reserved is still useful. -Ben From nobody Tue Jan 30 12:55:06 2018 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 B4D9712FB11 for ; Tue, 30 Jan 2018 12:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 7tNCko-9R5mw for ; Tue, 30 Jan 2018 12:55:03 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0936412FAF8 for ; Tue, 30 Jan 2018 12:55:03 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id x27so19051191qtm.12 for ; Tue, 30 Jan 2018 12:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=H4ghNUJXDbf0597FfROpMfZNhOrxu3vjK3ZqZvbnNmM=; b=b09TqUYrjmpN1sOyp/qOxFtxaRXXb0zvR2ka4Z8EP9IrQMvFdzRHjZW9fIfrLGSrR1 Q+AVxExjARCvwxkM+/p/n0fPJRYYRlZSLOGq55/RajR29NK4N5v6MtYr71rkoJJQs2qd tDd74sPW7Ob+foJbXEYSXJRMY7ENeWlC4ENXY= 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:message-id:date:to; bh=H4ghNUJXDbf0597FfROpMfZNhOrxu3vjK3ZqZvbnNmM=; b=F8lxbqSgQlXv2JyiIZx+HdT41Z7rWVsrnipcZcMv374maApcJ7dL5+JHGCGMm3eIgB lqU5JSgjKhuHky38z4p2JAeXCYPE/s3nX13ye9OFIz2tRy7cqQDDdfS5ekKyMDoUs0wE SzoGPsAzf/sHqW09a90Y1E+dI/rHDa7G+c3dhxet5AfudrME0dTvZGle9VNlr2yMJoUg GxE1ZAeqMmq9PwQ20hFcA6gQyMpTV7U/8BXt9SBL+ENqwTiAIgZmHTYtbmdLSO3duIBT NPSZcREK2E/h8VBDU2uxI9kRWanwbE+RA+nW43tuxi5nAfy4yGIL8XFSdp0rgBn2fll1 Uxlw== X-Gm-Message-State: AKwxytff0VC/N1Zgn15bbiSGYlVk3EIq7SYGvamZOpPt1vSkBNR5UrDk TZV25Xw1m4/IhOUA2qEMr3cZBQlfdXc= X-Google-Smtp-Source: AH8x226NlKb71lAK4FxMWbOsszVy42E6vYP2juAXRLRTCqZ5EXq9jJgxzulrNjM3RNUpbyCZgHLotA== X-Received: by 10.200.17.144 with SMTP id d16mr41869456qtj.339.1517345702035; Tue, 30 Jan 2018 12:55:02 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id x1sm9057412qkd.77.2018.01.30.12.55.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 12:55:01 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <6D27D187-ABD3-442F-9EA1-1D1BC6180A6C@sn3rd.com> Date: Tue, 30 Jan 2018 15:55:00 -0500 To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [TLS] TLS@IETF101: agenda requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 20:55:05 -0000 All, The TLS WG will meet @ IETF101. Please submit requests for agenda time = to tls-chairs@ietf.org. Along with your request please let us know how = long you would like. We will send out a remind later, but we are trying = to get an early sense of how much time we will need. Thanks! J&S= From nobody Tue Jan 30 13:42:35 2018 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 C011512D87D for ; Tue, 30 Jan 2018 13:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KbZQUaqVXvJn for ; Tue, 30 Jan 2018 13:42:31 -0800 (PST) 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 E23C612421A for ; Tue, 30 Jan 2018 13:42:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 787B5BE56; Tue, 30 Jan 2018 21:42:27 +0000 (GMT) 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 M1qPlN7rc8Lb; Tue, 30 Jan 2018 21:42:23 +0000 (GMT) Received: from [192.168.1.8] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D8CBBE4C; Tue, 30 Jan 2018 21:42:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517348543; bh=doL1j0yAnXZu5qepnqY/ReXzLveqsU63MN3y/ZyQ8ro=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BAUglikm3b1xUuk4dGJYhg65/VsYiVKnOQCy0OT4CB9kxqEe90SmIXTFySZkRXXe8 Pyhapg4HOKazbRKjvbV9ZfOlF2qrXsXX8uRrRkdkjRSNo41AwdZQjlfRQo96Md9Ipv tXvktCTgPpbRKVc7iwqaSPpND7ChYj6Q7+JP0wKI= To: Kathleen Moriarty References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> Cc: tls@ietf.org From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> Date: Tue, 30 Jan 2018 21:42:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jhrTO3c5RJCA3vzO4bX5zapLje1hiGLTq" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:42:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jhrTO3c5RJCA3vzO4bX5zapLje1hiGLTq Content-Type: multipart/mixed; boundary="WS02W0G4NtsNwSP10Gt4IHOn4HyoOY9XZ"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty Cc: tls@ietf.org Message-ID: <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> In-Reply-To: <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> --WS02W0G4NtsNwSP10Gt4IHOn4HyoOY9XZ Content-Type: multipart/mixed; boundary="------------040782AC6882EB6AB99AD1F6" Content-Language: en-GB This is a multi-part message in MIME format. --------------040782AC6882EB6AB99AD1F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kathleen, The WGLC for this has expired. There was only one explicit comment [1] saying to ship it. The WG have chatted about this a bunch of times though so FWIW I think it'd be fair to conclude there's pretty good consensus for this. Cheers, S. [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html On 15/01/18 21:34, Stephen Farrell wrote: >=20 > Hiya, >=20 > Kathleen's a bit busy at the moment so asked that, as shepherd, > I kick off the WGLC for this one (as the two chairs are authors). > The idea is that I'll summarise the WGLC thread to her and she > can then decide if this is ready to move forward. >=20 > So this starts a 2-week WGLC, ending on January 29th. >=20 > Cheers, > Shepherdy Stephen. >=20 > On 03/01/18 13:57, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Transport Layer Security WG of the IE= TF. >> >> Title : IANA Registry Updates for TLS and DTLS >> Authors : Joe Salowey >> Sean Turner >> Filename : draft-ietf-tls-iana-registry-updates-03.txt >> Pages : 16 >> Date : 2018-01-03 >> >> Abstract: >> This document describes a number of changes to (D)TLS IANA registri= es >> that range from adding notes to the registry all the way to changin= g >> the registration policy. These changes were mostly motivated by WG= >> review of the (D)TLS-related registries undertaken as part of the >> TLS1.3 development process. This document updates many (D)TLS RFCs= >> (see updates header). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/= >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-upd= ates-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updat= es-03 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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 >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------040782AC6882EB6AB99AD1F6 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.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/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------040782AC6882EB6AB99AD1F6-- --WS02W0G4NtsNwSP10Gt4IHOn4HyoOY9XZ-- --jhrTO3c5RJCA3vzO4bX5zapLje1hiGLTq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJacOa/AAoJEFqy+vF7Fyvq7A8QAIBgpXRQbRMgAQksbmLMGgFb l3jgCqXowS8kLngevatOJC1UWE6oigoahWpYlqmex/IjRqMA6GBMPPjSv47YUIRX 6nMDY/XfvfXqidAS1zsvbWmndQgE2qKxDX4n5r8WYWzcfAmWWTuZgHx0aXSMRc3s nczod3ZILoouyyWabLWKMQ5GowCrvyF7Jg5pO3W9kaf921Yyyh28L1iDvTZhPKql qR15UcUfmeIZeHAwVJGtj0Qx/fLEGjzZU2T12hSu8soHGbuUl1eTjWIeB0vHB0dy de2rCD+Dn+dFuyWJ5/XHSQ8oHu1DAKlwYu1SAPGEk/oCAV++BNFS9W/Tkl16j2D8 yioLPWlropNdm+ArcJ+ySAQhsWleqBF/9cyPWH+dr9X9Xs4Idi88XBNyF1nnh3uD iR4PTzMDklfjkFX/0qaRN7enyWiWxYowbx9k59YN5/t/ANBiYf5Om1/aPoOX78Ec OtVXLAquXYYasMCC1k6CeTkFIpuaSQ+u7sOTbJL/y6va1TlIJfoURO53zcuhjkEJ I/9R25DIv26V0hfFUfeZZ8Zfhech15Xgq2Zg2NfZR7lYUzKlfqVhoY+9gGvSDGB2 2WwdCPdbb4tS/x/jEN+DHm5JzoZvaBBIpvm646jrPVjDYEjTOKE/RbARlGTiyjDt 8ahLZGDaHWSdC2FwI/QI =b3P0 -----END PGP SIGNATURE----- --jhrTO3c5RJCA3vzO4bX5zapLje1hiGLTq-- From nobody Tue Jan 30 13:54:52 2018 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 121D3131443 for ; Tue, 30 Jan 2018 13:54:51 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kyWEEMVZ91wR for ; Tue, 30 Jan 2018 13:54:49 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 43F20124319 for ; Tue, 30 Jan 2018 13:54:49 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id e76so10435682pfk.1 for ; Tue, 30 Jan 2018 13:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y9/qHhVSlzl5mp0kjnShW33hXBhGToQ9aAiVRPJpkNg=; b=HY5JOVBaNE1dOyR1IKELIfRDAXsSaEmmv3ket42jiDiuFnZXkva4vkTKQevBctvmpP Gmwreb/KBDlHD62Ctwjo6NAzg5WzHTasLi9rETE1VIFUT5trLfTd/HBYyPaHJgVo2MaR t7ZDCIUgHPlhIWHue2lRxWcsFquQcKRlmhjAi/X9/QyncJpyCjnYYf62cvNPodqP1hZf LB+znrjWyEPoIrK8W7JKO6n0cgrEO2Z1W+wkdw081G7NG19zQJErEsItQxooSuRhJKcL I5/e9BknUoiIWeWkKi41h3EZ1RTlJs5msritacfvLvShsBCLmgmBhoF+CuHJXzz1/aFh uIyA== 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:references:from:date :message-id:subject:to:cc; bh=y9/qHhVSlzl5mp0kjnShW33hXBhGToQ9aAiVRPJpkNg=; b=HujCrUbpo0Kv4vBjUhT/QMU7lC66JniRi/OgCczhG/E2Ms1kBIDeb9cV/WaSD7HHyg faH1H46/Uc4olEwPAlN3oYaKUxW+3TIUi2uO31/mKuzijGyq6PYUaTUMpOGnE01uEb6G yRATViCbLKk2Ni2yOt7eO/kkNJDyhCq+38uxSPh7a9tSwbGEU5Qe+xu8qw6p+B0mmsz7 zUcOK81ENr27jJ+6ymcv0PHUm1GTqwjJUioQwlqUilh0BYkJ+9z+G7sZ9WcES7g4XgGa TLs8jFXa8sT40fVJ3CAHqMeKrzMga+1voHkM3em4YjZQugXEQdfJprO3vaxlP0id3DNi RWaQ== X-Gm-Message-State: AKwxyteT9q1JGDZ/TLMM4EBBOeyO3NS+5pVIIMEEGDhytyhMsc2B/d4R q92KkTR4SlD0BJspSsDWDiGPISfTiwa6vfleZaM= X-Google-Smtp-Source: AH8x227P0BTVjM9XL0120ChN/2xEgHofy4iOb7MLKPrgaswAtedeUtbpLY1CGzGjlWHMFBjL8eBTh1rsgOOdg2jaEQY= X-Received: by 10.101.96.78 with SMTP id b14mr25520109pgv.339.1517349288858; Tue, 30 Jan 2018 13:54:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Tue, 30 Jan 2018 13:54:08 -0800 (PST) In-Reply-To: <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> From: Kathleen Moriarty Date: Tue, 30 Jan 2018 16:54:08 -0500 Message-ID: To: Stephen Farrell Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:54:51 -0000 Great, thank you very much, Stephen! I'll get it rolling towards publication with last call starting soon. I'll do my review in the next couple of days. Best regards, Kathleen On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell wrote: > > Hi Kathleen, > > The WGLC for this has expired. > > There was only one explicit comment [1] saying to ship it. > The WG have chatted about this a bunch of times though so > FWIW I think it'd be fair to conclude there's pretty good > consensus for this. > > Cheers, > S. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html > > On 15/01/18 21:34, Stephen Farrell wrote: >> >> Hiya, >> >> Kathleen's a bit busy at the moment so asked that, as shepherd, >> I kick off the WGLC for this one (as the two chairs are authors). >> The idea is that I'll summarise the WGLC thread to her and she >> can then decide if this is ready to move forward. >> >> So this starts a 2-week WGLC, ending on January 29th. >> >> Cheers, >> Shepherdy Stephen. >> >> On 03/01/18 13:57, 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 : IANA Registry Updates for TLS and DTLS >>> Authors : Joe Salowey >>> Sean Turner >>> Filename : draft-ietf-tls-iana-registry-updates-03.txt >>> Pages : 16 >>> Date : 2018-01-03 >>> >>> Abstract: >>> This document describes a number of changes to (D)TLS IANA registries >>> that range from adding notes to the registry all the way to changing >>> the registration policy. These changes were mostly motivated by WG >>> review of the (D)TLS-related registries undertaken as part of the >>> TLS1.3 development process. This document updates many (D)TLS RFCs >>> (see updates header). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03 >>> >>> >>> 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 >> > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) -- Best regards, Kathleen From nobody Tue Jan 30 14:02:38 2018 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 A5BE11300CE for ; Tue, 30 Jan 2018 14:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 PfiBGAYOgonb for ; Tue, 30 Jan 2018 14:02:34 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 80D5B13088A for ; Tue, 30 Jan 2018 14:02:33 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id o35so19279184qtj.13 for ; Tue, 30 Jan 2018 14:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tcEMoBLJinDidjnn/HUobyjL/hIOCfqQmCcyr/okLl4=; b=BhLdeYCLVHxen7n2kJ8GlJ0zc2MWdUfCzEgbKrNFRRki09O6LjdGSJA6VrZWbwyh4S Vo50CrIpf8s5/MOgN8YDJSAeVb+GzsZV63BKZbM4pI6MII6U1hIJYTfR2fBUaykXLS3R m0MaxAMU7I4D3pCwavRbuG79imTDXYwT9WencjJ/QAo6S4tE/ctLLpL3U1X8sQ3i0VNC Lx01bYgUGXZ8pw7ZVSt9p1MOZ8SaoNzv4dxTZhJFTBWYID9mmhOo8UvMJy+rBxvMefGQ Q4JoI1Q/M17EjJiPNgzFhbi3PIOWkxl7YGdvaGZ9uh9DRNQnh8qnMSQt/AaYJSNOyXP4 E7wQ== 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:references:from:date :message-id:subject:to:cc; bh=tcEMoBLJinDidjnn/HUobyjL/hIOCfqQmCcyr/okLl4=; b=NMdmlCp9/Y0WCxEQST47nq7KY6Czoshbb8szhAYpCkCAeJtuIw2zJa9b7YmhSRoU7L Y9lPYlYRydG+Y7GVh+5fsI6V3hnJna+6VKlHWHmZWKw4XmW8dPcaFnW3WBBRSm7Ff5Kl 57ETU6YFJndH9KRFB2di5cXgGqNLlfVpEZkBpXgjb5zuF8TqwBdtxsAgTcP3awcwaWSV W3qgI1r5VoYsPRunmHInWrvILqG+ulc8YzqcMt5afJBuY9Rn71WpuFxmK9MuUdrYKOml mPkK7/OrcI8JytmSnBhqbZqAAOiokvs345mPuKN9xd2pupWjEtqugdkbeYTh9e4c8yqD B0eQ== X-Gm-Message-State: AKwxytdp7GVKtPPGtNHD8FXU9gzbZsRVQ7GjMNnKYR1Z101JFwKbMyKm X9QLPyjOy4en3W0z5B0q3a0yutfS8Rm2HkHhP0i0xsPI X-Google-Smtp-Source: AH8x2250Y+1hMXm+RxSzKAZ7GydbLugiw10zeZmWje5Eyd0zMNyOA0PjW0r5ruEBug7Xe6ISprElZdZS7dfi7WlWesc= X-Received: by 10.200.18.131 with SMTP id y3mr37031739qti.330.1517349752385; Tue, 30 Jan 2018 14:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.12.130 with HTTP; Tue, 30 Jan 2018 14:02:31 -0800 (PST) In-Reply-To: <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> From: Victor Vasiliev Date: Tue, 30 Jan 2018 17:02:31 -0500 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08289828fe805105640584ba" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 22:02:37 -0000 --089e08289828fe805105640584ba Content-Type: text/plain; charset="UTF-8" On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk wrote: > > The new note about "no ServerHello extension to echo back" makes me > wonder if (not) echoing back in Certificate should also be mentioned, > since the TLS 1.3 paradigm is that CertificateRequest extensions are > also "requests" that can get "responses" in the Certificate message. > True, though I guess this depends on your definition of "response"? > I also wondered whether there was any sense in reserving codepoint 0 (of > CertificateCompressionAlgorithm) for "uncompressed". I guess not, since > support for uncompressed certificates is implicit by means of not using > the extension. But sometimes keeping value 0 (basically) reserved is > still useful. > I've considered that, but decided that this would just introduce two ways to do the same thing (send certificate uncompressed), so I decided against it. --089e08289828fe805105640584ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
The new note about "no ServerHello extension to echo back" makes = me
wonder if (not) echoing back in Certificate should also be mentioned,
since the TLS 1.3 paradigm is that CertificateRequest extensions are
also "requests" that can get "responses" in the Certifi= cate message.

True, though I guess this= depends on your definition of "response"?
=C2=A0
=
I also wondered whether there was any sense in reserving codepoint 0 (of CertificateCompressionAlgorithm) for "uncompressed".=C2=A0 I= guess not, since
support for uncompressed certificates is implicit by means of not using
the extension.=C2=A0 But sometimes keeping value 0 (basically) reserved is<= br> still useful.

I've considered that,= but decided that this would just introduce two ways to do
the sa= me thing (send certificate uncompressed), so I decided against it.
--089e08289828fe805105640584ba-- From nobody Wed Jan 31 06:39:03 2018 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 9648612EB78 for ; Wed, 31 Jan 2018 06:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 kNLT80mujXK1 for ; Wed, 31 Jan 2018 06:38:59 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 BE28112D969 for ; Wed, 31 Jan 2018 06:35:42 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id s3so22024940qtb.10 for ; Wed, 31 Jan 2018 06:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mlxtp16MhvE16injt/Z0bK3RmVjBRMVhLnvaIh/yVL8=; b=bWHiqCtUA1rEA3YglbiDONZhKDJBnI1iqMm1NfpMNL+0FCyUyVTVGg+BPmhB9NlKBx 88lvwA4IG+8PK034DvF0ueEsT5CV6s4c2AJcS22/ny45A0Lfj6orEroOdH4nb8DHCHuw iWmMCgVihkzj5Y+Yz1t/45TG4InN2BpuFxSd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mlxtp16MhvE16injt/Z0bK3RmVjBRMVhLnvaIh/yVL8=; b=qdnLvDkiPzI7PnNTrW9fMdGcX42qqPk1XoYLJzP5a9sLSEI6lB8cmRB5zJGxi5nosa 3fEJSbYpmbmb7U3UIqXZFawJOUFhqlrg5zXH+MVtuMpsInZmoZtDx0YduGjQ77m2dh/D NN8KlRwqTMHX2Gve4MGIrylI/LVcM1Lx6vGWpOSj+jZEeujw9LiqEuIhPnlPZHHFVHCA 0DX6Q3HErWGA0f7Hdo8hBFNp1nz4BRyIOyEOJlMCbJg/5zCShpPZx1pj0SYp2QKtMgX3 m65EMZhkFIVibKf6Wv6LVOPbLrNvgzfq1C8R+j29brCLe7Q1MxcMxwnxANYGvWL/oYym 1nPA== X-Gm-Message-State: AKwxytfchhkx7s4Yh4QuoEXeLoAeW+6DjwuXu4eUaG+CG5MOOyBT6VR9 SCeNjjC6326cnjqPJcjMLfz6MmAhpJA= X-Google-Smtp-Source: AH8x225ZuIPRwCXUld7wabZkF7zmbhuhevuf170Eo8TNSGDd+tyoqnI2og+IYthdNJYeP2h/Qa5uvg== X-Received: by 10.200.44.34 with SMTP id d31mr49468236qta.14.1517409341842; Wed, 31 Jan 2018 06:35:41 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id b29sm1191005qkb.71.2018.01.31.06.35.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 06:35:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 31 Jan 2018 09:35:38 -0500 Cc: Stephen Farrell , "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 14:39:02 -0000 I have one PR that address both the WGLC comments (from mt and ekr): https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 If you=E2=80=99ve got other suggested changes let me know and I can = submit another PR and do the final merges before you initiate the = IETFLC. Cheers, spt > On Jan 30, 2018, at 16:54, Kathleen Moriarty = wrote: >=20 > Great, thank you very much, Stephen! I'll get it rolling towards > publication with last call starting soon. I'll do my review in the > next couple of days. >=20 > Best regards, > Kathleen >=20 > On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell > wrote: >>=20 >> Hi Kathleen, >>=20 >> The WGLC for this has expired. >>=20 >> There was only one explicit comment [1] saying to ship it. >> The WG have chatted about this a bunch of times though so >> FWIW I think it'd be fair to conclude there's pretty good >> consensus for this. >>=20 >> Cheers, >> S. >>=20 >> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html >>=20 >> On 15/01/18 21:34, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>> Kathleen's a bit busy at the moment so asked that, as shepherd, >>> I kick off the WGLC for this one (as the two chairs are authors). >>> The idea is that I'll summarise the WGLC thread to her and she >>> can then decide if this is ready to move forward. >>>=20 >>> So this starts a 2-week WGLC, ending on January 29th. >>>=20 >>> Cheers, >>> Shepherdy Stephen. >>>=20 >>> On 03/01/18 13:57, internet-drafts@ietf.org wrote: >>>>=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 : IANA Registry Updates for TLS and DTLS >>>> Authors : Joe Salowey >>>> Sean Turner >>>> Filename : draft-ietf-tls-iana-registry-updates-03.txt >>>> Pages : 16 >>>> Date : 2018-01-03 >>>>=20 >>>> Abstract: >>>> This document describes a number of changes to (D)TLS IANA = registries >>>> that range from adding notes to the registry all the way to = changing >>>> the registration policy. These changes were mostly motivated by = WG >>>> review of the (D)TLS-related registries undertaken as part of the >>>> TLS1.3 development process. This document updates many (D)TLS = RFCs >>>> (see updates header). >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -03 >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 3 >>>>=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 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >> -- >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jan 31 08:34:17 2018 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 9385F12EC46 for ; Wed, 31 Jan 2018 08:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uVAUZ7St3b68 for ; Wed, 31 Jan 2018 08:34:13 -0800 (PST) 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 9C29A12EC6B for ; Wed, 31 Jan 2018 08:34:08 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0VGWgef019773; Wed, 31 Jan 2018 16:34:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=QzLBWAqduMbpwozveQqS2yb+L4uDTUd2YVsqAxrRuwI=; b=f0L2xvRWq8VV9jerLHVfeKRKYj4GkKvE1XcAwjxgjYFBdnZLKIvqvZ6nJn4pBsKnyLYL xy8FNHw57L1pfFjdKXngvsnGOmGrOAPYV8vhHSWESygOO8K5vAkGfzTqY1/VzccfksyR CCsXmAA+bnRgX4rflbCqlqbUUYWtWz8SQPu2iVL/2WWVtTXQA+SO66EortqkeJnsLCDx Cq0csUNLCZqAFHuJJXv8pH+oVfPB28TjHdoSr8c7BZRGhuEb+0Fwdfv0k9avtTpfwh7d Ajn0xqtGVlAkMHiZ2Tx2fgc2hD0HzWL4gnJVVB0Vi0vPn2Z/YAxUtkLMGpVsP8uTNQ2Q SA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2fug7h09fq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2018 16:34:06 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0VGVC8W024660; Wed, 31 Jan 2018 11:34:06 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2ftpvr47tr-1; Wed, 31 Jan 2018 11:34:05 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id CC1B32007D; Wed, 31 Jan 2018 16:34:04 +0000 (GMT) To: Sean Turner , Kathleen Moriarty Cc: "" References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> From: Benjamin Kaduk Message-ID: <33a16bc9-6b94-fc03-ec80-7e4c76bd10af@akamai.com> Date: Wed, 31 Jan 2018 10:34:04 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D367C230EE5A74B01416DB5C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310214 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310214 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 16:34:15 -0000 This is a multi-part message in MIME format. --------------D367C230EE5A74B01416DB5C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On the "better late than never" front, I've got some nits: OLD: [...] A Standards Track document [RFC8126 ] is REQUIRED to register an extension with the value "Yes". NEW:       In order to register an extension with the value "Yes", a Standards Track       document [RFC8126] is REQUIRED. Since not all standards-track documents must register such extensions/cipher suites/etc.  (There are multiple occurrences of this text.) Is the "Exporter Value" table in the document supposed to have a "Recommended" column? Let's also double-check that the "WARNING: Cryptographic algorithms[...]" text does not always say "cipher suites listed here", even when talking about (e.g.) HashAlgorithm and SignatureAlgorithm. (Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".) Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"? OLD: Recommended algorithms regarded as secure for general use at the time of registration, however, cryptographic algorithms and parameters will be broken or weakened over time. NEW: Recommended algorithms are regarded as secure for general use at the time of registration, however, cryptographic algorithms and parameters will be broken or weakened over time. NOTES: Add "are" to improve grammar. -Ben On 01/31/2018 08:35 AM, Sean Turner wrote: > I have one PR that address both the WGLC comments (from mt and ekr): > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 > > If you’ve got other suggested changes let me know and I can submit another PR and do the final merges before you initiate the IETFLC. > > Cheers, > > spt > >> On Jan 30, 2018, at 16:54, Kathleen Moriarty wrote: >> >> Great, thank you very much, Stephen! I'll get it rolling towards >> publication with last call starting soon. I'll do my review in the >> next couple of days. >> >> Best regards, >> Kathleen >> >> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell >> wrote: >>> Hi Kathleen, >>> >>> The WGLC for this has expired. >>> >>> There was only one explicit comment [1] saying to ship it. >>> The WG have chatted about this a bunch of times though so >>> FWIW I think it'd be fair to conclude there's pretty good >>> consensus for this. >>> >>> Cheers, >>> S. >>> >>> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html >>> >>> On 15/01/18 21:34, Stephen Farrell wrote: >>>> Hiya, >>>> >>>> Kathleen's a bit busy at the moment so asked that, as shepherd, >>>> I kick off the WGLC for this one (as the two chairs are authors). >>>> The idea is that I'll summarise the WGLC thread to her and she >>>> can then decide if this is ready to move forward. >>>> >>>> So this starts a 2-week WGLC, ending on January 29th. >>>> >>>> Cheers, >>>> Shepherdy Stephen. >>>> >>>> On 03/01/18 13:57, 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 : IANA Registry Updates for TLS and DTLS >>>>> Authors : Joe Salowey >>>>> Sean Turner >>>>> Filename : draft-ietf-tls-iana-registry-updates-03.txt >>>>> Pages : 16 >>>>> Date : 2018-01-03 >>>>> >>>>> Abstract: >>>>> This document describes a number of changes to (D)TLS IANA registries >>>>> that range from adding notes to the registry all the way to changing >>>>> the registration policy. These changes were mostly motivated by WG >>>>> review of the (D)TLS-related registries undertaken as part of the >>>>> TLS1.3 development process. This document updates many (D)TLS RFCs >>>>> (see updates header). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>>>> >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03 >>>>> >>>>> >>>>> 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 >>>> >>> -- >>> PGP key change time for me. >>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >>> NewWithOld sigs in keyservers. >>> Sorry if that mucks something up;-) >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> 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 --------------D367C230EE5A74B01416DB5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On the "better late than never" front, I've got some nits:

OLD:

       [...] A Standards Track document
      [RFC8126] is REQUIRED to register an extension with the value
      "Yes".
NEW:

      In order to register an extension with the value "Yes", a Standards Track
      document [RFC8126] is REQUIRED.

Since not all standards-track documents must register such extensions/cipher suites/etc.  (There are multiple occurrences of this text.)


Is the "Exporter Value" table in the document supposed to have a "Recommended" column?

Let's also double-check that the "WARNING: Cryptographic algorithms[...]" text does not always say "cipher suites listed here", even when talking about (e.g.) HashAlgorithm and SignatureAlgorithm.

(Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".)

Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"?


OLD:

   Recommended algorithms regarded as secure for general use at the time
   of registration, however, cryptographic algorithms and parameters
   will be broken or weakened over time.

NEW:

   Recommended algorithms are regarded as secure for general use at the time
   of registration, however, cryptographic algorithms and parameters
   will be broken or weakened over time.
NOTES:

Add "are" to improve grammar.


-Ben


On 01/31/2018 08:35 AM, Sean Turner wrote:
I have one PR that address both the WGLC comments (from mt and ekr):
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57

If you’ve got other suggested changes let me know and I can submit another PR and do the final merges before you initiate the IETFLC.

Cheers,

spt


On Jan 30, 2018, at 16:54, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Great, thank you very much, Stephen!  I'll get it rolling towards
publication with last call starting soon.  I'll do my review in the
next couple of days.

Best regards,
Kathleen

On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

Hi Kathleen,

The WGLC for this has expired.

There was only one explicit comment [1] saying to ship it.
The WG have chatted about this a bunch of times though so
FWIW I think it'd be fair to conclude there's pretty good
consensus for this.

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html

On 15/01/18 21:34, Stephen Farrell wrote:

Hiya,

Kathleen's a bit busy at the moment so asked that, as shepherd,
I kick off the WGLC for this one (as the two chairs are authors).
The idea is that I'll summarise the WGLC thread to her and she
can then decide if this is ready to move forward.

So this starts a 2-week WGLC, ending on January 29th.

Cheers,
Shepherdy Stephen.

On 03/01/18 13:57, 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           : IANA Registry Updates for TLS and DTLS
       Authors         : Joe Salowey
                         Sean Turner
    Filename        : draft-ietf-tls-iana-registry-updates-03.txt
    Pages           : 16
    Date            : 2018-01-03

Abstract:
  This document describes a number of changes to (D)TLS IANA registries
  that range from adding notes to the registry all the way to changing
  the registration policy.  These changes were mostly motivated by WG
  review of the (D)TLS-related registries undertaken as part of the
  TLS1.3 development process.  This document updates many (D)TLS RFCs
  (see updates header).


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03
https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-03


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


--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)



-- 

Best regards,
Kathleen

_______________________________________________
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

--------------D367C230EE5A74B01416DB5C-- From nobody Wed Jan 31 09:43:54 2018 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 F1ECD12D964 for ; Wed, 31 Jan 2018 09:43:52 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SboKVohvbXTC for ; Wed, 31 Jan 2018 09:43:50 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 B8F1D126DCA for ; Wed, 31 Jan 2018 09:43:49 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 23so13386313pfp.3 for ; Wed, 31 Jan 2018 09:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=hz5HAUhlgStW2FHs+SveF9hjGqOobp08SNejDAalkPM=; b=G3XntIqHHFWrvy5kfnWZRL5XjVNUjU9jVzlurFtI7eeb6D2VSbUNjr6+DDjvzZ6AJN 698mGp87sGTRPf6Mjdv2HZBLMb/n1z9TFXzxN/dUOy45hlhAl8fD6SLsJgjBEMscRXI7 tYklku36ybO4leS42x47OULTBp5+ut3vJ/vb47LvJlMwji61Zecn/sbDQ3zcnaA5DEfJ LMWp2oj4bQwGapaROa6IEZWTh4HSwR21WA3si3dJO2NoPIqXxqQYkRQPiYcl/PqooTwj bO/R3dp4mOfdIKkfN2nxU1e2DJQQcXj0Wj8fCk4ZahkESZDSr6UG3H41MLZiAO/6rhBL 2vng== 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 :content-transfer-encoding; bh=hz5HAUhlgStW2FHs+SveF9hjGqOobp08SNejDAalkPM=; b=e5cPTEFPX5KYrZ+cINQRcArtbaoTc7FCoIZo1p4HIwUOR+Wd0zWxwZFlZnxrvw7LYD e65bO/Og4dC9H5kYke0KGSxfoUgA0t6aXyIFhgodP0inROWeGWL0c9lvUtdbeLI6Ucjj Fp9I2YB/jvy576yZYgNwlcXoBa81RmBJRLJx18HHm25BzMkGJ9NQB89TMHclrYUZ6kqp 2S2TD2qLizb8cTf2CjYdSwZcWJ5KOzV3XjKUu+VFuUqnKJ4D8YKpN/enUvr/QZi8lvkZ KIwufJGHd5VBNoyoE0zRkgwEXwWT38G0bOeG3ZD2mVSKcheFnQW3IExdxmzl5booTzYc nf9w== X-Gm-Message-State: AKwxytdvKylJKVbb7SrC6ja6TZvyOG7ocwDWgI/XoUX8/rbRq4TZJB3Q nnUggZ5W2R9tz9N/Lm3tDJKTp4chjZE1TTtFzqs= X-Google-Smtp-Source: AH8x2258azlYCpoa3sixs5sjBwAzonRdYIjTv7tm9VEjkeQxEZluwGGMNyQu0sV5AKbrVuOyxLldAStmQty7ntOTjFc= X-Received: by 10.101.96.78 with SMTP id b14mr27659927pgv.339.1517420629144; Wed, 31 Jan 2018 09:43:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Wed, 31 Jan 2018 09:43:08 -0800 (PST) From: Kathleen Moriarty Date: Wed, 31 Jan 2018 12:43:08 -0500 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 17:43:53 -0000 Thanks to the WG, chairs, and Stephen for your work on this draft and Ben for the additional review comments. The following nit and clarification points are in addition to Ben's suggested edits. It looks long, but should result in no or very minor easy changes with text provided. Section 9 - Text nit: Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers blindly implement cipher suites. Therefore, IANA [SHALL add/has added] the following warning to the registry: Perhaps: s/crazy/unexpected and not advised/ Or s/crazy/unexpected and NOT RECOMMENDED/ Sections 8,10, 11, 13, and 15 all update the registration policy on an existing registry. The rules for registration vary slightly and I'd like to confirm that this is what was intended: Sections 8, 10, 11, 13 Designated expert ensures the specification is publicly available. Section 10, 13, 15 Explicitly requires a standards track document. Section 9 doesn't state either that the specification is publicly available or a standards track document is required. Next, I'd like to understand the WG's view on what "specification" suffices for registries that do not require a standards track document. When you dig through 8126, we've had people on the IESG debate what is meant and people on the IESG change over time as do interpretations. Does this mean something as simple as an email to an IETF list that can be referenced and won't be deleted, a draft that is posted and never published, a standard in another standards body, etc.? If you only intend it to mean the last 2, I think you're okay not elaborating further in the draft, but if an email is enough, I think you may need some text. I'd use the phrase from 8126, section 4.6, "informal documentation, e.g. public IETF mailing list". Relevant text from 8126: "The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation." Best regards, Kathleen On Wed, Jan 31, 2018 at 11:34 AM, Benjamin Kaduk wrote: > On the "better late than never" front, I've got some nits: > > OLD: > > [...] A Standards Track document > [RFC8126] is REQUIRED to register an extension with the value > "Yes". > > NEW: > > In order to register an extension with the value "Yes", a Standards > Track > document [RFC8126] is REQUIRED. > > Since not all standards-track documents must register such extensions/cip= her > suites/etc. (There are multiple occurrences of this text.) > > > Is the "Exporter Value" table in the document supposed to have a > "Recommended" column? > > Let's also double-check that the "WARNING: Cryptographic algorithms[...]" > text does not always say "cipher suites listed here", even when talking > about (e.g.) HashAlgorithm and SignatureAlgorithm. > > (Also, we can spell "SignatureAlgorithm" as not-"SignarureAlgorithm".) > > Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"? > > > OLD: > > Recommended algorithms regarded as secure for general use at the time > of registration, however, cryptographic algorithms and parameters > will be broken or weakened over time. > > NEW: > > Recommended algorithms are regarded as secure for general use at the t= ime > of registration, however, cryptographic algorithms and parameters > will be broken or weakened over time. > > NOTES: > > Add "are" to improve grammar. > > > -Ben > > > On 01/31/2018 08:35 AM, Sean Turner wrote: > > I have one PR that address both the WGLC comments (from mt and ekr): > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 > > If you=E2=80=99ve got other suggested changes let me know and I can submi= t another > PR and do the final merges before you initiate the IETFLC. > > Cheers, > > spt > > On Jan 30, 2018, at 16:54, Kathleen Moriarty > wrote: > > Great, thank you very much, Stephen! I'll get it rolling towards > publication with last call starting soon. I'll do my review in the > next couple of days. > > Best regards, > Kathleen > > On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell > wrote: > > Hi Kathleen, > > The WGLC for this has expired. > > There was only one explicit comment [1] saying to ship it. > The WG have chatted about this a bunch of times though so > FWIW I think it'd be fair to conclude there's pretty good > consensus for this. > > Cheers, > S. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html > > On 15/01/18 21:34, Stephen Farrell wrote: > > Hiya, > > Kathleen's a bit busy at the moment so asked that, as shepherd, > I kick off the WGLC for this one (as the two chairs are authors). > The idea is that I'll summarise the WGLC thread to her and she > can then decide if this is ready to move forward. > > So this starts a 2-week WGLC, ending on January 29th. > > Cheers, > Shepherdy Stephen. > > On 03/01/18 13:57, 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 : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-03.txt > Pages : 16 > Date : 2018-01-03 > > Abstract: > This document describes a number of changes to (D)TLS IANA registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-update= s-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-= 03 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > > > -- > > Best regards, > Kathleen > > _______________________________________________ > 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 > > --=20 Best regards, Kathleen From nobody Wed Jan 31 11:47:01 2018 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 5DE4E12F2AF for ; Wed, 31 Jan 2018 11:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OjtvO3fi0ceP for ; Wed, 31 Jan 2018 11:46:57 -0800 (PST) Received: from esa3.dyson.c3s2.iphmx.com (esa3.dyson.c3s2.iphmx.com [68.232.139.42]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BF412ECC5 for ; Wed, 31 Jan 2018 11:46:56 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8791"; a="28121600" X-IronPort-AV: E=Sophos; i="5.46,441,1511827200"; d="scan'208,217"; a="28121600" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa3.dyson.c3s2.iphmx.com with ESMTP; 31 Jan 2018 20:01:37 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id EB81DFA10 for ; Wed, 31 Jan 2018 18:19:04 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id D4A7AFA02 for ; Wed, 31 Jan 2018 18:19:04 +0000 (GMT) Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-01.dyson.global.corp ([fe80::ac29:a07c:fbf9:9f84%15]) with mapi id 14.03.0319.002; Wed, 31 Jan 2018 19:46:54 +0000 From: Tony Putman To: "tls@ietf.org" Thread-Topic: New I-D draft-putman-tls13-preshared-dh-00.txt Thread-Index: AdOaxypYeUAlD3H0SDSnRvCYy/jNhA== Date: Wed, 31 Jan 2018 19:46:54 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC10B5AA3C@UK-MAL-MBOX-01.dyson.global.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC10B5AA3CUKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: [TLS] New I-D draft-putman-tls13-preshared-dh-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 19:47:00 -0000 --_000_140080C241BAA1419B58F093108F9EDC10B5AA3CUKMALMBOX01dyso_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I got little interest in my previous draft on using triple-DH authenticated= key agreement for TLS 1.2. In case the reason was that everyone is focusse= d on TLS 1.3, I have now produced a new I-D which specifies how this same m= ethod would work for TLS 1.3. It is published at https://www.ietf.org/inter= net-drafts/draft-putman-tls13-preshared-dh-00.txt. As part of this update, I have introduced support for anonymous clients and= I have shown how this would support 0-RTT. The primary purpose of this method (for me) is to support TLS on constraine= d devices. However, the fact that it supports 0-RTT may make it of interest= to the wider TLS community. The combination of anonymous clients and 0-RTT= means that if a client is able to discover a server public key (e.g. throu= gh DNSSEC) then it is immediately able to send 0-RTT data without having ha= d a previous session (i.e. without a session resumption ticket). The draft contains a table comparing triple-DH with other authentication me= thods. The comparisons are: Versus PSK (excluding session resumption): Advantages: A server breach does not permit client impersonation; hardware = protection for the server key is possible; the client identity is confident= ial. Disadvantages: Public-key computation(s) are needed. Versus Raw Keys: Advantages: Supports 0-RTT messages; only one public-key algorithm is used;= the handshake message exchange is shorter. Disadvantages: The keypair needed is different to that needed for PKI (disa= dvantage only if the server supports both). Versus Certificate Authentication: Advantages: Supports 0-RTT messages; only one public-key algorithm is used;= no certificate parsing is needed; the handshake message exchange is much s= horter. Disadvantages: Out-of-band public key distribution is needed (e.g. pre-prov= isioning, DNSSEC). Comments welcome. Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK. This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training. --_000_140080C241BAA1419B58F093108F9EDC10B5AA3CUKMALMBOX01dyso_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

 

I got little interest in my previous draft on using = triple-DH authenticated key agreement for TLS 1.2. In case the reason was t= hat everyone is focussed on TLS 1.3, I have now produced a new I-D which sp= ecifies how this same method would work for TLS 1.3. It is published at https://www.ietf.org/internet-drafts/draft-putman-tls13-preshared-dh-00.txt= .

 

As part of this update, I have introduced support fo= r anonymous clients and I have shown how this would support 0-RTT.

 

The primary purpose of this method (for me) is to su= pport TLS on constrained devices. However, the fact that it supports 0-RTT = may make it of interest to the wider TLS community. The combination of anon= ymous clients and 0-RTT means that if a client is able to discover a server public key (e.g. through DNSSEC) = then it is immediately able to send 0-RTT data without having had a previou= s session (i.e. without a session resumption ticket).

 

The draft contains a table comparing triple-DH with = other authentication methods. The comparisons are:

 

Versus PSK (excluding session resumption):

Advantages: A server breach does not permit client i= mpersonation; hardware protection for the server key is possible; the clien= t identity is confidential.

Disadvantages: Public-key computation(s) are needed.=

 

Versus Raw Keys:

Advantages: Supports 0-RTT messages; only one public= -key algorithm is used; the handshake message exchange is shorter.

Disadvantages: The keypair needed is different to th= at needed for PKI (disadvantage only if the server supports both).

 

Versus Certificate Authentication:

Advantages: Supports 0-RTT messages; only one public= -key algorithm is used; no certificate parsing is needed; the handshake mes= sage exchange is much shorter.

Disadvantages: Out-of-band public key distribution i= s needed (e.g. pre-provisioning, DNSSEC).

 

Comments welcome.

 

Tony

 


Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury= , SN16 0RP, UK.
This message is intended solely for the addressee and may contain confident= ial information. If you have received this message in error, please immedia= tely and permanently delete it, and do not use, copy or disclose the inform= ation contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & trainin= g. --_000_140080C241BAA1419B58F093108F9EDC10B5AA3CUKMALMBOX01dyso_-- From nobody Wed Jan 31 13:41:46 2018 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 1D75D12ECB9 for ; Wed, 31 Jan 2018 13:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EGTrZgU2pJeB for ; Wed, 31 Jan 2018 13:41:43 -0800 (PST) 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 113F012FAAD for ; Wed, 31 Jan 2018 13:41:42 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0VLfeQt004063; Wed, 31 Jan 2018 21:41:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=9kBzCjCakZUWRRx5l3aszfWaHjMMvrBABNDCXWXcchk=; b=YZNLPkB8L09fpd4l/t1AhQT3hbCCMOhj58gXtA/buy2TktzO138BstPRritLo6WecA1s uqfW8/Ie2mlLRQxivprK0F/iMxwB9MAMQqknGZs0ix+WcZxqjZmRWyxOflJELxUduBsl 7DNHhEpYKSGvMxnHvbULdWuQpZ4UgQhfEaKgr1YPVd84LtCVR3qMMUwolFIsUEeFydW4 6OPw+3HEXIWeUido2vMm5TDZ25cM3hv2PQhyR7aKfH9fNO75XZgnKDFXon7g75GeoR8r XhO2PRX7ycNbzPQg2+EOx6/CLPpC0I9k/clz7UVj1bwUA4tJmtGQb5A5IqYGeVhEcoWf tQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2funqe818e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2018 21:41:38 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0VLf05e007655; Wed, 31 Jan 2018 16:41:35 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2frnmyqpkb-1; Wed, 31 Jan 2018 16:41:35 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DC0DF2714F; Wed, 31 Jan 2018 21:41:34 +0000 (GMT) To: Victor Vasiliev Cc: "tls@ietf.org" References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> From: Benjamin Kaduk Message-ID: <9126f0e6-e135-5421-f9b9-1ff880fd19e8@akamai.com> Date: Wed, 31 Jan 2018 15:41:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5A9359ADE016D2EF3BB2393B" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_10:, , 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=897 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310271 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=878 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801310271 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:41:45 -0000 This is a multi-part message in MIME format. --------------5A9359ADE016D2EF3BB2393B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 01/30/2018 04:02 PM, Victor Vasiliev wrote: > On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk > wrote: > > The new note about "no ServerHello extension to echo back" makes me > wonder if (not) echoing back in Certificate should also be mentioned, > since the TLS 1.3 paradigm is that CertificateRequest extensions are > also "requests" that can get "responses" in the Certificate message. > > > True, though I guess this depends on your definition of "response"? >   I'm thinking of the text in section 4.2: Extensions are generally structured in a request/response fashion, though some extensions are just indications with no corresponding response. The client sends its extension requests in the ClientHello message and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate messages. The server sends extension requests in the CertificateRequest message which a client MAY respond to with a Certificate message. The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these. Implementations MUST NOT send extension responses if the remote endpoint did not send the corresponding extension requests, with the exception of the "cookie" extension in HelloRetryRequest. Upon receiving such an extension, an endpoint MUST abort the handshake with an "unsupported_extension" alert. -Ben > I also wondered whether there was any sense in reserving codepoint > 0 (of > CertificateCompressionAlgorithm) for "uncompressed".  I guess not, > since > support for uncompressed certificates is implicit by means of not > using > the extension.  But sometimes keeping value 0 (basically) reserved is > still useful. > > > I've considered that, but decided that this would just introduce two > ways to do > the same thing (send certificate uncompressed), so I decided against it. Sure.  I don't see a reason to add a code point for uncompressed, but maybe there is an aesthetic argument for leaving 0 reserved entirely.  But I definitely do not insist on anything. --------------5A9359ADE016D2EF3BB2393B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
The new note about "no ServerHello extension to echo back" makes me
wonder if (not) echoing back in Certificate should also be mentioned,
since the TLS 1.3 paradigm is that CertificateRequest extensions are
also "requests" that can get "responses" in the Certificate message.

True, though I guess this depends on your definition of "response"?
 

I'm thinking of the text in section 4.2:

   Extensions are generally structured in a request/response fashion,
   though some extensions are just indications with no corresponding
   response.  The client sends its extension requests in the ClientHello
   message and the server sends its extension responses in the
   ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate
   messages.  The server sends extension requests in the
   CertificateRequest message which a client MAY respond to with a
   Certificate message.  The server MAY also send unsolicited extensions
   in the NewSessionTicket, though the client does not respond directly
   to these.

   Implementations MUST NOT send extension responses if the remote
   endpoint did not send the corresponding extension requests, with the
   exception of the "cookie" extension in HelloRetryRequest.  Upon
   receiving such an extension, an endpoint MUST abort the handshake
   with an "unsupported_extension" alert.

-Ben

I also wondered whether there was any sense in reserving codepoint 0 (of
CertificateCompressionAlgorithm) for "uncompressed".  I guess not, since
support for uncompressed certificates is implicit by means of not using
the extension.  But sometimes keeping value 0 (basically) reserved is
still useful.

I've considered that, but decided that this would just introduce two ways to do
the same thing (send certificate uncompressed), so I decided against it.

Sure.  I don't see a reason to add a code point for uncompressed, but maybe there is an aesthetic argument for leaving 0 reserved entirely.  But I definitely do not insist on anything.
--------------5A9359ADE016D2EF3BB2393B-- From nobody Wed Jan 31 16:23:47 2018 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 16859130EF3 for ; Wed, 31 Jan 2018 16:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 WpMJrco4yu4w for ; Wed, 31 Jan 2018 16:23:43 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 D189C12EB46 for ; Wed, 31 Jan 2018 16:23:42 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id g14so24322004qti.2 for ; Wed, 31 Jan 2018 16:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TpQhdkT7Nu19Mfe8sRvRppnANLMuFeMszgNdP2tXd/Y=; b=lQSbbXn19XPcbtys0ki7iaQdHaCMCzPP62Wxn1y7Fs5kpyG+GM47L24anpwFDN4oCB 8g82uPV4b+cQakb52WXaNj95g2TdcBkA1sUfkZP6VYk9zVjDXUH1RyBomb31oCjTPRQm i7HVfOLUyfG4St0zO/7Z3zJByC5v9ZP34hEso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TpQhdkT7Nu19Mfe8sRvRppnANLMuFeMszgNdP2tXd/Y=; b=P9ZuRjSMQHM7E/WccQ8fHPtd+6uJ49/lV8TQ3lp1RqeMkjm80jq/XZM2iYMMGDm8KI axWuDJhwZg7HuuDGhOEN9UOuD8CzoJaX47CUK8N01WsJ/hDuphSO+P8fnmYaG6pE1YeV wMnFPJ9YrCkItNDvrkcmah/quBBGv3ONVIlDQn+MrlJqqEPbSmEROQxEELLGw1UdOqzw sEVIRLa7H/9KGgaSuKBgg7Ptr6jPJYntPrriokx+e601ZT+5brlyho4DxZHa2MSp/t1d FII8QyL0qyGgdVChp5KXr9Chu2jsHMCQNBjrZzCXYeBs8lRobM0/i4wBDy9j6kMdZj3q GeBQ== X-Gm-Message-State: AKwxytd/b/mPV0bBrmTfNoMMuWuFfcV2awsg+XwBpn/Cu6P80b6cy7G+ pXItRdf2lesu0abHjO5rXT9ZN8cN14Q= X-Google-Smtp-Source: AH8x226dzLpo9Rx90EzkHjkIXv7GbGRxf4axlsdWUMkhpCk35iA56GQw61lW6MiUwsUiMpci1cz2ww== X-Received: by 10.200.35.113 with SMTP id b46mr53979004qtb.262.1517444621782; Wed, 31 Jan 2018 16:23:41 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id x1sm10956267qkd.77.2018.01.31.16.23.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 16:23:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Wed, 31 Jan 2018 19:23:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <270438B9-496C-4067-9D43-2DB6CB7F08BF@sn3rd.com> References: To: Kathleen Moriarty , "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] AD Review, WAS: Re: WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:23:46 -0000 If anybody has any other views please let us know. > On Jan 31, 2018, at 12:43, Kathleen Moriarty = wrote: >=20 > Thanks to the WG, chairs, and Stephen for your work on this draft and > Ben for the additional review comments. The following nit and > clarification points are in addition to Ben's suggested edits. It > looks long, but should result in no or very minor easy changes with > text provided. >=20 > Section 9 - >=20 > Text nit: > Despite the following behavior being crazy, experience has shown = that > some customers use the IANA registry as checklist against which to > measure an implementation's completeness and some implementers > blindly implement cipher suites. Therefore, IANA [SHALL add/has > added] the following warning to the registry: > Perhaps: s/crazy/unexpected and not advised/ > Or s/crazy/unexpected and NOT RECOMMENDED/ mt had the same reaction so put the following in the PR that addresses = WGLC comments: r/crazy/misguided I wanted to avoid the 2119-language. > Sections 8,10, 11, 13, and 15 all update the registration policy on an > existing registry. The rules for registration vary slightly and I'd > like to confirm that this is what was intended: >=20 > Sections 8, 10, 11, 13 > Designated expert ensures the specification is publicly available. >=20 > Section 10, 13, 15 > Explicitly requires a standards track document. s8 (TLS ExtensionType Values) we changed to spec required. s10 (TLS Supported Groups) was changed to spec required by = draft-ietf-tls-rfc4492bis. draft-ietf-tls-rfc4492bis was really about = moving EC cipher suites from informational track to stds track; that = draft is sitting the RFC editor=E2=80=99s queue. The blurb in this = draft about stds track is just about how the initial values for the = Recommended column got populated. s11 (TLS ClientCertificateType Identifiers) we changed to spec required. s13 (TLS Exporter Label Registry) we didn=E2=80=99t change the rules we = just added a Recommended column. The blurb in this draft about stds = track is just about how the initial values for the Recommended column = got populated. s15 (TLS Certificate Types) we changed to spec required. > Section 9 doesn't state either that the specification is publicly > available or a standards track document is required. s9 (TLS Cipher Suite Registry) was changed to spec required (and some = for private use) and there=E2=80=99s a note at the end that section that = adds: The designated expert [RFC8126] only ensures that the specification is publicly available. > Next, I'd like to understand the WG's view on what "specification" > suffices for registries that do not require a standards track > document. When you dig through 8126, we've had people on the IESG > debate what is meant and people on the IESG change over time as do > interpretations. Does this mean something as simple as an email to an > IETF list that can be referenced and won't be deleted, a draft that is > posted and never published, a standard in another standards body, > etc.? If you only intend it to mean the last 2, I think you're okay > not elaborating further in the draft, but if an email is enough, I > think you may need some text. I'd use the phrase from 8126, section > 4.6, "informal documentation, e.g. public IETF mailing list". >=20 > Relevant text from 8126: >=20 > "The intention behind "permanent and readily available" is that a > document can reasonably be expected to be findable and retrievable > long after IANA assignment of the requested value. Publication of = an > RFC is an ideal means of achieving this requirement, but > Specification Required is intended to also cover the case of a > document published outside of the RFC path, including informal > documentation.=E2=80=9D The discussions I remember were about the latter two/three: a draft that = is posted and never published or a standard in another standards = body/industry consortium/university site/etc. spt > Best regards, > Kathleen >=20 > On Wed, Jan 31, 2018 at 11:34 AM, Benjamin Kaduk = wrote: >> On the "better late than never" front, I've got some nits: >>=20 >> OLD: >>=20 >> [...] A Standards Track document >> [RFC8126] is REQUIRED to register an extension with the value >> "Yes". >>=20 >> NEW: >>=20 >> In order to register an extension with the value "Yes", a = Standards >> Track >> document [RFC8126] is REQUIRED. >>=20 >> Since not all standards-track documents must register such = extensions/cipher >> suites/etc. (There are multiple occurrences of this text.) >>=20 >>=20 >> Is the "Exporter Value" table in the document supposed to have a >> "Recommended" column? >>=20 >> Let's also double-check that the "WARNING: Cryptographic = algorithms[...]" >> text does not always say "cipher suites listed here", even when = talking >> about (e.g.) HashAlgorithm and SignatureAlgorithm. >>=20 >> (Also, we can spell "SignatureAlgorithm" as = not-"SignarureAlgorithm".) >>=20 >> Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org"? >>=20 >>=20 >> OLD: >>=20 >> Recommended algorithms regarded as secure for general use at the = time >> of registration, however, cryptographic algorithms and parameters >> will be broken or weakened over time. >>=20 >> NEW: >>=20 >> Recommended algorithms are regarded as secure for general use at = the time >> of registration, however, cryptographic algorithms and parameters >> will be broken or weakened over time. >>=20 >> NOTES: >>=20 >> Add "are" to improve grammar. >>=20 >>=20 >> -Ben >>=20 >>=20 >> On 01/31/2018 08:35 AM, Sean Turner wrote: >>=20 >> I have one PR that address both the WGLC comments (from mt and ekr): >> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 >>=20 >> If you=E2=80=99ve got other suggested changes let me know and I can = submit another >> PR and do the final merges before you initiate the IETFLC. >>=20 >> Cheers, >>=20 >> spt >>=20 >> On Jan 30, 2018, at 16:54, Kathleen Moriarty >> wrote: >>=20 >> Great, thank you very much, Stephen! I'll get it rolling towards >> publication with last call starting soon. I'll do my review in the >> next couple of days. >>=20 >> Best regards, >> Kathleen >>=20 >> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell >> wrote: >>=20 >> Hi Kathleen, >>=20 >> The WGLC for this has expired. >>=20 >> There was only one explicit comment [1] saying to ship it. >> The WG have chatted about this a bunch of times though so >> FWIW I think it'd be fair to conclude there's pretty good >> consensus for this. >>=20 >> Cheers, >> S. >>=20 >> [1] https://www.ietf.org/mail-archive/web/tls/current/msg25279.html >>=20 >> On 15/01/18 21:34, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> Kathleen's a bit busy at the moment so asked that, as shepherd, >> I kick off the WGLC for this one (as the two chairs are authors). >> The idea is that I'll summarise the WGLC thread to her and she >> can then decide if this is ready to move forward. >>=20 >> So this starts a 2-week WGLC, ending on January 29th. >>=20 >> Cheers, >> Shepherdy Stephen. >>=20 >> On 03/01/18 13:57, internet-drafts@ietf.org wrote: >>=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 : IANA Registry Updates for TLS and DTLS >> Authors : Joe Salowey >> Sean Turner >> Filename : draft-ietf-tls-iana-registry-updates-03.txt >> Pages : 16 >> Date : 2018-01-03 >>=20 >> Abstract: >> This document describes a number of changes to (D)TLS IANA = registries >> that range from adding notes to the registry all the way to changing >> the registration policy. These changes were mostly motivated by WG >> review of the (D)TLS-related registries undertaken as part of the >> TLS1.3 development process. This document updates many (D)TLS RFCs >> (see updates header). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -03 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 3 >>=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 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >> -- >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >>=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 >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Wed Jan 31 16:53:54 2018 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 EB36A12FA89 for ; Wed, 31 Jan 2018 16:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 tQFhrXeUhdK0 for ; Wed, 31 Jan 2018 16:53:46 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 CCA2E13144A for ; Wed, 31 Jan 2018 16:53:45 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id t134so17306257qke.5 for ; Wed, 31 Jan 2018 16:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oj7e/re+6Edy6xFuuL7aVGVvxtTihm97nRbLY5zfnOg=; b=dQ8w5flauopPOWnmEsrNOddrcBCoLflJfYJL0Vw1n1E2Cdn5sqNpHu5qVdJNSmLGKg J+90j+139hjoSNRYdJm8KiVjdOKoO+16AL94UUf06JWsTr9K41OHPJcLeN3cA4LAYTOt Eec8rnMx0yriGABvZLyDJCk6CB0y+XSdwYKyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oj7e/re+6Edy6xFuuL7aVGVvxtTihm97nRbLY5zfnOg=; b=lPSJmKpM3MXmzO7BFmr8oK8SGX7M6EVvB3SwJa9ygrVa6Zhu/Sh1bIK5ospOXTXfJG Y+J4tccn0bMnb32F7uAUI/KwFe8K+N6DDPE/aYzNN11KkbHvmchNEuXFP8JsCpNDuz9K cLtuTOf8OBBZDzkM/5J/plVL9uWa9/Vu0aAvMyJ5bKQwUNr/Ep+YqrP/cV7jRGga17fg PYDOBCIlGWD8d2pnM8PQ4KonMoR5BeUVTNluvTC6DaHmc03HdhfgBI2LFyiRlwFptysi Cl5JKdiLyJb48XPdN7FGPnXQn+BaVDemoKCDo660w6sHLkte/s7oqsrH56HZt1uBz4PD szUg== X-Gm-Message-State: AKwxytcMNUGq/gsiH1msyatgMDJnxs1ChjoBlnq7NFTEVnJKGKBG4sXp snPrrUts6xi3Pi5RarUYhWJuqQ== X-Google-Smtp-Source: AH8x225prv6YUNP25QCTND/WdlWjV/cVPl+5f9uZ2tCi4PC0WAyqR0YTX+Rk16u+EGqTgQKiXX8Vog== X-Received: by 10.55.53.134 with SMTP id c128mr13489000qka.279.1517446424820; Wed, 31 Jan 2018 16:53:44 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id n20sm14492440qtb.28.2018.01.31.16.53.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 16:53:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <33a16bc9-6b94-fc03-ec80-7e4c76bd10af@akamai.com> Date: Wed, 31 Jan 2018 19:53:42 -0500 Cc: Kathleen Moriarty , "" Content-Transfer-Encoding: quoted-printable Message-Id: <9314821F-2439-437A-92BC-62A996F84BF4@sn3rd.com> References: <151498784861.30913.14397405953795919592@ietfa.amsl.com> <579c9dbe-39d9-a5de-d172-cd72aea36fd9@cs.tcd.ie> <308c9490-d72b-b5cb-3915-dee6657fb91b@cs.tcd.ie> <33a16bc9-6b94-fc03-ec80-7e4c76bd10af@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-iana-registry-updates-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:53:49 -0000 > On Jan 31, 2018, at 11:34, Benjamin Kaduk wrote: >=20 > On the "better late than never" front, I've got some nits: >=20 > OLD: >=20 > [...] A Standards Track document > [ > RFC8126 > ] is REQUIRED to register an extension with the value > "Yes". >=20 > NEW: >=20 > In order to register an extension with the value "Yes", a = Standards Track > document [RFC8126] is REQUIRED. >=20 > Since not all standards-track documents must register such = extensions/cipher suites/etc. (There are multiple occurrences of this = text.) Fixed (I think) 4x in the following PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/58 > Is the "Exporter Value" table in the document supposed to have a = "Recommended" column? Yeah we should add one ;). Address in the PR. > Let's also double-check that the "WARNING: Cryptographic = algorithms[...]" text does not always say "cipher suites listed here", = even when talking about (e.g.) HashAlgorithm and SignatureAlgorithm. >=20 > (Also, we can spell "SignatureAlgorithm" as = not-"SignarureAlgorithm=E2=80=9D.) Fix in the PR. > Maybe capitalize "TBD" in "tbd but maybe tls-reg-review@ietf.org=E2=80=9D= ? Because the list has actually been created I put the email address in = the draft (in the PR). > OLD: >=20 > Recommended algorithms regarded as secure for general use at the = time > of registration, however, cryptographic algorithms and parameters > will be broken or weakened over time. >=20 > NEW: >=20 > Recommended algorithms are regarded as secure for general use at = the time > of registration, however, cryptographic algorithms and parameters > will be broken or weakened over time. >=20 > NOTES: >=20 > Add "are" to improve grammar. Included in PR. spt > -Ben >=20 >=20 > On 01/31/2018 08:35 AM, Sean Turner wrote: >> I have one PR that address both the WGLC comments (from mt and ekr): >>=20 >> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/57 >>=20 >>=20 >> If you=E2=80=99ve got other suggested changes let me know and I can = submit another PR and do the final merges before you initiate the = IETFLC. >>=20 >> Cheers, >>=20 >> spt >>=20 >>=20 >>> On Jan 30, 2018, at 16:54, Kathleen Moriarty = >>> wrote: >>>=20 >>> Great, thank you very much, Stephen! I'll get it rolling towards >>> publication with last call starting soon. I'll do my review in the >>> next couple of days. >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> On Tue, Jan 30, 2018 at 4:42 PM, Stephen Farrell >>>=20 >>> >>> wrote: >>>=20 >>>> Hi Kathleen, >>>>=20 >>>> The WGLC for this has expired. >>>>=20 >>>> There was only one explicit comment [1] saying to ship it. >>>> The WG have chatted about this a bunch of times though so >>>> FWIW I think it'd be fair to conclude there's pretty good >>>> consensus for this. >>>>=20 >>>> Cheers, >>>> S. >>>>=20 >>>> [1]=20 >>>> https://www.ietf.org/mail-archive/web/tls/current/msg25279.html >>>>=20 >>>>=20 >>>> On 15/01/18 21:34, Stephen Farrell wrote: >>>>=20 >>>>> Hiya, >>>>>=20 >>>>> Kathleen's a bit busy at the moment so asked that, as shepherd, >>>>> I kick off the WGLC for this one (as the two chairs are authors). >>>>> The idea is that I'll summarise the WGLC thread to her and she >>>>> can then decide if this is ready to move forward. >>>>>=20 >>>>> So this starts a 2-week WGLC, ending on January 29th. >>>>>=20 >>>>> Cheers, >>>>> Shepherdy Stephen. >>>>>=20 >>>>> On 03/01/18 13:57,=20 >>>>> internet-drafts@ietf.org >>>>> wrote: >>>>>=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 : IANA Registry Updates for TLS and DTLS >>>>>> Authors : Joe Salowey >>>>>> Sean Turner >>>>>> Filename : draft-ietf-tls-iana-registry-updates-03.txt >>>>>> Pages : 16 >>>>>> Date : 2018-01-03 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes a number of changes to (D)TLS IANA = registries >>>>>> that range from adding notes to the registry all the way to = changing >>>>>> the registration policy. These changes were mostly motivated = by WG >>>>>> review of the (D)TLS-related registries undertaken as part of = the >>>>>> TLS1.3 development process. This document updates many (D)TLS = RFCs >>>>>> (see updates header). >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>>=20 >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>>>>>=20 >>>>>>=20 >>>>>> There are also htmlized versions available at: >>>>>>=20 >>>>>> = https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-03 >>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -03 >>>>>>=20 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>>=20 >>>>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 3 >>>>>>=20 >>>>>>=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: >>>>>>=20 >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>>=20 >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list >>>>>=20 >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>=20 >>>>>=20 >>>>>=20 >>>> -- >>>> PGP key change time for me. >>>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >>>> NewWithOld sigs in keyservers. >>>> Sorry if that mucks something up;-) >>>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> TLS mailing list >>>=20 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >>=20 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20