From nobody Fri Jan 11 04:03:55 2019 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 A8EED12F18C for ; Fri, 11 Jan 2019 04:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=LlVG7yYr; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PVE22WpJ 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 DBFW9XsFXJYk for ; Fri, 11 Jan 2019 04:03:38 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 31F1912E043 for ; Fri, 11 Jan 2019 04:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547208215; x=1549800215; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2gAu5KPXMUgJeZp/oZhijDyIniQMyn0dF3vJJ9IWbJQ=; b=LlVG7yYrEVrdluh/nXlYQdQFeCOunSXcpGLUOkN3XushAkP74jKLlxqcWVmNwBCM vcgFF/0dYyVwJGO2yO+jBLVT2L+dW3PwYGbI4AymtxAuSb+xc1uRb7BLJ37b/t0n pWil3DvqjKdGPW7djhjgNKwXAQW7k2vNQ3221Ql2NaQ=; X-AuditID: c1b4fb25-209009e000005ff7-05-5c388617493b Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 41.F9.24567.716883C5; Fri, 11 Jan 2019 13:03:35 +0100 (CET) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 11 Jan 2019 13:03:34 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 11 Jan 2019 13:03:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2gAu5KPXMUgJeZp/oZhijDyIniQMyn0dF3vJJ9IWbJQ=; b=PVE22WpJIqPEcG9AWg5c1s8ENm3ZjQgVxc2eProU2xpo6TzFKWUYaiBA7RA3wp88xtChCU4VB43mBTlkvjHpJQMzjK0YiMXbfoG6RtY4qr5/ZgWcXIc6wFMbdL7kSBWGz45dj2Sd+WsSXTYRvzrvAveNEY6+r2gEcjTrYJFp27c= Received: from VI1PR07MB4175.eurprd07.prod.outlook.com (20.176.6.24) by VI1PR07MB4894.eurprd07.prod.outlook.com (20.177.200.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.16; Fri, 11 Jan 2019 12:03:33 +0000 Received: from VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::8df6:757e:fa8a:78f8]) by VI1PR07MB4175.eurprd07.prod.outlook.com ([fe80::8df6:757e:fa8a:78f8%4]) with mapi id 15.20.1516.010; Fri, 11 Jan 2019 12:03:33 +0000 From: John Mattsson To: "emu@ietf.org" , "uta@ietf.org" , "tls@ietf.org" Thread-Topic: TLS attacks relevant for EAP-TLS Thread-Index: AQHUqaWsgXVGUZ7xxECwEjEjO4oOxQ== Date: Fri, 11 Jan 2019 12:03:32 +0000 Message-ID: <78409083-A0BF-459D-87B3-4F9E4E3152EC@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB4894; 6:oARDBW0bxLL5CPEXEzifzpC4+7j5Cdgk1zS6kcIvUbyCf1QFPo+K8bYqCbVmSpkAIn/p2YuAs2EM93Ct3VVuuSB4Jqz0bKxJNDuh5C5IbT976gjm/G+ZvbeTpx7kPlm8hapNPxCLaqI8d3wY++o+FvHTKHlrlJtqUzSpPILmvAJJh25KHP26A7Yb+GXiK9Ej1vXkFA+9JJgbiu1Bl8CulnhJoNQgrG2nwFvZfXyQrogmQ7ANo5fhKyxljCSnQUtaIC4Ws10jz2x6DrVgrPHRnMjvbQx+63RUzSeAJNsjbt4XzvXsHnmGH6QIauFKT8tg2QYCel6LYnANS+SAyK93Mbp4TEvSO6bBAEadI55DaaBoFUsKmfS1uxhNA8LWrTXCB47lX0DMyUoDY5q9dQtwedsqwU7BsbUOAnbW/qrerFp0ICtAovJBs3L4RJD/tn3E6PD3nbwi4iNWY0mcKLtZmw==; 5:znqVlLrbiqEzujQoQirIHZ4uZs6Esmr1un0t0Prg5SDC3hZ/mol02WrfGcq1+2sOJTMmuOarCGyl9Rv7l2pYOv/Q6BD07CtJbkVmcaZ9pGBUHvl65T4l3QaJh+BMFcBkb0p0m57xY1ya/E+DjlEgI11CTQHbILKeCn/qbK4gnzMGP6tnL1K+YeEEERF+MwwTWblo8gXcRU1lWQpzsyjqIw==; 7:FSJEW3VkuDWHnl8saAzrkSgfZcnZxVWOw2fFHZz3WnYu4r/C9dZsWIDhTAb6TyoaFj9PMzHv0s/JCtfgk9k8lg8l4CsIrddpNeLH77RmO927Klc2las5Vs2WRwbseCZqwThcTeHHYS3NTvMb1NZKKg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fa9f2d0c-4387-46b6-64f7-08d677bccf06 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4894; x-ms-traffictypediagnostic: VI1PR07MB4894: x-microsoft-antispam-prvs: x-forefront-prvs: 09144DB0F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(376002)(366004)(346002)(199004)(189003)(6486002)(6436002)(102836004)(25786009)(83716004)(71200400001)(71190400001)(106356001)(44832011)(105586002)(8936002)(81166006)(81156014)(966005)(14454004)(8676002)(66066001)(68736007)(6512007)(450100002)(6116002)(2501003)(2201001)(4744005)(256004)(14444005)(5660300001)(99286004)(6506007)(36756003)(53936002)(82746002)(186003)(478600001)(7736002)(305945005)(33656002)(476003)(6306002)(110136005)(486006)(58126008)(86362001)(2906002)(316002)(26005)(2616005)(3846002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4894; H:VI1PR07MB4175.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eT07yWx9+3go6jU8j1K1Z3Ai6glkMT7UI6YD7Qr2t9pEUIKcdLF3b4feUprCnGLZS7iaTaex9Z57EAjhlTv2QcUsNwHN4dTjQnwUdnMBza7YEIvkEeUqirYScYtauRmtvzCRBeNCGt/0Dx3I/S5zrSYzLl7leda4ww/MDsg1BOhSEvNLyOKUXoraH7ksbvOC8OGTDQhog+ECkllp9fQ13zCg/0lod/wmLz4DC1ZTrpO+J5O4U2DpEMzMuHrm8TAkoznMl6zHXdl+0CqMtT+XVBscUBgQBfj5PDDv+iOyc0t4WlxeF9aej8VSmQK6SPU/Gg8glIJFLwV5rE//0GrGDpXm9o6xV6Ol/Grvxz7LsNsyxKyHgZVD2Wm2uMrZklaGFKaILJjFUDd1DojPt3yTFlj5X9lu+3GXmvy1jP9KpXc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <30C6B5D8D9D1454DB5446EDA1D7C995B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa9f2d0c-4387-46b6-64f7-08d677bccf06 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2019 12:03:32.9269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4894 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbG9XFe8zSLGYP0tZYtj69eyWHw638Vo cepoM6MDs8eSJT+ZAhijuGxSUnMyy1KL9O0SuDKutO5mLdjCVbF02RqWBsYJXF2MnBwSAiYS bS+WsIHYQgJHGCWeXOKHsL8xStyYYtbFyAVkL2GSuHngCyOIwyIwgVliwqsLTBCZiUwSrdc6 2CFaHjFKzPgqBWKzCRhIzN3TADZWRCBR4mrTYkYQW1hAU2LZiuWMEHE9ib+rTrPD2N/+3WAF sVkEVCV+nJ4JVsMrYC/RuaKfBcRmFBCT+H5qDROIzSwgLnHryXwmiBcEJJbsOc8MYYtKvHz8 D2yOqIC+xINPB9ghemMlWlunA8U5gGoUJJb8lYQol5W4NL8b7DEJgSZ2iZuLm1ggEroSH6ZO ZYao95WYcjUJouYCo8TZSfvYIGq0JI7eegi1N1ti+vrzUL0yEl2bJjFC2LdYJSZ2MUHCJ1Vi +dpWqLicxKrehywTGPVmIXlnFtA6ZmAQrd+lDxH2kNhx6xULhK0oMaX7IfsscKgISpyc+YRl ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzARHJwy2/VHYyX3zgeYhTgYFTi4bWrsYgR Yk0sK67MPcQowcGsJMJ7Og8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnPePkGCMkEB6Yklqdmpq QWoRTJaJg1OqgdEyvObmlaPR4VKnEy3FHpg8lbP8ofn9O9eMhRxFDX+frJt7ztzCwWaLuZeH fvj+hrg7je6RNjs51VKdrzNr+4uFx0zj+xd8yvjlEQWxmKcSK9MZrJcwdkqeNfjtP7mfZ/EG z3vq+XunP7jakvXweu426W6HD3s+rHK8vkDbbxpz1RSxSS1tX5VYijMSDbWYi4oTATVwhuwg AwAA Archived-At: Subject: [TLS] TLS attacks relevant for EAP-TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 12:03:40 -0000 SGksDQoNClRoZSBkcmFmdCAiVXNpbmcgRUFQLVRMUyB3aXRoIFRMUyAxLjMiIChkcmFmdC1pZXRm LWVtdS1lYXAtdGxzMTMtMDMpIHNwZWNpZmllcyB0aGUgdXNlIG9mIEVBUC1UTFMgd2l0aCBUTFMg MS4zOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lbXUtZWFwLXRs czEzDQpodHRwczovL2dpdGh1Yi5jb20vZW11LXdnL2RyYWZ0LWlldGYtZW11LWVhcC10bHMxMw0K DQpJbiBCYW5na29rIHRoZSBFTVUgV0cgZGVjaWRlZCB0byBhbmFseXNlIGlmIHNvbWUgb2YgdGhl IGtub3duIGF0dGFja3Mgb24gVExTIGhhdmUgcmVsZXZhbmNlIGZvciBFQVAtVExTIGFuZCBpZiBk cmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMgc2hvdWxkIGhhdmUgc29tZSBzaG9ydCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBvbiBob3cgd2hlbiBjb25maWd1cmUgRUFQLVRMUyB0byBtaXRpZ2F0ZSBh dHRhY2tzIHdoZW4gaXQgaXMgdXNlZCB3aXRoIGVhcmxpZXIgdmVyc2lvbnMgb2YgVExTICgxLjAs IDEuMSwgMS4yKS4NCg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IG1vc3Qgb2YgdGhlIGF0dGFj a3Mgb24gVExTIChlLmcuIHRoZSBvbmVzIGxpc3RlZCBpbiBSRkMgNzQ1NykgYXJlIGxlc3Mgc2Vy aW91cyBmb3IgRUFQLVRMUyBhcyBFQVAtVExTIG9ubHkgdXNlcyB0aGUgVExTIGhhbmRzaGFrZSBh bmQgZG9lcyBub3QgcHJvdGVjdCBhbnkgYXBwbGljYXRpb24gZGF0YS4gSSBhbSBjdXJyZW50bHkg cGxhbm5pbmcgdG8gcmVmZXJlbmNlIFJGQyA3NTI1IGFuZCBSRkMgNzQ1Ny4gQXJlIHRoZXJlIGFu eSBvdGhlciBkb2N1bWVudHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8gcmVmZXJlbmNlIGFuZCBhcmUg dGhlcmUgYW55IHNwZWNpZmljIGF0dGFja3MgdGhhdCBzaG91bGQgYmUgaGlnaGxpZ2h0ZWQ/DQoN CkkgYW0gdGhhbmtmdWwgZm9yIGFueSBoZWxwIG9yIGlucHV0Lg0KDQpDaGVlcnMsDQpKb2huDQoN Cg== From nobody Mon Jan 14 13:02:58 2019 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 04157131301; Mon, 14 Jan 2019 13:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ywg9QC2Poa0a; Mon, 14 Jan 2019 13:02:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E44B1312FF; Mon, 14 Jan 2019 13:02:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 831DAB8264B; Mon, 14 Jan 2019 13:02:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tls@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190114210246.831DAB8264B@rfc-editor.org> Date: Mon, 14 Jan 2019 13:02:46 -0800 (PST) Archived-At: Subject: [TLS] =?utf-8?q?RFC_8448_on_Example_Handshake_Traces_for_TLS_1?= =?utf-8?q?=2E3?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 21:02:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8448 Title: Example Handshake Traces for TLS 1.3 Author: M. Thomson Status: Informational Stream: IETF Date: January 2018 Mailbox: martin.thomson@gmail.com Pages: 68 Characters: 159343 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-tls13-vectors-07.txt URL: https://www.rfc-editor.org/info/rfc8448 DOI: 10.17487/RFC8448 This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jan 15 17:13:32 2019 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 A8D12130F80 for ; Tue, 15 Jan 2019 17:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfm6DrqoXP5K for ; Tue, 15 Jan 2019 17:13:29 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4B62912D4EA for ; Tue, 15 Jan 2019 17:13:29 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id r14so5365985qtp.1 for ; Tue, 15 Jan 2019 17:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=gxTv/MUepLGTzEy02QqzNb1dWPG36N0fVN1/pzegk5I=; b=UtKuB4fdPwhHD8TXThmTJRGYWAEmgTnGGuYOBzcZmAGIJ+R99X5jGTawMCirjt97n7 THmLgwdDCI4MXjFkRrMQZQPC5phJgmVvHAc8YIRbMTcDsz3aVWVpv7+O878ECqFX0H1l OFCQrQQl5VES4+XNqPojv1vAtZocwdO7I8qbU= 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=gxTv/MUepLGTzEy02QqzNb1dWPG36N0fVN1/pzegk5I=; b=IxOK+tZafs3MIARIqh+8ZqQc+Uz+255ydPBYixN07B74NIi4FkSsHwtSFdYKSBo4+v 5Mj8DHPUERbSzbjxLUGmBZyHbAKLrAPpBpCUf1WKTHLCD34Nqw+arhMe4QdQ+7a0zh7T puaYpJQl/LchfIQYvFXTBFhZZ9jxdLdIdSMCsqXwBv1NQt7i1N4pZg79TVMpuYDkNKFq a8uUimx/Pd4HfjSWFTrCgbVeqC68gIPJybhp0O0qZ/7Nykn1VgMPzxffDCnNJkGxvXGV 6ipuAdGe5ll8x5d7rg+2Pq2enBLi18ozYz7bxDC9YDvXgtiZ2b2Q5fkVosdGpvGBhZjp YF4w== X-Gm-Message-State: AJcUukciyz8RXDM6cEXXiAZNFIKQ+OmpPOikULAcRH17iTyNOPvR8Dj0 ctXUHtDaLWcQHMeBsTrrdJgUbWbH/Vm4kmWpCl0k11rx4ng= X-Google-Smtp-Source: ALg8bN7YhLMJgNJBwj22vF9rHE1RNicrmLHMZquCq7I28RPD6V38glScp4FNuYI/IWYVKdm3oFjqIcPzuV/EkMH9HdE= X-Received: by 2002:a0c:8936:: with SMTP id 51mr5212621qvp.220.1547601208262; Tue, 15 Jan 2019 17:13:28 -0800 (PST) MIME-Version: 1.0 From: Watson Ladd Date: Tue, 15 Jan 2019 17:13:17 -0800 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 01:13:31 -0000 Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson From nobody Tue Jan 15 18:35:37 2019 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 1C98B13103A for ; Tue, 15 Jan 2019 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=cp/bHGx7; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TuWcDMQV 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 DjVGk5PSKg4Y for ; Tue, 15 Jan 2019 18:35:32 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 3239B131016 for ; Tue, 15 Jan 2019 18:35:32 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0G2UIaF003441; Tue, 15 Jan 2019 18:35:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=t08tGsEYA/6IYaORxajqQ1ADN/2nbbEfxtHFSuOiNkQ=; b=cp/bHGx7yOhFkxgcmMWVPkzaT2RDnSZkhXC/AlW+Uxvp2MUwnFgK5kQYGAMdLgLWhDw2 pPQcxpam1TSbobo/N/7Tsm44TYYVwzwCT4vipUs1eD3lyBuVqkPl72evsLV+dbmsZnlC ZWn2PMYslCK750TVfOQ0YivLj3eSJnVbaT4= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2q1rt60grj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Jan 2019 18:35:29 -0800 Received: from frc-mbx03.TheFacebook.com (2620:10d:c0a1:f82::27) by frc-hub02.TheFacebook.com (2620:10d:c021:18::172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 15 Jan 2019 18:35:22 -0800 Received: from frc-hub05.TheFacebook.com (2620:10d:c021:18::175) by frc-mbx03.TheFacebook.com (2620:10d:c0a1:f82::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 15 Jan 2019 18:35:22 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 15 Jan 2019 18:35:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t08tGsEYA/6IYaORxajqQ1ADN/2nbbEfxtHFSuOiNkQ=; b=TuWcDMQV9VM1oXxRT+2CDflMMSU879OaEhAdukgGEfCQFuMAEPSzdPJMWauu+RVXYanWcB1Hcl1cFuQHY338+qf81MhH5YoOG67qg0WqjchL8ipOsgwtpADmGvkWYvQxbK76qe9AN8B1Y/OrLWDFwhRKoC4zJ5uUMIfHsFvTUeA= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1840.namprd15.prod.outlook.com (10.174.255.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Wed, 16 Jan 2019 02:35:21 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::2dcf:43ad:f1a5:4eca]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::2dcf:43ad:f1a5:4eca%8]) with mapi id 15.20.1537.018; Wed, 16 Jan 2019 02:35:20 +0000 From: Subodh Iyengar To: Watson Ladd , "tls@ietf.org" Thread-Topic: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 Thread-Index: AQHUrTjO5Xfdo/YFZ0WGZmDoo9VjL6WxKkyZ Date: Wed, 16 Jan 2019 02:35:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.216.158.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1840; 20:qcRFMcyGHZ6EUwnfo64Jpb6IgWGElQLHnT5a4KoLzUAuLVmXrT5ZgKB1ihMdNJUiCW0aXAyktvJh8mLFptQs3NlU2Ma2ephKJqtF6StzY05+YoU95RbzNpeDGrn+EDsbBPnDXhhOrIW8tpPVpn64WrvV52iEDqkk0Kjad1lNM4E= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b3e5e38e-dc3e-4e73-d13c-08d67b5b4291 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1840; x-ms-traffictypediagnostic: MWHPR15MB1840: x-microsoft-antispam-prvs: x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(376002)(346002)(396003)(199004)(189003)(54094003)(2906002)(99286004)(2501003)(3846002)(86362001)(71190400001)(71200400001)(8676002)(55016002)(966005)(6246003)(606006)(14454004)(316002)(229853002)(6436002)(97736004)(6606003)(6116002)(74316002)(110136005)(68736007)(102836004)(26005)(256004)(6506007)(53546011)(8936002)(76176011)(81166006)(236005)(9686003)(5660300001)(186003)(25786009)(54896002)(81156014)(33656002)(105586002)(476003)(7696005)(446003)(66066001)(11346002)(486006)(53936002)(7736002)(19627405001)(14444005)(478600001)(106356001)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1840; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rejjvc57ftAvoPOSZAqLleLN+iYRbWvs+bBmwurs1eI6j5mwV94XuzaVxHjsQ4GuS75BCnN/9aVpxFwAUHtkGx0GoR+KN/g+5HvtgQWGfM/Nx+akkJantnfDIj1eq7ISSfzgOlyDLbwGpNFt2Hrp/N55o3H0WquvtdiL+1ZIQppQ7barUIoEZg3U/kdeI0VFkrT1XQj0Yb9wIfOElpTZHQ1VdlXuXPpeNzQqqFfu74wnfvzg5vU8Jwd+I3rolYASgnCKp+ynl+UBKeZPJxAli9Cve1wxctfgY2swESQUDMgMw9n9WREbKhxNryAKxwAImWsc8Rei7zMEpzlHZz2YIopiaEKLagwaGP0gPuE4u6744PfTWHxix1YaxB1HDvvqky0fvaU04/6OS+vbDwquMDMWtDbp5PRPuzxGBtmSciw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821A7E45DDEED81D2018F03B6820MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3e5e38e-dc3e-4e73-d13c-08d67b5b4291 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 02:35:20.7155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1840 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_01:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 02:35:35 -0000 --_000_MWHPR15MB1821A7E45DDEED81D2018F03B6820MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for bringing these up Watson >The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. Usually the negotiation happens during the processing of the client hello. The certificate decision gets made a later. Is there a specific implementat= ion detail you're concerned about. I think the negotiation of TLS version should be done first before deciding= to use DCs, and this needs to be done anyway because DCs are only valid TLS 1.3 an= d higher. The existing set of creds would become invalid with a future version of TLS= . The method by which the TLS terminating server receives the DC is out of sc= ope of this document, however I hope people implement some sort of structure to their b= ackend like DC_objs =3D [ DC_obj1, DC_obj2,. ...] DC_obj =3D { tls_version, private_key, DC structure, .etc.. } which would make it so that they would automatically get new creds when the= y are updated. Also there is the option of falling back to LURK style service if the DC do= esn't exist. I wonder if there is anything I'm missing here. The original rationale around DCs be= ing bound to version was to be able to preventing some attack on the current version of TLS whic= h might expose an oracle to be used against a future version of TLS that might fix it (like D= ROWN). If we think that this is not super useful since we will never have oracle attacks in TLS 1.3, we can remove it= as well. > The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. That would be great. Subodh ________________________________ From: TLS on behalf of Watson Ladd Sent: Tuesday, January 15, 2019 5:13:17 PM To: tls@ietf.org Subject: [TLS] Version pinning and indicating the signing algorithm in draf= t-ietf-tls-subcerts-02 Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DZnSY03FUuGDkpTjaYw9S-739-JBe-iqsIaeiu32GMvU&s=3DsxKHoBLptrk0e_hub5o= KvfRWf1akiS095tuHtXLCZ38&e=3D --_000_MWHPR15MB1821A7E45DDEED81D2018F03B6820MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for bringing these up Wats= on


>The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means = that the rollout of a new
version of TLS (which libraries consider = that they can do on their
own) makes an existing set of delegated c= redentials unusable, and the
signer of delegated credentials needs to = accept a new version of TLS
as valid before the extension can be used= with a new version. This is
similar to the issues prompting draft-wood-tls-external-psk-importer-00 w= here PSKs depend on
negotiated parameters, and thus are diffi= cult to use in practice.


Usually the negotiation happens d= uring the processing of the client hello.

The certificate decision gets mad= e a later. Is there a specific implementation detail

you're concerned about.


I think the negotiation of TLS ve= rsion should be done first before deciding to use

DCs, and this needs to be done an= yway because DCs are only valid TLS 1.3 and higher.


The existing set of creds would b= ecome invalid with a future version of TLS.

The method by which the TLS termi= nating server receives the DC is out of scope of this

document, however I hope people i= mplement some sort of structure to their backend like


= DC_objs =3D [ DC_obj1, DC_obj2,. ...]

DC_obj =3D { tls_version, private= _key, DC structure, .etc.. }


which would make it so that they = would automatically get new creds when they are updated.


Also there is the option of falli= ng back to LURK style service if the DC doesn't exist. I wonder

if there is anything I'm missing = here. The original rationale around DCs being bound to version

was to be able to preventing some= attack on the current version of TLS which might expose an

oracle to be used against a futur= e version of TLS that might fix it (like DROWN). If we think that this is n= ot super

useful since we will never have o= racle attacks in TLS 1.3, we can remove it as well.


> The second is that the Delegate= dCredential indicates the algorithm
that was used to sign it. Someone who is = a bit careless when
implementing might take that literally wi= th the result that they
verify a DelegatedCredential with RSA alg= orithm and the certificate is
really an ECDSA certificate. I'll submit = a PR with text for security
considerations/rewording the verification= steps.


That would be great.


Subodh

From: TLS <tls-bounces@i= etf.org> on behalf of Watson Ladd <watson=3D40cloudflare.com@dmarc.ie= tf.org>
Sent: Tuesday, January 15, 2019 5:13:17 PM
To: tls@ietf.org
Subject: [TLS] Version pinning and indicating the signing algorithm = in draft-ietf-tls-subcerts-02
 
Dear TLS WG,

While we were implementing delegated credentials we came up with the
following two problems. I thank David Benjamin for communicating the
first to me.

The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.

The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.

Sincerely,
Watson

_______________________________________________
TLS mailing list
TLS@ietf.org
https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo= _tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3DZnSY03FUuGDkpTjaYw9S-739-JBe-iqsIaeiu32GMvU&s=3DsxKHoBLp= trk0e_hub5oKvfRWf1akiS095tuHtXLCZ38&e=3D
--_000_MWHPR15MB1821A7E45DDEED81D2018F03B6820MWHPR15MB1821namp_-- From nobody Tue Jan 15 19:39:51 2019 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 2A64F12F1A2 for ; Tue, 15 Jan 2019 19:39:49 -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=lowentropy.net header.b=oOk+q3bG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T/Dp8ZxH 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 6rYke31ngxjy for ; Tue, 15 Jan 2019 19:39:46 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E57012F18C for ; Tue, 15 Jan 2019 19:39:46 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 3DA4A286A7 for ; Tue, 15 Jan 2019 22:39:45 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Tue, 15 Jan 2019 22:39:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:references:in-reply-to; s=fm1; bh=RHv lfLqndXBasiJpN4C/KZk8kEoJ25+HzdyadVqpZnc=; b=oOk+q3bGw1X7k9toPqp ZXSnFUdq76Z/0BDR64Hsl2aeUgXQ/kIBATiP1DoxSI8KKxqyXBDy50mCMKIb4THV afW3IbPQRTk99nxsj8te5mUiqvD1gM0r1tPyk5BECdaRV5JP8YTlpQm4ReFeKVCP 3BFgKmqf8Q0X2ci2SNJxa4PSKIR6KX2zGT+NrA8UGiTxX3VyPDtLZ2PJiDXTVUct 1KDkdSi2FS79/KLz3FeCV5fVey3kyppn4bAm0EvPFEUDJ8gO0KSTdLBNlPL8fYXO Z9AbnUXCTOfwwfuA5GbaPuK5EfunNza4XVgFiJySnPI/maky+dKUp3fK/Mu6Fz4D R2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RHvlfLqndXBasiJpN4C/KZk8kEoJ25+HzdyadVqpZ nc=; b=T/Dp8ZxHMxR4/F545g3PNjInNJ5yOzFSyKo073afeDb8GJtsmXiOGv8wG IZKsyMf6ttIbBfozkQxCalmCIFS1MhVpATrWMNwwNEUjT0fxA3CYc71dnkXhIlM1 WGWHR6zB3dIjG8UbaRDNww8a235CrUsDi5c8IzBg7P7NhX3ctgcp4fyvtUF2iDn8 oaJqxS9eqzVi7k3QBEmfYp3iRLrTSNeOI2IZLvN8CVSYl8oFDmWxJT8GMInSIoet csP4vo203vtY1zhpz4gn42bDF6N90RwvsL0fXfRFvT6d9/L5HDKYrE0+vlc6Nwtz kfTedlvsW0MeUC0oaJRIROwnLx68A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrgeeggdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfouffffhgjsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87288BA783; Tue, 15 Jan 2019 22:39:44 -0500 (EST) Message-Id: <1547609984.2756240.1635793576.0E070413@webmail.messagingengine.com> From: Martin Thomson To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 Date: Wed, 16 Jan 2019 14:39:44 +1100 References: In-Reply-To: Archived-At: Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 03:39:49 -0000 On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote: > Usually the negotiation happens during the processing of the client hello. I don't think that the problem here is a code problem. It's an operational one. In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be made in isolation. You decide to flip the switch and flip it. But if you are doing delegated credentials, deploying a new version depends on having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new credentials. And that assumes that all the necessary stores are keyed correctly (though this highlights the case where that might not happen), and the code has been written. It's not that it's impossible, but more that it complicates what was previously uncomplicated. As you say, the decision to use a delegated credential is fairly simple. From nobody Tue Jan 15 23:54:43 2019 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 5E2FC130DC0 for ; Tue, 15 Jan 2019 23:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, 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=fb.com header.b=ArZacDpH; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NbFRKoEt 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 OpG3ZLilzjP3 for ; Tue, 15 Jan 2019 23:54:40 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 14E87128D0C for ; Tue, 15 Jan 2019 23:54:40 -0800 (PST) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0G7qiW0025989; Tue, 15 Jan 2019 23:54:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=btAQtdFm0CsckYXbKUxOiAZoIvhZO/d2JdzW+Lqoxlw=; b=ArZacDpHyx3uZPtzoeIpMe42AM00btbJjfIMqYIwkqQ5QoLnOsJFlBblpApvL1aGKnvn IKR/Vm/DNHtd7h5UAhs+Ozu98eTytbQKT3DUnTRxxsHYxuzIyzZ0FWheNbPgmFtx3EAi 3+VAZ8oxZNUWi4e7OsQCmyytZdaFkhu9s6A= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2q205vr26f-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Jan 2019 23:54:39 -0800 Received: from frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) by frc-hub03.TheFacebook.com (2620:10d:c021:18::173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 15 Jan 2019 23:54:39 -0800 Received: from frc-hub02.TheFacebook.com (2620:10d:c021:18::172) by frc-mbx06.TheFacebook.com (2620:10d:c0a1:f82::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 15 Jan 2019 23:54:38 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 15 Jan 2019 23:54:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=btAQtdFm0CsckYXbKUxOiAZoIvhZO/d2JdzW+Lqoxlw=; b=NbFRKoEtSJrJ+8wAbQUabrqDpsB3XzuVyrZAgm8z/DhGm+aWJtcNF7hA2b6uNiZHNPQoX7t7P8ddcQiv4ZjAbFgu2QzljmqL6uERaczj66+mZYi7XcMuVPC37Vs8Bp6yHMvNP4JQjfK6l0FgDoCex7VssnQpX68pfR8i2KwzZ40= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1952.namprd15.prod.outlook.com (10.175.8.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Wed, 16 Jan 2019 07:54:37 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::2dcf:43ad:f1a5:4eca]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::2dcf:43ad:f1a5:4eca%8]) with mapi id 15.20.1537.018; Wed, 16 Jan 2019 07:54:37 +0000 From: Subodh Iyengar To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 Thread-Index: AQHUrTjO5Xfdo/YFZ0WGZmDoo9VjL6WxKkyZgAAVfwCAAEa3kA== Date: Wed, 16 Jan 2019 07:54:36 +0000 Message-ID: References: , <1547609984.2756240.1635793576.0E070413@webmail.messagingengine.com> In-Reply-To: <1547609984.2756240.1635793576.0E070413@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::1:1a70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1952; 20:eavgvJSy68FESYQnaYZPf0k1YJoi3UOQCGVYOWZF7lVrhG7MtZFkn7SfaIcmJa4lqjoeVjqEuCdyKUYlgwoXV5OkL1cBnqKvGy3OfxgQ/xVUmUuswdXkZBAaIMqy4D3q+nWgO1YlfCxDsiLfyOC7vqU9aTCfgbztxGuOcc9GEPY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 14f10fc4-6026-4a92-eb7c-08d67b87dc8a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1952; x-ms-traffictypediagnostic: MWHPR15MB1952: x-microsoft-antispam-prvs: x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(346002)(376002)(366004)(189003)(199004)(110136005)(33656002)(966005)(478600001)(316002)(14454004)(186003)(6116002)(6246003)(55016002)(6506007)(5660300001)(7696005)(53546011)(25786009)(76176011)(102836004)(6306002)(46003)(54896002)(9686003)(19627405001)(236005)(53936002)(2501003)(8936002)(74316002)(8676002)(486006)(105586002)(97736004)(256004)(7736002)(606006)(86362001)(6436002)(2906002)(106356001)(99286004)(71200400001)(71190400001)(476003)(229853002)(11346002)(6606003)(81156014)(446003)(81166006)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1952; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YwMD4QIYJ5I59waX0nMuMHHXgUFJYPxnKFc9/Ibj45r1UdvdEp3YiGwP1Bm5k4NaLdBooODMROeQwyIGW3Wzb6TfLM7j26hjA2i+vsojk64dlK0wYHQCubzQcqTunrBJ84X7nBAiQg6gSG+a49z6QqplTCQT+wv/hx4OKmtic0Ik0Vzcfkre+8z97uJMOg2+Mg9rssDkCkb8NMYnf0gF2FKbeRmtInGgTOsYQQFn0NmOEi2wxuPOD0ymqkcdpUuBUEdN/QJOFgOrX4ofyVfxqzOE+fo1hWW8sDyxWjNsZHzmKJEEdWUamqTTCEMOzcRbdIhLQ8ps/4QGjAitmuvrkjAKcRprIcFjxOeW1SE6y6iBWZnGtIrzOOJqvND7U7BaT1rFV9XGdSMOEOQWllzvaDU6oeoBhYEy1lD5DmByR+o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB182109567671DFECA4539372B6820MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 14f10fc4-6026-4a92-eb7c-08d67b87dc8a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 07:54:36.8405 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1952 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_03:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 07:54:43 -0000 --_000_MWHPR15MB182109567671DFECA4539372B6820MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't feel too strongly about the tls version binding and I'd be fine wit= h removing it to favor operational simplification. Subodh ________________________________ From: TLS on behalf of Martin Thomson Sent: Tuesday, January 15, 2019 7:39:44 PM To: tls@ietf.org Subject: Re: [TLS] Version pinning and indicating the signing algorithm in = draft-ietf-tls-subcerts-02 On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote: > Usually the negotiation happens during the processing of the client hello= . I don't think that the problem here is a code problem. It's an operational= one. In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be m= ade in isolation. You decide to flip the switch and flip it. But if you a= re doing delegated credentials, deploying a new version depends on having a= fallback in place for that version, or getting the vendor of delegated cre= dentials to start supplying new credentials. And that assumes that all the= necessary stores are keyed correctly (though this highlights the case wher= e that might not happen), and the code has been written. It's not that it'= s impossible, but more that it complicates what was previously uncomplicate= d. As you say, the decision to use a delegated credential is fairly simple. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DqOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=3DLwnVFi-5giNs_anA6Dy= KhcbiJ5NCSU5T1oZyDjx33Nw&e=3D --_000_MWHPR15MB182109567671DFECA4539372B6820MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don't feel too strongly about t= he tls version binding and I'd be fine with removing it to favor operationa= l simplification.


Subodh

From: TLS <tls-bounces@i= etf.org> on behalf of Martin Thomson <mt@lowentropy.net>
Sent: Tuesday, January 15, 2019 7:39:44 PM
To: tls@ietf.org
Subject: Re: [TLS] Version pinning and indicating the signing algori= thm in draft-ietf-tls-subcerts-02
 
On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wro= te:
> Usually the negotiation happens during the processing of the client he= llo.

I don't think that the problem here is a code problem.  It's an operat= ional one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be m= ade in isolation.  You decide to flip the switch and flip it.  Bu= t if you are doing delegated credentials, deploying a new version depends o= n having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new cred= entials.  And that assumes that all the necessary stores are keyed cor= rectly (though this highlights the case where that might not happen), and t= he code has been written.  It's not that it's impossible, but more that it complicates what was previously uncompli= cated.

As you say, the decision to use a delegated credential is fairly simple.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo= _tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3DqOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=3DLwnVFi-5= giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e=3D
--_000_MWHPR15MB182109567671DFECA4539372B6820MWHPR15MB1821namp_-- From nobody Wed Jan 16 12:25:34 2019 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 A61DB130F50; Wed, 16 Jan 2019 12:25:26 -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.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <154767032661.29586.10643059734542111710@ietfa.amsl.com> Date: Wed, 16 Jan 2019 12:25:26 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 20:25:27 -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 : Applying GREASE to TLS Extensibility Author : David Benjamin Filename : draft-ietf-tls-grease-02.txt Pages : 11 Date : 2019-01-16 Abstract: This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-grease-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-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 Thu Jan 17 02:21:52 2019 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 C71DE130E0A for ; Thu, 17 Jan 2019 02:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZAlSmVVABQdE for ; Thu, 17 Jan 2019 02:21:49 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AA1FE128B14 for ; Thu, 17 Jan 2019 02:21:48 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0BB1A61C839746EC250A for ; Thu, 17 Jan 2019 10:21:47 +0000 (GMT) Received: from SINEML706-CAH.china.huawei.com (10.223.161.56) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 10:21:46 +0000 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.129]) by SINEML706-CAH.china.huawei.com ([10.223.161.56]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 18:21:44 +0800 From: Wang Haiguang To: "tls@ietf.org" Thread-Topic: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated Thread-Index: AdSc+ToMK5SgJR+fTtWsM2NRX2mmLP//3EsA/90z5YA= Date: Thu, 17 Jan 2019 10:21:43 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E25155E@SINEML521-MBX.china.huawei.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E229AD4@SINEML521-MBX.china.huawei.com> <20181226145106.GA6893@LK-Perkele-VII> In-Reply-To: <20181226145106.GA6893@LK-Perkele-VII> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.37.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 10:21:51 -0000 RGVhciBJbGFyaQ0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIA0KDQpXZSBhcmUgbm93IHRy eWluZyB0byBtb3ZlIHRoZSBUTFMtSUJDIHRvIFRMUyAxLjMgYW5kIHdpbGwgdXBsb2FkIGEgbmV3 ZXIgdmVyc2lvbiBzb29uLiAgDQoNCkluIHlvdXIgcHJldmlvdXMgZW1haWwsIHlvdSBzYWlkIHRo YXQgd2l0aCBUTFMgMS4zLCB0aGUgY2xpZW50X2NlcnRpZmljYXRlX3R5cGUgaXMgdW5uZXNzYXJ5 Lg0KSW4gZmFjdCBjbGllbnRfY2VydGlmaWNhdGVfdHlwZSBhbmQgc2VydmVyX2NlcnRpZmljYXRl X3R5cGUgYXJlIGRlZmluZWQgaW4gUkZDIDcyNTAgYW5kIHVzZWQgaW4gY2xpZW50L3NlcnZlciBo ZWxsbyB0byANCmluZGljYXRlIHRoZSBwcmVmZXJlbmNlIG9mIGNsaWVudC9zZXJ2ZXIgb25lIGNl cnRpZmljYXRlLiANCg0KQ2xpZW50L3NlcnZlciBjYW4gdXNlIGl0IHRvIGluZGljYXRlIHdoZXRo ZXIgdGhleSB3YW50IHRvIHVzZSBSYXdQdWJsaWNLZXkgb3IgWC41MDkgaW4gYXV0aGVudGljYXRp b24uIFNvIGlmIHdlIGRvIG5vdCANCnVzZSBjbGllbnRfY2VydGlmaWNhdGVfdHlwZSwgaG93IHRo ZSBjbGllbnQgaW5kaWNhdGUgaXRzIHByZWZlcmVuY2Ugb24gUmF3UHVibGljS2V5LiANCg0KQmVz dCByZWdhcmRzLg0KDQpIYWlndWFuZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogaWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tIFttYWlsdG86aWxhcmlsaXVzdmFhcmFAd2VsaG8u Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMjYsIDIwMTggMTA6NTEgUE0NClRvOiBX YW5nIEhhaWd1YW5nIDx3YW5nLmhhaWd1YW5nLnNoaWVsZGxhYkBodWF3ZWkuY29tPg0KQ2M6IHRs c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIEEgbmV3IGRyYWZ0IGZvciAiVXNpbmcgSWRl bnRpdHkgYXMgUmF3IFB1YmxpYyBLZXkgaW4gVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMp IiBoYXMgYmVlbiB1cGRhdGVkDQoNCk9uIFdlZCwgRGVjIDI2LCAyMDE4IGF0IDA5OjAwOjA4QU0g KzAwMDAsIFdhbmcgSGFpZ3Vhbmcgd3JvdGU6DQo+IEhlbGxvLCBldmVyeW9uZQ0KPiANCj4gV2Ug aGF2ZSBqdXN0IHVwZGF0ZWQgdGhlIGludGVybmV0IGRyYWZ0IGZvciAiVXNpbmcgSWRlbnRpdHkg YXMgUmF3IFB1YmxpYyBLZXkgaW4gVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIi4gDQo+ IA0KPiBJbiB0aGlzIGRyYWZ0LCB3ZSBwcm9wb3NlIHRvIHVzZSB0aGUgSWRlbnRpdHkgYXMgcmF3 IHB1YmxpYyBrZXksIHdoaWNoIGZ1cnRoZXIgc2ltcGxpZmllcyBhdXRoZW50aWNhdGlvbiBhbmQg aWRlbnRpdHkgbWFuYWdlbWVudCBvZiBsYXJnZSBzY2FsZSBJb1QgZGV2aWNlcy4gDQo+IA0KPiBU aGUgdXBkYXRpbmcgYXJlIG1haW5seSBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9uIHBhcnQuIA0K PiANCj4gV2UgaGF2ZSBzb21lIElBTkEgcmVsYXRlZCBpc3N1ZXMgdGhhdCBuZWVkIGV4cGVydCBm cm9tIHRoaXMgZ3JvdXAgdG8gaGVscDoNCj4gMSkgVExTIHByb3RvY29sIHJlcXVpcmUgT0lEIHRv IGlkZW50aWZ5IGFuIHNpZ25hdHVyZSBhbGdvcml0aG0gdXNlZCBpbiBhdXRoZW50aWNhdGlvbiBh bmQga2V5IGV4Y2hhbmdlLiANCj4gICAgICBIb3dldmVyLCB0aGUgaWRlbnRpdHktYmFzZWQgc2ln bmF0dXJlIGFsZ29yaXRobSAoRUNDU0kpIHNwZWNpZmllZCBieSBJRVRGIGluIFJGQyA2NTA3IGRv ZXMgbm90IGhhdmUgYW4gT0lEIHlldC4gDQo+ICAgICAgV2UgaGF2ZSB3cml0dGVuIHRvIElBTkEg Zm9yIGNvbnNpZGVyYXRpb24gYnV0IGRvIG5vdCBnZXQgaXQgeWV0LiANCg0KQWxzbywgSHVhd2Vp IHNlZW1zIHRvIGhhdmUgYW4gT0lEIGFyYy4uLg0KDQo+IDIpIFRMUyBjaXBoZXIgc3VpdGVzIGFu ZCBhICBmZXcgVExTIHJlZ2lzdHJpZXMgbmVlZCB0byBiZSB1cGRhdGVkIGFsc28sIGJ5IGFkZGlu ZyBpbiB0aGUgcmVsYXRpdmUgbmFtZXMgZm9yIEVDQ1NJOiANCj4gICAgICAqIFRMUyAgY2lwaGVy IHN1aXRlcw0KDQpUaGlzIHJlZ2lzdHJ5IHNlZW1zIHRvIGJlIHNwZWNpZmljYXRpb24gcmVxdWly ZWQuDQoNCj4gICAgICAqIFRMUyBUTFMgS2V5RXhjaGFuZ2VBbGdvcml0aG0gUmVnaXN0cnkNCg0K RnJvbSB3aGF0IEkgY2FuIHRlbGwsIHRoZXJlIGlzIG5vIHN1Y2ggcmVnaXN0cnkuIFRoZSBrZXkg ZXhjaGFuZ2UgYWxnb3JpdGhtcyBzZWVtIHRvIGJlIHNwZWNpZmllZCBpbiB0aGUgUkZDcyB0aGVt c2VsdmVzLg0KDQo+ICAgICAgKiBUTFMgQ2xpZW50Q2VydGlmaWNhdGVUeXBlIFJlZ2lzdHJ5DQoN ClNwZWNpZmljYXRpb24gcmVxdWlyZWQgcmFuZ2UgZXhpc3RzLg0KDQo+ICAgICAgKiBUTFMgU2ln bmF0dXJlQWxnb3JpdGhtIFJlZ2lzdHJ5DQoNCk5vdGUgdGhhdCBTaWduYXR1cmVBbGdvcml0aG0g cmVnaXN0cnkgaGFzIGFsbCBlbnRyaWVzIHJlc2VydmVkLCBpdCBkb2VzIG5vdCBoYXZlIHVuYXNz aWduZWQgY29kZXBvaW50cy4gSW5zdGVhZCwgcmVxdWVzdCBTaWduYXR1cmVTY2hlbWUgYXNzaWdu bWVudCwgYW5kIHNwZWNpZnkgaWYgaXQgaXMgdmFsaWQgZm9yIFRMUyAxLjIgb3Igbm90LiBGcm9t IHRoZSBhYm92ZSByZWdpc3RyeSByZXF1ZXN0cywgSSB3b3VsZCBndWVzcyBpdCBpcyBtZWFudCB0 byBiZSB2YWxpZCBpbiBUTFMgMS4yLg0KDQo+IEFsdGhvdWdoIHRoZSBkcmFmdCBpcyBzdGlsbCBw ZXJzb25hbCBkcmFmdCAsIHNvbWUgdGVsZWNvbSBjdXN0b21lciANCj4gd2FudCB0byB1c2UgVExT K0VDQ1NJIGluIHRoZWlyIG5ldHdvcmsgZm9yIElvVCAgZGV2aWNlIGF1dGhlbnRpY2F0aW9uLg0K PiBUaGVyZWZvcmUsIGlzIGl0IHBvc3NpYmxlIGZvciBJQU5BIHRvIGFzc2lnbiB2YWx1ZSBmb3Ig YWJvdmUgVExTIA0KPiByZWdpc3RyaWVzIGFuZCBPSUQgZm9yIEVDQ1NJIHNpbmNlIEVDQ1NJIGlz IHNwZWNpZmllZCBieSBJRVRGPw0KPiANCj4gUGxlYXNlIGdpdmUgdXMgc29tZSBzdWdnZXN0aW9u IG9uIHRoZSBPSUQgYW5kIFRMUyByZWdpc3RyaWVzIHVwZGF0aW5nIGlzc3Vlcy4NCj4NCj4gQmVs b3cgaXMgdGhlIGxpbmsgdG8gb3VyIHJlY2VudGx5IHVwbG9hZGVkIGRyYWZ0LiANCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctdGxzLXJhdy1wdWJsaWMt a2V5LXdpdA0KPiBoLWliYy0wMy50eHQNCj4NCg0KU29tZSBvdGhlciBjb21tZW50czoNCg0KLSBX aHkgaXMgdGhpcyBzZWVtaX5uZ2x5IG9ubHkgc3BlY2lmaWVkIGZvciBUTFMgMS4yPyBJIGFtIG5v dCBzZWVpbmcgYW55DQogIG9ic3RhY2xlcyB0byBwb3J0aW5nIHRoaXMgdG8gVExTIDEuMyBpbiBm YWlybHkgc3RyYWlnaHRmb3J3YXJkDQogIG1hbm5lci4gVGhlIG9ubHkgcHJvYmxlbWF0aWMgYXNw ZWN0cyBJIHNlZSBhcmU6DQogIC0gVXNpbmcgU2lnbmF0dXJlQWxnb3JpdGhtLCBidXQgSSBkbyBu b3QgdGhpbmsgdGhhdCB3b3VsZCB3b3JrIGluDQogICAgVExTIDEuMiBlaXRoZXIgKHVzZSBTaWdu YXR1cmVTY2hlbWUgaW5zdGVhZCkuDQogIC0gVGhlIHdlaXJkIHByZWZlcmVuY2Ugc2lnbmFsaW5n IGZvciBjbGllbnQgc2lnbmF0dXJlIHZpYQ0KICAgIGNpcGhlcnN1aXRlLg0KICBGb3IgVExTIDEu MywgbmV3IGNpcGhlcnN1aXRlcywga2V5IGV4Y2hhbmdlIGFsZ29yaXRobXMgYW5kIGNsaWVudA0K ICBjZXJ0aWZpY2F0ZSB0eXBlcyB3b3VsZCBiZSB1bm5lY3Jlc3NhcnkgKHRoZSBsYXN0IHR3byBk byBub3QgZXZlbg0KICBleGlzdCBpbiBUTFMgMS4zLCB3aXRoIGZpcnN0IHRoZSBzdGFuZGFyZCBh bGdvcml0aG1zIHNob3VsZCB3b3JrKS4NCi0gU2VjdGlvbiAyIHJlZmVyZW5jZXMgUkZDIDIxMTkg YW5kIG5vdCBSRkMgODE3NCAoSSBoYXZlIHNlZW4gY29tcGxhaW50cw0KICBhYm91dCB0aGlzKS4N Ci0gU2VjdGlvbiAyIHNlZW1zIHRvIGJlIG1pc3NpbmcgIk5PVCBSRUNPTU1FTkRFRCIgKG9yIGlm IHRoZSBsaXN0IGlzDQogIHN1cHBvc2VkIHRvIGJlIG1pbmltYWwsICJSRUNPTU1FTkRFRCIgZG9l cyBub3Qgc2VlbSB0byBiZSB1c2VkDQogIGFueXdoZXJlICh0aGlzIGlzIGFjdHVhbGx5IGFuIGVy cmF0YSBvbiBSRkMgMjExOSkuDQotIFNlY3Rpb24gMyBoYXMgIlN1YmplY3RFQ0NTSVB1YmxpY0tl eUluZm8iIGluIGZpZ3VyZSAxIHRpdGxlLiBJDQogIHN1cHBvc2UgdGhhdCBzaG91bGQgYmUgInN1 YmplY3RQdWJsaWNLZXlJbmZvIj8NCi0gU2VjdGlvbiAzIGhhcyBtZWNoYW5pc20gdG8gZmV0Y2gg dGhlIHBhcmFtZXRlcnMgZnJvbSBVUkwuIFRob3NlDQogIHBhcmFtZXRlcnMgc2hvdWxkIGJlIHN0 cm9uZ2x5IGNoZWNrc3VtbWVkIChlLmcuLCBTSEEtMjU2KS4gQWxzbywgdGhlDQogIHJpc2tzIG9m IGZldGNoaW5nIGluZm9ybWF0aW9uIGZyb20gVVJMIGFzIHBhcnQgb2YgaGFuZHNoYWtlIChwcm9i aW5nLA0KICBwb2ludGluZyBhdCBzb21lIGxhcmdlIGZpbGUsIGV0Yy4uLikgc2hvdWxkIGJlIGNv bnNpZGVyZWQuDQotIFNlY3Rpb24gNCByZWZlcmVuY2VzIFJGQyA0NDkyLiBVc2UgUkZDIDg0MjIg aW5zdGVhZC4NCi0gU2VjdGlvbiA0IGRlZmluZXMgQUVTLUNCQyBjaWhwZXJzdWl0ZXMuIE5vIG5l dyBjaXBoZXJzdWl0ZXMgdXNpbmcNCiAgQUVTLUNCQyBhcmUgdG8gYmUgZGVmaW5lZC4gVXNlIEFF Uy1HQ00gYW5kL29yIENoYWNoYTIwLVBvbHkxMzA1DQogIGluc3RlYWQuIFRoZSB1c3VhbCBoYXNo IGFsZ29yaXRobXMgYXJlIFNIQS0zODQgZm9yIEFFUy0yNTYtR0NNIGFuZA0KICBTSEEtMjU2IGZv ciBBRVMtMTI4LUdDTSBhbmQgQ2hhY2hhMjAtUG9seTEzMDUuDQotIFNlY3Rpb24gNSBoYXMgIkFO U0kuMSBzdHJ1Y3R1cmUgZm9yIENlcnRpZmljYXRlUmVxdWVzdCIgSSBwcmVzdW1lDQogIHRoYXQg c2hvdWxkIGJlICJUTFMgMS4yIHN0cnVjdHVyZSBmb3IgQ2VydGlmaWNhdGVSZXF1ZXN0Ii4gDQot IFNlY3Rpb24gNTogU2luY2UgZWNjc2lfc2lnbiBpbiBDbGllbnRDZXJ0aWZpY2F0ZVR5cGUgaXMg YWN0dWFsDQogIGNvZGVwb2ludCwgYnV0IG5vIHZhbHVlIGlzIGtub3duLCBpdCBwcmVzdW1hYmx5 IHNob3VsZCBiZQ0KICAiZWNjc2lfc2lnbihUQkQxKSIuDQotIFNlY3Rpb24gNTogSSBkbyBub3Qg dGhpbmsgU2lnbmF0dXJlQWxnb3JpdGhtIGNhbiBiZSBvYnRhaW5lZC4NCiAgT25lIHNob3VsZCB1 c2UgU2lnbmF0dXJlU2NoZW1lIGluc3RlYWQuIEFuZCBpZiBpdCBpcyBpbmRlZWQNCiAgZml4ZWQg dG8gU0hBLTI1NiwgaXQgc2hvdWxkIGJlIHNwZWNpZmllZCBhcyAiZWNjc2lfc2hhMjU2KFRCRDIp Ig0KICBvciBzb21ldGhpbmcgbGlrZSB0aGF0LiBBbmQgdGhlbiBzcGVjaWZ5IFRMUyAxLjIgdG8g dXNlIHdoYXRldmVyDQogIEhhc2hBbGdvcml0aG0gYW5kIFNpZ25hdHVyZUFsZ29yaXRobSB0aGF0 IFNpZ25hdHVyZVNjaGVtZSBnZXRzIHJlYWQNCiAgYXMpLg0KLSBTZWN0aW9uIDYgaGFzIGV4YW1w bGUgdXJsIG9mICJwa2d4Lm9yZy8xLmh0bWwiLiBJIHByZXN1bWUgdGhhdA0KICBzaG91bGQgYmUg c29tZXRoaW5nIGxpa2UgImh0dHA6Ly9wa2d4LmV4YW1wbGUvMS5wa2ciIG9yIHRoZXJlYWJvdXRz Lg0KLSBTZWN0aW9uIDYuMjogTmVnb3RpYXRhdGluZyBjbGllbnQgcHJlZmVyZW5jZSBmb3Igc2ln bmF0dXJlIHR5cGVzDQogIHVzaW5nIGNpcGhlcnN1aXRlcyBsb29rcyB2ZXJ5IG9kZC4gSWYgc2Vy dmVyIHVzZWQgWC41MDksIGJ1dA0KICBzdXBwb3J0ZWQgYm90aCBFQ0RTQSBhbmQgRUNTU0kgZm9y IGNsaWVudCwgaXQgd291bGQgcGljayBFQ0RTQQ0KICBjaXBoZXJzdWl0ZSBhbmQgaW5jbHVkZSBi b3RoIEVDRFNBIGFuZCBFQ1NTSSBpbiBDZXJ0aWZpY2F0ZVJlcXVlc3QsDQogIGFuZCB0aGVuIHRo ZSBjbGllbnQgd291bGQgcGljay4gQWx0ZXJuYXRpdmVseSB0aGUgc2VydmVyIGNvdWxkDQogIGlu Y2x1ZGUgb25seSBFQ1NTSSBpbiBDZXJ0aWZpY2F0ZVJlcXVlc3QgaWYgaXQgZGVtYW5kZWQgRUNT U0kgZnJvbQ0KICB0aGUgY2xpZW50ICh0aGUgY2lwaGVyc3VpdGUgY291bGQgc3RpbGwgYmUgRUNE U0Egb25lKS4NCi0gU2VjdGlvbiA4IGhhcyBvYnNvbGV0ZSByZWdpc3RyYXRpb24gcG9saWN5IGlu Zm9ybWF0aW9uLiBOb25lIG9mDQogIHRoZSByZWdpc3RlcmllcyBhcmUgInN0YW5kYXJkcyBhY3Rp b24iIGFueW1vcmUsIGFsbCB0aGUgZXhpc3RpbmcNCiAgb25lcyBhcmUgInNwZWNpZmljYXRpb24g cmVxdWlyZWQiLiBPbmUgc2hvdWxkIGFsc28gZHVwbGljYXRlIGFsbA0KICByZXF1ZXN0ZWQgY29k ZXBvaW50cyBpbiB0aGlzIHNlY3Rpb24uDQoNCg0KLUlsYXJpDQo= From nobody Thu Jan 17 03:03:29 2019 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 919F5130DEC for ; Thu, 17 Jan 2019 03:03:27 -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] 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 ReZj5Li7Viyf for ; Thu, 17 Jan 2019 03:03:25 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39212130DD8 for ; Thu, 17 Jan 2019 03:03:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id CAD2345C76; Thu, 17 Jan 2019 13:03:22 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id WbvS9SAIukDa; Thu, 17 Jan 2019 13:03:22 +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 2C69D7A; Thu, 17 Jan 2019 13:03:19 +0200 (EET) Date: Thu, 17 Jan 2019 13:03:19 +0200 From: Ilari Liusvaara To: Wang Haiguang Cc: "tls@ietf.org" Message-ID: <20190117110319.GA23896@LK-Perkele-VII> References: <0AE05CBFB1A6A0468C8581DAE58A31309E229AD4@SINEML521-MBX.china.huawei.com> <20181226145106.GA6893@LK-Perkele-VII> <0AE05CBFB1A6A0468C8581DAE58A31309E25155E@SINEML521-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E25155E@SINEML521-MBX.china.huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 11:03:28 -0000 On Thu, Jan 17, 2019 at 10:21:43AM +0000, Wang Haiguang wrote: > Dear Ilari > > Sorry for the late reply. > > We are now trying to move the TLS-IBC to TLS 1.3 and will upload a newer version soon. > > In your previous email, you said that with TLS 1.3, the client_certificate_type is unnessary. > In fact client_certificate_type and server_certificate_type are defined in RFC 7250 and used in client/server hello to > indicate the preference of client/server one certificate. > > Client/server can use it to indicate whether they want to use RawPublicKey or X.509 in authentication. So if we do not > use client_certificate_type, how the client indicate its preference on RawPublicKey. Ugh, just noticed that the terminology is pretty confusing... There are three similarly named things: - Registry called ClientCertificateType (only used by TLS 1.2, these values go into one field in CertificateRequest message) - extension called client_certificate_type (used by TLS 1.2&1.3) - Registry called certificate types (values used by client_certificate_type come from here). -Ilari From nobody Thu Jan 17 09:05:02 2019 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 3D3FB130E77 for ; Thu, 17 Jan 2019 09:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 bTGB3y-tophY for ; Thu, 17 Jan 2019 09:04:59 -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 526DE130DE4 for ; Thu, 17 Jan 2019 09:04:59 -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 CCB5C3D966; Thu, 17 Jan 2019 17:04:58 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B8EB5DD7B; Thu, 17 Jan 2019 17:04:58 +0000 (UTC) From: Hubert Kario To: tls@ietf.org, David Benjamin Date: Thu, 17 Jan 2019 18:04:57 +0100 Message-ID: <2605372.0b8annkhzO@pintsize.usersys.redhat.com> In-Reply-To: <154767032661.29586.10643059734542111710@ietfa.amsl.com> References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1682802.uODAfzuBr0"; 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]); Thu, 17 Jan 2019 17:04:58 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:05:01 -0000 --nextPart1682802.uODAfzuBr0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 16 January 2019 21:25:26 CET internet-drafts@ietf.org wrote: > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-grease-02 while record_size_limit extension sends just one value, it does specificall= y=20 allow the client to advertise higher values than the protocol versions or=20 extensions would indicate I wonder if sending such values shouldn't be part of GREASE behaviour, even= if=20 it wouldn't use GREASE values... =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 --nextPart1682802.uODAfzuBr0 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+dkqjRuAHS9fUFAlxAtbkACgkQkqjRuAHS 9fUMPQ//VdJYKNs3/RC/5j8YIU/0ts/S4kDHj4w3i+k5z2zJ2SooGdXSgZcJmO/6 O2jpbeczpyEjqdqZ1kPaaZYQsfvkmMPXf7DFKkueVizfLC5BfScVtkBTGJvHZ4SR MGWtTUjAPcvPH0I/8PC9Cj69clcWzNUvXGLJGhxaAJCPJrxchBM25nOTWDafg4cB gJsbndUWkvVf7tz5iQU+osRcnXFQE5i0Rr+Jd95OePQh15fd/74zmtFKZn/kP+xP Z/LvWwjzZo5Tqgn+Cg29O4EOIlxGoUr831WHApeVZIcM6T3ndAXeR6DgjDptY0T9 Z85nN5tkbx4Vvl4fTX9+897NgB3tFocZj3LGn9qEu6vQluoPytZCaJDWh3PH4+FJ wsoM4ckWlZNXsyfkrOJBZ3xPvGAaDFgo6oKUELGu1qEXg5jZCg0rXMD+h1zxJis6 xJ4nyAi47Z+YLlRlQZa5Hb8fsWGsTKnoWNIS8p5hcF9zN3uQioVhYH35sno502Rt EDB/qlhF7wGGoHFE67wdI2YV+Do1WOiNq480bjDLwvPiS90EqZfscvtr/ZKTbsKE lgETZlGDrvw2Ns5olpZDPJ+D/p76eO8z0sqI53VVjw0EVyVddJyRT8VHWVadyHf1 sQNz8jmb6ec61rBC/klq2ZMAPOmdn4TmH1um4OWFR/qVtaTwV6w= =0+PI -----END PGP SIGNATURE----- --nextPart1682802.uODAfzuBr0-- From nobody Thu Jan 17 12:23:53 2019 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 D6DB4130EC1 for ; Thu, 17 Jan 2019 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.052 X-Spam-Level: X-Spam-Status: No, score=-14.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 KwsF1G0qP9Nx for ; Thu, 17 Jan 2019 12:23:49 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6A4128CF2 for ; Thu, 17 Jan 2019 12:23:49 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id p17so12831540qtl.5 for ; Thu, 17 Jan 2019 12:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UKuEgjQcz4HTSSdnINy1YnVflaWlDvz4yMzlqC0Ue94=; b=FIAEua8OQrwPHzdFGedsplls7Xy2EW1cvfGbNWRO5Y9NC0/zXl/Is3fNXW+TF2BSB0 UVtauj4fnSUh6EA4SDI4PBqlX6OtkNTnpdrRj2RkvfvdAfeVvxUndFxhXRkV1tPKpCB/ g+XKZ193NLOVo0Ciat1GX8EsJihCwqn9G10uU= 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=UKuEgjQcz4HTSSdnINy1YnVflaWlDvz4yMzlqC0Ue94=; b=q6v0zvPyk/7nEvQ4wJv1W3m5Ube8eMnoadRrw3khFYjnDpwGfsZIXfSaDuTi/oxHQQ 3d0xEB7Bt7OAJhBc6C72Xc1OhytKDaHFKYhMgEPWxwa7qzDJPkR4y3Oyr3Ov8LfPWuZz Ij0WPOPx6qFrMWBCeThVi/sU3Weg0iCtigCckfHJYhYfnf029dn326fxPVHqd4JMCKCS azJyFQaSXWlxIuzd7eIeBFxDLFmH2zRhHS1t6NtRXbPW6uHMGqkJTICBjotcEtpIwBK8 9VXg4AtaFirBMkmBnV7kC323/72DMY+GgYz4SH+N1X1aYXjGYi5dp9DGRPVAn54GXWoZ azQg== X-Gm-Message-State: AJcUukcFx1z7D0dn+TC/eC/dFPTpxRdkAXMsNTHnWSJPx6wFFsh3s2N/ lg76fTYeXTwCXJyTP06HM6HDr4j15TH5/Rw4v3qo X-Google-Smtp-Source: ALg8bN5uifwhcBKiWDucinCp8aTapxtzCGu6leRiJrY5II8t8B4UAqBXuJ2RgHb+0QnGEpGLeJVBVjTQ/FSffCd+New= X-Received: by 2002:ac8:2fdc:: with SMTP id m28mr13555002qta.202.1547756628328; Thu, 17 Jan 2019 12:23:48 -0800 (PST) MIME-Version: 1.0 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> In-Reply-To: <2605372.0b8annkhzO@pintsize.usersys.redhat.com> From: David Benjamin Date: Thu, 17 Jan 2019 14:23:37 -0600 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000084111057fad2c80" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:23:52 -0000 --000000000000084111057fad2c80 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario wrote: > On Wednesday, 16 January 2019 21:25:26 CET internet-drafts@ietf.org wrote: > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-grease-02 > > while record_size_limit extension sends just one value, it does > specifically > allow the client to advertise higher values than the protocol versions or > extensions would indicate > > I wonder if sending such values shouldn't be part of GREASE behaviour, > even if > it wouldn't use GREASE values... > I think that should be sorted out in a separate document. This one's been sitting around for a while as it is, and record_size_limit doesn't have an RFC to cite yet. :-) David --000000000000084111057fad2c80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario = <hkario@redhat.co= m> wrote:
On Wednesday, 16 J= anuary 2019 21:25:26 CET internet-drafts@ietf.org wrote:
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tl= s-grease-02

while record_size_limit extension sends just one value, it does specificall= y
allow the client to advertise higher values than the protocol versions or <= br> extensions would indicate

I wonder if sending such values shouldn't be part of GREASE behaviour, = even if
it wouldn't use GREASE values...

<= div dir=3D"ltr">
I think that should be sort= ed out in a separate document. This one's been sitting around for a whi= le as it is, and record_size_limit doesn't have an RFC to cite yet. :-)=

David
--000000000000084111057fad2c80-- From nobody Thu Jan 17 12:31:42 2019 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 29CB112958B for ; Thu, 17 Jan 2019 12:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 r7Twa55XQJKo for ; Thu, 17 Jan 2019 12:31:37 -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 C64CC1271FF for ; Thu, 17 Jan 2019 12:31:37 -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 4C6B92498C; Thu, 17 Jan 2019 20:31:37 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id B85F2600C0; Thu, 17 Jan 2019 20:31:36 +0000 (UTC) From: Hubert Kario To: David Benjamin Cc: tls@ietf.org Date: Thu, 17 Jan 2019 21:31:35 +0100 Message-ID: <96738939.LbPAkC2fvU@pintsize.usersys.redhat.com> In-Reply-To: References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart386943394.S8uMhp4YJZ"; 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.28]); Thu, 17 Jan 2019 20:31:37 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:31:40 -0000 --nextPart386943394.S8uMhp4YJZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 17 January 2019 21:23:37 CET David Benjamin wrote: > On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario wrote: > > On Wednesday, 16 January 2019 21:25:26 CET internet-drafts@ietf.org wro= te: > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-tls-grease-02 > >=20 > > while record_size_limit extension sends just one value, it does > > specifically > > allow the client to advertise higher values than the protocol versions = or > > extensions would indicate > >=20 > > I wonder if sending such values shouldn't be part of GREASE behaviour, > > even if > > it wouldn't use GREASE values... >=20 > I think that should be sorted out in a separate document. This one's been > sitting around for a while as it is, and record_size_limit doesn't have an > RFC to cite yet. :-) eee? https://tools.ietf.org/html/rfc8449 =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 --nextPart386943394.S8uMhp4YJZ 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+dkqjRuAHS9fUFAlxA5icACgkQkqjRuAHS 9fVUVA/+JT4qNFsJjcf6U3//klmoy8g2F0hjaGBbTnvF2OSSTNN9WBGHXG2hMEfP zSZ5kTbmYSgnJDbGcDYT8eGuvaZDltqet/Ju46YcZewUdXaKZKUtQX3zTxnDnYdv C2Fabd3/RJZZyj46LdaKtbF0ioFddWA377pta/2N79hPBrwBRmSgZjHqRMbNWfx/ ZQczbXYvFueC/OJBUms6Ib433IVA/XrckOjxhLM/jV3Pz8Bgck/tko3Ckv8ktGzn D6A6sHIIH6X75ubtJXIJ49SOTfG7Q3Bh35fRHcs8gy1z+G4S5hdg4QuzChqmRZ87 IuW1I91CGg8yx53kt/PJFAhVXtTXV/MaBac43yJ9Lr3wzQblYjzJTCHJncVAiqNE Lxdc7kEwThlVLvavtdFc1wz36V5nt++bJtEuyEr5hssueIElI7MVIPlM5h948eaa j6oDCIIyJuD3vTPffaC6EXfWfoa5cLDowrS5joTOpN8iYhs3TkelB636vr56vLi8 EJD5MwEZn6xMoqFybAv35IiXg3OgCKF/K9A29RTWjN/aKuUtv6z7O6fz5dFct5Ex LV3IyXxLqhwC9NysujKUhsbSVzYAo6TBqSk4QytHzp7bQm5Vj6b3rCgFfWYec+Ws OiX/MCExbR9mNXhXAWByzrE47DGIrWWnQSVAnufnua6QqDgVhWU= =WD4/ -----END PGP SIGNATURE----- --nextPart386943394.S8uMhp4YJZ-- From nobody Thu Jan 17 12:38:21 2019 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 D3B79130FBB for ; Thu, 17 Jan 2019 12:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.052 X-Spam-Level: X-Spam-Status: No, score=-14.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 blpr5Vcx5jTj for ; Thu, 17 Jan 2019 12:38:13 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 90162130F3B for ; Thu, 17 Jan 2019 12:38:12 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id r14so12929988qtp.1 for ; Thu, 17 Jan 2019 12:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xvu+ltqRUpQ/rGlWW0S7OWfg3XgSl/VL5nb4cNDFBhI=; b=h2Zg+pvk12kScB6BHPxNEZj/2hHiO/HKtCrf82vNQtT46Xvq7/kbtY8PwgYjIxaKky yMx7S5n0ysP/Ch7nbHkDbZj7/BYEdHC66UNroYRi+5DyRLd38YyuPw/B2y0MUyos0bTl 2UQ3Sf4eNz4DcVdGCCBj8DH0Tf1E06YNSsTGE= 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=Xvu+ltqRUpQ/rGlWW0S7OWfg3XgSl/VL5nb4cNDFBhI=; b=gTjd5ZFhbXQ/HywiMvFryL2azXEu/H1IwLYHpb2jOiY017Tc0bupEV1ZmIziMySL+w 3C/FqPVOcvcG+/VWEXFhP2Ae6n+sVR2Vi17BM1t/mv+rNSRxWoI1AAzLfITmTkg4OuQJ N6gsou2UbNLd+P13vZUJ+bxZJlVyeliBOgF+zZFHoDlbVApGwo/tnZvsPxI27komfDHq 20ZQH3oY18Z1k4A3Rc/lo6Vkw6vCg6SWKPjRaM3CzOCINYe9xufB2AidxyyDUKGLUI9p ey6Q5ZQISDByhS8WOU0vxdXLrtTGp2gA9cv9jPsJ2Zgb8BGzV35bzU7q8zhZBl54m+Ui ghCg== X-Gm-Message-State: AJcUukfrniV13OVsK5GrZ17Ikj5ZylhwpmJILdiTOCpbCDlUTPhgpRG2 lutxoQOCdMD+AJM2bLQq7pIfD8wHtZRugTZ8MuRj X-Google-Smtp-Source: ALg8bN6NYAr6JfC/0Kt1CDhgFSnbUxap9Ab4cbpQA8q6td9LnlTdYF2g4KZj3gZUCGM0KmIvnNN0J7T0hnIFx2me/n0= X-Received: by 2002:a0c:d0d7:: with SMTP id b23mr12643265qvh.67.1547757491654; Thu, 17 Jan 2019 12:38:11 -0800 (PST) MIME-Version: 1.0 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> <96738939.LbPAkC2fvU@pintsize.usersys.redhat.com> In-Reply-To: <96738939.LbPAkC2fvU@pintsize.usersys.redhat.com> From: David Benjamin Date: Thu, 17 Jan 2019 14:38:00 -0600 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000007d8ec5057fad5ffb" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 20:38:20 -0000 --0000000000007d8ec5057fad5ffb Content-Type: text/plain; charset="UTF-8" On Thu, Jan 17, 2019 at 2:31 PM Hubert Kario wrote: > On Thursday, 17 January 2019 21:23:37 CET David Benjamin wrote: > > On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario wrote: > > > On Wednesday, 16 January 2019 21:25:26 CET internet-drafts@ietf.org > wrote: > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-tls-grease-02 > > > > > > while record_size_limit extension sends just one value, it does > > > specifically > > > allow the client to advertise higher values than the protocol versions > or > > > extensions would indicate > > > > > > I wonder if sending such values shouldn't be part of GREASE behaviour, > > > even if > > > it wouldn't use GREASE values... > > > > I think that should be sorted out in a separate document. This one's been > > sitting around for a while as it is, and record_size_limit doesn't have > an > > RFC to cite yet. :-) > > eee? https://tools.ietf.org/html/rfc8449 Oh, huh. It wasn't linked from https://tools.ietf.org/html/draft-ietf-tls-record-limit-03, so I didn't see it. David --0000000000007d8ec5057fad5ffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 17, 2019 at 2:31 PM Hubert Kario &l= t;hkario@redhat.com<= /a>> wrote:
On Thursday, 17 Janu= ary 2019 21:23:37 CET David Benjamin wrote:
> On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 16 January 2019 21:25:26 CET internet-drafts@ietf.org wrote:=
> > > There are also htmlized versions available at:
> > > https://tools.ietf.org/html/draft= -ietf-tls-grease-02
> >
> > while record_size_limit extension sends just one value, it does > > specifically
> > allow the client to advertise higher values than the protocol ver= sions or
> > extensions would indicate
> >
> > I wonder if sending such values shouldn't be part of GREASE b= ehaviour,
> > even if
> > it wouldn't use GREASE values...
>
> I think that should be sorted out in a separate document. This one'= ;s been
> sitting around for a while as it is, and record_size_limit doesn't= have an
> RFC to cite yet. :-)

eee? https://tools.ietf.org/html/rfc8449
Oh, huh. It w= asn't linked from=C2=A0https://tools.ietf.org/html/draft-= ietf-tls-record-limit-03, so I didn't see it.

David
--0000000000007d8ec5057fad5ffb-- From nobody Thu Jan 17 15:39:10 2019 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 564EB130FBE for ; Thu, 17 Jan 2019 15:39:09 -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 H8LuTgqCsCDh for ; Thu, 17 Jan 2019 15:39:08 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 D58D7130FBD for ; Thu, 17 Jan 2019 15:39:07 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id y16so7071424qki.7 for ; Thu, 17 Jan 2019 15:39:07 -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:date:references :to:in-reply-to:message-id; bh=o3zsauSYbaGaxni29ks9TNivSMmSgGND4GO5Hgdh0hI=; b=idUmFgRIMWBsr6+taMpIQ2COI6OgDOuIo6VgP7c4a4U4BOFDpezjZsjE5+WmDTikvY vEgor3NV/sWJwbXMa0EYfoy0WJXzEm5xbs7lf/MBzDi6cgRwEFql/37dV/Y/5ZgceH4v ZXAAbstTSI+oo868MVTBuKJMqfkLs6jiHDoY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=o3zsauSYbaGaxni29ks9TNivSMmSgGND4GO5Hgdh0hI=; b=DIsQaB7U31kATNmV1yaCaGmleUwv99cb1i1v9VaPjeVjdr01RbD/bfxRGG0H/ZikcZ p5zBHUvLwi0U46WsshlIiVBxrjyAFcVegCeZNXlQgZm6JVwPkj5Px1B0VqEL2UPaJgNw YQmnQF0tV7Sk5ra0UeOwFP3OZ87DsSyCCxwLjh4BWgYnH4etvKhyU6m4NwgqpyVtq+8z ktA9AgoqnynmvRkIe2dpaG/QwjLv7tnBOt5QJkmwivrCK5EFkmEyJyaNtM803rYpJ5o3 weQSswbhVa4ZVqBZjbjeSTnTIZoujL7pTVW/B+JHXU2QZ4cq2/dZiUAfo9evSxleS9rR 6qUQ== X-Gm-Message-State: AJcUukcsiT3picTCeYS2vTnAQ7ZpI1fXShm5ihHLLtTDctvGJUihFWgN Q/vwmrtXSj9til4BB0Z7RWJdsYxLIXTKcA== X-Google-Smtp-Source: ALg8bN4mjNsrn83kuv1Jji9tCtWU/eA3WCGKyh1Ds6x5cszUA1DwOEQGGt3iDY/SV2cOOjG/jAT/IA== X-Received: by 2002:a37:7183:: with SMTP id m125mr12475255qkc.195.1547768346891; Thu, 17 Jan 2019 15:39:06 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id r1sm59508504qte.28.2019.01.17.15.39.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Jan 2019 15:39:06 -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 12.2 \(3445.102.3\)) Date: Thu, 17 Jan 2019 18:39:05 -0500 References: <8F19BCF1-992D-4F7A-8E3B-3DFC2036511C@sn3rd.com> To: TLS List In-Reply-To: <8F19BCF1-992D-4F7A-8E3B-3DFC2036511C@sn3rd.com> Message-Id: <58A2754E-545E-4D2F-A6D6-2724672EE8A5@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 23:39:09 -0000 It looks like we have consensus to adopt this draft as a working group = item. Chris, please submit the draft as: = draft-ietf-tls-ticketrequests-00.txt Best, Joe and Sean > On Nov 7, 2018, at 02:47, Sean Turner wrote: >=20 > At TLS@IETF103, there was consensus in the room to adopt = draft-wood-tls-ticketrequests. This message is to confirm that = consensus. If you do not support adoption of = draft-wood-tls-ticketrequests as WG item please say so by 2359UTC on 30 = November 2018 (and say why). >=20 > Thanks, > Joe and Sean From nobody Fri Jan 18 09:57:30 2019 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 4D76B131288 for ; Fri, 18 Jan 2019 09:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 3QpA4u4lQK9Z for ; Fri, 18 Jan 2019 09:57:24 -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 974F1131280 for ; Fri, 18 Jan 2019 09:57:24 -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 2887D8667E for ; Fri, 18 Jan 2019 17:57:24 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id C3F8C2A2BD for ; Fri, 18 Jan 2019 17:57:23 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 18 Jan 2019 18:57:17 +0100 Message-ID: <2601131.Af52qPZ5Q9@pintsize.usersys.redhat.com> In-Reply-To: <20180810235504.856F6B812F4@rfc-editor.org> References: <20180810235504.856F6B812F4@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1827220.sob6s1NPZZ"; 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.26]); Fri, 18 Jan 2019 17:57:24 +0000 (UTC) Archived-At: Subject: Re: [TLS] RFC 8449 on Record Size Limit Extension for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 17:57:28 -0000 --nextPart1827220.sob6s1NPZZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 11 August 2018 01:55:04 CET rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 8449 >=20 > Title: Record Size Limit Extension for TLS > Author: M. Thomson > Status: Standards Track > Stream: IETF > Date: August 2018 > Mailbox: martin.thomson@gmail.com > Pages: 8 > Characters: 18932 > Updates: RFC 6066 >=20 > I-D Tag: draft-ietf-tls-record-limit-03.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8449 >=20 > DOI: 10.17487/RFC8449 test coverage for this extension is in tlsfuzzer test-record-size-limit.py= =20 script, it was added in https://github.com/tomato42/tlsfuzzer/pull/494 =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 --nextPart1827220.sob6s1NPZZ 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+dkqjRuAHS9fUFAlxCE30ACgkQkqjRuAHS 9fVnow//XsN/HHuHJCae+pqF7gGKLaDi2rY7LHZGNiOjIdjuO0ZnmcgcdiqbBrAY 6hOpCQ1RoNp7Fx8EhxEpuvld42/W+K93Bvtwrmj7e+V0qpyUEfGM5MzbJ0w1IwvL d1MpXSf0QqubZeweC0CnCH/H0idVTha8ajBPeO3QhHhYGuZfErRcAfYnWN8sVI8t bP+N1ByXWS2Q7MjzMIAcC6P6ZDzaZ07xg5Kkt/IZSnnOR44PdYlmSLL0Qt7Vfs3H ZwXelj6elI1k/ZFmJavUpV+TcLZeoikG6/WdTQ3G4Uol8H25us5/YEpsYzvOTzNy 05+J5NBdlaFOvJ/JBkOHwoOVoRWUu87ufEejaUTuoYjav0A2H4rJ++k2VPI+JE98 EMYrXULpE8dKXZQUiKRtF1XeIdBUKBexq+xRAx1vchiayx0Fhc7Gxmlcv1AZ8beX KOe8lDvP2ZHhuMoHQ3ieQODuIWKJdkyhHBLac6b4uQZJttjDZSaOK6HBXAoEHmlU igw3RDMyzAVhGd/H7C55YHdjdn8ZqniR/vAy6bxxx9Jzom8V26q/n7YliIzzxUkB oRGWD6PLnc0BQnXL+FUU9grtcYJIirhWcQj7m6zcgz/y1x9LLW1EzrUZuNmm0WvE /uH4EhoEOfbdhHx379E1onr5/bn9Dc9Z/HdCaK//p0MWeQMIGIM= =pQdp -----END PGP SIGNATURE----- --nextPart1827220.sob6s1NPZZ-- From nobody Fri Jan 18 16:32:42 2019 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 AF40F130F8B; Fri, 18 Jan 2019 16:32:35 -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.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <154785795557.17452.3793151756514602603@ietfa.amsl.com> Date: Fri, 18 Jan 2019 16:32:35 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 00:32:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Ticket Requests Authors : Tommy Pauly David Schinazi Christopher A. Wood Filename : draft-ietf-tls-ticketrequests-00.txt Pages : 6 Date : 2019-01-18 Abstract: TLS session tickets enable stateless connection resumption for clients without server-side per-client state. Servers vend session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. Moreover, clients should use tickets at most once for session resumption, especially if such keying material protects early application data. Single-use tickets bound the number of parallel connections a client may initiate by the number of tickets received from a given server. To address this limitation, this document describes a mechanism by which clients may specify the desired number of tickets needed for future connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jan 19 00:02:50 2019 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 B444512EB11 for ; Sat, 19 Jan 2019 00:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8RPQSA1Atl6t for ; Sat, 19 Jan 2019 00:02:48 -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 1026D12958B for ; Sat, 19 Jan 2019 00:02:47 -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 0E57B5F74A for ; Sat, 19 Jan 2019 08:02:47 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-93.ams2.redhat.com [10.36.116.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 315AE600C1 for ; Sat, 19 Jan 2019 08:02:45 +0000 (UTC) Message-ID: <87sgxpcbx8.fsf-dueno@redhat.com> From: Daiki Ueno To: tls@ietf.org Date: Sat, 19 Jan 2019 09:02:43 +0100 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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.39]); Sat, 19 Jan 2019 08:02:47 +0000 (UTC) Archived-At: Subject: [TLS] custom lower limit of record_size_limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2019 08:02:50 -0000 Hello, While RFC 8449 defines the minimum of record_size_limit as 64, if a server takes account of the Security Consideration and chooses its own lower limit (larger than 64), what should it behave? Very small record sizes might generate additional work for senders and receivers, limiting throughput and increasing exposure to denial of service. In the beginning of section 4 (emphasis is my own): When the "record_size_limit" extension is _negotiated_, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. and later in the same section: Endpoints SHOULD advertise the "record_size_limit" extension, even if they have no need to limit the size of records. [...] _For servers, this allows clients to know that their limit will be respected._ My interpretation is that, if the client sent "record_size_limit" but didn't receive the extension from the server, that would mean the extension was not negotiated and the server may not respect the limit. Is this correct, or 64 is really mandatory to implement? Regards, -- Daiki Ueno From nobody Sun Jan 20 21:13:53 2019 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 BD537130E2F for ; Sun, 20 Jan 2019 21:13:51 -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=lowentropy.net header.b=CGSP4Q6Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mvsTTElp 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 hr2YB6-mTxZ1 for ; Sun, 20 Jan 2019 21:13:50 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE23130DE9 for ; Sun, 20 Jan 2019 21:13:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id B005A15FF9 for ; Mon, 21 Jan 2019 00:13:48 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 21 Jan 2019 00:13:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=bHZ rodyRpcX1qxn3EYg8TUh7hF/G9GpucxR4p/+u5Rg=; b=CGSP4Q6YlduBLVhlJ2k 3cddKG+nocOjc4rNKpKcd9i3jq9/8laRlkUxe05oTVQtiLvnuyvUJJD3CEtZZ1pH EzP+iXlH5kxnro2bTDjq0MjbQM3IRWlV06+B33SLCZV5txi2abrgKPtJzwtg+qqy J8I8fnU64ENsAfd9dB/DDKDNnaAQ8HeeiKt6Ax3idmatvyy6kVr2ymz8/je3JVLY JqsL1oQabOXIrUYrQqwJaQoS3tmgqYZN8GNaaWUmkQ2yjQAbTLluxN5OxlwHVUvM z9azkMJ1Rbg92lKTbjrIRxIGODDFZcmWC9/nrO2KEigODOjnBXkG3vIeeFB0ktOo RPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=bHZrodyRpcX1qxn3EYg8TUh7hF/G9GpucxR4p/+u5 Rg=; b=mvsTTElpAv3K54quBrLDm+O+Iof1kbC7S/Z7NfR2fEJB+05fwNzfY8WbD h6likQzeCWO89j6VFt4CFS5KDyLSRbEWn4nUbKDx4dnSd5y7MhnNgYY/BCu0sn6m JCza6vSyHyFMenEQF6AigLYwrp/Hy2Va4R2iRR/A9JcQ2263VUrgTt7/wqTEo18x PJtGhNoacO2A+vDCICLtv4Eedmz/9NrgNEQmWR4W9w6kWsJNAMZwDmNK+P3BNErX WBpPM0bYCaEzVq7FWwgPhA0T3OOUhljttwWdbsCGb3Ljybs7VQA9RYyBpG+vmIHR XMnvxlvtGTKkLAI5B3jtVC6kekNdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheehgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 582D54146; Mon, 21 Jan 2019 00:13:47 -0500 (EST) Message-Id: <1548047627.3833063.1639671064.0129BD5E@webmail.messagingengine.com> From: Martin Thomson To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <87sgxpcbx8.fsf-dueno@redhat.com> In-Reply-To: <87sgxpcbx8.fsf-dueno@redhat.com> Date: Mon, 21 Jan 2019 16:13:47 +1100 Archived-At: Subject: Re: [TLS] custom lower limit of record_size_limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 05:13:52 -0000 On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote: > My interpretation is that, if the client sent "record_size_limit" but > didn't receive the extension from the server, that would mean the > extension was not negotiated and the server may not respect the limit. > > Is this correct, or 64 is really mandatory to implement? Unfortunately, if you want your peer to respect your limit, then you have to be willing to generate very small records. BTW, 64 is entirely an arbitrary number. It's at the point where the overheads get really noticeable, so performance is probably pretty bad well before you get to this point. But we didn't get any indication that it was impossible to go that low. If there had been feedback about it being too small, I'm fairly sure that a large number would have been fine. Do you know why 64 is considered too hard to implement? From nobody Mon Jan 21 00:03:22 2019 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 730E6131023 for ; Mon, 21 Jan 2019 00:03:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KdD4HAT0i6fX for ; Mon, 21 Jan 2019 00:03:16 -0800 (PST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 A08E2130FC4 for ; Mon, 21 Jan 2019 00:03:16 -0800 (PST) Received: by mail-wr1-f53.google.com with SMTP id x10so22066480wrs.8 for ; Mon, 21 Jan 2019 00:03:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=EuuNDAkrGq5dW+WTbCfvIdxFyrtmFmAYbbWa3BmGvrk=; b=h8N+1lp8lQ9DRirK8uu1aQs7NBbLtHztO7KQ9OiGhJ8LNnvKxoTJypG6yZptzLpdE7 aG9uWWdq+wvDTYv8DXYMnNfwKGA5vogE5REUUpN8hm1j1bPS/8eAgkhJCwmT5ZPdLqaG 2gTwn/bqCGzT8+zV5+LRMYJtEUumJCavOhsjGXbbAOXrVS9evm89xyudFurB7vn5Db5w ngYSVmzX+XpFU3XYqOlDxYK9piLbEoeT26O12TVICaPijQvVimQ9xXnfFZovkLVgt61+ 6aOlywXMrRa6oped7qhRWcTsK34W2wxKAtf3/Y+7xd0AhZEKN2SQ+S4Dt86Jr11ChyaN gwaQ== X-Gm-Message-State: AJcUukc4+342VtlJjKQ4XtcbmLUH5LT48hfc+pKDBzh5mtcIDvkLpHgs 0rBWy02iuM7ORRqkAuO2yK7FzRdRucw= X-Google-Smtp-Source: ALg8bN5mpw4m4F4kDXDvOcnSx10pH5VUf8z3JuiDfd7J0D+xLHbI2vmSV0KaH/JiDwpyW3K9jsYCWg== X-Received: by 2002:a5d:6105:: with SMTP id v5mr26075114wrt.63.1548057794878; Mon, 21 Jan 2019 00:03:14 -0800 (PST) Received: from localhost.localdomain (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id 124sm51251695wmh.22.2019.01.21.00.03.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Jan 2019 00:03:14 -0800 (PST) Message-ID: From: Nikos Mavrogiannopoulos To: Martin Thomson , tls@ietf.org Date: Mon, 21 Jan 2019 09:03:13 +0100 In-Reply-To: <1548047627.3833063.1639671064.0129BD5E@webmail.messagingengine.com> References: <87sgxpcbx8.fsf-dueno@redhat.com> <1548047627.3833063.1639671064.0129BD5E@webmail.messagingengine.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.3 (3.30.3-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] custom lower limit of record_size_limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 08:03:21 -0000 On Mon, 2019-01-21 at 16:13 +1100, Martin Thomson wrote: > On Sat, Jan 19, 2019, at 19:02, Daiki Ueno wrote: > > My interpretation is that, if the client sent "record_size_limit" > > but > > didn't receive the extension from the server, that would mean the > > extension was not negotiated and the server may not respect the > > limit. > > > > Is this correct, or 64 is really mandatory to implement? > > Unfortunately, if you want your peer to respect your limit, then you > have to be willing to generate very small records. > > BTW, 64 is entirely an arbitrary number. It's at the point where the > overheads get really noticeable, so performance is probably pretty > bad well before you get to this point. But we didn't get any > indication that it was impossible to go that low. > > If there had been feedback about it being too small, I'm fairly sure > that a large number would have been fine. Do you know why 64 is > considered too hard to implement? I do not think that 64 is not hard to implement, but I think it is very hard to implement it in a way that it is efficient. I have not measured specifically TLS with 64 byte packets, but my experience with ATM (telephony) which has 53-byte packets, suggest to avoid small packetizations if you want use your CPU for something other than packing and unpacking frames. regards, Nikos From nobody Mon Jan 21 00:17:01 2019 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 2BCF3130FA5 for ; Mon, 21 Jan 2019 00:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BnO-HNsxg-YC for ; Mon, 21 Jan 2019 00:16:57 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 92BA9130F2D for ; Mon, 21 Jan 2019 00:16:57 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C90B5696073E9A79B534 for ; Mon, 21 Jan 2019 08:16:54 +0000 (GMT) Received: from SINEML702-CAH.china.huawei.com (10.223.161.52) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 21 Jan 2019 08:16:54 +0000 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.100]) by SINEML702-CAH.china.huawei.com ([169.254.255.221]) with mapi id 14.03.0415.000; Mon, 21 Jan 2019 16:16:41 +0800 From: Wang Haiguang To: "tls@ietf.org" Thread-Topic: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated Thread-Index: AdSc+ToMK5SgJR+fTtWsM2NRX2mmLP//3EsA/90z5YCARR/BgP/5YrHw Date: Mon, 21 Jan 2019 08:16:39 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E2650B4@SINEML521-MBX.china.huawei.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E229AD4@SINEML521-MBX.china.huawei.com> <20181226145106.GA6893@LK-Perkele-VII> <0AE05CBFB1A6A0468C8581DAE58A31309E25155E@SINEML521-MBX.china.huawei.com> <20190117110319.GA23896@LK-Perkele-VII> In-Reply-To: <20190117110319.GA23896@LK-Perkele-VII> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.37.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 08:16:59 -0000 RGVhciBJbGFyaSwgUnVzcyBhbmQgYWxsDQoNCkluIHByZXZpb3VzIGNvbW1lbnRzIHJlY2VpdmVk IGZyb20gdGhlIG1haWxpbmcgbGlzdCwgZXhwZXJ0cyBzdWdnZXN0IHVzIHRvIGJhc2Ugb3VyIFRM Uy1JQkMgZHJhZnQgb24gVExTIDEuMyBpbnN0ZWFkIG9mIFRMUyAxLjIuICBXZSBkbyB0aGluayBp dCBpcyBleGNlbGxlbnQgc3VnZ2VzdGlvbi4gDQpUaGVyZWZvcmUsIHJlY2VudGx5LCB3ZSBoYXZl IHJldmlzZWQgb3VyIGludGVybmV0IGRyYWZ0ICJVc2luZyBJZGVudGl0eSBhcyBSYXcgUHVibGlj IEtleSBpbiBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykiICBhY2NvcmRpbmdseSBhbmQg bm93IGl0IGlzIGJhc2VkIG9uIFRMUyAxLjMuIA0KDQpCZXNpZGUgdGhhdCwgYW4gT0lEIGhhcyBi ZWVuIGFzc2lnbmVkIGJ5IHRoZSBJQU5BIHJlY2VudGx5IGZvciB0aGUgRUNDU0kgc2lnbmF0dXJl IGFsZ29yaXRobSwgYW5kIHRoZXJlZm9yZSwgIHRoZSBPSUQgdGFibGUgaGFzIGJlZW4gdXBkYXRl ZCBhbHNvLiANCg0KUGxlYXNlIGhlbHAgdG8gcmV2aWV3IG91ciByZXZpc2VkIGRyYWZ0IGFuZCBs ZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzIG9uIGl0LiBCZWxvdyBpcyB0aGUgbGluayB0byB0aGUg bmV3IGRyYWZ0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy10bHMtcmF3LXB1 YmxpYy1rZXktd2l0aC1pYmMtMDcudHh0DQoNCkJlc3QgcmVnYXJkcy4NCg0KSGFpZ3VhbmcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNv bSBbbWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSmFu dWFyeSAxNywgMjAxOSA3OjAzIFBNDQpUbzogV2FuZyBIYWlndWFuZyA8d2FuZy5oYWlndWFuZy5z aGllbGRsYWJAaHVhd2VpLmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExT XSBBIG5ldyBkcmFmdCBmb3IgIlVzaW5nIElkZW50aXR5IGFzIFJhdyBQdWJsaWMgS2V5IGluIFRy YW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIgaGFzIGJlZW4gdXBkYXRlZA0KDQpPbiBUaHUs IEphbiAxNywgMjAxOSBhdCAxMDoyMTo0M0FNICswMDAwLCBXYW5nIEhhaWd1YW5nIHdyb3RlOg0K PiBEZWFyIElsYXJpDQo+IA0KPiBTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIA0KPiANCj4gV2Ug YXJlIG5vdyB0cnlpbmcgdG8gbW92ZSB0aGUgVExTLUlCQyB0byBUTFMgMS4zIGFuZCB3aWxsIHVw bG9hZCBhIG5ld2VyIHZlcnNpb24gc29vbi4gIA0KPiANCj4gSW4geW91ciBwcmV2aW91cyBlbWFp bCwgeW91IHNhaWQgdGhhdCB3aXRoIFRMUyAxLjMsIHRoZSBjbGllbnRfY2VydGlmaWNhdGVfdHlw ZSBpcyB1bm5lc3NhcnkuDQo+IEluIGZhY3QgY2xpZW50X2NlcnRpZmljYXRlX3R5cGUgYW5kIHNl cnZlcl9jZXJ0aWZpY2F0ZV90eXBlIGFyZSANCj4gZGVmaW5lZCBpbiBSRkMgNzI1MCBhbmQgdXNl ZCBpbiBjbGllbnQvc2VydmVyIGhlbGxvIHRvIGluZGljYXRlIHRoZSBwcmVmZXJlbmNlIG9mIGNs aWVudC9zZXJ2ZXIgb25lIGNlcnRpZmljYXRlLg0KPiANCj4gQ2xpZW50L3NlcnZlciBjYW4gdXNl IGl0IHRvIGluZGljYXRlIHdoZXRoZXIgdGhleSB3YW50IHRvIHVzZSANCj4gUmF3UHVibGljS2V5 IG9yIFguNTA5IGluIGF1dGhlbnRpY2F0aW9uLiBTbyBpZiB3ZSBkbyBub3QgdXNlIGNsaWVudF9j ZXJ0aWZpY2F0ZV90eXBlLCBob3cgdGhlIGNsaWVudCBpbmRpY2F0ZSBpdHMgcHJlZmVyZW5jZSBv biBSYXdQdWJsaWNLZXkuDQoNClVnaCwganVzdCBub3RpY2VkIHRoYXQgdGhlIHRlcm1pbm9sb2d5 IGlzIHByZXR0eSBjb25mdXNpbmcuLi4NCg0KVGhlcmUgYXJlIHRocmVlIHNpbWlsYXJseSBuYW1l ZCB0aGluZ3M6DQoNCi0gUmVnaXN0cnkgY2FsbGVkIENsaWVudENlcnRpZmljYXRlVHlwZSAob25s eSB1c2VkIGJ5IFRMUyAxLjIsIHRoZXNlDQogIHZhbHVlcyBnbyBpbnRvIG9uZSBmaWVsZCBpbiBD ZXJ0aWZpY2F0ZVJlcXVlc3QgbWVzc2FnZSkNCi0gZXh0ZW5zaW9uIGNhbGxlZCBjbGllbnRfY2Vy dGlmaWNhdGVfdHlwZSAodXNlZCBieSBUTFMgMS4yJjEuMykNCi0gUmVnaXN0cnkgY2FsbGVkIGNl cnRpZmljYXRlIHR5cGVzICh2YWx1ZXMgdXNlZCBieQ0KICBjbGllbnRfY2VydGlmaWNhdGVfdHlw ZSBjb21lIGZyb20gaGVyZSkuDQoNCg0KDQotSWxhcmkNCg== From nobody Mon Jan 21 07:10:10 2019 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 D04BE130F88 for ; Mon, 21 Jan 2019 07:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ieMbXnIbPiJA for ; Mon, 21 Jan 2019 07:10:06 -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 570A1130FCD for ; Mon, 21 Jan 2019 07:10:06 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9169E757D6; Mon, 21 Jan 2019 15:10:05 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id D035E61090; Mon, 21 Jan 2019 15:10:04 +0000 (UTC) From: Hubert Kario To: tls@ietf.org, Tommy Pauly Date: Mon, 21 Jan 2019 16:09:57 +0100 Message-ID: <15963767.JlSI183RGp@pintsize.usersys.redhat.com> In-Reply-To: <154785795557.17452.3793151756514602603@ietfa.amsl.com> References: <154785795557.17452.3793151756514602603@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1638868.PUVoOPF6UF"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 21 Jan 2019 15:10:05 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2019 15:10:09 -0000 --nextPart1638868.PUVoOPF6UF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 19 January 2019 01:32:35 CET 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. >=20 > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > Filename : draft-ietf-tls-ticketrequests-00.txt > Pages : 6 > Date : 2019-01-18 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00 The security section probably should note that large server self-imposed li= mit=20 could be used for Denial of Service. "Servers MUST NOT send more than 255 tickets to clients." across the whole connection or directly after Finished? For long-lived=20 connections that may be problematic, especially when connected with multipl= e=20 post handshake authentication exchanges... What about ticket count after post handshake authentication? Should we allo= w=20 the client to re-issue the extension in Certificate message? Should handling of "0" in extension be special? As in, if client is asking = for=20 0 tickets (e.g. because it will not do resumption), "SHOULD" the server=20 respect that and send no tickets? (while the min(srv_limit,=20 clnt_request.count) will do that, I think it may be prudent to spell it out) Is the extension negotiated every time when resuming the session, or should= it=20 be saved as part of session data by server? What if client starts advertisi= ng=20 it, drops it or changes value in the next ClientHello that offers resumptio= n? I'm assuming that it cannot be changed by client in 2nd ClientHello when do= ing=20 Hello Retry Request handshake. Shouldn't that be stated explicitly though? =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 --nextPart1638868.PUVoOPF6UF 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+dkqjRuAHS9fUFAlxF4MUACgkQkqjRuAHS 9fWTfQ/7Br1Aa/SFWy2okGG6ZAJjQNr1CXm5+kAm+voQ16+3x+OcEcKUcGebCVlQ r+inW6GjjPDSxl2yGZdmu+zn46S0ZpWSvaVcSj0EQTjoBKHU0hDUe5r/DeKTYan2 gB0foxRhc0nV2pJ1uOyVJprJaEtWsc3SWiJPrePU7fHmZSIxXyUbmJSog5EKnVDT 41syOLqJk/UBoXrk/kP4jRTPqvI9ms/v6/MY0cpAaFNAJZWIOeSL8TwM7Qkwrfet BVJpWebJ7VDfrkJSWqPGfDAV4H7N9hmqJxedogx6jILZXQcrgrCdPnh8Hpo5VM2p imjED7cuCRey2QP8TdOiV80EB7HtEaDv0KUIAEAEN464Y01wPJiHwM3ItclMwomd +3IYCBhA+P1a0nXNteDRprj6mSHv7Y8OvawIpv/stfTqBxUi0ZCtCP2mk073gQo5 8tlhfJjq+FzOeShy0Q+8MgNrdgSEyHR3SznXFCVIZCLD/uDYAlaA8lTI4o2XF8Mt PzV/cVQ0MXkDvkEz0SIP7VvTPgrcahDoXDo3ahYVgKptdIiYzN+aEubdNCYHYZbB ltvJ+H3v09gZ6Xh0BrG4ZJsgDmYsetMCiCsBZRS0sojK5qEXNau/eB8KPTfFV0P9 bS7LOZA0j+Mcs9j/94el5uc1ZVnQEtNqinz+EAvtyIrYg2HrpWs= =Bzn2 -----END PGP SIGNATURE----- --nextPart1638868.PUVoOPF6UF-- From nobody Tue Jan 22 11:06:53 2019 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 E20B912875B for ; Tue, 22 Jan 2019 11:06:50 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 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 VBdoaRNj3FbP for ; Tue, 22 Jan 2019 11:06:48 -0800 (PST) Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) (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 4E4DE12785F for ; Tue, 22 Jan 2019 11:06:48 -0800 (PST) Received: by mail-qt1-f194.google.com with SMTP id y20so28820941qtm.13 for ; Tue, 22 Jan 2019 11:06:48 -0800 (PST) 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 :content-transfer-encoding; bh=SdaBXTJHE8b8axLan65+7E9CfNX7R9nttthLLiqzSCU=; b=Qi0CcOwgmhl3Zbvm1quov+Lt9z7HfaRoldtq+PdBLMmcEBlrAejFrK76L0UIyAKoOX twiscEl6O+/G9sC47gh9zZtHAHYd3Lq89GDJKJ/4IJqMVfqRSpWG4yInp3QFqWN0dLb8 ednUbNJAAiiD4nDc0tNMk2xsJXJjG3ZM+mrB+5J1Tn2pIqI0WLe3ZwZkM+UDM/QKQITt 8Pb0xOIaDMgL0VJ8SARVbLtxLWk/LuFivL+IYL1MCd1ijfyllUDSuq8/k0V3IxR6hccK wqjvbUwdAakMvVpwjzCDdaX/PEPOdwK+KehQ2f9Qr/adkAFpzcgme5jmujgRgDs0q4zD nlWg== X-Gm-Message-State: AJcUukdeKWnYpkwUTt816iGV2TaHq8cBVKmTCBF2hyoZEiiujHLBBoB4 0osW3U9Qo74On8Ih46N1LSyuNTQ8uXtpCTU/mC2tHGR1 X-Google-Smtp-Source: ALg8bN4XUYjfZ9ToWLbjejiB/1KIaSPxtV1kjeuzwA00IGZ1SK6Kw1sxG9kLepVUVJZMY+bLMYhELhw1eSi9vwoxh8Q= X-Received: by 2002:ac8:7201:: with SMTP id a1mr32608897qtp.291.1548184006609; Tue, 22 Jan 2019 11:06:46 -0800 (PST) MIME-Version: 1.0 From: Adam Langley Date: Tue, 22 Jan 2019 11:06:35 -0800 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Yet more TLS 1.3 deployment updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 19:06:51 -0000 (This is another installment of our experiences with deploying the RFC-final TLS 1.3=E2=80=94previous messages: [1][2]. We share these with th= e community to hopefully avoid other people hitting the same issues.) In the last update, David reported our experience with a bug[3] in Java 11's TLS 1.3 implementation. We can confirm that this was fixed in 11.0.2. However, since then another issue[4] has come to our attention[8], the fix for which is not in any released version of Java 11. Additionally, we have found a third issue by code inspection which we'll report on the Java bugtracker. As such, we continue to fingerprint Java 11 clients on the server and deny them TLS 1.3. This undercuts TLS 1.3's anti-downgrade measures and we continue to send a special nonce suffix in that case[2]. Last week we tried sending KeyUpdate messages in Google Chrome, which went poorly. Several, major OpenSSL-using applications block TLS 1.2 (and prior) renegotiation by installing a callback with OpenSSL and watching for SSL_CB_HANDSHAKE_START events after the handshake has completed. Such events are assumed to be renegotiation attempts by a client and cause the connection to be dropped. However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3 post-handshake messages are received[5], including KeyUpdate. This causes KeyUpdate messages to break with, at least, HAProxy, and with NGINX prior to this commit[6]. (There may well be more, but that level of breakage was enough to drown any other signal.) Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages per connection[7]. Therefore clients that send periodic KeyUpdates based on elapsed time or transmitted bytes will eventually hit that limit, which is fatal to the connection. Therefore KeyUpdate messages are not currently viable on the web, at least when client initiated. [1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE [2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ [3] https://bugs.openjdk.java.net/browse/JDK-8211806 [4] https://bugs.openjdk.java.net/browse/JDK-8213202 [5] https://github.com/openssl/openssl/issues/8069 [6] https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc= 39dde5ee/nginx/src/event/ngx_event_openssl.c [7] https://github.com/openssl/openssl/issues/8068 [8] https://twitter.com/__subodh/status/1085642001595265024 Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Jan 22 13:33:54 2019 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 7505B131141 for ; Tue, 22 Jan 2019 13:33:53 -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=lowentropy.net header.b=gwox+cyB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xmbIErcQ 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 Bv-zXLEPJfrD for ; Tue, 22 Jan 2019 13:33:51 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542AA131133 for ; Tue, 22 Jan 2019 13:33:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 694AF142A8; Tue, 22 Jan 2019 16:33:50 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Tue, 22 Jan 2019 16:33:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:date:in-reply-to:subject; s=fm1; bh=HgO q+bry0BpWpxo52u7G9kuygzlkx0rKOYcV8wibo1Q=; b=gwox+cyBJ6h3+Hz9J8k t+CyKydnu6rstbgzLX4YT/nlo0ay8X5Ujl95iWpmH+vcDYCjy+u/qZddsD2xsvnM xlzXDwdR7ojMH6Ud0B/zzBERmHhvvjSmLZYa93sxlatMzS4xvRr9KATkfutWHD7y MlpJnn8LWO2jw1U7LgWnQ4W51caaR0wylTOeuOr02XCh2oGYkeaanI/9WCtKRb6b 0D4DC4SbJafPSuGyNsDHeGrUB0OjVLkHIPGutXmsnfKpCehlKR9TUr0eRhonY54b abgUYCf7o3d5p0Pk2/+TVoJkv7a7/IR/phd5TZxUZDWxhBXyPyg4IPVjrYeQsBnE 2SQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HgOq+bry0BpWpxo52u7G9kuygzlkx0rKOYcV8wibo 1Q=; b=xmbIErcQL28NytoI5S/w+Czipg7OIl4zpHn0e8Q0+udK+pThNi2elznGO D4hPHb+Kl3yTWwntX0U+jp/fA1KPj6XFMj5vHcAKUKpfRTiXkoaWrKyed0AswGfj Nvwrp66USDvq48OA1fICkEU5HLiBEPe3kOQpKtAR15HlQRB+11XY3T0LFxxCIedb vSGaaqE4G21DnRQKlqhrVXEy62OHwyEGeBuQ3X4i2petidm0JV+N573Ezq8M7mQb lbjUF6wgztFMPTsSFCe1aOiRc8uvQDRnvpMaoELRZG5S5I6pNG1nVarNJ2KKVWmG BETrbSDFd8re6qjlLvi/yZZIYQSMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheekgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg fofhffjgfusehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 999684146; Tue, 22 Jan 2019 16:33:49 -0500 (EST) Message-Id: <1548192829.1018496.1641183592.56FCA0FD@webmail.messagingengine.com> From: Martin Thomson To: Nikos Mavrogiannopoulos , tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <87sgxpcbx8.fsf-dueno@redhat.com> <1548047627.3833063.1639671064.0129BD5E@webmail.messagingengine.com> Date: Wed, 23 Jan 2019 08:33:49 +1100 In-Reply-To: Archived-At: Subject: Re: [TLS] custom lower limit of record_size_limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 21:33:53 -0000 On Mon, Jan 21, 2019, at 19:03, Nikos Mavrogiannopoulos wrote: > I do not think that 64 is not hard to implement, but I think it is very > hard to implement it in a way that it is efficient. Totally agree. There's like a curve for performance with an asymptote as records get bigger and a steep incline as records get smaller. I picked 64, not because it is good - it's clearly terrible for performance - but because it was a power of 2 that was enough bigger than the handshake overhead that you couldn't configure a connection that was guaranteed to be unusable. 32 might have been enough, but it's pretty ludicrous, especially in DTLS. I didn't want to make this a performance consideration. Clearly 128 is much better than 64 performance-wise, but then 256 is better again. Where on that curve your preference lies will depend on your constraints. In the end, if a peer wants 64 and that would degrade performance too much for you, then you have a choice: don't negotiate the extension, or - for clients that don't get this choice - don't communicate with that peer. From nobody Thu Jan 24 07:49:03 2019 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 50E78130E93 for ; Thu, 24 Jan 2019 07:49:02 -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 ik1m8mR_2YY4 for ; Thu, 24 Jan 2019 07:49:00 -0800 (PST) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A0F130E8F for ; Thu, 24 Jan 2019 07:49:00 -0800 (PST) Received: by mail-qt1-x841.google.com with SMTP id u47so7061337qtj.6 for ; Thu, 24 Jan 2019 07:49:00 -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:date:references :to:in-reply-to:message-id; bh=C8gQwH4o6ehgQcJJvhltyh+0jcoVpk+4GSL/RirPucU=; b=V+JQtwmsjmI+0oAq5TqTRiE2nZ3n2FZUNAtW8rlB60FyBmVK2dnMQE3WAEdDCp9UJn TBqbI9YCXEPdfBtRq/WNEPy5BCgQ4TwTHy2GM8qztaTFcwSJPJ2wCo6yb3HI00kzX02z LvFBCmTO+QjqO8ORjg3Q1kYicMqxG0z3JCJQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=C8gQwH4o6ehgQcJJvhltyh+0jcoVpk+4GSL/RirPucU=; b=UWf97eV8GhW12BYGxpG6boYYSW0wFBV7Hwl49y/831BrDp4igGv8tyxjddEFRcTB7y dfnDP4GmlhG0G/GhpuaUf9jBnuiZfCKNos1840fBa7oko0ZOgDs+nQNa5t7ktvD2eWr+ w/Wvq2557m9idopVemlpLeuYo1wB9KuzsXdXdFLknVipNHqHZpor67MT4i2eiW0LjZqw qCGw1FYT+zRu7pBfvAB0o/1HhO3OzJT8LD217pSmMFtzGdVoUsgCtVZM1d1tVH/L/T8m FBRt+KqEr4fa/8cI7KMGkIF+aXSCyXgSt37DexMWQsc5tsdDzwyrUS44g4lr8DzlkdoE GqGA== X-Gm-Message-State: AJcUukcmjK4AU14Zh2DERjchyF3RqQLKwQsu/T/4duZYS0DqiPRuhKfJ G7QXAo7JjviA3srqeQOpe68JE4n0+n9dDw== X-Google-Smtp-Source: ALg8bN5AMsZceEtoSH5QIOxRtj87iQ9W2Jl3ZiS0qws+OehO0xLXANZQvYK6gYwjsuX5Bz8DHBC4LA== X-Received: by 2002:a0c:eb41:: with SMTP id c1mr6752929qvq.211.1548344939192; Thu, 24 Jan 2019 07:48:59 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id k16sm31025638qkj.38.2019.01.24.07.48.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jan 2019 07:48:58 -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 12.2 \(3445.102.3\)) Date: Thu, 24 Jan 2019 10:48:57 -0500 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> <96738939.LbPAkC2fvU@pintsize.usersys.redhat.com> To: TLS List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 15:49:02 -0000 > On Jan 17, 2019, at 15:38, David Benjamin = wrote: >=20 > On Thu, Jan 17, 2019 at 2:31 PM Hubert Kario = wrote: > On Thursday, 17 January 2019 21:23:37 CET David Benjamin wrote: > > On Thu, Jan 17, 2019 at 11:05 AM Hubert Kario = wrote: > > > On Wednesday, 16 January 2019 21:25:26 CET = internet-drafts@ietf.org wrote: > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-tls-grease-02 > > >=20 > > > while record_size_limit extension sends just one value, it does > > > specifically > > > allow the client to advertise higher values than the protocol = versions or > > > extensions would indicate > > >=20 > > > I wonder if sending such values shouldn't be part of GREASE = behaviour, > > > even if > > > it wouldn't use GREASE values... > >=20 > > I think that should be sorted out in a separate document. This one's = been > > sitting around for a while as it is, and record_size_limit doesn't = have an > > RFC to cite yet. :-) >=20 > eee? https://tools.ietf.org/html/rfc8449 >=20 > Oh, huh. It wasn't linked from = https://tools.ietf.org/html/draft-ietf-tls-record-limit-03, so I didn't = see it. >=20 > David I was minutes away from issuing the WGLC for this draft when Hubert=E2=80=99= s message came in. I want to make sure we address his comment, but I = also want to get the WGLC going. Since this is the only known issue, = the WGLC will refer to issue specifically (and this thread) to see if we = can bring it to a close. You can comment on the WGLC thread or in this = thread. =20 spt= From nobody Thu Jan 24 07:50:40 2019 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 4FC89130ED8 for ; Thu, 24 Jan 2019 07:50:38 -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 4HruuqgYfNOK for ; Thu, 24 Jan 2019 07:50:34 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 33EB6130EC7 for ; Thu, 24 Jan 2019 07:50:34 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id g125so3510489qke.4 for ; Thu, 24 Jan 2019 07:50:34 -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=S+VwLphUGB7I90aZ/5PNiTtzrT4XMmUhzcSZzzWa1Dk=; b=W9T+KTegPyloRvUQvGdgZaPDdizKRL+TEZcfTc8Cj/bHccmVo41QTAVX60h5sEssgX TMj5RKeiWqrMeSd0M10FmSlp9RBgk5ua4DZMXNUC16wlJoyijvUPPFwb47h/i0/p/wBu j8yYdHzlfXRTurkJQ0+8IhEUep/7xWxJ+DjLI= 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=S+VwLphUGB7I90aZ/5PNiTtzrT4XMmUhzcSZzzWa1Dk=; b=q731ft77n9h6XilmVk/6BCyKeQU2RGCg+WtD0F3jyRdvw3ZDC7mYEmFT0qBCU65BTL 4d3TcgiXia3fwAAKX2NTcFE2DpQCfUKWUFagM3BoHlmc/1uyxGxHJZOCwdTMCmFbqHOJ BBms1gt59ft6D6O1tKFDDTHm9SVsNAXURieqNC92CEb6nrenT4ATaHqOwUf71Cbf7afd kMRlQI93/4g29k4mIzMGixnufHJU6y6CXsxo/OcHLsC2XLZZw6TJU4B8+wZkaFKTxtnA X35i9XyZJTkHvF1b65ImMwR8HV2KKODHARJNU5CgaCYi5B7bif1rhmX2RIPlCxJw3c+m 8N3g== X-Gm-Message-State: AJcUuke3DYBpfTUJBOdCGW7pLH6oJzC+5bERF0OczdhFBKIcCR4J9S3y yIu/kPn99Pu3FqEBJ8axmLfN3e1WmQEMZA== X-Google-Smtp-Source: ALg8bN7H/CXjAEmVFLojwNGggLMSkru/LWUuTp4TaSyGEmYYUpDCLyvmWiAi3dLfUIRWze2RwSZOQQ== X-Received: by 2002:ae9:efd6:: with SMTP id d205mr5861429qkg.274.1548345033132; Thu, 24 Jan 2019 07:50:33 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id w15sm79461012qta.16.2019.01.24.07.50.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Jan 2019 07:50:32 -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 12.2 \(3445.102.3\)) Message-Id: Date: Thu, 24 Jan 2019 10:50:31 -0500 To: TLS List X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 15:50:38 -0000 This is the working group last call for the "Applying GREASE to TLS = Extensibility" draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-grease/. Please review = the document and send your comments to the list by 2359 UTC on 8 = February 2019. NOTE: There is one outstanding issue raised by Hubert [0]. Please chime = in there or here so that we can address his comment one way or the = other. Thanks, Chris, Joe, and Sean [0] = https://mailarchive.ietf.org/arch/msg/tls/nr4dA2JqcpqAjh-oY_1z2l6ZMFo= From nobody Thu Jan 24 11:32:09 2019 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 D4FA61311CF for ; Thu, 24 Jan 2019 11:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 WnWOvYffggXh for ; Thu, 24 Jan 2019 11:32:05 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 DB513131159 for ; Thu, 24 Jan 2019 11:32:04 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id c21so4022977qkl.6 for ; Thu, 24 Jan 2019 11:32:04 -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=r6rEJVmAWqIi9j+qnJWBOoKhShzcBnjbAomHf1K/ypk=; b=rHnvPecrWe0jyXIO6wlGd9LTBJ03MZLGGmowmdKe7qahB/C4w0o2UarvS3QizyYkQA y/49lhOD8dTlvCaJ9vai9YtTLcUmcK+CzTPaUpNOf8alnII0SOuewbNnIkXTCnda3oUI yfg/au7TvfIlelgShdZR0OoIqVGZosHvNYqXiWh6e7HB7TH6g1L861xKDCyTLYNOerXx l5XYmmShF4NM+UQpzkS8Bc3nu5iul+Xc794In5BNu/QfSvZzVtwiEk/KOcUp6HrLe/9J SAUSP0+d2phcHywC2m/HJ/1p9mohqsDbeVA0pnDOgJsHSwfCaDh+7BvNldXfltLnmYm6 4W7g== 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=r6rEJVmAWqIi9j+qnJWBOoKhShzcBnjbAomHf1K/ypk=; b=ooK4aru4Vae42RQIt+lcHffNsOZ+EMzUwnzla1wy1eAx5juU8hbm7AWgUwrZ2zPbqt AvyBWHwY2QEW2FfrnHQdsz7H+109Nu8kOrLuuxLkLREeR8OCdtESWAAbnt7LuWyzxKEG bre8LknqIMgNxZ3fHmwL6q3RG+sqRkpozJ5VTBLUvsbJo76mIR3xl+rstrm5yzNTd2HB I6UOAdATyriNUKy3VR7mvttG8aRl9uVidpStD+NqoLF+Zn0DOhuNdWmQBDGmgCCq5BUW S973iGYzY5sL8v/ri7oHyyVYq2D/O/C3eZnaLBPsH8jhs/CAsKsYfuTVHQDcdN12B9yR OzxQ== X-Gm-Message-State: AJcUukcwSOIkbjUndpnCrEkJb+u2kKcKWU/m5x4Fretw2OdiZ0fQlqmS Hw9grB9CrO7WXsELbeBkh3sR2mmSiAFdB/TEkRwNSFBsu0Nilw== X-Google-Smtp-Source: ALg8bN7WvK2vxQ8O1jdtJIKiDMfzQSDG1XM+R6p+m30hM2Utn8TW/QaFv/9LayyM0mRLq4L0qAsqcKE7KbgtxkG205g= X-Received: by 2002:a37:9906:: with SMTP id b6mr7036279qke.208.1548358323682; Thu, 24 Jan 2019 11:32:03 -0800 (PST) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 24 Jan 2019 11:31:52 -0800 Message-ID: To: "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000de53660580394373" Archived-At: Subject: [TLS] sending draft-ietf-tls-sni-encryption to IESG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 19:32:07 -0000 --000000000000de53660580394373 Content-Type: text/plain; charset="UTF-8" WGLC last call completed some time ago and we have a revised draft and shepherd writeup - https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. We'll be sending this draft to the IESG soon. Thanks, Chris, Joe, and Sean --000000000000de53660580394373 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WGLC last call completed some time ago an= d we have a revised draft and shepherd writeup -=C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.=C2=A0 We= 'll be sending this draft to the IESG soon.=C2=A0=C2=A0

Thanks,

Chris, Joe, and Se= an
--000000000000de53660580394373-- From nobody Thu Jan 24 15:03:31 2019 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 3A2101311F1 for ; Thu, 24 Jan 2019 15:03:30 -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=lowentropy.net header.b=d6ILzO9J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MF7jlpX6 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 pMELPIkP80OR for ; Thu, 24 Jan 2019 15:03:28 -0800 (PST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E5E1311DE for ; Thu, 24 Jan 2019 15:03:28 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 3BFE8126AE for ; Thu, 24 Jan 2019 18:03:27 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Thu, 24 Jan 2019 18:03:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:in-reply-to:subject:date; s=fm1; bh=Z5f LweD89Dj9gf3lKZs6Q+QXYNFWsLzjbNMrzFFPZWw=; b=d6ILzO9JZxj7oXYI5E8 jzUU1tRBNfHZMzrIq8IBnKXXVb2LMN657t2pDnXc1KpJf+UBpsVF0Sy+qruFzkac CIh4/xyd3IN5jFayb2x/q3rq6FlK0gqtECuDpL/+Gspmo8jtDcDYS63T/URcgBEK gas0w8DtXaQhXxYrMKHDl9xzCqOPkOikClKGGspsn1qc9ec5yfNnHla5j2H8Vncx q5jphn3ECZ6DBNL+Tk/LA3GmYJOoLee+GJt0WjJZA3f9AWIp4ax4bTaRD38fuIbA p3b/03ZXZQGae4ymlF3fhWn+3m3KxUi1nGortrrKNOXmPu+sBSpuB37bBMSEtbAD HPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Z5fLweD89Dj9gf3lKZs6Q+QXYNFWsLzjbNMrzFFPZ Ww=; b=MF7jlpX64RZ1OHQy9A2X2CwXECdjBrSGTUyKwTO5yvRJey8FdPOqo8q0t RRcaQbB3gXlfvBoA7NURtjFd7UYj9z7/gtE0mlm3in1FwqNREeHtQ8qwfe0BmQOk Q7wWX+roRUwShv50FWS6aYvJeHiXrFBVgPEvHXW6iPu0CSBijnUI8NzB2Gpo4zip k0vR7pDyH5a1+rZjtaWJS8JhG1eLfc2b61PwA9UG8YFajWnlBXRA9xiMWV7QvCyB rLx10r02lDeFELo2ulukE2uEwT0mLW9yMu/kLvzrV4/XYxjv5Ztvs2k7Ivc4Qtgr m+N29BS/MtUDcPtvRG8S3XJOO5sxg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieefgddtiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhgjufffsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id EA82C9E560; Thu, 24 Jan 2019 18:03:25 -0500 (EST) Message-Id: <1548371005.3487947.1642965368.3A897C7A@webmail.messagingengine.com> From: Martin Thomson To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> In-Reply-To: Date: Fri, 25 Jan 2019 10:03:25 +1100 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 23:03:30 -0000 On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote: > > while record_size_limit extension sends just one value, it does > > specifically > > allow the client to advertise higher values than the protocol versions or > > extensions would indicate > > > > I wonder if sending such values shouldn't be part of GREASE behaviour, > > even if > > it wouldn't use GREASE values... > > > > I think that should be sorted out in a separate document. This one's been > sitting around for a while as it is, and record_size_limit doesn't have an > RFC to cite yet. :-) I'm in two minds about this. On the one hand, we don't need any actual machinery here, so why do anything? On the other hand, it's just a note that this is possible, and adding that sort of note is easy. > The record_size_limit extension {{!RFC8449}} includes a value that can be greased by endpoints that don't place constraints on their record size. Advertising values larger than the protocol supports is permitted and has no effect on the behavior of a compliant peer. From nobody Thu Jan 24 15:23:37 2019 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 E8FC61311EA for ; Thu, 24 Jan 2019 15:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37yzi8EQ9Jq0 for ; Thu, 24 Jan 2019 15:23:34 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 D217013108C for ; Thu, 24 Jan 2019 15:23:33 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id i20so6908621otl.0 for ; Thu, 24 Jan 2019 15:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t9IMpp7X7Ki4vHYT3t2kWCeU7gwFHu8ngQeKTHd+3J0=; b=FpX4qBcaIiyA7s/TvZ1sTTtYLegm60Ycd7zTDlHizATg5Ce396HdNimKm4JHXlUVeg m/7DaOF3u9LWSAWJs62MSglsKrQP4xTVy6MU+ILCRDGN3BVbC3pzp1FojckBU5OQqiYR fH7jlDqNs4aJaItZt73KeJI7w1U6QrIgUqcXI= 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=t9IMpp7X7Ki4vHYT3t2kWCeU7gwFHu8ngQeKTHd+3J0=; b=ccctKEocv1PHUhEkmAZOSLEu/IOuNN7vOoaqScwNqXdP4W4vbvxtZ9I4nclJm+qwRv ajjtmmMJWZy8+A/WupF3x76vjBO7zBbPH0KIJfhSuNOJcONj2aqls9dpyv9yhPpYy0Qa sj/OwsaGk2Vqe7PzLxzY5oif3+/VzyPfyTC/T4tVE8NkTTqrVq45LzE5bB8MiKy4pwjf DQoZWp+bXYsnWZrlzjO5fv06Ht28pBbO/OWueeySrHBjEUeMzJR3JJ3oXmphFEcc+Hxq w7WS9T01xxfmmiDsdW1cHucMnnwK2OFl/J3RtOzUXZehvJLNjVUS9mZZaixexlHJtsyH aiWw== X-Gm-Message-State: AJcUukf+UmumOJvYVFSr6hrCGqx9Gk0+FFwmrwWUJmi1okZ41S54zGv0 1TmB8TxrhvSrqRB+CuTef/XtI12+dwys4eLFxJKhK9A00xA= X-Google-Smtp-Source: ALg8bN65sOoaXfy1fxzFMz/uhnvPOSWZZW4kqsqzgRW4pPIGLk7eoTvAEHR+1CQo7xYPak2/NC5VVlrPyyLFHYKQh7g= X-Received: by 2002:a9d:76da:: with SMTP id p26mr5592658otl.366.1548372212899; Thu, 24 Jan 2019 15:23:32 -0800 (PST) MIME-Version: 1.0 References: <1547609984.2756240.1635793576.0E070413@webmail.messagingengine.com> In-Reply-To: From: Nick Sullivan Date: Thu, 24 Jan 2019 15:23:20 -0800 Message-ID: To: Subodh Iyengar Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bb081b05803c7f5f" Archived-At: Subject: Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 23:23:36 -0000 --000000000000bb081b05803c7f5f Content-Type: text/plain; charset="UTF-8" I'm also fine with removing the field and would welcome a PR to that effect. Putting in a version to protect a DC from future cross-protocol attacks that exploit TLS 1.3 smells a bit like over-engineering anyway. Nick On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar wrote: > I don't feel too strongly about the tls version binding and I'd be fine > with removing it to favor operational simplification. > > > Subodh > ------------------------------ > *From:* TLS on behalf of Martin Thomson < > mt@lowentropy.net> > *Sent:* Tuesday, January 15, 2019 7:39:44 PM > *To:* tls@ietf.org > *Subject:* Re: [TLS] Version pinning and indicating the signing algorithm > in draft-ietf-tls-subcerts-02 > > On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote: > > Usually the negotiation happens during the processing of the client > hello. > > I don't think that the problem here is a code problem. It's an > operational one. > > In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be > made in isolation. You decide to flip the switch and flip it. But if you > are doing delegated credentials, deploying a new version depends on having > a fallback in place for that version, or getting the vendor of delegated > credentials to start supplying new credentials. And that assumes that all > the necessary stores are keyed correctly (though this highlights the case > where that might not happen), and the code has been written. It's not that > it's impossible, but more that it complicates what was previously > uncomplicated. > > As you say, the decision to use a delegated credential is fairly simple. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qOxPqAH-53XWS1ivRMVW5YPWzTYrcOjqXPcoImyDlnM&s=LwnVFi-5giNs_anA6DyKhcbiJ5NCSU5T1oZyDjx33Nw&e= > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000bb081b05803c7f5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm also fine with removing the field and would welcom= e a PR to that effect.

Putting in a version to protect a= DC from future cross-protocol attacks that exploit TLS 1.3 smells a bit li= ke over-engineering anyway.

Nick

On Tue, Jan 15, 2019 at 11:54 PM Subodh Iyengar <subodh@fb.com> wrote:

I don't feel too strongly abo= ut the tls version binding and I'd be fine with removing it to favor op= erational simplification.


Subodh

On Wed, Jan 16, 2019, at 13:35, Subodh Iyengar wrote:
> Usually the negotiation happens during the processing of the client he= llo.

I don't think that the problem here is a code problem.=C2=A0 It's a= n operational one.

In many ways, the decision to use TLS 1.3 over TLS 1.2 is one that can be m= ade in isolation.=C2=A0 You decide to flip the switch and flip it.=C2=A0 Bu= t if you are doing delegated credentials, deploying a new version depends o= n having a fallback in place for that version, or getting the vendor of delegated credentials to start supplying new cred= entials.=C2=A0 And that assumes that all the necessary stores are keyed cor= rectly (though this highlights the case where that might not happen), and t= he code has been written.=C2=A0 It's not that it's impossible, but more that it complicates what was previously unco= mplicated.

As you say, the decision to use a delegated credential is fairly simple.
_______________________________________________
TLS mailing list
TLS@ietf.org
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000bb081b05803c7f5f-- From nobody Fri Jan 25 08:23:39 2019 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 22E77130E7F for ; Fri, 25 Jan 2019 08:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.052 X-Spam-Level: X-Spam-Status: No, score=-14.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 sCkqmAxHFFCP for ; Fri, 25 Jan 2019 08:23:35 -0800 (PST) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 E81F5130EE7 for ; Fri, 25 Jan 2019 08:23:34 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id r14so11341008qtp.1 for ; Fri, 25 Jan 2019 08:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywlhNXUjXBUFoHmfENrqtINrK1w3YxJzS9sllbAhH0w=; b=SOQ16kKj1b4TJlnjuNN6K2l/h5xHN+Y8rVjfBPPi06aMdLFHhhbfcjjcUCFbfdgq1D EFEFS8AvjkCgLe5UcEeKt3agyJRtFwHYqQT2pPnNLJmtRrZpns1qQTaT4Ara/1RJfH/i GWMmvz5PG57nA63bVf7RdIHNOFKCPRp9oxC7M= 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=ywlhNXUjXBUFoHmfENrqtINrK1w3YxJzS9sllbAhH0w=; b=IrCUJrjnuY4dCYEGl0hQy7wirlcKit/NIETL0pCghIUwO9yJsUm8ml+7odD2e3+7bv RzICyLE+k+XDCIiDq+krYID2XOqmXY/HDfSc9NgvtXBZwPaRe+UDxy8HSy3ojA4QG4no BP2NTS17VIii825HbhABobaf1BWHhoQz5lQnOYQU9kyy1zdvPTfWCPq8AjkMAQIIX1Lx cjJb4zGAeuAHPbLNxZ6xPmcZVU1SYQaNIZdrl+QI1jMkm4GKPhHDMPAyrQ/v63Rgz4qY mO+g1oX5Zql3kSXMXpflcm1sOnpShynXS/3oTAcoldl245f2hYK4S/L/IHPzqArjndAx zbwg== X-Gm-Message-State: AJcUukfd9Z/4i3IyGYa/PadwhzUDjIW8LDCA2BQsMn9/pEK/TUYfCO8U stU3MBhcdUG//OSfTqBtW0VGToccmN5wVQT2mBuuG24= X-Google-Smtp-Source: ALg8bN5xk2IV+cTym+8QJGqM3wLz9bHOxXNuTdkk4M73UiMN6SnjMBgptKeUxNxZhK62yOKzhoqengfYL3oE+6FoAjE= X-Received: by 2002:aed:3482:: with SMTP id x2mr11269922qtd.72.1548433413975; Fri, 25 Jan 2019 08:23:33 -0800 (PST) MIME-Version: 1.0 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> <1548371005.3487947.1642965368.3A897C7A@webmail.messagingengine.com> In-Reply-To: <1548371005.3487947.1642965368.3A897C7A@webmail.messagingengine.com> From: David Benjamin Date: Fri, 25 Jan 2019 10:23:22 -0600 Message-ID: To: Martin Thomson Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000099b16105804abf2f" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 16:23:37 -0000 --00000000000099b16105804abf2f Content-Type: text/plain; charset="UTF-8" On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson wrote: > On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote: > > > while record_size_limit extension sends just one value, it does > > > specifically > > > allow the client to advertise higher values than the protocol versions > or > > > extensions would indicate > > > > > > I wonder if sending such values shouldn't be part of GREASE behaviour, > > > even if > > > it wouldn't use GREASE values... > > > > > > > I think that should be sorted out in a separate document. This one's been > > sitting around for a while as it is, and record_size_limit doesn't have > an > > RFC to cite yet. :-) > > I'm in two minds about this. On the one hand, we don't need any actual > machinery here, so why do anything? On the other hand, it's just a note > that this is possible, and adding that sort of note is easy. > > > The record_size_limit extension {{!RFC8449}} includes a value that can > be greased by endpoints that don't place constraints on their record size. > Advertising values larger than the protocol supports is permitted and has > no effect on the behavior of a compliant peer. > I don't feel very strongly either way, though it is odd that it basically contradicts the sender's rules in RFC 8449. 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. A server MUST NOT enforce this restriction; a client might advertise a higher limit that is enabled by an extension or version the server It does say "unless explicitly allowed by such a future version or extension", so this is basically blanket overruling that sentence a few months after publication. (But overruling it isn't entirely wrong, given the current text imposes a future-proofing receiver rule that the sender is forbidden from checking.) David --00000000000099b16105804abf2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote:
> > while record_size_limit extension sends just one value, it does > > specifically
> > allow the client to advertise higher values than the protocol ver= sions or
> > extensions would indicate
> >
> > I wonder if sending such values shouldn't be part of GREASE b= ehaviour,
> > even if
> > it wouldn't use GREASE values...
> >
>
> I think that should be sorted out in a separate document. This one'= ;s been
> sitting around for a while as it is, and record_size_limit doesn't= have an
> RFC to cite yet. :-)

I'm in two minds about this.=C2=A0 On the one hand, we don't need a= ny actual machinery here, so why do anything?=C2=A0 On the other hand, it&#= 39;s just a note that this is possible, and adding that sort of note is eas= y.

> The record_size_limit extension {{!RFC8449}} includes a value that can= be greased by endpoints that don't place constraints on their record s= ize.=C2=A0 Advertising values larger than the protocol supports is permitte= d and has no effect on the behavior of a compliant peer.

I don't feel very strongly either way, though it is o= dd that it basically contradicts the=C2=A0sender's rules in RFC 8449.

=C2=A0 =C2=A0Higher values are currently reserved f= or future
=C2=A0 =C2=A0versions of the protocol that may allow la= rger records; an endpoint
=C2=A0 =C2=A0MUST NOT send a value high= er than the protocol-defined maximum record
=C2=A0 =C2=A0size unl= ess explicitly allowed by such a future version or extension.
=C2= =A0 =C2=A0A server MUST NOT enforce this restriction; a client might advert= ise
=C2=A0 =C2=A0a higher limit that is enabled by an extension o= r version the server=C2=A0

It does say "unles= s explicitly allowed by such a future version or extension", so this i= s basically blanket overruling that sentence a few months after publication= . (But overruling it isn't entirely wrong, given the current text impos= es a future-proofing receiver rule that the sender is forbidden from checki= ng.)

David
--00000000000099b16105804abf2f-- From nobody Fri Jan 25 10:12:24 2019 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 B76D8131008 for ; Fri, 25 Jan 2019 10:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 6CgICP90et71 for ; Fri, 25 Jan 2019 10:12:21 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 28F53131001 for ; Fri, 25 Jan 2019 10:12:19 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id m62so11819885ith.5 for ; Fri, 25 Jan 2019 10:12:19 -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=dpZRxDkhn3csIfa0U0Y1ntNxvDbRPq1GZCAw43L4SsU=; b=ttHjI6W+bpckqSYIYQBnczM22MDGqlxdt7fyCcXo5zsiHI6OTmNqvaL3nqwG/KLfA9 1UFxsfvBtSiQAWZUmN+6QRzWX9XLSZNU8xMBdzQVZi6Nl2v7diQCYtcI29s1cr15tqsJ fsW+AXFIU35wFJkWAC34Ssi/l9ouE2kEQhAGt/w10PHKRAu6lXAigPA5fW73S4kxxDNh 7uTZW31/4aUSYHvp9blm1nZcw/E3srkWJtBYlY+c+8RGvusMLOFaZhlZW5o9rjVjIt5y Fd0eDcWkdOUQgnNg9OIs6cXxHM2JB2TGLYNmIq/nODK/G9+Y05CU3n2Jo6x4dMj6U1D1 ptwQ== 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=dpZRxDkhn3csIfa0U0Y1ntNxvDbRPq1GZCAw43L4SsU=; b=TgLCMXbuMMAtXl1hlYPBKrghGbOqY665vyEDq/iAQRPCt5olm4l/Ep9c8CTRg/ygYH qiKnfdYfsUbCQU6L9BJt7geNbOwO6hC/wQXpvDh+/mI1+ITAGmhkA5ektV/lel0ROrTS m0cym3PQCewNkRkJD10XFSpp2zUbRmeTfZoLz3iqNdUiG3vDjr5M0iQifxXghRNCfi4L AoPvV0hSZe5oJVE8OZVUhfhpDDcmMonTOuB9pC+sSnKX2lLucX9//cnfDC75JyubH+OE PNjDrA9FbBufeztCA4so0nJQad53iiz6c6rZlNdXZaV39ZYoO8ZRyIyFFJDAiWTOX+nz xeGA== X-Gm-Message-State: AJcUukcODaejMT6LPqLHCY9n25ENUevHUBBhKbaIAz6/3F9n92DduzgD 7NYLXQ70RFuDrhXiqx2u/O6sHJIKob0H9JV8DWTeTmyecac= X-Google-Smtp-Source: ALg8bN5zcdolgeDaJWGoquczEdKQ67kHw39jccmTtjQZrgOadGCgEHyeNRtDNQBOqbfdw58cE6fMnqZqItghx9WcPSs= X-Received: by 2002:a24:edc4:: with SMTP id r187mr5301132ith.158.1548439938062; Fri, 25 Jan 2019 10:12:18 -0800 (PST) MIME-Version: 1.0 From: Christopher Wood Date: Fri, 25 Jan 2019 10:11:48 -0800 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 18:12:23 -0000 At the TLS@IETF103 session, there was interest in adopting draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG item, provided that it's limited to external PSKs with certificates for the initial handshake. This email is to determine whether there is WG consensus to adopt this draft (as is) as a WG item. If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180208. If you are opposed to this being a WG document, please say so (and say why). Thanks, Chris, Joe and Sean From nobody Fri Jan 25 10:45:56 2019 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 7A7BB130EA3 for ; Fri, 25 Jan 2019 10:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rTFOa-zevu1A for ; Fri, 25 Jan 2019 10:45:52 -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 51C82131022 for ; Fri, 25 Jan 2019 10:45:51 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BAB6B87628; Fri, 25 Jan 2019 18:45:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id C69A23DAA; Fri, 25 Jan 2019 18:45:49 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 25 Jan 2019 19:45:43 +0100 Message-ID: <6035047.RC8yvgZ2HI@pintsize.usersys.redhat.com> In-Reply-To: References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <1548371005.3487947.1642965368.3A897C7A@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2726546.2iyKYnOi7W"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 25 Jan 2019 18:45:50 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 18:45:54 -0000 --nextPart2726546.2iyKYnOi7W Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 25 January 2019 17:23:22 CET David Benjamin wrote: > On Thu, Jan 24, 2019 at 5:03 PM Martin Thomson wrote: > > On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote: > > > > while record_size_limit extension sends just one value, it does > > > > specifically > > > > allow the client to advertise higher values than the protocol versi= ons > >=20 > > or > >=20 > > > > extensions would indicate > > > >=20 > > > > I wonder if sending such values shouldn't be part of GREASE behavio= ur, > > > > even if > > > > it wouldn't use GREASE values... > > >=20 > > > I think that should be sorted out in a separate document. This one's > > > been > > > sitting around for a while as it is, and record_size_limit doesn't ha= ve > >=20 > > an > >=20 > > > RFC to cite yet. :-) > >=20 > > I'm in two minds about this. On the one hand, we don't need any actual > > machinery here, so why do anything? On the other hand, it's just a note > > that this is possible, and adding that sort of note is easy. > >=20 > > > The record_size_limit extension {{!RFC8449}} includes a value that can > >=20 > > be greased by endpoints that don't place constraints on their record si= ze. > > Advertising values larger than the protocol supports is permitted and h= as > > no effect on the behavior of a compliant peer. >=20 > I don't feel very strongly either way, though it is odd that it basically > contradicts the sender's rules in RFC 8449. >=20 > 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. > A server MUST NOT enforce this restriction; a client might advertise > a higher limit that is enabled by an extension or version the server >=20 > It does say "unless explicitly allowed by such a future version or > extension", so this is basically blanket overruling that sentence a few > months after publication. (But overruling it isn't entirely wrong, given > the current text imposes a future-proofing receiver rule that the sender = is > forbidden from checking.) we can claim that GREASE cipher suites are signalling cipher suite value fo= r=20 this purpose ("unless explicitly allowed by (...) extension")... but my point was that to ensure future-proofing that "MUST NOT enforce" is= =20 much more important to keep flexible that to be strict ("MUST NOT send") *unless* the idea was to later create an RFC that just increases the maximu= m=20 record sizes without introducing any additional extension to signal support= =20 for it =E2=80=93 which I don't think would be safe to do =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 --nextPart2726546.2iyKYnOi7W 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+dkqjRuAHS9fUFAlxLWVcACgkQkqjRuAHS 9fXCog/8C52zdoelKVHv+f4PNihycoI8gpkLRdWBgYa0l/pDcPksNpWdg5EF77Hv Z93GA+24PQ/w4jBBsXYRNEwZ6NpfkDAGnJnByyz2vXGI5HHGwvvvKnUkEKhzTxU1 0Rxe/spMS17TLX8UAj2/pSLL6H5WAwn9LvVR/tAcC77bCOyMeMn5Mc9THm72s3wm mt17Dcd0Q5obHr2rvkifpE6oKM6fyQPIT0ehodApuB45L8cUhBecrh1JA1+/jYaV dOL7XriLBsF4adfXAP6zc07GaK2eQEvBYs+xpdip2voN0JMwtsClW8I8iiQ0grG3 RzyJB1KJnPPEoPYC7oQKQEKeXMRdCFej1U3Za2IHnbeTvWGQ74/bWf/tBWsQMzyc 1WENryQ5233D8t7P/NR5/4VhKTr8+IvJNUEcKeoS3ynU439f+La1RC14g5dye96X kqXcRuPcV4XxmuTCsNTWTUElO2Zg8N55YtFRzk9Tr83tEw9qu5pTbsmFGOeSTAyM nNsZL30A3MG24ZYTWPlUiBjMUHM9JOJx9yxLp0y4L8w/5ykC3sCFdYgF38+5q+EU vtgidUog0AUaR0NDgTTm8k7eIlOIt/dWxdC4dPEkGticSI0aF96UIFiOpQDIO9g8 +dDlVud94/8j73qipnlvdauphq1o028QucWKh9mPvcbLGmzZkgY= =3EEY -----END PGP SIGNATURE----- --nextPart2726546.2iyKYnOi7W-- From nobody Fri Jan 25 15:53:01 2019 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 0C3FB12872C for ; Fri, 25 Jan 2019 15:53: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 QQeZBk_HufcI for ; Fri, 25 Jan 2019 15:52:58 -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 2136E12426A for ; Fri, 25 Jan 2019 15:52:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C90FC300A81 for ; Fri, 25 Jan 2019 18:34:39 -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 1UC8Jpb2NIiv for ; Fri, 25 Jan 2019 18:34:38 -0500 (EST) Received: from [172.20.10.105] (rrcs-173-196-183-153.west.biz.rr.com [173.196.183.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 8BC6C300474; Fri, 25 Jan 2019 18:34:38 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Fri, 25 Jan 2019 18:52:54 -0500 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <8B65B643-211D-4AE3-9970-7639573995DF@vigilsec.com> References: To: Christopher Wood X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2019 23:53:00 -0000 Of course, I support WG adoption. And, if the document is adopted, I am = willing to continue as author. Russ > On Jan 25, 2019, at 1:11 PM, Christopher Wood = wrote: >=20 > At the TLS@IETF103 session, there was interest in adopting > draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG > item, provided that it's limited to external PSKs with certificates > for the initial handshake. This email is to determine whether there is > WG consensus to adopt this draft (as is) as a WG item. >=20 > If you would like for this draft to become a WG document and you are > willing to review it as it moves through the process, then please let > the list know by 2359UTC 20180208. If you are opposed to this being a > WG document, please say so (and say why). >=20 > Thanks, > Chris, Joe and Sean From nobody Fri Jan 25 21:38:24 2019 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 304D0128D0C for ; Fri, 25 Jan 2019 21:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffC_pyZlt_gq for ; Fri, 25 Jan 2019 21:38:20 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 BF3EC128CF3 for ; Fri, 25 Jan 2019 21:38:20 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id e12so10552347otl.5 for ; Fri, 25 Jan 2019 21:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PXe+Tze/rE2g/fy7Q8FE77LufGWw+Km0Cnq9TsjSF/Q=; b=jaAQcV6IhefpZ4LKwQj+jUgz/iQts4soZDhu/ac6E7T8igwsT8NoVTef1P0D7u5puw kePWV4REwh0vcT+aSiBeHY7Awsjgs1HOhOmcFMWEuURsnopw/Mb6nKlF065j3UGpC0jH bfT9H2hB8Nuxc4RsRYNxRbDTS/WODayh45tIo= 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=PXe+Tze/rE2g/fy7Q8FE77LufGWw+Km0Cnq9TsjSF/Q=; b=Sa6tfTN896MN4ObKKerViKps+zoZFAoKmrE5rYxGuzPbj16+T1NyCaLNGmM06klvvu TuXyB2qswsRrjOCJwX511SZkuDedNaXK6hRv5A3u3r4AYRwcq8AoOYvTQseZZVi2CS+j VyR6UL0nv39TD5rawoSypXPl8wr7lcxv2X2qM2ZdKl1aEZbyoYYVl8YINzfmtULNRx2Q 1yIp5bjA+Z8He3E9HIaHO+bP8m1kMGCbfsFUPthrsfbafF692lkaeG7sKV0AWA41ndVU rOEknwIXngIL18FErnjIlSws/X9qrCjilXAa66UH6mWyNJxJ3p+DTr37aNfd8XzNz4JE 3RLg== X-Gm-Message-State: AJcUukdv+VgwyxH1z9tv2N8m1gCeKBPN0SYvuapNuDsXT+nNIt1IYWbp S/tXiCOyD336ZtkFPiJ4tPoQ1DkHeAyOb6JfBjIUnw== X-Google-Smtp-Source: ALg8bN7sEwPzS/d2Pz4k1MqrQv97pCBp/3jO2kZrbqeQX9+mFZ8M0DroDS87pvPw2xLPYNf3dK32Gd2N6xk/7RWdG8I= X-Received: by 2002:a9d:7cd9:: with SMTP id r25mr9576347otn.110.1548481099953; Fri, 25 Jan 2019 21:38:19 -0800 (PST) MIME-Version: 1.0 References: <8B65B643-211D-4AE3-9970-7639573995DF@vigilsec.com> In-Reply-To: <8B65B643-211D-4AE3-9970-7639573995DF@vigilsec.com> From: Nick Sullivan Date: Fri, 25 Jan 2019 21:38:08 -0800 Message-ID: To: Russ Housley Cc: Christopher Wood , IETF TLS Content-Type: multipart/alternative; boundary="000000000000e79e99058055d93e" Archived-At: Subject: Re: [TLS] Call for Adoption: TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 05:38:23 -0000 --000000000000e79e99058055d93e Content-Type: text/plain; charset="UTF-8" I support adoption. On Fri, Jan 25, 2019 at 3:53 PM Russ Housley wrote: > Of course, I support WG adoption. And, if the document is adopted, I am > willing to continue as author. > > Russ > > > > On Jan 25, 2019, at 1:11 PM, Christopher Wood < > christopherwood07@gmail.com> wrote: > > > > At the TLS@IETF103 session, there was interest in adopting > > draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG > > item, provided that it's limited to external PSKs with certificates > > for the initial handshake. This email is to determine whether there is > > WG consensus to adopt this draft (as is) as a WG item. > > > > If you would like for this draft to become a WG document and you are > > willing to review it as it moves through the process, then please let > > the list know by 2359UTC 20180208. If you are opposed to this being a > > WG document, please say so (and say why). > > > > Thanks, > > Chris, Joe and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e79e99058055d93e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption.
On Fri, = Jan 25, 2019 at 3:53 PM Russ Housley <housley@vigilsec.com> wrote:
Of course, I support WG adoption.=C2=A0 And, if the document is adop= ted, I am willing to continue as author.

Russ


> On Jan 25, 2019, at 1:11 PM, Christopher Wood <christopherwood07@gmail.com> wrote:
>
> At the TLS@IETF103 session, there was interest in adopting
> draft-housley-tls-tls13-cert-with-extern-psk as an experimental WG
> item, provided that it's limited to external PSKs with certificate= s
> for the initial handshake. This email is to determine whether there is=
> WG consensus to adopt this draft (as is) as a WG item.
>
> If you would like for this draft to become a WG document and you are > willing to review it as it moves through the process, then please let<= br> > the list know by 2359UTC 20180208. If you are opposed to this being a<= br> > WG document, please say so (and say why).
>
> Thanks,
> Chris, Joe and Sean

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e79e99058055d93e-- From nobody Sat Jan 26 13:46:44 2019 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 559D11311E1 for ; Sat, 26 Jan 2019 13:46:36 -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=lowentropy.net header.b=E8tXNEZ7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I5mWeFi5 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 K4GFcuj4Of68 for ; Sat, 26 Jan 2019 13:46:34 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EC91311DA for ; Sat, 26 Jan 2019 13:46:34 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6B91B21D19; Sat, 26 Jan 2019 16:46:33 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute1.internal (MEProxy); Sat, 26 Jan 2019 16:46:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:subject:references:in-reply-to:date; s=fm1; bh=Bg0 Aj3HAKBa96iav7o9IPf6ZQl+6QLAa4BxOA1CKKRU=; b=E8tXNEZ7sSM8954VWK2 teqBsTAIuFmcQPTX5bH9ioGVlTVtROmcXkpEZYYGGHfNqNsayZaIWqWHsO77BGiS rhgLrKQpySi4WwLdEGcZOvfS1Tf7ocaYcPwhBLoKsKCV1fGIGTsBQgrz5Qfu8/mq bRKUQJPCwu7SCaK7JqqiW4L7oa4bFgvUdIt7etgEBHNYDOis7fmzQ1znZJKgVJmY nSLAIbQB4dx/clBWlOeqx4zG0cUu6ZbSuxIQOQmWPZ/BWThaER7Z+JM8AMXlaVcF dOh1uR+DCcyrxGS8/li4JRTkvJNH7amMLKr/RrEXEWbZP2tyuxb/J0S+yVmoVp1Q C9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Bg0Aj3HAKBa96iav7o9IPf6ZQl+6QLAa4BxOA1CKK RU=; b=I5mWeFi5ky31Zx8+ep+ajCrMaixE4TwhVIT5rZZdMh0sPkTC7BidI60sl tgP9u1H40QyAsoQqjG44nCGnxFSkzS+b5IHhILbdqNGxhqA2mD28ddj65SiDwJwd SDjCS37stSE8VK0O4UiEo8dCo4efmldxfg/zlZG5Vp6CKjBs5L/KoI9BEWEKB4Yu TaibKjOpTKLSk0rpi5gIr6GJBLb6Bb1ABD6YqRTF9sgXOtiqNe3sUrIhsDb14j9W ItyiCQeHv5AFF1Zsj5JnM6fU/UH/G6+t4lXGpGRjzg/RtvzLkc1okJnpL91JDpkq gWrtoNje4SwGRVWVVCsUL0TdsyuNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrieeigdduheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkhffvggfgtg foufhfjgffsehtjeertdertdejnecuhfhrohhmpeforghrthhinhcuvfhhohhmshhonhcu oehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6947762304; Sat, 26 Jan 2019 16:46:32 -0500 (EST) Message-Id: <1548539192.1596994.1644255264.04011363@webmail.messagingengine.com> From: Martin Thomson To: David Benjamin Cc: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-36e4bfd3 References: <154767032661.29586.10643059734542111710@ietfa.amsl.com> <2605372.0b8annkhzO@pintsize.usersys.redhat.com> <1548371005.3487947.1642965368.3A897C7A@webmail.messagingengine.com> In-Reply-To: Date: Sun, 27 Jan 2019 08:46:32 +1100 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 21:46:43 -0000 > I don't feel very strongly either way, though it is odd that it basically > contradicts the sender's rules in RFC 8449. > > 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. > A server MUST NOT enforce this restriction; a client might advertise > a higher limit that is enabled by an extension or version the server > > It does say "unless explicitly allowed by such a future version or > extension", so this is basically blanket overruling that sentence a few > months after publication. Yeah, it's not ideal. Given that, I'd say that we don't need to say anything. It's still safe to grease by setting smaller values, but the value in doing so is hopefully marginal. From nobody Sun Jan 27 13:52:48 2019 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 94A98130EE3; Sun, 27 Jan 2019 13:52:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, tls-chairs@ietf.org, cawood@apple.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154862596653.13429.6397446382615490041.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2019 13:52:46 -0800 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 104 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 21:52:47 -0000 A new meeting session request has just been submitted by Christopher A. Wood, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: acme cfrg curdle dispatch httpbis mls perc quic rtcweb stir saag secdispatch suit taps teep tokbind uta Second Priority: dprive ace Third Priority: tcpinc lamps sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 27 15:47:24 2019 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 ABD40124BF6; Sun, 27 Jan 2019 15:47:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, tls-chairs@ietf.org, cawood@apple.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154863284266.13246.9146760438169453844.idtracker@ietfa.amsl.com> Date: Sun, 27 Jan 2019 15:47:22 -0800 Archived-At: Subject: [TLS] tls - Update to a Meeting Session Request for IETF 104 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2019 23:47:23 -0000 An update to a meeting session request has just been submitted by Christopher A. Wood, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: acme cfrg curdle dispatch dnsop httpbis mls perc quic rtcweb stir saag secdispatch suit taps teep tokbind uta Second Priority: dprive ace Third Priority: tcpinc lamps sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jan 28 17:20:05 2019 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 F0406126DBF for ; Mon, 28 Jan 2019 17:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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=apple.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 3qO_S2e57-xC for ; Mon, 28 Jan 2019 17:20:02 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960C9126CB6 for ; Mon, 28 Jan 2019 17:20:02 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x0T1HF3V009214 for ; Mon, 28 Jan 2019 17:20:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : content-transfer-encoding : subject : message-id : date : to; s=20180706; bh=PF8+TMV8bQqxzXHwdQTP5ZjNb6Te7sF44BtufSgRMUE=; b=jw2YwIyJd0VyF7hpjqay8+eFnUoIE1Y0QLuh+VpbYgD5mjvGzOMCuLX7woWupb09Y0Kp zAyEFV9ZB20TAzqf1TuO0yM/uPVyCbnQR7Mc6npI9/1Mvjq/ATj1P2NNSIn1Ie2KyMFk fOEnud0mwDTfgsxeUJbYaYa7aazrJwVpIS5JF2cd0TaI1KloWRPYmELjorqGYV3//TCk HxedfWZwx8ORfry9jXebWPd8/d9TK5XjldcYoWdnrdKaOgqKoVJvjbqzCReshps5Pltr PNYaY8UhVsapBWx7jdF5Ehrwl1T37rX51hDDkyfHM8dunhEMX3XmZEf+BjhIa9pD9EA7 eg== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2q8n0r7kav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 28 Jan 2019 17:20:02 -0800 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PM200MWBJPD4M50@ma1-mtap-s02.corp.apple.com> for tls@ietf.org; Mon, 28 Jan 2019 17:20:01 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PM200L00JJKSD00@nwk-mmpp-sz13.apple.com> for tls@ietf.org; Mon, 28 Jan 2019 17:20:01 -0800 (PST) X-Va-A: X-Va-T-CD: 6b43b320ab324d5737d05a4f03df4db2 X-Va-E-CD: 7c2085acdb00142f400dc09a9547f013 X-Va-R-CD: 427f461699623c3ac52db8f64daf858f X-Va-CD: 0 X-Va-ID: 0c923d8c-e77f-449b-b216-90150dcf41c7 X-V-A: X-V-T-CD: 6b43b320ab324d5737d05a4f03df4db2 X-V-E-CD: 7c2085acdb00142f400dc09a9547f013 X-V-R-CD: 427f461699623c3ac52db8f64daf858f X-V-CD: 0 X-V-ID: 310d295d-b799-4f73-81e9-fbf6991fc85c Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PM200K00JHTLR00@nwk-mmpp-sz13.apple.com> for tls@ietf.org; Mon, 28 Jan 2019 17:20:01 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-29_01:,, signatures=0 Received: from [17.234.77.73] (unknown [17.234.77.73]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PM2009RDJPCEL10@nwk-mmpp-sz13.apple.com> for tls@ietf.org; Mon, 28 Jan 2019 17:20:01 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-transfer-encoding: quoted-printable Message-id: <8748BBB5-0402-4950-9F1A-3B76F3C34CAE@apple.com> Date: Mon, 28 Jan 2019 17:19:53 -0800 To: "tls@ietf.org" X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-29_01:, , signatures=0 Archived-At: Subject: [TLS] TLS 1.3 in iOS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 01:20:04 -0000 Hi all, Last week, we shipped the first developer seed of iOS 12.2. Among other = features, TLS 1.3 is now enabled by default for the entire system. All = users of Network.framework and NSURLSession APIs will now negotiate TLS = 1.3. The number of TLS 1.3 capable clients on the Internet should take = quite a leap forward, and we are pleased to help move the needle towards = faster and more secure network connections.=20 We'd like to thank the members of this working group, and Eric Rescorla = in particular, for all the work put into this protocol and its = deployment on the Internet. Enjoy! =E2=80=94Tommy= From nobody Mon Jan 28 21:42:54 2019 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 7F5D6130EDE for ; Mon, 28 Jan 2019 21:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, 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=fb.com header.b=F7h+LJsJ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=gYbFAglG 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 8lontBsYU4kQ for ; Mon, 28 Jan 2019 21:42:51 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D526B130EA4 for ; Mon, 28 Jan 2019 21:42:50 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0T5gnsk019701 for ; Mon, 28 Jan 2019 21:42:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=PQcZFB3iBu56bF7GpO//RTkr8Z04GjaxEvvbnxehZok=; b=F7h+LJsJOAWCh6nDvLya3H0uzn64bVWuX7Wy0CE9N2zpYgBPE7jS3Y4ZgOoS4RyXGSA3 5uL9u85AigkiICedqaxOJlpZi2HDD4lnDMprmKdWqnEgkdwiOGPTqX6HkyoaLgeMdb1l kGo+6xjy0qXHQlT+oSijlKM5CTZU/s3Es84= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qaewg89mn-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 28 Jan 2019 21:42:50 -0800 Received: from prn-hub02.TheFacebook.com (2620:10d:c081:35::126) by prn-hub04.TheFacebook.com (2620:10d:c081:35::128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 28 Jan 2019 21:42:44 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Mon, 28 Jan 2019 21:42:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PQcZFB3iBu56bF7GpO//RTkr8Z04GjaxEvvbnxehZok=; b=gYbFAglGzf5JZsDIuyTO4vjT+eHq6XZZMgxVvfJLDsENasdnFjAz871Dohrykt6HmxX3PznS2ll/Negm9MByCdn8qLXGbvNPOZKygGN0oUU7p0HkL4ISkePibedPzeQEGiPzqignytqFiYilQoJqFProM5qy5dCDNAU8NXkOVlQ= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1549.namprd15.prod.outlook.com (10.173.235.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Tue, 29 Jan 2019 05:42:43 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b%7]) with mapi id 15.20.1558.023; Tue, 29 Jan 2019 05:42:43 +0000 From: Subodh Iyengar To: "tls@ietf.org" Thread-Topic: ticket lifetimes Thread-Index: AQHUt5PbJPg1BCv4IU2K+uhv0WevMg== Date: Tue, 29 Jan 2019 05:42:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.93.142.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1549; 20:jqRE+ja44JvhZ/okVvq5Ze6D1H/zHGtwDDAiEJzkZi4tu9GstyLj9/radYzjhA5CMecJrefS0NtfupynrfPrchxC2d4cLD3DNz0FFIcP+bmi/pE0klP6FHLpNcZqCcMc6XR1EyRKUad0VWg9ZZYiS7aYXEBE6sWXtQt/+/C/QWo= x-ms-office365-filtering-correlation-id: 1176cbcd-b0a6-4bee-93a0-08d685ac970a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1549; x-ms-traffictypediagnostic: MWHPR15MB1549: x-microsoft-antispam-prvs: x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(346002)(366004)(136003)(199004)(189003)(1730700003)(3480700005)(71190400001)(8676002)(186003)(99286004)(81166006)(71200400001)(3846002)(86362001)(7696005)(102836004)(221733001)(476003)(105004)(2351001)(26005)(316002)(6506007)(66066001)(8936002)(486006)(5640700003)(55016002)(81156014)(7736002)(19627405001)(33656002)(256004)(14444005)(105586002)(7116003)(6436002)(106356001)(6916009)(54896002)(68736007)(6116002)(14454004)(53936002)(9686003)(2906002)(2501003)(97736004)(74316002)(25786009)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1549; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2FxADNHbfJJY26BNQwksoRYRF+9QXRvvyvVCxMmINjl0/X8SGvSkIMdjSKAZWmN7BK/ailbL4k63JlSQ8pFg//XmIPCjGcShfvQH98VT8iD6X/gbbMsd+QstDEPiHgcc2uboWv5qvziR+4sRd4C3r+R5FTTNEUuMVgrQdoASncbWdaqwvApEtwHh+/2DszPIxawGgkZIHa2vs4IanzGPWLtpYsChOAqbhdzrsFJlCCaBrAALbJpP2BgWTnD5lksrxoROGQNhYunsaEmo+vxAZBopNrg0glNN+fqfPIEtPkIylZqSyWsbbGObZwf0d64h/vIbZMgXyMgc8V5mkGZJ4MjEAjpfhJgwYm2x8EEyoYNd3rBAnt9tAV+z/uRG7M/INKpuPGm4dPvDFj2IY1WULtg7WjUkGFhj+H8j7wgtPU8= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB182191E96C1A065B2396318EB6970MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1176cbcd-b0a6-4bee-93a0-08d685ac970a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2019 05:42:43.2244 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1549 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-29_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 05:42:52 -0000 --_000_MWHPR15MB182191E96C1A065B2396318EB6970MWHPR15MB1821namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This= had several original motivations including reducing the time that a ticket= is reused (for privacy or PFS). Another major motivation for this was to l= imit the exposure of servers that use keyless ssl like mechanisms, i.e. if = they kept a STEK locally, but the keyless SSL server remotely, then the the= ft of a STEK would presumably limit the MITM capabilities to the ticket lif= etime. However thinking about it some more because of the renewal capability of ti= ckets in TLS 1.3, an entity owning the STEK could just re-issue new tickets= forever on a resumed connection. This would look to the client as a new ti= cket and it would refresh its lifetime on the ticket. Thereby a MITM could = intercept connections to users that have been to the server with the STEK. = I'm wondering whether it might be useful to define a mechanism to limit the= lifetime of all ticket resumption across all resumptions from the original= connection instead of just the limited per ticket lifetime. Subodh --_000_MWHPR15MB182191E96C1A065B2396318EB6970MWHPR15MB1821namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This= had several original motivations including reducing the time that a ticket= is reused (for privacy or PFS). Another major motivation for this was to l= imit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, but the= keyless SSL server remotely, then the theft of a STEK would presumably lim= it the MITM capabilities to the ticket lifetime. 

However thinking about it some more because of the renewal capability of ti= ckets in TLS 1.3, an entity owning the STEK could just re-issue new tickets= forever on a resumed connection. This would look to the client as a new ti= cket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to users that ha= ve been to the server with the STEK. I'm wondering whether it might be usef= ul to define a mechanism to limit the lifetime of all ticket resumption acr= oss all resumptions from the original connection instead of just the limited per ticket lifetime.

Subodh


--_000_MWHPR15MB182191E96C1A065B2396318EB6970MWHPR15MB1821namp_-- From nobody Mon Jan 28 21:58:01 2019 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 065E6130F46 for ; Mon, 28 Jan 2019 21:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 awzQIAcL_l_6 for ; Mon, 28 Jan 2019 21:57:54 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 48AE8130F21 for ; Mon, 28 Jan 2019 21:57:54 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id s17so7735886ybp.6 for ; Mon, 28 Jan 2019 21:57:54 -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:content-transfer-encoding; bh=g2KRbca2S37I2tEk+ulLJ+izSFGr64NQd6PRKnu5maw=; b=mTZqSeb7iTQcA4pBjKrhIiHTWrFFHwC2Cwnd7p323YTgoAi0tUArq4+P7A/BqjnVRI twowOpv3nIn2kPXz3JdO3EFrGy1XzHr8DfnHrxz0BZNWQufEDBmvTbOv54SovllN/Duo dwdI7ENJKMToqHYxCIoMHwCI9orKa+kJHDJxv8Yr+k4enY6sfAa+oRmBsg9Si4qnSIHL xTBVAGUklu52bjN7XCUZPXiALRIZl0ld6CbA0inRyf15plazjOqWZzAmUfa5a6Ccq1iV ZZIE5jvWXXourT3kw8HokXEUZ9IjqYJsvXyq4Q1SjDfYV3XEcsp1c1qBt97gm+whzYzY yD7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g2KRbca2S37I2tEk+ulLJ+izSFGr64NQd6PRKnu5maw=; b=NFaNaTX3xCVV/tvJJWv3ZXm/X9Gt0wwP7tRbxLryjQwy1yC6cL9Ng6C772bOI4t0OI zGc/13AoTlhMAsJF8moK7wEem4V1ryEXK/rih0pU4/KxlqQvFE5Zy8Srm9moW39XnNnm zx+lPNK1rsQTe+hwA3WUhxRVg1qF7WiUvtOQ3xfaNap4TtduNE1NVK5Y+HwLC0f9/Xqj u4x6R+9yOj4XEztlJR4mVov5bLsQSLNdDvsJX82eA7SDeHH84ensbj1BaDIrHLBz2ujN KQkedbd9MAPJ9PwNADagBhm9uIDPj5TlGBgxt6xaDzZTnW/vz+klRo1vNAGldFocU7D7 d89A== X-Gm-Message-State: AHQUAuZK1/KCvrNRWOuoZKUoeVyBIxTuxlHlTkTJf5OphaB7Vo2mqXJS /ClMLrHLCwY/h6tJfm9pFhMqnBPuhzpK10J+rhw= X-Google-Smtp-Source: AHgI3IZzRTnp7quR6FtBAooL+y6c74kcKHzuARMv+5EuUzjL2qPhTD41pOgSYdN65ZV1D/qBq2T+NJcUI2VVM4oXt2E= X-Received: by 2002:a5b:890:: with SMTP id e16mr9681481ybq.310.1548741473289; Mon, 28 Jan 2019 21:57:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Mon, 28 Jan 2019 21:57:21 -0800 Message-ID: To: Subodh Iyengar Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 05:58:00 -0000 On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. Th= is had several original motivations including reducing the time that a tick= et is reused (for privacy or PFS). Another major motivation for this was to= limit the exposure of servers that use keyless ssl like mechanisms, i.e. i= f they kept a STEK locally, but the keyless SSL server remotely, then the t= heft of a STEK would presumably limit the MITM capabilities to the ticket l= ifetime. > > However thinking about it some more because of the renewal capability of = tickets in TLS 1.3, an entity owning the STEK could just re-issue new ticke= ts forever on a resumed connection. This would look to the client as a new = ticket and it would refresh its lifetime on the ticket. Thereby a MITM coul= d intercept connections to users that have been to the server with the STEK= . I'm wondering whether it might be useful to define a mechanism to limit t= he lifetime of all ticket resumption across all resumptions from the origin= al connection instead of just the limited per ticket lifetime. Since clients already store tickets, could they not also store the time of original ticket issuance and cap the resumption window to N (7) days from that point? That is, it seems clients could implement this behavior without any protocol support. Best, Chris From nobody Mon Jan 28 22:04:57 2019 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 0CF06130EF5 for ; Mon, 28 Jan 2019 22:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, 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=fb.com header.b=OycAkONh; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=X15Txbne 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 ZVpUWhTQ8BXu for ; Mon, 28 Jan 2019 22:04:53 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADE6130EF3 for ; Mon, 28 Jan 2019 22:04:52 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0T63O7w009964; Mon, 28 Jan 2019 22:04:51 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=RHDXjW6FAg/LuJnDE3h1/jVtED8dKLdB0QOUMTV+ts4=; b=OycAkONhAvRyY3NWYeStbbqo8dNzAIUMiokHyj9UGYNBRksIRWPbMwZD7HnAIo6YDTtk cvckbNX+4VBh7g3ENeQamVHx8JSj0akJYC7HflYVoDjUDXN3ExRyESuRaY5x653G1F3G VqqCoR2f+bwuKo9Q5wk9eeYZqa7CbC9VfVU= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qafam8950-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 28 Jan 2019 22:04:51 -0800 Received: from frc-mbx04.TheFacebook.com (192.168.155.19) by frc-hub06.TheFacebook.com (192.168.177.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 28 Jan 2019 22:04:51 -0800 Received: from frc-hub04.TheFacebook.com (192.168.177.74) by frc-mbx04.TheFacebook.com (192.168.155.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Mon, 28 Jan 2019 22:04:50 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Mon, 28 Jan 2019 22:04:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RHDXjW6FAg/LuJnDE3h1/jVtED8dKLdB0QOUMTV+ts4=; b=X15TxbneogRE3quYX20J1ZWOUA8Z/R7ED9TixhzjGwWqmGnK77m6HsYNWqstiAHDJ5RdKRSyFxh/21q6+Vo18/TsTx7lSvgkL9p7CHFSQAAUCg57l+trtfom99/nDxCydkwnU7QLCR+RKOdRm9paqF85kboDnQcA70MsyzeHK6o= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1231.namprd15.prod.outlook.com (10.175.2.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Tue, 29 Jan 2019 06:04:50 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b%7]) with mapi id 15.20.1558.023; Tue, 29 Jan 2019 06:04:49 +0000 From: Subodh Iyengar To: Christopher Wood CC: "tls@ietf.org" Thread-Topic: [TLS] ticket lifetimes Thread-Index: AQHUt5PbJPg1BCv4IU2K+uhv0WevMqXFv9eAgAAArOY= Date: Tue, 29 Jan 2019 06:04:49 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.93.142.132] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1231; 20:IMB1WAz8CaGv9qgvTfmAzotxEeXoV+R0/YJhk/C28rIZBPxYBweXo+swhkHU+1nx50bmMwJzxhVf8Kvbg+0tbW8wdGue+XVSaHYNPv6I89y3PM+s5teQLGbU5d9rYwSfSIBEbVVrlV8bU6xQ9q8GDUD66LICMHtzu29AaE7SAMY= x-ms-office365-filtering-correlation-id: 29c11691-98fb-49c4-6c5b-08d685afadba x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1231; x-ms-traffictypediagnostic: MWHPR15MB1231: x-microsoft-antispam-prvs: x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(136003)(346002)(39860400002)(189003)(199004)(14454004)(106356001)(2906002)(39060400002)(4326008)(19627405001)(25786009)(9686003)(74316002)(6916009)(97736004)(54896002)(33656002)(6116002)(478600001)(6246003)(105586002)(66066001)(53936002)(6436002)(55016002)(8676002)(8936002)(81166006)(1411001)(7696005)(7736002)(229853002)(256004)(3846002)(71200400001)(71190400001)(81156014)(14444005)(316002)(86362001)(26005)(486006)(105004)(68736007)(11346002)(99286004)(476003)(446003)(186003)(53546011)(102836004)(76176011)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1231; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 45TsVWCZ95FPfIvHIlgo/ZflFmBN1aWhfHNsDNNtWBBW6vDHRk24I0OWWXcIc3ySmD627EgpRBzEWqEDcV2cZUihtLmplrUEN4D/GvpyeRQ8N4LQ9D1+pTolv9mcjhOGQJ1xBdpSVQiSNOkl37h3BOjTI4FsaV7ioOh/kgpYNtGo4f9ImIBK93mwJoyce7BHWCu00ThFIjknNGTvRIIu5CLa8jxpZJHrO5gOogybA33I+cgfw9QHdei9W5IWo6WPhDaLOh9bZkDTq2mC2OpU2q3UUTQ3PYNAfQfp9MncwqYvExl5Utl6gljMtAMe8mY48jS/ZoWXCqLnJE9sYo1mxuepDY8j2wcWnBFpbP8CIAJLwb/7TKJcr+IJLy5m7xaw7ylyheYa3ZHV/27GGqlhXocnq77jcUYja35lnPfqLM0= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821FCD14D0DBFDE0A1D8617B6970MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 29c11691-98fb-49c4-6c5b-08d685afadba X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2019 06:04:49.7919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1231 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-29_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 06:04:55 -0000 --_000_MWHPR15MB1821FCD14D0DBFDE0A1D8617B6970MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Since clients already store tickets, could they not also store the time of original ticket issuance and cap the resumption window to N (7) days from that point? That is, it seems clients could implement this behavior without any protocol support. Correct, however the server currently provides a value for this, and client= s do not enforce a lower bound on this. 7 days is an upper bound. Servers would provide a much lower value than 7 days practically. If I'm understanding your suggestion correctly, you're suggesting that clie= nts change the meaning of ticket_lifetime_hint? That is not just limit it to the scope of the ticket but the entire TLS ses= sion? That would be fine to by me, however might break some folks. Subodh ________________________________ From: Christopher Wood Sent: Monday, January 28, 2019 9:57 PM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] ticket lifetimes On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. Th= is had several original motivations including reducing the time that a tick= et is reused (for privacy or PFS). Another major motivation for this was to= limit the exposure of servers that use keyless ssl like mechanisms, i.e. i= f they kept a STEK locally, but the keyless SSL server remotely, then the t= heft of a STEK would presumably limit the MITM capabilities to the ticket l= ifetime. > > However thinking about it some more because of the renewal capability of = tickets in TLS 1.3, an entity owning the STEK could just re-issue new ticke= ts forever on a resumed connection. This would look to the client as a new = ticket and it would refresh its lifetime on the ticket. Thereby a MITM coul= d intercept connections to users that have been to the server with the STEK= . I'm wondering whether it might be useful to define a mechanism to limit t= he lifetime of all ticket resumption across all resumptions from the origin= al connection instead of just the limited per ticket lifetime. Since clients already store tickets, could they not also store the time of original ticket issuance and cap the resumption window to N (7) days from that point? That is, it seems clients could implement this behavior without any protocol support. Best, Chris --_000_MWHPR15MB1821FCD14D0DBFDE0A1D8617B6970MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> Since clie= nts already store tickets, could they not also store the
time of origina= l ticket issuance and cap the resumption window to N
(7) days from that point? That is, it seems clients could implement
this behavior without any protocol support.

Correct, however the server currently provides a value for this, and client= s do not enforce a lower bound on this. 7 days is an upper bound. 
Servers would provide a much lower value tha= n 7 days practically. 

If I'm understanding your suggestion correct= ly, you're suggesting that clients change the meaning of ticket_lifetime_hi= nt?
That is not just limit it to the scope of th= e ticket but the entire TLS session? That would be fine to by me, however m= ight break some folks.

Subodh
From: Christopher Wood <= christopherwood07@gmail.com>
Sent: Monday, January 28, 2019 9:57 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
 
On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <= ;subodh@fb.com> wrote:
>
> In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days.= This had several original motivations including reducing the time that a t= icket is reused (for privacy or PFS). Another major motivation for this was= to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, but the= keyless SSL server remotely, then the theft of a STEK would presumably lim= it the MITM capabilities to the ticket lifetime.
>
> However thinking about it some more because of the renewal capability = of tickets in TLS 1.3, an entity owning the STEK could just re-issue new ti= ckets forever on a resumed connection. This would look to the client as a n= ew ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it migh= t be useful to define a mechanism to limit the lifetime of all ticket resum= ption across all resumptions from the original connection instead of just the limited per ticket lifetime.
Since clients already store tickets, could they not also store the
time of original ticket issuance and cap the resumption window to N
(7) days from that point? That is, it seems clients could implement
this behavior without any protocol support.

Best,
Chris
--_000_MWHPR15MB1821FCD14D0DBFDE0A1D8617B6970MWHPR15MB1821namp_-- From nobody Mon Jan 28 22:14:12 2019 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 D88A3130EFC for ; Mon, 28 Jan 2019 22:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 W5HZhvAxUeOJ for ; Mon, 28 Jan 2019 22:14:08 -0800 (PST) Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 64DC4130EF5 for ; Mon, 28 Jan 2019 22:14:08 -0800 (PST) Received: by mail-yw1-xc2e.google.com with SMTP id d190so7773757ywb.5 for ; Mon, 28 Jan 2019 22:14:08 -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:content-transfer-encoding; bh=0WzYUFeEZBaS3Ns6Y0iVirW5hq8lk6KLGMYnSGKANd4=; b=i4j7Sp0Sjh+2MRaJRrZJhfN8xpaPN0SS7ZXBQwNx/YIoRddkwwTS4M85/+V0TcWBzM k0rNh88eeaAg+8Cplt9QGOEthkSVzFVHBnrjbELZjHy9e9peldj++gDs3srxyBIGgOQR TxUuNN3SrepWRKCIIHoHJ8ycj9BwV5YuDhhRByAtfDosWB1zqEmZgZEAnNekiI7bb0dB ZKHI/JHJSsIlaleJObg7TjSIzhSZ7zDwPKnl6eIV+cw2tsGVi/wWj9NWsg+nwCW1FYpP FPV9NO/iC6i2bdxmECZvSOvT/j9SRGvWI705r+kYguhgVKISSYWPrxOVKzJRWcOUATO+ T+LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0WzYUFeEZBaS3Ns6Y0iVirW5hq8lk6KLGMYnSGKANd4=; b=g1M7a5PwjaxIPOJ4M1sr0CdUP+J6fHcg/VzXVxjux5eUAXqZwAZGDUiBBTt1iAzbIk xRMvzJ0VzLxFxmSyK+nd2NV0XMLhaMqrqt7aogjrH88D4SyjpVP07xQN4DcQOD5U54yb K/EmUXQwIohCR7xqNkNfSinlaX/rSaoYjdHxMyGfooPOovf++lWQaoOEFAGjuQzoRRxJ /20QsYQPFh+6hkA+NKtluo2XuIPiiY4sJxqIKWS/5ZCNhrTIMTkLEqmpqAYz/UZHFnf/ 4e7c848quToNe/+40WVbizRbppmRKlhk6VamV/rCfXX7f8x008skW7bHK1WmlwZiea48 rPMQ== X-Gm-Message-State: AJcUukdK9iTohCuPE8sUHnMlno7yxaOLCvZOLqHiGvkKZQDsI5LosobX 2x8g9Ucs07zZgJYZNp4OoQm40f3sB4HV+K0b/ho= X-Google-Smtp-Source: ALg8bN49ZLdsayEBYTFvC2jBnd0IxQ8aNTg29RF2Axox97GJ/9Lqkm5/r2nIHSgU4pww57gIJA4GhiSYCltKNQbAYGo= X-Received: by 2002:a0d:c0c1:: with SMTP id b184mr24054374ywd.263.1548742447449; Mon, 28 Jan 2019 22:14:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Mon, 28 Jan 2019 22:13:36 -0800 Message-ID: To: Subodh Iyengar Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 06:14:10 -0000 On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: > > > Since clients already store tickets, could they not also store the > time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support. > > Correct, however the server currently provides a value for this, and clie= nts do not enforce a lower bound on this. 7 days is an upper bound. > Servers would provide a much lower value than 7 days practically. > > If I'm understanding your suggestion correctly, you're suggesting that cl= ients change the meaning of ticket_lifetime_hint? > That is not just limit it to the scope of the ticket but the entire TLS s= ession? That would be fine to by me, however might break some folks. If by "entire TLS session" you mean the resumed (and renewed) sessions, then yep! Best, Chris > > Subodh > ________________________________ > From: Christopher Wood > Sent: Monday, January 28, 2019 9:57 PM > To: Subodh Iyengar > Cc: tls@ietf.org > Subject: Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. = This had several original motivations including reducing the time that a ti= cket is reused (for privacy or PFS). Another major motivation for this was = to limit the exposure of servers that use keyless ssl like mechanisms, i.e.= if they kept a STEK locally, but the keyless SSL server remotely, then the= theft of a STEK would presumably limit the MITM capabilities to the ticket= lifetime. > > > > However thinking about it some more because of the renewal capability o= f tickets in TLS 1.3, an entity owning the STEK could just re-issue new tic= kets forever on a resumed connection. This would look to the client as a ne= w ticket and it would refresh its lifetime on the ticket. Thereby a MITM co= uld intercept connections to users that have been to the server with the ST= EK. I'm wondering whether it might be useful to define a mechanism to limit= the lifetime of all ticket resumption across all resumptions from the orig= inal connection instead of just the limited per ticket lifetime. > > Since clients already store tickets, could they not also store the > time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support. > > Best, > Chris From nobody Tue Jan 29 10:59:41 2019 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 DBAEF130FC7 for ; Tue, 29 Jan 2019 10:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.414 X-Spam-Level: X-Spam-Status: No, score=-4.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, KHOP_DYNAMIC=2, 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=fb.com header.b=HIb1Cbtu; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UdIxx6c7 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 EwJNwXbJPAwk for ; Tue, 29 Jan 2019 10:59:38 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 13410130FC2 for ; Tue, 29 Jan 2019 10:59:37 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0TIu3iK013527; Tue, 29 Jan 2019 10:59:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=NSxSz1Vj+UBvuIFTg+pnstrfm7AMZAaUAqPZS5v7XgU=; b=HIb1CbtuhOoUkSFcUyExuDab47/861vxRYm6Yab1Rg87x/kOlZ4WWxq9bYLcKMvAVtxY AiY+am3hnC53oyEK8av3MTf1QQLmlrsjtcDtxXh+fTh2729wVaTmnWqvAcLlvvgrvGZs bCl9QWEx5pu36VY8strj2awHFl3nXlaHt9U= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qatt80exy-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jan 2019 10:59:37 -0800 Received: from frc-hub05.TheFacebook.com (2620:10d:c021:18::175) by frc-hub06.TheFacebook.com (2620:10d:c021:18::176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 29 Jan 2019 10:59:34 -0800 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 29 Jan 2019 10:59:34 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NSxSz1Vj+UBvuIFTg+pnstrfm7AMZAaUAqPZS5v7XgU=; b=UdIxx6c7/RCFHnVVVlggF1v0auGBDmPDyu5Q8FMWGxNkGJyrvn5D+Y9JjypOibEr6QSvnTQrcGs/6n3Y/rOhH5ivQl19UtjQkQP4V5PKFdTnuC08El3w8QpHuqsqchPXuIl1m8vSA/MeakAqKWRLa9liDDxMW4b4Fh80IAWIMSU= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1869.namprd15.prod.outlook.com (10.174.100.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.16; Tue, 29 Jan 2019 18:59:33 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b%7]) with mapi id 15.20.1558.023; Tue, 29 Jan 2019 18:59:33 +0000 From: Subodh Iyengar To: Christopher Wood CC: "tls@ietf.org" Thread-Topic: [TLS] ticket lifetimes Thread-Index: AQHUt5PbJPg1BCv4IU2K+uhv0WevMqXFv9eAgAAArOaAAAPeAIAA1cE8 Date: Tue, 29 Jan 2019 18:59:33 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:ac11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1869; 20:dclANwvnS7dqS7/Aovxlnd2DyLYbG6CuwxXh6D5zYAQ+fIrPtenECt/E2UToc+QEdY2Yhdk6DOqH4UFzC7BPpppsT94JClXJDHftQv4xDF7pfDNTPR0tBqxBUOU0xEuqlghUI47rw2LJGvguKwF6vTbeLy3TqU1agHMnSdcf+mc= x-ms-office365-filtering-correlation-id: f9349dcd-73f6-4f5c-3a2e-08d6861be7fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1869; x-ms-traffictypediagnostic: MWHPR15MB1869: x-microsoft-antispam-prvs: x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(376002)(39860400002)(346002)(51444003)(189003)(199004)(256004)(4326008)(229853002)(97736004)(14454004)(93886005)(68736007)(446003)(14444005)(11346002)(476003)(99286004)(33656002)(19627405001)(46003)(76176011)(106356001)(186003)(7696005)(105586002)(6606003)(6246003)(478600001)(1411001)(6916009)(486006)(316002)(2906002)(55016002)(102836004)(53936002)(71200400001)(39060400002)(74316002)(8676002)(81166006)(71190400001)(25786009)(7736002)(6506007)(54896002)(81156014)(86362001)(9686003)(6436002)(6116002)(53546011)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1869; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rRxVjAwbiuwfbmoJhenSh/H3YbQYMn/4Uc7bAOMV15FOSk4Nkt72vwk9WZHvWfViLBgwQn95TDYvnQRjbq7rZHsnkWS9jer5eW/l0uKR7aia+Xxd6RZrLT82AKSC/QecjEv8HTMGg7AyGlbjzZ0l6HqhNzULZqWIpDOIWl6liZl2U+Vio4o48CxU7oNfKQnknGaS62LsYVAG6HmM98B0pDNK0NjutR3EDODkDMMNG6jLOGz85sju3D6gt+BIFRjIEpzn/1wgSWKBFUvDl230Ydye52dioIDivbYpLkXRicuy/ourDFDzadnXnNlWMEZGfXEpeAzgsPT8yTjaRpIoa5B6Dg4JT1cYTBfuCp7Avalsg+4bvTu9q4xkm+xUW2qWVsVWVbw6a0X3sAQXRqHFoSUw0UMqZ8SEu0LKQ+OJWSU= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1821F11E2B857B4DE5B21CF6B6970MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f9349dcd-73f6-4f5c-3a2e-08d6861be7fb X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2019 18:59:33.1556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1869 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-29_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 18:59:41 -0000 --_000_MWHPR15MB1821F11E2B857B4DE5B21CF6B6970MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > If by "entire TLS session" you mean the resumed (and renewed) sessions, then yep! Ya I think that'd need a new draft either way. Can definitely write that up if people don't think it's the worst idea in the world. Subodh ________________________________ From: Christopher Wood Sent: Monday, January 28, 2019 10:13:36 PM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] ticket lifetimes On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: > > > Since clients already store tickets, could they not also store the > time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support. > > Correct, however the server currently provides a value for this, and clie= nts do not enforce a lower bound on this. 7 days is an upper bound. > Servers would provide a much lower value than 7 days practically. > > If I'm understanding your suggestion correctly, you're suggesting that cl= ients change the meaning of ticket_lifetime_hint? > That is not just limit it to the scope of the ticket but the entire TLS s= ession? That would be fine to by me, however might break some folks. If by "entire TLS session" you mean the resumed (and renewed) sessions, then yep! Best, Chris > > Subodh > ________________________________ > From: Christopher Wood > Sent: Monday, January 28, 2019 9:57 PM > To: Subodh Iyengar > Cc: tls@ietf.org > Subject: Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. = This had several original motivations including reducing the time that a ti= cket is reused (for privacy or PFS). Another major motivation for this was = to limit the exposure of servers that use keyless ssl like mechanisms, i.e.= if they kept a STEK locally, but the keyless SSL server remotely, then the= theft of a STEK would presumably limit the MITM capabilities to the ticket= lifetime. > > > > However thinking about it some more because of the renewal capability o= f tickets in TLS 1.3, an entity owning the STEK could just re-issue new tic= kets forever on a resumed connection. This would look to the client as a ne= w ticket and it would refresh its lifetime on the ticket. Thereby a MITM co= uld intercept connections to users that have been to the server with the ST= EK. I'm wondering whether it might be useful to define a mechanism to limit= the lifetime of all ticket resumption across all resumptions from the orig= inal connection instead of just the limited per ticket lifetime. > > Since clients already store tickets, could they not also store the > time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support. > > Best, > Chris --_000_MWHPR15MB1821F11E2B857B4DE5B21CF6B6970MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> If by "entire TLS session&= quot; you mean the resumed (and renewed)
sessions, then yep!

Ya I think that'd need a new draft either way. Can definitely wri= te that up
if people don't think it's the worst idea in the world.

Subodh
From: Christopher Wood <= christopherwood07@gmail.com>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
 
On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar &l= t;subodh@fb.com> wrote:
>
> > Since clients already store tickets, could they not also store th= e
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and c= lients do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggesting that= clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TL= S session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________________________________
> From: Christopher Wood <christopherwood07@gmail.com>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> w= rote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 = days. This had several original motivations including reducing the time tha= t a ticket is reused (for privacy or PFS). Another major motivation for thi= s was to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, bu= t the keyless SSL server remotely, then the theft of a STEK would presumabl= y limit the MITM capabilities to the ticket lifetime.
> >
> > However thinking about it some more because of the renewal capabi= lity of tickets in TLS 1.3, an entity owning the STEK could just re-issue n= ew tickets forever on a resumed connection. This would look to the client a= s a new ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it migh= t be useful to define a mechanism to limit the lifetime of all ticket resum= ption across all resumptions from the original connection instead of just the limited per ticket lifetime. >
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Best,
> Chris
--_000_MWHPR15MB1821F11E2B857B4DE5B21CF6B6970MWHPR15MB1821namp_-- From nobody Tue Jan 29 12:18:33 2019 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 B2245130FF2 for ; Tue, 29 Jan 2019 12:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPjW4hmDDb85 for ; Tue, 29 Jan 2019 12:18:27 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::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 75C60130EAE for ; Tue, 29 Jan 2019 12:18:27 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id r62so17331653oie.1 for ; Tue, 29 Jan 2019 12:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cbx/94Co4E90W7epMzLCfR927NLe1J75PESfwj+JCIg=; b=xDCLAvSdM3rzA8axzvPaJZUdCllISEg/DvjD+rUWMd4OlW5EJlEpKg0PrEe/nj73/R VmyVRHbNYK0OR72xzGb/rhveSChV5y2Y11vZecTHU+qmSw9xzpmWHQmoV4N/OSoSjYaF qm5Vsm8wCqfv4tFQrTE4Wp0U0KOM87JNqmCAI= 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=Cbx/94Co4E90W7epMzLCfR927NLe1J75PESfwj+JCIg=; b=OxVfg4LkAt7BhIuPtSw7Y7RnsJWxI9nxL74L6x83y0T7v3Knyhb4pn5cxRmk1h3exL 8trjH0p9vCPxKCg45v3NrBZaqPQ2G1KuqbiAmLu5tbCz5UT2oBzIBojTe7sc9tuYv7v+ FZju9Yk3gRTNXS71bUodeTsh3FrEsez2BJ8qgHnVTeKPRAMbYSNtj7iL1f+DZk1Bxqix KHjw90SViiI2fNWkt9dXOKT0CxvMqXW3faiSljV4+47yRs61TEWFR9jzZz0wnRsWdpJD k22N3OPpHoDNuWn1dzyeJqWFaf+rK/kXOX1jUUIztyLMiWJ+U4JP1tFpuzOpKQtOjlON cI0g== X-Gm-Message-State: AHQUAub1b+aFGCpNV+no252iCc+aKlm1iLG0PnK9wcgZsuXebIXjSc9F gevtuWhzzEQZWvlEyC7x7wl7lMzW3bGLcE7CwJo51w== X-Google-Smtp-Source: ALg8bN5uwy0WLaOD9arvYcTIt+Lninv/gAzqQcOVja92UzoOQvYFnXQM8drmHbRDs/yntvP2SlXChW6CS3FrVMRF+z4= X-Received: by 2002:aca:1c04:: with SMTP id c4mr10079259oic.191.1548793106256; Tue, 29 Jan 2019 12:18:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 29 Jan 2019 12:18:14 -0800 Message-ID: To: Subodh Iyengar Cc: Christopher Wood , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ee03ee05809e7e5a" Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 20:18:31 -0000 --000000000000ee03ee05809e7e5a Content-Type: text/plain; charset="UTF-8" Wouldn't this issue also be mitigated by requiring the server to re-authenticate during resumption with the certificate once in a while? Nick On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar wrote: > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Ya I think that'd need a new draft either way. Can definitely write that up > if people don't think it's the worst idea in the world. > > Subodh > ------------------------------ > *From:* Christopher Wood > *Sent:* Monday, January 28, 2019 10:13:36 PM > *To:* Subodh Iyengar > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: > > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Correct, however the server currently provides a value for this, and > clients do not enforce a lower bound on this. 7 days is an upper bound. > > Servers would provide a much lower value than 7 days practically. > > > > If I'm understanding your suggestion correctly, you're suggesting that > clients change the meaning of ticket_lifetime_hint? > > That is not just limit it to the scope of the ticket but the entire TLS > session? That would be fine to by me, however might break some folks. > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Best, > Chris > > > > > Subodh > > ________________________________ > > From: Christopher Wood > > Sent: Monday, January 28, 2019 9:57 PM > > To: Subodh Iyengar > > Cc: tls@ietf.org > > Subject: Re: [TLS] ticket lifetimes > > > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > > > > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. > This had several original motivations including reducing the time that a > ticket is reused (for privacy or PFS). Another major motivation for this > was to limit the exposure of servers that use keyless ssl like mechanisms, > i.e. if they kept a STEK locally, but the keyless SSL server remotely, then > the theft of a STEK would presumably limit the MITM capabilities to the > ticket lifetime. > > > > > > However thinking about it some more because of the renewal capability > of tickets in TLS 1.3, an entity owning the STEK could just re-issue new > tickets forever on a resumed connection. This would look to the client as a > new ticket and it would refresh its lifetime on the ticket. Thereby a MITM > could intercept connections to users that have been to the server with the > STEK. I'm wondering whether it might be useful to define a mechanism to > limit the lifetime of all ticket resumption across all resumptions from the > original connection instead of just the limited per ticket lifetime. > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Best, > > Chris > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ee03ee05809e7e5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wouldn't this issue also be mitigated by requirin= g the server to re-authenticate during resumption with the certificate once= in a while?

Nick

On Tue, Jan 29, 2019 at 11:= 00 AM Subodh Iyengar <subodh@fb.com= > wrote:
>=C2=A0If by "entire TLS session" you mean = the resumed (and renewed)
sessions, then yep!

Ya I think that'd = need a new draft either way. Can definitely write that up
if people don't th= ink it's the worst idea in the world.

Subodh
From= : Christopher Wood <christopherwood07@gmail.com>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
=C2=A0
On Mon, Jan 28, 2019 at= 10:04 PM Subodh Iyengar <subodh@fb.com> wrote:
>
> > Since clients already store tickets, could they not also store th= e
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and c= lients do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggest= ing that clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TL= S session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________________________________
> From: Christopher Wood <christopherwood07@gmail.com>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org=
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 = days. This had several original motivations including reducing the time tha= t a ticket is reused (for privacy or PFS). Another major motivation for thi= s was to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, bu= t the keyless SSL server remotely, then the theft of a STEK would presumabl= y limit the MITM capabilities to the ticket lifetime.
> >
> > However thinking about it some more because of the renewal capabi= lity of tickets in TLS 1.3, an entity owning the STEK could just re-issue n= ew tickets forever on a resumed connection. This would look to the client a= s a new ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it = might be useful to define a mechanism to limit the lifetime of all ticket r= esumption across all resumptions from the original connection instead of just the limited per ticket lifetime. >
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Best,
> Chris
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ee03ee05809e7e5a-- From nobody Tue Jan 29 13:02:22 2019 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 292E0130F0D for ; Tue, 29 Jan 2019 13:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.071 X-Spam-Level: X-Spam-Status: No, score=-13.071 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 jwLf-o1a2HE3 for ; Tue, 29 Jan 2019 13:02:16 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CB1130EAE for ; Tue, 29 Jan 2019 13:02:16 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id v11so23940569qtc.2 for ; Tue, 29 Jan 2019 13:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dN6FWRx8Dkfw9lQGEW0l6/h4Mp0C8evIZpOf9czudUI=; b=h9TvOVG+XNUS0KOjld8wJyjRawTj2yUcmQEIdAGyOqh3CQn2dpO7HGyxCDat1fBahu xovpAxg9+q+d4gsiz9GCFpI4YsEb8msb8rlVqyUYvPkmUxUCRlQdQ4G3NBUW0kG6IiOH 0R2g+sy7qohbteg20Thpbp9cg0fbc8S3VaJAs= 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=dN6FWRx8Dkfw9lQGEW0l6/h4Mp0C8evIZpOf9czudUI=; b=jbJm2FgqT2no15twYx2O/N9MNthQ3dxuUIYeBAcsUG9/xh2BZY4Y3SIiqRMnbLwI39 N6tJVl4lN955lsOnl2Uoj1whoFAS6IbNPq7+k0Imd22QU6J1jiX9JZB01dl6atM6DrYV Z/3Ju0Chl3qv4NoY777y5v+mcpE+Bl7h+cLUMdS16ES9c9YZoYO6jgVd+4vH905heP1w nkdql74yTP8YFFwCHkHigIzxet/qFLzJpOzzTfO+2Zv7ZHPTe9jE6KjQLRwPaoo+AYZq W+hzY1ifCrwwtdf3KgKF2L64tWxbKZrST5hDsRuGOaGxBt1oemm96Y0Ep+WbFKmGPIWH 7GKQ== X-Gm-Message-State: AJcUukfzv53EjN9D8LD758goznEkxjJc/ZGwlmreGlkXsSLQhS61qVo9 f7GFPaKYdRoGmpZJfxZd6oAebz5A7L1cOM5XdjyF X-Google-Smtp-Source: ALg8bN6GQ7P3pvzUJ5ib8SV+qzTElZLvMC1rbJzVg896VEAmLPKevsMKG5z8R3MZn9D6m1zi8iCGPUzsebIA1MSFU/Y= X-Received: by 2002:a0c:a545:: with SMTP id y63mr25772432qvy.119.1548795734882; Tue, 29 Jan 2019 13:02:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 29 Jan 2019 15:02:04 -0600 Message-ID: To: Nick Sullivan Cc: Subodh Iyengar , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009c421f05809f1bc1" Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 21:02:19 -0000 --0000000000009c421f05809f1bc1 Content-Type: text/plain; charset="UTF-8" This two-lifetime thing is actually already what we implement in BoringSSL. :-) We track both a lifetime for the ticket (one day) and also for the original authentication the ticket roots up to (one week). The lifetime of the ticket is bounded by both these values, and the latter is not extendable on renew. On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan wrote: > Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while? > Existing servers won't do this, so I see this less as a mitigation and more as an optimization to plug the one-week-cliff that the fix produces. But, yeah, that would be handy. (Probably something like: "re"-auth'd identity apply to tickets, PSK applies to connection. Client sends an extension to advertise we're nearing the unrenewable bound.) David > Nick > > On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar wrote: > >> > If by "entire TLS session" you mean the resumed (and renewed) >> sessions, then yep! >> >> Ya I think that'd need a new draft either way. Can definitely write that >> up >> if people don't think it's the worst idea in the world. >> >> Subodh >> ------------------------------ >> *From:* Christopher Wood >> *Sent:* Monday, January 28, 2019 10:13:36 PM >> *To:* Subodh Iyengar >> *Cc:* tls@ietf.org >> *Subject:* Re: [TLS] ticket lifetimes >> >> On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: >> > >> > > Since clients already store tickets, could they not also store the >> > time of original ticket issuance and cap the resumption window to N >> > (7) days from that point? That is, it seems clients could implement >> > this behavior without any protocol support. >> > >> > Correct, however the server currently provides a value for this, and >> clients do not enforce a lower bound on this. 7 days is an upper bound. >> > Servers would provide a much lower value than 7 days practically. >> > >> > If I'm understanding your suggestion correctly, you're suggesting that >> clients change the meaning of ticket_lifetime_hint? >> > That is not just limit it to the scope of the ticket but the entire TLS >> session? That would be fine to by me, however might break some folks. >> >> If by "entire TLS session" you mean the resumed (and renewed) >> sessions, then yep! >> >> Best, >> Chris >> >> > >> > Subodh >> > ________________________________ >> > From: Christopher Wood >> > Sent: Monday, January 28, 2019 9:57 PM >> > To: Subodh Iyengar >> > Cc: tls@ietf.org >> > Subject: Re: [TLS] ticket lifetimes >> > >> > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: >> > > >> > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 >> days. This had several original motivations including reducing the time >> that a ticket is reused (for privacy or PFS). Another major motivation for >> this was to limit the exposure of servers that use keyless ssl like >> mechanisms, i.e. if they kept a STEK locally, but the keyless SSL server >> remotely, then the theft of a STEK would presumably limit the MITM >> capabilities to the ticket lifetime. >> > > >> > > However thinking about it some more because of the renewal capability >> of tickets in TLS 1.3, an entity owning the STEK could just re-issue new >> tickets forever on a resumed connection. This would look to the client as a >> new ticket and it would refresh its lifetime on the ticket. Thereby a MITM >> could intercept connections to users that have been to the server with the >> STEK. I'm wondering whether it might be useful to define a mechanism to >> limit the lifetime of all ticket resumption across all resumptions from the >> original connection instead of just the limited per ticket lifetime. >> > >> > Since clients already store tickets, could they not also store the >> > time of original ticket issuance and cap the resumption window to N >> > (7) days from that point? That is, it seems clients could implement >> > this behavior without any protocol support. >> > >> > Best, >> > Chris >> _______________________________________________ >> 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 > > --0000000000009c421f05809f1bc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This two-lifetime thing is actually already what we implem= ent in BoringSSL. :-) We track both a lifetime for the ticket (one day) and= also for the original authentication the ticket roots up to (one week). Th= e lifetime of the ticket is bounded by both these values, and the latter is= not extendable on renew.

On Tue, Jan 29, 2019 at 2= :18 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
Wouldn't this issue also be mitigated by r= equiring the server to re-authenticate during resumption with the certifica= te once in a while?

Existing se= rvers won't do this, so I see this less as a mitigation and more as an = optimization to plug the one-week-cliff that the fix produces. But, yeah, t= hat would be handy. (Probably something like: "re"-auth'd ide= ntity apply to tickets, PSK applies to connection. Client sends an extensio= n to advertise we're nearing the unrenewable bound.)
David
=C2=A0
Nick

On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar <subodh@fb.com> wrote:
>=C2=A0If by "entire TLS session" you mean = the resumed (and renewed)
sessions, then yep!

Ya I think that'd = need a new draft either way. Can definitely write that up
if people don't th= ink it's the worst idea in the world.

Subodh
From: Christopher Wood <christopherwo= od07@gmail.com>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
=C2=A0
On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <subodh@fb.com> wrote= :
>
> > Since clients already store tickets, could they not also store th= e
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and c= lients do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggest= ing that clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TL= S session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________________________________
> From: Christopher Wood <christopherwood07@gmail.com>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org=
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 = days. This had several original motivations including reducing the time tha= t a ticket is reused (for privacy or PFS). Another major motivation for thi= s was to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, bu= t the keyless SSL server remotely, then the theft of a STEK would presumabl= y limit the MITM capabilities to the ticket lifetime.
> >
> > However thinking about it some more because of the renewal capabi= lity of tickets in TLS 1.3, an entity owning the STEK could just re-issue n= ew tickets forever on a resumed connection. This would look to the client a= s a new ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it = might be useful to define a mechanism to limit the lifetime of all ticket r= esumption across all resumptions from the original connection instead of just the limited per ticket lifetime. >
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Best,
> Chris
_______________________________________________
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

--0000000000009c421f05809f1bc1-- From nobody Tue Jan 29 14:14:14 2019 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 C751112E7C1 for ; Tue, 29 Jan 2019 14:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ZZT5uIP3; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=QhV47V8R 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 AXzGN__1Th0q for ; Tue, 29 Jan 2019 14:14:08 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 6505D130EDB for ; Tue, 29 Jan 2019 14:14:08 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0TM5cT5013685; Tue, 29 Jan 2019 14:14:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=RsJHoYtOwXreE/Ds6DwUSVD+V1HGqEVZSapbCQ+pLFo=; b=ZZT5uIP3Ob+GgaI7iFgAynHmMwMe21ViS5ZUWLP7JGuixcnk8aX6Ax0EcvQGN7y3AmYA 4sP5LdbHLLVPLr61pLjnWFkRKnGI0Wo9EZOeJ6268UerzBztyy0/zn7UFRTsMkbn8Typ E946lvusfEjypfn4hmyaUfzNPW/8T1dpMZc= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qavr8gk0q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jan 2019 14:14:06 -0800 Received: from frc-mbx02.TheFacebook.com (2620:10d:c0a1:f82::26) by frc-hub06.TheFacebook.com (2620:10d:c021:18::176) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 29 Jan 2019 14:14:05 -0800 Received: from frc-hub03.TheFacebook.com (2620:10d:c021:18::173) by frc-mbx02.TheFacebook.com (2620:10d:c0a1:f82::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 29 Jan 2019 14:14:04 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 29 Jan 2019 14:14:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RsJHoYtOwXreE/Ds6DwUSVD+V1HGqEVZSapbCQ+pLFo=; b=QhV47V8RjOttwkZVHXgpuVt5HqAwCpRZWw3F83Q2zsxHLvBcb7ZUmqGaLE87mBh/NMOgzTIAP7nSxHTuveXrkAiPMdFPPeD1cr6KIb/DYQh1NFRIwi29CVqv0bPvQUppGolgJVYEaTA5ux9W6Tl/jhpMoQp3nPvf/QW94sNVhl0= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1790.namprd15.prod.outlook.com (10.174.255.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.17; Tue, 29 Jan 2019 22:14:02 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::e4f1:9986:a3d:178b%7]) with mapi id 15.20.1558.023; Tue, 29 Jan 2019 22:14:02 +0000 From: Subodh Iyengar To: David Benjamin , Nick Sullivan CC: "tls@ietf.org" Thread-Topic: [TLS] ticket lifetimes Thread-Index: AQHUt5PbJPg1BCv4IU2K+uhv0WevMqXFv9eAgAAArOaAAAPeAIAA1cE8gAAWPACAAAw/AIAAE3Gs Date: Tue, 29 Jan 2019 22:14:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:7d31] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1790; 20:R/r4PdLTCsUD8bB1WC4H6LLrzjRVW6kHS8Y1Ru67brIlhymmHZcbxaGVXSlz2E694pX6HzshwrH0sQnmXatzb2eDH9bewE8PH8FJgmtm4vhIZt90dPlWSIx09QvpwuMsZxFewDpJux06cQSieq55zkbTpqiI9oFOv5XvLaDc5vk= x-ms-office365-filtering-correlation-id: e270f98d-8287-4ce3-ef84-08d686371366 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1790; x-ms-traffictypediagnostic: MWHPR15MB1790: x-microsoft-antispam-prvs: x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(376002)(396003)(346002)(51444003)(199004)(189003)(19627405001)(76176011)(110136005)(33656002)(6306002)(2906002)(105586002)(229853002)(7696005)(71190400001)(97736004)(53936002)(9686003)(86362001)(236005)(99286004)(106356001)(93886005)(55016002)(6436002)(71200400001)(186003)(81156014)(105004)(81166006)(46003)(74316002)(966005)(4326008)(102836004)(478600001)(54896002)(606006)(8936002)(486006)(8676002)(256004)(14444005)(476003)(7736002)(5070765005)(6506007)(25786009)(6246003)(53546011)(11346002)(68736007)(14454004)(446003)(6116002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1790; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HKS9Ug8NJO4nHgzicKNTpa6mX0u5l3jFRX3ASIUxV7n//lrlm3CuXKnyMQoJRyXWwmNjCCBwQHA3kaGSZiB0NC9tU2YykF8J/L7+mSVoORibBmLmR08zWamHP2QvBCpvJ0ynkv+mK6V1pLDqAJdSWzW3dMrBtIF9Qa8AeeNwW7BBtNTeOJuXAtOo8IE1ZWjcooTVwVjSxV5SgBf+Vg05xv6+NKkEC68i9Ppv57u2uH3R3da/xK0VmR/ATqNOF+dpGkXdDugClh/sN4cbXVPr3Fwt1yufpZvxaMc6nDw5zamVGEfB5t0bJlfEqT39RL4tED0rLW6jQyf8jgIK72jF7bgMv2jeTQ27I0dcDN5yEzq7F43XUcxXRGxt5xMFjQHDcax7sFmm+wms7cDLBuklOD6jmH/i4qHJxXRxZmX/TmM= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18215B0C046B3ADFA88F0FC4B6970MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e270f98d-8287-4ce3-ef84-08d686371366 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2019 22:14:02.4777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1790 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-29_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 22:14:12 -0000 --_000_MWHPR15MB18215B0C046B3ADFA88F0FC4B6970MWHPR15MB1821namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBXb3VsZG4ndCB0aGlzIGlzc3VlIGFsc28gYmUgbWl0aWdhdGVkIGJ5IHJlcXVpcmluZyB0aGUg c2VydmVyIHRvIHJlLWF1dGhlbnRpY2F0ZSBkdXJpbmcgcmVzdW1wdGlvbiB3aXRoIHRoZSBjZXJ0 aWZpY2F0ZSBvbmNlIGluIGEgd2hpbGU/DQoNCkkgdGhpbmsgaXQncyBwcm9iYWJseSBqdXN0IGVh c2llciB0byBkcm9wIHRoZSByZXN1bXB0aW9uIGNvbXBsZXRlbHkuDQoNCj4gVGhpcyB0d28tbGlm ZXRpbWUgdGhpbmcgaXMgYWN0dWFsbHkgYWxyZWFkeSB3aGF0IHdlIGltcGxlbWVudCBpbiBCb3Jp bmdTU0wuIPCfmIoNCg0KRmFudGFzdGljLiBXb3VsZCBpdCBoZWxwIHRvIGhhdmUgYW4gZXh0ZW5z aW9uIHRvIHNldCBhIGxvd2VyIGJvdW5kIG9uIHRoaXMgdmFsdWUsIG9yIGp1c3QgbWFrZSBpdCBt b3JlIHBhaW5mdWw/DQoNClN1Ym9kaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc+DQpTZW50OiBUdWVz ZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDE6MDIgUE0NClRvOiBOaWNrIFN1bGxpdmFuDQpDYzogU3Vi b2RoIEl5ZW5nYXI7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIHRpY2tldCBsaWZl dGltZXMNCg0KVGhpcyB0d28tbGlmZXRpbWUgdGhpbmcgaXMgYWN0dWFsbHkgYWxyZWFkeSB3aGF0 IHdlIGltcGxlbWVudCBpbiBCb3JpbmdTU0wuIDotKSBXZSB0cmFjayBib3RoIGEgbGlmZXRpbWUg Zm9yIHRoZSB0aWNrZXQgKG9uZSBkYXkpIGFuZCBhbHNvIGZvciB0aGUgb3JpZ2luYWwgYXV0aGVu dGljYXRpb24gdGhlIHRpY2tldCByb290cyB1cCB0byAob25lIHdlZWspLiBUaGUgbGlmZXRpbWUg b2YgdGhlIHRpY2tldCBpcyBib3VuZGVkIGJ5IGJvdGggdGhlc2UgdmFsdWVzLCBhbmQgdGhlIGxh dHRlciBpcyBub3QgZXh0ZW5kYWJsZSBvbiByZW5ldy4NCg0KT24gVHVlLCBKYW4gMjksIDIwMTkg YXQgMjoxOCBQTSBOaWNrIFN1bGxpdmFuIDxuaWNrPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOjQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCldv dWxkbid0IHRoaXMgaXNzdWUgYWxzbyBiZSBtaXRpZ2F0ZWQgYnkgcmVxdWlyaW5nIHRoZSBzZXJ2 ZXIgdG8gcmUtYXV0aGVudGljYXRlIGR1cmluZyByZXN1bXB0aW9uIHdpdGggdGhlIGNlcnRpZmlj YXRlIG9uY2UgaW4gYSB3aGlsZT8NCg0KRXhpc3Rpbmcgc2VydmVycyB3b24ndCBkbyB0aGlzLCBz byBJIHNlZSB0aGlzIGxlc3MgYXMgYSBtaXRpZ2F0aW9uIGFuZCBtb3JlIGFzIGFuIG9wdGltaXph dGlvbiB0byBwbHVnIHRoZSBvbmUtd2Vlay1jbGlmZiB0aGF0IHRoZSBmaXggcHJvZHVjZXMuIEJ1 dCwgeWVhaCwgdGhhdCB3b3VsZCBiZSBoYW5keS4gKFByb2JhYmx5IHNvbWV0aGluZyBsaWtlOiAi cmUiLWF1dGgnZCBpZGVudGl0eSBhcHBseSB0byB0aWNrZXRzLCBQU0sgYXBwbGllcyB0byBjb25u ZWN0aW9uLiBDbGllbnQgc2VuZHMgYW4gZXh0ZW5zaW9uIHRvIGFkdmVydGlzZSB3ZSdyZSBuZWFy aW5nIHRoZSB1bnJlbmV3YWJsZSBib3VuZC4pDQoNCkRhdmlkDQoNCk5pY2sNCg0KT24gVHVlLCBK YW4gMjksIDIwMTkgYXQgMTE6MDAgQU0gU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb208bWFp bHRvOnN1Ym9kaEBmYi5jb20+PiB3cm90ZToNCj4gSWYgYnkgImVudGlyZSBUTFMgc2Vzc2lvbiIg eW91IG1lYW4gdGhlIHJlc3VtZWQgKGFuZCByZW5ld2VkKQ0Kc2Vzc2lvbnMsIHRoZW4geWVwIQ0K DQpZYSBJIHRoaW5rIHRoYXQnZCBuZWVkIGEgbmV3IGRyYWZ0IGVpdGhlciB3YXkuIENhbiBkZWZp bml0ZWx5IHdyaXRlIHRoYXQgdXANCmlmIHBlb3BsZSBkb24ndCB0aGluayBpdCdzIHRoZSB3b3Jz dCBpZGVhIGluIHRoZSB3b3JsZC4NCg0KU3Vib2RoDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogQ2hyaXN0b3BoZXIgV29vZCA8Y2hyaXN0b3BoZXJ3b29kMDdAZ21haWwu Y29tPG1haWx0bzpjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5jb20+Pg0KU2VudDogTW9uZGF5LCBK YW51YXJ5IDI4LCAyMDE5IDEwOjEzOjM2IFBNDQpUbzogU3Vib2RoIEl5ZW5nYXINCkNjOiB0bHNA aWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSB0aWNrZXQg bGlmZXRpbWVzDQoNCk9uIE1vbiwgSmFuIDI4LCAyMDE5IGF0IDEwOjA0IFBNIFN1Ym9kaCBJeWVu Z2FyIDxzdWJvZGhAZmIuY29tPG1haWx0bzpzdWJvZGhAZmIuY29tPj4gd3JvdGU6DQo+DQo+ID4g U2luY2UgY2xpZW50cyBhbHJlYWR5IHN0b3JlIHRpY2tldHMsIGNvdWxkIHRoZXkgbm90IGFsc28g c3RvcmUgdGhlDQo+IHRpbWUgb2Ygb3JpZ2luYWwgdGlja2V0IGlzc3VhbmNlIGFuZCBjYXAgdGhl IHJlc3VtcHRpb24gd2luZG93IHRvIE4NCj4gKDcpIGRheXMgZnJvbSB0aGF0IHBvaW50PyBUaGF0 IGlzLCBpdCBzZWVtcyBjbGllbnRzIGNvdWxkIGltcGxlbWVudA0KPiB0aGlzIGJlaGF2aW9yIHdp dGhvdXQgYW55IHByb3RvY29sIHN1cHBvcnQuDQo+DQo+IENvcnJlY3QsIGhvd2V2ZXIgdGhlIHNl cnZlciBjdXJyZW50bHkgcHJvdmlkZXMgYSB2YWx1ZSBmb3IgdGhpcywgYW5kIGNsaWVudHMgZG8g bm90IGVuZm9yY2UgYSBsb3dlciBib3VuZCBvbiB0aGlzLiA3IGRheXMgaXMgYW4gdXBwZXIgYm91 bmQuDQo+IFNlcnZlcnMgd291bGQgcHJvdmlkZSBhIG11Y2ggbG93ZXIgdmFsdWUgdGhhbiA3IGRh eXMgcHJhY3RpY2FsbHkuDQo+DQo+IElmIEknbSB1bmRlcnN0YW5kaW5nIHlvdXIgc3VnZ2VzdGlv biBjb3JyZWN0bHksIHlvdSdyZSBzdWdnZXN0aW5nIHRoYXQgY2xpZW50cyBjaGFuZ2UgdGhlIG1l YW5pbmcgb2YgdGlja2V0X2xpZmV0aW1lX2hpbnQ/DQo+IFRoYXQgaXMgbm90IGp1c3QgbGltaXQg aXQgdG8gdGhlIHNjb3BlIG9mIHRoZSB0aWNrZXQgYnV0IHRoZSBlbnRpcmUgVExTIHNlc3Npb24/ IFRoYXQgd291bGQgYmUgZmluZSB0byBieSBtZSwgaG93ZXZlciBtaWdodCBicmVhayBzb21lIGZv bGtzLg0KDQpJZiBieSAiZW50aXJlIFRMUyBzZXNzaW9uIiB5b3UgbWVhbiB0aGUgcmVzdW1lZCAo YW5kIHJlbmV3ZWQpDQpzZXNzaW9ucywgdGhlbiB5ZXAhDQoNCkJlc3QsDQpDaHJpcw0KDQo+DQo+ IFN1Ym9kaA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBDaHJp c3RvcGhlciBXb29kIDxjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5jb208bWFpbHRvOmNocmlzdG9w aGVyd29vZDA3QGdtYWlsLmNvbT4+DQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxOSA5 OjU3IFBNDQo+IFRvOiBTdWJvZGggSXllbmdhcg0KPiBDYzogdGxzQGlldGYub3JnPG1haWx0bzp0 bHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSB0aWNrZXQgbGlmZXRpbWVzDQo+DQo+ IE9uIE1vbiwgSmFuIDI4LCAyMDE5IGF0IDk6NDMgUE0gU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBm Yi5jb208bWFpbHRvOnN1Ym9kaEBmYi5jb20+PiB3cm90ZToNCj4gPg0KPiA+IEluIFRMUyAxLjMg d2UgYWRkZWQgYSBtYXhpbXVtIGFnZSB0byB0aGUgdGlja2V0IGxpZmV0aW1lIHRvIGJlIDcgZGF5 cy4gVGhpcyBoYWQgc2V2ZXJhbCBvcmlnaW5hbCBtb3RpdmF0aW9ucyBpbmNsdWRpbmcgcmVkdWNp bmcgdGhlIHRpbWUgdGhhdCBhIHRpY2tldCBpcyByZXVzZWQgKGZvciBwcml2YWN5IG9yIFBGUyku IEFub3RoZXIgbWFqb3IgbW90aXZhdGlvbiBmb3IgdGhpcyB3YXMgdG8gbGltaXQgdGhlIGV4cG9z dXJlIG9mIHNlcnZlcnMgdGhhdCB1c2Uga2V5bGVzcyBzc2wgbGlrZSBtZWNoYW5pc21zLCBpLmUu IGlmIHRoZXkga2VwdCBhIFNURUsgbG9jYWxseSwgYnV0IHRoZSBrZXlsZXNzIFNTTCBzZXJ2ZXIg cmVtb3RlbHksIHRoZW4gdGhlIHRoZWZ0IG9mIGEgU1RFSyB3b3VsZCBwcmVzdW1hYmx5IGxpbWl0 IHRoZSBNSVRNIGNhcGFiaWxpdGllcyB0byB0aGUgdGlja2V0IGxpZmV0aW1lLg0KPiA+DQo+ID4g SG93ZXZlciB0aGlua2luZyBhYm91dCBpdCBzb21lIG1vcmUgYmVjYXVzZSBvZiB0aGUgcmVuZXdh bCBjYXBhYmlsaXR5IG9mIHRpY2tldHMgaW4gVExTIDEuMywgYW4gZW50aXR5IG93bmluZyB0aGUg U1RFSyBjb3VsZCBqdXN0IHJlLWlzc3VlIG5ldyB0aWNrZXRzIGZvcmV2ZXIgb24gYSByZXN1bWVk IGNvbm5lY3Rpb24uIFRoaXMgd291bGQgbG9vayB0byB0aGUgY2xpZW50IGFzIGEgbmV3IHRpY2tl dCBhbmQgaXQgd291bGQgcmVmcmVzaCBpdHMgbGlmZXRpbWUgb24gdGhlIHRpY2tldC4gVGhlcmVi eSBhIE1JVE0gY291bGQgaW50ZXJjZXB0IGNvbm5lY3Rpb25zIHRvIHVzZXJzIHRoYXQgaGF2ZSBi ZWVuIHRvIHRoZSBzZXJ2ZXIgd2l0aCB0aGUgU1RFSy4gSSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0 IG1pZ2h0IGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdG8gbGltaXQgdGhlIGxpZmV0 aW1lIG9mIGFsbCB0aWNrZXQgcmVzdW1wdGlvbiBhY3Jvc3MgYWxsIHJlc3VtcHRpb25zIGZyb20g dGhlIG9yaWdpbmFsIGNvbm5lY3Rpb24gaW5zdGVhZCBvZiBqdXN0IHRoZSBsaW1pdGVkIHBlciB0 aWNrZXQgbGlmZXRpbWUuDQo+DQo+IFNpbmNlIGNsaWVudHMgYWxyZWFkeSBzdG9yZSB0aWNrZXRz LCBjb3VsZCB0aGV5IG5vdCBhbHNvIHN0b3JlIHRoZQ0KPiB0aW1lIG9mIG9yaWdpbmFsIHRpY2tl dCBpc3N1YW5jZSBhbmQgY2FwIHRoZSByZXN1bXB0aW9uIHdpbmRvdyB0byBODQo+ICg3KSBkYXlz IGZyb20gdGhhdCBwb2ludD8gVGhhdCBpcywgaXQgc2VlbXMgY2xpZW50cyBjb3VsZCBpbXBsZW1l bnQNCj4gdGhpcyBiZWhhdmlvciB3aXRob3V0IGFueSBwcm90b2NvbCBzdXBwb3J0Lg0KPg0KPiBC ZXN0LA0KPiBDaHJpcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb190bHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9aDNK dTlFQlM3bUh0d2ctd0F5TjdmUSZtPUFlSHBrWVh3UXRGNERqZnFkSE5sdU9MSWNUSE9EVGlobjdp NFdCenVjakEmcz1CNHpMNkVtdjBqeWhBc3VKeUJueE16TzhsMXc3U0R1NU9wQjRtOGphck1rJmU9 Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBt YWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCjxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX3RscyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1oM0p1OUVCUzdtSHR3 Zy13QXlON2ZRJm09QWVIcGtZWHdRdEY0RGpmcWRITmx1T0xJY1RIT0RUaWhuN2k0V0J6dWNqQSZz PUI0ekw2RW12MGp5aEFzdUp5Qm54TXpPOGwxdzdTRHU1T3BCNG04amFyTWsmZT0+DQo= --_000_MWHPR15MB18215B0C046B3ADFA88F0FC4B6970MWHPR15MB1821namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDE1cHg7IGZvbnQtZmFtaWx5OiAmcXVvdDtTZWdvZSBVSSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkg V2ViIChXZXN0IEV1cm9wZWFuKSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssIC1hcHBsZS1z eXN0ZW0sIEJsaW5rTWFjU3lzdGVtRm9udCwgUm9ib3RvLCAmcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90Oywgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMywgMzMsIDMzKTsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpIj4NCiZndDsgV291bGRuJ3QgdGhpcyBpc3N1ZSBhbHNvIGJl IG1pdGlnYXRlZCBieSByZXF1aXJpbmcgdGhlIHNlcnZlciB0byByZS1hdXRoZW50aWNhdGUgZHVy aW5nIHJlc3VtcHRpb24gd2l0aCB0aGUgY2VydGlmaWNhdGUgb25jZSBpbiBhIHdoaWxlPzwvZGl2 Pg0KPGJyPg0KSSB0aGluayBpdCdzIHByb2JhYmx5IGp1c3QgZWFzaWVyIHRvIGRyb3AgdGhlIHJl c3VtcHRpb24gY29tcGxldGVseS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEVtb2ppRm9udCwgQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiwg JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDssICZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7 LCBOb3RvQ29sb3JFbW9qaSwgJnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LCAmcXVvdDtBbmRy b2lkIEVtb2ppJnF1b3Q7LCBFbW9qaVN5bWJvbHM7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KJmd0OyZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywg MzMpOyBmb250LWZhbWlseTogJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O1NlZ29lIFVJIFdl YiAoV2VzdCBFdXJvcGVhbikmcXVvdDssICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAtYXBwbGUtc3lz dGVtLCBCbGlua01hY1N5c3RlbUZvbnQsIFJvYm90bywgJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVv dDssIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudCI+VGhpcw0KIHR3by1saWZl dGltZSB0aGluZyBpcyBhY3R1YWxseSBhbHJlYWR5IHdoYXQgd2UgaW1wbGVtZW50IGluIEJvcmlu Z1NTTC4gPHNwYW4+8J+Yijwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogRW1vamlGb250LCBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmLCAm cXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDss IE5vdG9Db2xvckVtb2ppLCAmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJv aWQgRW1vamkmcXVvdDssIEVtb2ppU3ltYm9sczsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdi KDAsIDAsIDApOyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMywgMzMsIDMzKTsgZm9udC1m YW1pbHk6ICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSBXZWIgKFdlc3QgRXVy b3BlYW4pJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSZxdW90OywgLWFwcGxlLXN5c3RlbSwgQmxpbmtN YWNTeXN0ZW1Gb250LCBSb2JvdG8sICZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE1cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1 KTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQiPjxzcGFuPjxicj4NCjwvc3Bhbj48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogRW1vamlGb250LCBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmLCAmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90Oywg JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5vdG9Db2xvckVtb2ppLCAmcXVvdDtTZWdvZSBV SSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQgRW1vamkmcXVvdDssIEVtb2ppU3ltYm9sczsg Zm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzMywgMzMsIDMzKTsgZm9udC1mYW1pbHk6ICZxdW90O1NlZ29lIFVJJnF1b3Q7LCAm cXVvdDtTZWdvZSBVSSBXZWIgKFdlc3QgRXVyb3BlYW4pJnF1b3Q7LCAmcXVvdDtTZWdvZSBVSSZx dW90OywgLWFwcGxlLXN5c3RlbSwgQmxpbmtNYWNTeXN0ZW1Gb250LCBSb2JvdG8sICZxdW90O0hl bHZldGljYSBOZXVlJnF1b3Q7LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQi PjxzcGFuPkZhbnRhc3RpYy4NCiBXb3VsZCBpdCBoZWxwIHRvIGhhdmUgYW4gZXh0ZW5zaW9uIHRv IHNldCBhIGxvd2VyIGJvdW5kIG9uIHRoaXMgdmFsdWUsIG9yIGp1c3QgbWFrZSBpdCBtb3JlIHBh aW5mdWw/PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg Y29sb3I6IHJnYigwLCAwLCAwKTsiPg0KU3Vib2RoPC9kaXY+DQo8ZGl2IGlkPSJhcHBlbmRvbnNl bmQiPjwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5OCUiIHRh YmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFj ZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAw MDAwMCI+PGI+RnJvbTo8L2I+IERhdmlkIEJlbmphbWluICZsdDtkYXZpZGJlbkBjaHJvbWl1bS5v cmcmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgMTowMiBQ TTxicj4NCjxiPlRvOjwvYj4gTmljayBTdWxsaXZhbjxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5 ZW5nYXI7IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gdGlja2V0 IGxpZmV0aW1lczwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj5UaGlzIHR3by1saWZldGltZSB0aGluZyBpcyBhY3R1YWxseSBhbHJlYWR5IHdo YXQgd2UgaW1wbGVtZW50IGluIEJvcmluZ1NTTC4gOi0pIFdlIHRyYWNrIGJvdGggYSBsaWZldGlt ZSBmb3IgdGhlIHRpY2tldCAob25lIGRheSkgYW5kIGFsc28gZm9yIHRoZSBvcmlnaW5hbCBhdXRo ZW50aWNhdGlvbiB0aGUgdGlja2V0IHJvb3RzIHVwIHRvIChvbmUgd2VlaykuIFRoZSBsaWZldGlt ZSBvZiB0aGUgdGlja2V0IGlzIGJvdW5kZWQNCiBieSBib3RoIHRoZXNlIHZhbHVlcywgYW5kIHRo ZSBsYXR0ZXIgaXMgbm90IGV4dGVuZGFibGUgb24gcmVuZXcuDQo8ZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+T24gVHVlLCBKYW4gMjksIDIwMTkgYXQgMjoxOCBQTSBOaWNrIFN1bGxpdmFu ICZsdDtuaWNrPTxhIGhyZWY9Im1haWx0bzo0MGNsb3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWls X3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5Xb3VsZG4ndCB0aGlzIGlzc3VlIGFsc28gYmUgbWl0 aWdhdGVkIGJ5IHJlcXVpcmluZyB0aGUgc2VydmVyIHRvIHJlLWF1dGhlbnRpY2F0ZSBkdXJpbmcg cmVzdW1wdGlvbiB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSBvbmNlIGluIGEgd2hpbGU/PC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkV4aXN0aW5nIHNl cnZlcnMgd29uJ3QgZG8gdGhpcywgc28gSSBzZWUgdGhpcyBsZXNzIGFzIGEgbWl0aWdhdGlvbiBh bmQgbW9yZSBhcyBhbiBvcHRpbWl6YXRpb24gdG8gcGx1ZyB0aGUgb25lLXdlZWstY2xpZmYgdGhh dCB0aGUgZml4IHByb2R1Y2VzLiBCdXQsIHllYWgsIHRoYXQgd291bGQgYmUgaGFuZHkuIChQcm9i YWJseSBzb21ldGhpbmcgbGlrZTogJnF1b3Q7cmUmcXVvdDstYXV0aCdkIGlkZW50aXR5IGFwcGx5 IHRvIHRpY2tldHMsIFBTSyBhcHBsaWVzDQogdG8gY29ubmVjdGlvbi4gQ2xpZW50IHNlbmRzIGFu IGV4dGVuc2lvbiB0byBhZHZlcnRpc2Ugd2UncmUgbmVhcmluZyB0aGUgdW5yZW5ld2FibGUgYm91 bmQuKTwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRhdmlkPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsg cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+TmljazwvZGl2Pg0KPC9k aXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSJ4X21fLTU5NTUwMzMxNjE2NDg3MTEyNDRtXzE5NjEwOTgyOTM2OTg5MTQxNjlnbWFpbF9h dHRyIj5PbiBUdWUsIEphbiAyOSwgMjAxOSBhdCAxMTowMCBBTSBTdWJvZGggSXllbmdhciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5zdWJvZGhAZmIu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9nbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQ6MXB4 IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0 ciI+DQo8ZGl2IGlkPSJ4X21fLTU5NTUwMzMxNjE2NDg3MTEyNDRtXzE5NjEwOTgyOTM2OTg5MTQx NjlnbWFpbC1tXzM5NzcyNzExMDI2NDc0MzgyODFkaXZ0YWdkZWZhdWx0d3JhcHBlciIgZGlyPSJs dHIiIHN0eWxlPSJmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQomZ3Q7Jm5ic3A7PHNwYW4gc3R5bGU9ImNv bG9yOnJnYigzMywzMywzMyk7IGZvbnQtZmFtaWx5OndmX3NlZ29lLXVpX25vcm1hbCwmcXVvdDtT ZWdvZSBVSSZxdW90OywmcXVvdDtTZWdvZSBXUCZxdW90OyxUYWhvbWEsQXJpYWwsc2Fucy1zZXJp ZixzZXJpZixFbW9qaUZvbnQ7IGZvbnQtc2l6ZToxNC42NjY3cHgiPklmIGJ5ICZxdW90O2VudGly ZSBUTFMgc2Vzc2lvbiZxdW90OyB5b3UgbWVhbiB0aGUgcmVzdW1lZCAoYW5kIHJlbmV3ZWQpPC9z cGFuPjxiciBzdHlsZT0iY29sb3I6cmdiKDMzLDMzLDMzKTsgZm9udC1mYW1pbHk6d2Zfc2Vnb2Ut dWlfbm9ybWFsLCZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9t YSxBcmlhbCxzYW5zLXNlcmlmLHNlcmlmLEVtb2ppRm9udDsgZm9udC1zaXplOjE0LjY2NjdweCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMzLDMzLDMzKTsgZm9udC1mYW1pbHk6d2Zfc2Vnb2Ut dWlfbm9ybWFsLCZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9t YSxBcmlhbCxzYW5zLXNlcmlmLHNlcmlmLEVtb2ppRm9udDsgZm9udC1zaXplOjE0LjY2NjdweCI+ c2Vzc2lvbnMsIHRoZW4geWVwITwvc3Bhbj48YnIgc3R5bGU9ImNvbG9yOnJnYigzMywzMywzMyk7 IGZvbnQtZmFtaWx5OndmX3NlZ29lLXVpX25vcm1hbCwmcXVvdDtTZWdvZSBVSSZxdW90OywmcXVv dDtTZWdvZSBXUCZxdW90OyxUYWhvbWEsQXJpYWwsc2Fucy1zZXJpZixzZXJpZixFbW9qaUZvbnQ7 IGZvbnQtc2l6ZToxNC42NjY3cHgiPg0KPGRpdj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMzLDMz LDMzKTsgZm9udC1mYW1pbHk6d2Zfc2Vnb2UtdWlfbm9ybWFsLCZxdW90O1NlZ29lIFVJJnF1b3Q7 LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9tYSxBcmlhbCxzYW5zLXNlcmlmLHNlcmlmLEVtb2pp Rm9udDsgZm9udC1zaXplOjE0LjY2NjdweCI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48Zm9u dCBjb2xvcj0iIzIxMjEyMSIgZmFjZT0id2Zfc2Vnb2UtdWlfbm9ybWFsLCBTZWdvZSBVSSwgU2Vn b2UgV1AsIFRhaG9tYSwgQXJpYWwsIHNhbnMtc2VyaWYsIHNlcmlmLCBFbW9qaUZvbnQiPjxzcGFu PllhIEkgdGhpbmsgdGhhdCdkIG5lZWQgYSBuZXcgZHJhZnQgZWl0aGVyIHdheS4gQ2FuIGRlZmlu aXRlbHkgd3JpdGUgdGhhdCB1cDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9y PSIjMjEyMTIxIiBmYWNlPSJ3Zl9zZWdvZS11aV9ub3JtYWwsIFNlZ29lIFVJLCBTZWdvZSBXUCwg VGFob21hLCBBcmlhbCwgc2Fucy1zZXJpZiwgc2VyaWYsIEVtb2ppRm9udCI+PHNwYW4+aWYgcGVv cGxlIGRvbid0IHRoaW5rIGl0J3MgdGhlIHdvcnN0IGlkZWEgaW4gdGhlIHdvcmxkLjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMjEyMTIxIiBmYWNlPSJ3Zl9zZWdvZS11 aV9ub3JtYWwsIFNlZ29lIFVJLCBTZWdvZSBXUCwgVGFob21hLCBBcmlhbCwgc2Fucy1zZXJpZiwg c2VyaWYsIEVtb2ppRm9udCI+PHNwYW4+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgY29sb3I9IiMyMTIxMjEiIGZhY2U9IndmX3NlZ29lLXVpX25vcm1hbCwgU2Vnb2UgVUks IFNlZ29lIFdQLCBUYWhvbWEsIEFyaWFsLCBzYW5zLXNlcmlmLCBzZXJpZiwgRW1vamlGb250Ij48 c3Bhbj5TdWJvZGg8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8aHIgc3R5bGU9ImRpc3Bs YXk6aW5saW5lLWJsb2NrOyB3aWR0aDo5OCUiPg0KPGRpdiBpZD0ieF9tXy01OTU1MDMzMTYxNjQ4 NzExMjQ0bV8xOTYxMDk4MjkzNjk4OTE0MTY5Z21haWwtbV8zOTc3MjcxMTAyNjQ3NDM4MjgxZGl2 UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIg Y29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IENocmlz dG9waGVyIFdvb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5jb208L2E+Jmd0Ozxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTkgMTA6MTM6MzYgUE08YnI+ DQo8Yj5Ubzo8L2I+IFN1Ym9kaCBJeWVuZ2FyPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGxzQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1RMU10gdGlja2V0IGxpZmV0aW1lczwvZm9udD4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbV8tNTk1NTAzMzE2MTY0ODcxMTI0NG1f MTk2MTA5ODI5MzY5ODkxNDE2OWdtYWlsLW1fMzk3NzI3MTEwMjY0NzQzODI4MUJvZHlGcmFnbWVu dCI+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KPGRpdiBj bGFzcz0ieF9tXy01OTU1MDMzMTYxNjQ4NzExMjQ0bV8xOTYxMDk4MjkzNjk4OTE0MTY5Z21haWwt bV8zOTc3MjcxMTAyNjQ3NDM4MjgxUGxhaW5UZXh0Ij4NCk9uIE1vbiwgSmFuIDI4LCAyMDE5IGF0 IDEwOjA0IFBNIFN1Ym9kaCBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnN1Ym9kaEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFNpbmNlIGNsaWVudHMgYWxyZWFkeSBzdG9yZSB0aWNrZXRzLCBjb3Vs ZCB0aGV5IG5vdCBhbHNvIHN0b3JlIHRoZTxicj4NCiZndDsgdGltZSBvZiBvcmlnaW5hbCB0aWNr ZXQgaXNzdWFuY2UgYW5kIGNhcCB0aGUgcmVzdW1wdGlvbiB3aW5kb3cgdG8gTjxicj4NCiZndDsg KDcpIGRheXMgZnJvbSB0aGF0IHBvaW50PyBUaGF0IGlzLCBpdCBzZWVtcyBjbGllbnRzIGNvdWxk IGltcGxlbWVudDxicj4NCiZndDsgdGhpcyBiZWhhdmlvciB3aXRob3V0IGFueSBwcm90b2NvbCBz dXBwb3J0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENvcnJlY3QsIGhvd2V2ZXIgdGhlIHNlcnZlciBj dXJyZW50bHkgcHJvdmlkZXMgYSB2YWx1ZSBmb3IgdGhpcywgYW5kIGNsaWVudHMgZG8gbm90IGVu Zm9yY2UgYSBsb3dlciBib3VuZCBvbiB0aGlzLiA3IGRheXMgaXMgYW4gdXBwZXIgYm91bmQuPGJy Pg0KJmd0OyBTZXJ2ZXJzIHdvdWxkIHByb3ZpZGUgYSBtdWNoIGxvd2VyIHZhbHVlIHRoYW4gNyBk YXlzIHByYWN0aWNhbGx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElmIEknbSB1bmRlcnN0YW5kaW5n IHlvdXIgc3VnZ2VzdGlvbiBjb3JyZWN0bHksIHlvdSdyZSBzdWdnZXN0aW5nIHRoYXQgY2xpZW50 cyBjaGFuZ2UgdGhlIG1lYW5pbmcgb2YgdGlja2V0X2xpZmV0aW1lX2hpbnQ/PGJyPg0KJmd0OyBU aGF0IGlzIG5vdCBqdXN0IGxpbWl0IGl0IHRvIHRoZSBzY29wZSBvZiB0aGUgdGlja2V0IGJ1dCB0 aGUgZW50aXJlIFRMUyBzZXNzaW9uPyBUaGF0IHdvdWxkIGJlIGZpbmUgdG8gYnkgbWUsIGhvd2V2 ZXIgbWlnaHQgYnJlYWsgc29tZSBmb2xrcy48YnI+DQo8YnI+DQpJZiBieSAmcXVvdDtlbnRpcmUg VExTIHNlc3Npb24mcXVvdDsgeW91IG1lYW4gdGhlIHJlc3VtZWQgKGFuZCByZW5ld2VkKTxicj4N CnNlc3Npb25zLCB0aGVuIHllcCE8YnI+DQo8YnI+DQpCZXN0LDxicj4NCkNocmlzPGJyPg0KPGJy Pg0KJmd0Ozxicj4NCiZndDsgU3Vib2RoPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgRnJvbTogQ2hyaXN0b3BoZXIgV29vZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdG9waGVyd29vZDA3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlz dG9waGVyd29vZDA3QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTZW50OiBNb25kYXksIEph bnVhcnkgMjgsIDIwMTkgOTo1NyBQTTxicj4NCiZndDsgVG86IFN1Ym9kaCBJeWVuZ2FyPGJyPg0K Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRs c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbVExTXSB0aWNrZXQgbGlmZXRp bWVzPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gTW9uLCBKYW4gMjgsIDIwMTkgYXQgOTo0MyBQTSBT dWJvZGggSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iIHRhcmdldD0i X2JsYW5rIj5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEluIFRMUyAxLjMgd2UgYWRkZWQgYSBtYXhpbXVtIGFnZSB0byB0aGUgdGlja2V0 IGxpZmV0aW1lIHRvIGJlIDcgZGF5cy4gVGhpcyBoYWQgc2V2ZXJhbCBvcmlnaW5hbCBtb3RpdmF0 aW9ucyBpbmNsdWRpbmcgcmVkdWNpbmcgdGhlIHRpbWUgdGhhdCBhIHRpY2tldCBpcyByZXVzZWQg KGZvciBwcml2YWN5IG9yIFBGUykuIEFub3RoZXIgbWFqb3IgbW90aXZhdGlvbiBmb3IgdGhpcyB3 YXMgdG8gbGltaXQgdGhlIGV4cG9zdXJlIG9mIHNlcnZlcnMNCiB0aGF0IHVzZSBrZXlsZXNzIHNz bCBsaWtlIG1lY2hhbmlzbXMsIGkuZS4gaWYgdGhleSBrZXB0IGEgU1RFSyBsb2NhbGx5LCBidXQg dGhlIGtleWxlc3MgU1NMIHNlcnZlciByZW1vdGVseSwgdGhlbiB0aGUgdGhlZnQgb2YgYSBTVEVL IHdvdWxkIHByZXN1bWFibHkgbGltaXQgdGhlIE1JVE0gY2FwYWJpbGl0aWVzIHRvIHRoZSB0aWNr ZXQgbGlmZXRpbWUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhvd2V2ZXIgdGhpbmtp bmcgYWJvdXQgaXQgc29tZSBtb3JlIGJlY2F1c2Ugb2YgdGhlIHJlbmV3YWwgY2FwYWJpbGl0eSBv ZiB0aWNrZXRzIGluIFRMUyAxLjMsIGFuIGVudGl0eSBvd25pbmcgdGhlIFNURUsgY291bGQganVz dCByZS1pc3N1ZSBuZXcgdGlja2V0cyBmb3JldmVyIG9uIGEgcmVzdW1lZCBjb25uZWN0aW9uLiBU aGlzIHdvdWxkIGxvb2sgdG8gdGhlIGNsaWVudCBhcyBhIG5ldyB0aWNrZXQgYW5kIGl0IHdvdWxk IHJlZnJlc2ggaXRzDQogbGlmZXRpbWUgb24gdGhlIHRpY2tldC4gVGhlcmVieSBhIE1JVE0gY291 bGQgaW50ZXJjZXB0IGNvbm5lY3Rpb25zIHRvIHVzZXJzIHRoYXQgaGF2ZSBiZWVuIHRvIHRoZSBz ZXJ2ZXIgd2l0aCB0aGUgU1RFSy4gSSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0IG1pZ2h0IGJlIHVz ZWZ1bCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdG8gbGltaXQgdGhlIGxpZmV0aW1lIG9mIGFsbCB0 aWNrZXQgcmVzdW1wdGlvbiBhY3Jvc3MgYWxsIHJlc3VtcHRpb25zIGZyb20NCiB0aGUgb3JpZ2lu YWwgY29ubmVjdGlvbiBpbnN0ZWFkIG9mIGp1c3QgdGhlIGxpbWl0ZWQgcGVyIHRpY2tldCBsaWZl dGltZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTaW5jZSBjbGllbnRzIGFscmVhZHkgc3RvcmUgdGlj a2V0cywgY291bGQgdGhleSBub3QgYWxzbyBzdG9yZSB0aGU8YnI+DQomZ3Q7IHRpbWUgb2Ygb3Jp Z2luYWwgdGlja2V0IGlzc3VhbmNlIGFuZCBjYXAgdGhlIHJlc3VtcHRpb24gd2luZG93IHRvIE48 YnI+DQomZ3Q7ICg3KSBkYXlzIGZyb20gdGhhdCBwb2ludD8gVGhhdCBpcywgaXQgc2VlbXMgY2xp ZW50cyBjb3VsZCBpbXBsZW1lbnQ8YnI+DQomZ3Q7IHRoaXMgYmVoYXZpb3Igd2l0aG91dCBhbnkg cHJvdG9jb2wgc3VwcG9ydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXN0LDxicj4NCiZndDsgQ2hy aXM8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMm YW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9aDNKdTlFQlM3 bUh0d2ctd0F5TjdmUSZhbXA7bT1BZUhwa1lYd1F0RjREamZxZEhObHVPTEljVEhPRFRpaG43aTRX Qnp1Y2pBJmFtcDtzPUI0ekw2RW12MGp5aEFzdUp5Qm54TXpPOGwxdzdTRHU1T3BCNG04amFyTWsm YW1wO2U9IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExT IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb190bHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1w O3I9aDNKdTlFQlM3bUh0d2ctd0F5TjdmUSZhbXA7bT1BZUhwa1lYd1F0RjREamZxZEhObHVPTElj VEhPRFRpaG43aTRXQnp1Y2pBJmFtcDtzPUI0ekw2RW12MGp5aEFzdUp5Qm54TXpPOGwxdzdTRHU1 T3BCNG04amFyTWsmYW1wO2U9IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczxicj4NCjwvYT48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_MWHPR15MB18215B0C046B3ADFA88F0FC4B6970MWHPR15MB1821namp_-- From nobody Tue Jan 29 14:52:52 2019 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 3B3EC131029 for ; Tue, 29 Jan 2019 14:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.082 X-Spam-Level: X-Spam-Status: No, score=-11.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 QKSeL0GSO4yy for ; Tue, 29 Jan 2019 14:52:46 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 68C6D130FE5 for ; Tue, 29 Jan 2019 14:52:46 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id t13so24244454qtn.3 for ; Tue, 29 Jan 2019 14:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LVMTZL/+GvWcR4zVa34ej5VSO9Bf+SG+xO3/Ystk6Tw=; b=PLZIpBzR0oL52R/9oN0QpojN1NRE+iy8nMaSjKP/Gb7J9GIuFTY5fRFxI2jUiTtUUB D1hqINQ0BDBGLqwSCXHOgO3Jkwjs5B8F9WncL895+YYGiT22KzD5w+FqHUh/lT9AFnMT 6IfVh7C38KCYsIPmMwDK1KhABo9HHZh73yY/M= 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=LVMTZL/+GvWcR4zVa34ej5VSO9Bf+SG+xO3/Ystk6Tw=; b=c9eHxKRKO6pxWVmYy5vtySrmVxr7tVqAV8DgcPfqYaQgcbPnp0ORE98otNYQrq/cf7 sHzAJpCetnx8GiF51Yms+D5k/z/ZMpzK4ixy5kpRFIwSf2krjbyNOf9Z2ry2Z/9GFo0O Xhozt5/GxoDu07WXaIAOu8YkrfnPmRWMHlxf/azYdYyNzIZiONGHZG0B54foRUQWWMvc rvGLPbEC+zhBxEUY5RVQoVlPx7IJ/QQZpaFhXN4REhsosOJaHb/Gd1AsYiNFqN+6TI0F QACyuJs7l/1aBVkypx3ayjU8jC9pUJKupvx+ZNfHU20+90aS6bOhlMa3j+gNZ5qDxWPX hWYw== X-Gm-Message-State: AJcUukeGvR98PHHV/0Bz3X/13Cn35vJX/6ORAhFp0RsZ47lsgExeFfSX 0sSgRlkfu9rT8M+IoQ7ivBhBFH+Q0jmsuKmXyYM7axQ= X-Google-Smtp-Source: ALg8bN5NrrK41xTnJpOkOgIBfKeOoDEvyZ7BBSAKzQ4CtCCBmCJ46XYH3cpjR8V/NYtTdC8zqF//3gRS4wjrWzOH/Mk= X-Received: by 2002:aed:3482:: with SMTP id x2mr26811906qtd.72.1548802365196; Tue, 29 Jan 2019 14:52:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 29 Jan 2019 16:52:32 -0600 Message-ID: To: Subodh Iyengar Cc: Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ceb18d0580a0a6b4" Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 22:52:50 -0000 --000000000000ceb18d0580a0a6b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar wrote: > > Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while? > > I think it's probably just easier to drop the resumption completely. > > > This two-lifetime thing is actually already what we implement in > BoringSSL. =F0=9F=98=8A > > Fantastic. Would it help to have an extension to set a lower bound on thi= s > value, or just make it more painful? > (Did you mean upper bound?) I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on the renewability, but apparently that's not how others read it! I don't care strongly either way about an extension to set a renewal bound, I think. A client is always free to tighten ticket lifetime policies unilaterally. We don't need an extension to advertise its policies unless we want to allow server to change their behavior in response. In the other direction, if we think the server may also have an opinion on renewability (you mention keyless things), a NewSessionTicket extension would be easy to support. The client would then use the more restrictive of the server's preferences and its local policy. Though, I guess, having not specified it this way from the start, the server can't be sure the client honors the extension. I don't know what consequences that has for server-preference scenario. (For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals to extend lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are capped much more tightly. Since TLS 1.2 resumption doesn't involve an ECDH operation, any concerns about a stale online signature are overshadowed by how much data the client is willing to make vulnerable to a single session secret. We'd probably do something similar if we implemented TLS 1.3's plain psk_ke, but we only do psk_dhe_ke.) David > Subodh > ------------------------------ > *From:* David Benjamin > *Sent:* Tuesday, January 29, 2019 1:02 PM > *To:* Nick Sullivan > *Cc:* Subodh Iyengar; tls@ietf.org > > *Subject:* Re: [TLS] ticket lifetimes > This two-lifetime thing is actually already what we implement in > BoringSSL. :-) We track both a lifetime for the ticket (one day) and also > for the original authentication the ticket roots up to (one week). The > lifetime of the ticket is bounded by both these values, and the latter is > not extendable on renew. > > On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan 40cloudflare.com@dmarc.ietf.org> wrote: > > Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while? > > > Existing servers won't do this, so I see this less as a mitigation and > more as an optimization to plug the one-week-cliff that the fix produces. > But, yeah, that would be handy. (Probably something like: "re"-auth'd > identity apply to tickets, PSK applies to connection. Client sends an > extension to advertise we're nearing the unrenewable bound.) > > David > > > Nick > > On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar wrote: > > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Ya I think that'd need a new draft either way. Can definitely write that = up > if people don't think it's the worst idea in the world. > > Subodh > ------------------------------ > *From:* Christopher Wood > *Sent:* Monday, January 28, 2019 10:13:36 PM > *To:* Subodh Iyengar > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: > > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Correct, however the server currently provides a value for this, and > clients do not enforce a lower bound on this. 7 days is an upper bound. > > Servers would provide a much lower value than 7 days practically. > > > > If I'm understanding your suggestion correctly, you're suggesting that > clients change the meaning of ticket_lifetime_hint? > > That is not just limit it to the scope of the ticket but the entire TLS > session? That would be fine to by me, however might break some folks. > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Best, > Chris > > > > > Subodh > > ________________________________ > > From: Christopher Wood > > Sent: Monday, January 28, 2019 9:57 PM > > To: Subodh Iyengar > > Cc: tls@ietf.org > > Subject: Re: [TLS] ticket lifetimes > > > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > > > > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days= . > This had several original motivations including reducing the time that a > ticket is reused (for privacy or PFS). Another major motivation for this > was to limit the exposure of servers that use keyless ssl like mechanisms= , > i.e. if they kept a STEK locally, but the keyless SSL server remotely, th= en > the theft of a STEK would presumably limit the MITM capabilities to the > ticket lifetime. > > > > > > However thinking about it some more because of the renewal capability > of tickets in TLS 1.3, an entity owning the STEK could just re-issue new > tickets forever on a resumed connection. This would look to the client as= a > new ticket and it would refresh its lifetime on the ticket. Thereby a MIT= M > could intercept connections to users that have been to the server with th= e > STEK. I'm wondering whether it might be useful to define a mechanism to > limit the lifetime of all ticket resumption across all resumptions from t= he > original connection instead of just the limited per ticket lifetime. > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Best, > > Chris > _______________________________________________ > 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 > > > > --000000000000ceb18d0580a0a6b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar <subodh@fb.com> wrote:
> Wouldn't this issue also be mitigated by requiring the server to r= e-authenticate during resumption with the certificate once in a while?
I think it's probably just easier to drop the resumption completely.=C2= =A0

>=C2=A0This two-lifetime thing is actually already what we implement in BoringSSL. =F0=9F=98=8A

Fantastic. Would it help to have an extension to set a lower bound on this value, or = just make it more painful?

<= /div>
(Did you mean upper bound?)

I'd actu= ally interpreted the RFC 8446 text to imply a 7 day upper bound on the rene= wability, but apparently that's not how others read it! I don't car= e strongly either way about an extension to set a renewal bound, I think. A= client is always free to tighten ticket lifetime policies unilaterally. We= don't need an extension to advertise its policies unless we want to al= low server to change their behavior in response. In the other direction, if= we think the server may also have an opinion on renewability (you mention = keyless things), a NewSessionTicket extension would be easy to support. The= client would then use the more restrictive of the server's preferences= and its local policy.

Though, I guess, having not= specified it this way from the start, the server can't be sure the cli= ent honors the extension. I don't know what consequences that has for s= erver-preference scenario.

(For completeness, Bori= ngSSL doesn't allow TLS 1.2 ticket renewals to extend lifetime at all, = only TLS 1.3, and TLS 1.2 lifetimes are=C2=A0capped much more tightly. Sinc= e TLS 1.2 resumption doesn't involve an ECDH operation, any concerns ab= out a stale online signature are overshadowed by how much data the client i= s willing to make vulnerable to a single session secret. We'd probably = do something similar if we implemented TLS 1.3's plain=C2=A0psk_ke, but= we only do psk_dhe_ke.)

David
=C2=A0
Subodh
From:= David Benjamin <davidben@chromium.org>
Sent: Tuesday, January 29, 2019 1:02 PM
To: Nick Sullivan
Cc: Subodh Iyengar; tls@ietf.org

Subject: Re: [TLS] ticket lifetimes
This two-lifetime thing is actually already what we implem= ent in BoringSSL. :-) We track both a lifetime for the ticket (one day) and= also for the original authentication the ticket roots up to (one week). Th= e lifetime of the ticket is bounded by both these values, and the latter is not extendable on renew.

On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan <nick=3D40cloudflare.com@dm= arc.ietf.org> wrote:
Wouldn't this issue also be mitigated by requiring the server to r= e-authenticate during resumption with the certificate once in a while?

Existing servers won't do this, so I see this less as a mitigation= and more as an optimization to plug the one-week-cliff that the fix produc= es. But, yeah, that would be handy. (Probably something like: "re"= ;-auth'd identity apply to tickets, PSK applies to connection. Client sends an extension to advertise we're nearing th= e unrenewable bound.)

David
=C2=A0
Nick

On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyeng= ar <subodh@fb.com= > wrote:
>=C2=A0If by "entire TLS session" you mean = the resumed (and renewed)
sessions, then yep!

Ya I think that'd = need a new draft either way. Can definitely write that up
if people don't th= ink it's the worst idea in the world.

Subodh
From: Christopher Wood <christopherwood07@gmail.com>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
=C2=A0
On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <subodh@fb.com> wrote:
>
> > Since clients already store tickets, could they not also store th= e
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and c= lients do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggest= ing that clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TL= S session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________________________________
> From: Christopher Wood <christopherwood07@gmail.com>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org=
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 = days. This had several original motivations including reducing the time tha= t a ticket is reused (for privacy or PFS). Another major motivation for thi= s was to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, bu= t the keyless SSL server remotely, then the theft of a STEK would presumabl= y limit the MITM capabilities to the ticket lifetime.
> >
> > However thinking about it some more because of the renewal capabi= lity of tickets in TLS 1.3, an entity owning the STEK could just re-issue n= ew tickets forever on a resumed connection. This would look to the client a= s a new ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it = might be useful to define a mechanism to limit the lifetime of all ticket r= esumption across all resumptions from the original connection instead of just the limited per ticket lifetime. >
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Best,
> Chris
_______________________________________________
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

--000000000000ceb18d0580a0a6b4-- From nobody Tue Jan 29 20:29:22 2019 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 ECA6213104F for ; Tue, 29 Jan 2019 20:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, 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=fb.com header.b=BjIHzJtl; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=hXe1R5r7 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 dsBd9OcNmvfm for ; Tue, 29 Jan 2019 20:29:17 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 B102413100D for ; Tue, 29 Jan 2019 20:29:17 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0U4Q7Se030487; Tue, 29 Jan 2019 20:29:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=lDbzn3Z32QOS1P9ZZYNN6+ovW+J9kow4p/2vQjGXwgQ=; b=BjIHzJtlDwoOCvG+IZB/uTfs/zaSXzJuyNlmmhKSLHatTawNdgwh0aZPmOPsgMGXCsvE lBdiJXhZA6KT48JKaLgC4swT18FO96mv5GTFVUgCjU2czLlYSSDU4w7NPedBijGvPk+m 7hpZ0YkOm6unA4ccmFfu5QAirz6tpx4ajK4= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2qb1ug8f9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Jan 2019 20:29:16 -0800 Received: from prn-hub06.TheFacebook.com (2620:10d:c081:35::130) by prn-hub06.TheFacebook.com (2620:10d:c081:35::130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3; Tue, 29 Jan 2019 20:29:15 -0800 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1531.3 via Frontend Transport; Tue, 29 Jan 2019 20:29:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lDbzn3Z32QOS1P9ZZYNN6+ovW+J9kow4p/2vQjGXwgQ=; b=hXe1R5r75Fb3QM3bU6+rd7RQ4Sg3hiU4PLcqkAMuL61cV1g/1jcTUmVJgALgiwpCkIkDuo+gOh2mk113sOOqU+uaik63ZCzO0E8WO0jZl6kJYlCPcuU0dkMi28OJWRbErlsNPF/xL9VBlTsry4ZN4vZwrgSuu3kflXUqDmFh5wE= Received: from CY4PR15MB1814.namprd15.prod.outlook.com (10.174.54.11) by CY4PR15MB1941.namprd15.prod.outlook.com (10.172.179.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.23; Wed, 30 Jan 2019 04:28:54 +0000 Received: from CY4PR15MB1814.namprd15.prod.outlook.com ([fe80::84a6:7d5b:d837:8051]) by CY4PR15MB1814.namprd15.prod.outlook.com ([fe80::84a6:7d5b:d837:8051%4]) with mapi id 15.20.1558.021; Wed, 30 Jan 2019 04:28:54 +0000 From: Subodh Iyengar To: David Benjamin CC: Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] ticket lifetimes Thread-Index: AQHUt5PbJPg1BCv4IU2K+uhv0WevMqXFv9eAgAAArOaAAAPeAIAA1cE8gAAWPACAAAw/AIAAE3GsgAALbQCAAAUm9w== Date: Wed, 30 Jan 2019 04:28:54 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.77.211.173] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1941; 20:0ygt1cp153pSfc8KR1EI1LjsWXgRh9rV38/FYrC/e3ji8LcBVUIcFMHoAViEuWsYH+L3wgCns9csTj30HLHDN2UBf8WvXFMixEFbS1FdIxbRf4f84wyISqJRu6SDk7We2BAvVuA+5W+cHSkYx94VAq/LpjCcMKru0TY8moqqVdE= x-ms-office365-filtering-correlation-id: 798b2058-cbad-478a-c260-08d6866b719e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1941; x-ms-traffictypediagnostic: CY4PR15MB1941: x-microsoft-antispam-prvs: x-forefront-prvs: 0933E9FD8D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(396003)(136003)(346002)(199004)(189003)(51444003)(6916009)(19627405001)(81166006)(76176011)(86362001)(102836004)(106356001)(6606003)(105004)(26005)(446003)(105586002)(606006)(186003)(316002)(25786009)(33656002)(6506007)(53546011)(68736007)(6436002)(9686003)(54896002)(6486002)(236005)(6306002)(14454004)(6512007)(478600001)(966005)(71200400001)(71190400001)(97736004)(66066001)(6246003)(14444005)(8936002)(4326008)(3846002)(8676002)(6116002)(256004)(81156014)(229853002)(5070765005)(74316002)(1015004)(54906003)(7736002)(486006)(2906002)(11346002)(476003)(93886005)(99286004)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1941; H:CY4PR15MB1814.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: s37UsSf0kUR4MO0U15snUags5JGB+52UV2FFPZfCMeDkDgS2ElKX7d7OVBlFOcSFxsRikEUzfzzV+g7kOm2TcgVLJW/nIu0RhSm8EsDktvHLAv0+KV0E6sZOd+ZEsyzSwaYEzs6E1LEDNWi7aKWNbKE0WESxf8vA+M/e+TBX0E3dsIipga+EjDlZKyE4SRbY2YUAxlIvxOhzYkHoZpdfA01UBs58IV2segSqTje2TgjhwmC+x8EOSZceQG7X4EL/9XWtnweibaejeNQbwlpGnOyZIPtMe0CX3xpzyy740W3YkG4FPaWk1fbWPBOVDeDGHlj7PPs+uVgkROWa6G58E01kvxV7wA9tSnFA62q/AaLGZdKW1blqIT/YbHsH7Nno1qJH8vqiCi40BJKAeX920+CMNeSN2uzXL7H1VwxNaO4= Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18217B38EB252E42AFDC65BDB6970MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 798b2058-cbad-478a-c260-08d6866b719e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2019 04:28:54.4575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1941 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-30_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 04:29:21 -0000 --_000_MWHPR15MB18217B38EB252E42AFDC65BDB6970MWHPR15MB1821namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KERpZCB5b3UgbWVhbiB1cHBlciBib3VuZD8pDQo+IE5hIEkgbWVhbnQgbG93ZXIgYm91bmQuIFRo YXQgaXMgc3VjaCBhbiBleHRlbnNpb24gd291bGQgYmUgdXNlbGVzcyBpZiB0aGUgdGltZSB0aGUg c2VydmVyIG1lbnRpb25lZCA+IHRpbWUgdGhlIGNsaWVudCBkZWNpZGVkIHRvIGNhY2hlIGl0LiBI b3dldmVyIHRoZSBzZXJ2ZXIgbWlnaHQgYWR2ZXJ0aXNlIGEgdGltZSA8IHRpbWUgdGhlIGNsaWVu dCBkZWNpZGVkIHRvIGNhY2hlIGl0LCBpbiB3aGljaCBpdCB3b3VsZCBiZSB1c2VmdWwuDQoNCj4g SSdkIGFjdHVhbGx5IGludGVycHJldGVkIHRoZSBSRkMgODQ0NiB0ZXh0IHRvIGltcGx5IGEgNyBk YXkgdXBwZXIgYm91bmQgb24gdGhlIHJlbmV3YWJpbGl0eSwgYnV0IGFwcGFyZW50bHkgdGhhdCdz IG5vdCBob3cgb3RoZXJzIHJlYWQgaXQhDQo+DQpUaG91Z2gsIEkgZ3Vlc3MsIGhhdmluZyBub3Qg c3BlY2lmaWVkIGl0IHRoaXMgd2F5IGZyb20gdGhlIHN0YXJ0LCB0aGUgc2VydmVyIGNhbid0IGJl IHN1cmUgdGhlIGNsaWVudCBob25vcnMgdGhlIGV4dGVuc2lvbi4gSSBkb24ndCBrbm93IHdoYXQg Y29uc2VxdWVuY2VzIHRoYXQgaGFzIGZvciBzZXJ2ZXItcHJlZmVyZW5jZSBzY2VuYXJpby4NCg0K WXVwIEkgdGhpbmsgdGhlcmUgaXMgYSBkaXNjb25uZWN0IGJldHdlZW4gdGhlIGludGVudGlvbiBv ZiB0aGUgc2VydmVyIG9wZXJhdG9yIGFuZCB0aGUgcHJvdG9jb2wuIFRoYXQgaXMgdGhlIHNlcnZl ciBvcGVyYXRvciB3b3VsZCBsaWtlIHRvIGhhdmUgb25seSA3IGRheSB1c2VzIG9mIHRoZSBQU0ss IGhvd2V2ZXIgdW5iZWtub3duc3QgdG8gdGhlbiwgdGhlaXIgbGlicmFyeSBpcyByZW5ld2luZyB0 aGUgdGlja2V0IGFuZCBleHRlbmRpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBQU0suIFRoaXMgZGlz Y29ubmVjdCBleGlzdHMgaW4gYm90aCBUTFMgMS4yIGFuZCAxLjMsIGhvd2V2ZXIgZm9yIFRMUyAx LjIgdGhlIHJlbmV3YWwgb2YgdGlja2V0cyBpcyBsZXNzIHdpZGVseSBkZXBsb3llZCB0aGFuIGl0 IHNob3VsZCBiZSBiZWNhdXNlIG9mIHNvbWUgaGlzdG9yaWMgY2xpZW50IGludG9sZXJhbmNlIG9m IGl0Lg0KDQpJIHRoaW5rIHRoZSBpbnRlcnByZXRhdGlvbiB0aGF0IHRoZSBsaWZldGltZSBhcHBs aWVzIHRvIHRoZSBjdXJyZW50IHRpY2tldCBvbmx5IGlzIHRoZSBtb3JlIGNvbW1vbiBpbnRlcnBy ZXRhdGlvbi4gSSBkaWQgYSBzaG9ydCBzdHVkeSBvZiBzZXZlcmFsIFRMUyAxLjMgaW1wbGVtZW50 YXRpb24gc2hhbmRsaW5nIG9mIHRpY2tldCBsaWZldGltZXMgYnkgc3RhcmluZyBhdCBzb21lIGNv ZGUgcmVhbGx5IGludGVuc2VseToNCg0KT3BlblNTTDoNCkxlYXZlcyB0aWNrZXQgbWFuYWdlbWVu dCBvbiB0aGUgY2xpZW50IHRvIHRoZSBjYWxsZXIgdmlhIGNhbGxiYWNrcyBhbmQgZG9lc24ndCBl bmZvcmNlIGFueXRoaW5nIGJ5IGl0c2VsZi4NCg0KTlNTOg0KTG9va3MgbGlrZSBpdCB0cmVhdHMg dGhlIGxpZmV0aW1lIG9mIGVhY2ggdGlja2V0IGluZGVwZW5kZW50bHkgYW5kIGVuZm9yY2VzIHRo ZSB0aWNrZXQgbGlmZXRpbWUuDQoNCmh0dHBzOi8vZHhyLm1vemlsbGEub3JnL21vemlsbGEtY2Vu dHJhbC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wvdGxzMTNjb24uYyM0NTkNCjxodHRwczov L2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIv c3NsL3NzbG5vbmNlLmMjNzI2Pmh0dHBzOi8vZHhyLm1vemlsbGEub3JnL21vemlsbGEtY2VudHJh bC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wvc3Nsbm9uY2UuYyMxMjAyDQpodHRwczovL2R4 ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3Ns L3RsczEzY29uLmMjNDY2MQ0KDQoNCk9wZW5KREs6DQpJZ25vcmVzIGxpZmV0aW1lIGhpbnQgYWZ0 ZXIgY2hlY2tpbmcgdGhhdCBpdCBpcyA8IDcgZGF5cyBhbmQgdGhlbiB1c2VzIGEgamRrIHNwZWNp ZmllZCB0aW1lb3V0IHdoaWNoIGlzIGEgZGVmYXVsdCBvZiAxIGRheQ0KDQpodHRwOi8vaGcub3Bl bmpkay5qYXZhLm5ldC9qZGsvamRrMTEvZmlsZS82OGZhM2Q0MDI2ZWEvc3JjL2phdmEuYmFzZS9z aGFyZS9jbGFzc2VzL3N1bi9zZWN1cml0eS9zc2wvTmV3U2Vzc2lvblRpY2tldC5qYXZhI2wzMzYN Cmh0dHA6Ly9oZy5vcGVuamRrLmphdmEubmV0L2pkay9qZGsxMS9maWxlLzY4ZmEzZDQwMjZlYS9z cmMvamF2YS5iYXNlL3NoYXJlL2NsYXNzZXMvc3VuL3NlY3VyaXR5L3NzbC9TU0xTZXNzaW9uQ29u dGV4dEltcGwuamF2YSNsNjUNCg0KDQpib3Jpbmdzc2w6DQoNCkhhcyB0aGUgYWJpbGl0eSB0byB1 c2UgYW4gaW50ZXJuYWwgc2Vzc2lvbiBjYWNoZS4gQmVmb3JlIGl0IHVzZXMgYSB0aWNrZXQgaXQg Y2hlY2tzIHRoZSBzZXNzaW9uIHRpbWVvdXQgYWdhaW5zdCBjdXJyZW50IHRpbWUuIEV2ZXJ5dGlt ZSBpdCByZWNlaXZlcyBhIG5ldyBzZXNzaW9uIHRpY2tldCBpdCBjbGFtcHMgdGhlIFNTTF9TRVNT SU9OJ3MgdGltZW91dCB1c2luZyBzc2xfc2Vzc2lvbl9yZWJhc2VfdGltZSBhbmQgdGhlbiBjbGVh cnMgYW55IHRpbWVkIG91dCB0aWNrZXRzIHdpdGggU1NMX0NUWF9mbHVzaF9zZXNzaW9ucy4NCg0K Rml6ejoNCg0KVHJlYXRzIGVhY2ggdGlja2V0IGxpZmV0aW1lIGluZGVwZW5kZW50bHkuDQoNCm1i ZWQgdGxzOg0KTGVhdmVzIGl0IHRvIGNhbGxlciB3aXRoIG1iZWR0bHNfc3NsX2NvbmZfc2Vzc2lv bl9jYWNoZS4gIEhvd2V2ZXIgdGhlIEFQSSBkb2Vzbid0IGFsbG93IG1iZWR0bHMgdG8gdmVyaWZ5 IHdoZXRoZXIgb3Igbm90IHRoZSB0aWNrZXRfbGlmZXRpbWUgaGFzIGV4Y2VlZGVkIGFuZCBpdHMg dXAgdG8gdGhlIGNhbGxlciB0byB2ZXJpZnkgdGhpcy4NCg0KU2VlbXMgbGlrZSB0aGVyZSBpcyBy b29tIGZvciBjbGFyaWZpY2F0aW9uIG9uIHRoZSB0aWNrZXQgbGlmZXRpbWUuDQoNClN1Ym9kaA0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IERhdmlkIEJlbmphbWluIDxk YXZpZGJlbkBjaHJvbWl1bS5vcmc+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDI6 NTIgUE0NClRvOiBTdWJvZGggSXllbmdhcg0KQ2M6IE5pY2sgU3VsbGl2YW47IHRsc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtUTFNdIHRpY2tldCBsaWZldGltZXMNCg0KT24gVHVlLCBKYW4gMjks IDIwMTkgYXQgNDoxNCBQTSBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vi b2RoQGZiLmNvbT4+IHdyb3RlOg0KPiBXb3VsZG4ndCB0aGlzIGlzc3VlIGFsc28gYmUgbWl0aWdh dGVkIGJ5IHJlcXVpcmluZyB0aGUgc2VydmVyIHRvIHJlLWF1dGhlbnRpY2F0ZSBkdXJpbmcgcmVz dW1wdGlvbiB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSBvbmNlIGluIGEgd2hpbGU/DQoNCkkgdGhpbmsg aXQncyBwcm9iYWJseSBqdXN0IGVhc2llciB0byBkcm9wIHRoZSByZXN1bXB0aW9uIGNvbXBsZXRl bHkuDQoNCj4gVGhpcyB0d28tbGlmZXRpbWUgdGhpbmcgaXMgYWN0dWFsbHkgYWxyZWFkeSB3aGF0 IHdlIGltcGxlbWVudCBpbiBCb3JpbmdTU0wuIPCfmIoNCg0KRmFudGFzdGljLiBXb3VsZCBpdCBo ZWxwIHRvIGhhdmUgYW4gZXh0ZW5zaW9uIHRvIHNldCBhIGxvd2VyIGJvdW5kIG9uIHRoaXMgdmFs dWUsIG9yIGp1c3QgbWFrZSBpdCBtb3JlIHBhaW5mdWw/DQoNCihEaWQgeW91IG1lYW4gdXBwZXIg Ym91bmQ/KQ0KDQpJJ2QgYWN0dWFsbHkgaW50ZXJwcmV0ZWQgdGhlIFJGQyA4NDQ2IHRleHQgdG8g aW1wbHkgYSA3IGRheSB1cHBlciBib3VuZCBvbiB0aGUgcmVuZXdhYmlsaXR5LCBidXQgYXBwYXJl bnRseSB0aGF0J3Mgbm90IGhvdyBvdGhlcnMgcmVhZCBpdCEgSSBkb24ndCBjYXJlIHN0cm9uZ2x5 IGVpdGhlciB3YXkgYWJvdXQgYW4gZXh0ZW5zaW9uIHRvIHNldCBhIHJlbmV3YWwgYm91bmQsIEkg dGhpbmsuIEEgY2xpZW50IGlzIGFsd2F5cyBmcmVlIHRvIHRpZ2h0ZW4gdGlja2V0IGxpZmV0aW1l IHBvbGljaWVzIHVuaWxhdGVyYWxseS4gV2UgZG9uJ3QgbmVlZCBhbiBleHRlbnNpb24gdG8gYWR2 ZXJ0aXNlIGl0cyBwb2xpY2llcyB1bmxlc3Mgd2Ugd2FudCB0byBhbGxvdyBzZXJ2ZXIgdG8gY2hh bmdlIHRoZWlyIGJlaGF2aW9yIGluIHJlc3BvbnNlLiBJbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCBp ZiB3ZSB0aGluayB0aGUgc2VydmVyIG1heSBhbHNvIGhhdmUgYW4gb3BpbmlvbiBvbiByZW5ld2Fi aWxpdHkgKHlvdSBtZW50aW9uIGtleWxlc3MgdGhpbmdzKSwgYSBOZXdTZXNzaW9uVGlja2V0IGV4 dGVuc2lvbiB3b3VsZCBiZSBlYXN5IHRvIHN1cHBvcnQuIFRoZSBjbGllbnQgd291bGQgdGhlbiB1 c2UgdGhlIG1vcmUgcmVzdHJpY3RpdmUgb2YgdGhlIHNlcnZlcidzIHByZWZlcmVuY2VzIGFuZCBp dHMgbG9jYWwgcG9saWN5Lg0KDQpUaG91Z2gsIEkgZ3Vlc3MsIGhhdmluZyBub3Qgc3BlY2lmaWVk IGl0IHRoaXMgd2F5IGZyb20gdGhlIHN0YXJ0LCB0aGUgc2VydmVyIGNhbid0IGJlIHN1cmUgdGhl IGNsaWVudCBob25vcnMgdGhlIGV4dGVuc2lvbi4gSSBkb24ndCBrbm93IHdoYXQgY29uc2VxdWVu Y2VzIHRoYXQgaGFzIGZvciBzZXJ2ZXItcHJlZmVyZW5jZSBzY2VuYXJpby4NCg0KKEZvciBjb21w bGV0ZW5lc3MsIEJvcmluZ1NTTCBkb2Vzbid0IGFsbG93IFRMUyAxLjIgdGlja2V0IHJlbmV3YWxz IHRvIGV4dGVuZCBsaWZldGltZSBhdCBhbGwsIG9ubHkgVExTIDEuMywgYW5kIFRMUyAxLjIgbGlm ZXRpbWVzIGFyZSBjYXBwZWQgbXVjaCBtb3JlIHRpZ2h0bHkuIFNpbmNlIFRMUyAxLjIgcmVzdW1w dGlvbiBkb2Vzbid0IGludm9sdmUgYW4gRUNESCBvcGVyYXRpb24sIGFueSBjb25jZXJucyBhYm91 dCBhIHN0YWxlIG9ubGluZSBzaWduYXR1cmUgYXJlIG92ZXJzaGFkb3dlZCBieSBob3cgbXVjaCBk YXRhIHRoZSBjbGllbnQgaXMgd2lsbGluZyB0byBtYWtlIHZ1bG5lcmFibGUgdG8gYSBzaW5nbGUg c2Vzc2lvbiBzZWNyZXQuIFdlJ2QgcHJvYmFibHkgZG8gc29tZXRoaW5nIHNpbWlsYXIgaWYgd2Ug aW1wbGVtZW50ZWQgVExTIDEuMydzIHBsYWluIHBza19rZSwgYnV0IHdlIG9ubHkgZG8gcHNrX2Ro ZV9rZS4pDQoNCkRhdmlkDQoNClN1Ym9kaA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc8bWFpbHRvOmRh dmlkYmVuQGNocm9taXVtLm9yZz4+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI5LCAyMDE5IDE6 MDIgUE0NClRvOiBOaWNrIFN1bGxpdmFuDQpDYzogU3Vib2RoIEl5ZW5nYXI7IHRsc0BpZXRmLm9y ZzxtYWlsdG86dGxzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW1RMU10gdGlja2V0IGxpZmV0 aW1lcw0KVGhpcyB0d28tbGlmZXRpbWUgdGhpbmcgaXMgYWN0dWFsbHkgYWxyZWFkeSB3aGF0IHdl IGltcGxlbWVudCBpbiBCb3JpbmdTU0wuIDotKSBXZSB0cmFjayBib3RoIGEgbGlmZXRpbWUgZm9y IHRoZSB0aWNrZXQgKG9uZSBkYXkpIGFuZCBhbHNvIGZvciB0aGUgb3JpZ2luYWwgYXV0aGVudGlj YXRpb24gdGhlIHRpY2tldCByb290cyB1cCB0byAob25lIHdlZWspLiBUaGUgbGlmZXRpbWUgb2Yg dGhlIHRpY2tldCBpcyBib3VuZGVkIGJ5IGJvdGggdGhlc2UgdmFsdWVzLCBhbmQgdGhlIGxhdHRl ciBpcyBub3QgZXh0ZW5kYWJsZSBvbiByZW5ldy4NCg0KT24gVHVlLCBKYW4gMjksIDIwMTkgYXQg MjoxOCBQTSBOaWNrIFN1bGxpdmFuIDxuaWNrPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCldvdWxk bid0IHRoaXMgaXNzdWUgYWxzbyBiZSBtaXRpZ2F0ZWQgYnkgcmVxdWlyaW5nIHRoZSBzZXJ2ZXIg dG8gcmUtYXV0aGVudGljYXRlIGR1cmluZyByZXN1bXB0aW9uIHdpdGggdGhlIGNlcnRpZmljYXRl IG9uY2UgaW4gYSB3aGlsZT8NCg0KRXhpc3Rpbmcgc2VydmVycyB3b24ndCBkbyB0aGlzLCBzbyBJ IHNlZSB0aGlzIGxlc3MgYXMgYSBtaXRpZ2F0aW9uIGFuZCBtb3JlIGFzIGFuIG9wdGltaXphdGlv biB0byBwbHVnIHRoZSBvbmUtd2Vlay1jbGlmZiB0aGF0IHRoZSBmaXggcHJvZHVjZXMuIEJ1dCwg eWVhaCwgdGhhdCB3b3VsZCBiZSBoYW5keS4gKFByb2JhYmx5IHNvbWV0aGluZyBsaWtlOiAicmUi LWF1dGgnZCBpZGVudGl0eSBhcHBseSB0byB0aWNrZXRzLCBQU0sgYXBwbGllcyB0byBjb25uZWN0 aW9uLiBDbGllbnQgc2VuZHMgYW4gZXh0ZW5zaW9uIHRvIGFkdmVydGlzZSB3ZSdyZSBuZWFyaW5n IHRoZSB1bnJlbmV3YWJsZSBib3VuZC4pDQoNCkRhdmlkDQoNCk5pY2sNCg0KT24gVHVlLCBKYW4g MjksIDIwMTkgYXQgMTE6MDAgQU0gU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb208bWFpbHRv OnN1Ym9kaEBmYi5jb20+PiB3cm90ZToNCj4gSWYgYnkgImVudGlyZSBUTFMgc2Vzc2lvbiIgeW91 IG1lYW4gdGhlIHJlc3VtZWQgKGFuZCByZW5ld2VkKQ0Kc2Vzc2lvbnMsIHRoZW4geWVwIQ0KDQpZ YSBJIHRoaW5rIHRoYXQnZCBuZWVkIGEgbmV3IGRyYWZ0IGVpdGhlciB3YXkuIENhbiBkZWZpbml0 ZWx5IHdyaXRlIHRoYXQgdXANCmlmIHBlb3BsZSBkb24ndCB0aGluayBpdCdzIHRoZSB3b3JzdCBp ZGVhIGluIHRoZSB3b3JsZC4NCg0KU3Vib2RoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogQ2hyaXN0b3BoZXIgV29vZCA8Y2hyaXN0b3BoZXJ3b29kMDdAZ21haWwuY29t PG1haWx0bzpjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5jb20+Pg0KU2VudDogTW9uZGF5LCBKYW51 YXJ5IDI4LCAyMDE5IDEwOjEzOjM2IFBNDQpUbzogU3Vib2RoIEl5ZW5nYXINCkNjOiB0bHNAaWV0 Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSB0aWNrZXQgbGlm ZXRpbWVzDQoNCk9uIE1vbiwgSmFuIDI4LCAyMDE5IGF0IDEwOjA0IFBNIFN1Ym9kaCBJeWVuZ2Fy IDxzdWJvZGhAZmIuY29tPG1haWx0bzpzdWJvZGhAZmIuY29tPj4gd3JvdGU6DQo+DQo+ID4gU2lu Y2UgY2xpZW50cyBhbHJlYWR5IHN0b3JlIHRpY2tldHMsIGNvdWxkIHRoZXkgbm90IGFsc28gc3Rv cmUgdGhlDQo+IHRpbWUgb2Ygb3JpZ2luYWwgdGlja2V0IGlzc3VhbmNlIGFuZCBjYXAgdGhlIHJl c3VtcHRpb24gd2luZG93IHRvIE4NCj4gKDcpIGRheXMgZnJvbSB0aGF0IHBvaW50PyBUaGF0IGlz LCBpdCBzZWVtcyBjbGllbnRzIGNvdWxkIGltcGxlbWVudA0KPiB0aGlzIGJlaGF2aW9yIHdpdGhv dXQgYW55IHByb3RvY29sIHN1cHBvcnQuDQo+DQo+IENvcnJlY3QsIGhvd2V2ZXIgdGhlIHNlcnZl ciBjdXJyZW50bHkgcHJvdmlkZXMgYSB2YWx1ZSBmb3IgdGhpcywgYW5kIGNsaWVudHMgZG8gbm90 IGVuZm9yY2UgYSBsb3dlciBib3VuZCBvbiB0aGlzLiA3IGRheXMgaXMgYW4gdXBwZXIgYm91bmQu DQo+IFNlcnZlcnMgd291bGQgcHJvdmlkZSBhIG11Y2ggbG93ZXIgdmFsdWUgdGhhbiA3IGRheXMg cHJhY3RpY2FsbHkuDQo+DQo+IElmIEknbSB1bmRlcnN0YW5kaW5nIHlvdXIgc3VnZ2VzdGlvbiBj b3JyZWN0bHksIHlvdSdyZSBzdWdnZXN0aW5nIHRoYXQgY2xpZW50cyBjaGFuZ2UgdGhlIG1lYW5p bmcgb2YgdGlja2V0X2xpZmV0aW1lX2hpbnQ/DQo+IFRoYXQgaXMgbm90IGp1c3QgbGltaXQgaXQg dG8gdGhlIHNjb3BlIG9mIHRoZSB0aWNrZXQgYnV0IHRoZSBlbnRpcmUgVExTIHNlc3Npb24/IFRo YXQgd291bGQgYmUgZmluZSB0byBieSBtZSwgaG93ZXZlciBtaWdodCBicmVhayBzb21lIGZvbGtz Lg0KDQpJZiBieSAiZW50aXJlIFRMUyBzZXNzaW9uIiB5b3UgbWVhbiB0aGUgcmVzdW1lZCAoYW5k IHJlbmV3ZWQpDQpzZXNzaW9ucywgdGhlbiB5ZXAhDQoNCkJlc3QsDQpDaHJpcw0KDQo+DQo+IFN1 Ym9kaA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBDaHJpc3Rv cGhlciBXb29kIDxjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5jb208bWFpbHRvOmNocmlzdG9waGVy d29vZDA3QGdtYWlsLmNvbT4+DQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyOCwgMjAxOSA5OjU3 IFBNDQo+IFRvOiBTdWJvZGggSXllbmdhcg0KPiBDYzogdGxzQGlldGYub3JnPG1haWx0bzp0bHNA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSB0aWNrZXQgbGlmZXRpbWVzDQo+DQo+IE9u IE1vbiwgSmFuIDI4LCAyMDE5IGF0IDk6NDMgUE0gU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5j b208bWFpbHRvOnN1Ym9kaEBmYi5jb20+PiB3cm90ZToNCj4gPg0KPiA+IEluIFRMUyAxLjMgd2Ug YWRkZWQgYSBtYXhpbXVtIGFnZSB0byB0aGUgdGlja2V0IGxpZmV0aW1lIHRvIGJlIDcgZGF5cy4g VGhpcyBoYWQgc2V2ZXJhbCBvcmlnaW5hbCBtb3RpdmF0aW9ucyBpbmNsdWRpbmcgcmVkdWNpbmcg dGhlIHRpbWUgdGhhdCBhIHRpY2tldCBpcyByZXVzZWQgKGZvciBwcml2YWN5IG9yIFBGUykuIEFu b3RoZXIgbWFqb3IgbW90aXZhdGlvbiBmb3IgdGhpcyB3YXMgdG8gbGltaXQgdGhlIGV4cG9zdXJl IG9mIHNlcnZlcnMgdGhhdCB1c2Uga2V5bGVzcyBzc2wgbGlrZSBtZWNoYW5pc21zLCBpLmUuIGlm IHRoZXkga2VwdCBhIFNURUsgbG9jYWxseSwgYnV0IHRoZSBrZXlsZXNzIFNTTCBzZXJ2ZXIgcmVt b3RlbHksIHRoZW4gdGhlIHRoZWZ0IG9mIGEgU1RFSyB3b3VsZCBwcmVzdW1hYmx5IGxpbWl0IHRo ZSBNSVRNIGNhcGFiaWxpdGllcyB0byB0aGUgdGlja2V0IGxpZmV0aW1lLg0KPiA+DQo+ID4gSG93 ZXZlciB0aGlua2luZyBhYm91dCBpdCBzb21lIG1vcmUgYmVjYXVzZSBvZiB0aGUgcmVuZXdhbCBj YXBhYmlsaXR5IG9mIHRpY2tldHMgaW4gVExTIDEuMywgYW4gZW50aXR5IG93bmluZyB0aGUgU1RF SyBjb3VsZCBqdXN0IHJlLWlzc3VlIG5ldyB0aWNrZXRzIGZvcmV2ZXIgb24gYSByZXN1bWVkIGNv bm5lY3Rpb24uIFRoaXMgd291bGQgbG9vayB0byB0aGUgY2xpZW50IGFzIGEgbmV3IHRpY2tldCBh bmQgaXQgd291bGQgcmVmcmVzaCBpdHMgbGlmZXRpbWUgb24gdGhlIHRpY2tldC4gVGhlcmVieSBh IE1JVE0gY291bGQgaW50ZXJjZXB0IGNvbm5lY3Rpb25zIHRvIHVzZXJzIHRoYXQgaGF2ZSBiZWVu IHRvIHRoZSBzZXJ2ZXIgd2l0aCB0aGUgU1RFSy4gSSdtIHdvbmRlcmluZyB3aGV0aGVyIGl0IG1p Z2h0IGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdG8gbGltaXQgdGhlIGxpZmV0aW1l IG9mIGFsbCB0aWNrZXQgcmVzdW1wdGlvbiBhY3Jvc3MgYWxsIHJlc3VtcHRpb25zIGZyb20gdGhl IG9yaWdpbmFsIGNvbm5lY3Rpb24gaW5zdGVhZCBvZiBqdXN0IHRoZSBsaW1pdGVkIHBlciB0aWNr ZXQgbGlmZXRpbWUuDQo+DQo+IFNpbmNlIGNsaWVudHMgYWxyZWFkeSBzdG9yZSB0aWNrZXRzLCBj b3VsZCB0aGV5IG5vdCBhbHNvIHN0b3JlIHRoZQ0KPiB0aW1lIG9mIG9yaWdpbmFsIHRpY2tldCBp c3N1YW5jZSBhbmQgY2FwIHRoZSByZXN1bXB0aW9uIHdpbmRvdyB0byBODQo+ICg3KSBkYXlzIGZy b20gdGhhdCBwb2ludD8gVGhhdCBpcywgaXQgc2VlbXMgY2xpZW50cyBjb3VsZCBpbXBsZW1lbnQN Cj4gdGhpcyBiZWhhdmlvciB3aXRob3V0IGFueSBwcm90b2NvbCBzdXBwb3J0Lg0KPg0KPiBCZXN0 LA0KPiBDaHJpcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb190bHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9aDNKdTlF QlM3bUh0d2ctd0F5TjdmUSZtPUFlSHBrWVh3UXRGNERqZnFkSE5sdU9MSWNUSE9EVGlobjdpNFdC enVjakEmcz1CNHpMNkVtdjBqeWhBc3VKeUJueE16TzhsMXc3U0R1NU9wQjRtOGphck1rJmU9Pg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls aW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X3RscyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1oM0p1OUVCUzdtSHR3Zy13 QXlON2ZRJm09QWVIcGtZWHdRdEY0RGpmcWRITmx1T0xJY1RIT0RUaWhuN2k0V0J6dWNqQSZzPUI0 ekw2RW12MGp5aEFzdUp5Qm54TXpPOGwxdzdTRHU1T3BCNG04amFyTWsmZT0+DQo= --_000_MWHPR15MB18217B38EB252E42AFDC65BDB6970MWHPR15MB1821namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFw cGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBjb2xvcjojMDAwMDAwOyBmb250 LWZhbWlseTpDYWxpYnJpLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMCwwLDApOyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1 NSwyNTUpOyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPihEaWQgeW91IG1lYW4gdXBwZXIgYm91 bmQ/KTwvc3Bhbj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0 OyBjb2xvcjojMDAwMDAwOyBmb250LWZhbWlseTpDYWxpYnJpLEhlbHZldGljYSxzYW5zLXNlcmlm Ij4NCjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7IGZvbnQtc2l6ZToxNXB4OyBi YWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGRpc3BsYXk6aW5saW5lIWltcG9ydGFu dCI+Jmd0OyBOYSBJIG1lYW50IGxvd2VyIGJvdW5kLiBUaGF0IGlzIHN1Y2ggYW4gZXh0ZW5zaW9u IHdvdWxkIGJlIHVzZWxlc3MgaWYgdGhlIHRpbWUgdGhlIHNlcnZlciBtZW50aW9uZWQgJmd0OyB0 aW1lIHRoZSBjbGllbnQgZGVjaWRlZCB0byBjYWNoZSBpdC4gSG93ZXZlcg0KIHRoZSBzZXJ2ZXIg bWlnaHQgYWR2ZXJ0aXNlIGEgdGltZSAmbHQ7IHRpbWUgdGhlIGNsaWVudCBkZWNpZGVkIHRvIGNh Y2hlIGl0LCBpbiB3aGljaCBpdCB3b3VsZCBiZSB1c2VmdWwuPC9zcGFuPjwvZGl2Pg0KPGRpdj48 c3BhbiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTsgZm9udC1zaXplOjE1cHg7IGJhY2tncm91bmQt Y29sb3I6cmdiKDI1NSwyNTUsMjU1KTsgZGlzcGxheTppbmxpbmUhaW1wb3J0YW50Ij48YnI+DQo8 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApOyBmb250LXNp emU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpOyBkaXNwbGF5OmlubGlu ZSFpbXBvcnRhbnQiPiZndDsmbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2Io MjU1LDI1NSwyNTUpOyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPkknZCBhY3R1YWxseSBpbnRl cnByZXRlZCB0aGUgUkZDIDg0NDYgdGV4dCB0byBpbXBseSBhIDcgZGF5IHVwcGVyIGJvdW5kDQog b24gdGhlIHJlbmV3YWJpbGl0eSwgYnV0IGFwcGFyZW50bHkgdGhhdCdzIG5vdCBob3cgb3RoZXJz IHJlYWQgaXQhJm5ic3A7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMw MDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTVweCI+Jmd0OyZuYnNwOzxicj4NCjxzcGFu IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGRpc3BsYXk6aW5saW5l IWltcG9ydGFudCI+VGhvdWdoLCBJIGd1ZXNzLCBoYXZpbmcgbm90IHNwZWNpZmllZCBpdCB0aGlz IHdheSBmcm9tIHRoZSBzdGFydCwgdGhlIHNlcnZlciBjYW4ndCBiZSBzdXJlIHRoZSBjbGllbnQg aG9ub3JzIHRoZSBleHRlbnNpb24uIEkgZG9uJ3Qga25vdyB3aGF0IGNvbnNlcXVlbmNlcyB0aGF0 IGhhcyBmb3Igc2VydmVyLXByZWZlcmVuY2UNCiBzY2VuYXJpby48L3NwYW4+PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTVweCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTsg ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50Ij48YnI+DQo8L3NwYW4+PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7IGZvbnQtc2l6ZToxNXB4OyBi YWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGRpc3BsYXk6aW5saW5lIWltcG9ydGFu dCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KTsgZGlzcGxh eTppbmxpbmUhaW1wb3J0YW50Ij5ZdXAgSSB0aGluayB0aGVyZSBpcyBhIGRpc2Nvbm5lY3QgYmV0 d2VlbiB0aGUgaW50ZW50aW9uIG9mIHRoZSBzZXJ2ZXINCiBvcGVyYXRvciBhbmQgdGhlIHByb3Rv Y29sLiBUaGF0IGlzIHRoZSBzZXJ2ZXIgb3BlcmF0b3Igd291bGQgbGlrZSB0byBoYXZlIG9ubHkg NyBkYXkgdXNlcyBvZiB0aGUgUFNLLCBob3dldmVyIHVuYmVrbm93bnN0IHRvIHRoZW4sIHRoZWly IGxpYnJhcnkgaXMgcmVuZXdpbmcgdGhlIHRpY2tldCBhbmQgZXh0ZW5kaW5nIHRoZSBsaWZldGlt ZSBvZiB0aGUgUFNLLiBUaGlzIGRpc2Nvbm5lY3QgZXhpc3RzIGluIGJvdGggVExTIDEuMiBhbmQg MS4zLCBob3dldmVyDQogZm9yIFRMUyAxLjIgdGhlIHJlbmV3YWwgb2YgdGlja2V0cyBpcyBsZXNz IHdpZGVseSBkZXBsb3llZCB0aGFuIGl0IHNob3VsZCBiZSBiZWNhdXNlIG9mIHNvbWUgaGlzdG9y aWMgY2xpZW50IGludG9sZXJhbmNlIG9mIGl0Ljwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8ZGl2Pjxz cGFuIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApOyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1j b2xvcjpyZ2IoMjU1LDI1NSwyNTUpOyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSk7IGRpc3BsYXk6aW5saW5lIWlt cG9ydGFudCI+PGJyPg0KPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMw MDAwMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTVweCI+SSB0aGluayB0aGUgaW50ZXJwcmV0 YXRpb24gdGhhdCB0aGUgbGlmZXRpbWUgYXBwbGllcyB0byB0aGUgY3VycmVudCB0aWNrZXQgb25s eSBpcyZuYnNwO3RoZSBtb3JlIGNvbW1vbiBpbnRlcnByZXRhdGlvbi4gSSBkaWQgYSBzaG9ydCBz dHVkeSBvZiBzZXZlcmFsIFRMUyAxLjMgaW1wbGVtZW50YXRpb24gc2hhbmRsaW5nIG9mIHRpY2tl dCBsaWZldGltZXMgYnkNCiBzdGFyaW5nIGF0IHNvbWUgY29kZSByZWFsbHkgaW50ZW5zZWx5Ojwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE1cHgiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1cHgiPk9wZW5TU0w6PC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTVweCI+TGVhdmVzIHRpY2tldCBtYW5hZ2VtZW50IG9uIHRoZSBjbGllbnQg dG8gdGhlIGNhbGxlciB2aWEgY2FsbGJhY2tzIGFuZCBkb2Vzbid0IGVuZm9yY2UgYW55dGhpbmcg YnkgaXRzZWxmLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMDAw Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1cHgiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1cHgi Pk5TUzo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNXB4Ij5Mb29rcyBsaWtlIGl0IHRyZWF0cyB0aGUgbGlmZXRp bWUgb2YgZWFjaCB0aWNrZXQgaW5kZXBlbmRlbnRseSBhbmQgZW5mb3JjZXMgdGhlIHRpY2tldCBs aWZldGltZS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNXB4Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNXB4Ij48 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGEgaHJlZj0iaHR0cHM6Ly9keHIubW96aWxsYS5vcmcvbW96 aWxsYS1jZW50cmFsL3NvdXJjZS9zZWN1cml0eS9uc3MvbGliL3NzbC90bHMxM2Nvbi5jIzQ1OSIg Y2xhc3M9Ik9XQUF1dG9MaW5rIiBpZD0iTFBsbmsyMzUwMjgiPmh0dHBzOi8vZHhyLm1vemlsbGEu b3JnL21vemlsbGEtY2VudHJhbC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wvdGxzMTNjb24u YyM0NTk8L2E+DQo8ZGl2Pjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE1cHgiPjxhIGhyZWY9Imh0dHBzOi8vZHhyLm1vemlsbGEub3JnL21vemlsbGEtY2VudHJh bC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wvc3Nsbm9uY2UuYyM3MjYiIGNsYXNzPSJPV0FB dXRvTGluayIgaWQ9IkxQbG5rMjIzMTAiPjwvYT48YSBocmVmPSJodHRwczovL2R4ci5tb3ppbGxh Lm9yZy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbG5vbmNl LmMjMTIwMiIgY2xhc3M9Ik9XQUF1dG9MaW5rIiBpZD0iTFBsbms2MjEzNDEiPmh0dHBzOi8vZHhy Lm1vemlsbGEub3JnL21vemlsbGEtY2VudHJhbC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wv c3Nsbm9uY2UuYyMxMjAyPC9hPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMDAwIj48YSBocmVmPSJodHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxh LWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3RsczEzY29uLmMjNDY2MSIgY2xh c3M9Ik9XQUF1dG9MaW5rIiBpZD0iTFBsbms1NjcxMiI+aHR0cHM6Ly9keHIubW96aWxsYS5vcmcv bW96aWxsYS1jZW50cmFsL3NvdXJjZS9zZWN1cml0eS9uc3MvbGliL3NzbC90bHMxM2Nvbi5jIzQ2 NjE8L2E+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpIj4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KSI+ DQpPcGVuSkRLOjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUs IDI1NSwgMjU1KSI+DQpJZ25vcmVzIGxpZmV0aW1lIGhpbnQgYWZ0ZXIgY2hlY2tpbmcgdGhhdCBp dCBpcyAmbHQ7IDcgZGF5cyBhbmQgdGhlbiB1c2VzIGEgamRrIHNwZWNpZmllZCB0aW1lb3V0IHdo aWNoIGlzIGEgZGVmYXVsdCBvZiAxIGRheTxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9oZy5v cGVuamRrLmphdmEubmV0L2pkay9qZGsxMS9maWxlLzY4ZmEzZDQwMjZlYS9zcmMvamF2YS5iYXNl L3NoYXJlL2NsYXNzZXMvc3VuL3NlY3VyaXR5L3NzbC9OZXdTZXNzaW9uVGlja2V0LmphdmEjbDMz NiIgc3R5bGU9Im1hcmdpbjogMHB4Ij5odHRwOi8vaGcub3Blbmpkay5qYXZhLm5ldC9qZGsvamRr MTEvZmlsZS82OGZhM2Q0MDI2ZWEvc3JjL2phdmEuYmFzZS9zaGFyZS9jbGFzc2VzL3N1bi9zZWN1 cml0eS9zc2wvTmV3U2Vzc2lvblRpY2tldC5qYXZhI2wzMzY8L2E+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmksIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpIj4NCjxhIGhyZWY9Imh0dHA6 Ly9oZy5vcGVuamRrLmphdmEubmV0L2pkay9qZGsxMS9maWxlLzY4ZmEzZDQwMjZlYS9zcmMvamF2 YS5iYXNlL3NoYXJlL2NsYXNzZXMvc3VuL3NlY3VyaXR5L3NzbC9TU0xTZXNzaW9uQ29udGV4dElt cGwuamF2YSNsNjUiIHN0eWxlPSJtYXJnaW46IDBweCI+aHR0cDovL2hnLm9wZW5qZGsuamF2YS5u ZXQvamRrL2pkazExL2ZpbGUvNjhmYTNkNDAyNmVhL3NyYy9qYXZhLmJhc2Uvc2hhcmUvY2xhc3Nl cy9zdW4vc2VjdXJpdHkvc3NsL1NTTFNlc3Npb25Db250ZXh0SW1wbC5qYXZhI2w2NTwvYT48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KYm9yaW5nc3Ns OjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGFzIHRoZSBhYmlsaXR5IHRvIHVzZSBh biBpbnRlcm5hbCBzZXNzaW9uIGNhY2hlLiBCZWZvcmUgaXQgdXNlcyBhIHRpY2tldCBpdCBjaGVj a3MgdGhlIHNlc3Npb24gdGltZW91dCBhZ2FpbnN0IGN1cnJlbnQgdGltZS4gRXZlcnl0aW1lIGl0 IHJlY2VpdmVzIGEgbmV3IHNlc3Npb24gdGlja2V0IGl0IGNsYW1wcyB0aGUgU1NMX1NFU1NJT04n cyB0aW1lb3V0IHVzaW5nJm5ic3A7c3NsX3Nlc3Npb25fcmViYXNlX3RpbWUgYW5kIHRoZW4gY2xl YXJzIGFueQ0KIHRpbWVkIG91dCB0aWNrZXRzIHdpdGgmbmJzcDtTU0xfQ1RYX2ZsdXNoX3Nlc3Np b25zLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rml6ejo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRyZWF0cyBlYWNoIHRpY2tldCBsaWZldGltZSBpbmRlcGVuZGVudGx5 LjwvZGl2Pg0KPGRpdj48dT48YnI+DQo8L3U+PC9kaXY+DQo8ZGl2Pm1iZWQgdGxzOjwvZGl2Pg0K PGRpdj5MZWF2ZXMgaXQgdG8gY2FsbGVyIHdpdGgmbmJzcDs8c3Bhbj5tYmVkdGxzX3NzbF9jb25m X3Nlc3Npb25fY2FjaGUuJm5ic3A7IEhvd2V2ZXIgdGhlIEFQSSBkb2Vzbid0IGFsbG93IG1iZWR0 bHMgdG8gdmVyaWZ5IHdoZXRoZXIgb3Igbm90IHRoZSB0aWNrZXRfbGlmZXRpbWUgaGFzIGV4Y2Vl ZGVkIGFuZCBpdHMgdXAgdG8gdGhlIGNhbGxlciB0byB2ZXJpZnkgdGhpcy48L3NwYW4+PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWVtcyBsaWtlIHRoZXJlIGlzIHJvb20gZm9yIGNs YXJpZmljYXRpb24gb24gdGhlIHRpY2tldCBsaWZldGltZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PlN1Ym9kaDwvZGl2Pg0KPGRpdiBpZD0iYXBwZW5kb25zZW5kIj48L2Rpdj4NCjxo ciB0YWJpbmRleD0iLTEiIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazsgd2lkdGg6OTglIj4N CjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBz YW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9t OjwvYj4gRGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVuQGNocm9taXVtLm9yZyZndDs8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyOSwgMjAxOSAyOjUyIFBNPGJyPg0KPGI+VG86 PC9iPiBTdWJvZGggSXllbmdhcjxicj4NCjxiPkNjOjwvYj4gTmljayBTdWxsaXZhbjsgdGxzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSB0aWNrZXQgbGlmZXRpbWVzPC9m b250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0K PGRpdiBjbGFzcz0ieF9nbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0ieF9nbWFp bF9hdHRyIj5PbiBUdWUsIEphbiAyOSwgMjAxOSBhdCA0OjE0IFBNIFN1Ym9kaCBJeWVuZ2FyICZs dDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSIgaWQ9IkxQbG5rMjU5MTMyIiBjbGFzcz0i T1dBQXV0b0xpbmsiPnN1Ym9kaEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJ4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Es c2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOjBweDsgZm9udC1zaXplOjE1cHg7IGNvbG9yOnJnYigzMywzMywzMyk7IGJhY2tn cm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSI+DQomZ3Q7IFdvdWxkbid0IHRoaXMgaXNzdWUg YWxzbyBiZSBtaXRpZ2F0ZWQgYnkgcmVxdWlyaW5nIHRoZSBzZXJ2ZXIgdG8gcmUtYXV0aGVudGlj YXRlIGR1cmluZyByZXN1bXB0aW9uIHdpdGggdGhlIGNlcnRpZmljYXRlIG9uY2UgaW4gYSB3aGls ZT88L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCkkgdGhpbmsgaXQncyBwcm9iYWJseSBqdXN0 IGVhc2llciB0byBkcm9wIHRoZSByZXN1bXB0aW9uIGNvbXBsZXRlbHkuJm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkVtb2ppRm9udCxDYWxpYnJpLEFyaWFsLEhlbHZldGljYSxzYW5z LXNlcmlmLCZxdW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7LCZxdW90O1NlZ29lIFVJIEVtb2pp JnF1b3Q7LE5vdG9Db2xvckVtb2ppLCZxdW90O1NlZ29lIFVJIFN5bWJvbCZxdW90OywmcXVvdDtB bmRyb2lkIEVtb2ppJnF1b3Q7LEVtb2ppU3ltYm9sczsgZm9udC1zaXplOjEycHQ7IGNvbG9yOnJn YigwLDAsMCkiPg0KJmd0OyZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzMsMzMsMzMpOyBm b250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpOyBkaXNwbGF5 OmlubGluZSFpbXBvcnRhbnQiPlRoaXMgdHdvLWxpZmV0aW1lIHRoaW5nIGlzIGFjdHVhbGx5IGFs cmVhZHkgd2hhdCB3ZSBpbXBsZW1lbnQgaW4gQm9yaW5nU1NMLg0KPHNwYW4+8J+Yijwvc3Bhbj48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpFbW9qaUZvbnQsQ2FsaWJyaSxB cmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiwmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90Oywm cXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxOb3RvQ29sb3JFbW9qaSwmcXVvdDtTZWdvZSBVSSBT eW1ib2wmcXVvdDssJnF1b3Q7QW5kcm9pZCBFbW9qaSZxdW90OyxFbW9qaVN5bWJvbHM7IGZvbnQt c2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzMs MzMsMzMpOyBmb250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUp OyBkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQiPjxzcGFuPjxicj4NCjwvc3Bhbj48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpFbW9qaUZvbnQsQ2FsaWJyaSxBcmlhbCxIZWx2 ZXRpY2Esc2Fucy1zZXJpZiwmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OywmcXVvdDtTZWdv ZSBVSSBFbW9qaSZxdW90OyxOb3RvQ29sb3JFbW9qaSwmcXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVv dDssJnF1b3Q7QW5kcm9pZCBFbW9qaSZxdW90OyxFbW9qaVN5bWJvbHM7IGZvbnQtc2l6ZToxMnB0 OyBjb2xvcjpyZ2IoMCwwLDApIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzMsMzMsMzMpOyBm b250LXNpemU6MTVweDsgYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpOyBkaXNwbGF5 OmlubGluZSFpbXBvcnRhbnQiPjxzcGFuPkZhbnRhc3RpYy4gV291bGQgaXQgaGVscCB0byBoYXZl IGFuIGV4dGVuc2lvbiB0byBzZXQgYSBsb3dlciBib3VuZCBvbiB0aGlzIHZhbHVlLCBvciBqdXN0 IG1ha2UgaXQgbW9yZSBwYWluZnVsPzwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PihEaWQgeW91IG1lYW4gdXBwZXIgYm91 bmQ/KTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSdkIGFjdHVhbGx5IGludGVycHJl dGVkIHRoZSBSRkMgODQ0NiB0ZXh0IHRvIGltcGx5IGEgNyBkYXkgdXBwZXIgYm91bmQgb24gdGhl IHJlbmV3YWJpbGl0eSwgYnV0IGFwcGFyZW50bHkgdGhhdCdzIG5vdCBob3cgb3RoZXJzIHJlYWQg aXQhIEkgZG9uJ3QgY2FyZSBzdHJvbmdseSBlaXRoZXIgd2F5IGFib3V0IGFuIGV4dGVuc2lvbiB0 byBzZXQgYSByZW5ld2FsIGJvdW5kLCBJIHRoaW5rLiBBIGNsaWVudCBpcyBhbHdheXMgZnJlZSB0 byB0aWdodGVuDQogdGlja2V0IGxpZmV0aW1lIHBvbGljaWVzIHVuaWxhdGVyYWxseS4gV2UgZG9u J3QgbmVlZCBhbiBleHRlbnNpb24gdG8gYWR2ZXJ0aXNlIGl0cyBwb2xpY2llcyB1bmxlc3Mgd2Ug d2FudCB0byBhbGxvdyBzZXJ2ZXIgdG8gY2hhbmdlIHRoZWlyIGJlaGF2aW9yIGluIHJlc3BvbnNl LiBJbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCBpZiB3ZSB0aGluayB0aGUgc2VydmVyIG1heSBhbHNv IGhhdmUgYW4gb3BpbmlvbiBvbiByZW5ld2FiaWxpdHkgKHlvdSBtZW50aW9uDQoga2V5bGVzcyB0 aGluZ3MpLCBhIE5ld1Nlc3Npb25UaWNrZXQgZXh0ZW5zaW9uIHdvdWxkIGJlIGVhc3kgdG8gc3Vw cG9ydC4gVGhlIGNsaWVudCB3b3VsZCB0aGVuIHVzZSB0aGUgbW9yZSByZXN0cmljdGl2ZSBvZiB0 aGUgc2VydmVyJ3MgcHJlZmVyZW5jZXMgYW5kIGl0cyBsb2NhbCBwb2xpY3kuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaG91Z2gsIEkgZ3Vlc3MsIGhhdmluZyBub3Qgc3BlY2lmaWVk IGl0IHRoaXMgd2F5IGZyb20gdGhlIHN0YXJ0LCB0aGUgc2VydmVyIGNhbid0IGJlIHN1cmUgdGhl IGNsaWVudCBob25vcnMgdGhlIGV4dGVuc2lvbi4gSSBkb24ndCBrbm93IHdoYXQgY29uc2VxdWVu Y2VzIHRoYXQgaGFzIGZvciBzZXJ2ZXItcHJlZmVyZW5jZSBzY2VuYXJpby48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PihGb3IgY29tcGxldGVuZXNzLCBCb3JpbmdTU0wgZG9lc24ndCBh bGxvdyBUTFMgMS4yIHRpY2tldCByZW5ld2FscyB0byBleHRlbmQgbGlmZXRpbWUgYXQgYWxsLCBv bmx5IFRMUyAxLjMsIGFuZCBUTFMgMS4yIGxpZmV0aW1lcyBhcmUmbmJzcDtjYXBwZWQgbXVjaCBt b3JlIHRpZ2h0bHkuIFNpbmNlIFRMUyAxLjIgcmVzdW1wdGlvbiBkb2Vzbid0IGludm9sdmUgYW4g RUNESCBvcGVyYXRpb24sIGFueSBjb25jZXJucyBhYm91dCBhIHN0YWxlIG9ubGluZQ0KIHNpZ25h dHVyZSBhcmUgb3ZlcnNoYWRvd2VkIGJ5IGhvdyBtdWNoIGRhdGEgdGhlIGNsaWVudCBpcyB3aWxs aW5nIHRvIG1ha2UgdnVsbmVyYWJsZSB0byBhIHNpbmdsZSBzZXNzaW9uIHNlY3JldC4gV2UnZCBw cm9iYWJseSBkbyBzb21ldGhpbmcgc2ltaWxhciBpZiB3ZSBpbXBsZW1lbnRlZCBUTFMgMS4zJ3Mg cGxhaW4mbmJzcDtwc2tfa2UsIGJ1dCB3ZSBvbmx5IGRvIHBza19kaGVfa2UuKTwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+RGF2aWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8Ymxv Y2txdW90ZSBjbGFzcz0ieF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBi b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDApIj4NClN1Ym9kaDwvZGl2 Pg0KPGRpdiBpZD0ieF9tXy0yNTAzMjMyNDE0NTc4NTE3NjkwYXBwZW5kb25zZW5kIj48L2Rpdj4N CjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4 X21fLTI1MDMyMzI0MTQ1Nzg1MTc2OTBkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFj ZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6 MTFwdCI+PGI+RnJvbTo8L2I+IERhdmlkIEJlbmphbWluICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2 aWRiZW5AY2hyb21pdW0ub3JnIiB0YXJnZXQ9Il9ibGFuayIgaWQ9IkxQbG5rMjcxNDQzIiBjbGFz cz0iT1dBQXV0b0xpbmsiPmRhdmlkYmVuQGNocm9taXVtLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjksIDIwMTkgMTowMiBQTTxicj4NCjxiPlRvOjwvYj4g TmljayBTdWxsaXZhbjxicj4NCjxiPkNjOjwvYj4gU3Vib2RoIEl5ZW5nYXI7IDxhIGhyZWY9Im1h aWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBpZD0iTFBsbmsxMjkxMjAiIGNsYXNz PSJPV0FBdXRvTGluayI+DQp0bHNAaWV0Zi5vcmc8L2E+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgaWQ9InhfbV8tMjUwMzIzMjQxNDU3ODUxNzY5MGRpdlJwbHlG d2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0i IzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIHRpY2tldCBsaWZldGltZXM8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPlRoaXMgdHdvLWxpZmV0aW1lIHRoaW5nIGlzIGFj dHVhbGx5IGFscmVhZHkgd2hhdCB3ZSBpbXBsZW1lbnQgaW4gQm9yaW5nU1NMLiA6LSkgV2UgdHJh Y2sgYm90aCBhIGxpZmV0aW1lIGZvciB0aGUgdGlja2V0IChvbmUgZGF5KSBhbmQgYWxzbyBmb3Ig dGhlIG9yaWdpbmFsIGF1dGhlbnRpY2F0aW9uIHRoZSB0aWNrZXQgcm9vdHMgdXAgdG8gKG9uZSB3 ZWVrKS4gVGhlIGxpZmV0aW1lIG9mIHRoZSB0aWNrZXQgaXMgYm91bmRlZA0KIGJ5IGJvdGggdGhl c2UgdmFsdWVzLCBhbmQgdGhlIGxhdHRlciBpcyBub3QgZXh0ZW5kYWJsZSBvbiByZW5ldy4NCjxk aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PbiBUdWUsIEphbiAyOSwgMjAxOSBhdCAyOjE4 IFBNIE5pY2sgU3VsbGl2YW4gJmx0O25pY2s9PGEgaHJlZj0ibWFpbHRvOjQwY2xvdWRmbGFyZS5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBpZD0iTFBsbms3OTAxNzkiIGNsYXNz PSJPV0FBdXRvTGluayI+NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJ4X21fLTI1MDMy MzI0MTQ1Nzg1MTc2OTB4X2dtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJ4X21fLTI1 MDMyMzI0MTQ1Nzg1MTc2OTB4X2dtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGly PSJsdHIiPg0KPGRpdj5Xb3VsZG4ndCB0aGlzIGlzc3VlIGFsc28gYmUgbWl0aWdhdGVkIGJ5IHJl cXVpcmluZyB0aGUgc2VydmVyIHRvIHJlLWF1dGhlbnRpY2F0ZSBkdXJpbmcgcmVzdW1wdGlvbiB3 aXRoIHRoZSBjZXJ0aWZpY2F0ZSBvbmNlIGluIGEgd2hpbGU/PC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkV4aXN0aW5nIHNlcnZlcnMgd29uJ3Qg ZG8gdGhpcywgc28gSSBzZWUgdGhpcyBsZXNzIGFzIGEgbWl0aWdhdGlvbiBhbmQgbW9yZSBhcyBh biBvcHRpbWl6YXRpb24gdG8gcGx1ZyB0aGUgb25lLXdlZWstY2xpZmYgdGhhdCB0aGUgZml4IHBy b2R1Y2VzLiBCdXQsIHllYWgsIHRoYXQgd291bGQgYmUgaGFuZHkuIChQcm9iYWJseSBzb21ldGhp bmcgbGlrZTogJnF1b3Q7cmUmcXVvdDstYXV0aCdkIGlkZW50aXR5IGFwcGx5IHRvIHRpY2tldHMs IFBTSyBhcHBsaWVzDQogdG8gY29ubmVjdGlvbi4gQ2xpZW50IHNlbmRzIGFuIGV4dGVuc2lvbiB0 byBhZHZlcnRpc2Ugd2UncmUgbmVhcmluZyB0aGUgdW5yZW5ld2FibGUgYm91bmQuKTwvZGl2Pg0K PGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRhdmlkPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9tXy0yNTAzMjMyNDE0NTc4NTE3Njkw eF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+Tmlj azwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJ4X21fLTI1MDMyMzI0MTQ1Nzg1MTc2 OTB4X2dtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJ4X21fLTI1MDMyMzI0MTQ1 Nzg1MTc2OTB4X21fLTU5NTUwMzMxNjE2NDg3MTEyNDRtXzE5NjEwOTgyOTM2OTg5MTQxNjlnbWFp bF9hdHRyIj4NCk9uIFR1ZSwgSmFuIDI5LCAyMDE5IGF0IDExOjAwIEFNIFN1Ym9kaCBJeWVuZ2Fy ICZsdDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGlkPSJM UGxuazY0NTg3OCIgY2xhc3M9Ik9XQUF1dG9MaW5rIj5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0ieF9tXy0yNTAzMjMyNDE0NTc4NTE3 NjkweF9nbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVy LWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJ4X21fLTI1MDMyMzI0MTQ1Nzg1MTc2OTB4X21fLTU5NTUw MzMxNjE2NDg3MTEyNDRtXzE5NjEwOTgyOTM2OTg5MTQxNjlnbWFpbC1tXzM5NzcyNzExMDI2NDc0 MzgyODFkaXZ0YWdkZWZhdWx0d3JhcHBlciIgZGlyPSJsdHIiIHN0eWxlPSJmb250LXNpemU6MTJw dDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1mYW1pbHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1z ZXJpZixFbW9qaUZvbnQsJnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDssJnF1b3Q7U2Vnb2Ug VUkgRW1vamkmcXVvdDssTm90b0NvbG9yRW1vamksJnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7 LCZxdW90O0FuZHJvaWQgRW1vamkmcXVvdDssRW1vamlTeW1ib2xzIj4NCiZndDsmbmJzcDs8c3Bh biBzdHlsZT0iY29sb3I6cmdiKDMzLDMzLDMzKTsgZm9udC1mYW1pbHk6d2Zfc2Vnb2UtdWlfbm9y bWFsLCZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9tYSxBcmlh bCxzYW5zLXNlcmlmLHNlcmlmLEVtb2ppRm9udDsgZm9udC1zaXplOjE0LjY2NjdweCI+SWYgYnkg JnF1b3Q7ZW50aXJlIFRMUyBzZXNzaW9uJnF1b3Q7IHlvdSBtZWFuIHRoZSByZXN1bWVkIChhbmQg cmVuZXdlZCk8L3NwYW4+PGJyIHN0eWxlPSJjb2xvcjpyZ2IoMzMsMzMsMzMpOyBmb250LWZhbWls eTp3Zl9zZWdvZS11aV9ub3JtYWwsJnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7U2Vnb2UgV1Am cXVvdDssVGFob21hLEFyaWFsLHNhbnMtc2VyaWYsc2VyaWYsRW1vamlGb250OyBmb250LXNpemU6 MTQuNjY2N3B4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzMsMzMsMzMpOyBmb250LWZhbWls eTp3Zl9zZWdvZS11aV9ub3JtYWwsJnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7U2Vnb2UgV1Am cXVvdDssVGFob21hLEFyaWFsLHNhbnMtc2VyaWYsc2VyaWYsRW1vamlGb250OyBmb250LXNpemU6 MTQuNjY2N3B4Ij5zZXNzaW9ucywgdGhlbiB5ZXAhPC9zcGFuPjxiciBzdHlsZT0iY29sb3I6cmdi KDMzLDMzLDMzKTsgZm9udC1mYW1pbHk6d2Zfc2Vnb2UtdWlfbm9ybWFsLCZxdW90O1NlZ29lIFVJ JnF1b3Q7LCZxdW90O1NlZ29lIFdQJnF1b3Q7LFRhaG9tYSxBcmlhbCxzYW5zLXNlcmlmLHNlcmlm LEVtb2ppRm9udDsgZm9udC1zaXplOjE0LjY2NjdweCI+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMzMsMzMsMzMpOyBmb250LWZhbWlseTp3Zl9zZWdvZS11aV9ub3JtYWwsJnF1b3Q7U2Vn b2UgVUkmcXVvdDssJnF1b3Q7U2Vnb2UgV1AmcXVvdDssVGFob21hLEFyaWFsLHNhbnMtc2VyaWYs c2VyaWYsRW1vamlGb250OyBmb250LXNpemU6MTQuNjY2N3B4Ij48YnI+DQo8L3NwYW4+PC9kaXY+ DQo8ZGl2Pjxmb250IGNvbG9yPSIjMjEyMTIxIiBmYWNlPSJ3Zl9zZWdvZS11aV9ub3JtYWwsIFNl Z29lIFVJLCBTZWdvZSBXUCwgVGFob21hLCBBcmlhbCwgc2Fucy1zZXJpZiwgc2VyaWYsIEVtb2pp Rm9udCI+PHNwYW4+WWEgSSB0aGluayB0aGF0J2QgbmVlZCBhIG5ldyBkcmFmdCBlaXRoZXIgd2F5 LiBDYW4gZGVmaW5pdGVseSB3cml0ZSB0aGF0IHVwPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgY29sb3I9IiMyMTIxMjEiIGZhY2U9IndmX3NlZ29lLXVpX25vcm1hbCwgU2Vnb2UgVUks IFNlZ29lIFdQLCBUYWhvbWEsIEFyaWFsLCBzYW5zLXNlcmlmLCBzZXJpZiwgRW1vamlGb250Ij48 c3Bhbj5pZiBwZW9wbGUgZG9uJ3QgdGhpbmsgaXQncyB0aGUgd29yc3QgaWRlYSBpbiB0aGUgd29y bGQuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9IiMyMTIxMjEiIGZhY2U9 IndmX3NlZ29lLXVpX25vcm1hbCwgU2Vnb2UgVUksIFNlZ29lIFdQLCBUYWhvbWEsIEFyaWFsLCBz YW5zLXNlcmlmLCBzZXJpZiwgRW1vamlGb250Ij48c3Bhbj48YnI+DQo8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzIxMjEyMSIgZmFjZT0id2Zfc2Vnb2UtdWlfbm9ybWFs LCBTZWdvZSBVSSwgU2Vnb2UgV1AsIFRhaG9tYSwgQXJpYWwsIHNhbnMtc2VyaWYsIHNlcmlmLCBF bW9qaUZvbnQiPjxzcGFuPlN1Ym9kaDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxociBz dHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4X21fLTI1 MDMyMzI0MTQ1Nzg1MTc2OTB4X21fLTU5NTUwMzMxNjE2NDg3MTEyNDRtXzE5NjEwOTgyOTM2OTg5 MTQxNjlnbWFpbC1tXzM5NzcyNzExMDI2NDc0MzgyODFkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+ DQo8Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9 ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gQ2hyaXN0b3BoZXIgV29vZCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdG9waGVyd29vZDA3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGlk PSJMUGxuazk4NzMwMiIgY2xhc3M9Ik9XQUF1dG9MaW5rIj5jaHJpc3RvcGhlcndvb2QwN0BnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjgsIDIwMTkg MTA6MTM6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IFN1Ym9kaCBJeWVuZ2FyPGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaWQ9IkxQbG5r OTM2NTE2IiBjbGFzcz0iT1dBQXV0b0xpbmsiPg0KdGxzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1RMU10gdGlja2V0IGxpZmV0aW1lczwvZm9udD4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfbV8tMjUwMzIzMjQxNDU3ODUxNzY5MHhfbV8t NTk1NTAzMzE2MTY0ODcxMTI0NG1fMTk2MTA5ODI5MzY5ODkxNDE2OWdtYWlsLW1fMzk3NzI3MTEw MjY0NzQzODI4MUJvZHlGcmFnbWVudCI+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQiPg0KPGRpdiBjbGFzcz0ieF9tXy0yNTAzMjMyNDE0NTc4NTE3NjkweF9tXy01 OTU1MDMzMTYxNjQ4NzExMjQ0bV8xOTYxMDk4MjkzNjk4OTE0MTY5Z21haWwtbV8zOTc3MjcxMTAy NjQ3NDM4MjgxUGxhaW5UZXh0Ij4NCk9uIE1vbiwgSmFuIDI4LCAyMDE5IGF0IDEwOjA0IFBNIFN1 Ym9kaCBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIGlkPSJMUGxuazk2MTI2OSIgY2xhc3M9Ik9XQUF1dG9MaW5rIj5zdWJvZGhAZmIuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBTaW5jZSBjbGllbnRzIGFs cmVhZHkgc3RvcmUgdGlja2V0cywgY291bGQgdGhleSBub3QgYWxzbyBzdG9yZSB0aGU8YnI+DQom Z3Q7IHRpbWUgb2Ygb3JpZ2luYWwgdGlja2V0IGlzc3VhbmNlIGFuZCBjYXAgdGhlIHJlc3VtcHRp b24gd2luZG93IHRvIE48YnI+DQomZ3Q7ICg3KSBkYXlzIGZyb20gdGhhdCBwb2ludD8gVGhhdCBp cywgaXQgc2VlbXMgY2xpZW50cyBjb3VsZCBpbXBsZW1lbnQ8YnI+DQomZ3Q7IHRoaXMgYmVoYXZp b3Igd2l0aG91dCBhbnkgcHJvdG9jb2wgc3VwcG9ydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDb3Jy ZWN0LCBob3dldmVyIHRoZSBzZXJ2ZXIgY3VycmVudGx5IHByb3ZpZGVzIGEgdmFsdWUgZm9yIHRo aXMsIGFuZCBjbGllbnRzIGRvIG5vdCBlbmZvcmNlIGEgbG93ZXIgYm91bmQgb24gdGhpcy4gNyBk YXlzIGlzIGFuIHVwcGVyIGJvdW5kLjxicj4NCiZndDsgU2VydmVycyB3b3VsZCBwcm92aWRlIGEg bXVjaCBsb3dlciB2YWx1ZSB0aGFuIDcgZGF5cyBwcmFjdGljYWxseS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJZiBJJ20gdW5kZXJzdGFuZGluZyB5b3VyIHN1Z2dlc3Rpb24gY29ycmVjdGx5LCB5b3Un cmUgc3VnZ2VzdGluZyB0aGF0IGNsaWVudHMgY2hhbmdlIHRoZSBtZWFuaW5nIG9mIHRpY2tldF9s aWZldGltZV9oaW50Pzxicj4NCiZndDsgVGhhdCBpcyBub3QganVzdCBsaW1pdCBpdCB0byB0aGUg c2NvcGUgb2YgdGhlIHRpY2tldCBidXQgdGhlIGVudGlyZSBUTFMgc2Vzc2lvbj8gVGhhdCB3b3Vs ZCBiZSBmaW5lIHRvIGJ5IG1lLCBob3dldmVyIG1pZ2h0IGJyZWFrIHNvbWUgZm9sa3MuPGJyPg0K PGJyPg0KSWYgYnkgJnF1b3Q7ZW50aXJlIFRMUyBzZXNzaW9uJnF1b3Q7IHlvdSBtZWFuIHRoZSBy ZXN1bWVkIChhbmQgcmVuZXdlZCk8YnI+DQpzZXNzaW9ucywgdGhlbiB5ZXAhPGJyPg0KPGJyPg0K QmVzdCw8YnI+DQpDaHJpczxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IFN1Ym9kaDxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZyb206IENocmlz dG9waGVyIFdvb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlcndvb2QwN0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIiBpZD0iTFBsbmszMjIzNzMiIGNsYXNzPSJPV0FBdXRvTGluayI+ Y2hyaXN0b3BoZXJ3b29kMDdAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7IFNlbnQ6IE1vbmRh eSwgSmFudWFyeSAyOCwgMjAxOSA5OjU3IFBNPGJyPg0KJmd0OyBUbzogU3Vib2RoIEl5ZW5nYXI8 YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayIgaWQ9IkxQbG5rNTA1MTcyIiBjbGFzcz0iT1dBQXV0b0xpbmsiPg0KdGxzQGlldGYub3JnPC9h Pjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtUTFNdIHRpY2tldCBsaWZldGltZXM8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBPbiBNb24sIEphbiAyOCwgMjAxOSBhdCA5OjQzIFBNIFN1Ym9kaCBJeWVuZ2Fy ICZsdDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGlkPSJM UGxuazc3Njg1MCIgY2xhc3M9Ik9XQUF1dG9MaW5rIj5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEluIFRMUyAxLjMgd2UgYWRkZWQgYSBt YXhpbXVtIGFnZSB0byB0aGUgdGlja2V0IGxpZmV0aW1lIHRvIGJlIDcgZGF5cy4gVGhpcyBoYWQg c2V2ZXJhbCBvcmlnaW5hbCBtb3RpdmF0aW9ucyBpbmNsdWRpbmcgcmVkdWNpbmcgdGhlIHRpbWUg dGhhdCBhIHRpY2tldCBpcyByZXVzZWQgKGZvciBwcml2YWN5IG9yIFBGUykuIEFub3RoZXIgbWFq b3IgbW90aXZhdGlvbiBmb3IgdGhpcyB3YXMgdG8gbGltaXQgdGhlIGV4cG9zdXJlIG9mIHNlcnZl cnMNCiB0aGF0IHVzZSBrZXlsZXNzIHNzbCBsaWtlIG1lY2hhbmlzbXMsIGkuZS4gaWYgdGhleSBr ZXB0IGEgU1RFSyBsb2NhbGx5LCBidXQgdGhlIGtleWxlc3MgU1NMIHNlcnZlciByZW1vdGVseSwg dGhlbiB0aGUgdGhlZnQgb2YgYSBTVEVLIHdvdWxkIHByZXN1bWFibHkgbGltaXQgdGhlIE1JVE0g Y2FwYWJpbGl0aWVzIHRvIHRoZSB0aWNrZXQgbGlmZXRpbWUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEhvd2V2ZXIgdGhpbmtpbmcgYWJvdXQgaXQgc29tZSBtb3JlIGJlY2F1c2Ugb2Yg dGhlIHJlbmV3YWwgY2FwYWJpbGl0eSBvZiB0aWNrZXRzIGluIFRMUyAxLjMsIGFuIGVudGl0eSBv d25pbmcgdGhlIFNURUsgY291bGQganVzdCByZS1pc3N1ZSBuZXcgdGlja2V0cyBmb3JldmVyIG9u IGEgcmVzdW1lZCBjb25uZWN0aW9uLiBUaGlzIHdvdWxkIGxvb2sgdG8gdGhlIGNsaWVudCBhcyBh IG5ldyB0aWNrZXQgYW5kIGl0IHdvdWxkIHJlZnJlc2ggaXRzDQogbGlmZXRpbWUgb24gdGhlIHRp Y2tldC4gVGhlcmVieSBhIE1JVE0gY291bGQgaW50ZXJjZXB0IGNvbm5lY3Rpb25zIHRvIHVzZXJz IHRoYXQgaGF2ZSBiZWVuIHRvIHRoZSBzZXJ2ZXIgd2l0aCB0aGUgU1RFSy4gSSdtIHdvbmRlcmlu ZyB3aGV0aGVyIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBtZWNoYW5pc20gdG8gbGlt aXQgdGhlIGxpZmV0aW1lIG9mIGFsbCB0aWNrZXQgcmVzdW1wdGlvbiBhY3Jvc3MgYWxsIHJlc3Vt cHRpb25zIGZyb20NCiB0aGUgb3JpZ2luYWwgY29ubmVjdGlvbiBpbnN0ZWFkIG9mIGp1c3QgdGhl IGxpbWl0ZWQgcGVyIHRpY2tldCBsaWZldGltZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTaW5jZSBj bGllbnRzIGFscmVhZHkgc3RvcmUgdGlja2V0cywgY291bGQgdGhleSBub3QgYWxzbyBzdG9yZSB0 aGU8YnI+DQomZ3Q7IHRpbWUgb2Ygb3JpZ2luYWwgdGlja2V0IGlzc3VhbmNlIGFuZCBjYXAgdGhl IHJlc3VtcHRpb24gd2luZG93IHRvIE48YnI+DQomZ3Q7ICg3KSBkYXlzIGZyb20gdGhhdCBwb2lu dD8gVGhhdCBpcywgaXQgc2VlbXMgY2xpZW50cyBjb3VsZCBpbXBsZW1lbnQ8YnI+DQomZ3Q7IHRo aXMgYmVoYXZpb3Igd2l0aG91dCBhbnkgcHJvdG9jb2wgc3VwcG9ydC48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBCZXN0LDxicj4NCiZndDsgQ2hyaXM8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIiBpZD0iTFBsbms3Nzg5NzciIGNsYXNzPSJPV0FBdXRvTGluayI+ VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f dGxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPWgzSnU5 RUJTN21IdHdnLXdBeU43ZlEmYW1wO209QWVIcGtZWHdRdEY0RGpmcWRITmx1T0xJY1RIT0RUaWhu N2k0V0J6dWNqQSZhbXA7cz1CNHpMNkVtdjBqeWhBc3VKeUJueE16TzhsMXc3U0R1NU9wQjRtOGph ck1rJmFtcDtlPSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgaWQ9IkxQbG5rNjg2 NDc3IiBjbGFzcz0iT1dBQXV0b0xpbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGlkPSJMUGxu azExMjQwNCIgY2xhc3M9Ik9XQUF1dG9MaW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBS VHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9aDNKdTlFQlM3bUh0d2ctd0F5TjdmUSZhbXA7bT1BZUhw a1lYd1F0RjREamZxZEhObHVPTEljVEhPRFRpaG43aTRXQnp1Y2pBJmFtcDtzPUI0ekw2RW12MGp5 aEFzdUp5Qm54TXpPOGwxdzdTRHU1T3BCNG04amFyTWsmYW1wO2U9IiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIiBpZD0iTFBsbms1NjQzMTIiIGNsYXNzPSJPV0FBdXRvTGluayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8YnI+DQo8L2E+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MWHPR15MB18217B38EB252E42AFDC65BDB6970MWHPR15MB1821namp_-- From nobody Tue Jan 29 21:42:27 2019 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 89D48131182 for ; Tue, 29 Jan 2019 21:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.081 X-Spam-Level: X-Spam-Status: No, score=-11.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 kdVQr2SlfzvV for ; Tue, 29 Jan 2019 21:42:21 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 7AD3D13118A for ; Tue, 29 Jan 2019 21:42:20 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id r14so25105650qtp.1 for ; Tue, 29 Jan 2019 21:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k+nd5G+/tHjTPkiTbc7JgdZ8FjnTo/QbmCNc1M93VR0=; b=FoqiW4BRrzNfLdfymIuiYhrS5omEM9gvV/BxS3WvVzwHTBFRHLxqKU0CIMVka+1EJz 7TOh66jgjNWDMhQKD0Abcr2bcknLWkOVSWQHyp9uaQbAGONmTu+IQmRpyelBbJpHmrI3 f37FKQIf32I+6PVdQmWclZ9lisO8eTA0mwXFs= 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=k+nd5G+/tHjTPkiTbc7JgdZ8FjnTo/QbmCNc1M93VR0=; b=Ln4VZr7DnJbuwzMu91BxEcj30ombn8LgphPxdHhHbBQnNUqiHC4CoieH47BXTo4pqR zaWimVZdJcyIFADuOlPYeq9Mpa9pP0nxIOHFftGrkVhOPPssC2sJi/Ldu789mnS7kFhI h5aIs90pvidWlJRgAtc8p3OU5JwDVeI3Jd3slEW6PF5eGbGysGdnhzCJoT6upVrhLxrR H9DzXxy4EBiQflvQBrjmEeC4xgShnBT1AUiOAynh8amvRa5iMX85EhzAai1OmdxGWq6z oqjQhV8Y4vfXuA1bc7BgahG26fKFfTe8xWjL2Kdy/rRy+bTi3sPcVYDN5+vFfkXjIURE zJyg== X-Gm-Message-State: AJcUukejESelgoCvAo30vlkYeE6gEhEI5O1IeLaMMGdZrHmjtLLPAfHi vBLPPtVa/H8Oyb7oV0Xl0L+SI+wDiLncHj27LcBn X-Google-Smtp-Source: ALg8bN4nxqyRRgdIZtVmkEdzlS6l2/IO+NGmj0sAIxG2QJS4gRhKnWH9MooTmQSsCdu8/BzKlB9G3C4ewwwfkepLjGg= X-Received: by 2002:ac8:1873:: with SMTP id n48mr28511185qtk.10.1548826939180; Tue, 29 Jan 2019 21:42:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 29 Jan 2019 23:42:07 -0600 Message-ID: To: Subodh Iyengar Cc: Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000087a4040580a65fe1" Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 05:42:25 -0000 --00000000000087a4040580a65fe1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 10:29 PM Subodh Iyengar wrote: > (Did you mean upper bound?) > > Na I meant lower bound. That is such an extension would be useless if > the time the server mentioned > time the client decided to cache it. > However the server might advertise a time < time the client decided to > cache it, in which it would be useful. > Oh, I think we were maybe using the words differently. I was thinking "upper bound" in the sense any server-sent value should be an upper bound on the true lifetime because the client can always choose to drop it earlier, but it should not drop it later than that point. Interpreting the server-sent value as a lower-bound, in this sense of the word, would be silly as that precludes the client from evicting the cache of its own accord. > > I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound > on the renewability, but apparently that's not how others read it! > > > > Though, I guess, having not specified it this way from the start, the > server can't be sure the client honors the extension. I don't know what > consequences that has for server-preference scenario. > > Yup I think there is a disconnect between the intention of the server > operator and the protocol. That is the server operator would like to have > only 7 day uses of the PSK, however unbeknownst to then, their library is > renewing the ticket and extending the lifetime of the PSK. This disconnec= t > exists in both TLS 1.2 and 1.3, however for TLS 1.2 the renewal of ticket= s > is less widely deployed than it should be because of some historic client > intolerance of it. > > I think the interpretation that the lifetime applies to the current ticke= t > only is the more common interpretation. I did a short study of several TL= S > 1.3 implementation shandling of ticket lifetimes by staring at some code > really intensely: > Er, right, sorry I should have been clearer. Yeah, we interpret ticket_lifetime field in NewSessionTicket to be the renewable lifetime, since the spec talks about a particular ticket. We then implement an unrenewable lifetime which is set at 7 days after the initial handshake. I'd read the hard-coded 7 day timeout as a bound on the latter but, now that I look at it again, I'm not sure why I thought that. (Though I'm pretty happy with the interpretation anyway.) We'd definitely discussed the authentication freshness cliff during standardization, but maybe that text never made it in there? :-/ > boringssl: > > Has the ability to use an internal session cache. Before it uses a ticket > it checks the session timeout against current time. Everytime it receives= a > new session ticket it clamps the SSL_SESSION's timeout > using ssl_session_rebase_time and then clears any timed out tickets > with SSL_CTX_flush_sessions. > Not quite. The internal session cache is only active on the server. It's not using the right key to be used on a client anyway. The client uses callbacks to maintain an external cache. (One could imagine passing the key in or whatever, but our API evolved from the callback-based story from OpenSSL, and that's worked well enough to not change it.) But the external cache stores SSL_SESSION objects which have timeouts. Those timeouts are managed by BoringSSL and implement the various lifetime policies. ssl_session_rebase_time itself does not change any lifetimes. It just rebases the starting time for convenience (per spec, ticket age and ticket lifetime are measured from issuance of the particular ticket, not the original auth point). There's also two timeouts on each ticket, as noted, and one of them never renews. Seems like there is room for clarification on the ticket lifetime. > Agreed. > Subodh > ------------------------------ > *From:* David Benjamin > *Sent:* Tuesday, January 29, 2019 2:52 PM > *To:* Subodh Iyengar > *Cc:* Nick Sullivan; tls@ietf.org > > *Subject:* Re: [TLS] ticket lifetimes > On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar wrote: > > > Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while? > > I think it's probably just easier to drop the resumption completely. > > > This two-lifetime thing is actually already what we implement in > BoringSSL. =F0=9F=98=8A > > Fantastic. Would it help to have an extension to set a lower bound on thi= s > value, or just make it more painful? > > > (Did you mean upper bound?) > > I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound o= n > the renewability, but apparently that's not how others read it! I don't > care strongly either way about an extension to set a renewal bound, I > think. A client is always free to tighten ticket lifetime policies > unilaterally. We don't need an extension to advertise its policies unless > we want to allow server to change their behavior in response. In the othe= r > direction, if we think the server may also have an opinion on renewabilit= y > (you mention keyless things), a NewSessionTicket extension would be easy = to > support. The client would then use the more restrictive of the server's > preferences and its local policy. > > Though, I guess, having not specified it this way from the start, the > server can't be sure the client honors the extension. I don't know what > consequences that has for server-preference scenario. > > (For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals to > extend lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are capped mu= ch > more tightly. Since TLS 1.2 resumption doesn't involve an ECDH operation, > any concerns about a stale online signature are overshadowed by how much > data the client is willing to make vulnerable to a single session secret. > We'd probably do something similar if we implemented TLS 1.3's > plain psk_ke, but we only do psk_dhe_ke.) > > David > > > Subodh > ------------------------------ > *From:* David Benjamin > *Sent:* Tuesday, January 29, 2019 1:02 PM > *To:* Nick Sullivan > *Cc:* Subodh Iyengar; tls@ietf.org > > *Subject:* Re: [TLS] ticket lifetimes > This two-lifetime thing is actually already what we implement in > BoringSSL. :-) We track both a lifetime for the ticket (one day) and also > for the original authentication the ticket roots up to (one week). The > lifetime of the ticket is bounded by both these values, and the latter is > not extendable on renew. > > On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan 40cloudflare.com@dmarc.ietf.org> wrote: > > Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while? > > > Existing servers won't do this, so I see this less as a mitigation and > more as an optimization to plug the one-week-cliff that the fix produces. > But, yeah, that would be handy. (Probably something like: "re"-auth'd > identity apply to tickets, PSK applies to connection. Client sends an > extension to advertise we're nearing the unrenewable bound.) > > David > > > Nick > > On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar wrote: > > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Ya I think that'd need a new draft either way. Can definitely write that = up > if people don't think it's the worst idea in the world. > > Subodh > ------------------------------ > *From:* Christopher Wood > *Sent:* Monday, January 28, 2019 10:13:36 PM > *To:* Subodh Iyengar > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar wrote: > > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Correct, however the server currently provides a value for this, and > clients do not enforce a lower bound on this. 7 days is an upper bound. > > Servers would provide a much lower value than 7 days practically. > > > > If I'm understanding your suggestion correctly, you're suggesting that > clients change the meaning of ticket_lifetime_hint? > > That is not just limit it to the scope of the ticket but the entire TLS > session? That would be fine to by me, however might break some folks. > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Best, > Chris > > > > > Subodh > > ________________________________ > > From: Christopher Wood > > Sent: Monday, January 28, 2019 9:57 PM > > To: Subodh Iyengar > > Cc: tls@ietf.org > > Subject: Re: [TLS] ticket lifetimes > > > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar wrote: > > > > > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days= . > This had several original motivations including reducing the time that a > ticket is reused (for privacy or PFS). Another major motivation for this > was to limit the exposure of servers that use keyless ssl like mechanisms= , > i.e. if they kept a STEK locally, but the keyless SSL server remotely, th= en > the theft of a STEK would presumably limit the MITM capabilities to the > ticket lifetime. > > > > > > However thinking about it some more because of the renewal capability > of tickets in TLS 1.3, an entity owning the STEK could just re-issue new > tickets forever on a resumed connection. This would look to the client as= a > new ticket and it would refresh its lifetime on the ticket. Thereby a MIT= M > could intercept connections to users that have been to the server with th= e > STEK. I'm wondering whether it might be useful to define a mechanism to > limit the lifetime of all ticket resumption across all resumptions from t= he > original connection instead of just the limited per ticket lifetime. > > > > Since clients already store tickets, could they not also store the > > time of original ticket issuance and cap the resumption window to N > > (7) days from that point? That is, it seems clients could implement > > this behavior without any protocol support. > > > > Best, > > Chris > _______________________________________________ > 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 > > > > --00000000000087a4040580a65fe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 10:29 PM Subodh Iyengar <subodh@fb.com> wrote:
(Did you mean upper bound?)
> Na I meant lower bound. That is s= uch an extension would be useless if the time the server mentioned > tim= e the client decided to cache it. However the server might advertise a time < time the client decided to cache it= , in which it would be useful.
Oh, I think we were maybe using the words differently= . I was thinking "upper bound" in the sense any server-sent value= should be an upper bound on the true lifetime because the client can alway= s choose to drop it earlier, but it should not drop it later than that poin= t. Interpreting the server-sent value as a lower-bound, in this sense of th= e word, would be silly as that precludes the client from evicting the cache= of its own accord.
=C2=A0
>=C2=A0I'd actually interpreted= the RFC 8446 text to imply a 7 day upper bound on the renewability, but apparently that's not how others read it!=C2= =A0
>=C2=A0

= Though, I guess, having not specified it this way from the start, the serve= r can't be sure the client honors the extension. I don't know what = consequences that has for server-preference scenario.
<= /span>

Yup I think there is a disconnect betw= een the intention of the server operator and the protocol. That is the server operator would like to have = only 7 day uses of the PSK, however unbeknownst to then, their library is r= enewing the ticket and extending the lifetime of the PSK. This disconnect e= xists in both TLS 1.2 and 1.3, however for TLS 1.2 the renewal of tickets is less widely deployed than it should = be because of some historic client intolerance of it.

I think the int= erpretation that the lifetime applies to the current ticket only is=C2=A0th= e more common interpretation. I did a short study of several TLS 1.3 implem= entation shandling of ticket lifetimes by staring at some code really intensely:

Er, right, sorry = I should have been clearer. Yeah, we interpret ticket_lifetime field in New= SessionTicket to be the renewable lifetime, since the spec talks about a pa= rticular ticket. We then implement an unrenewable lifetime which is set at = 7 days after the initial handshake.

I'd read t= he hard-coded 7 day timeout as a bound on the latter but, now that I look a= t it again, I'm not sure why I thought that. (Though I'm pretty hap= py with the interpretation anyway.) We'd definitely discussed the authe= ntication freshness cliff during standardization, but maybe that text never= made it in there? :-/=C2=A0
=
=C2=A0
=
boringssl:

Has the ability to use an internal session cache. Before it uses a tic= ket it checks the session timeout against current time. Everytime it receiv= es a new session ticket it clamps the SSL_SESSION's timeout using=C2=A0= ssl_session_rebase_time and then clears any timed out tickets with=C2=A0SSL_CTX_flush_sessions.

Not quite. The inter= nal session cache is only active on the server. It's not using the righ= t key to be used on a client anyway. The client uses callbacks to maintain = an external cache. (One could imagine passing the key in or whatever, but o= ur API evolved from the callback-based story from OpenSSL, and that's w= orked well enough to not change it.) But the external cache stores SSL_SESS= ION objects which have timeouts. Those timeouts are managed by BoringSSL an= d implement the various lifetime policies.

ssl_ses= sion_rebase_time itself does not change any lifetimes. It just rebases the = starting time for convenience (per spec, ticket age and ticket lifetime are= measured from issuance of the particular ticket, not the original auth poi= nt). There's also two timeouts on each ticket, as noted, and one of the= m never renews.

Seems like there is room for clarification on the ticket lifetime.

= Agreed.
=C2=A0
Subodh
From: David Benj= amin <davidbe= n@chromium.org>
Sent: Tuesday, January 29, 2019 2:52 PM
To: Subodh Iyengar
Cc: Nick Sullivan; tls@ietf.org

Subject: Re: [TLS] ticket lifetimes
On Tue, Jan 29, 2019 at = 4:14 PM Subodh Iyengar <subodh@fb= .com> wrote:
> Wouldn't this issue also be mitigated by requiring the server to r= e-authenticate during resumption with the certificate once in a while?
I think it's probably just easier to drop the resumption completely.=C2= =A0

>=C2=A0This two-lifetime thing is act= ually already what we implement in BoringSSL. =F0=9F=98=8A

Fantastic. Would it help to have a= n extension to set a lower bound on this value, or just make it more painfu= l?

(Did you mean upper bound?)

I'd actually interpreted the RFC 8446 text to imply a 7 day upper = bound on the renewability, but apparently that's not how others read it= ! I don't care strongly either way about an extension to set a renewal = bound, I think. A client is always free to tighten ticket lifetime policies unilaterally. We don't need an extension to a= dvertise its policies unless we want to allow server to change their behavi= or in response. In the other direction, if we think the server may also hav= e an opinion on renewability (you mention keyless things), a NewSessionTicket extension would be easy to support. Th= e client would then use the more restrictive of the server's preference= s and its local policy.

Though, I guess, having not specified it this way from the start, the = server can't be sure the client honors the extension. I don't know = what consequences that has for server-preference scenario.

(For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals= to extend lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are=C2=A0ca= pped much more tightly. Since TLS 1.2 resumption doesn't involve an ECD= H operation, any concerns about a stale online signature are overshadowed by how much data the client is willing to make = vulnerable to a single session secret. We'd probably do something simil= ar if we implemented TLS 1.3's plain=C2=A0psk_ke, but we only do psk_dh= e_ke.)

David
=C2=A0
Subodh
From: David Benjamin <davidben@chromium.org>
Sent: Tuesday, January 29, 2019 1:02 PM
To: Nick Sullivan
Cc: Subodh Iyengar; tls@ietf.org

Subject: Re: [TLS] ticket lifetimes
This two-lifetime thing is actually already what we implem= ent in BoringSSL. :-) We track both a lifetime for the ticket (one day) and= also for the original authentication the ticket roots up to (one week). Th= e lifetime of the ticket is bounded by both these values, and the latter is not extendable on renew.

On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.o= rg> wrote:
Wouldn't this issue also be mitigated by requiring the server to r= e-authenticate during resumption with the certificate once in a while?

Existing servers won't do this, so I see this less as a mitigation= and more as an optimization to plug the one-week-cliff that the fix produc= es. But, yeah, that would be handy. (Probably something like: "re"= ;-auth'd identity apply to tickets, PSK applies to connection. Client sends an extension to advertise we're nearing th= e unrenewable bound.)

David
=C2=A0
Nick

On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar <subodh@fb.com> wrote:
>=C2=A0If by "entire TLS session" you mean = the resumed (and renewed)
sessions, then yep!

Ya I think that'd = need a new draft either way. Can definitely write that up
if people don't th= ink it's the worst idea in the world.

Subodh
From: Christopher Wood <christopherwood07@gmail.com>
Sent: Monday, January 28, 2019 10:13:36 PM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] ticket lifetimes
=C2=A0
On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <subodh@fb.com> wrote:
>
> > Since clients already store tickets, could they not also store th= e
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Correct, however the server currently provides a value for this, and c= lients do not enforce a lower bound on this. 7 days is an upper bound.
> Servers would provide a much lower value than 7 days practically.
>
> If I'm understanding your suggestion correctly, you're suggest= ing that clients change the meaning of ticket_lifetime_hint?
> That is not just limit it to the scope of the ticket but the entire TL= S session? That would be fine to by me, however might break some folks.

If by "entire TLS session" you mean the resumed (and renewed)
sessions, then yep!

Best,
Chris

>
> Subodh
> ________________________________
> From: Christopher Wood <christopherwood07@gmail.com>
> Sent: Monday, January 28, 2019 9:57 PM
> To: Subodh Iyengar
> Cc: tls@ietf.org
> Subject: Re: [TLS] ticket lifetimes
>
> On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <subodh@fb.com> wrote:
> >
> > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 = days. This had several original motivations including reducing the time tha= t a ticket is reused (for privacy or PFS). Another major motivation for thi= s was to limit the exposure of servers that use keyless ssl like mechanisms, i.e. if they kept a STEK locally, bu= t the keyless SSL server remotely, then the theft of a STEK would presumabl= y limit the MITM capabilities to the ticket lifetime.
> >
> > However thinking about it some more because of the renewal capabi= lity of tickets in TLS 1.3, an entity owning the STEK could just re-issue n= ew tickets forever on a resumed connection. This would look to the client a= s a new ticket and it would refresh its lifetime on the ticket. Thereby a MITM could intercept connections to user= s that have been to the server with the STEK. I'm wondering whether it = might be useful to define a mechanism to limit the lifetime of all ticket r= esumption across all resumptions from the original connection instead of just the limited per ticket lifetime. >
> Since clients already store tickets, could they not also store the
> time of original ticket issuance and cap the resumption window to N > (7) days from that point? That is, it seems clients could implement > this behavior without any protocol support.
>
> Best,
> Chris
_______________________________________________
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

--00000000000087a4040580a65fe1-- From nobody Tue Jan 29 23:37:21 2019 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 DE965130F0B for ; Tue, 29 Jan 2019 23:37:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6Jc5ekeynLAh for ; Tue, 29 Jan 2019 23:37:17 -0800 (PST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 2ECB5130F01 for ; Tue, 29 Jan 2019 23:37:17 -0800 (PST) Received: by mail-wm1-f46.google.com with SMTP id y8so20394256wmi.4 for ; Tue, 29 Jan 2019 23:37:17 -0800 (PST) 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=z9B6+7j/RTerWpFu8iANeoaSX5g+W5HjGbFPVuvXgR4=; b=JNY6UeC/PWgrD5I3GZcntaIF5D/8QkQDgGhunIQpg+yriAEv1V0xmpR466FTmrJFsO O2p2226m3gCuHig+8h/vP/8AYvZaEsykTuVglMPgue/q78AXiRE00sSxdzXpYQCJvkmC WUuepfUoIol0SX75xF8ZIwmnFdhnm7bCjHkFmZYREsaQ7ueWuG1xxceOAFTFVqmeGbJw CJbjyivVk8Q66ytfH4NMplxstnzoKxY0EOt4ffGF9kElpXbzHu8/eJJdmwEpLVxbXlb8 c4et996uy7OZrp9Efh8NQ9Ky9CGGb4TOFHB5bwf4jItaLZbI2Bhik8AYmag0YBLIrhhF OgiQ== X-Gm-Message-State: AJcUukfc1pIaSA2F71emFQQuSXdu9dqPzmFRSRoKuWGEwuVwd8ZZpLBa pi3/ukbA9mBYx504pJjW4/p9HaPg29weSDVAm4xYRA== X-Google-Smtp-Source: ALg8bN7vz7L47NyGvspAuI027vw30ppP6oKvszou9vVd+c7hm4eRzjJf3oclx3VGJ6LiNj95y0XPQ3Ew9At1CSxWDjg= X-Received: by 2002:a1c:ad43:: with SMTP id w64mr23403449wme.32.1548833835413; Tue, 29 Jan 2019 23:37:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nikos Mavrogiannopoulos Date: Wed, 30 Jan 2019 08:37:02 +0100 Message-ID: To: David Benjamin Cc: Subodh Iyengar , Nick Sullivan , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000938d8e0580a7fae1" Archived-At: Subject: Re: [TLS] ticket lifetimes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 07:37:20 -0000 --000000000000938d8e0580a7fae1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 11:53 PM David Benjamin wrote: > On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar wrote: > >> > Wouldn't this issue also be mitigated by requiring the server to >> re-authenticate during resumption with the certificate once in a while? >> >> I think it's probably just easier to drop the resumption completely. >> >> > This two-lifetime thing is actually already what we implement in >> BoringSSL. =F0=9F=98=8A >> >> Fantastic. Would it help to have an extension to set a lower bound on >> this value, or just make it more painful? >> > > (Did you mean upper bound?) > > I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound o= n > the renewability, but apparently that's not how others read it! > That was also our understanding in the implementation for gnutls. regards, Nikos --000000000000938d8e0580a7fae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 29, 2019 at 11:53 PM David Benjamin <davidben@chromium.org> wrote:


regards,
Nikos

--000000000000938d8e0580a7fae1-- From nobody Thu Jan 31 17:45:25 2019 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 E10D51311E2 for ; Thu, 31 Jan 2019 17:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 Ii0-CJEekiSu for ; Thu, 31 Jan 2019 17:45:21 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 66EB91311DD for ; Thu, 31 Jan 2019 17:45:21 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id y1so2346045plp.9 for ; Thu, 31 Jan 2019 17:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=ghmyAysdvaqTDxiOVU/vZ6yCZfl1WRyV7211JY9o2U4=; b=ndFiBLvc5Grz2TkZVOr6EB54zYwIFdiXlqYArNpzidOzR/6m2R6htZZyTrx/UvWD+y wxMFXUPmQrMKiNel9jroiTUGOEQzKzp6P89zzae4SW8dxLLGLzr486EXO5wAyBsScQrT 93vF7Ro52P+k3udJOxumgTGBSsiUUe7RACVTAGdBZyxt32y9d+Fj3ShAehbZIEnN/ZKs 23u1qqcxgZLPICIY5FBg/Cm4tX+hLG5UwFBAOwDVMVCrCq+GInOofII0nxYSAjXKV063 4RzcxhWyOPzo7CKBlprdH/pDhIoYEV4hJTmwQMYyDBL88nhOPv614GZhnv6aEJ7ZVhrq phRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=ghmyAysdvaqTDxiOVU/vZ6yCZfl1WRyV7211JY9o2U4=; b=MILEl4lZQO6KJaTC9uOtpoCLhiSIkW0ABnz7tiJvV9aeMk0bLODBTWKz8Q9BcyB61/ dUKbltxr9KUhh9hQ27hZDqhPYrhlO9Ouz/SBX78+WxJ++YpICJtYd7ZLg5auNDAFQVuh Y6F0ZhcLj5gnbTVUhZgk6iC+WTX9nvujzrlfqjQk7ICxK39S6SjoogpkVn4JNYHSpWTI XQ64FKAVgIbtYDvn0V79zRTdlpNoCPFR0hLNwOybmEKElzJvx/OModR11AVS0lbcSRV3 8NTKWbh4x6EvfFKorOYPuFD0IRkk5TcDuxB2U0g8ZkHcKouAqjsm+2I1FOBqzr9nX+Zg qCEQ== X-Gm-Message-State: AJcUukeOpuN8e2LAG8jFiQ2trFxVEKKEWS98uqmMuEJMTEXsxjF1wGL6 2uvGnaY4/9THLLkAB0zhN8sStNnfJiI= X-Google-Smtp-Source: ALg8bN7jWFt21mz6VGFz9dDstnz4Ubi3l6RSK48o4y5ZzQwujJf8DPpVaerPttfj8SzRLU3K5rjXog== X-Received: by 2002:a17:902:bf0c:: with SMTP id bi12mr37648626plb.0.1548985520502; Thu, 31 Jan 2019 17:45:20 -0800 (PST) Received: from [10.1.104.145] ([76.74.153.36]) by smtp.gmail.com with ESMTPSA id s9sm6618587pgl.88.2019.01.31.17.45.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Jan 2019 17:45:19 -0800 (PST) From: "Christopher Wood" To: "TLS WG" Date: Thu, 31 Jan 2019 17:45:16 -0800 X-Mailer: MailMate (1.12.4r5594) Message-ID: <45DC31AD-B771-4646-B305-42B75F5CBAE1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Sending draft-ietf-tls-exported-authenticator to IESG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 01:45:23 -0000 The shepherd writeup for this draft is now complete: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator= /shepherdwriteup/ We=E2=80=99re sending this to IESG as the next step. Thanks, Chris, Joe, and Sean From nobody Thu Jan 31 17:45:49 2019 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 652FD131213; Thu, 31 Jan 2019 17:45:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood To: X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: christopherwood07@gmail.com, Sean Turner , Christopher Wood , iesg-secretary@ietf.org, tls-chairs@ietf.org, tls@ietf.org Message-ID: <154898553540.10094.15436164994319816052.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2019 17:45:35 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-exported-authenticator-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 01:45:40 -0000 Christopher Wood has requested publication of draft-ietf-tls-exported-authenticator-08 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-exported-authenticator/ From nobody Thu Jan 31 21:54:56 2019 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 149BF131106; Thu, 31 Jan 2019 21:54:54 -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.90.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, Joseph Salowey , joe@salowey.net, tls@ietf.org Message-ID: <154900049407.9952.2685085534072721469.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2019 21:54:54 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-sni-encryption-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 05:54:54 -0000 Joseph Salowey has requested publication of draft-ietf-tls-sni-encryption-04 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/