From nobody Sun Mar 1 17:40:53 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2033A0DF1 for ; Sun, 1 Mar 2020 17:40:51 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dDi9K-1Z9wI for ; Sun, 1 Mar 2020 17:40:49 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2C4493A0DED for ; Sun, 1 Mar 2020 17:40:48 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0221eZs2023664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Mar 2020 20:40:37 -0500 Date: Sun, 1 Mar 2020 17:40:35 -0800 From: Benjamin Kaduk To: Stefan Santesson Cc: secdispatch@ietf.org Message-ID: <20200302014035.GB98042@kduck.mit.edu> References: <20200226012438.GM56312@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] Signature Validation Token (SVT) - Request for time slot at secdispatch in Vancouver IETF X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 01:40:52 -0000 On Wed, Feb 26, 2020 at 11:11:52AM +0100, Stefan Santesson wrote: > Hi, > > Great question! > > We have not yet identified any reason to create any mechanisms within the present specification even though we recognize that this concept could be supported by external mechanisms such as block chaining and hash trees etc. > > However. I'm more than willing to discuss whether anything should be added to the specifications. > > The basic claim and idea is that storing a claim from a trusted authority that a particular certificate was valid at a certain point in time is no different from storing a claim that the whole signature was valid at a certain point in time. > This change of how things are done (from the former to the latter) do however have an extreme positive effect on the simplicity of the solution. > This is the only parameter that is fixed. Everything else can be discussed. I think that our general trend is to recognize that very few things (e.g., the "trusted authority") behave perfectly and without error, and thus to build in mechanisms to detect and/or recover from such failure when the cost of doing so is not too great. So I would welcome research into what mechanisms are available and their cost, so as to assess whether the cost is "too great". -Ben > Stefan Santesson > > On 2020-02-26, 02:25, "Secdispatch on behalf of Benjamin Kaduk" wrote: > > > Are there any technical mechanisms (e.g., blockchain with periodic > timestamps) to mitigate the requirement to trust the validation/re-signing > service? There are probably some solution sketches in the list archives > here or on saag ("merkle tree" might be a good search term). > > -Ben > > > > > > From nobody Mon Mar 2 01:36:54 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD713A10D7; Mon, 2 Mar 2020 01:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaHOdLmlZM9g; Mon, 2 Mar 2020 01:36:50 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20614.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::614]) (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 C09473A10DE; Mon, 2 Mar 2020 01:36:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NgtPHWwseSIRudbeaccxmu4Lr0RjtQx73aSLbrQ1iH2U5A3Jc6zwKetT/Us31tKmB5uWzsCBdXTodG3VYOqwRICEtK69Sw5XM/BG1K4VcNB3fLEtGtCv/2oa0dr4ZxQjVbgdL4UMILymFmKRB7bj84Q7uUrqbrjrSwwrxCrFNtlN9CIcFxS0CzQpoC5CN6YTp+frVRlQ8EUjePcyudclsblwUaosUza2CMPE1/CzHVTxujnuTTHUrZoeN40VHy0P9IXvQQmBLYStSt1uGPC6TlhDMqzYK04uD8TTK+V4EIrILaRiW9BIiih/P4YsBy5K9o2OvT4R6bNHaO37IvJ2iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uqMm2j+SmcU+qHCCp8snCjbggoseX+FZDTe7XG89qtI=; b=fvniy/6rTP0L+akHDFVLyiz4fwQCl3AJofnBP4DNJXTAmUgkMRkw+j74ykfNlyFSCpREQ5lYI9R3BG7g7juRdFwN4ak6RL8JMmH0bRG5vTO+tJcMNzeABTASMHoUysCNNuNtT8vyznjuRgO8jUNo4zzUsyJWNwO5tiyYBBOdL+tzL81Ip80X/xzC5OODFCMSpJB9wF2QTGAr119cd9boBcuJgH7R+20i/Em70Bm5cf4ZDA6LYJJQJcs+o5Im/gAVF8WOUxTHUXa0TkKEP6mvnr15g0AOqEgAOvskMymbQhj4vHMOw4pN3hkbGiaGM6RfDXmVfB62tkWXvDMDlflblg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uqMm2j+SmcU+qHCCp8snCjbggoseX+FZDTe7XG89qtI=; b=jQBBSWIeWeQOuc7sGv8g90skqFkZ/Zo2a7WB71gF0CCiiXTkFOjOvQaM1h/kLPTAetXHE4h2mIHSttDD7FdsLcyvc0Vh0wRg1p8kEyGQDPxtPV89yuTrTy/q70ED16LRs/5GI7u9u3x/ZPo9JxdDHwB9qYpIK5d/dRRShKz/nkA= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.5.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.9; Mon, 2 Mar 2020 09:36:44 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2793.011; Mon, 2 Mar 2020 09:36:44 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" , "ietf@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: Call for agenda items - Secdispatch IETF107 Thread-Index: AQHV8HYVzIXlT4duF0y+0pexmf9ihQ== Date: Mon, 2 Mar 2020 09:36:44 +0000 Message-ID: <3B0C0D88-08A0-4116-82A1-8ED007F4DE15@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 30250897-d5ba-4ee9-f3f4-08d7be8d3872 x-ms-traffictypediagnostic: HE1PR0702MB3625: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(396003)(366004)(39860400002)(189003)(199004)(4326008)(186003)(71200400001)(450100002)(316002)(6512007)(110136005)(8936002)(8676002)(81166006)(81156014)(64756008)(66476007)(66946007)(66446008)(66556008)(91956017)(76116006)(2906002)(5660300002)(26005)(6506007)(53546011)(33656002)(86362001)(44832011)(966005)(36756003)(2616005)(6486002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3625; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oYzPa2IP7L6txmqAutuQtTrVnHNFpGbL8pkAI2ntz8sJfrBp+CMdX+OYW4XPScB2xQOswzghlI2OGhb0Il0iExSbyNFATL5ZOdTyHHhZWWgtQEai4WLQVH4OzdJIvXcIF13n2iiF3Lp0IGNw6QeOG0eNneGeQLpLBcug1a3R6lDtWaaaINn32itulQ5/1+fteAKhzEyC/XUK1ODc9K8aznB/GLh22TBskXXtza+kM0sNqC9EQpxiCaYfOp42tzJPaZBhp81xULqmE81ml9ceCwfD9DZZOyBnCwZdabxITLGaRb9T3qgFUWnJrwwR6inM0stzrrxdiqtISUsT3bob6sDhftXM2xWKGfKgoaf0W3XVjeL358v9/6U3Q6+OWS9Th71NgJU7W6929s26pNGPd9LFQWpvnQHXJ3djma4DIKaEmatNDT1o+gAwO73gQXMqR8Mf9Ou4u56rcyeD7L7RWI0R8D6/+hH6G5XvUBACg0vQsCv5ih88oHWtyaZBv8I3siNeqJ6O1TAAQHi3S/m9cA== x-ms-exchange-antispam-messagedata: KjSCnRcUbYJ/wKBIwz/4d2YYM+JjhfFkcVVxRe1nEuUL/AzzA27HYJsOVQqt/WOnFEgpl/Zuml5fLCgKWGKYi9op+Qp64ZdWShrqVxO62lYMJTdfXQKTHTNM3a5RR8uydE8JUMrMqrQRC+NMszEEsw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3B0C0D8808A0411682A18ED007F4DE15ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30250897-d5ba-4ee9-f3f4-08d7be8d3872 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 09:36:44.2208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QhX0wO4XjKdE8QciqNmiNq8yXe8alC0mIYpaZWLjd3KMqHK7Nu7UTAJFj82WHa2P+UBA+Jz3GzTQHdTexd5XOPRzLbPulRHOKD9F73QYsMVu1+kkA40NCQfGPkzR+f8z X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3625 Archived-At: Subject: [Secdispatch] Call for agenda items - Secdispatch IETF107 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 09:36:52 -0000 --_000_3B0C0D8808A0411682A18ED007F4DE15ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGlzIGlzIGEgcmVtaW5kZXIgdG8gc2VuZCB5b3VyIGlucHV0IHRvIHRoZSBz ZWNkaXNwYXRjaCBtYWlsaW5nIGxpc3QgdG8gcHJlcGFyZSBmb3IgSUVURjEwNy4NCg0KSW4gb3Jk ZXIgdG8gZ2V0IGEgZHJhZnQgYWdlbmRhIG91dCwgdGhlIGRlYWRsaW5lIGZvciByZXF1ZXN0aW5n IGEgc2xvdCBvbiB0aGUgYWdlbmRhIGlzIE1hcmNoIDEwdGguDQoNCkFsc28sIHBsZWFzZSBub3Rl IHRoZSBuZXcgd2lraSB3aGVyZSB3ZSBoYXZlIHN0YXJ0ZWQgY29sbGVjdGluZyB1c2VmdWwgaW5m b3JtYXRpb24gb24gdGhlIHByb2Nlc3MgYW5kIHBsYW5uaW5nIG9mIFNlY2Rpc3BhdGNoIElFVEYx MDc6IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3NlY2Rpc3BhdGNoL3dpa2kgLiBGZWVkYmFj ayBpcyB3ZWxjb21lLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KRnJvbTogRnJhbmNlc2NhIFBh bG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+DQpEYXRlOiBUaHVyc2Rh eSwgMjAgRmVicnVhcnkgMjAyMCBhdCAwOTo0Nw0KVG86ICJzZWNkaXNwYXRjaEBpZXRmLm9yZyIg PHNlY2Rpc3BhdGNoQGlldGYub3JnPg0KQ2M6ICJzZWNkaXNwYXRjaC1jaGFpcnNAaWV0Zi5vcmci IDxzZWNkaXNwYXRjaC1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBDYWxsIGZvciBhZ2VuZGEg aXRlbXMgYXQgSUVURjEwNw0KUmVzZW50IGRhdGU6IFRodXJzZGF5LCAyMCBGZWJydWFyeSAyMDIw IGF0IDA5OjQ3DQoNCkhpLA0KDQpTZWNEaXNwYXRjaCB3aWxsIG1lZXQgYXQgSUVURjEwNy4gIE5v dyBpdOKAmXMgdGhlIHRpbWUgdG8gc3RhcnQgcHJlcGFyaW5nIHRoZSBkaXNjdXNzaW9uIHRvIG1h a2UgdGhlIGJlc3QgdXNlIG9mIG91ciB2YWx1YWJsZSBmYWNlLXRvLWZhY2UgdGltZS4gUGxlYXNl IGNvbnNpZGVyIHN0YXJ0aW5nIG9yIHBpY2tpbmcgdXAgbWFpbCBkaXNjdXNzaW9uIG9uIHRvcGlj cyB5b3XigJlkIGxpa2UgdG8gYnJpbmcgdXAuDQoNCklmIHlvdSB3b3VsZCBsaWtlIHRpbWUgb24g dGhlIGFnZW5kYSwgc2VuZCB5b3VyIHJlcXVlc3QgdG8gdGhlIG1haWxpbmcgbGlzdC4gIEhlbHBm dWwgaXRlbXMgdG8gaW5jbHVkZSBpbiB5b3VyIHJlcXVlc3QgKGlmIGtub3duL2FwcGxpY2FibGUp IGFyZToNCg0KKDEpIHBvaW50ZXJzIHRvIGEgZHJhZnQocykNCigyKSBwb2ludGVycyB0byBvbmdv aW5nL3ByaW9yIGRpc2N1c3Npb25zDQooMykgcG9pbnRlcnMgdG8gaW1wbGVtZW50YXRpb25zDQoo NCkgcG9pbnRlcnMgdG8gYW55IG90aGVyIGJhY2tncm91bmQgbWF0ZXJpYWxzDQooNSkgc3VtbWFy aXppbmcgcHJpb3IgZW5nYWdlbWVudCB3aXRoIGV4aXN0aW5nIFdHcw0KKDYpIHN1bW1hcml6aW5n IHdobyB3b3VsZCB3YW50IHRvIGFkdmFuY2UgdGhpcyB3b3JrDQooNykgZGVzaXJlZCBuZXh0IHN0 ZXBzDQoNCklmIG5lZWRlZCwgcHJlY2VkZW5jZSBpbiB0aGUgbWVldGluZyB3aWxsIGJlIGdpdmVu IHRvIGRvY3VtZW50cyB0aGF0IGhhdmUgZGVtb25zdHJhdGVkIGludGVyZXN0IGluIHRoZSBmb3Jt IG9mIGFjdGl2ZSBkcmFmdHMgYW5kIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLg0KDQpJZiB5b3Ug aGF2ZSBxdWVzdGlvbnMsIHBsZWFzZSByZWFjaCBvdXQgdG8gdGhlIGNvLWNoYWlycy4NCg0KRnJh bmNlc2NhDQo= --_000_3B0C0D8808A0411682A18ED007F4DE15ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4410909C0CCB764A86268F12F2B6EF22@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBpcyBhIHJlbWluZGVyIHRvIHNlbmQgeW91 ciBpbnB1dCB0byB0aGUgc2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0IHRvIHByZXBhcmUgZm9yIElF VEYxMDcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBvcmRl ciB0byBnZXQgYSBkcmFmdCBhZ2VuZGEgb3V0LDxiPiB0aGUgZGVhZGxpbmUgZm9yIHJlcXVlc3Rp bmcgYSBzbG90IG9uIHRoZSBhZ2VuZGEgaXMgTWFyY2ggMTA8c3VwPnRoPC9zdXA+PC9iPi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PGJyPg0KQWxzbywgcGxlYXNlIG5vdGUgdGhlIG5ldyB3aWtpIHdoZXJl IHdlIGhhdmUgc3RhcnRlZCBjb2xsZWN0aW5nIHVzZWZ1bCBpbmZvcm1hdGlvbiBvbiB0aGUgcHJv Y2VzcyBhbmQgcGxhbm5pbmcgb2YgU2VjZGlzcGF0Y2ggSUVURjEwNzoNCjxhIGhyZWY9Imh0dHBz Oi8vdHJhYy5pZXRmLm9yZy90cmFjL3NlY2Rpc3BhdGNoL3dpa2kiPmh0dHBzOi8vdHJhYy5pZXRm Lm9yZy90cmFjL3NlY2Rpc3BhdGNoL3dpa2k8L2E+IC4gRmVlZGJhY2sgaXMgd2VsY29tZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8YnI+DQpGcmFu Y2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2Zy YW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVy c2RheSwgMjAgRmVicnVhcnkgMjAyMCBhdCAwOTo0Nzxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7c2Vj ZGlzcGF0Y2hAaWV0Zi5vcmcmcXVvdDsgJmx0O3NlY2Rpc3BhdGNoQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7c2VjZGlzcGF0Y2gtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtz ZWNkaXNwYXRjaC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPkNhbGwg Zm9yIGFnZW5kYSBpdGVtcyBhdCBJRVRGMTA3PGJyPg0KPGI+UmVzZW50IGRhdGU6IDwvYj5UaHVy c2RheSwgMjAgRmVicnVhcnkgMjAyMCBhdCAwOTo0Nzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjRGlzcGF0 Y2ggd2lsbCBtZWV0IGF0IElFVEYxMDcuICZuYnNwO05vdyBpdOKAmXMgdGhlIHRpbWUgdG8gc3Rh cnQgcHJlcGFyaW5nIHRoZSBkaXNjdXNzaW9uIHRvIG1ha2UgdGhlIGJlc3QgdXNlIG9mIG91ciB2 YWx1YWJsZSBmYWNlLXRvLWZhY2UgdGltZS4gUGxlYXNlIGNvbnNpZGVyIHN0YXJ0aW5nIG9yIHBp Y2tpbmcNCiB1cCBtYWlsIGRpc2N1c3Npb24gb24gdG9waWNzIHlvdeKAmWQgbGlrZSB0byBicmlu ZyB1cC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlvdSB3b3Vs ZCBsaWtlIHRpbWUgb24gdGhlIGFnZW5kYSwgc2VuZCB5b3VyIHJlcXVlc3QgdG8gdGhlIG1haWxp bmcgbGlzdC4mbmJzcDsgSGVscGZ1bCBpdGVtcyB0byBpbmNsdWRlIGluIHlvdXIgcmVxdWVzdCAo aWYga25vd24vYXBwbGljYWJsZSkgYXJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+KDEpIHBvaW50ZXJzIHRvIGEgZHJhZnQocyk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDIpIHBvaW50ZXJzIHRvIG9uZ29pbmcvcHJpb3IgZGlz Y3Vzc2lvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDMp IHBvaW50ZXJzIHRvIGltcGxlbWVudGF0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4oNCkgcG9pbnRlcnMgdG8gYW55IG90aGVyIGJhY2tncm91bmQgbWF0 ZXJpYWxzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig1KSBz dW1tYXJpemluZyBwcmlvciBlbmdhZ2VtZW50IHdpdGggZXhpc3RpbmcgV0dzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig2KSBzdW1tYXJpemluZyB3aG8gd291 bGQgd2FudCB0byBhZHZhbmNlIHRoaXMgd29yazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4oNykgZGVzaXJlZCBuZXh0IHN0ZXBzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiBuZWVkZWQsIHByZWNlZGVuY2UgaW4gdGhlIG1lZXRp bmcgd2lsbCBiZSBnaXZlbiB0byBkb2N1bWVudHMgdGhhdCBoYXZlIGRlbW9uc3RyYXRlZCBpbnRl cmVzdCBpbiB0aGUgZm9ybSBvZiBhY3RpdmUgZHJhZnRzIGFuZCBtYWlsaW5nIGxpc3QgZGlzY3Vz c2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlvdSBoYXZl IHF1ZXN0aW9ucywgcGxlYXNlIHJlYWNoIG91dCB0byB0aGUgY28tY2hhaXJzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyYW5jZXNjYTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3B0C0D8808A0411682A18ED007F4DE15ericssoncom_-- From nobody Mon Mar 2 13:51:02 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71E3A0884 for ; Mon, 2 Mar 2020 13:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TWr67uTqD94 for ; Mon, 2 Mar 2020 13:50:57 -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 78D663A0880 for ; Mon, 2 Mar 2020 13:50:57 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id b22so317906pls.12 for ; Mon, 02 Mar 2020 13:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=hh7shVrPcnnqtsroD1xzj42gUQrdqwjhO9Z1u1hioks=; b=Q1TzUlZ6xuoIzkp+Gb0If6JCIepao5Y2ytoM7Sm5tyMPw5xfyksl9nxD8gXFcHY9Z7 shjJc6t7JV6gu7GhMDkR+kcUKy5iIjxwEuZXNpBtFHjK9Nv8EuNWsWUhyBoMWmELhIoC 2oS0nI8lr/hHdMIBCR2dUdEYsoh27S8xHr6icgxDT3HvUjwCctD9Xno77PfVJub14Ba7 X6+6HKI458NTx+1YyYPwHr5u/pKB8JNH+mTXqJ8U1yBcdwYIdkt1cQjwnratP+w4DzOz wjlq1bjJVFWS/hSZO0FOmabWsh2IHyuvWzyHjG5gcoItGxaNkEXHsrdDV0uylBwuvrMn Wrbw== 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=hh7shVrPcnnqtsroD1xzj42gUQrdqwjhO9Z1u1hioks=; b=HUbigFYmoRantm9uabHjB5+AV+vCDIgdkSnTOomXDpFK91gcoGwXv8J1Ph7DYMb7/u nK1kd9AhwKvaFdK6HHN0LaUN6Hfo1f7/TNqmnLSKCgi+s9kWrqWjB6e3tasBFoQDsbfS 2ZRHh2W+LrErktFmF4T8M6BDAe1a+rSUod1ajG55YP1nX93fnRv/Qkd2mhMTk96f8nCW IyrOdlIZvR8xQ2BM0pbqxNnXAKBeVT0rn7c46Q4v/fJ1Y3CvVaZyTZrQ8ji82h4vaE4r bpHTajmPsXj6t54LH6Z73xtDVjQdTUnLmQ9hPIfXAL847pRY7/aqobWiphAhlNCFuKRl 7qvg== X-Gm-Message-State: ANhLgQ2WNAiXA+1cgKNl1SFlrJ5UTmitQU4zsaNV4VVU2KHkkCgX0Q9L 007N9EUz+BJSVYuGg2MfLXg26H0hgGe1NMJaSu9YyDMEFxDjjwb59j21Em7DXmWkvQrBSGTj8fx rXCpZxBIvIwpnEskX+tILlan4noQ= X-Google-Smtp-Source: ADFU+vt55Q0aLq0HjOVZgHvTeemKkSkUMh9v8SgLASwCSsmJ82SQZ5wUVciKVyc2ZvzL8lT/vTUhI8auWuqtz2RV5FI= X-Received: by 2002:a17:902:aa45:: with SMTP id c5mr1070730plr.113.1583185856644; Mon, 02 Mar 2020 13:50:56 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Mon, 2 Mar 2020 14:50:30 -0700 Message-ID: To: secdispatch-chairs@ietf.org, secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000996687059fe62e0c" Archived-At: Subject: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:51:01 -0000 --000000000000996687059fe62e0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello SecDispatchers and Chairs thereof, I'd like to request some time on the agenda in Vancouver to present on https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ in an effort to gauge interest and potentially find an appropriate venue for the work to proceed (or just put it and its ridiculously long title out of its misery). Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications Abstract This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner. Discussion around the value of having something like this defined happened in the OAuth WG a bit before the Singapore meeting (no doubt that's not the only time but it's the one in which I was involved recently) and an AD nudged me to secdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ falls somewhere in the middle of that long and sometimes contentious thread. I was unable to get a draft published prior to the I-D submission cut-off for Singapore and got a short "if time allows" presentation slot at the meeting. The judgment coming out of that meeting was "needs draft". I did get an actual draft published a bit after Singapore (the one with the ridiculously long title previously mentioned) and there's been some, if not exactly an overwhelming amount of, discussion and support of it on this very list: https://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-something-someth= ing-certificate%22 Thanks. Brian Campbell --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000996687059fe62e0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello SecDispatchers and Chairs thereof,
I'd like to request some time on the agenda in Vancouver = to present on https://datatracker.ietf.org/doc/draft-bdc-somet= hing-something-certificate/ in an effort to gauge interest and potentia= lly find an appropriate venue for the work to proceed (or just put it and i= ts ridiculously long title out of its misery).

Client-Cert HTTP He= ader: Conveying Client Certificate Information from
=C2=A0 =C2=A0 =C2=A0= TLS Terminating Reverse Proxies to Origin Server Applications

Abstract<= br>
=C2=A0 =C2=A0This document defines the HTTP header field "Clien= t-Cert" that allows
=C2=A0 =C2=A0a TLS terminating reverse proxy to= convey information about the
=C2=A0 =C2=A0client certificate of a mutua= lly-authenticated TLS connection to an
=C2=A0 =C2=A0origin server in a c= ommon and predictable manner.

Discussion around th= e value of having something like this defined happened in the OAuth WG a bi= t before the Singapore meeting (no doubt that's not the only time but i= t's the one in which I was involved recently) and an AD nudged me to se= cdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XC= vxWbHwqlT3ITEEQoKo/ falls somewhere in the middle of that long and some= times contentious thread. I was unable to get a draft published prior to th= e I-D submission cut-off for Singapore and got a short "if time allows= " presentation slot at the meeting. The judgment coming out of that me= eting was "needs draft".

I did get = an actual draft published a bit after Singapore (the one with the ridiculou= sly long title previously mentioned) and there's been some, if not exac= tly an overwhelming amount of, discussion and support of it on this very li= st: https://mailarchive.ietf.org/arch/search= /?q=3D%22draft-bdc-something-something-certificate%22

Thanks.
Brian Campbell


=





=




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000996687059fe62e0c-- From nobody Mon Mar 2 15:54:25 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6167D3A1425 for ; Mon, 2 Mar 2020 15:54:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mR9B8eUtB2C for ; Mon, 2 Mar 2020 15:54:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF3A3A092E for ; Mon, 2 Mar 2020 15:54:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F7ED3897F for ; Mon, 2 Mar 2020 18:53:11 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DBB6EE6 for ; Mon, 2 Mar 2020 18:54:16 -0500 (EST) From: Michael Richardson To: secdispatch@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 23:54:23 -0000 --=-=-= Content-Type: text/plain Brian Campbell wrote: > Hello SecDispatchers and Chairs thereof, > I'd like to request some time on the agenda in Vancouver to present on > https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ > in an effort to gauge interest and potentially find an appropriate venue > for the work to proceed (or just put it and its ridiculously long title out > of its misery). > Client-Cert HTTP Header: Conveying Client Certificate Information from > TLS Terminating Reverse Proxies to Origin Server Applications > Abstract I have previously read this document. I was surprised it wasn't already a thing actually. I can't see why it would any place other than HTTPbis. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5dnKgACgkQgItw+93Q 3WWCbggAvdt0sVuRhbZkwYlyVWXam+6pqJTrjO1RiMdCkDcVTSe1v1nZTWs4ZLBZ chjhtxNSQt5AsPtS/hVar55x9bdrdc5FrxFTYF7vqbpIWkDl+4cWPLMdBkTvAmrx voU/KcbM5ZucvR1te+TpBHTYydKWA348xGMCwKx5gb2fX0Jd1fKmUryqDcvmbRs8 YFjjrizZMP/+O641+UdkRWz9mbd3jZ5qldVMuZkOMKEbZoNiqrcRRTb2uyXVtgcU KUSazNJijWo8eQ3eIndlIxU0dtZUjCQGIEdzMFV0DN8x5i17+sI4vW7JCXrf0B5V IGTqGojuapepnWdsuoifINFNPDOJFA== =AJ1J -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 5 23:24:41 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584BF3A08E1 for ; Thu, 5 Mar 2020 23:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl 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 JqYWDV1oZMog for ; Thu, 5 Mar 2020 23:24:37 -0800 (PST) Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.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 03CC03A08E0 for ; Thu, 5 Mar 2020 23:24:36 -0800 (PST) Received: from popmini.vanrein.org ([83.161.146.46]) by smtp-cloud9.xs4all.net with ESMTP id A7LUjoBvN9Im2A7LVjCYuB; Fri, 06 Mar 2020 08:24:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1583479466; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=IcFFHrZzuv/rhltlhldASMVYiJsQ7UATVmBeheF8yno=; b=E2Q+OLOqEGZQP/zv3xMDpIaE6SvXRk08KpiQxx8PCRaJwHhv/8yAq/XF 4N/G43/osbzduzhyCth96k9Jby6VoBdxmw+C4dcK8kDRWim5TL0XWu8l01 jdWfUJJyX7gmHqSfNKLD3WiDpkbTXi1FT+/+0Q7kuj687AWbsdVHXgjE0= Received: by fame.vanrein.org (Postfix, from userid 1006) id 05DE0271E9; Fri, 6 Mar 2020 07:24:25 +0000 (UTC) X-Original-To: secdispatch@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 20E3F271E6; Fri, 6 Mar 2020 07:24:21 +0000 (UTC) Message-ID: <5E61FAA4.3030902@openfortress.nl> Date: Fri, 06 Mar 2020 08:24:20 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: SECDISPATCH WG X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfKoV/y5kp6ui3ycQ+gz4XAWhu8mypmoEclwaE0xER8kEEXrAI7pBxz/SrTomUBbFQect4ZdHJdYA1vYsByIORtDXsQI3PeowfnI3zBiB3L/El02Ug7Hl krLNpCL82M5GlOMRayP43S6Y9vlaQb81m2xCvp1ATkXXxYP5UNXs1n5B990Q4vBCaXnbYSe1WAERpA== Archived-At: Subject: [Secdispatch] Draft: Adding SASL to HTTP X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 07:24:39 -0000 Hello, This draft proposes to introduce SASL as an authentication mechanism into HTTP. Adding such mechanisms requires IETF Review according to RFC 7235. I don't know where to turn, and this has long stopped this proposal from progressing. It currently hangs somewhere between DISPATCH And SECDISPATCH, so it would be useful to hear thoughts about this proposal. I have been made aware that SASL in HTTP has been tried before; the reasons why that didn't finish 15 years ago are resolved in this draft: Scalability: - stateless server side (server state relays through the client) - sequential messages distributed over connections is no problem Security: - no fixation on DIGEST-MD5 (compatibility pulls down security) - support for channel binding without fixating protocol layering Benjamin Kaduk noted my search for IETF mechanisms and responded with: > That said, I'm happy to see work in this space and would be willing to > AD-sponsor it upon a recommendation of either DISPATCH group, if that is > the recommendation. The authors of the prior HTTP SASL proposal also welcome this work being done. What are your recommendations towards this work? Thanks, -Rick Name: draft-vanrein-httpauth-sasl Revision: 04 Title: HTTP Authentication with SASL Document date: 2020-03-04 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-04.txt Status: https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/ Htmlized: https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-httpauth-sasl-04 Abstract: Most application-level protocols standardise their authentication exchanges under the SASL framework. HTTP has taken another course, and often ends up replicating the work to allow individual mechanisms. This specification adopts full SASL authentication into HTTP. From nobody Tue Mar 10 08:37:26 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6483A1124 for ; Tue, 10 Mar 2020 08:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5qtK6KfhKgL for ; Tue, 10 Mar 2020 08:37:23 -0700 (PDT) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (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 7ED623A0EB2 for ; Tue, 10 Mar 2020 08:37:23 -0700 (PDT) Received: by mail-oi1-f177.google.com with SMTP id c1so14294781oiy.2 for ; Tue, 10 Mar 2020 08:37:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oPqwfs5QgyRAiY/g9PJ2tlINiwvGKi7XPolOM8ItKEQ=; b=Pt/u7vpPbrIWUmfuOYg0RdjqZCny4zLRJRtBK8ZfBwLAISYPweA9TUOyqw0Su7KGIR Oai2d7F7M6KA6viQt3Izzd3pfTHHkwCBbCA2SpgMfdzZjlqweAL0YH9CgJ1n1tLWVWVV AfMFWYddwhlBb0xYLQilZDqRA4nzPC0/N2bbru0Bll4wEStziWvkj7NsT44/HmOD9vGU 7EuEO/y67KSt516/m74w0Ud2v1S6n3290l96L4jLgSXqL6NdmcenuLAapJ6G60L+RNoE 9xNgmB3WSG4gCt6MLalv0v4Gc2inPSDHMk+B/LIE6iA0t69tB1CynZgFd2qof2XnF8ZC 1hpA== X-Gm-Message-State: ANhLgQ3w/vFRS/+xZvF38rG6yqKcAeD+nYm51IdczCNH8cyoIJ5UTbiN QoQmaTJwrLJYF/tGPiv1BPtTQ2bOruU4cqhEaWpB5DiMTw4= X-Google-Smtp-Source: ADFU+vuNLCpwFcC5qU23yJYbfkjkpxbM8yrC7I0tv+qee3WQwJpOLb02gCr9LO/98udBSDL9qyXre+Y7gZckBJi1w40= X-Received: by 2002:aca:488a:: with SMTP id v132mr1621167oia.166.1583854642455; Tue, 10 Mar 2020 08:37:22 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Tue, 10 Mar 2020 11:37:11 -0400 Message-ID: To: IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000056ea3405a081e5ad" Archived-At: Subject: [Secdispatch] Deterministic generation of public key pairs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:37:25 -0000 --00000000000056ea3405a081e5ad Content-Type: text/plain; charset="UTF-8" [Yes I know this is too late for Vancouver, wanting to discuss] As folk may have noticed, I am currently proposing CFRG start work on the threshold cryptography work used in the Mesh. I would appreciate views on what should be done with another piece of the Mesh, the UDF scheme. The original goal of UDF was fairly modest, 'lets do PGP fingerprints a bit better using Base32'. But it has since gown. Most of the pieces are pretty unremarkable. How many formats do people need to represent a nonce in text? But one part that I have discovered is increasingly useful is the use of deterministic key generation. So for example let us say I use the udf tool to create an SSH key: udf keygen /x448 UDF: ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A udf config ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A This is a seed that can be written down and can be used to generate a private keypair using any of the commonly used public key algorithms. So you can use it for any application where you would use traditional key escrow. One thing I use this for is to move S/MIME and PGP keys about. Can also use it to keep a paper back up of whole disk encryption keys etc. The spec (but not the tool yet) also supports Shamir Secret Sharing. I need to rejig that to match the developments in the threshold spec. So is this something we should do and if so where? This is separable from the Mesh and does have some functionality overlap. But it also makes a lot of common sysadmin config much easier. --00000000000056ea3405a081e5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Ye= s I know this is too late for Vancouver, wanting to discuss]

As folk may have noticed, I am currentl= y proposing CFRG start work on the threshold cryptography work used in the = Mesh. I would appreciate views on what should be done with another piece of= the Mesh, the UDF scheme.

The original goal of UDF was fairly modest, 'lets do PGP fingerprints= a bit better using Base32'. But it has since gown. Most of the pieces = are pretty unremarkable. How many formats do people need to represent a non= ce in text?=C2=A0

But one= part that I have discovered is increasingly=C2=A0useful is the use of dete= rministic key generation. So for example let us say I use the udf tool to c= reate an SSH key:

udf key= gen /x448=C2=A0
UDF: ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A=C2=A0=C2=A0

udf config ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A=C2=A0

This is a seed that can be written down and can be use= d to generate a private keypair using any of the commonly used public key a= lgorithms. So you can use it for any application where you would use tradit= ional key escrow.

One thi= ng I use this for is to move S/MIME and PGP keys about. Can also use it to = keep a paper back=C2=A0up of whole disk encryption keys etc.

The spec (but not the tool yet) also su= pports Shamir Secret Sharing. I need to rejig that to match the development= s in the threshold spec.


So is = this something we should do and if so where? This is separable from the Mes= h and does have some functionality overlap. But it also makes a lot of comm= on sysadmin config much easier.


--00000000000056ea3405a081e5ad-- From nobody Tue Mar 10 10:00:56 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC03A16F0 for ; Tue, 10 Mar 2020 10:00:53 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=ncsc.gov.uk 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 5uiWq2NqxIqd for ; Tue, 10 Mar 2020 10:00:48 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100134.outbound.protection.outlook.com [40.107.10.134]) (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 820C43A16ED for ; Tue, 10 Mar 2020 10:00:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nOQN0TCRWTIPsg/GQFoM5M+8fQ43ZJ5P7LnEfbTHlICu3oPH6C76S+P1Yli73oyjD8Z2JKEykkwDjcph3pAish63dwtq4U0RQNiAVqQytNqYhH47Ragfo2bivRBDdavi4hSVlrsRHW82FITfPpbY1Fe8sUnIRi9e3iZc57c3++nk3CsFVtZMI1ITkq3VtZHrJcLsonwcxQPNC3pJuKOMrlvBJl2T4Dzh9ke6Z1ppDo8jPmX5fHmI3N5LJfU2IgdhaLSldu5XAoaUngiu8+4CDDTnu+19eX1mejelfbDqCb+3cBqpfHQ5Wowb5LJyTCmyX2+sQonrRrU9/tWdxsk3xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3bmfu1gC8s0lLojgwv1k7jlQd5biZc/4mmly7DDMJVc=; b=MaIBOdurKLm4lgPgND0hoZlwPGr4UV2FmSOFYVFMhm0yQ6mkd5LKuXSEtH+H8IIxykWs+038ltZqTrbVMu3B1GBmGiB/obteU9sdsfLzWrzLsEvU+Hng9kIb96BI5EGWm69jQRu5MmchgnS0CsFH1p3oMVQS2rEa2GnXQ3cC6vYfX64Avl7u0hx6r8t/KSm6xM4uV0QG9Wyt+DVszKxxfspOQHInSesHA82y+XHFpgWe09Dx4TbcXPNiatCz7FhxxB18k+Jz4cymViT6ygnvbM709yIKgUT7YDGhH1WEef70hB7qYfCJOUWHWoa/mPpTJBlCKVVnQNaKcJaIralfhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3bmfu1gC8s0lLojgwv1k7jlQd5biZc/4mmly7DDMJVc=; b=jijOr+cAzo74gDgUwSUhchV23WlTNTVWGmAmJTf7+MSw34i0xHww8eE3d9I5U5vTG81t+v05tNSfEmVgPiLpPNPrn2NCzRfgZaDQVbsBhrJFCrDeJjJZ4k0ytXj/1+9mtBSQbF+KhWpMZaf/F8Hh499JOt6P6oEDjMWrlfEVTa0= Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM (20.179.131.80) by LNXP123MB2122.GBRP123.PROD.OUTLOOK.COM (20.176.159.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Tue, 10 Mar 2020 17:00:43 +0000 Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c]) by LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c%6]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 17:00:43 +0000 From: Kirsty P To: "secdispatch@ietf.org" Thread-Topic: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt Thread-Index: AQHV86jPt3WqYZHQGkS6Pyj9v0KtrKg7fH1MgAaWl5o= Date: Tue, 10 Mar 2020 17:00:43 +0000 Message-ID: References: <158349344094.2274.4065518603647811950@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kirsty.p@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66ea9a61-c63d-4760-b44a-08d7c51491d6 x-ms-traffictypediagnostic: LNXP123MB2122: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(346002)(366004)(396003)(39850400004)(199004)(189003)(316002)(966005)(6506007)(55236004)(478600001)(86362001)(52536014)(71200400001)(7696005)(186003)(76116006)(6916009)(8676002)(5660300002)(66946007)(19627405001)(8936002)(33656002)(9686003)(55016002)(64756008)(81166006)(26005)(15650500001)(66446008)(66556008)(2906002)(81156014)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:LNXP123MB2122; H:LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s3YuZs21Jws/RB/pYNpTpD4FKqoIkDcC3Go93h5VKyOoeNfwo6VVmg5KVO+hzujonVSA6cH5XK2FNXTdpYLSVFJ4U8mPArPK22X+NRQVE+054A6IoCU6f++FzyvKySdWNiwjPb/hj5hrh/qLMPOPWfxPukiWNMNOt/IxGm8raIfmANSVAuIsdxv+yxf8b9My74dwCkfm8sO0WvvBGGYQDH/YI9coKtLVSUJ/DgZSRxpak++T72hsCI5ULGq2Uisry6Qj2g8yoGs+8yEUjicwjJ7zvKlx8PpI/JPhX3edrzkkqNKissJzVItPw4jI4l0AZC+cSpG34y5y6zF/cFCm1rsazR3FTNtlKHeYze/M41cZWEUDLYPf8vI0I30Pc2s5sB3C4tmndtRwWkYmXXPe/hGVQmWY/UMdVmV4LdDyp+iESnpoeCbnhbRiTfLxUlGbJF/zTVMDdSVCQwio95ncFDndPyvLFU4DIqGOmMN6ewcvbOr+FLtyEpOjwlXe1XiuOAPkXi5qplIAwBF5vOxrUw== x-ms-exchange-antispam-messagedata: dSBUH/GIyMHihyRR42U0I3ceHflVExCcPpy9iAj7PcVLZ60Stw5VCLPeGhxeOPQYyls+qQlnXXblRwa06TqqATnRSSC7kZeuesn+civiYjBXJZuKnX1aniZ9bU+iGg3GzT+hUTNovzL2zyTHxErUWA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB2330E7D239FABA31AA1B93C7D7FF0LNXP123MB2330GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 66ea9a61-c63d-4760-b44a-08d7c51491d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 17:00:43.1990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uI7dGG5Hur2L2aXZcd+Yghv36TxS81vJftCngUPrRq1Yu/2SRNPwmm38HOqQnbDmXJ/aY7YGr2U02ccPcG9CwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB2122 Archived-At: Subject: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:00:54 -0000 --_000_LNXP123MB2330E7D239FABA31AA1B93C7D7FF0LNXP123MB2330GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'd like to request a slot at secdispatch for IETF 107 to present the draft= below. Additionally, comments/feedback on the draft from interested parties are ve= ry welcome. Kirsty A new version of I-D, draft-paine-smart-indicators-of-compromise-00.txt has been successfully submitted by Kirsty Paine and posted to the IETF repository. Name: draft-paine-smart-indicators-of-compromise Revision: 00 Title: Indicators of Compromise (IoCs) and Their Role in Attack De= fence Document date: 2020-03-06 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/id/draft-paine-smart-indicators-of-com= promise-00.txt Status: https://datatracker.ietf.org/doc/draft-paine-smart-indicato= rs-of-compromise/ Htmlized: https://tools.ietf.org/html/draft-paine-smart-indicators-of= -compromise-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-paine-smart-ind= icators-of-compromise Abstract: Indicators of Compromise (IoCs) are an important technique in attack defence (often called cyber defence). This document outlines the different types of IoC, their associated benefits and limitations, and discusses their effective use. It also contextualises the role of IoCs in defending against attacks through describing a recent case study. This draft does not pre-suppose where IoCs can be found or should be detected - as they can be discovered and deployed in networks, endpoints or elsewhere - rather, engineers should be aware that they need to be detectable (either by endpoint security appliances or network-based defences, or ideally both) to be effective. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB2330E7D239FABA31AA1B93C7D7FF0LNXP123MB2330GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I'd like to request a slot at secdispatch for IETF 107 to present the draft= below. 
Additionally, comments/feedback on the draft from interested parties are ve= ry welcome.

Kirsty



A new version of I-D, draft-paine-smart-indicators= -of-compromise-00.txt
has been successfully submitted by Kirsty Paine and posted to the
IETF repository.

Name:           draft-pai= ne-smart-indicators-of-compromise
Revision:       00
Title:          Indicators of = Compromise (IoCs) and Their Role in Attack Defence
Document date:  2020-03-06
Group:          Individual Sub= mission
Pages:          15
URL:            https://www.ietf.org/id/draft-paine-smart-indicators-of-compromise-00.txt
Status:       &= nbsp; https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-compromise= /
Htmlized:       https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-paine-smart-indicators-of-compr= omise


Abstract:
   Indicators of Compromise (IoCs) are an important technique in = attack
   defence (often called cyber defence).  This document outl= ines the
   different types of IoC, their associated benefits and limitati= ons,
   and discusses their effective use.  It also contextualise= s the role
   of IoCs in defending against attacks through describing a rece= nt case
   study.  This draft does not pre-suppose where IoCs can be= found or
   should be detected - as they can be discovered and deployed in=
   networks, endpoints or elsewhere - rather, engineers should be= aware
   that they need to be detectable (either by endpoint security    appliances or network-based defences, or ideally both) to be    effective.




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

The IETF Secretariat
This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB2330E7D239FABA31AA1B93C7D7FF0LNXP123MB2330GBRP_-- From nobody Tue Mar 10 10:28:11 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726243A1652 for ; Tue, 10 Mar 2020 10:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_LiuHNX4TK0 for ; Tue, 10 Mar 2020 10:28:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E523A1659 for ; Tue, 10 Mar 2020 10:28:04 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D4AC43818F; Tue, 10 Mar 2020 13:26:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CD268825; Tue, 10 Mar 2020 13:27:58 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: IETF SecDispatch In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Deterministic generation of public key pairs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:28:10 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > udf config ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A > This is a seed that can be written down and can be used to generate a > private keypair using any of the commonly used public key algorithms. So > you can use it for any application where you would use traditional key > escrow. > One thing I use this for is to move S/MIME and PGP keys about. Can also use > it to keep a paper back up of whole disk encryption keys etc. > The spec (but not the tool yet) also supports Shamir Secret Sharing. I need > to rejig that to match the developments in the threshold spec. > So is this something we should do and if so where? This is separable from > the Mesh and does have some functionality overlap. But it also makes a lot > of common sysadmin config much easier. I think AD sponsorship for the entire UDF document. (Not just the deterministic key generation part. or was that part of your goal?) A better name is needed, as there has been snakeoil created that had a similar name. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5nzh4ACgkQgItw+93Q 3WVfrwf/ea+Bn4DtZBOV9TCj4Usa+G9mXS3t5bhSDU9+VJwnojvOClnegqD5aWpv /IZsaGrrHVfVK8QsSjuf5sSJA9g0gcGwoknLZWW7NCho1l5z1VRuEXJIMae1G8oS Jw6DmIz5Vgn5Yh9a/hf3eM0j/UpTbBqx2NduuYtB3VLjQqrEtyEiMzUNum5Rz3d8 vm7wOQwnyB3jYJjX5KYmtFEfTOXE/oOxCZEWbTR1Zc85UFiYWm1BV8oariT9ng1T iur1Enis3uxaLLc+T07NFDy/smS5+7uTgkqqh+l8syd3gUr7wG7mHT2KrK09PoAa 3wGfNMZLb/FE50e1YenMb03aL35uyw== =Sn3f -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 10 10:36:30 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E1A3A1810 for ; Tue, 10 Mar 2020 10:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiAGEDmyR0S2 for ; Tue, 10 Mar 2020 10:36:25 -0700 (PDT) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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 97E413A180B for ; Tue, 10 Mar 2020 10:36:25 -0700 (PDT) Received: by mail-oi1-f174.google.com with SMTP id i1so14694909oie.8 for ; Tue, 10 Mar 2020 10:36:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2MSJTFi7nu29xwC8h/yZZHgR+NQZBjbbMwuMfegva7g=; b=WNrljsRPKLeb58yI5f6ejiuBqP8Kr3IFBfqzC/ZkwLgsUVPHEim5mhYPbEJaLSAsQc 6sf3Mq7mn/vCx5oMhL9bMSQcbH1m4b2JwS+1P+ZYnFrz3GFxphg9FIew5+Mj7N7affP+ wi8dw2DKXZS1ou1H3KBKt4xoOQXHTIEUeWZiv+nGpa3fSpodq5o3NYNeRkW+gfm/UnOv 94tmViNFiMyPzer9bB1yO9wZvgyP0b1+A/1HRZkRU7rBOHUOFyoIvpBBL1cAyY1ui0tA 71KgPplpcAX6llagrFARXKlYX6YjUTzlXG25LwUPVV1iuGU0Y7l5g4xrURZSehUHbqTr oQCw== X-Gm-Message-State: ANhLgQ17F0VCHUKfWLpBVlcsvAjr6IZZK1zVZcvfCSvAgFIV+rPkmPMf krrHT4ojxGZpf0dN5E7jw6jOLYka4VZBBi924zVJoYa/ X-Google-Smtp-Source: ADFU+vtsIHyQKOMhV9Fa/azl745m4Tm74yYNPydW0tRXzq7Hmah2Iqm903Jzq2PkTJhT4MGE1zAFwfZ/1CYPUqiRVcc= X-Received: by 2002:aca:4106:: with SMTP id o6mr1995530oia.173.1583861784883; Tue, 10 Mar 2020 10:36:24 -0700 (PDT) MIME-Version: 1.0 References: <13723.1583861278@localhost> In-Reply-To: <13723.1583861278@localhost> From: Phillip Hallam-Baker Date: Tue, 10 Mar 2020 13:36:14 -0400 Message-ID: To: Michael Richardson Cc: IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000000fb76305a0838f54" Archived-At: Subject: Re: [Secdispatch] Deterministic generation of public key pairs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:36:27 -0000 --0000000000000fb76305a0838f54 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 10, 2020 at 1:28 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > udf config ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A > > > This is a seed that can be written down and can be used to generate a > > private keypair using any of the commonly used public key > algorithms. So > > you can use it for any application where you would use traditional > key > > escrow. > > > One thing I use this for is to move S/MIME and PGP keys about. Can > also use > > it to keep a paper back up of whole disk encryption keys etc. > > > The spec (but not the tool yet) also supports Shamir Secret Sharing. > I need > > to rejig that to match the developments in the threshold spec. > > > > So is this something we should do and if so where? This is separable > from > > the Mesh and does have some functionality overlap. But it also makes > a lot > > of common sysadmin config much easier. > > I think AD sponsorship for the entire UDF document. > (Not just the deterministic key generation part. or was that part of your > goal?) > I would like to do the whole doc can drop Secure Internet Names which are a bit on the edge. The digest function parts could be bikeshedded of course but probably not usefully. > A better name is needed, as there has been snakeoil created that had a > similar name. > I am OK with the IETF calling it anything people like except for Fred. If isn't really a fingerprint format at this point either. --0000000000000fb76305a0838f54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 10, 2020 at 1:28 PM Michael Richardson = <mcr+ietf@sandelman.ca>= ; wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > udf config ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-= K4A

=C2=A0 =C2=A0 > This is a seed that can be written down and can be used = to generate a
=C2=A0 =C2=A0 > private keypair using any of the commonly used public ke= y algorithms. So
=C2=A0 =C2=A0 > you can use it for any application where you would use t= raditional key
=C2=A0 =C2=A0 > escrow.

=C2=A0 =C2=A0 > One thing I use this for is to move S/MIME and PGP keys = about. Can also use
=C2=A0 =C2=A0 > it to keep a paper back up of whole disk encryption keys= etc.

=C2=A0 =C2=A0 > The spec (but not the tool yet) also supports Shamir Sec= ret Sharing. I need
=C2=A0 =C2=A0 > to rejig that to match the developments in the threshold= spec.


=C2=A0 =C2=A0 > So is this something we should do and if so where? This = is separable from
=C2=A0 =C2=A0 > the Mesh and does have some functionality overlap. But i= t also makes a lot
=C2=A0 =C2=A0 > of common sysadmin config much easier.

I think AD sponsorship for the entire UDF document.
(Not just the deterministic key generation part. or was that part of your g= oal?)

I would like to do the whole doc can drop Secure Inte= rnet Names which are a bit on the edge. The digest function parts could be = bikeshedded of course but probably not usefully.

=C2=A0=
A better name is needed, as there has been snakeoil created that had a
similar name.

I am OK with the IETF calling it anything peo= ple like except for Fred.

If isn't really a fingerprint format at this point either.
=
--0000000000000fb76305a0838f54-- From nobody Tue Mar 10 10:39:05 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4033A180C for ; Tue, 10 Mar 2020 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaW4dhlXfebK for ; Tue, 10 Mar 2020 10:38:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FD63A1801 for ; Tue, 10 Mar 2020 10:38:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 733C93818F; Tue, 10 Mar 2020 13:37:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6D1B2825; Tue, 10 Mar 2020 13:38:56 -0400 (EDT) From: Michael Richardson To: Kirsty P cc: "secdispatch\@ietf.org" In-Reply-To: References: <158349344094.2274.4065518603647811950@ietfa.amsl.com>, X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 17:39:03 -0000 --=-=-= Content-Type: text/plain Hi, thank you for this interesting document. It uses terminology which I did not know existed before. The document does not specify a protocol of any kind, although MISP-project is referenced. It does not seem to be about any kind of directly implementable Best Current Practice, but seems like background for something bigger. I'm not sure how publishing this as an RFC would be helpful. Are you considering ways to represent the Indicators such that they can be more easily exchanged? I believe that the IETF has done a bunch of work in that area (INCH, MILE, IODEF come to mind), but perhaps not exactly in this direction. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5n0LAACgkQgItw+93Q 3WVsdAgAqJyQfvHep7/bZ04JQtyqnyEw+xW1Rr1r1hVVVOH2mTsRNL4PuoTRcdbL dZiwclZOCkAhC97mIR+qWVemmgqSsFIioN8tIwLTy6Z0saATiYS7C0g4BFPIRnHq 5CPQwPOz406DXK4HJT16hV1jHy08d8tsLZlf4WJc1+aNTmw0P00gpdt/EHol7dTa q9xRF1R8LF8HlvCEQvCztpOiNATKVbRfIlhLGR5Vrdw0OeSwJQY3e4j7sx2O7om7 02uLpZ6R037Po1UafgTRv1toHlCJDr6xyLI1ApSste/YqvgiYub9Xbf+/JX9Hofk YtJSExVbVrKsDMQUgEA6h7zEyknmOA== =UZpJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 11 10:16:15 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771093A0E8C for ; Wed, 11 Mar 2020 10:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFk6TynqrF3c for ; Wed, 11 Mar 2020 10:16:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CF63A0E8A for ; Wed, 11 Mar 2020 10:16:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D0DD038986; Wed, 11 Mar 2020 13:14:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9FDCEAE8; Wed, 11 Mar 2020 13:16:01 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: IETF SecDispatch In-Reply-To: References: <13723.1583861278@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Deterministic generation of public key pairs X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 17:16:14 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: >> Phillip Hallam-Baker wrote: > udf config >> ssh-agent ZAAA-FFQA-3LE5-SAHG-E6K6-HOTN-TVLB-K4A >> >> > This is a seed that can be written down and can be used to generate >> a > private keypair using any of the commonly used public key >> algorithms. So > you can use it for any application where you would >> use traditional key > escrow. >> >> > One thing I use this for is to move S/MIME and PGP keys about. Can >> also use > it to keep a paper back up of whole disk encryption keys >> etc. >> >> > The spec (but not the tool yet) also supports Shamir Secret Sharing. >> I need > to rejig that to match the developments in the threshold >> spec. >> >> >> > So is this something we should do and if so where? This is separable >> from > the Mesh and does have some functionality overlap. But it also >> makes a lot > of common sysadmin config much easier. >> >> I think AD sponsorship for the entire UDF document. (Not just the >> deterministic key generation part. or was that part of your goal?) >> > I would like to do the whole doc can drop Secure Internet Names which > are a bit on the edge. The digest function parts could be bikeshedded > of course but probably not usefully. okay, we agree that the whole document should go as a single thing. >> A better name is needed, as there has been snakeoil created that had a >> similar name. > I am OK with the IETF calling it anything people like except for Fred. > If isn't really a fingerprint format at this point either. It was specifically the Deterministic Generation of Public Key Pairs that I think matches some decade-old snake oil. I will google a bit to see if I can find that. Some variation on "Portable Privacy" might be the right direction. I think that this Beauty Contest is the only important thing left to do with the document :-), which I guess says something how mature I think it is. I've had an offline 1024-bit RSA key root@sandelman.ca in a secure place six different generations of media for 25 years. Clearly, it's now too weak to bother with. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5pHNEACgkQgItw+93Q 3WXJ0AgAwTCJuCTasfUE2ix2lotRHOQEvNDFHZ4bFcG7LweRzhkqDpB7HViqUXpf EAaP+59OGno64lYTzIFy9Eigh9JESlFiXly56ABUke2euMNO9izbOfO4FmSOciYJ MXCboeLeljIp5pistEvju8QTYW0wVeckxiLe6bRk4XD9wQ9Dze6XGJF4mgkbpO5d zoJyREaspaCrxWKgj7VRgFizWOe7pMwFkUkJi0HMyRnP2SfGOUDkuMqfPnvVCsCo liUsbAZ7dCnTMOpnsHTrj/+ExJjy9AOVoKTY4Rbl2bwGhahUIWnPjCevwS8jgYro 7otd2iYciNzQyAmgUWtpOwx2HpRE1w== =6J3j -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 13 06:29:01 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47AD3A03EF for ; Fri, 13 Mar 2020 06:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 3V-hmht54eNl for ; Fri, 13 Mar 2020 06:28:57 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100132.outbound.protection.outlook.com [40.107.10.132]) (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 F19903A03EC for ; Fri, 13 Mar 2020 06:28:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L1pZaRmOmIWfegfmGYYTJpDkkKInpcFUwTLlAxaXwzLN/LLp1KS1aWHftJJp8Gcgaij9ve75uOV0gOWx46G77GeuM+9Ki/t34yxCk7GoZpNBLgkG+Z1dzDmR61bdqboL+jPPrZ/RNb0pYr+PB0q215Cu5BeG0SkgUgKV3tgXjXPL0guuVLuakaYc0p4PZVKdagThMsIRdigCzyjAAGooPKn36P2zD/kgKLeiHt0IEb20kkbWaIVNWjTT/TD3l4Xs3MhwctPvWLImWuQkS6mqhglaImR3JSCc69dlnsz2PhgVniT2Fy/6mJ8DENGiAUSmaUXYDVH072kN7pXlxjFRag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4jVloRIXlp0WdPSqJ4tzyWzkHA3EJ/O05AXWi1MUF1w=; b=CUXzoqBmD4k2GI49BVT8Tmp8WecUp1n5JGeZmIt4e5edE+s2BPvXcomP45w6NsvKdwZ/qAx6NwLkwu4SoFaIA/L2zJYw8corUhMV7ZZ0Ik6W3wSyBlEO0ftp9AniFMhZH2LlyjnsVewuT1PSLzEbwXUBDiOHrQ1gUT50hq+td2YGJVEkL6k9FEP6FEP8/65GhAGnM70CtfJr37WhCKKifSQax1YPsvkcRLAT2/PjbeX20vC53RlGYhtouxxTs7xPXC4Bq/tyn5M/7Oj37MaqnOB+n0yfog3RDNKm2gWoMQK4GwgZlNLYipHZJ5jATB4jjlF5/gOkt/iyWjcXOTmH8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4jVloRIXlp0WdPSqJ4tzyWzkHA3EJ/O05AXWi1MUF1w=; b=mURI+DLp2H2WRmd7K9Htco3IJ7Y6dKz5lM0fM5L3zyz23g5DvO+yZyrw3iNZ9q0Ga7CVZI9MiwDp+FZsXTnlQBfl4lXxgWP71jugQyro7frMWYgu1pPvVfN1HXcmV+BXPexneLkOY6WcX1UC361JFprT/mnhuEPb2SM1X++Hmk4= Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM (20.179.131.80) by LNXP123MB1689.GBRP123.PROD.OUTLOOK.COM (20.179.129.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.16; Fri, 13 Mar 2020 13:28:48 +0000 Received: from LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c]) by LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM ([fe80::dc7a:97bb:102a:9c1c%6]) with mapi id 15.20.2793.013; Fri, 13 Mar 2020 13:28:48 +0000 From: Kirsty P To: Michael Richardson CC: "secdispatch@ietf.org" Thread-Topic: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt Thread-Index: AQHV+TsjkeM0ZezgBUeK9w+2MoZ0XQ== Date: Fri, 13 Mar 2020 13:28:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kirsty.p@ncsc.gov.uk; x-originating-ip: [51.140.78.31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6cb1316-9eea-45f6-4a3b-08d7c7527688 x-ms-traffictypediagnostic: LNXP123MB1689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 034119E4F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(366004)(39850400004)(136003)(199004)(64756008)(81156014)(66556008)(66476007)(66946007)(76116006)(186003)(66446008)(5660300002)(26005)(52536014)(4326008)(8936002)(15650500001)(316002)(81166006)(86362001)(6916009)(33656002)(8676002)(478600001)(966005)(53546011)(55016002)(55236004)(9686003)(6506007)(2906002)(7696005)(71200400001)(19627405001); DIR:OUT; SFP:1102; SCL:1; SRVR:LNXP123MB1689; H:LNXP123MB2330.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: I/8Ey3qgCbAk+8XFpgSwGm73Uw6hOj56ciwz84wCCfTfhvCwZKYVtK9RjGZhmChlYz1ermCrOyZdSxeiIhWJ8LyFGLVX6VeGhQWKnEdllhWGyv35t6TrBNHYq8E7mc7YJWHoiijByba1Yo8kgQQza2BYM/gJTW1QjGjr6oX14RzRTxgWSKYHCMnULV0LyePGZG24dRttTgviFcPfoPjfUmVl8ldvr3+K4xWQWKq/2czyfTViiT/0vgPn5m0UcZ04j2u7iabQHmbznpPxK6AFf5VqIs9ac7r6x2TcNIVUQr7nuhSvpfyiNmw9qeKRRF121ZbEXL6MxD45P78Ry5QbUDuH7vbAplXl8Sng7WOUVthjip8vN3Oxz4tDXXE3g1jr/l4/qFWa4e3ZTcDmDbIeyaVljKyZm1yYGK2xkBawGRFO7v5CfFfSlQguz51jyU9fMh51BvVCnL2S02F6c03sCo1W/IjiwP0BTnObV0cKGIh8EoZe5bWf0IQURdQFlupOs0RMczPS0Y9X2ofnFUok+w== x-ms-exchange-antispam-messagedata: n2HDxK144Sv/zIk7/bFCu35DCK3pBreRysEkZUW4BCz735w4OCJjYTljg0BsGjKJoYFpH5nDV9eSqbjuLopEpduw57kqgolI7Cham74+k5wC32ezorAhov4P/uVkQ2APvmlYQnZiVaPwHQJj+KrPRw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LNXP123MB23307096A4D421A16F43BC90D7FA0LNXP123MB2330GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: e6cb1316-9eea-45f6-4a3b-08d7c7527688 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2020 13:28:48.4924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pBi8NE93JS/3uGSePfi/7Uygwsf+/mYLFayBPfoBlkHzOveJrchd0P9BfljV206A3DAz8yYVclImjlhFY7py0Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP123MB1689 Archived-At: Subject: Re: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 13:29:00 -0000 --_000_LNXP123MB23307096A4D421A16F43BC90D7FA0LNXP123MB2330GBRP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for your interest in the draft. You=92re right that we=92re not setting out to specify a protocol, or neces= sarily an example of Best Current Practice, but the ability to detect and u= se Indicators of Compromise to protect against attack can be impacted heavi= ly by protocol design decisions, so there is a clear benefit in providing a= reference to help designers to consider this impact. Given that, I hope that this will become an Informational RFC, but I=92m ke= en to hear more thoughts on the most appropriate way to publish what we bel= ieve to be an important aid to those considering protocol security. ________________________________ From: Michael Richardson Sent: Tuesday, March 10, 2020 17:38 To: Kirsty P Cc: secdispatch@ietf.org Subject: Re: [Secdispatch] Fw: New Version Notification for draft-paine-sma= rt-indicators-of-compromise-00.txt Hi, thank you for this interesting document. It uses terminology which I did not know existed before. The document does not specify a protocol of any kind, although MISP-project is referenced. It does not seem to be about any kind of directly implementable Best Current Practice, but seems like background for somethin= g bigger. I'm not sure how publishing this as an RFC would be helpful. Are you considering ways to represent the Indicators such that they can be more easily exchanged? I believe that the IETF has done a bunch of work in that area (INCH, MILE, IODEF come to mind), but perhaps not exactly in this direction. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB23307096A4D421A16F43BC90D7FA0LNXP123MB2330GBRP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks for your interest in the draft.

You=92re right that we=92re not setting out to specify a protocol, or = necessarily an example of Best Current Practice, but the ability to detect = and use Indicators of Compromise to protect against attack can be impacted = heavily by protocol design decisions, so there is a clear benefit in providing a reference to help designers to = consider this impact. 

Given that, I hope that this will become an Informational RFC, but I= =92m keen to hear more thoughts on the most appropriate way to publish what= we believe to be an important aid to those considering protocol security.<= /div>


From: Michael Richardson
Sent: Tuesday, March 10, 2020 17:38
To: Kirsty P
Cc: secdispatch@ietf.org
Subject: Re: [Secdispatch] Fw: New Version Notification for draft-pa= ine-smart-indicators-of-compromise-00.txt


Hi, thank you for this interesting document.
It uses terminology which I did not know existed before.

The document does not specify a protocol of any kind, although MISP-project=
is referenced.   It does not seem to be about any kind of directl= y
implementable Best Current Practice, but seems like background for somethin= g
bigger.

I'm not sure how publishing this as an RFC would be helpful.
Are you considering ways to represent the Indicators such that they can be<= br> more easily exchanged?  I believe that the IETF has done a bunch of wo= rk in
that area (INCH, MILE, IODEF come to mind), but perhaps not exactly in this=
direction.

--
]            &n= bsp;  Never tell me the odds!       = ;          | ipv6 mesh network= s [
]   Michael Richardson, Sandelman Software Works   = ;     |    IoT architect   [ ]     mcr@sandelman.ca  http://www.sandelman.ca/        |&nb= sp;  ruby on rails    [


This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LNXP123MB23307096A4D421A16F43BC90D7FA0LNXP123MB2330GBRP_-- From nobody Fri Mar 13 13:59:30 2020 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 726F13A1019; Fri, 13 Mar 2020 13:59:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, secdispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158413314745.3136.2959651919077781044@ietfa.amsl.com> Date: Fri, 13 Mar 2020 13:59:07 -0700 Archived-At: Subject: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 107 X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 20:59:20 -0000 Dear Francesca Palombini, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. secdispatch Session 1 (2:00 requested) Friday, 27 March 2020, Session I 2000-2200 Room Name: Virtual Track 1 size: None --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/secdispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Security Dispatch Area Name: Security Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: Chair Conflict: saag dispatch ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secevent suit teep tls tokbind trans cbor core gendispatch Technology Overlap: httpbis People who must be present: Kathleen Moriarty Roman Danyliw Richard Barnes Francesca Palombini Resources Requested: Special Requests: Please avoid conflict with any Security related BoF. Please schedule for a session of at least 2h. --------------------------------------------------------- From nobody Tue Mar 17 13:33:26 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF103A0D72; Tue, 17 Mar 2020 13:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvKz1QMyXjrf; Tue, 17 Mar 2020 13:33:22 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::610]) (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 BA6733A0D71; Tue, 17 Mar 2020 13:33:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U0c0GfkcrWiod9A8AXVfycp+mV1Cz6AA4ZVsewYVBKXYXPXux5cCxausxCyEEFm3D53dWXQbE1aJLarVG+MOtX707fLdjgmL8bB6Vn7XbXena3J7A883PeqpcaTaj1kWvVEXXyXxaojMZKXD5esLVe0aXx4R+AegVZ7+g2VRogwSGazLoMyb4ijYmmOlf1PbfFIF5hMUL4I4xjnH7Sd26I58R/h9hK5DiZ1szWCwapjW4jDu+Zd17ktmOoPqd919RYN8i9/3HfLp8T28qyGjjMsSyp687HO6VYCuG1eI0ANxcHfRJKJxd43sOjnyscGrXgUgUb2Hy1YFuXeMqeWj3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PS+w9Xv0faIsy7QSsL9EK3SNHmkqOlKyvUSHFwr/Gw4=; b=HurPuTa4oRyxjENC0pO8G4dv7Dyk3MFFmw0GKoxHLMuBJ1IreMJ8bq5tMkm+3Rx0lYjyssedBFDzQ60ySEwH3rfW4/+JpjpohFfpnXnTUPDSUMLJxrdhI2INhyRhcl07EScx/twPy0lSrsB+c/F8wVK10UE1Z9Nb+1TTd9G3y2wlwta9qQySVzpn0EyNuRuFxS1zM5qLJToE8CM2mSIvmv2I4rTHRNdAawb2bbxLBlQp9TX0wZqXn71tprf1moouKr+RcfsZc3VxuP0H68/vzLZ9bRZWClls1eQ7VulMwByK9NT0URbDB40KG9tjveHywV0BE/G6HfJfPHTSgqO8KA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PS+w9Xv0faIsy7QSsL9EK3SNHmkqOlKyvUSHFwr/Gw4=; b=Y/zL1cgJC/OlgcJWG7tkh4AOvc2P6tixmylgC6hKeF5/cud3mzd4yDZuDxCbnR92G8c2nHxn4z4Z4JjBd1t3RCfWnalwpMhvgL11+87Wa1hz51SoNAMm6z3TA3Q+oswCfV/WqaDbPkHGS9MhL9wjpWML9cFv2ea7n4VsjdnBmGk= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (52.133.6.18) by HE1PR0702MB3643.eurprd07.prod.outlook.com (10.167.125.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.10; Tue, 17 Mar 2020 20:33:16 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::e49e:708f:4fe7:5d02%4]) with mapi id 15.20.2835.013; Tue, 17 Mar 2020 20:33:16 +0000 From: Francesca Palombini To: "secdispatch@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: IETF 107 agenda + looking for minute takers Thread-Index: AQHV/JtJt4IgoexkaUGGCYhWnup7EQ== Date: Tue, 17 Mar 2020 20:33:16 +0000 Message-ID: <1F61FF0E-875D-4843-8256-A1CA2299774C@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec7fdd70-0599-4202-8809-08d7cab26c69 x-ms-traffictypediagnostic: HE1PR0702MB3643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(39860400002)(366004)(396003)(199004)(71200400001)(966005)(478600001)(2906002)(6506007)(6486002)(26005)(316002)(33656002)(8936002)(76116006)(6916009)(186003)(66476007)(66446008)(66556008)(64756008)(81166006)(36756003)(81156014)(66946007)(8676002)(5660300002)(86362001)(2616005)(4326008)(450100002)(6512007)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3643; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K9pYoW2XPQEWoL9FTLmwL5DwYYlw5sDcJ8gLI2XctTz8GME3vkWy3zDe4lMUom8cKrqJykK9fnetAJMNA3pdlcGTCRjzIgarclarqhSczBKezraK4uud+0S1vtiLBO3OOebszTHxwrgJWvSdglE2NH7D8aQtC0sfkia9VL9qk7XoqOe0cE6/8aF/oHeu7ggAvc/J8bQCr3Tgq4NtrTZxjfhhetSIZXdEYJvNbs/VkVZQ6BkaY8VStQoNWzOEPUkRxKC2Xbfy+qM8VtijrbBsqGrz1miUKQkuBaxWZpYVU50RqZF4rOtwdB0rw8nBkIcbYd9HkxQ00li8WoIMVb1f1I3doTKPyO8BEt3MIxIjJumvPf9HMN7kO1dGvEO5acjOe2XlyyPLJJvBpYv/RvJLVcDEdh5xxy4Fn0tf4OtLVckiiyIkOPgc2QGluloT0FmUj22QBRKQjFc7AhpJ6hTg4iYnldR7702j9RGPDNegxTuAOSnRyo5rVW3JICTKpwc/ x-ms-exchange-antispam-messagedata: JVm6GNF/egXjgDtsvk/uKU9HxrOQIrq6LftgO/X67eaSpv8YByqO7MT5ikKz/8lZ9hAaW5QAu98yXt77YxWhS/i2zwK2iXZ8Iux3dVAbm0iwlmbST/ujIaAe1UQ/1q3qjsCDzrbNfhjsGgKBOvzHeg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <11272A53443D9C4FB6284E8FE72DEFF0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec7fdd70-0599-4202-8809-08d7cab26c69 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 20:33:16.7319 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 49SrNSGJ/gUoA7+LiR6RonuppwkiDNm1ChbsjZjqH0BJcgi5e+qNJp7w6te+nq8IOurwt6c9lTkVl2MFVwr0QOPmPRSGvxUEvTqQPXf4LdblMPCjuFxTeQ/Y24ReEdrG X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3643 Archived-At: Subject: [Secdispatch] IETF 107 agenda + looking for minute takers X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 20:33:25 -0000 IFNlY2Rpc3BhdGNoLA0KDQpBcyB5b3UgbWlnaHQgaGF2ZSBzZWVuLCB3ZSBoYXZlIGJlZW4gc2No ZWR1bGVkIHRvIGhhdmUgYW4gYWxsIHZpcnR1YWwgbWVldGluZyBvbiBGcmlkYXksIE1hcmNoIDI3 IDIwMjAsIDIwOjAwLTIyOjAwIFVUQy4NClRoZSBzZXNzaW9uIHdpbGwgaGFwcGVuIG92ZXIgV2Vi ZXgsIHlvdXIgY2hhaXJzIGFyZSB3b3JraW5nIG9uIGl0LCBhbmQgd2lsbCBzb29uIGJlIHByb3Zp ZGluZyBhIGxpbmsuIFRoZSBsaW5rIHdpbGwgYWxzbyBiZSBhZGRlZCB0byB0aGUgYWdlbmRhIHdo ZW4gd2UgaGF2ZSBpdCwgc28gbG9vayB1cCBmb3IgdXBkYXRlcy4gRm9yIG1vcmUgaW5mb3JtYXRp b24gb24gaG93IHRvIHBhcnRpY2lwYXRlOiBodHRwczovL3d3dy5pZXRmLm9yZy9ob3cvbWVldGlu Z3MvMTA3L3Nlc3Npb24tcGFydGljaXBhbnQtZ3VpZGUvIA0KDQpUaGUgYWdlbmRhIGhhcyBiZWVu IHVwbG9hZGVkOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9hZ2VuZGEtMTA3LXNl Y2Rpc3BhdGNoLyAocGFzdGVkIGJlbG93KQ0KUGxlYXNlIG1ha2Ugc3VyZSB0byByZXZpZXcgYW5k IGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGZlZWRiYWNrL2NvbW1lbnRzLg0KDQpCZWNhdXNlIG9m IHRoZSBtZWV0aW5nIGJlaW5nIGZ1bGx5IHZpcnR1YWwsIHdlIGtpbmRseSBhc2sgeW91IHRvIGhl bHAgdXMgb3V0IGluIGFkdmFuY2U6IHdlIHdpbGwgbmVlZCAxIGphYmJlciBzY3JpYmUgYW5kIDIg bWludXRlIHRha2Vycy4gUGxlYXNlIGRvIHZvbHVudGVlciwgYW5kIGxldCB1cyBjaGFpcnMga25v dyBpZiB5b3UgYXJlIHVwIGZvciBpdCwgd2Ugd2lsbCBiZSBldGVybmFsbHkgZ3JhdGVmdWwuDQoN ClRoYW5rIHlvdSBhbGwgYW5kIHRhbGsgdG8geW91IHNvb24sDQpGcmFuY2VzY2EsIEthdGhsZWVu LCBSaWNoYXJkDQoNCi0tDQoNClNlY2Rpc3BhdGNoIEAgSUVURjEwNw0KRnJpZGF5LCBNYXJjaCAy NyAyMDIwLCAyMDowMC0yMjowMCBVVEMNCkNoYWlyczogRnJhbmNlc2NhIFBhbG9tYmluaSwgS2F0 aGxlZW4gTW9yaWFydHksIFJpY2hhcmQgQmFybmVzDQoNCjEuIExvZ2lzdGljcyBhbmQgaW50cm9k dWN0aW9uIChjaGFpcnMsIDEwIG1pbikNCg0KMi4gRGlzcGF0Y2ggaXRlbXMNCg0KPT0gMS4gU2ln bmF0dXJlIFZhbGlkYXRpb24gVG9rZW4gKFNWVCkgPT0NCltodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3NlY2Rpc3BhdGNoL1ZodHNyekl5akRjWFpZRFQzZTNwX2FRbFY5WSBs aW5rIHRvIG1haWwgcG9zdF0NCg0KKiBwcmVzZW50ZXI6IFtTdGVmYW4gU2FudGVzc29uXQ0KKiB0 aW1lIGFsbG9jYXRlZDogMjUnDQoqIG9iamVjdGl2ZTogZ2V0IGZlZWRiYWNrOyBzdGFuZGFyZGl6 ZSBTVlQgaW4gSUVURi4NCiogc3BlY2lmaWNhdGlvbjogIGh0dHBzOi8vZG9jcy5zd2VkZW5jb25u ZWN0LnNlL3RlY2huaWNhbC1mcmFtZXdvcmsvaW5kZXguaHRtbCNzaWd2YWwNCg0KPT0gMi4gQ2xp ZW50LUNlcnQgSFRUUCBIZWFkZXIgPT0NCltodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3NlY2Rpc3BhdGNoLzdKUUxCOFoydnhkXzNMVURBS3ZfbXZPU3hxSS8gbGluayB0byBt YWlsIHBvc3RdDQoNCiogcHJlc2VudGVyOiBbQnJpYW4gQ2FtcGJlbGxdDQoqIHRpbWUgYWxsb2Nh dGVkOiAyNScNCiogb2JqZWN0aXZlOiBnZXQgZmVlZGJhY2s7IGdhdWdlIGludGVyZXN0IGFuZCBw b3RlbnRpYWxseSBmaW5kIGFuIGFwcHJvcHJpYXRlIHZlbnVlLg0KKiBzcGVjaWZpY2F0aW9uOiAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJkYy1zb21ldGhpbmctc29tZXRoaW5n LWNlcnRpZmljYXRlLTAyDQoNCj09IDMuIEluZGljYXRvcnMgb2YgQ29tcHJvbWlzZSAoSW9DKSBh bmQgVGhlaXIgUm9sZSBpbiBBdHRhY2sgRGVmZW5jZSA9PQ0Kbm8gbWFpbA0KDQoqIHByZXNlbnRl cjogW0tpcnN0eSBQYWluZV0NCiogdGltZSBhbGxvY2F0ZWQ6IDI1Jw0KKiBvYmplY3RpdmU6IGtu b3dsZWRnZSBzaGFyaW5nIHdpdGggSUVURiBvbiBzb21lIG9mIHRoZSBwbGFjZXMgd2hlcmUgY3li ZXIgZGVmZW5jZSBpbnRlcmFjdHMgd2l0aCBpdHMgd29yaw0KKiBzcGVjaWZpY2F0aW9uOiAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhaW5lLXNtYXJ0LWluZGljYXRvcnMtb2Yt Y29tcHJvbWlzZS0wMA0KDQo9PSA0LiBBZGRpbmcgU0FTTCB0byBIVFRQID09DQpbaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zZWNkaXNwYXRjaC8xSEpuc0lCVlRQemRJbzZy UV9PejgtTnRCZFUvIGxpbmsgdG8gbWFpbCBwb3N0XQ0KDQoqIHByZXNlbnRlcjogW1JpY2sgdmFu IFJlaW5dDQoqIHRpbWUgYWxsb2NhdGVkOiAyNScNCiogb2JqZWN0aXZlOiBmaW5kIGFuIGFwcHJv cHJpYXRlIHZlbnVlIHRvIHByb2dyZXNzIHRoZSB3b3JrDQoqIHNwZWNpZmljYXRpb246IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12YW5yZWluLWh0dHBhdXRoLXNhc2wtMDQNCg0K NC4gQ2hhaXIgc3VtbWFyeS9zZXNzaW9uIHJlc3VsdHMgcmVhZG91dCAoMTAgbWludXRlcykNCg0K DQo= From nobody Fri Mar 20 10:31:01 2020 Return-Path: X-Original-To: secdispatch@ietf.org Delivered-To: secdispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C283D3A0C99; Fri, 20 Mar 2020 10:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Agenda To: X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158472545878.13440.18168871559674839777@ietfa.amsl.com> Date: Fri, 20 Mar 2020 10:30:58 -0700 Archived-At: Subject: [Secdispatch] Virtual IETF 107 Meeting WebEx Invitation: SECDISPATCH X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:30:59 -0000 SECDISPATCH Session at IETF 107 Friday, March 27 20:00-22:00 UTC Join meeting: Meeting number (access code): 317 095 560 Meeting password: 6mgE8Qy8deb IETF 107 Agenda: From szimmeck@wesleyan.edu Sat Mar 21 17:08:54 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652323A080A for ; Sat, 21 Mar 2020 17:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wesleyan.edu 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 Yv22GjqXmTdi for ; Sat, 21 Mar 2020 17:08:52 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB603A0805 for ; Sat, 21 Mar 2020 17:08:52 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id l14so9594437ilj.8 for ; Sat, 21 Mar 2020 17:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wesleyan.edu; s=wesgmail; h=mime-version:from:date:message-id:subject:to; bh=unw0pjq9vJp98bPU9TMXc8AfwLTBTe8VBRhSn2bw7aI=; b=g0go/C9/xOyMQmeL589IOk2MD+p7Sd4SNcXvCKdmhynAQilvN0Q94F2U1ng2BmftrV 0CWNTCIV5r7/aD53YlqY3YODVwzdXt3G56Mc7LxfAulRC+aPc2Q7Jz7J4Vf6IjaAAx2q Ve1k2VmfBiwXss+t56Q09oDCaiAPCiAI61ijw= 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=unw0pjq9vJp98bPU9TMXc8AfwLTBTe8VBRhSn2bw7aI=; b=NmOltcOrW0464g8kVroqYHntEKnE6cpIbPSv+4sMhb1IgShHBTQ/NSjWjUYGE27VLH XXw86R3vwtZ7ml4fWY0aDfUueyu1oDM0x3alhnOKUE3iSY7jjOYcEwxtyVJCZgX06rzC iFjSkY5QK30LkmtOEyrltny2PU8JqFPKNHxoJbRiBgCwR6omOJJeRdX12w6hk5LmzymJ 2FAFTdZLl4zZKR+kZI4XaXeZxrk/3ZEgikNts78qw6bBaN4EGXoS/IVkC4jVCokfqf1z 1q/pAJHEFXbwvbyHpzBrOFrz5Kwn/uoLdcAjVWrbt85xkHWTOiYnZmbB5RmJwjjsQ4C0 TSBg== X-Gm-Message-State: ANhLgQ12Kml6QPuIzxtJPIlB+E+QIDoR0iLjimTm+qCAI/NJjR7TlsQZ Ri5AlzhqzcXOyHZHxw5/geCeHhlsZqryXuaMLSpn/No8t7E= X-Google-Smtp-Source: ADFU+vv760HOjnkzK2NyWIhe/T4n/OlW2FVJul5m+XBU0ZELo3DSP20SPGmOfDVmUCODo2ITB022zGRDEfFX0E4dEJU= X-Received: by 2002:a92:6501:: with SMTP id z1mr15294249ilb.235.1584835730934; Sat, 21 Mar 2020 17:08:50 -0700 (PDT) MIME-Version: 1.0 From: Sebastian Zimmeck Date: Sat, 21 Mar 2020 20:08:40 -0400 Message-ID: To: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5485505a16652bf" Archived-At: Subject: [Secdispatch] CCPA Do-Not-Sell X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 01:15:22 -0000 --000000000000c5485505a16652bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable At the beginning of this year the California Consumer Privacy Act (CCPA) became effective. In addition to the rights of data access and deletion, this new privacy law gives consumers the right to opt out from the sale of personal information. A "sale" is understood broadly and likely covers, for example, a website or app disclosing location data or device identifiers to an ad network for purposes of monetization. Now, the most recent regulation= s to the CCPA published by the California Attorney General specify that automatic signals communicating a user's decision to opt out must be respected. Here is the relevant language: "If a business collects personal information from consumers online, the business shall treat user-enabled global privacy controls, such as a browser plugin or privacy setting, device setting, or other mechanism, that communicate or signal the consumer=E2=80=99s choice to opt-out of the sale = of their personal information as a valid request ... ." I am interested in setting up a working group on such device controls. The Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. However, the difference is that recipients of the DNT signal were not required to comply with the signal. Rather, they only needed to *say* whether they would comply; per the California Online Privacy Protection Act (CalOPPA). Also, the CCPA may have substantial impact beyond California as some companies, e.g., Microsoft, already made clear that they would apply the CCPA to all consumers in the US. It would be great to get a discussion started ... Best regards, Sebastian _______________________________________________ Check out PrivacyFlash Pro Developed at the privacy-tech-lab , Wesleyan University --000000000000c5485505a16652bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the beginning of this year the California Consumer= Privacy Act (CCPA) became effective. In addition to the rights of data acc= ess and deletion, this new privacy law gives consumers the right to opt=C2= =A0out from the sale of personal information. A "sale" is underst= ood broadly and likely covers, for example, a website or app disclosing loc= ation data or device identifiers to an ad network for purposes of monetizat= ion. Now, the most recent=C2=A0regulatio= ns to the CCPA=C2=A0published by the California Attorney General specif= y that automatic signals communicating a user's decision to opt out mus= t be respected. Here is the relevant language:

&qu= ot;If a business collects personal information from consumers online, the b= usiness shall treat user-enabled global privacy controls, such as a browser= plugin or privacy setting, device setting, or other mechanism, that commun= icate or signal the consumer=E2=80=99s choice to opt-out of the sale of the= ir personal information as a valid request ... ."=C2=A0

=
I am interested in setting up a working group on such device con= trols. The Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) sign= al. However, the difference is that recipients of the DNT signal were not r= equired to comply with the signal. Rather, they only needed to say w= hether they would comply; per the California Online Privacy Protection Act = (CalOPPA).

Also, the CCPA may have substantial imp= act beyond California as some companies, e.g., Microsoft, already made clea= r that they would apply the CCPA to all consumers in the US.

=
It would be great to get a discussion started ...
<= div dir=3D"ltr">

Best regards,

Sebast= ian

______________________________________________= _
Check out=C2=A0PrivacyFlash Pro
Devel= oped at the=C2=A0privacy-tech-lab, Wesleyan University
--000000000000c5485505a16652bf-- From nobody Mon Mar 23 02:38:30 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528163A0983; Mon, 23 Mar 2020 02:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSkQBGmgLOsN; Mon, 23 Mar 2020 02:38:23 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0604.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::604]) (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 C47C03A0986; Mon, 23 Mar 2020 02:38:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OWazN33Art5LrSOgbJhGvs3AJ9ZzyY5lJ7U1lZrcfi/HaHThtbynBI9cOQj28/lWWqIeFKy8YegKDFoykqvp3jPfyJ9B64ImjuNv986SYm4owMO5WdMJwV5A2itSKOTvdmkjMi0hB+Kl3NQUebPhxQjTDwk6qVdAXoDKuy4UflhctW2hWqHOswaSIb45pHzhrQeQkUsvSnaRR+IrB5i/f+NWwD/u2vOhJQk/vpsqj9cGkcSDUM7MdLKwNkdYGzA2TfFNp0/JfgjgG2YgUgzlHh12GOL9z73yPmkAVEnfxuup/fadi3uj290ILqPM4Clv2BVSSFo/VouCQKpPGEMEYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VFNmgQ+fitQVPClP/Jq7JlEBQwo0gkLRydACNfc3njE=; b=hAtHfpT8I+UxYHaBaTDuXlNJMX/jnPpXm0rpR1X0ARrNos2YXdvjsrsuCGtizThP2D5u8zrAbZPU+HhGY4C/XXF4gJ1Zfh7Q/sTLi8DNSIpScCbGeLl6JsRbs6qTwZm3iaxW8PYi1dJQWpvba7HNL+r5NW9afZne4rxnOd1BQ8JaJjiD3K3LKmEe4077vYhcaypwf/Uoiw143oIZDxybKGS9BtWTRY1eNupij+FsOjRmDifiZYkrE2da+p9T+SaQ8UhSBvMs2QHJm4oQ6V6eo+ZlT5kzWH0kfWiK+uWnQNSrnLJ4qMIr7KbEjNLGZSOR2r/rBvYqnzGUmWRZzE+y7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VFNmgQ+fitQVPClP/Jq7JlEBQwo0gkLRydACNfc3njE=; b=dk6kb+igp70Gb7MH0VjORoFgI1kHaLj0vbr1cVncxqtGgQAcb8wMc1VL/Sh8Ib4Yd+WEKbw9YVW8UbyHUuWtEuT2xEEOfTWXW3OF+4CDzGGEvNt5T322DWwiMkrtadpa6D+UUSUqEtw5Hu96uP5/c479iLj5dA6sN7qVmWhg81M= Received: from VI1PR0702MB3824.eurprd07.prod.outlook.com (52.134.6.15) by VI1PR0702MB3679.eurprd07.prod.outlook.com (52.134.7.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.9; Mon, 23 Mar 2020 09:38:15 +0000 Received: from VI1PR0702MB3824.eurprd07.prod.outlook.com ([fe80::dd8:6664:7029:97a3]) by VI1PR0702MB3824.eurprd07.prod.outlook.com ([fe80::dd8:6664:7029:97a3%3]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 09:38:15 +0000 From: Francesca Palombini To: "ietf@ietf.org" CC: "secdispatch@ietf.org" , "secdispatch-chairs@ietf.org" Thread-Topic: Looking for minute takers and jabber scribe secdispatch Thread-Index: AQHWAPbHQpkRQx2b306mdBXmUmFBHA== Date: Mon, 23 Mar 2020 09:38:15 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0e06123-f0c7-46c3-93f6-08d7cf0de991 x-ms-traffictypediagnostic: VI1PR0702MB3679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(136003)(366004)(376002)(199004)(66446008)(91956017)(6486002)(186003)(86362001)(33656002)(54906003)(44832011)(6512007)(8936002)(71200400001)(66556008)(316002)(450100002)(2906002)(558084003)(81166006)(66476007)(8676002)(64756008)(76116006)(66946007)(4326008)(81156014)(2616005)(6916009)(5660300002)(36756003)(26005)(6506007)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0702MB3679; H:VI1PR0702MB3824.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZiK+/+MBdGC93RWx6YC4HoPq4BwUtbHysyNm3rSLbvF4G8Mq/7KYKDuREJgW9a5KivXdaNrH3qwFeICqL/wsR+Rsgo16V5uoIFv38TfHW104/A4eqCi/6Fmu2CMhX7eoJkMOic/ZDg9KAwxmg9fm+LqhF0MAvxRoygcZx8E9uiorze9ZkE5aBdn2GuFtNKzIE79PSQUZpr1zy3yraR0x4qYqdHxLN5uMWTjh7H8XBzkMH+csZDXEjPz10NX+J2ud5vldZg90iSvcy4WKJ64oE0ZeNp/RwQiH11yTY31mZ9XlBtJGGmE4KyhQsyDB+hvswgK/7Mr4XFdViwZS5TpvVliAMmO9zAyNI1SRGGmaOmojt2dbKrXXeR0bQLdoz9LbcfcHQQY5PpmVxEw7vxQLOk0LDyIb3GKAj/PKNMyM6m7EMTt7GimRPonHhnybBJQ0 x-ms-exchange-antispam-messagedata: Zi9psnxVTE3SRpk3DVctKLXF1+hbvL3Qfl3K/Yoa7nY+xrQPH3VzE+bdAjW7krZNgxjkBZZgTle3wlxl8xU6kBM0neuHR/XNpR6eKdDrLq/qYAfBTMxMp7U/6Y7efIRxLZWWllXuli9PBAizTKufrQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0e06123-f0c7-46c3-93f6-08d7cf0de991 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 09:38:15.5641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R1FBXA5OHpOftXdxBSFbxOzc0bouUuqDLdYpsLuoPBkv6mjfbrHHhH12WPqbuhH9MkSlU21GCY81Hxb9EaujN8IPYGC9BvcbBLuutSwGNiOJD50d9hjkk9RY+zobZIPZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3679 Archived-At: Subject: [Secdispatch] Looking for minute takers and jabber scribe secdispatch X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 09:38:25 -0000 SGkgYWxsLA0KDQpTZWNkaXNwYXRjaCBpcyBtZWV0aW5nIHRoaXMgRnJpZGF5IE1hcmNoIDI3LCAy MDowMC0yMjowMCBVVEMuIElmIHlvdSBhcmUgam9pbmluZyB1cywgd2UgYXJlIGxvb2tpbmcgZm9y IDIgbWludXRlIHRha2VycyBhbmQgMSBqYWJiZXIgc2NyaWJlLiANCg0KVGhhbmtzIQ0KRnJhbmNl c2NhDQoNCg0KDQo= From nobody Fri Mar 27 10:22:00 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E923A0A07 for ; Fri, 27 Mar 2020 10:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p03VlqShiJsa for ; Fri, 27 Mar 2020 10:21:55 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 73CA03A093B for ; Fri, 27 Mar 2020 10:21:55 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id e7so8529600lfq.1 for ; Fri, 27 Mar 2020 10:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KXV1qt11JyrAb4K2pVS0RUaF5izCAgHyi7wKh3htWOQ=; b=yDiTTU/VTN0tTtFaEtcrPjaCKyHsPxebcAW5fLOaupIyA5m3Xx+tLtu+2PSngd8z6f nV3aGxGWjP1AsfSZRJ71T3zjCQQRH9s5o00uUKDCInoFO6U8JFWMLCorL4e/L0Av384l oxUKc3/6s6Ia6I6SUp+7NCNZsJysp2QQBunOkmODhWYVGYgQJns/fPU+bzvecdiei2L5 ZoPMHxRMEE/e+9BwxHCU7KeeWpEFTdWHUXib5jGJwZpdT6EzuY+aoricZuAOA5kEVkrM KHQmppaJgVMh3xDSx22KDIP0Ogr+5XNqs6vQRmKfrNps0qbE1J+QEi+B996ViusWn6FZ 68Ow== 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=KXV1qt11JyrAb4K2pVS0RUaF5izCAgHyi7wKh3htWOQ=; b=EZiEfxc/KV3W3iiu7kzJM277GRUKdwTgadWZ7oCZYuhy4ob2QjbUBN2/W32cSn1PD9 nZZAXYymKTbzkTxg7wxCdLeEjVMx/yOz8MoTi1hvC2O/f969tPOSNdMRYQoaPhDU8ITk Gf+8Wdnm5fR/KTXE+NJQXCZHbTvFBysp3MT41R1ZDL5pPvpSt63tiDNRMLDCEuz6AwAD flseXbpkeN7MXxb4VyRrt1E/IVvlUYPtEUxpjHig/WIoZmOBGzIpvRUlTTIF8Nd8LY+L K4MGX2nRyH5xnOECF4sG6KbsWvSPV6xN0kDGjurVtbSGAU74OwGnV44Ze6HiyKFrzPi0 6isQ== X-Gm-Message-State: AGi0PuZhy2ztaCua4sB9C7AJG96yYT8R7r5YCwucFB1KcYCEFd0Nm0d1 T63RQygpL2PL6p9vKGZ8C2XbLBnxjxPFZd9+OaMY8Q== X-Google-Smtp-Source: APiQypLJTekgE5+ZOyGqBs39KKcGhwSHOXroVAIbfFlJEBoZ4Z8pmemyHiCnMkKFXfUHyWjXAKvpD5q0EIk8V0tw1Y0= X-Received: by 2002:a19:c781:: with SMTP id x123mr226294lff.140.1585329713573; Fri, 27 Mar 2020 10:21:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 27 Mar 2020 10:21:17 -0700 Message-ID: To: Brian Campbell Cc: secdispatch-chairs@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000006e064605a1d956f2" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 17:21:59 -0000 --0000000000006e064605a1d956f2 Content-Type: text/plain; charset="UTF-8" Overall, I agree that something like this is needed. However, I have two concerns about the mechanism described here. First, as you note in S B.1., if the header is not properly sanitized, there is a trivial attack and there are stronger mechanism that do not require sanitization: "Client-Cert" header that would appear to the backend to have come from the reverse proxy. Although numerous other methods of detecting/preventing header injection are possible; such as the use of a unique secret value as part of the header name or value or the application of a signature, HMAC, or AEAD, there is no common general standardized mechanism. The potential problem of client header injection is not at all unique to the functionality of this draft and it would therefor be inappropriate for this draft to define a one-off solution. In the absence of a generic standardized solution existing currently, stripping/sanitizing the headers is the de facto means of protecting against header injection in practice today. Sanitizing This seems like an odd argument to make: if a strong mechanism is in order, we should design one and make it generic, not just throw and continue to use weaker mechanisms. Second, I think it's quite unwise to only pass the EE cert. This means that the server will be unable to independently evaluate the cert chain, which (1) is unduly restrictive on the architecture because it forces the proxy to do it and (2) means that there is no backstop in the case where the proxy makes errors or has a not-very-good validator. You should pass the whole chain. This also implies that you should have a way to pass extensions such as SCTs and stapled OCSP responses. Finally, two points about TLS integration. 1. You should define how this works in the case of resumption of a connection that had client auth. Should the proxy attach the chain from the original connection? 2. How do you handle post-handshake client authentication? Specifically: (a) How do you handle the situation in which part of the HTTP request is covered by the client cert? (b) Post-handshake client authentication allows for the client to authenticate with multiple certificates one after the other. How is this propagated to the server? On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell wrote: > Hello SecDispatchers and Chairs thereof, > > I'd like to request some time on the agenda in Vancouver to present on > https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ > in an effort to gauge interest and potentially find an appropriate venue > for the work to proceed (or just put it and its ridiculously long title out > of its misery). > > Client-Cert HTTP Header: Conveying Client Certificate Information from > TLS Terminating Reverse Proxies to Origin Server Applications > > Abstract > > This document defines the HTTP header field "Client-Cert" that allows > a TLS terminating reverse proxy to convey information about the > client certificate of a mutually-authenticated TLS connection to an > origin server in a common and predictable manner. > > Discussion around the value of having something like this defined happened > in the OAuth WG a bit before the Singapore meeting (no doubt that's not the > only time but it's the one in which I was involved recently) and an AD > nudged me to secdispatch - > https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ > falls somewhere in the middle of that long and sometimes contentious > thread. I was unable to get a draft published prior to the I-D submission > cut-off for Singapore and got a short "if time allows" presentation slot at > the meeting. The judgment coming out of that meeting was "needs draft". > > I did get an actual draft published a bit after Singapore (the one with > the ridiculously long title previously mentioned) and there's been some, if > not exactly an overwhelming amount of, discussion and support of it on this > very list: > https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22 > > Thanks. > Brian Campbell > > > > > > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --0000000000006e064605a1d956f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Overall, I agree that something like this is needed. H= owever,
I have two concerns about the mechanism described here.

F= irst, as you note in S B.1., if the header is not properly
sanitized, th= ere is a trivial attack and there are stronger
mechanism that do not req= uire sanitization:

=C2=A0 =C2=A0"Client-Cert" header that = would appear to the backend to have come
=C2=A0 =C2=A0from the reverse p= roxy.=C2=A0 Although numerous other methods of
=C2=A0 =C2=A0detecting/pr= eventing header injection are possible; such as the use
=C2=A0 =C2=A0of = a unique secret value as part of the header name or value or the
=C2=A0 = =C2=A0application of a signature, HMAC, or AEAD, there is no common general=
=C2=A0 =C2=A0standardized mechanism.=C2=A0 The potential problem of cli= ent header
=C2=A0 =C2=A0injection is not at all unique to the functional= ity of this draft and
=C2=A0 =C2=A0it would therefor be inappropriate fo= r this draft to define a one-off
=C2=A0 =C2=A0solution.=C2=A0 In the abs= ence of a generic standardized solution existing
=C2=A0 =C2=A0currently,= stripping/sanitizing the headers is the de facto means of
=C2=A0 =C2=A0= protecting against header injection in practice today.=C2=A0 Sanitizing
=
This seems like an odd argument to make: if a strong mechanism is
in= order, we should design one and make it generic, not just throw
and con= tinue to use weaker mechanisms.


Second, I think it's quite u= nwise to only pass the EE cert. This
means that the server will be unabl= e to independently evaluate
the cert chain, which (1) is unduly restrict= ive on the architecture
because it forces the proxy to do it and (2) mea= ns that there
is no backstop in the case where the proxy makes errors or=
has a not-very-good validator. You should pass the whole chain.
This= also implies that you should have a way to pass extensions
such as SCTs= and stapled OCSP responses.


Finally, two points about TLS integ= ration.

1. You should define how this works in the case of resumptio= n
of a connection that had client auth. Should the proxy attach the
c= hain from the original connection?


2. How do you handle post-han= dshake client authentication? Specifically:
(a) How do you handle the si= tuation in which part of the HTTP
request is covered by the client cert?=

(b) Post-handshake client authentication allows for the client
t= o authenticate with multiple certificates one after the other.
How is th= is propagated to the server?

On Mon, Mar 2, 2020 at 1:51 PM Brian Campbe= ll <bcampbell=3D40p= ingidentity.com@dmarc.ietf.org> wrote:
Hello SecDispatchers an= d Chairs thereof,

I'd like to request some tim= e on the agenda in Vancouver to present on = https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/= in an effort to gauge interest and potentially find an appropriate ven= ue for the work to proceed (or just put it and its ridiculously long title = out of its misery).

Client-Cert HTTP Header: Conveying Client Cert= ificate Information from
=C2=A0 =C2=A0 =C2=A0TLS Terminating Reverse Pro= xies to Origin Server Applications
Abstract

=C2=A0 =C2=A0This do= cument defines the HTTP header field "Client-Cert" that allows=C2=A0 =C2=A0a TLS terminating reverse proxy to convey information about t= he
=C2=A0 =C2=A0client certificate of a mutually-authenticated TLS conne= ction to an
=C2=A0 =C2=A0origin server in a common and predictable manne= r.

Discussion around the value of having something= like this defined happened in the OAuth WG a bit before the Singapore meet= ing (no doubt that's not the only time but it's the one in which I = was involved recently) and an AD nudged me to secdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT= 3ITEEQoKo/ falls somewhere in the middle of that long and sometimes con= tentious thread. I was unable to get a draft published prior to the I-D sub= mission cut-off for Singapore and got a short "if time allows" pr= esentation slot at the meeting. The judgment coming out of that meeting was= "needs draft".

I did get an actual= draft published a bit after Singapore (the one with the ridiculously long = title previously mentioned) and there's been some, if not exactly an ov= erwhelming amount of, discussion and support of it on this very list: https://mailarchive.ietf.org/ar= ch/search/?q=3D%22draft-bdc-something-something-certificate%22

Thanks.
Brian Campbell

=





=





CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--0000000000006e064605a1d956f2-- From nobody Fri Mar 27 12:16:41 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A703A09D4 for ; Fri, 27 Mar 2020 12:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-Pw0qlgv8ht for ; Fri, 27 Mar 2020 12:16:37 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8BD783A0BDB for ; Fri, 27 Mar 2020 12:16:37 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02RJGVvT005742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 15:16:34 -0400 Date: Fri, 27 Mar 2020 12:16:31 -0700 From: Benjamin Kaduk To: Rick van Rein Cc: SECDISPATCH WG Message-ID: <20200327191631.GO50174@kduck.mit.edu> References: <5E61FAA4.3030902@openfortress.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E61FAA4.3030902@openfortress.nl> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] Draft: Adding SASL to HTTP X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 19:16:40 -0000 Hi Rick, Thanks for bringing this to SECDISPATCH. Doing a quick read of the draft before the session, the prospect of caching authentication results via a "s2s" field in a Positive Response stuck out at me -- is this effectively a bearer token or is there a way envisioned to bind such cached data to some cryptographic keying material? Thanks, Ben On Fri, Mar 06, 2020 at 08:24:20AM +0100, Rick van Rein wrote: > Hello, > > This draft proposes to introduce SASL as an authentication mechanism > into HTTP. Adding such mechanisms requires IETF Review according to RFC > 7235. > > I don't know where to turn, and this has long stopped this proposal from > progressing. It currently hangs somewhere between DISPATCH And > SECDISPATCH, so it would be useful to hear thoughts about this proposal. > > I have been made aware that SASL in HTTP has been tried before; the > reasons why that didn't finish 15 years ago are resolved in this draft: > > Scalability: > > - stateless server side (server state relays through the client) > - sequential messages distributed over connections is no problem > > Security: > > - no fixation on DIGEST-MD5 (compatibility pulls down security) > - support for channel binding without fixating protocol layering > > > Benjamin Kaduk noted my search for IETF mechanisms and responded with: > > > That said, I'm happy to see work in this space and would be willing to > > AD-sponsor it upon a recommendation of either DISPATCH group, if that is > > the recommendation. > > The authors of the prior HTTP SASL proposal also welcome this work being > done. > > > What are your recommendations towards this work? > > > Thanks, > -Rick > > > Name: draft-vanrein-httpauth-sasl > Revision: 04 > Title: HTTP Authentication with SASL > Document date: 2020-03-04 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-vanrein-httpauth-sasl-04.txt > Status: > https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-httpauth-sasl-04 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl > Diff: > https://www.ietf.org/rfcdiff?url2=draft-vanrein-httpauth-sasl-04 > > Abstract: > Most application-level protocols standardise their authentication > exchanges under the SASL framework. HTTP has taken another course, > and often ends up replicating the work to allow individual > mechanisms. This specification adopts full SASL authentication into > HTTP. > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Fri Mar 27 12:28:20 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972B93A093B for ; Fri, 27 Mar 2020 12:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE_KN9hHf9YO for ; Fri, 27 Mar 2020 12:28:16 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B84C33A08B8 for ; Fri, 27 Mar 2020 12:28:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02RJSCx9010029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 15:28:14 -0400 Date: Fri, 27 Mar 2020 12:28:12 -0700 From: Benjamin Kaduk To: Sebastian Zimmeck Cc: secdispatch@ietf.org Message-ID: <20200327192812.GP50174@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] CCPA Do-Not-Sell X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 19:28:19 -0000 On Sat, Mar 21, 2020 at 08:08:40PM -0400, Sebastian Zimmeck wrote: > At the beginning of this year the California Consumer Privacy Act (CCPA) > became effective. In addition to the rights of data access and deletion, > this new privacy law gives consumers the right to opt out from the sale of > personal information. A "sale" is understood broadly and likely covers, for > example, a website or app disclosing location data or device identifiers to > an ad network for purposes of monetization. Now, the most recent regulations > to the CCPA > > published > by the California Attorney General specify that automatic signals > communicating a user's decision to opt out must be respected. Here is the > relevant language: > > "If a business collects personal information from consumers online, the > business shall treat user-enabled global privacy controls, such as a > browser plugin or privacy setting, device setting, or other mechanism, that > communicate or signal the consumer’s choice to opt-out of the sale of their > personal information as a valid request ... ." > > I am interested in setting up a working group on such device controls. The > Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. > However, the difference is that recipients of the DNT signal were not > required to comply with the signal. Rather, they only needed to *say* > whether they would comply; per the California Online Privacy Protection Act > (CalOPPA). > > Also, the CCPA may have substantial impact beyond California as some > companies, e.g., Microsoft, already made clear that they would apply the > CCPA to all consumers in the US. > > It would be great to get a discussion started ... It's not really clear to me how much discussion is needed... if one assumes that you're just considering a HTTP header field, then the only technical question I can think of is whether there's intended to be some level of richness of expressivity vs. a boolean signal "don't sell my data". At that point it is mostly a matter of writing down the expected semantics (the header field registry requires only Expert Review for allocations). -Ben From nobody Fri Mar 27 12:37:33 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88EB3A0772; Fri, 27 Mar 2020 12:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJMmsGp_KYvS; Fri, 27 Mar 2020 12:37:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2EAE93A0745; Fri, 27 Mar 2020 12:37:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02RJb5ip013380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 15:37:07 -0400 Date: Fri, 27 Mar 2020 12:37:04 -0700 From: Benjamin Kaduk To: Eric Rescorla Cc: Brian Campbell , IETF SecDispatch , secdispatch-chairs@ietf.org Message-ID: <20200327193704.GQ50174@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 19:37:31 -0000 On Fri, Mar 27, 2020 at 10:21:17AM -0700, Eric Rescorla wrote: > Overall, I agree that something like this is needed. However, > I have two concerns about the mechanism described here. > > First, as you note in S B.1., if the header is not properly > sanitized, there is a trivial attack and there are stronger > mechanism that do not require sanitization: > > "Client-Cert" header that would appear to the backend to have come > from the reverse proxy. Although numerous other methods of > detecting/preventing header injection are possible; such as the use > of a unique secret value as part of the header name or value or the > application of a signature, HMAC, or AEAD, there is no common general > standardized mechanism. The potential problem of client header > injection is not at all unique to the functionality of this draft and > it would therefor be inappropriate for this draft to define a one-off > solution. In the absence of a generic standardized solution existing > currently, stripping/sanitizing the headers is the de facto means of > protecting against header injection in practice today. Sanitizing > > This seems like an odd argument to make: if a strong mechanism is > in order, we should design one and make it generic, not just throw > and continue to use weaker mechanisms. > > > Second, I think it's quite unwise to only pass the EE cert. This > means that the server will be unable to independently evaluate > the cert chain, which (1) is unduly restrictive on the architecture > because it forces the proxy to do it and (2) means that there > is no backstop in the case where the proxy makes errors or > has a not-very-good validator. You should pass the whole chain. > This also implies that you should have a way to pass extensions > such as SCTs and stapled OCSP responses. > > > Finally, two points about TLS integration. > > 1. You should define how this works in the case of resumption > of a connection that had client auth. Should the proxy attach the > chain from the original connection? Hmm, that requires the proxy to keep that state around (either locally or in the resumption ticket). Brainstorming, in TLS 1.3 one could also have the application manage the authentication state by having the proxy not issue tickets right at the handshake completion, and instead wait for the application to return a blob to include in the ticket. This would provide a convenient excuse for adding a way to secure the proxy/backend channel, with the proxy adding a header with a key fingerprint, and the backend encrypting its response to that key, only if the key is whitelisted in the application's configuration. On the other hand, it's more moving parts, it's TLS 1.3-only (since you can't wait to issue the ticket in 1.2), and you'd have to have a way to distinguish whether the client cert (chain) or the application's blob are being passed. That might mean two or three header fields going from proxy to backend, and more consistency checking/error handling to match. > > 2. How do you handle post-handshake client authentication? Specifically: > (a) How do you handle the situation in which part of the HTTP > request is covered by the client cert? HTTP footers come to mind as the obvious channel from proxy to backend that's available in HTTP and can be used for data that arrives "later". But it induces perhaps even negative excitement to think of the prospect... > (b) Post-handshake client authentication allows for the client > to authenticate with multiple certificates one after the other. > How is this propagated to the server? Also, do we care only about the list of what certificates were presented, the order as well, and/or at what point in the bytestream each occurred? -Ben > On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > > Hello SecDispatchers and Chairs thereof, > > > > I'd like to request some time on the agenda in Vancouver to present on > > https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ > > in an effort to gauge interest and potentially find an appropriate venue > > for the work to proceed (or just put it and its ridiculously long title out > > of its misery). > > > > Client-Cert HTTP Header: Conveying Client Certificate Information from > > TLS Terminating Reverse Proxies to Origin Server Applications > > > > Abstract > > > > This document defines the HTTP header field "Client-Cert" that allows > > a TLS terminating reverse proxy to convey information about the > > client certificate of a mutually-authenticated TLS connection to an > > origin server in a common and predictable manner. > > > > Discussion around the value of having something like this defined happened > > in the OAuth WG a bit before the Singapore meeting (no doubt that's not the > > only time but it's the one in which I was involved recently) and an AD > > nudged me to secdispatch - > > https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ > > falls somewhere in the middle of that long and sometimes contentious > > thread. I was unable to get a draft published prior to the I-D submission > > cut-off for Singapore and got a short "if time allows" presentation slot at > > the meeting. The judgment coming out of that meeting was "needs draft". > > > > I did get an actual draft published a bit after Singapore (the one with > > the ridiculously long title previously mentioned) and there's been some, if > > not exactly an overwhelming amount of, discussion and support of it on this > > very list: > > https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22 > > > > Thanks. > > Brian Campbell > > > > > > > > > > > > > > > > > > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibited.. > > If you have received this communication in error, please notify the sender > > immediately by e-mail and delete the message and any file attachments from > > your computer. Thank you.*_______________________________________________ > > Secdispatch mailing list > > Secdispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/secdispatch > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Fri Mar 27 15:17:20 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC453A0964; Fri, 27 Mar 2020 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32lnjK_VpfPp; Fri, 27 Mar 2020 15:17:16 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40057.outbound.protection.outlook.com [40.107.4.57]) (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 4A7683A05A0; Fri, 27 Mar 2020 15:17:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXHgv6zO5KRw7q3HnKcccoYN7HP5Qjm4Rjg5MbO/v7Jji5rBLSKNTDKjSQ4FNHeMZ+zIdDOYHlyIcQQIKOG/L/D5tX9AcHfxB/xvYQTLa5SQHeufUBzM3YqewnaYCUw7CeNQWEqVbtl5FitsoJTjOArtHxrAF1rOUhCWbIkQfSrKbatfi9sZn/hXzja06XIY8B6ni7ILhz/mdWadLaQsGqlwn07t4vXqbpQaqutPdLmPk+Xga4EGSTHhyXaq6UXv1+YF4q42ZyQXDGGiR1BIXvuJdNf1YJWwnOLvDkOx79g9vFjZkiLAzQKyfMLcl3XI2OTeU1V0G03jPq4hruFBYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dAmYY4OS6jfM5kH2fiNHyZemOqdQdoTcWmLgfBtxKE=; b=S4V0eaSuGJv7vL8PMUQx/ORDqh6GvSyqLd9IHaVEGb4Xh/432O1S+ch11GMcnzuGSFgTVH4hJ+jyL7VBpKs41GE32aIbrNKHQewoRyBsci8q6VLa9qAF8x0XqF+jFAiQnqwB748wYb6bMKzFeVVjbYVZHOZWdaOMgzFqnfL7Y4hCjmAhrNIvOe3k3ttAnLDtRgg6423Ce7XyOWwC4a0e514F5q6C73SSLk/KDz3yij5rXT5NTI9VGMnOC4d9Ns4HHcNXXX1ySs98lXHGTZnlQGkB4FIb7S54qlWZ+omXcoHHIiRvC7kXZ7VQ7Peht7jGfgbD58Rat5JKJcj3ugTR/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dAmYY4OS6jfM5kH2fiNHyZemOqdQdoTcWmLgfBtxKE=; b=IKFSIdP4ZA6jO9x9cE/TQXVZYiI5fzGj1VoTPflysTtuW5t9yLppRDE9qD0SpIdipkSGmn7dc41UCHivQvudVZUMYNfo2Bsak4YX+7Kd3g/C3jDXwavs/hSxKiFdANhNyB3yaJTHmJDWVWpfDqwpWqBaxOjgK2uvzShvEdZQkcE= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2665.eurprd07.prod.outlook.com (10.168.187.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.15; Fri, 27 Mar 2020 22:17:12 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::46a:30:fc8d:a724]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::46a:30:fc8d:a724%7]) with mapi id 15.20.2856.018; Fri, 27 Mar 2020 22:17:12 +0000 From: Mohit Sethi M To: Eric Rescorla , Brian Campbell CC: IETF SecDispatch , "secdispatch-chairs@ietf.org" Thread-Topic: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header Thread-Index: AQHWBIV2hjLsIQ1RGEme1grzVmPFEQ== Date: Fri, 27 Mar 2020 22:17:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:190:326c:5f0c:2481:d832:5f65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c98e574-8707-440f-cd3b-08d7d29c9975 x-ms-traffictypediagnostic: HE1PR0701MB2665: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0355F3A3AE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(396003)(136003)(366004)(39860400002)(4326008)(316002)(2906002)(31686004)(76116006)(66446008)(110136005)(186003)(478600001)(66946007)(54906003)(6506007)(6486002)(86362001)(5660300002)(71200400001)(66476007)(6512007)(64756008)(53546011)(31696002)(2616005)(36756003)(66556008)(8676002)(966005)(8936002)(81156014)(81166006); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6/ThY+iRYGaxfpD/luLYPLyrpJxvaTrLLBArPUmYB8oDhEZ/9QzKwpeYcqx+boethnov9nzg9R1F7iXsWMRqghSaGTXAldGWnt8RphoN9m0EHoV1w03crO2prnL4eRQpcvGg6A8Wtb/cMSsOJi2itL6x05IucxjVewCUJjiG3YhnYDzt3jOS6zdO87CvLzVLfUI9hQy7Hsu2aRPLAeLePqQ13vFvpEhswOcFKVONCfTt2q8dF3xGwM2rYc80ms6bReZU3uUervsN1Bgq710nUFkTEreKcGsKHC7qATDqqUNnlp4yf+IjkzW4qHg2WQW2zycbTXacqx7P59JgPcbsBse18a6OJ8RTk/rFOy6TDkI9A0NTFQq7yUUOMnL1k5zasGwnU522I0QtJI/mZBX1QHdCQiQXxloX9j9ONCPmpXn0qV6vk+w/5c41Ar8Wp/Tb+U00Tsy6tykBK4c+6HuobVBBMp6JEf+KZoRolD1S6nf9VpmGf4HxtPXVBsZrfHg32QLD1/MP4xVnlEwI1uQ2Wg== x-ms-exchange-antispam-messagedata: VWHda65cR2zbar3yficCM4n5GiAW9yhU2qrNAnu/BtNRFBqCeK2b+g5DlaYHnJMVrmn1qy1mLlWhbocbzztOjqlShm2yWrLjnOZ05ujrf0bq0skMZP31Jx0lcQ0BYDIEDuP3q4Y1cP9xkVViGB9DyHbjmY7rOgcd9fX4JOamsPHz4KzEJD5mxJPsodIt1fTnjziGQ4WjP6eslvOZe4/HDA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_a93a634a22db682a77bbd6e8199c8372ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c98e574-8707-440f-cd3b-08d7d29c9975 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2020 22:17:12.5480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Iu5FAsq2eS8G4S+Js8TGhG9joPLAjDaiZekgRw+npOaQyRR6zKZylQ1HhWLCL0JcJ8m/Coh8hhcQmhBypiP1AUmzzKD/QXv+7xBFq7Njayk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2665 Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 22:17:19 -0000 --_000_a93a634a22db682a77bbd6e8199c8372ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCk9uIGZ1cnRoZXIgdGhvdWdodCwgSSBhY3R1YWxseSBhZ3JlZSB0aGF0IHBh c3NpbmcgdGhlIGVudGlyZSBjaGFpbiBtYWtlcyBtb3JlIHNlbnNlLiBUaGlzIHdvdWxkIGJlIHVz ZWZ1bCBpZiB0aGUgVExTIHByb3h5IGRvZXNuJ3QgaGF2ZSB0aGUgdHJ1c3QgYW5jaG9yIChidXQg dGhlIGJhY2tlbmQgc2VydmVyIGhhcyBpdCkuDQoNCi0tTW9oaXQNCg0KT24gMy8yNy8yMCA3OjIx IFBNLCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KDQpPdmVyYWxsLCBJIGFncmVlIHRoYXQgc29tZXRo aW5nIGxpa2UgdGhpcyBpcyBuZWVkZWQuIEhvd2V2ZXIsDQpJIGhhdmUgdHdvIGNvbmNlcm5zIGFi b3V0IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGhlcmUuDQoNCkZpcnN0LCBhcyB5b3Ugbm90ZSBp biBTIEIuMS4sIGlmIHRoZSBoZWFkZXIgaXMgbm90IHByb3Blcmx5DQpzYW5pdGl6ZWQsIHRoZXJl IGlzIGEgdHJpdmlhbCBhdHRhY2sgYW5kIHRoZXJlIGFyZSBzdHJvbmdlcg0KbWVjaGFuaXNtIHRo YXQgZG8gbm90IHJlcXVpcmUgc2FuaXRpemF0aW9uOg0KDQogICAiQ2xpZW50LUNlcnQiIGhlYWRl ciB0aGF0IHdvdWxkIGFwcGVhciB0byB0aGUgYmFja2VuZCB0byBoYXZlIGNvbWUNCiAgIGZyb20g dGhlIHJldmVyc2UgcHJveHkuICBBbHRob3VnaCBudW1lcm91cyBvdGhlciBtZXRob2RzIG9mDQog ICBkZXRlY3RpbmcvcHJldmVudGluZyBoZWFkZXIgaW5qZWN0aW9uIGFyZSBwb3NzaWJsZTsgc3Vj aCBhcyB0aGUgdXNlDQogICBvZiBhIHVuaXF1ZSBzZWNyZXQgdmFsdWUgYXMgcGFydCBvZiB0aGUg aGVhZGVyIG5hbWUgb3IgdmFsdWUgb3IgdGhlDQogICBhcHBsaWNhdGlvbiBvZiBhIHNpZ25hdHVy ZSwgSE1BQywgb3IgQUVBRCwgdGhlcmUgaXMgbm8gY29tbW9uIGdlbmVyYWwNCiAgIHN0YW5kYXJk aXplZCBtZWNoYW5pc20uICBUaGUgcG90ZW50aWFsIHByb2JsZW0gb2YgY2xpZW50IGhlYWRlcg0K ICAgaW5qZWN0aW9uIGlzIG5vdCBhdCBhbGwgdW5pcXVlIHRvIHRoZSBmdW5jdGlvbmFsaXR5IG9m IHRoaXMgZHJhZnQgYW5kDQogICBpdCB3b3VsZCB0aGVyZWZvciBiZSBpbmFwcHJvcHJpYXRlIGZv ciB0aGlzIGRyYWZ0IHRvIGRlZmluZSBhIG9uZS1vZmYNCiAgIHNvbHV0aW9uLiAgSW4gdGhlIGFi c2VuY2Ugb2YgYSBnZW5lcmljIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBleGlzdGluZw0KICAgY3Vy cmVudGx5LCBzdHJpcHBpbmcvc2FuaXRpemluZyB0aGUgaGVhZGVycyBpcyB0aGUgZGUgZmFjdG8g bWVhbnMgb2YNCiAgIHByb3RlY3RpbmcgYWdhaW5zdCBoZWFkZXIgaW5qZWN0aW9uIGluIHByYWN0 aWNlIHRvZGF5LiAgU2FuaXRpemluZw0KDQpUaGlzIHNlZW1zIGxpa2UgYW4gb2RkIGFyZ3VtZW50 IHRvIG1ha2U6IGlmIGEgc3Ryb25nIG1lY2hhbmlzbSBpcw0KaW4gb3JkZXIsIHdlIHNob3VsZCBk ZXNpZ24gb25lIGFuZCBtYWtlIGl0IGdlbmVyaWMsIG5vdCBqdXN0IHRocm93DQphbmQgY29udGlu dWUgdG8gdXNlIHdlYWtlciBtZWNoYW5pc21zLg0KDQoNClNlY29uZCwgSSB0aGluayBpdCdzIHF1 aXRlIHVud2lzZSB0byBvbmx5IHBhc3MgdGhlIEVFIGNlcnQuIFRoaXMNCm1lYW5zIHRoYXQgdGhl IHNlcnZlciB3aWxsIGJlIHVuYWJsZSB0byBpbmRlcGVuZGVudGx5IGV2YWx1YXRlDQp0aGUgY2Vy dCBjaGFpbiwgd2hpY2ggKDEpIGlzIHVuZHVseSByZXN0cmljdGl2ZSBvbiB0aGUgYXJjaGl0ZWN0 dXJlDQpiZWNhdXNlIGl0IGZvcmNlcyB0aGUgcHJveHkgdG8gZG8gaXQgYW5kICgyKSBtZWFucyB0 aGF0IHRoZXJlDQppcyBubyBiYWNrc3RvcCBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgcHJveHkgbWFr ZXMgZXJyb3JzIG9yDQpoYXMgYSBub3QtdmVyeS1nb29kIHZhbGlkYXRvci4gWW91IHNob3VsZCBw YXNzIHRoZSB3aG9sZSBjaGFpbi4NClRoaXMgYWxzbyBpbXBsaWVzIHRoYXQgeW91IHNob3VsZCBo YXZlIGEgd2F5IHRvIHBhc3MgZXh0ZW5zaW9ucw0Kc3VjaCBhcyBTQ1RzIGFuZCBzdGFwbGVkIE9D U1AgcmVzcG9uc2VzLg0KDQoNCkZpbmFsbHksIHR3byBwb2ludHMgYWJvdXQgVExTIGludGVncmF0 aW9uLg0KDQoxLiBZb3Ugc2hvdWxkIGRlZmluZSBob3cgdGhpcyB3b3JrcyBpbiB0aGUgY2FzZSBv ZiByZXN1bXB0aW9uDQpvZiBhIGNvbm5lY3Rpb24gdGhhdCBoYWQgY2xpZW50IGF1dGguIFNob3Vs ZCB0aGUgcHJveHkgYXR0YWNoIHRoZQ0KY2hhaW4gZnJvbSB0aGUgb3JpZ2luYWwgY29ubmVjdGlv bj8NCg0KDQoyLiBIb3cgZG8geW91IGhhbmRsZSBwb3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aGVu dGljYXRpb24/IFNwZWNpZmljYWxseToNCihhKSBIb3cgZG8geW91IGhhbmRsZSB0aGUgc2l0dWF0 aW9uIGluIHdoaWNoIHBhcnQgb2YgdGhlIEhUVFANCnJlcXVlc3QgaXMgY292ZXJlZCBieSB0aGUg Y2xpZW50IGNlcnQ/DQoNCihiKSBQb3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aGVudGljYXRpb24g YWxsb3dzIGZvciB0aGUgY2xpZW50DQp0byBhdXRoZW50aWNhdGUgd2l0aCBtdWx0aXBsZSBjZXJ0 aWZpY2F0ZXMgb25lIGFmdGVyIHRoZSBvdGhlci4NCkhvdyBpcyB0aGlzIHByb3BhZ2F0ZWQgdG8g dGhlIHNlcnZlcj8NCg0KT24gTW9uLCBNYXIgMiwgMjAyMCBhdCAxOjUxIFBNIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGw9NDBwaW5naWRlbnRpdHkuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MHBpbmdpZGVudGl0eS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhlbGxvIFNlY0Rpc3Bh dGNoZXJzIGFuZCBDaGFpcnMgdGhlcmVvZiwNCg0KSSdkIGxpa2UgdG8gcmVxdWVzdCBzb21lIHRp bWUgb24gdGhlIGFnZW5kYSBpbiBWYW5jb3V2ZXIgdG8gcHJlc2VudCBvbiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZGMtc29tZXRoaW5nLXNvbWV0aGluZy1jZXJ0aWZp Y2F0ZS8gaW4gYW4gZWZmb3J0IHRvIGdhdWdlIGludGVyZXN0IGFuZCBwb3RlbnRpYWxseSBmaW5k IGFuIGFwcHJvcHJpYXRlIHZlbnVlIGZvciB0aGUgd29yayB0byBwcm9jZWVkIChvciBqdXN0IHB1 dCBpdCBhbmQgaXRzIHJpZGljdWxvdXNseSBsb25nIHRpdGxlIG91dCBvZiBpdHMgbWlzZXJ5KS4N Cg0KQ2xpZW50LUNlcnQgSFRUUCBIZWFkZXI6IENvbnZleWluZyBDbGllbnQgQ2VydGlmaWNhdGUg SW5mb3JtYXRpb24gZnJvbQ0KICAgICBUTFMgVGVybWluYXRpbmcgUmV2ZXJzZSBQcm94aWVzIHRv IE9yaWdpbiBTZXJ2ZXIgQXBwbGljYXRpb25zDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgSFRUUCBoZWFkZXIgZmllbGQgIkNsaWVudC1DZXJ0IiB0aGF0IGFsbG93 cw0KICAgYSBUTFMgdGVybWluYXRpbmcgcmV2ZXJzZSBwcm94eSB0byBjb252ZXkgaW5mb3JtYXRp b24gYWJvdXQgdGhlDQogICBjbGllbnQgY2VydGlmaWNhdGUgb2YgYSBtdXR1YWxseS1hdXRoZW50 aWNhdGVkIFRMUyBjb25uZWN0aW9uIHRvIGFuDQogICBvcmlnaW4gc2VydmVyIGluIGEgY29tbW9u IGFuZCBwcmVkaWN0YWJsZSBtYW5uZXIuDQoNCkRpc2N1c3Npb24gYXJvdW5kIHRoZSB2YWx1ZSBv ZiBoYXZpbmcgc29tZXRoaW5nIGxpa2UgdGhpcyBkZWZpbmVkIGhhcHBlbmVkIGluIHRoZSBPQXV0 aCBXRyBhIGJpdCBiZWZvcmUgdGhlIFNpbmdhcG9yZSBtZWV0aW5nIChubyBkb3VidCB0aGF0J3Mg bm90IHRoZSBvbmx5IHRpbWUgYnV0IGl0J3MgdGhlIG9uZSBpbiB3aGljaCBJIHdhcyBpbnZvbHZl ZCByZWNlbnRseSkgYW5kIGFuIEFEIG51ZGdlZCBtZSB0byBzZWNkaXNwYXRjaCAtIGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvalE1TUFaMVhDdnhXYkh3cWxUM0lU RUVRb0tvLyBmYWxscyBzb21ld2hlcmUgaW4gdGhlIG1pZGRsZSBvZiB0aGF0IGxvbmcgYW5kIHNv bWV0aW1lcyBjb250ZW50aW91cyB0aHJlYWQuIEkgd2FzIHVuYWJsZSB0byBnZXQgYSBkcmFmdCBw dWJsaXNoZWQgcHJpb3IgdG8gdGhlIEktRCBzdWJtaXNzaW9uIGN1dC1vZmYgZm9yIFNpbmdhcG9y ZSBhbmQgZ290IGEgc2hvcnQgImlmIHRpbWUgYWxsb3dzIiBwcmVzZW50YXRpb24gc2xvdCBhdCB0 aGUgbWVldGluZy4gVGhlIGp1ZGdtZW50IGNvbWluZyBvdXQgb2YgdGhhdCBtZWV0aW5nIHdhcyAi bmVlZHMgZHJhZnQiLg0KDQpJIGRpZCBnZXQgYW4gYWN0dWFsIGRyYWZ0IHB1Ymxpc2hlZCBhIGJp dCBhZnRlciBTaW5nYXBvcmUgKHRoZSBvbmUgd2l0aCB0aGUgcmlkaWN1bG91c2x5IGxvbmcgdGl0 bGUgcHJldmlvdXNseSBtZW50aW9uZWQpIGFuZCB0aGVyZSdzIGJlZW4gc29tZSwgaWYgbm90IGV4 YWN0bHkgYW4gb3ZlcndoZWxtaW5nIGFtb3VudCBvZiwgZGlzY3Vzc2lvbiBhbmQgc3VwcG9ydCBv ZiBpdCBvbiB0aGlzIHZlcnkgbGlzdDogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L3NlYXJjaC8/cT0lMjJkcmFmdC1iZGMtc29tZXRoaW5nLXNvbWV0aGluZy1jZXJ0aWZpY2F0ZSUy Mg0KDQpUaGFua3MuDQpCcmlhbiBDYW1wYmVsbA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkNPTkZJ REVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBi eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0 YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1haWxpbmcgbGlzdA0K U2VjZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNlY2Rpc3BhdGNoIG1h aWxpbmcgbGlzdA0KU2VjZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOlNlY2Rpc3BhdGNoQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXNwYXRjaA0K DQo= --_000_a93a634a22db682a77bbd6e8199c8372ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <917EF2A9AFEC634EB939C07870AC6137@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgQnJpYW4s PC9wPg0KPHA+T24gZnVydGhlciB0aG91Z2h0LCBJIGFjdHVhbGx5IGFncmVlIHRoYXQgcGFzc2lu ZyB0aGUgZW50aXJlIGNoYWluIG1ha2VzIG1vcmUgc2Vuc2UuIFRoaXMgd291bGQgYmUgdXNlZnVs IGlmIHRoZSBUTFMgcHJveHkgZG9lc24ndCBoYXZlIHRoZSB0cnVzdCBhbmNob3IgKGJ1dCB0aGUg YmFja2VuZCBzZXJ2ZXIgaGFzIGl0KS48YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0K PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAzLzI3LzIwIDc6MjEgUE0sIEVyaWMgUmVz Y29ybGEgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJt aWQ6Q0FCY1plQlBKTzRqMEtaaz16am9wTjJvRVdMTi1OcllSdEtPPUd1UTJlNUN6SDc9aVBBQG1h aWwuZ21haWwuY29tIj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCk92ZXJhbGwsIEkgYWdyZWUgdGhh dCBzb21ldGhpbmcgbGlrZSB0aGlzIGlzIG5lZWRlZC4gSG93ZXZlciw8YnI+DQpJIGhhdmUgdHdv IGNvbmNlcm5zIGFib3V0IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGhlcmUuPGJyPg0KPGJyPg0K Rmlyc3QsIGFzIHlvdSBub3RlIGluIFMgQi4xLiwgaWYgdGhlIGhlYWRlciBpcyBub3QgcHJvcGVy bHk8YnI+DQpzYW5pdGl6ZWQsIHRoZXJlIGlzIGEgdHJpdmlhbCBhdHRhY2sgYW5kIHRoZXJlIGFy ZSBzdHJvbmdlcjxicj4NCm1lY2hhbmlzbSB0aGF0IGRvIG5vdCByZXF1aXJlIHNhbml0aXphdGlv bjo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7JnF1b3Q7Q2xpZW50LUNlcnQmcXVvdDsgaGVhZGVy IHRoYXQgd291bGQgYXBwZWFyIHRvIHRoZSBiYWNrZW5kIHRvIGhhdmUgY29tZTxicj4NCiZuYnNw OyAmbmJzcDtmcm9tIHRoZSByZXZlcnNlIHByb3h5LiZuYnNwOyBBbHRob3VnaCBudW1lcm91cyBv dGhlciBtZXRob2RzIG9mPGJyPg0KJm5ic3A7ICZuYnNwO2RldGVjdGluZy9wcmV2ZW50aW5nIGhl YWRlciBpbmplY3Rpb24gYXJlIHBvc3NpYmxlOyBzdWNoIGFzIHRoZSB1c2U8YnI+DQombmJzcDsg Jm5ic3A7b2YgYSB1bmlxdWUgc2VjcmV0IHZhbHVlIGFzIHBhcnQgb2YgdGhlIGhlYWRlciBuYW1l IG9yIHZhbHVlIG9yIHRoZTxicj4NCiZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBvZiBhIHNpZ25h dHVyZSwgSE1BQywgb3IgQUVBRCwgdGhlcmUgaXMgbm8gY29tbW9uIGdlbmVyYWw8YnI+DQombmJz cDsgJm5ic3A7c3RhbmRhcmRpemVkIG1lY2hhbmlzbS4mbmJzcDsgVGhlIHBvdGVudGlhbCBwcm9i bGVtIG9mIGNsaWVudCBoZWFkZXI8YnI+DQombmJzcDsgJm5ic3A7aW5qZWN0aW9uIGlzIG5vdCBh dCBhbGwgdW5pcXVlIHRvIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoaXMgZHJhZnQgYW5kPGJyPg0K Jm5ic3A7ICZuYnNwO2l0IHdvdWxkIHRoZXJlZm9yIGJlIGluYXBwcm9wcmlhdGUgZm9yIHRoaXMg ZHJhZnQgdG8gZGVmaW5lIGEgb25lLW9mZjxicj4NCiZuYnNwOyAmbmJzcDtzb2x1dGlvbi4mbmJz cDsgSW4gdGhlIGFic2VuY2Ugb2YgYSBnZW5lcmljIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBleGlz dGluZzxicj4NCiZuYnNwOyAmbmJzcDtjdXJyZW50bHksIHN0cmlwcGluZy9zYW5pdGl6aW5nIHRo ZSBoZWFkZXJzIGlzIHRoZSBkZSBmYWN0byBtZWFucyBvZjxicj4NCiZuYnNwOyAmbmJzcDtwcm90 ZWN0aW5nIGFnYWluc3QgaGVhZGVyIGluamVjdGlvbiBpbiBwcmFjdGljZSB0b2RheS4mbmJzcDsg U2FuaXRpemluZzxicj4NCjxicj4NClRoaXMgc2VlbXMgbGlrZSBhbiBvZGQgYXJndW1lbnQgdG8g bWFrZTogaWYgYSBzdHJvbmcgbWVjaGFuaXNtIGlzPGJyPg0KaW4gb3JkZXIsIHdlIHNob3VsZCBk ZXNpZ24gb25lIGFuZCBtYWtlIGl0IGdlbmVyaWMsIG5vdCBqdXN0IHRocm93PGJyPg0KYW5kIGNv bnRpbnVlIHRvIHVzZSB3ZWFrZXIgbWVjaGFuaXNtcy48YnI+DQo8YnI+DQo8YnI+DQpTZWNvbmQs IEkgdGhpbmsgaXQncyBxdWl0ZSB1bndpc2UgdG8gb25seSBwYXNzIHRoZSBFRSBjZXJ0LiBUaGlz PGJyPg0KbWVhbnMgdGhhdCB0aGUgc2VydmVyIHdpbGwgYmUgdW5hYmxlIHRvIGluZGVwZW5kZW50 bHkgZXZhbHVhdGU8YnI+DQp0aGUgY2VydCBjaGFpbiwgd2hpY2ggKDEpIGlzIHVuZHVseSByZXN0 cmljdGl2ZSBvbiB0aGUgYXJjaGl0ZWN0dXJlPGJyPg0KYmVjYXVzZSBpdCBmb3JjZXMgdGhlIHBy b3h5IHRvIGRvIGl0IGFuZCAoMikgbWVhbnMgdGhhdCB0aGVyZTxicj4NCmlzIG5vIGJhY2tzdG9w IGluIHRoZSBjYXNlIHdoZXJlIHRoZSBwcm94eSBtYWtlcyBlcnJvcnMgb3I8YnI+DQpoYXMgYSBu b3QtdmVyeS1nb29kIHZhbGlkYXRvci4gWW91IHNob3VsZCBwYXNzIHRoZSB3aG9sZSBjaGFpbi48 YnI+DQpUaGlzIGFsc28gaW1wbGllcyB0aGF0IHlvdSBzaG91bGQgaGF2ZSBhIHdheSB0byBwYXNz IGV4dGVuc2lvbnM8YnI+DQpzdWNoIGFzIFNDVHMgYW5kIHN0YXBsZWQgT0NTUCByZXNwb25zZXMu PGJyPg0KPGJyPg0KPGJyPg0KRmluYWxseSwgdHdvIHBvaW50cyBhYm91dCBUTFMgaW50ZWdyYXRp b24uPGJyPg0KPGJyPg0KMS4gWW91IHNob3VsZCBkZWZpbmUgaG93IHRoaXMgd29ya3MgaW4gdGhl IGNhc2Ugb2YgcmVzdW1wdGlvbjxicj4NCm9mIGEgY29ubmVjdGlvbiB0aGF0IGhhZCBjbGllbnQg YXV0aC4gU2hvdWxkIHRoZSBwcm94eSBhdHRhY2ggdGhlPGJyPg0KY2hhaW4gZnJvbSB0aGUgb3Jp Z2luYWwgY29ubmVjdGlvbj88YnI+DQo8YnI+DQo8YnI+DQoyLiBIb3cgZG8geW91IGhhbmRsZSBw b3N0LWhhbmRzaGFrZSBjbGllbnQgYXV0aGVudGljYXRpb24/IFNwZWNpZmljYWxseTo8YnI+DQoo YSkgSG93IGRvIHlvdSBoYW5kbGUgdGhlIHNpdHVhdGlvbiBpbiB3aGljaCBwYXJ0IG9mIHRoZSBI VFRQPGJyPg0KcmVxdWVzdCBpcyBjb3ZlcmVkIGJ5IHRoZSBjbGllbnQgY2VydD88YnI+DQo8YnI+ DQooYikgUG9zdC1oYW5kc2hha2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFsbG93cyBmb3IgdGhl IGNsaWVudDxicj4NCnRvIGF1dGhlbnRpY2F0ZSB3aXRoIG11bHRpcGxlIGNlcnRpZmljYXRlcyBv bmUgYWZ0ZXIgdGhlIG90aGVyLjxicj4NCkhvdyBpcyB0aGlzIHByb3BhZ2F0ZWQgdG8gdGhlIHNl cnZlcj88YnI+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIE1hciAyLCAyMDIwIGF0IDE6NTEg UE0gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbD08YSBocmVmPSJtYWlsdG86NDBwaW5naWRl bnRpdHkuY29tQGRtYXJjLmlldGYub3JnIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPjQwcGluZ2lk ZW50aXR5LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4DQog ICAgICAgICAgMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+SGVsbG8gU2VjRGlzcGF0Y2hl cnMgYW5kIENoYWlycyB0aGVyZW9mLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSdk IGxpa2UgdG8gcmVxdWVzdCBzb21lIHRpbWUgb24gdGhlIGFnZW5kYSBpbiBWYW5jb3V2ZXIgdG8g cHJlc2VudCBvbiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1iZGMtc29tZXRoaW5nLXNvbWV0aGluZy1jZXJ0aWZpY2F0ZS8iIHRhcmdldD0iX2JsYW5rIiBt b3otZG8tbm90LXNlbmQ9InRydWUiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYmRjLXNvbWV0aGluZy1zb21ldGhpbmctY2VydGlmaWNhdGUvPC9hPiBpbiBhbiBlZmZv cnQgdG8gZ2F1Z2UgaW50ZXJlc3QgYW5kIHBvdGVudGlhbGx5IGZpbmQgYW4gYXBwcm9wcmlhdGUg dmVudWUgZm9yIHRoZSB3b3JrIHRvIHByb2NlZWQgKG9yIGp1c3QgcHV0IGl0IGFuZCBpdHMgcmlk aWN1bG91c2x5IGxvbmcgdGl0bGUgb3V0IG9mIGl0cyBtaXNlcnkpLg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo0MHB4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjQwcHgiPkNsaWVudC1DZXJ0IEhUVFAgSGVhZGVyOiBDb252ZXlpbmcgQ2xpZW50 IENlcnRpZmljYXRlIEluZm9ybWF0aW9uIGZyb208YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO1RM UyBUZXJtaW5hdGluZyBSZXZlcnNlIFByb3hpZXMgdG8gT3JpZ2luIFNlcnZlciBBcHBsaWNhdGlv bnM8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjQwcHgiPjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6NDBweCI+QWJzdHJhY3Q8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBIVFRQIGhlYWRlciBmaWVsZCAmcXVvdDtDbGll bnQtQ2VydCZxdW90OyB0aGF0IGFsbG93czxicj4NCiZuYnNwOyAmbmJzcDthIFRMUyB0ZXJtaW5h dGluZyByZXZlcnNlIHByb3h5IHRvIGNvbnZleSBpbmZvcm1hdGlvbiBhYm91dCB0aGU8YnI+DQom bmJzcDsgJm5ic3A7Y2xpZW50IGNlcnRpZmljYXRlIG9mIGEgbXV0dWFsbHktYXV0aGVudGljYXRl ZCBUTFMgY29ubmVjdGlvbiB0byBhbjxicj4NCiZuYnNwOyAmbmJzcDtvcmlnaW4gc2VydmVyIGlu IGEgY29tbW9uIGFuZCBwcmVkaWN0YWJsZSBtYW5uZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5EaXNjdXNzaW9uIGFyb3VuZCB0aGUgdmFsdWUgb2YgaGF2aW5nIHNvbWV0aGluZyBs aWtlIHRoaXMgZGVmaW5lZCBoYXBwZW5lZCBpbiB0aGUgT0F1dGggV0cgYSBiaXQgYmVmb3JlIHRo ZSBTaW5nYXBvcmUgbWVldGluZyAobm8gZG91YnQgdGhhdCdzIG5vdCB0aGUgb25seSB0aW1lIGJ1 dCBpdCdzIHRoZSBvbmUgaW4gd2hpY2ggSSB3YXMgaW52b2x2ZWQgcmVjZW50bHkpIGFuZCBhbiBB RCBudWRnZWQgbWUgdG8gc2VjZGlzcGF0Y2ggLQ0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9qUTVNQVoxWEN2eFdiSHdxbFQzSVRFRVFvS28vIiB0 YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj4NCmh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvalE1TUFaMVhDdnhXYkh3cWxUM0lURUVRb0tvLzwv YT4gZmFsbHMgc29tZXdoZXJlIGluIHRoZSBtaWRkbGUgb2YgdGhhdCBsb25nIGFuZCBzb21ldGlt ZXMgY29udGVudGlvdXMgdGhyZWFkLiBJIHdhcyB1bmFibGUgdG8gZ2V0IGEgZHJhZnQgcHVibGlz aGVkIHByaW9yIHRvIHRoZSBJLUQgc3VibWlzc2lvbiBjdXQtb2ZmIGZvciBTaW5nYXBvcmUgYW5k IGdvdCBhIHNob3J0DQogJnF1b3Q7aWYgdGltZSBhbGxvd3MmcXVvdDsgcHJlc2VudGF0aW9uIHNs b3QgYXQgdGhlIG1lZXRpbmcuIFRoZSBqdWRnbWVudCBjb21pbmcgb3V0IG9mIHRoYXQgbWVldGlu ZyB3YXMgJnF1b3Q7bmVlZHMgZHJhZnQmcXVvdDsuDQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkkgZGlkIGdldCBhbiBhY3R1YWwgZHJhZnQgcHVibGlzaGVkIGEgYml0IGFm dGVyIFNpbmdhcG9yZSAodGhlIG9uZSB3aXRoIHRoZSByaWRpY3Vsb3VzbHkgbG9uZyB0aXRsZSBw cmV2aW91c2x5IG1lbnRpb25lZCkgYW5kIHRoZXJlJ3MgYmVlbiBzb21lLCBpZiBub3QgZXhhY3Rs eSBhbiBvdmVyd2hlbG1pbmcgYW1vdW50IG9mLCBkaXNjdXNzaW9uIGFuZCBzdXBwb3J0IG9mIGl0 IG9uIHRoaXMgdmVyeSBsaXN0Og0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL3NlYXJjaC8/cT0lMjJkcmFmdC1iZGMtc29tZXRoaW5nLXNvbWV0aGluZy1jZXJ0aWZp Y2F0ZSUyMiIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+DQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2VhcmNoLz9xPSUyMmRyYWZ0LWJkYy1zb21ldGhp bmctc29tZXRoaW5nLWNlcnRpZmljYXRlJTIyPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhbmtzLjwvZGl2Pg0KPGRpdj5CcmlhbiBDYW1wYmVsbCA8YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi cj4NCjwvZGl2Pg0KPGJyPg0KPGkgc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7Ym9yZGVy OjBweA0KICAgICAgICAgICAgbm9uZTtvdXRsaW5lOmN1cnJlbnRjb2xvciBub25lDQogICAgICAg ICAgICAwcHg7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7YmFja2dyb3VuZDpyZ2IoMjU1LDI1NSwy NTUpIG5vbmUNCiAgICAgICAgICAgIHJlcGVhdCBzY3JvbGwgMCUNCjAlO2ZvbnQtZmFtaWx5OnBy b3hpbWEtbm92YS16ZW5kZXNrLHN5c3RlbS11aSwtYXBwbGUtc3lzdGVtLHN5c3RlbS11aSwmcXVv dDtTZWdvZQ0KICAgICAgICAgICAgVUkmcXVvdDssUm9ib3RvLE94eWdlbi1TYW5zLFVidW50dSxD YW50YXJlbGwsJnF1b3Q7SGVsdmV0aWNhDQogICAgICAgICAgICBOZXVlJnF1b3Q7LEFyaWFsLHNh bnMtc2VyaWY7Y29sb3I6cmdiKDg1LDg1LDg1KSI+PHNwYW4gc3R5bGU9Im1hcmdpbjowcHg7cGFk ZGluZzowcHg7Ym9yZGVyOjBweA0KICAgICAgICAgICAgICBub25lO291dGxpbmU6Y3VycmVudGNv bG9yIG5vbmUNCiAgICAgICAgICAgICAgMHB4O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO2JhY2tn cm91bmQ6dHJhbnNwYXJlbnQgbm9uZQ0KICAgICAgICAgICAgICByZXBlYXQgc2Nyb2xsIDAlDQow JTtmb250LWZhbWlseTpwcm94aW1hLW5vdmEtemVuZGVzayxzeXN0ZW0tdWksLWFwcGxlLXN5c3Rl bSxCbGlua01hY1N5c3RlbUZvbnQsJnF1b3Q7U2Vnb2UNClVJJnF1b3Q7LFJvYm90byxPeHlnZW4t U2FucyxVYnVudHUsQ2FudGFyZWxsLCZxdW90O0hlbHZldGljYQ0KICAgICAgICAgICAgICBOZXVl JnF1b3Q7LEFyaWFsLHNhbnMtc2VyaWY7Zm9udC13ZWlnaHQ6NjAwIj48Zm9udCBzaXplPSIyIj5D T05GSURFTlRJQUxJVFkNCiBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xv c3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeQ0KIHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5k IGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LjwvZm9u dD48L3NwYW4+PC9pPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNl Y2Rpc3BhdGNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij5TZWNkaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpc3BhdGNoIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2VjZGlzcGF0Y2g8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0 Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2VjZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86U2VjZGlzcGF0 Y2hAaWV0Zi5vcmciPlNlY2Rpc3BhdGNoQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZWNkaXNwYXRjaCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNk aXNwYXRjaDwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_a93a634a22db682a77bbd6e8199c8372ericssoncom_-- From nobody Fri Mar 27 16:15:37 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB373A0BEB for ; Fri, 27 Mar 2020 16:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHV5ZDsdloiQ for ; Fri, 27 Mar 2020 16:15:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7A56A3A0A3A for ; Fri, 27 Mar 2020 16:15:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02RNFRiJ018643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 19:15:30 -0400 Date: Fri, 27 Mar 2020 16:15:26 -0700 From: Benjamin Kaduk To: Kirsty P Cc: "secdispatch@ietf.org" Message-ID: <20200327231526.GU50174@kduck.mit.edu> References: <158349344094.2274.4065518603647811950@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] Fw: New Version Notification for draft-paine-smart-indicators-of-compromise-00.txt X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 23:15:35 -0000 Hi Kirsty, While reading the draft to prepare for the session, I had something occur to me that was not really relevant for the dispatch question, so I didn't mention it live, but still seems worth mentioning: Different IoCs can, of course, have different properties, and I think it's important to have some mention of how this can apply both to the level of confidence that the presence of any given IoC indicates true compromise, and for how long a given IoC remains an IoC. To consider IP addresses as a familiar example that I know how to reason about, if I'm a security researcher taking notes on my investigations, the fact that an IP address known to be a botnet C&C appears in my notes does not indicate that my machine is compromised! Likewise, with IP(v4) addresses growing scarce, they will be getting reallocated and/or reassigned to different entities; we see this already in the form of spam reputation scores, with IP addresses remaining on blacklists even after they have been reassigned. -Ben On Tue, Mar 10, 2020 at 05:00:43PM +0000, Kirsty P wrote: > Hi, > > I'd like to request a slot at secdispatch for IETF 107 to present the draft below. > Additionally, comments/feedback on the draft from interested parties are very welcome. > > Kirsty > > > > A new version of I-D, draft-paine-smart-indicators-of-compromise-00.txt > has been successfully submitted by Kirsty Paine and posted to the > IETF repository. > > Name: draft-paine-smart-indicators-of-compromise > Revision: 00 > Title: Indicators of Compromise (IoCs) and Their Role in Attack Defence > Document date: 2020-03-06 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/id/draft-paine-smart-indicators-of-compromise-00.txt > Status: https://datatracker.ietf.org/doc/draft-paine-smart-indicators-of-compromise/ > Htmlized: https://tools.ietf.org/html/draft-paine-smart-indicators-of-compromise-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-paine-smart-indicators-of-compromise > > > Abstract: > Indicators of Compromise (IoCs) are an important technique in attack > defence (often called cyber defence). This document outlines the > different types of IoC, their associated benefits and limitations, > and discusses their effective use. It also contextualises the role > of IoCs in defending against attacks through describing a recent case > study. This draft does not pre-suppose where IoCs can be found or > should be detected - as they can be discovered and deployed in > networks, endpoints or elsewhere - rather, engineers should be aware > that they need to be detectable (either by endpoint security > appliances or network-based defences, or ideally both) to be > effective. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright © > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Sat Mar 28 10:37:45 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD06F3A08E3 for ; Sat, 28 Mar 2020 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wesleyan.edu 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 r2caMbXdnxcA for ; Sat, 28 Mar 2020 10:37:41 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 B22C43A08FB for ; Sat, 28 Mar 2020 10:37:41 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id x16so11813465ilp.12 for ; Sat, 28 Mar 2020 10:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wesleyan.edu; s=wesgmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YR76ErmUyMlqL5Dw13HqFL/+KgtZZqn2ypx55mR0/ds=; b=UV/OY1TS3QEgPXvadbTp+ml9hcVvLXP/KOjFP4ZvZPDEdlDFGRJtFXdQppab4JYXI2 Q/ySTN/4spo8kZSnt0Qo3Sz4BIuJUYz/ZqKdlFVFWO6QhaQtWLX+UlLGWSkGtyFmT1bK aZ3U++mRwxAIdw7dA8d+mq/eg7KJSywHM1A8c= 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=YR76ErmUyMlqL5Dw13HqFL/+KgtZZqn2ypx55mR0/ds=; b=ADhLdrLQ3ZPwDEebzuucZP3SJUSw4GbWYo19nUkwu7NRKxbkpF0zB+qGSSHJN5HACD 734XdyoaNo6ZaPC3UIj/HHHV25iXmUztUGFhTJmu0o/s9Iv1MA6MJDRd5n3+Par8h1+S UQrV72epdmGP5BAuzT6Mzg4ipupH84pMsFAEi3xhcA0nR5JmsXbn2GBBIpmTgEf2xAM5 IhD3GrkZ4y/aOT16mlPGwxzDp4DKnvkygRY35Jd4YWMGlpplcHIKM8eYivvqkMUOEAAI IxoDI+xG4OyAlEPEmqXp45pSzWzZV8SP7XFiZvCGbnSmQJKGoQbBqZDErndDtui6KQbm ZBzQ== X-Gm-Message-State: ANhLgQ1jdQshZZb6sSFDhqhFlpTd6BdPu+3kvcJvjAQ+I45NKY50CNLH 9/nbm5JZ0TZltc5RatFxmgu9xUHTksaDO5omz5/ggw== X-Google-Smtp-Source: ADFU+vuF6ct6uAGuirOEH2lf9L+YSN1akOrwyM9+7xwsVBHwf0MngZRWBteKEOgNOGSnO/eCfOICH28pFG4IzmBOcug= X-Received: by 2002:a92:6501:: with SMTP id z1mr4535288ilb.235.1585417060931; Sat, 28 Mar 2020 10:37:40 -0700 (PDT) MIME-Version: 1.0 References: <20200327192812.GP50174@kduck.mit.edu> In-Reply-To: <20200327192812.GP50174@kduck.mit.edu> From: Sebastian Zimmeck Date: Sat, 28 Mar 2020 13:37:29 -0400 Message-ID: To: Benjamin Kaduk Cc: secdispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000bcf1b705a1edace5" Archived-At: Subject: Re: [Secdispatch] CCPA Do-Not-Sell X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 17:37:44 -0000 --000000000000bcf1b705a1edace5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed, from a technical standpoint the implementation of a header field is straightforward. Though, there are related policy implications. Given the broad scope of what is considered a sale per the CCPA, especially, a lot of data collected by ad networks would be subject to Do-Not-Sell. Also, it would be nice to create a solution going beyond the browser, particularly, covering mobile apps. Best regards, Sebastian _______________________________________________ Check out PrivacyFlash Pro Developed at the privacy-tech-lab , Wesleyan University On Fri, Mar 27, 2020 at 3:28 PM Benjamin Kaduk wrote: > On Sat, Mar 21, 2020 at 08:08:40PM -0400, Sebastian Zimmeck wrote: > > At the beginning of this year the California Consumer Privacy Act (CCPA= ) > > became effective. In addition to the rights of data access and deletion= , > > this new privacy law gives consumers the right to opt out from the sale > of > > personal information. A "sale" is understood broadly and likely covers, > for > > example, a website or app disclosing location data or device identifier= s > to > > an ad network for purposes of monetization. Now, the most recent > regulations > > to the CCPA > > < > https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-text-of-se= cond-set-mod-031120.pdf > ?> > > published > > by the California Attorney General specify that automatic signals > > communicating a user's decision to opt out must be respected. Here is t= he > > relevant language: > > > > "If a business collects personal information from consumers online, the > > business shall treat user-enabled global privacy controls, such as a > > browser plugin or privacy setting, device setting, or other mechanism, > that > > communicate or signal the consumer=E2=80=99s choice to opt-out of the s= ale of > their > > personal information as a valid request ... ." > > > > I am interested in setting up a working group on such device controls. > The > > Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. > > However, the difference is that recipients of the DNT signal were not > > required to comply with the signal. Rather, they only needed to *say* > > whether they would comply; per the California Online Privacy Protection > Act > > (CalOPPA). > > > > Also, the CCPA may have substantial impact beyond California as some > > companies, e.g., Microsoft, already made clear that they would apply th= e > > CCPA to all consumers in the US. > > > > It would be great to get a discussion started ... > > It's not really clear to me how much discussion is needed... > if one assumes that you're just considering a HTTP header field, then the > only technical question I can think of is whether there's intended to be > some level of richness of expressivity vs. a boolean signal "don't sell m= y > data". At that point it is mostly a matter of writing down the expected > semantics (the header field registry requires only Expert Review for > allocations). > > -Ben > > --000000000000bcf1b705a1edace5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 2= 7, 2020 at 3:28 PM Benjamin Kaduk <kadu= k@mit.edu> wrote:
On Sat, Mar 21, 2020 at 08:08:40PM -0400, Sebastian Zimmeck wrot= e:
> At the beginning of this year the California Consumer Privacy Act (CCP= A)
> became effective. In addition to the rights of data access and deletio= n,
> this new privacy law gives consumers the right to opt out from the sal= e of
> personal information. A "sale" is understood broadly and lik= ely covers, for
> example, a website or app disclosing location data or device identifie= rs to
> an ad network for purposes of monetization. Now, the most recent regul= ations
> to the CCPA
> <https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/ccpa-text-of= -second-set-mod-031120.pdf?>
> published
> by the California Attorney General specify that automatic signals
> communicating a user's decision to opt out must be respected. Here= is the
> relevant language:
>
> "If a business collects personal information from consumers onlin= e, the
> business shall treat user-enabled global privacy controls, such as a > browser plugin or privacy setting, device setting, or other mechanism,= that
> communicate or signal the consumer=E2=80=99s choice to opt-out of the = sale of their
> personal information as a valid request ... ."
>
> I am interested in setting up a working group on such device controls.= The
> Do-Not-Sell signal could be similar to a Do-Not-Track (DNT) signal. > However, the difference is that recipients of the DNT signal were not<= br> > required to comply with the signal. Rather, they only needed to *say*<= br> > whether they would comply; per the California Online Privacy Protectio= n Act
> (CalOPPA).
>
> Also, the CCPA may have substantial impact beyond California as some > companies, e.g., Microsoft, already made clear that they would apply t= he
> CCPA to all consumers in the US.
>
> It would be great to get a discussion started ...

It's not really clear to me how much discussion is needed...
if one assumes that you're just considering a HTTP header field, then t= he
only technical question I can think of is whether there's intended to b= e
some level of richness of expressivity vs. a boolean signal "don't= sell my
data".=C2=A0 At that point it is mostly a matter of writing down the e= xpected
semantics (the header field registry requires only Expert Review for
allocations).

-Ben

--000000000000bcf1b705a1edace5-- From nobody Sat Mar 28 21:38:03 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B33A10E8 for ; Sat, 28 Mar 2020 21:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGoGyiuZX1NO for ; Sat, 28 Mar 2020 21:38:00 -0700 (PDT) Received: from camel.ash.relay.mailchannels.net (camel.ash.relay.mailchannels.net [23.83.222.29]) (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 5EA623A10E7 for ; Sat, 28 Mar 2020 21:37:58 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 362AF36119C; Sun, 29 Mar 2020 04:37:54 +0000 (UTC) Received: from pdx1-sub0-mail-a87.g.dreamhost.com (100-96-54-82.trex.outbound.svc.cluster.local [100.96.54.82]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8F513361171; Sun, 29 Mar 2020 04:37:53 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a87.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Sun, 29 Mar 2020 04:37:54 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Desert-Continue: 44931d3454b4afa2_1585456674023_3467246815 X-MC-Loop-Signature: 1585456674023:3677758109 X-MC-Ingress-Time: 1585456674023 Received: from pdx1-sub0-mail-a87.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTP id 1F5B0B2960; Sat, 28 Mar 2020 21:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=cryptonector.com; bh=K8wVIQrN3vF5cTda8rVokpLo9J Q=; b=OkMfHBmlmT/p6RlflH1c6os7NeuT9VRI11HHev81E8nZ5tjzDUrma1YAel lciSZ+INkwClyDtr+DCPlXKDUf0cP8Fe87StGcrs4e4q4piYavVwN6BRcmPYviTJ 4BN0KWJsDW6S4p4lcBPw63kknN3wvNlJRSKa+hgjGIC4zRrFg= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 84E1EB295B; Sat, 28 Mar 2020 21:37:50 -0700 (PDT) Date: Sat, 28 Mar 2020 23:37:48 -0500 X-DH-BACKEND: pdx1-sub0-mail-a87 From: Nico Williams To: ietf-http-wg@w3.org Cc: secdispatch@ietf.org Message-ID: <20200329043333.GO18021@localhost> Reply-To: ietf-http-wg@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeivddgjeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkrhggtggufgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepshgvvggrlhhsohdvrdhfvggvuggsrggtkhdpihgvthhfrdhorhhgpdhmihgtrhhoshhofhhtrdgtohhmnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 04:38:02 -0000 I've just submitted draft-williams-http-accept-auth-and-redirect-00 [0] to deal with the problem of the mutual exclusivity of 3xx and 401. This problem arises when, for example, one mixes in some organization, both Negotiate [RFC4559] and redirect-based authentication flows. This problem is rather vexing: the server has to decide which to go with without knowing which the user-agent supports! The solution seems simple: let the user-agent tell the server what authentication schemes it supports. (Indeed, one common hack is to glean this from the user-agent string.) As well, let the server mix redirection and authentication requests. As well, while we're at it, why not codify redirect-based authentication. In particular, the PowerShell HTTP command-line client, Invoke-WebRequest [1] has an option to copy Authorization headers from redirect responses to redirected requests, which seems like just the ticket: | -PreserveAuthorizationOnRedirect | | Indicates the cmdlet should preserve the Authorization header, when | present, across redirections. | | By default, the cmdlet strips the Authorization header before | redirecting. Specifying this parameter disables this logic for cases | where the header needs to be sent to the redirection location. ISTR seeing a prohibition on copying headers from redirect responses to redirected requests, but I can't find this now. Digest [RFC2617] actually describes the Authorization-copying behavior in a paragraph that straddles pages 17 and 18, using the "domain" parameter of Digest to effect a redirection. This I-D then adds an Accept-Auth request header, and an HTTP authentication scheme named Redirect, and codifies other ways to mix redirection and authentication requests. This I-D seems trivial enough to go the ISE route, but perhaps some WG, such as HTTPbis, might be interested in taking a closer look, reviewing, possibly leading to request not to publish (if, e.g., there's already a solution I've missed or this is problematic for some reason), or to adopting the work. Cc'ed is secdispatch@ietf.org, in case they want to dispatch this I-D. Reply-To is set to HTTPbis. See also [2]. Feedback would be greatly appreciated. Stay safe! [0] https://tools.ietf.org/html/draft-williams-http-accept-auth-and-redirect-00 https://www.ietf.org/internet-drafts/draft-williams-http-accept-auth-and-redirect-00.txt [1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7 [2] https://mailarchive.ietf.org/arch/msg/art/T4nP5Rv91yuE0ew8p0vJh2fX1IM/ Nico -- From nobody Sun Mar 29 15:13:49 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E753A0E15 for ; Sun, 29 Mar 2020 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvASmHotPigm for ; Sun, 29 Mar 2020 15:13:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403E83A0E11 for ; Sun, 29 Mar 2020 15:13:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9EE63897D; Sun, 29 Mar 2020 18:12:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5981FC9; Sun, 29 Mar 2020 18:13:39 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , Eric Rescorla , IETF SecDispatch , Brian Campbell In-Reply-To: <20200327193704.GQ50174@kduck.mit.edu> References: <20200327193704.GQ50174@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 22:13:48 -0000 --=-=-= Content-Type: text/plain On Fri, Mar 27, 2020 at 10:21:17AM -0700, Eric Rescorla wrote: >> Overall, I agree that something like this is needed. However, >> I have two concerns about the mechanism described here. >> >> First, as you note in S B.1., if the header is not properly >> sanitized, there is a trivial attack and there are stronger >> mechanism that do not require sanitization: >> >> "Client-Cert" header that would appear to the backend to have come >> from the reverse proxy. Although numerous other methods of >> detecting/preventing header injection are possible; such as the use >> of a unique secret value as part of the header name or value or the >> application of a signature, HMAC, or AEAD, there is no common general >> standardized mechanism. The potential problem of client header >> injection is not at all unique to the functionality of this draft and >> it would therefor be inappropriate for this draft to define a one-off >> solution. In the absence of a generic standardized solution existing >> currently, stripping/sanitizing the headers is the de facto means of >> protecting against header injection in practice today. Sanitizing >> >> This seems like an odd argument to make: if a strong mechanism is >> in order, we should design one and make it generic, not just throw >> and continue to use weaker mechanisms. I agree: it seems like we ought to make some kind of more generic mechanism. It feels like we are creating a new reverse-proxy/framework channel. The stupidest version I can imagine is two sets of HTTP headers... message/rfc822 like. There are a bunch of such interfaces around already, and maybe we can do this if we assume HTTP/2 here. Benjamin Kaduk wrote: > Hmm, that requires the proxy to keep that state around (either locally or > in the resumption ticket). Brainstorming, in TLS 1.3 one could also have > the application manage the authentication state by having the proxy not > issue tickets right at the handshake completion, and instead wait for the > application to return a blob to include in the ticket. This would provide > a convenient excuse for adding a way to secure the proxy/backend channel, > with the proxy adding a header with a key fingerprint, and the backend > encrypting its response to that key, only if the key is whitelisted in the > application's configuration. On the other hand, it's more moving I think that you two have potentially given a reasonable technical reason why this work is not as trivial as envisioned, and that we need to boil a bit more water here, without an entire ocean. That maybe it requires a significant part of a WG, if not an entire WG. It was mentioned that HTTPBIS plans to cleave of some pieces, but I don't have the time to follow all of HTTPBIS... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6BHZMACgkQgItw+93Q 3WV7EAf+M+WJ/DQ3VPIAwANDdy/KQ4JbW88f6y+kj2eOtrqjevLZFLKbutfmzeN8 b+FEAPzQVv26cxIO1yIbk0egqUvDgXcd6EeDhmpQElzUMKr8cy29VoqYmCvl/ezO /O9/RnrGiIzPcnyYsrilhgemKzFG1Imjeguql0L3/0LlR393mwgj1hZyo+K/ChlG hxBJazdeXmCeY7uoikJXkkTXhgh0Xx+XQaExCdjh13jTosaAC2//yYVLgsMPXr/8 Ac+1K0XkYPIoWLs87u7sxLSZ4ptJhMyaG2V4BZQcwj+ThrVw1Y4O0BrHe5sKt35F C0/kxuN3qcrIgkS3neitMhwvCkQkZg== =y27/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 30 10:38:15 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81C43A0906 for ; Mon, 30 Mar 2020 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsGttw5lSDUZ for ; Mon, 30 Mar 2020 10:38:03 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 5888F3A090E for ; Mon, 30 Mar 2020 10:38:03 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id q5so14916508lfb.13 for ; Mon, 30 Mar 2020 10:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0+olRDNjuWZc2sVXIa4lyqGNmujP6jPPJP56yQL3myA=; b=Ba5eO0JPuLKCue2sULMRLRUfxWrVBEKQO4V6MTKDLK2bR8KuB6GvSiku0cTc7H7VJ+ RCJWmjDCe+GHUHoZZlw8V7Z5CGpmVqG+IIPeoftEqrDqLrrQdSY+sVFGiidpaYJNLZqa YcW61eN7/RuRmGmZkpHkzFzuNjjOrZFeKpiBBi/w6UBWuI/9oriBpETVNyPVYokiTwaO ChzVofaQUnEwDqjzO759mhT/D7A3zVQ3HPPBbPZgxHPbyDbHlOwMkaRi9fhxOLtsP+nf bV7NFpuHiqoOSUqz7bfr7OIbgBYKXT1k4widGkwc7wuqtKYikXfpyCt95OrMdppLQvUi /xNA== 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=0+olRDNjuWZc2sVXIa4lyqGNmujP6jPPJP56yQL3myA=; b=jPdL8GPMs5xkApOEZLY41gB0eIA3ng3PRlhYeGEF0dA0NfBo3xMmyeWrWWiNgt5j4m OSLg/elUbtrzWrOOyyQDXsL/bJ83ZLbMVLB711LZB6YP4xKuOXr2jsPq3uBCvq30pMpd iC1AN5Zf5epJbVmG/H9By0N/UDnsnIvocnffbl5HZGEs3Ltena17FlIkOaiqIAJKfFUZ BVVIircNBTnMrcxNagpAqSt15KKifmRlBBWhirLyClY735TZQpzHSeoTY1f//c/rsS/A tH6UNen9oqwGGB1HwA2mOE/JUT4VuHvTKqNR9eFP7I9quwxly3rufnmE1QHWd8NKtrxS YpOA== X-Gm-Message-State: AGi0PubxngCirOUT/hdSgdbdr78dreBIfgg+6TIVsCHFCwSSf8w/sU9p 2JJ1KddYY7peWmP6A7ppPt/8gdwyyB+N676t09KwI1mNwIRU5WlItyzCqooTmKKV88EMoIUpuN5 6HUzoa6V9DUlGH0/rt9Nxpg== X-Google-Smtp-Source: APiQypLZuVlv74cJrL3TqaK8zT7kNp/ZdWV6pTFQbdPJ6sKg6Hz4h0gMVl7pgPGsLnTU+3q/ZxLkwIXBDPzQfzMSe8E= X-Received: by 2002:a19:a40f:: with SMTP id q15mr8616272lfc.104.1585589881376; Mon, 30 Mar 2020 10:38:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 30 Mar 2020 11:37:35 -0600 Message-ID: To: Eric Rescorla Cc: secdispatch-chairs@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000a3c39305a215e978" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 17:38:13 -0000 --000000000000a3c39305a215e978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and feedback, Eric. My attempts at answers/responses are inline below. On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla wrote: > > Overall, I agree that something like this is needed. However, > I have two concerns about the mechanism described here. > > First, as you note in S B.1., if the header is not properly > sanitized, there is a trivial attack and there are stronger > mechanism that do not require sanitization: > > "Client-Cert" header that would appear to the backend to have come > from the reverse proxy. Although numerous other methods of > detecting/preventing header injection are possible; such as the use > of a unique secret value as part of the header name or value or the > application of a signature, HMAC, or AEAD, there is no common general > standardized mechanism. The potential problem of client header > injection is not at all unique to the functionality of this draft and > it would therefor be inappropriate for this draft to define a one-off > solution. In the absence of a generic standardized solution existing > currently, stripping/sanitizing the headers is the de facto means of > protecting against header injection in practice today. Sanitizing > > This seems like an odd argument to make: if a strong mechanism is > in order, we should design one and make it generic, not just throw > and continue to use weaker mechanisms. > Ironically, that text was written (at least in part) in an attempt to head off having this very argument with you. We (you and I specifically) have been down this road before discussing essentially the same issue with respect to (the now defunct for unrelated reasons) https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure didn't seem to be be sufficient appetite to work on a generic solution. Maybe that's changed and there is more of an appetite now? Maybe. There was some talk at the secdispatch session of the prospect of spinning up or splitting off a WG to work on reverse proxy stuff. But a lot more than talk is needed and I maintain that, in the absence of something generic being defined and widely available, the de facto is sufficiently good and appropriate for a document/draft like this. > > Second, I think it's quite unwise to only pass the EE cert. This > means that the server will be unable to independently evaluate > the cert chain, which (1) is unduly restrictive on the architecture > because it forces the proxy to do it and (2) means that there > is no backstop in the case where the proxy makes errors or > has a not-very-good validator. You should pass the whole chain. > Passing the end-entity cert vs. including intermediates or the whole chain is something that's up for discussion should this document find a home where it can be worked on and progressed. As with most things, there are tradeoffs involved. What you describe as unduly restrictive, however, could also be viewed as properly constraining different components to doing the most appropriate functionality. The backend server doing the validation would mean it has to evaluate the cert chain on every request (which is likely prohibitively expensive with multiple public key opperations) and/or have some complicated caching. And allowing either piece to do the validation could also increase the likelihood that things are set up such that neither actually does it. > This also implies that you should have a way to pass extensions > such as SCTs and stapled OCSP responses. > I was under the (maybe naive) impression that such things were largely or even exclusively for the server side and not applicable or defined for the client side? Regardless, I'd view this as additional reasons for why it's more appropriately restrictive for the reverse proxy to be checking the certificate validity and only passing the cert back to the backend on successful validation. > > Finally, two points about TLS integration. > > 1. You should define how this works in the case of resumption > of a connection that had client auth. Should the proxy attach the > chain from the original connection? > Is such a resumed connection still considered to be client authenticated? I thought so and thus my assumption/expectation was that yes the proxy would attach the chain from the original connection. Is that problematic for some reason? Or are you just saying that it needs to be stated explicitly in the document? > > 2. How do you handle post-handshake client authentication? Specifically: > (a) How do you handle the situation in which part of the HTTP > request is covered by the client cert? > > (b) Post-handshake client authentication allows for the client > to authenticate with multiple certificates one after the other. > How is this propagated to the server? > I'd been thinking that post-handshake authentication and renegotiation were forbidden so these questions were out of scope. But I guess that only applies to HTTP/2? So, off-the-cuff I'd say that for (a) the header is only passed on requests that are covered in full by the cert. But that pragmatically it's super difficult or impossible with the APIs in the average environment to figure out what application data came before or after the cert auth and so it'll end up being however a particular proxy implementation treats this situation currently but just with a standard header. For (b) I'd say only propagate the most recent one. Having given my half-assed answers though, I'd welcome input if you think there are better answers. > > On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Hello SecDispatchers and Chairs thereof, >> >> I'd like to request some time on the agenda in Vancouver to present on >> https://datatracker.ietf.org/doc/draft-bdc-something-something-certifica= te/ >> in an effort to gauge interest and potentially find an appropriate venue >> for the work to proceed (or just put it and its ridiculously long title = out >> of its misery). >> >> Client-Cert HTTP Header: Conveying Client Certificate Information from >> TLS Terminating Reverse Proxies to Origin Server Applications >> >> Abstract >> >> This document defines the HTTP header field "Client-Cert" that allows >> a TLS terminating reverse proxy to convey information about the >> client certificate of a mutually-authenticated TLS connection to an >> origin server in a common and predictable manner. >> >> Discussion around the value of having something like this defined >> happened in the OAuth WG a bit before the Singapore meeting (no doubt >> that's not the only time but it's the one in which I was involved recent= ly) >> and an AD nudged me to secdispatch - >> https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ >> falls somewhere in the middle of that long and sometimes contentious >> thread. I was unable to get a draft published prior to the I-D submissio= n >> cut-off for Singapore and got a short "if time allows" presentation slot= at >> the meeting. The judgment coming out of that meeting was "needs draft". >> >> I did get an actual draft published a bit after Singapore (the one with >> the ridiculously long title previously mentioned) and there's been some,= if >> not exactly an overwhelming amount of, discussion and support of it on t= his >> very list: >> https://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-something-som= ething-certificate%22 >> >> Thanks. >> Brian Campbell >> >> >> >> >> >> >> >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a3c39305a215e978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks fo= r the review and feedback, Eric. My attempts at answers/responses are inlin= e below.

On Fri, Mar 27, 2020 at 11:22 AM Eric R= escorla <ekr@rtfm.com<= /a>> wrote:
<= div dir=3D"ltr">
Overall, I agree that something like this is needed. Ho= wever,
I have two concerns about the mechanism described here.

Fi= rst, as you note in S B.1., if the header is not properly
sanitized, the= re is a trivial attack and there are stronger
mechanism that do not requ= ire sanitization:

=C2=A0 =C2=A0"Client-Cert" header that w= ould appear to the backend to have come
=C2=A0 =C2=A0from the reverse pr= oxy.=C2=A0 Although numerous other methods of
=C2=A0 =C2=A0detecting/pre= venting header injection are possible; such as the use
=C2=A0 =C2=A0of a= unique secret value as part of the header name or value or the
=C2=A0 = =C2=A0application of a signature, HMAC, or AEAD, there is no common general=
=C2=A0 =C2=A0standardized mechanism.=C2=A0 The potential problem of cli= ent header
=C2=A0 =C2=A0injection is not at all unique to the functional= ity of this draft and
=C2=A0 =C2=A0it would therefor be inappropriate fo= r this draft to define a one-off
=C2=A0 =C2=A0solution.=C2=A0 In the abs= ence of a generic standardized solution existing
=C2=A0 =C2=A0currently,= stripping/sanitizing the headers is the de facto means of
=C2=A0 =C2=A0= protecting against header injection in practice today.=C2=A0 Sanitizing
=
This seems like an odd argument to make: if a strong mechanism is
in= order, we should design one and make it generic, not just throw
and con= tinue to use weaker mechanisms.

I= ronically, that text was written (at least in part) in an attempt to head o= ff having this very argument with you. We (you and I specifically) have bee= n down this road before discussing essentially the same issue with respect = to (the now defunct for unrelated reasons) https://datatracker= .ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure didn't seem t= o be be sufficient appetite to work on a generic solution. Maybe that's= changed and there is more of an appetite now? Maybe. There was some talk a= t the secdispatch session of the prospect of spinning up or splitting off a= WG to work on reverse proxy stuff. But a lot more than talk is needed and = I maintain that, in the absence of something generic being defined and wide= ly available, the de facto is sufficiently good and appropriate for a docum= ent/draft like this.=C2=A0

=C2=A0

Second, I = think it's quite unwise to only pass the EE cert. This
means that th= e server will be unable to independently evaluate
the cert chain, which = (1) is unduly restrictive on the architecture
because it forces the prox= y to do it and (2) means that there
is no backstop in the case where the= proxy makes errors or
has a not-very-good validator. You should pass th= e whole chain.

Passing the end-en= tity cert vs. including intermediates or the whole chain is something that&= #39;s up for discussion should this document find a home where it can be wo= rked on and progressed. As with most things, there are tradeoffs involved. =

What you describe as unduly restrictive, howe= ver, could also be viewed as properly constraining different components to = doing the most appropriate functionality. The backend server doing the vali= dation would mean it has to evaluate the cert chain on every request (which= is likely prohibitively expensive with multiple public key opperations) an= d/or have some complicated caching. And allowing either piece to do the val= idation could also increase the likelihood that things are set up such that= neither actually does it.

=C2=A0
This also impl= ies that you should have a way to pass extensions
such as SCTs and stapl= ed OCSP responses.

I was under th= e (maybe naive) impression that such things were largely or even exclusivel= y for the server side and not applicable or defined for the client side?

Regardless, I'd view this as additional reasons = for why it's more appropriately restrictive for the reverse proxy to be= checking the certificate validity and only passing the cert back to the ba= ckend on successful validation.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Final= ly, two points about TLS integration.

1. You should define how this = works in the case of resumption
of a connection that had client auth. Sh= ould the proxy attach the
chain from the original connection?
<= /blockquote>

Is such a resumed connection still consider= ed to be client authenticated? I thought so and thus my assumption/expectat= ion was that yes the proxy would attach the chain from the original connect= ion. Is that problematic for some reason? Or are you just saying that it ne= eds to be stated explicitly in the document?

= =C2=A0

2. How do you handle post-handshake client authentication? Specific= ally:
(a) How do you handle the situation in which part of the HTTP
r= equest is covered by the client cert?

(b) Post-handshake client auth= entication allows for the client
to authenticate with multiple certifica= tes one after the other.
How is this propagated to the server?
=

I'd been thinking that post-handshake = authentication and renegotiation were forbidden so these questions were out= of scope. But I guess that only applies to HTTP/2?

So, off-the-cuff I'd say that for (a) the header is only passed o= n requests that are covered in full by the cert. But that pragmatically it&= #39;s super difficult or impossible with the APIs in the average environmen= t to figure out what application data came before or after the cert auth an= d so it'll end up being however a particular proxy implementation treat= s this situation currently but just with a standard header. For (b) I'= d say only propagate the most recent one.

Hav= ing given my half-assed answers though, I'd welcome input if you think = there are better answers.
=C2=A0

=C2=A0

On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=3D40pingident= ity.com@dmarc.ietf.org> wrote:
Hello SecDispatchers and Chairs= thereof,

I'd like to request some time on the= agenda in Vancouver to present on https://= datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ in = an effort to gauge interest and potentially find an appropriate venue for t= he work to proceed (or just put it and its ridiculously long title out of i= ts misery).

Client-Cert HTTP Header: Conveying Client Certificate= Information from
=C2=A0 =C2=A0 =C2=A0TLS Terminating Reverse Proxies to= Origin Server Applications

=
Abstract

=C2=A0 =C2=A0This document = defines the HTTP header field "Client-Cert" that allows
=C2=A0= =C2=A0a TLS terminating reverse proxy to convey information about the
= =C2=A0 =C2=A0client certificate of a mutually-authenticated TLS connection = to an
=C2=A0 =C2=A0origin server in a common and predictable manner.

Discussion around the value of having something like = this defined happened in the OAuth WG a bit before the Singapore meeting (n= o doubt that's not the only time but it's the one in which I was in= volved recently) and an AD nudged me to secdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQ= oKo/ falls somewhere in the middle of that long and sometimes contentio= us thread. I was unable to get a draft published prior to the I-D submissio= n cut-off for Singapore and got a short "if time allows" presenta= tion slot at the meeting. The judgment coming out of that meeting was "= ;needs draft".

I did get an actual draft= published a bit after Singapore (the one with the ridiculously long title = previously mentioned) and there's been some, if not exactly an overwhel= ming amount of, discussion and support of it on this very list: https://mailarchive.ietf.org/arch/sea= rch/?q=3D%22draft-bdc-something-something-certificate%22

=
Thanks.
Brian Campbell

<= br>




<= br>




CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a3c39305a215e978-- From nobody Mon Mar 30 11:05:15 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BE53A0A20 for ; Mon, 30 Mar 2020 11:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiXDQfZa1WXG for ; Mon, 30 Mar 2020 11:05:09 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02FD3A0FFD for ; Mon, 30 Mar 2020 11:03:52 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id 19so19090632ljj.7 for ; Mon, 30 Mar 2020 11:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdB5KN1KHWUobMc7Xq+PGaDPz0VyECgeFTp+kt3p3XQ=; b=AcHdCUEquxkrBTrw0wFdOglei7T+Z+8vTctiAyR+4VbvrZ05ZVTtmhrlWSlx062rz+ kCj4dJOpRxZa+UDCYYV0Z/e5fyjOSnE9p/uPn4qPwK8Wa+it0VF9hT9RcPTZEbdI7RCW 4TjVC8lUxOD8/DI94AOesw3/NYp6lVGadA9ksFavN6SkYO2h1Jmic5tSVmZ3tMPU3ZM+ 9MF4am7BKfmwlEN+6tTC30R370DM4kpu8BjRAFfgK9DhtltX3xsYduq4XNQcniKJY3Fx Pj2X2R9nJqWci70SwrCTndLgXU3+AOgTFOz8czwOk7d9Ihi13h8DgArWT0u0YQZHbHAl OzHQ== 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=sdB5KN1KHWUobMc7Xq+PGaDPz0VyECgeFTp+kt3p3XQ=; b=Z9T2L4TwIKb1d/3zYpA4b1XzZzoGBy3THhcM8kH3w/1uY+oOFXRsxP/nWdEfPefHpG DHekz/EieGCcXuwzmjilV98mQLullBB80NZlQQfgtPUurK4sJYeGg7ivUD9H15byqkGS DUYc35nVWZDRrmoJNGZC6iN1Er+nJwcBsBiPa713RTER4SKc6wJDSyxP0F0FvjhQ6Rf4 zbrCe3/DrTUGgmettm3gZYNHwAXwYlGC5+fE7tUqrjO9gVJJylubEgNMAXpvtY7gd9NA 3yAeyzXiKc3//GBuivbyJS5DQFdKfE+HW8Qi0vd4H5CGL/6Wxdu5Y4LfmbGRd+Da2kdM +W/A== X-Gm-Message-State: AGi0PuYg+NN9KaZ8nZddb7v/AQupTO9txYBSqCTxRirceKNQPNc1ETW6 B6wbPcoHoPdMkXCEhiblXu8Q0dhAURT8NGc8Ley91XOtXuPmPr+xmrNXqfvKS1lzj/WdJ9RFcB6 oMioeGbIqsn16X43YapoHpQ== X-Google-Smtp-Source: APiQypJCMakfFV2S09KklW2pVvBXr1dDH43o2ovEscq5qpoFadSIaYIRgCBpf09t5HWHP/tAUFPWb5DNAnHqKdcRyKo= X-Received: by 2002:a2e:97cd:: with SMTP id m13mr8056487ljj.20.1585591430989; Mon, 30 Mar 2020 11:03:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 30 Mar 2020 12:03:24 -0600 Message-ID: To: Mohit Sethi M Cc: Eric Rescorla , IETF SecDispatch , "secdispatch-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000000edff05a2164663" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:05:13 -0000 --00000000000000edff05a2164663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I just tried to articulate to EKR in the last mail, passing the end-entity cert vs. including intermediates or the whole chain, or something else is a topic that's up for discussion should this document find a home where it can be worked on and progressed. But as it true with most things, there are tradeoffs involved. And as explained in the draft, my first best attempt at finding the right place in the tradeoffs was to go with the end-entity cert and not more or less. On Fri, Mar 27, 2020 at 4:17 PM Mohit Sethi M wrote: > Hi Brian, > > On further thought, I actually agree that passing the entire chain makes > more sense. This would be useful if the TLS proxy doesn't have the trust > anchor (but the backend server has it). > > --Mohit > On 3/27/20 7:21 PM, Eric Rescorla wrote: > > > Overall, I agree that something like this is needed. However, > I have two concerns about the mechanism described here. > > First, as you note in S B.1., if the header is not properly > sanitized, there is a trivial attack and there are stronger > mechanism that do not require sanitization: > > "Client-Cert" header that would appear to the backend to have come > from the reverse proxy. Although numerous other methods of > detecting/preventing header injection are possible; such as the use > of a unique secret value as part of the header name or value or the > application of a signature, HMAC, or AEAD, there is no common general > standardized mechanism. The potential problem of client header > injection is not at all unique to the functionality of this draft and > it would therefor be inappropriate for this draft to define a one-off > solution. In the absence of a generic standardized solution existing > currently, stripping/sanitizing the headers is the de facto means of > protecting against header injection in practice today. Sanitizing > > This seems like an odd argument to make: if a strong mechanism is > in order, we should design one and make it generic, not just throw > and continue to use weaker mechanisms. > > > Second, I think it's quite unwise to only pass the EE cert. This > means that the server will be unable to independently evaluate > the cert chain, which (1) is unduly restrictive on the architecture > because it forces the proxy to do it and (2) means that there > is no backstop in the case where the proxy makes errors or > has a not-very-good validator. You should pass the whole chain. > This also implies that you should have a way to pass extensions > such as SCTs and stapled OCSP responses. > > > Finally, two points about TLS integration. > > 1. You should define how this works in the case of resumption > of a connection that had client auth. Should the proxy attach the > chain from the original connection? > > > 2. How do you handle post-handshake client authentication? Specifically: > (a) How do you handle the situation in which part of the HTTP > request is covered by the client cert? > > (b) Post-handshake client authentication allows for the client > to authenticate with multiple certificates one after the other. > How is this propagated to the server? > > On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > >> Hello SecDispatchers and Chairs thereof, >> >> I'd like to request some time on the agenda in Vancouver to present on >> https://datatracker.ietf.org/doc/draft-bdc-something-something-certifica= te/ >> in an effort to gauge interest and potentially find an appropriate venue >> for the work to proceed (or just put it and its ridiculously long title = out >> of its misery). >> >> Client-Cert HTTP Header: Conveying Client Certificate Information from >> TLS Terminating Reverse Proxies to Origin Server Applications >> >> Abstract >> >> This document defines the HTTP header field "Client-Cert" that allows >> a TLS terminating reverse proxy to convey information about the >> client certificate of a mutually-authenticated TLS connection to an >> origin server in a common and predictable manner. >> >> Discussion around the value of having something like this defined >> happened in the OAuth WG a bit before the Singapore meeting (no doubt >> that's not the only time but it's the one in which I was involved recent= ly) >> and an AD nudged me to secdispatch - >> https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ >> falls somewhere in the middle of that long and sometimes contentious >> thread. I was unable to get a draft published prior to the I-D submissio= n >> cut-off for Singapore and got a short "if time allows" presentation slot= at >> the meeting. The judgment coming out of that meeting was "needs draft". >> >> I did get an actual draft published a bit after Singapore (the one with >> the ridiculously long title previously mentioned) and there's been some,= if >> not exactly an overwhelming amount of, discussion and support of it on t= his >> very list: >> https://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-something-som= ething-certificate%22 >> >> Thanks. >> Brian Campbell >> >> >> >> >> >> >> >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= .. >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> Secdispatch mailing list >> Secdispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/secdispatch >> > > _______________________________________________ > Secdispatch mailing listSecdispatch@ietf.orghttps://www.ietf.org/mailman/= listinfo/secdispatch > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000000edff05a2164663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I just tried to articulate to EKR in the last mail, pas= sing the end-entity cert vs. including intermediates or the whole chain, or= something else is a topic that's up for discussion should this documen= t find a home where it can be worked on and progressed. But as it true with= most things, there are tradeoffs involved. And as explained in the draft, = my first best attempt at finding the right place in the tradeoffs was to go= with the end-entity cert and not more or less.

On Fri, Mar 27, 2020 at= 4:17 PM Mohit Sethi M <mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi Brian,

On further thought, I actually agree that passing the entire chain makes= more sense. This would be useful if the TLS proxy doesn't have the tru= st anchor (but the backend server has it).

--Mohit

On 3/27/20 7:21 PM, Eric Rescorla wrote:

Overall, I agree that something like this is needed. However,
I have two concerns about the mechanism described here.

First, as you note in S B.1., if the header is not properly
sanitized, there is a trivial attack and there are stronger
mechanism that do not require sanitization:

=C2=A0 =C2=A0"Client-Cert" header that would appear to the backen= d to have come
=C2=A0 =C2=A0from the reverse proxy.=C2=A0 Although numerous other methods = of
=C2=A0 =C2=A0detecting/preventing header injection are possible; such as th= e use
=C2=A0 =C2=A0of a unique secret value as part of the header name or value o= r the
=C2=A0 =C2=A0application of a signature, HMAC, or AEAD, there is no common = general
=C2=A0 =C2=A0standardized mechanism.=C2=A0 The potential problem of client = header
=C2=A0 =C2=A0injection is not at all unique to the functionality of this dr= aft and
=C2=A0 =C2=A0it would therefor be inappropriate for this draft to define a = one-off
=C2=A0 =C2=A0solution.=C2=A0 In the absence of a generic standardized solut= ion existing
=C2=A0 =C2=A0currently, stripping/sanitizing the headers is the de facto me= ans of
=C2=A0 =C2=A0protecting against header injection in practice today.=C2=A0 S= anitizing

This seems like an odd argument to make: if a strong mechanism is
in order, we should design one and make it generic, not just throw
and continue to use weaker mechanisms.


Second, I think it's quite unwise to only pass the EE cert. This
means that the server will be unable to independently evaluate
the cert chain, which (1) is unduly restrictive on the architecture
because it forces the proxy to do it and (2) means that there
is no backstop in the case where the proxy makes errors or
has a not-very-good validator. You should pass the whole chain.
This also implies that you should have a way to pass extensions
such as SCTs and stapled OCSP responses.


Finally, two points about TLS integration.

1. You should define how this works in the case of resumption
of a connection that had client auth. Should the proxy attach the
chain from the original connection?


2. How do you handle post-handshake client authentication? Specifically: (a) How do you handle the situation in which part of the HTTP
request is covered by the client cert?

(b) Post-handshake client authentication allows for the client
to authenticate with multiple certificates one after the other.
How is this propagated to the server?

On Mon, Mar 2, 2020 at 1:51 PM Brian = Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
Hello SecDispatchers and Chairs thereof,

I'd like to request some time on the agenda in Vancouver to presen= t on https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/= in an effort to gauge interest and potentially find an appropriate ven= ue for the work to proceed (or just put it and its ridiculously long title = out of its misery).

Client-Cert HTTP Header: Conveying Client C= ertificate Information from
=C2=A0 =C2=A0 =C2=A0TLS Terminating Reverse Proxies to Origin Server Applic= ations

Abstract

=C2=A0 =C2=A0This document defines the HTTP header field "Client-Cert&= quot; that allows
=C2=A0 =C2=A0a TLS terminating reverse proxy to convey information about th= e
=C2=A0 =C2=A0client certificate of a mutually-authenticated TLS connection = to an
=C2=A0 =C2=A0origin server in a common and predictable manner.

Discussion around the value of having something like this defined happ= ened in the OAuth WG a bit before the Singapore meeting (no doubt that'= s not the only time but it's the one in which I was involved recently) = and an AD nudged me to secdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ falls somewhere in the middle of that long and sometimes contentious thre= ad. I was unable to get a draft published prior to the I-D submission cut-o= ff for Singapore and got a short "if time allows" presentation slot at the meeting. The judgment = coming out of that meeting was "needs draft".


Thanks.
Brian Campbell











CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for th= e sole use of the intended recipient(s). Any review, use, distribution or d= isclosure by others is strictly prohibited..=C2=A0 If you have received thi= s communication in error, please notify the sender immediately by e-mail and delete the message and any file attac= hments from your computer. Thank you.____________________= ___________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.=
org
https://www.ietf.org/mailman/listinfo/secdispatch

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000000edff05a2164663-- From nobody Mon Mar 30 11:13:07 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284243A0D1E for ; Mon, 30 Mar 2020 11:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eu1Heook7dw for ; Mon, 30 Mar 2020 11:13:02 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 012293A0D28 for ; Mon, 30 Mar 2020 11:13:02 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id j17so15010658lfe.7 for ; Mon, 30 Mar 2020 11:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Esb5S7q71D+yRj6wekjXgI/zh0eu3jmxEnmVl03bITA=; b=U/rHZMnC/0FbC1rsks/a1YXHxf+3cWDv+tU1JOQk8z9s5VHqUF/5vVJPVFXiyPXg5C zjTSn6ngBnrlGuyGdbUOrKQm2lhWiYWTfL+nkzJQyKVLsMR2njYOegIzSbQSeitOXmsf XwWcWtDSG05mLl806O0PIKTXfR9PY0Bl4omhNUOomfJpnOdE0uorTCm/19E3ZbCHClqc cTvgYSdqaPpc7drM7IQmWG6QLrm0Vb2ljAR7Myv90qGaOZbdPqAELXyydG3YXucNzRIj s/FgARPKn09ca6dfOSkZn2k1fK4Zjd+tAgcPV3nZS398qmyNSpPzPxNxgIqxqRjt7BpT +iTg== 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=Esb5S7q71D+yRj6wekjXgI/zh0eu3jmxEnmVl03bITA=; b=WRQ8kssUxeowsCVNBPU/NQ6o6KMPo1M6SO3UYyvx3pdgDMGwG7yqBBBCzwcygxpfkw iL+kB4+aebHWpLOdNY11XRQZCzHPaNB374rjuo/yKbcymJivbkpvl0Mx6kUaNHHwBIQ1 I7ERJGTVTYOKL0TkEULc27KtqkKTXnvjhaipR3wa9UlKVrSJpUJr73KF6aLpS2ezbgWL bBA/mEzMMEToaK/7LFmyEZZRmpOnPrneepRMxmNEW3lSs9RBbCd8rE9TCAB4lSbbKJ4H w23FSYHa0TSQUTh8AgPZaHUeuL7uJ+pg6Y5OaxR6uV457LIDEj5tCqdPRKtCpKSS0CTG Ek/w== X-Gm-Message-State: AGi0PubGqsIGhH7ytt85AzeUZNQ0sFPrSPtxGIkpptsdgLXTzW1m/W8t bkVRSn7niUJBNPLBnYWqXdqJaVY9/eUDMGtWXY55vQ== X-Google-Smtp-Source: APiQypIKgn5muQ8AzOnhBFHZDBIWvnjv76B3rrs9JRX68jEQTGTp+uJnnCl3dikqJ2cVKAfWaMTkQZlaCzuVmf2kL88= X-Received: by 2002:a19:ad4c:: with SMTP id s12mr8924932lfd.109.1585591979882; Mon, 30 Mar 2020 11:12:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 30 Mar 2020 11:12:23 -0700 Message-ID: To: Brian Campbell Cc: secdispatch-chairs@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000b8685d05a2166610" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:13:06 -0000 --000000000000b8685d05a2166610 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 10:38 AM Brian Campbell wrote: > > Thanks for the review and feedback, Eric. My attempts at answers/responses > are inline below. > > On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla wrote: > >> >> Overall, I agree that something like this is needed. However, >> I have two concerns about the mechanism described here. >> >> First, as you note in S B.1., if the header is not properly >> sanitized, there is a trivial attack and there are stronger >> mechanism that do not require sanitization: >> >> "Client-Cert" header that would appear to the backend to have come >> from the reverse proxy. Although numerous other methods of >> detecting/preventing header injection are possible; such as the use >> of a unique secret value as part of the header name or value or the >> application of a signature, HMAC, or AEAD, there is no common general >> standardized mechanism. The potential problem of client header >> injection is not at all unique to the functionality of this draft and >> it would therefor be inappropriate for this draft to define a one-off >> solution. In the absence of a generic standardized solution existing >> currently, stripping/sanitizing the headers is the de facto means of >> protecting against header injection in practice today. Sanitizing >> >> This seems like an odd argument to make: if a strong mechanism is >> in order, we should design one and make it generic, not just throw >> and continue to use weaker mechanisms. >> > > Ironically, that text was written (at least in part) in an attempt to head > off having this very argument with you. We (you and I specifically) have > been down this road before discussing essentially the same issue with > respect to (the now defunct for unrelated reasons) > https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure > didn't seem to be be sufficient appetite to work on a generic solution. > Well, I don't know why you think that I would have found it more persuasive this time around. Maybe that's changed and there is more of an appetite now? Maybe. There was > some talk at the secdispatch session of the prospect of spinning up or > splitting off a WG to work on reverse proxy stuff. But a lot more than talk > is needed and I maintain that, in the absence of something generic being > defined and widely available, the de facto is sufficiently good and > appropriate for a document/draft like this. > Well, if what you want is a code point registration for something that's de facto, then sure, but if you want to have an IETF PS, then the solution should reflect what we ordinarily consider to be best practice. > >> >> Second, I think it's quite unwise to only pass the EE cert. This >> means that the server will be unable to independently evaluate >> the cert chain, which (1) is unduly restrictive on the architecture >> because it forces the proxy to do it and (2) means that there >> is no backstop in the case where the proxy makes errors or >> has a not-very-good validator. You should pass the whole chain. >> > > Passing the end-entity cert vs. including intermediates or the whole chain > is something that's up for discussion should this document find a home > where it can be worked on and progressed. As with most things, there are > tradeoffs involved. > > What you describe as unduly restrictive, however, could also be viewed as > properly constraining different components to doing the most appropriate > functionality. The backend server doing the validation would mean it has to > evaluate the cert chain on every request (which is likely prohibitively > expensive with multiple public key opperations) and/or have some > complicated caching. And allowing either piece to do the validation could > also increase the likelihood that things are set up such that neither > actually does it. > ISTM that we have quite a bit of experience with MITM proxies (a slightly different setting) and the quality of checking varies wildly, so I would prefer to leave the origin server with the ability to do this work. > > >> This also implies that you should have a way to pass extensions >> such as SCTs and stapled OCSP responses. >> > > I was under the (maybe naive) impression that such things were largely or > even exclusively for the server side and not applicable or defined for the > client side? > That's the situation now, but it might not be in the future. > > >> >> Finally, two points about TLS integration. >> >> 1. You should define how this works in the case of resumption >> of a connection that had client auth. Should the proxy attach the >> chain from the original connection? >> > > Is such a resumed connection still considered to be client authenticated? > I thought so and thus my assumption/expectation was that yes the proxy > would attach the chain from the original connection. Is that problematic > for some reason? Or are you just saying that it needs to be stated > explicitly in the document? > I'm saying that it needs to be in the document. > >> >> 2. How do you handle post-handshake client authentication? Specifically: >> (a) How do you handle the situation in which part of the HTTP >> request is covered by the client cert? >> >> (b) Post-handshake client authentication allows for the client >> to authenticate with multiple certificates one after the other. >> How is this propagated to the server? >> > > I'd been thinking that post-handshake authentication and renegotiation > were forbidden so these questions were out of scope. But I guess that only > applies to HTTP/2? > I'm not aware of any restriction on post-handshake auth for H2 (H2 was designed before TLS 1.3). -Ekr > So, off-the-cuff I'd say that for (a) the header is only passed on > requests that are covered in full by the cert. But that pragmatically it's > super difficult or impossible with the APIs in the average environment to > figure out what application data came before or after the cert auth and so > it'll end up being however a particular proxy implementation treats this > situation currently but just with a standard header. For (b) I'd say only > propagate the most recent one. > > Having given my half-assed answers though, I'd welcome input if you think > there are better answers. > > > > >> >> On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell > 40pingidentity.com@dmarc.ietf.org> wrote: >> >>> Hello SecDispatchers and Chairs thereof, >>> >>> I'd like to request some time on the agenda in Vancouver to present on >>> https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ >>> in an effort to gauge interest and potentially find an appropriate venue >>> for the work to proceed (or just put it and its ridiculously long title out >>> of its misery). >>> >>> Client-Cert HTTP Header: Conveying Client Certificate Information from >>> TLS Terminating Reverse Proxies to Origin Server Applications >>> >>> Abstract >>> >>> This document defines the HTTP header field "Client-Cert" that allows >>> a TLS terminating reverse proxy to convey information about the >>> client certificate of a mutually-authenticated TLS connection to an >>> origin server in a common and predictable manner. >>> >>> Discussion around the value of having something like this defined >>> happened in the OAuth WG a bit before the Singapore meeting (no doubt >>> that's not the only time but it's the one in which I was involved recently) >>> and an AD nudged me to secdispatch - >>> https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ >>> falls somewhere in the middle of that long and sometimes contentious >>> thread. I was unable to get a draft published prior to the I-D submission >>> cut-off for Singapore and got a short "if time allows" presentation slot at >>> the meeting. The judgment coming out of that meeting was "needs draft". >>> >>> I did get an actual draft published a bit after Singapore (the one with >>> the ridiculously long title previously mentioned) and there's been some, if >>> not exactly an overwhelming amount of, discussion and support of it on this >>> very list: >>> https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22 >>> >>> Thanks. >>> Brian Campbell >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited.. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >>> _______________________________________________ >>> Secdispatch mailing list >>> Secdispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdispatch >>> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --000000000000b8685d05a2166610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 30, 2020 at 10:38 AM Bria= n Campbell <bcampbell@ping= identity.com> wrote:

Thanks for the review and feedback, Eric. My attempts at answers/respons= es are inline below.

On Fri, Mar 27, 2020 at 11:= 22 AM Eric Rescorla <e= kr@rtfm.com> wrote:

Overall, I agree that something like this i= s needed. However,
I have two concerns about the mechanism described her= e.

First, as you note in S B.1., if the header is not properly
sa= nitized, there is a trivial attack and there are stronger
mechanism that= do not require sanitization:

=C2=A0 =C2=A0"Client-Cert" h= eader that would appear to the backend to have come
=C2=A0 =C2=A0from th= e reverse proxy.=C2=A0 Although numerous other methods of
=C2=A0 =C2=A0d= etecting/preventing header injection are possible; such as the use
=C2= =A0 =C2=A0of a unique secret value as part of the header name or value or t= he
=C2=A0 =C2=A0application of a signature, HMAC, or AEAD, there is no c= ommon general
=C2=A0 =C2=A0standardized mechanism.=C2=A0 The potential p= roblem of client header
=C2=A0 =C2=A0injection is not at all unique to t= he functionality of this draft and
=C2=A0 =C2=A0it would therefor be ina= ppropriate for this draft to define a one-off
=C2=A0 =C2=A0solution.=C2= =A0 In the absence of a generic standardized solution existing
=C2=A0 = =C2=A0currently, stripping/sanitizing the headers is the de facto means of<= br>=C2=A0 =C2=A0protecting against header injection in practice today.=C2= =A0 Sanitizing

This seems like an odd argument to make: if a strong = mechanism is
in order, we should design one and make it generic, not jus= t throw
and continue to use weaker mechanisms.

Ironically, that text was written (at least in part) in an= attempt to head off having this very argument with you. We (you and I spec= ifically) have been down this road before discussing essentially the same i= ssue with respect to (the now defunct for unrelated reasons) h= ttps://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure= didn't seem to be be sufficient appetite to work on a generic solution= .

Well, I don'= t know why you think that I would have found it more persuasive this time a= round.


Maybe that's changed and there is more of an appetite now? = Maybe. There was some talk at the secdispatch session of the prospect of sp= inning up or splitting off a WG to work on reverse proxy stuff. But a lot m= ore than talk is needed and I maintain that, in the absence of something ge= neric being defined and widely available, the de facto is sufficiently good= and appropriate for a document/draft like this.=C2=A0

Well, if what you want is a code p= oint registration for something that's de facto, then sure, but if you = want to have an IETF PS, then the solution should reflect what we ordinaril= y consider to be best practice.


=C2=A0

Second, I think it= 9;s quite unwise to only pass the EE cert. This
means that the server wi= ll be unable to independently evaluate
the cert chain, which (1) is undu= ly restrictive on the architecture
because it forces the proxy to do it = and (2) means that there
is no backstop in the case where the proxy make= s errors or
has a not-very-good validator. You should pass the whole cha= in.

Passing the end-entity cert v= s. including intermediates or the whole chain is something that's up fo= r discussion should this document find a home where it can be worked on and= progressed. As with most things, there are tradeoffs involved.
<= div>
What you describe as unduly restrictive, however, could = also be viewed as properly constraining different components to doing the m= ost appropriate functionality. The backend server doing the validation woul= d mean it has to evaluate the cert chain on every request (which is likely = prohibitively expensive with multiple public key opperations) and/or have s= ome complicated caching. And allowing either piece to do the validation cou= ld also increase the likelihood that things are set up such that neither ac= tually does it.

ISTM that we have quite a bit of experience with MITM proxies (a slightly= different setting) and the quality of checking varies wildly, so I would p= refer to leave the origin server with the ability to do this work.

<= div>
=C2=A0
This also implies that you should have a way to pass= extensions
such as SCTs and stapled OCSP responses.

I was under the (maybe naive) impression that such t= hings were largely or even exclusively for the server side and not applicab= le or defined for the client side?

That's the situation now, but it might not be in the fu= ture.


= =C2=A0

Finally, two points about TLS integration.

1. You should def= ine how this works in the case of resumption
of a connection that had cl= ient auth. Should the proxy attach the
chain from the original connectio= n?

Is such a resumed connection s= till considered to be client authenticated? I thought so and thus my assump= tion/expectation was that yes the proxy would attach the chain from the ori= ginal connection. Is that problematic for some reason? Or are you just sayi= ng that it needs to be stated explicitly in the document?

I'm saying that it needs to = be in the document.=C2=A0

=C2=A0
<= div dir=3D"ltr">
2. How do you handle post-handshake client authenticati= on? Specifically:
(a) How do you handle the situation in which part of t= he HTTP
request is covered by the client cert?

(b) Post-handshake= client authentication allows for the client
to authenticate with multip= le certificates one after the other.
How is this propagated to the serve= r?

I'd been thinking that pos= t-handshake authentication and renegotiation were forbidden so these questi= ons were out of scope. But I guess that only applies to HTTP/2?

I'm not aware of any r= estriction on post-handshake auth for H2 (H2 was designed before TLS 1.3).<= /div>

-Ekr


So, off-the-cuff I'd say that= for (a) the header is only passed on requests that are covered in full by = the cert. But that pragmatically it's super difficult or impossible wit= h the APIs in the average environment to figure out what application data c= ame before or after the cert auth and so it'll end up being however a p= articular proxy implementation treats this situation currently but just wit= h a standard header. For (b) I'd say only propagate the most recent on= e.

Having given my half-assed answers though,= I'd welcome input if you think there are better answers.
=C2=A0

=C2=A0

On Mon, Mar 2, 2020 at 1:51 PM Br= ian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
=
Hello SecDispatchers and Chairs thereof,

I= 9;d like to request some time on the agenda in Vancouver to present on https://datatracker.ietf.org/doc/draft-bdc-some= thing-something-certificate/ in an effort to gauge interest and potenti= ally find an appropriate venue for the work to proceed (or just put it and = its ridiculously long title out of its misery).

Client-Cert HTTP H= eader: Conveying Client Certificate Information from
=C2=A0 =C2=A0 =C2= =A0TLS Terminating Reverse Proxies to Origin Server Applications

Abstra= ct

=C2=A0 =C2=A0This document defines the HTTP header field "Cl= ient-Cert" that allows
=C2=A0 =C2=A0a TLS terminating reverse proxy= to convey information about the
=C2=A0 =C2=A0client certificate of a mu= tually-authenticated TLS connection to an
=C2=A0 =C2=A0origin server in = a common and predictable manner.

Discussion around= the value of having something like this defined happened in the OAuth WG a= bit before the Singapore meeting (no doubt that's not the only time bu= t it's the one in which I was involved recently) and an AD nudged me to= secdispatch - https://mailarchive.ietf.org/arc= h/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ falls somewhere in the middle = of that long and sometimes contentious thread. I was unable to get a draft = published prior to the I-D submission cut-off for Singapore and got a short= "if time allows" presentation slot at the meeting. The judgment = coming out of that meeting was "needs draft".

=
I did get an actual draft published a bit after Singapore (the o= ne with the ridiculously long title previously mentioned) and there's b= een some, if not exactly an overwhelming amount of, discussion and support = of it on this very list: h= ttps://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-something-somethi= ng-certificate%22

Thanks.
Brian Camp= bell




=





=

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you. --000000000000b8685d05a2166610-- From nobody Mon Mar 30 11:17:21 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219653A0D93; Mon, 30 Mar 2020 11:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u6i_RUom9_L; Mon, 30 Mar 2020 11:17:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 DD8593A0D8E; Mon, 30 Mar 2020 11:17:18 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UIE23a005479; Mon, 30 Mar 2020 19:16:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=/Y+jVDae3G1+SyVTwv3E0no2LXrq2BhyaDxj04QEedU=; b=ncvY+uiYWTc/5vEJrA/Z2O1Bdh0hVKfIXHcJRyXpIjAW2ADnQ0NhGBKooOVjDsY3/7gg PfTV3p6bphEjNo+6dxQOr4cMH7psx0UZMWew9J0dLcaMjfkXtJU257f9h5rDieS8cBrM /0kqE8BpLtgAarwFJ5vpwqynPNgDrn/tSeQ0TP3PjSYLWaW5n6/nIvI6sunGCxCnReJ8 DKlHtz1X5WIhEaHQ6BiExZwgfssdCTAhTz2SVtf3lPUWx0gx1kiWs2PKP/E67Dz8zlUm AgeQ2cHhDqRF36siRit7hDQ638XrqMnvGxwW34WKKxxKdmxDJC8alnVe0QGIkiJibqCr 7w== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 301ygp9g1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 19:16:18 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02UHli8g007198; Mon, 30 Mar 2020 14:16:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint7.akamai.com with ESMTP id 3028d8f4na-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 14:16:17 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 13:16:16 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Mon, 30 Mar 2020 13:16:11 -0500 From: "Salz, Rich" To: Eric Rescorla , Brian Campbell CC: IETF SecDispatch , "secdispatch-chairs@ietf.org" Thread-Topic: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header Thread-Index: AQHWBFxLVTcxakOIMk25J8Uizezb5ahhvuSAgAAJuYD//74HgA== Date: Mon, 30 Mar 2020 18:16:11 +0000 Message-ID: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: multipart/alternative; boundary="_000_7FE4FEF8AA3044D8BED82578B307FCD4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003300155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 impostorscore=0 suspectscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300155 Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:17:20 -0000 --_000_7FE4FEF8AA3044D8BED82578B307FCD4akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQuIEEgc3RhbmRhcmRpemVkIHBsYWNlIGZvciBhIFRMUy10 ZXJtaW5hdGluZyBpbnRlcm1lZGlhcnkgdG8gcHJlc2VudCB0aGUgY2VydGlmaWNhdGUgdG8gYW4g b3JpZ2luIGlzIGEgZ29vZCB0aGluZy4gIEl0IHdpbGwgbWFrZSBDRE4gY3VzdG9tZXJzIG1vcmUg cG9ydGFibGUuDQoNCk1heWJlIHRoaXMgaXMgYSBwb2ludCBzb2x1dGlvbiB0aGF0IG1vc3Qgb2Yg dGhlIEludGVybmV0IGRvZXNu4oCZdCBjYXJlIGFib3V0LiAgQnV0IG1lYXN1cmFibGUgcG9ydGlv biBzaG91bGQgY2FyZSBhbmQgd291bGQgYmVuZWZpdC4NCg== --_000_7FE4FEF8AA3044D8BED82578B307FCD4akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgdGhpcyBkb2N1bWVudC4g QSBzdGFuZGFyZGl6ZWQgcGxhY2UgZm9yIGEgVExTLXRlcm1pbmF0aW5nIGludGVybWVkaWFyeSB0 byBwcmVzZW50IHRoZSBjZXJ0aWZpY2F0ZSB0byBhbiBvcmlnaW4gaXMgYSBnb29kIHRoaW5nLiZu YnNwOyBJdCB3aWxsIG1ha2UgQ0ROIGN1c3RvbWVycyBtb3JlIHBvcnRhYmxlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXliZSB0aGlzIGlzIGEgcG9pbnQgc29sdXRpb24gdGhhdCBtb3N0IG9m IHRoZSBJbnRlcm5ldCBkb2VzbuKAmXQgY2FyZSBhYm91dC4mbmJzcDsgQnV0IG1lYXN1cmFibGUg cG9ydGlvbiBzaG91bGQgY2FyZSBhbmQgd291bGQgYmVuZWZpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7FE4FEF8AA3044D8BED82578B307FCD4akamaicom_-- From nobody Mon Mar 30 11:21:55 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18D23A07A5 for ; Mon, 30 Mar 2020 11:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8IMvCAG-xG6 for ; Mon, 30 Mar 2020 11:21:51 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317193A0DA4 for ; Mon, 30 Mar 2020 11:21:51 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id i20so19186045ljn.6 for ; Mon, 30 Mar 2020 11:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pg8XeBehl66pgQ07Vw1Pc1X2Rik8d6rNDSbcqvH+OM4=; b=Mzb9F+rt7D2rqhIxHNvDKT/iOTnfL9mU5+zeplTOx1B1y4CfGFgTDIvVQosI3bxm8W Q5YA2UN7w0CSGBjRZ4j594KLBm4I9B3hEAj4cVhjDd2WA8Y+vJpmF2KKfSmeZ9Iz5hIp i0utb0UkBxuHa0GcF5foevptRSP+JZHraMtdXXaFaggYWB6aHTFMCglrFgAifUt0YBfa bI3ozUsy3LCmq9parLl87E33x+AjArTpF3u+BwFRiERyiEjpop0n5LlF8Jql5HbpWFPG QuzYoznV7mguwyNF3hmm1fcQXqNLMeT7WW12TnEfPJs1jyBrH/C4k0e9JeTZRQXM9hW3 YmNg== 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=Pg8XeBehl66pgQ07Vw1Pc1X2Rik8d6rNDSbcqvH+OM4=; b=RXVlqr4QuX3iN9rNSJb6A+UuHK0NBOe48mK6fg05jVxt5zOz73QnPt08c7rp2RRnHS fzVMoBmg6opAS9bL7ChhTKl2gkf4Vaup92zVCuCc2KUFoaKUvWKSobXPw7DgbHHW5maP CMtC5ykSBbag+Lpt80gfopgxZvEW5opZdTg+PZ3JBfxfPoNmMRx2qs9mi4f+r29cN/3A d/xVUkGlgE2f1cT5KtwpYaM86W0qI//XD3UjX7ZsDDU7W7dIcusC94BXciEDkms0aVkW P5SNf28BWpMNjxPDYWbYKcFKPLEYJnznnE984kg6ds0ZhoWzdcoGNixyLfHwaCw5zaGA BPNg== X-Gm-Message-State: AGi0PubZOYvf4RUea2eJzFL8So8HD2CVh0B2djcEa/rI2K75U8lTsght uk0OfN73khyjC2Lycnpu0CYRsdDIl6ivwCnj3PVVeg== X-Google-Smtp-Source: APiQypJP5oaUJEv4YYfN9tM+fAsa4EE5B+TNRwPZXoJvUtEVZIoWv7wxzONJMRtAfWhsuo6iTvxTHUqNkERF/Vmo27w= X-Received: by 2002:a2e:780a:: with SMTP id t10mr8223374ljc.83.1585592509256; Mon, 30 Mar 2020 11:21:49 -0700 (PDT) MIME-Version: 1.0 References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> In-Reply-To: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> From: Eric Rescorla Date: Mon, 30 Mar 2020 11:21:13 -0700 Message-ID: To: "Salz, Rich" Cc: Brian Campbell , IETF SecDispatch , "secdispatch-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004631c205a21686be" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:21:54 -0000 --0000000000004631c205a21686be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not arguing that we shouldn't do this work; I'm saying that if we are to publish it as a PS, then we should not do something we know to be very brittle. -Ekr On Mon, Mar 30, 2020 at 11:17 AM Salz, Rich wrote: > I support this document. A standardized place for a TLS-terminating > intermediary to present the certificate to an origin is a good thing. It > will make CDN customers more portable. > > > > Maybe this is a point solution that most of the Internet doesn=E2=80=99t = care > about. But measurable portion should care and would benefit. > --0000000000004631c205a21686be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not arguing that we shouldn't do this wor= k; I'm saying that if we are to publish it as a PS, then we should not = do something we know to be very brittle.

-Ekr


On Mon, Mar 30, 2020 at 11:17 AM Salz, Rich <rsalz@akamai.com> wrote:

I support this document. A standardized place for a = TLS-terminating intermediary to present the certificate to an origin is a g= ood thing.=C2=A0 It will make CDN customers more portable.

=C2=A0

Maybe this is a point solution that most of the Inte= rnet doesn=E2=80=99t care about.=C2=A0 But measurable portion should care a= nd would benefit.

--0000000000004631c205a21686be-- From nobody Mon Mar 30 11:25:47 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476F43A0DBF; Mon, 30 Mar 2020 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwDdErnbfBAn; Mon, 30 Mar 2020 11:25:44 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A744E3A0DB9; Mon, 30 Mar 2020 11:25:44 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UIEpnU024443; Mon, 30 Mar 2020 19:25:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ksd0ZcyeeuuKmqHxiPySCtDHzWi5FbGBxC3J+fi78rQ=; b=SZcVlA+gOHaHuveO8U9gdfKwnlQgedqQ4ygdVLIdtPgK3EFQ8qdzbbj92TtE89xA8xBW /vOlsdKwNZQBt/YtA+DGI8HWbQ+tvCOu/BdVnYy6fVi0aCLLr2XmbM0HevKF9ozOCgUU E1gxyMgmtKVQ3ndY9wVuT6GbhlrXK9MzWDQbDFzTL2RGJSr/LoHLSdo60Dx9PVnJXh1D 56fneXtCz2eVguhW+W4Thy0iHfVTOsutJ2CDrDCWKNSMHJGLga5DpoudX9689E2uHEnH a/CRz631USkDB/EpRdoDP4Lz1U6ygOeKdFD66N9lWVgxGA2lgEV7DeQSUzVgDYagFKhe Tg== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 301vay9h2q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 19:25:43 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02UIGjmR003844; Mon, 30 Mar 2020 14:25:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint4.akamai.com with ESMTP id 3028dk29wh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 14:25:42 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 11:25:42 -0700 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Mon, 30 Mar 2020 13:25:37 -0500 From: "Salz, Rich" To: Eric Rescorla CC: Brian Campbell , IETF SecDispatch , "secdispatch-chairs@ietf.org" Thread-Topic: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header Thread-Index: AQHWBFxLVTcxakOIMk25J8Uizezb5ahhvuSAgAAJuYD//74HgIAARHGA//++MAA= Date: Mon, 30 Mar 2020 18:25:36 +0000 Message-ID: <15394FED-64E0-4C38-8CAC-E0ACC9614B73@akamai.com> References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: multipart/alternative; boundary="_000_15394FED64E04C388CACE0ACC9614B73akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003300156 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 phishscore=0 mlxscore=0 priorityscore=1501 spamscore=0 clxscore=1015 mlxlogscore=967 lowpriorityscore=0 impostorscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300156 Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:25:46 -0000 --_000_15394FED64E04C388CACE0ACC9614B73akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSdtIG5vdCBhcmd1aW5nIHRoYXQgd2Ugc2hvdWxkbid0IGRvIHRoaXMgd29yazsgSSdt IHNheWluZyB0aGF0IGlmIHdlIGFyZSB0byBwdWJsaXNoIGl0IGFzIGEgUFMsIHRoZW4gd2Ugc2hv dWxkIG5vdCBkbyBzb21ldGhpbmcgd2Uga25vdyB0byBiZSB2ZXJ5IGJyaXR0bGUuDQoNCkkgYW0g bm90IHN1cmUgaXTigJlzIGJyaXR0bGUuICBCdXQgdGhhdCBpcyBzb21ldGhpbmcgZm9yIHRoZSBX RyB0byBkaXNjdXNzLiAgVGhlIGludGVybWVkaWFyeSBpcyBhbHJlYWR5IGFzc2VydGluZyBhbGwg c29ydCBvZiB0aGluZ3MgYWJvdXQgdGhlIGNsaWVudCA6KQ0K --_000_15394FED64E04C388CACE0ACC9614B73akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <685B94C6AEB0924F8B6E8B277A7E31F5@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODYw Nzk5NzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03 MTI1NzcwMTAgNjYwMzYwMzg0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tYmlkaS1mb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tYmlkaS1mb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0K PGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj5JJ20gbm90IGFyZ3VpbmcgdGhhdCB3ZSBzaG91bGRuJ3QgZG8gdGhpcyB3b3Jr OyBJJ20gc2F5aW5nIHRoYXQgaWYgd2UgYXJlIHRvIHB1Ymxpc2ggaXQgYXMgYSBQUywgdGhlbiB3 ZSBzaG91bGQgbm90IGRvIHNvbWV0aGluZyB3ZSBrbm93IHRvIGJlIHZlcnkgYnJpdHRsZS48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3VyZSBp dOKAmXMgYnJpdHRsZS4mbmJzcDsgQnV0IHRoYXQgaXMgc29tZXRoaW5nIGZvciB0aGUgV0cgdG8g ZGlzY3Vzcy4mbmJzcDsgVGhlIGludGVybWVkaWFyeSBpcyBhbHJlYWR5IGFzc2VydGluZyBhbGwg c29ydCBvZiB0aGluZ3MgYWJvdXQgdGhlIGNsaWVudCA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_15394FED64E04C388CACE0ACC9614B73akamaicom_-- From nobody Mon Mar 30 12:42:57 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323D43A0FC5 for ; Mon, 30 Mar 2020 12:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfuxTDhYT1Hu for ; Mon, 30 Mar 2020 12:42:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79AD3A0FDC for ; Mon, 30 Mar 2020 12:42:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E748F3897A; Mon, 30 Mar 2020 15:41:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 742B1451; Mon, 30 Mar 2020 15:42:48 -0400 (EDT) From: Michael Richardson To: "Salz\, Rich" cc: IETF SecDispatch In-Reply-To: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 19:42:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Salz, Rich wrote: > I support this document. A standardized place for a TLS-terminating > intermediary to present the certificate to an origin is a good thing. > It will make CDN customers more portable. > Maybe this is a point solution that most of the Internet doesn=E2=80= =99t care > about. But measurable portion should care and would benefit. Do you want a new WG, HTTPBIS, the proposed HTTPSBIS-offshoot, TLS, or ??? I concur with how important it is. Is there an email chain about the HTTPSBIS offshoot, btw? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6CS7gACgkQgItw+93Q 3WW+zAgAhft7uTDVoXzzzbCZ9s8p0YVv1IjpAcgPbyA0ySkLSn4oMYrgWyMZb1Gi AWd3tKiaGPYloAhuK827EBTXzJFYTzK6GyzMjmIz0444xIQotawTO75SrR4ur3v7 pAzRXgzbGz1xPGA4sh90r1Gp6XSNHLYku/3G2hSqciKqRRDbNfI5ltLi6Ah8dRM9 aU7nTpCAEBdIt+UbtadF8qfC19nXp01w0XahI8GJyat37euypAJLh1tf0vehtB8a gRwSuk4PvZIemrtKZMDYrLBHK/blRq4pzLWvOJJULS5YFyhIpkblZ63kq+IQjQG0 HsDTUT884I+LqoaLvljlerAagKUFXg== =rVjL -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 30 12:49:30 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86383A0FF4 for ; Mon, 30 Mar 2020 12:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj3QxMZVzwkL for ; Mon, 30 Mar 2020 12:49:27 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3B53A0FF8 for ; Mon, 30 Mar 2020 12:49:15 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id s13so4116773lfb.9 for ; Mon, 30 Mar 2020 12:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4GnJxlml83JFLEhNqfQ41XdUJHj/AzyJ4azva9AyM90=; b=VEVprbXAndpTkHo0S8ss+MPmx35FFQtfmz6pC9gQJ61WTUTeh8LYm6gZkprJS4TTHd xHfnMMUPyf9M3FSq5l4aKIY/rv/bUa3hE+S/TShRM1jCipHCXEyScw2SFui3CaknF4ZS 13ON7+2bGNPNg+ycpndd4fm+TD0uHMJDoNDwiSU+BuO/6bp+uUEgP84vGCSrpArBvoaL XA47GFNu8LcLHjVMEAjnWAiiPZagxxBhjy12hB95qf5nP7oeJr3HKhUJE1IBLxAapja9 odtZ3x1/xAPIRuJo56dcQ+592r/R3bI+f7bYjq8XkTmlenPyWAap4Bi3fCEcq7DVQag9 2phQ== 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=4GnJxlml83JFLEhNqfQ41XdUJHj/AzyJ4azva9AyM90=; b=te7V7qalM6Pa2dnPpF3iJAIEQaFLoRd11bgxvUknbTSX4Z+GZRWdvSHhfR8Dw2rb9b v1rOsbbyUSPkV7noZ8W3eczJgS+HYVuPzpSSbEF+HIS5Kx5SJqinazkD2G7YbS7tfFMG d/c59fVuCPplbAL087hOASgMgHQaPM9y3jRr+W+Sdo5yjDipXRaoRg7rPt2ABZkmqSU1 rixcKs2LdF/lJlXgLgfDcHCHLV8KTFEjrRlQRpPjWF/8c2MHAFBLPHHrRaOa0ciwTmoR WA/nfokTrdXIhfl5Ln2sCMTN20Cc4AsfxmQtpAOtMDSH5/M8FEPAKVQkEIao51I3RF74 lhEw== X-Gm-Message-State: AGi0PuZwFne3hz55OG/YDZqikbxMld+YZuWRuE+ZtM/SsfF+eGr5FxKS HiSeKXyjMnTLsoTteXmIfP2/SscXv/85nTaNvFd4ZA== X-Google-Smtp-Source: APiQypKUrZfo73D8cHpnKjkswDDsqDWQ1d7WTZXnOiU5oG1PdyolNXLltgzIB+XgR2cyCfHl9P9y9gFH8Jx+/tJJ1TA= X-Received: by 2002:a19:4b4d:: with SMTP id y74mr8949978lfa.161.1585597753096; Mon, 30 Mar 2020 12:49:13 -0700 (PDT) MIME-Version: 1.0 References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> <10060.1585597368@localhost> In-Reply-To: <10060.1585597368@localhost> From: Eric Rescorla Date: Mon, 30 Mar 2020 12:48:36 -0700 Message-ID: To: Michael Richardson Cc: "Salz, Rich" , IETF SecDispatch Content-Type: multipart/alternative; boundary="000000000000d4a45a05a217be7c" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 19:49:29 -0000 --000000000000d4a45a05a217be7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do not believe this should be in TLS, as it is not a change to the TLS protocol. I do, however, believe that the TLS WG should be consulted because of the types of technical issues I raised in my review. -Ekr On Mon, Mar 30, 2020 at 12:43 PM Michael Richardson wrote: > > Salz, Rich wrote: > > I support this document. A standardized place for a TLS-terminating > > intermediary to present the certificate to an origin is a good thin= g. > > It will make CDN customers more portable. > > > Maybe this is a point solution that most of the Internet doesn=E2= =80=99t care > > about. But measurable portion should care and would benefit. > > Do you want a new WG, HTTPBIS, the proposed HTTPSBIS-offshoot, TLS, or ??= ? > > I concur with how important it is. > Is there an email chain about the HTTPSBIS offshoot, btw? > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --000000000000d4a45a05a217be7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not believe this should be in TLS, as it is not = a change to the TLS protocol. I do, however, believe that the TLS WG should= be consulted because of the types of technical issues I raised in my revie= w.

-Ekr


On Mon, Mar 30, 20= 20 at 12:43 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 > I support this document. A standardized place for a TLS-= terminating
=C2=A0 =C2=A0 > intermediary to present the certificate to an origin is = a good thing.
=C2=A0 =C2=A0 > It will make CDN customers more portable.

=C2=A0 =C2=A0 > Maybe this is a point solution that most of the Internet= doesn=E2=80=99t care
=C2=A0 =C2=A0 > about.=C2=A0 But measurable portion should care and woul= d benefit.

Do you want a new WG, HTTPBIS, the proposed HTTPSBIS-offshoot, TLS, or ???<= br>
I concur with how important it is.
Is there an email chain about the HTTPSBIS offshoot, btw?

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



_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch
--000000000000d4a45a05a217be7c-- From nobody Mon Mar 30 12:52:03 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7673A103C for ; Mon, 30 Mar 2020 12:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ3SoJNr1jEH for ; Mon, 30 Mar 2020 12:52:00 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C633A1023 for ; Mon, 30 Mar 2020 12:52:00 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 02UJpmem030007; Mon, 30 Mar 2020 20:51:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PrTByMC+QsmyOY4yYwRI7sraGqIfKDlHPmgLcEPm9D0=; b=JxFZHkLoOX9lbu/MG68P0tGqODMuD/PErk1A4tM4xy6uP3qVUX9faVVrW9FA6R6M+DRb sPGnPwsv2uTKLZ+2mDrnJLywqDSkn6pTvmjeyIE8ql1D0Nwxs62Q21VJdCcMCqNsIPeT GFa9G8Ktmb9bwZnR2TdniLRBAD0DyjgnPHgpBwVwIDhQhauBIyFh6UELscopMoY7zQBT RdNbCIshmfT66qrpNF4SSGyJV9fA1GWUuCvk7a3wzR+poUuRva63g0zcuFQSLSE99GLR +q3+b4PeUX+QO4RxVjR9/5OXcBoM+E6ETX8SBJbBzQ7tknAA7wvx+x9xU26N7sijbElb rA== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 301vhht7xf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 20:51:57 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02UJlIVW007690; Mon, 30 Mar 2020 15:51:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 3028dj7b2m-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 15:51:56 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 14:51:55 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Mon, 30 Mar 2020 14:51:50 -0500 From: "Salz, Rich" To: Michael Richardson , "Salz, Rich" CC: IETF SecDispatch Thread-Topic: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header Thread-Index: AQHWBFxLVTcxakOIMk25J8Uizezb5ahhvuSAgAAJuYD//74HgIAAWz0A//+/fAA= Date: Mon, 30 Mar 2020 19:51:50 +0000 Message-ID: <63BA2CBA-493F-4F7E-A99F-D6238A384CDC@akamai.com> References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> <10060.1585597368@localhost> In-Reply-To: <10060.1585597368@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: text/plain; charset="utf-8" Content-ID: <72E61BA91BC53F4C9029BA90D8C7E9F6@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=840 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003300168 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=824 phishscore=0 mlxscore=0 impostorscore=0 spamscore=0 bulkscore=0 malwarescore=0 adultscore=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300168 Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 19:52:02 -0000 SXQgYmVsb25nIHdpdGggSFRUUCwgSSBkb24ndCBjYXJlIHdoZXJlLg0KIA0KDQo= From nobody Mon Mar 30 13:37:43 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF43A109E for ; Mon, 30 Mar 2020 13:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v85FPlbwDGlf for ; Mon, 30 Mar 2020 13:37:40 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308C23A10B8 for ; Mon, 30 Mar 2020 13:37:13 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n17so19633712lji.8 for ; Mon, 30 Mar 2020 13:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ifHiOdNWRBWq2sLTvujDkjzrbtvDJl+7WMnc/ilvdXk=; b=ZKRIbmWZI9yGCJK1bHxFRFOer+k9dHXXASo7jeiGAePp62UbcuOoOCx5yS/J/SDVu2 iFacMBQfJvzYyWvzuExZnVSqA+J1sGuNRCbA6h2B6ThDXcmayPok2lQ8SbpDDlqltAcB GrXV6p60TmHHN15QgIfxxQA0vdTYnuOQQESoxkUVrjF4Dau1tPMY9pTp8LPx6omLD7zG SCfs7I8cuHbNDUbYovzeQEw1ylhkG1IknYLeXsCzqX4FI/FwUIHE69lgzY8Ly3RkXO2E CXUTrmbfi34JokmxvzEHpLaVYOMB92iCrTQMeF0SbU4crqTUjjg6cbbU9fIjSHhs+wag pxyw== 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=ifHiOdNWRBWq2sLTvujDkjzrbtvDJl+7WMnc/ilvdXk=; b=KFf5FjfJk625nkB3BoAcYwYc+huQb5BK3BNTr8ink8gvsuiPvo1dRDGsKLNXqXbOQe ThxyykSfeXU+1mn8iRZuuEKA13IVIZOn+Sj3UlZid+VeIhz8f41kMMSUFDA/B2riM2Sy 76Jdf6GieIVI6xOa+gb/i/PcUcWK2Ty2TG3uPka96RpD2d8x+sG/WWv8lMybWlMO2nwc qUu7sCa0odiBh1VDjnccyoo425LVdRjCR6T1GfiL9hd28JM7NWcV3qQDEEJ7l8vLHutP bAqJLIa/MJFfvWxix6u5nKYN4m9s1xTyLEQpVQYWH7Uf+vK/zrM4VV6inBN/jWfjpYkl zt3A== X-Gm-Message-State: AGi0PuZZtH0aPBIPDxjTIDyvxS6AeSeGkEFb/4j1uNaQjrt+M9Th0T6U DJr58+3DKsZJrzyjfSIpvqBSeWBPUg1ZJWvD3kYFaja8YY7xXEMsOKLqJ9kKSJlkG4zJoyseqYQ tE+XYowNHoWrU11U7bfn1YFqV X-Google-Smtp-Source: APiQypKm+3rbfx93dvtfqfMe/xshEoOpcd1K7+vJd+Xs0iNWp13P45v9qPGiVtqmSfctV8XKk0msYyTU+G2CX1PCVbc= X-Received: by 2002:a2e:2a03:: with SMTP id q3mr8099728ljq.216.1585600631327; Mon, 30 Mar 2020 13:37:11 -0700 (PDT) MIME-Version: 1.0 References: <7FE4FEF8-AA30-44D8-BED8-2578B307FCD4@akamai.com> <10060.1585597368@localhost> <63BA2CBA-493F-4F7E-A99F-D6238A384CDC@akamai.com> In-Reply-To: <63BA2CBA-493F-4F7E-A99F-D6238A384CDC@akamai.com> From: Brian Campbell Date: Mon, 30 Mar 2020 14:36:44 -0600 Message-ID: To: "Salz, Rich" Cc: Michael Richardson , IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000062e7f205a2186aba" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 20:37:42 -0000 --00000000000062e7f205a2186aba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The outcome from SECDISPATCH last week, as I understand it, is that the next step is to take the work to the HTTPbis WG and see if there's there's sufficient interest there in taking it up. I plan to get that started soon (for some value of soon anyway). There was some discussion on mic and in jabber about spinning up or out a new WG with a focus on proxy to backend type stuff. But I don't think it rose to the level of being something actionable coming out of the meeting. On Mon, Mar 30, 2020 at 1:52 PM Salz, Rich wrote: > It belong with HTTP, I don't care where. > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000062e7f205a2186aba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The outcome from SECDISPATCH last week, as I understa= nd it, is that the next step is to take the work to the HTTPbis WG and see = if there's there's sufficient interest there in taking it up. I pla= n to get that started soon (for some value of soon anyway).
=
There was some discussion on mic and in jabber about spinnin= g up or out a new WG with a focus on proxy to backend type stuff. But I don= 't think it rose to the level of being something actionable coming out = of the meeting.

On Mon, Mar 30, 2020 at 1:52 PM Salz, Rich <rsa= lz=3D40akamai.com@dmarc.ietf= .org> wrote:
It belong with HTTP, I don't care where.


_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000062e7f205a2186aba-- From nobody Mon Mar 30 14:03:56 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B488F3A0766 for ; Mon, 30 Mar 2020 14:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0TEk7QU4KQV for ; Mon, 30 Mar 2020 14:03:51 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA03E3A0897 for ; Mon, 30 Mar 2020 14:03:27 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p10so19465862ljn.1 for ; Mon, 30 Mar 2020 14:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EMiXTm86ckd4/1kEt/YvuoPPfP8llHvaFoGHqkD71tg=; b=MP+ZMRIMVc+jVDonIObKduQyflU1iCCBehYpWO7T/AMAktkZIo7Y+yQuKQVNyYsdr3 z3mX1A5XgQuZ47LpqCNM9d4dyXvilPWKsBd3KstQJOSmmgSWMMw9yzIZhpf30keu6md1 9HI0HTG8DFlId8PmUtESWmdQYqUFc6+Qd12NgHGHnNDwCme+vE7yiMI5uaKjJQzipjYU U9ILP4e26RI2bQa0TVn5dAmaZVU4o/5tSmV3xCGse/dzcGqaMT69++RSQLMmQIr1KDZa H1yw2hn2jegZFQgMvmAuM6eWJWJotHkbyDZcGWackQVejvdx7Ao/PLs+dDF+UfBVnRRK F0Jg== 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=EMiXTm86ckd4/1kEt/YvuoPPfP8llHvaFoGHqkD71tg=; b=hO8QDmwBNzK/olGKbYi5veq/OE+6hFLITLJ0vZ2fvrUfBDTpLP903JqTurdHCU/voy j0B8cEkJqpWRZi0qZMOfRermpHQbezo4BTWDr5hgGvKJ8EqB5TOcrdXZwNRQuO5Geszv oaZzr8dQw/lXm70cIHFL2HM5g3HUf+EmU+wKPJsXNurgvgtS618nh3ZZHLNJiTe56MNE GLf3L/Ji3FvD87mdj4w2WaoyabC5gCs7+u5dDLRtcFqLvB+GA652zLqfIGbXTqutDLQ8 6SAlDWBQVMq92AXejH/8w7JbaPk4c0+hWLGSwz+sb6MFu6nOP+pQd+eJeF8PicRswyig uEQw== X-Gm-Message-State: AGi0Pua9fVbEUBIiyzRVh97AmQTAaDcAarc3wJ1rw8IIhnNkax+tDgkY Qd6RNCv/CiMVlqVUAIvP1ekd3QFjTO5QwrafRCnAEvA1V3AyuufBoOmcibjcZB2EfPWvYzySOIP +mx4O0KNbdlOrjNPk029Z3w== X-Google-Smtp-Source: APiQypLJ2FgwBoBQJynH82isF2eDWpWLLM4xtlE5lTPr8j+9aHD43kl6AD7Tnw4x/QThIqNUK8yb6s+mHZg5JxKh5bY= X-Received: by 2002:a2e:97cd:: with SMTP id m13mr8435962ljj.20.1585602205609; Mon, 30 Mar 2020 14:03:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 30 Mar 2020 15:02:58 -0600 Message-ID: To: Eric Rescorla Cc: secdispatch-chairs@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="00000000000038884405a218c8a3" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 21:03:56 -0000 --00000000000038884405a218c8a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I didn't expect it to be any more persuasive. I was only hoping it'd be sufficient to avoid relitigating the whole thing. Especially because, short of spinning up a significant bit of new work, I don't see how the outcome will be any different. I'm not looking for just for a code point registration for something that's de facto. I'm endeavoring to bring some level of commonality to a situation that happens in practice now so as to hopefully improve interoperability. Indeed the situation may not be quite as straightforward as I have presented it in an early revision of an individual draft. But I'd suggest that characterizing it as "very brittle" is a bit hyperbolic. In working on the document I did try to educate myself somewhat on things that would be less than straightforward. When doing that I came across the recently published RFC 8740, which "updates RFC 7540 [HTTP/2] by forbidding TLS 1.3 post-handshake authentication." On Mon, Mar 30, 2020 at 12:13 PM Eric Rescorla wrote: > > > On Mon, Mar 30, 2020 at 10:38 AM Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> >> Thanks for the review and feedback, Eric. My attempts at >> answers/responses are inline below. >> >> On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla wrote: >> >>> >>> Overall, I agree that something like this is needed. However, >>> I have two concerns about the mechanism described here. >>> >>> First, as you note in S B.1., if the header is not properly >>> sanitized, there is a trivial attack and there are stronger >>> mechanism that do not require sanitization: >>> >>> "Client-Cert" header that would appear to the backend to have come >>> from the reverse proxy. Although numerous other methods of >>> detecting/preventing header injection are possible; such as the use >>> of a unique secret value as part of the header name or value or the >>> application of a signature, HMAC, or AEAD, there is no common genera= l >>> standardized mechanism. The potential problem of client header >>> injection is not at all unique to the functionality of this draft an= d >>> it would therefor be inappropriate for this draft to define a one-of= f >>> solution. In the absence of a generic standardized solution existin= g >>> currently, stripping/sanitizing the headers is the de facto means of >>> protecting against header injection in practice today. Sanitizing >>> >>> This seems like an odd argument to make: if a strong mechanism is >>> in order, we should design one and make it generic, not just throw >>> and continue to use weaker mechanisms. >>> >> >> Ironically, that text was written (at least in part) in an attempt to >> head off having this very argument with you. We (you and I specifically) >> have been down this road before discussing essentially the same issue wi= th >> respect to (the now defunct for unrelated reasons) >> https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure >> didn't seem to be be sufficient appetite to work on a generic solution. >> > > Well, I don't know why you think that I would have found it more > persuasive this time around. > > > Maybe that's changed and there is more of an appetite now? Maybe. There >> was some talk at the secdispatch session of the prospect of spinning up = or >> splitting off a WG to work on reverse proxy stuff. But a lot more than t= alk >> is needed and I maintain that, in the absence of something generic being >> defined and widely available, the de facto is sufficiently good and >> appropriate for a document/draft like this. >> > > Well, if what you want is a code point registration for something that's > de facto, then sure, but if you want to have an IETF PS, then the solutio= n > should reflect what we ordinarily consider to be best practice. > > > >> >>> >>> Second, I think it's quite unwise to only pass the EE cert. This >>> means that the server will be unable to independently evaluate >>> the cert chain, which (1) is unduly restrictive on the architecture >>> because it forces the proxy to do it and (2) means that there >>> is no backstop in the case where the proxy makes errors or >>> has a not-very-good validator. You should pass the whole chain. >>> >> >> Passing the end-entity cert vs. including intermediates or the whole >> chain is something that's up for discussion should this document find a >> home where it can be worked on and progressed. As with most things, ther= e >> are tradeoffs involved. >> >> What you describe as unduly restrictive, however, could also be viewed a= s >> properly constraining different components to doing the most appropriate >> functionality. The backend server doing the validation would mean it has= to >> evaluate the cert chain on every request (which is likely prohibitively >> expensive with multiple public key opperations) and/or have some >> complicated caching. And allowing either piece to do the validation coul= d >> also increase the likelihood that things are set up such that neither >> actually does it. >> > > ISTM that we have quite a bit of experience with MITM proxies (a slightly > different setting) and the quality of checking varies wildly, so I would > prefer to leave the origin server with the ability to do this work. > > > >> >> >>> This also implies that you should have a way to pass extensions >>> such as SCTs and stapled OCSP responses. >>> >> >> I was under the (maybe naive) impression that such things were largely o= r >> even exclusively for the server side and not applicable or defined for t= he >> client side? >> > > That's the situation now, but it might not be in the future. > > >> >> >>> >>> Finally, two points about TLS integration. >>> >>> 1. You should define how this works in the case of resumption >>> of a connection that had client auth. Should the proxy attach the >>> chain from the original connection? >>> >> >> Is such a resumed connection still considered to be client authenticated= ? >> I thought so and thus my assumption/expectation was that yes the proxy >> would attach the chain from the original connection. Is that problematic >> for some reason? Or are you just saying that it needs to be stated >> explicitly in the document? >> > > I'm saying that it needs to be in the document. > > >> >>> >>> 2. How do you handle post-handshake client authentication? Specifically= : >>> (a) How do you handle the situation in which part of the HTTP >>> request is covered by the client cert? >>> >>> (b) Post-handshake client authentication allows for the client >>> to authenticate with multiple certificates one after the other. >>> How is this propagated to the server? >>> >> >> I'd been thinking that post-handshake authentication and renegotiation >> were forbidden so these questions were out of scope. But I guess that on= ly >> applies to HTTP/2? >> > > I'm not aware of any restriction on post-handshake auth for H2 (H2 was > designed before TLS 1.3). > > -Ekr > > >> So, off-the-cuff I'd say that for (a) the header is only passed on >> requests that are covered in full by the cert. But that pragmatically it= 's >> super difficult or impossible with the APIs in the average environment t= o >> figure out what application data came before or after the cert auth and = so >> it'll end up being however a particular proxy implementation treats this >> situation currently but just with a standard header. For (b) I'd say onl= y >> propagate the most recent one. >> >> Having given my half-assed answers though, I'd welcome input if you thin= k >> there are better answers. >> >> >> >> >>> >>> On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell >> 40pingidentity.com@dmarc.ietf.org> wrote: >>> >>>> Hello SecDispatchers and Chairs thereof, >>>> >>>> I'd like to request some time on the agenda in Vancouver to present on >>>> https://datatracker.ietf.org/doc/draft-bdc-something-something-certifi= cate/ >>>> in an effort to gauge interest and potentially find an appropriate ven= ue >>>> for the work to proceed (or just put it and its ridiculously long titl= e out >>>> of its misery). >>>> >>>> Client-Cert HTTP Header: Conveying Client Certificate Information from >>>> TLS Terminating Reverse Proxies to Origin Server Applications >>>> >>>> Abstract >>>> >>>> This document defines the HTTP header field "Client-Cert" that allo= ws >>>> a TLS terminating reverse proxy to convey information about the >>>> client certificate of a mutually-authenticated TLS connection to an >>>> origin server in a common and predictable manner. >>>> >>>> Discussion around the value of having something like this defined >>>> happened in the OAuth WG a bit before the Singapore meeting (no doubt >>>> that's not the only time but it's the one in which I was involved rece= ntly) >>>> and an AD nudged me to secdispatch - >>>> https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoK= o/ >>>> falls somewhere in the middle of that long and sometimes contentious >>>> thread. I was unable to get a draft published prior to the I-D submiss= ion >>>> cut-off for Singapore and got a short "if time allows" presentation sl= ot at >>>> the meeting. The judgment coming out of that meeting was "needs draft"= . >>>> >>>> I did get an actual draft published a bit after Singapore (the one wit= h >>>> the ridiculously long title previously mentioned) and there's been som= e, if >>>> not exactly an overwhelming amount of, discussion and support of it on= this >>>> very list: >>>> https://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-something-s= omething-certificate%22 >>>> >>>> Thanks. >>>> Brian Campbell >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed.. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> _______________________________________________ >>>> Secdispatch mailing list >>>> Secdispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdispatch >>>> >>> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000038884405a218c8a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't expect it to be any more persuasive. I w= as only hoping it'd be sufficient to avoid relitigating the whole thing= . Especially because, short of spinning up a significant bit of new work, I= don't see how the outcome will be any different. I'm not looking f= or just for a code point registration for something that's de facto. I&= #39;m endeavoring to bring some level of commonality to a situation that ha= ppens in practice now so as to hopefully improve interoperability.

Indeed the situation may not be quite as straightforw= ard as I have presented it in an early revision of an individual draft. But= I'd suggest that characterizing it as "very brittle" is a bi= t hyperbolic.

In working on the document I di= d try to educate myself somewhat on things that would be less than straight= forward. When doing that I came across the recently published RFC 8740, whi= ch "updates RFC 7540 [HTTP/2] by forbidding TLS 1.3 post-handshake aut= hentication."



On Mon, Mar 30, 2020= at 12:13 PM Eric Rescorla <ekr@rtfm.com= > wrote:
=


=
On Mon, Mar 30, 2020 at 10:38 AM Bria= n Campbell <bcampbell@pingidentity.com> wrote:

<= div dir=3D"ltr">
Thanks for the review and feedback, Eric. My attempts = at answers/responses are inline below.
On Fri, M= ar 27, 2020 at 11:22 AM Eric Rescorla <ekr@rtfm.com> wrote:

Overall, I agree that som= ething like this is needed. However,
I have two concerns about the mecha= nism described here.

First, as you note in S B.1., if the header is = not properly
sanitized, there is a trivial attack and there are stronger=
mechanism that do not require sanitization:

=C2=A0 =C2=A0"C= lient-Cert" header that would appear to the backend to have come
= =C2=A0 =C2=A0from the reverse proxy.=C2=A0 Although numerous other methods = of
=C2=A0 =C2=A0detecting/preventing header injection are possible; such= as the use
=C2=A0 =C2=A0of a unique secret value as part of the header = name or value or the
=C2=A0 =C2=A0application of a signature, HMAC, or A= EAD, there is no common general
=C2=A0 =C2=A0standardized mechanism.=C2= =A0 The potential problem of client header
=C2=A0 =C2=A0injection is not= at all unique to the functionality of this draft and
=C2=A0 =C2=A0it wo= uld therefor be inappropriate for this draft to define a one-off
=C2=A0 = =C2=A0solution.=C2=A0 In the absence of a generic standardized solution exi= sting
=C2=A0 =C2=A0currently, stripping/sanitizing the headers is the de= facto means of
=C2=A0 =C2=A0protecting against header injection in prac= tice today.=C2=A0 Sanitizing

This seems like an odd argument to make= : if a strong mechanism is
in order, we should design one and make it ge= neric, not just throw
and continue to use weaker mechanisms.

Ironically, that text was written (at least = in part) in an attempt to head off having this very argument with you. We (= you and I specifically) have been down this road before discussing essentia= lly the same issue with respect to (the now defunct for unrelated reasons) = https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ = and there sure didn't seem to be be sufficient appetite to work on a ge= neric solution.

We= ll, I don't know why you think that I would have found it more persuasi= ve this time around.


Maybe that's changed and there is more of an = appetite now? Maybe. There was some talk at the secdispatch session of the = prospect of spinning up or splitting off a WG to work on reverse proxy stuf= f. But a lot more than talk is needed and I maintain that, in the absence o= f something generic being defined and widely available, the de facto is suf= ficiently good and appropriate for a document/draft like this.=C2=A0

Well, if what you wa= nt is a code point registration for something that's de facto, then sur= e, but if you want to have an IETF PS, then the solution should reflect wha= t we ordinarily consider to be best practice.


=
=C2=A0

Second, I= think it's quite unwise to only pass the EE cert. This
means that t= he server will be unable to independently evaluate
the cert chain, which= (1) is unduly restrictive on the architecture
because it forces the pro= xy to do it and (2) means that there
is no backstop in the case where th= e proxy makes errors or
has a not-very-good validator. You should pass t= he whole chain.

Passing the end-e= ntity cert vs. including intermediates or the whole chain is something that= 's up for discussion should this document find a home where it can be w= orked on and progressed. As with most things, there are tradeoffs involved.=

What you describe as unduly restrictive, how= ever, could also be viewed as properly constraining different components to= doing the most appropriate functionality. The backend server doing the val= idation would mean it has to evaluate the cert chain on every request (whic= h is likely prohibitively expensive with multiple public key opperations) a= nd/or have some complicated caching. And allowing either piece to do the va= lidation could also increase the likelihood that things are set up such tha= t neither actually does it.
<= br>
ISTM that we have quite a bit of experience with MITM proxies= (a slightly different setting) and the quality of checking varies wildly, = so I would prefer to leave the origin server with the ability to do this wo= rk.


=

=C2=A0
This also implies that you should have a= way to pass extensions
such as SCTs and stapled OCSP responses.

I was under the (maybe naive) impression= that such things were largely or even exclusively for the server side and = not applicable or defined for the client side?

That's the situation now, but it might not = be in the future.


=C2=A0

Finally, two points about TLS integration.

1. You sh= ould define how this works in the case of resumption
of a connection tha= t had client auth. Should the proxy attach the
chain from the original c= onnection?

Is such a resumed conn= ection still considered to be client authenticated? I thought so and thus m= y assumption/expectation was that yes the proxy would attach the chain from= the original connection. Is that problematic for some reason? Or are you j= ust saying that it needs to be stated explicitly in the document?
=

I'm saying that it n= eeds to be in the document.=C2=A0

=C2=A0

2. How do you handle post-handshake client = authentication? Specifically:
(a) How do you handle the situation in whi= ch part of the HTTP
request is covered by the client cert?

(b) Po= st-handshake client authentication allows for the client
to authenticate= with multiple certificates one after the other.
How is this propagated = to the server?

I'd been think= ing that post-handshake authentication and renegotiation were forbidden so = these questions were out of scope. But I guess that only applies to HTTP/2?=

I'm not aw= are of any restriction on post-handshake auth for H2 (H2 was designed befor= e TLS 1.3).

-Ekr


So, off-the-cuff I= 9;d say that for (a) the header is only passed on requests that are covered= in full by the cert. But that pragmatically it's super difficult or im= possible with the APIs in the average environment to figure out what applic= ation data came before or after the cert auth and so it'll end up being= however a particular proxy implementation treats this situation currently = but just with a standard header. For (b) I'd say only propagate the mo= st recent one.

Having given my half-assed ans= wers though, I'd welcome input if you think there are better answers. <= br>
=C2=A0

=C2=A0

On Mon, Mar 2, 2020 = at 1:51 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org= > wrote:
Hello SecDispatchers and Chairs thereof,

I'd like to request some time on the agenda in Vancouver to p= resent on https://datatracker.ietf.org/doc/d= raft-bdc-something-something-certificate/ in an effort to gauge interes= t and potentially find an appropriate venue for the work to proceed (or jus= t put it and its ridiculously long title out of its misery).

Clien= t-Cert HTTP Header: Conveying Client Certificate Information from
=C2=A0= =C2=A0 =C2=A0TLS Terminating Reverse Proxies to Origin Server Applications=

Abstract

=C2=A0 =C2=A0This document defines the HTTP header fie= ld "Client-Cert" that allows
=C2=A0 =C2=A0a TLS terminating re= verse proxy to convey information about the
=C2=A0 =C2=A0client certific= ate of a mutually-authenticated TLS connection to an
=C2=A0 =C2=A0origin= server in a common and predictable manner.

Discus= sion around the value of having something like this defined happened in the= OAuth WG a bit before the Singapore meeting (no doubt that's not the o= nly time but it's the one in which I was involved recently) and an AD n= udged me to secdispatch - https://mailarchive.i= etf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ falls somewhere in = the middle of that long and sometimes contentious thread. I was unable to g= et a draft published prior to the I-D submission cut-off for Singapore and = got a short "if time allows" presentation slot at the meeting. Th= e judgment coming out of that meeting was "needs draft".

I did get an actual draft published a bit after Singa= pore (the one with the ridiculously long title previously mentioned) and th= ere's been some, if not exactly an overwhelming amount of, discussion a= nd support of it on this very list: https://mailarchive.ietf.org/arch/search/?q=3D%22draft-bdc-some= thing-something-certificate%22

Thanks.
Brian Campbell











CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000038884405a218c8a3-- From nobody Mon Mar 30 17:57:52 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA923A16D0 for ; Mon, 30 Mar 2020 17:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3Se9PH7wUJY for ; Mon, 30 Mar 2020 17:57:48 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76153A15AF for ; Mon, 30 Mar 2020 17:57:47 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id k21so20221314ljh.2 for ; Mon, 30 Mar 2020 17:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MkqfjbUqyoK1P6Qf5pxGxlxDSdLiSQqLAjU6fkxL8CI=; b=REEUHpcw4fMS545KetPYlw7P1qxzyiXxwAZ1FMiJKtGHyKojgB+GDrwJuOHc0vG+mS 8VF9z5u9KRWuzRAvjUkHv3MKq/HuQkH8iApmlNSDlRa4kkaQvXAbZU8u/dN4MW2scUTz CecjbnACYcnP0l3KbwzBYlfVS0TXKvAznvFc0A6CU4y8pbedIymPJ74Sm+h3lb0PkXXu /iEbBNEXiaLe4br5GuErHWtfHIp0xBBE4bW9Hu4u/DYrOBM7xMaOE7EmU8qUe5IPyp6f ISg9/RA8WblXCKUdRWux3Rib1z3pL5VK7uJLIrOe/G86L8qGrKHDSls8bj3cPrmCW71V w0jQ== 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=MkqfjbUqyoK1P6Qf5pxGxlxDSdLiSQqLAjU6fkxL8CI=; b=Se4S/eHBiAvRomRYzD3jRDJRC2cRlQLuucFhcC12lTeb25MvgDtLLgb4v0fc0vXqll yWA+64a5J0b6dHxt8Q9fQgpc4tFaePytXBUX5UbUHoGTdHQO36Mag0mYKKmGMCaftRgs Xk7PFTuHsBQglKOZnkdI0bS7j09TAn5TCW0q63RODyQlI6wP7CH6IUVqjFjbf+Mf3TDY aGhXXR3wm2KMVEQ6jvIsbl5XbROWYVukNYCWyga99GfACgVyU+2MlZNkay4py9s+vw/q Wx2rtxrvTvM4gZhq8AjuzQVNY+ubC+XEqNsW/2fMc4E2WTaNE2LyTaaYgTL3F3iB++0X 3xuQ== X-Gm-Message-State: AGi0PuaNEEjq84KeWr3K0BgS9B9eAOWTvrQJj6/cFdtalc2Vd0DPuwle NTgi6MyQqGqKvsG2aUxXk8jcm79dgUpCH6EsyVAr0w== X-Google-Smtp-Source: APiQypJDlvgh/vtGO9rqYjPoQEkwPxasZ7os64cSlypvbU901xNC7BGGN8P6UYh5rA3SwWyFOk/6wxesMOOOCijKP4E= X-Received: by 2002:a2e:780a:: with SMTP id t10mr8951856ljc.83.1585616265760; Mon, 30 Mar 2020 17:57:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 30 Mar 2020 17:57:09 -0700 Message-ID: To: Brian Campbell Cc: secdispatch-chairs@ietf.org, IETF SecDispatch Content-Type: multipart/alternative; boundary="0000000000004574df05a21c0e3c" Archived-At: Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 00:57:51 -0000 --0000000000004574df05a21c0e3c Content-Type: text/plain; charset="UTF-8" On Mon, Mar 30, 2020 at 2:03 PM Brian Campbell wrote: > I didn't expect it to be any more persuasive. I was only hoping it'd be > sufficient to avoid relitigating the whole thing. > For obvious reasons, I'm not that excited about that. Especially because, short of spinning up a significant bit of new work, I > don't see how the outcome will be any different. I'm not looking for just > for a code point registration for something that's de facto. I'm > endeavoring to bring some level of commonality to a situation that happens > in practice now so as to hopefully improve interoperability. > Again, I'm fine to see an informational document with a code point registration, but the import of a Proposed Standard is that the IETF thinks this is a good idea, and ISTM that the design you have proposed is not in fact have security properties we would otherwise want. In working on the document I did try to educate myself somewhat on things > that would be less than straightforward. When doing that I came across the > recently published RFC 8740, which "updates RFC 7540 [HTTP/2] by forbidding > TLS 1.3 post-handshake authentication." > Ah, good. So this just applies to HTTP 1.1. -Ekr > > On Mon, Mar 30, 2020 at 12:13 PM Eric Rescorla wrote: > >> >> >> On Mon, Mar 30, 2020 at 10:38 AM Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> >>> Thanks for the review and feedback, Eric. My attempts at >>> answers/responses are inline below. >>> >>> On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla wrote: >>> >>>> >>>> Overall, I agree that something like this is needed. However, >>>> I have two concerns about the mechanism described here. >>>> >>>> First, as you note in S B.1., if the header is not properly >>>> sanitized, there is a trivial attack and there are stronger >>>> mechanism that do not require sanitization: >>>> >>>> "Client-Cert" header that would appear to the backend to have come >>>> from the reverse proxy. Although numerous other methods of >>>> detecting/preventing header injection are possible; such as the use >>>> of a unique secret value as part of the header name or value or the >>>> application of a signature, HMAC, or AEAD, there is no common general >>>> standardized mechanism. The potential problem of client header >>>> injection is not at all unique to the functionality of this draft and >>>> it would therefor be inappropriate for this draft to define a one-off >>>> solution. In the absence of a generic standardized solution existing >>>> currently, stripping/sanitizing the headers is the de facto means of >>>> protecting against header injection in practice today. Sanitizing >>>> >>>> This seems like an odd argument to make: if a strong mechanism is >>>> in order, we should design one and make it generic, not just throw >>>> and continue to use weaker mechanisms. >>>> >>> >>> Ironically, that text was written (at least in part) in an attempt to >>> head off having this very argument with you. We (you and I specifically) >>> have been down this road before discussing essentially the same issue with >>> respect to (the now defunct for unrelated reasons) >>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there >>> sure didn't seem to be be sufficient appetite to work on a generic >>> solution. >>> >> >> Well, I don't know why you think that I would have found it more >> persuasive this time around. >> >> >> Maybe that's changed and there is more of an appetite now? Maybe. There >>> was some talk at the secdispatch session of the prospect of spinning up or >>> splitting off a WG to work on reverse proxy stuff. But a lot more than talk >>> is needed and I maintain that, in the absence of something generic being >>> defined and widely available, the de facto is sufficiently good and >>> appropriate for a document/draft like this. >>> >> >> Well, if what you want is a code point registration for something that's >> de facto, then sure, but if you want to have an IETF PS, then the solution >> should reflect what we ordinarily consider to be best practice. >> >> >> >>> >>>> >>>> Second, I think it's quite unwise to only pass the EE cert. This >>>> means that the server will be unable to independently evaluate >>>> the cert chain, which (1) is unduly restrictive on the architecture >>>> because it forces the proxy to do it and (2) means that there >>>> is no backstop in the case where the proxy makes errors or >>>> has a not-very-good validator. You should pass the whole chain. >>>> >>> >>> Passing the end-entity cert vs. including intermediates or the whole >>> chain is something that's up for discussion should this document find a >>> home where it can be worked on and progressed. As with most things, there >>> are tradeoffs involved. >>> >>> What you describe as unduly restrictive, however, could also be viewed >>> as properly constraining different components to doing the most appropriate >>> functionality. The backend server doing the validation would mean it has to >>> evaluate the cert chain on every request (which is likely prohibitively >>> expensive with multiple public key opperations) and/or have some >>> complicated caching. And allowing either piece to do the validation could >>> also increase the likelihood that things are set up such that neither >>> actually does it. >>> >> >> ISTM that we have quite a bit of experience with MITM proxies (a slightly >> different setting) and the quality of checking varies wildly, so I would >> prefer to leave the origin server with the ability to do this work. >> >> >> >>> >>> >>>> This also implies that you should have a way to pass extensions >>>> such as SCTs and stapled OCSP responses. >>>> >>> >>> I was under the (maybe naive) impression that such things were largely >>> or even exclusively for the server side and not applicable or defined for >>> the client side? >>> >> >> That's the situation now, but it might not be in the future. >> >> >>> >>> >>>> >>>> Finally, two points about TLS integration. >>>> >>>> 1. You should define how this works in the case of resumption >>>> of a connection that had client auth. Should the proxy attach the >>>> chain from the original connection? >>>> >>> >>> Is such a resumed connection still considered to be client >>> authenticated? I thought so and thus my assumption/expectation was that yes >>> the proxy would attach the chain from the original connection. Is that >>> problematic for some reason? Or are you just saying that it needs to be >>> stated explicitly in the document? >>> >> >> I'm saying that it needs to be in the document. >> >> >>> >>>> >>>> 2. How do you handle post-handshake client authentication? Specifically: >>>> (a) How do you handle the situation in which part of the HTTP >>>> request is covered by the client cert? >>>> >>>> (b) Post-handshake client authentication allows for the client >>>> to authenticate with multiple certificates one after the other. >>>> How is this propagated to the server? >>>> >>> >>> I'd been thinking that post-handshake authentication and renegotiation >>> were forbidden so these questions were out of scope. But I guess that only >>> applies to HTTP/2? >>> >> >> I'm not aware of any restriction on post-handshake auth for H2 (H2 was >> designed before TLS 1.3). >> >> -Ekr >> >> >>> So, off-the-cuff I'd say that for (a) the header is only passed on >>> requests that are covered in full by the cert. But that pragmatically it's >>> super difficult or impossible with the APIs in the average environment to >>> figure out what application data came before or after the cert auth and so >>> it'll end up being however a particular proxy implementation treats this >>> situation currently but just with a standard header. For (b) I'd say only >>> propagate the most recent one. >>> >>> Having given my half-assed answers though, I'd welcome input if you >>> think there are better answers. >>> >>> >>> >>> >>>> >>>> On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell >>> 40pingidentity.com@dmarc.ietf.org> wrote: >>>> >>>>> Hello SecDispatchers and Chairs thereof, >>>>> >>>>> I'd like to request some time on the agenda in Vancouver to present on >>>>> https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ >>>>> in an effort to gauge interest and potentially find an appropriate venue >>>>> for the work to proceed (or just put it and its ridiculously long title out >>>>> of its misery). >>>>> >>>>> Client-Cert HTTP Header: Conveying Client Certificate Information from >>>>> TLS Terminating Reverse Proxies to Origin Server Applications >>>>> >>>>> Abstract >>>>> >>>>> This document defines the HTTP header field "Client-Cert" that >>>>> allows >>>>> a TLS terminating reverse proxy to convey information about the >>>>> client certificate of a mutually-authenticated TLS connection to an >>>>> origin server in a common and predictable manner. >>>>> >>>>> Discussion around the value of having something like this defined >>>>> happened in the OAuth WG a bit before the Singapore meeting (no doubt >>>>> that's not the only time but it's the one in which I was involved recently) >>>>> and an AD nudged me to secdispatch - >>>>> https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ >>>>> falls somewhere in the middle of that long and sometimes contentious >>>>> thread. I was unable to get a draft published prior to the I-D submission >>>>> cut-off for Singapore and got a short "if time allows" presentation slot at >>>>> the meeting. The judgment coming out of that meeting was "needs draft". >>>>> >>>>> I did get an actual draft published a bit after Singapore (the one >>>>> with the ridiculously long title previously mentioned) and there's been >>>>> some, if not exactly an overwhelming amount of, discussion and support of >>>>> it on this very list: >>>>> https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22 >>>>> >>>>> Thanks. >>>>> Brian Campbell >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). Any >>>>> review, use, distribution or disclosure by others is strictly prohibited.. >>>>> If you have received this communication in error, please notify the sender >>>>> immediately by e-mail and delete the message and any file attachments from >>>>> your computer. Thank you.* >>>>> _______________________________________________ >>>>> Secdispatch mailing list >>>>> Secdispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdispatch >>>>> >>>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* --0000000000004574df05a21c0e3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Mar 30, 2020 at 2:03 PM Brian= Campbell <bcampbell@pingidentity.com> wrote:
I didn't expect it t= o be any more persuasive. I was only hoping it'd be sufficient to avoid= relitigating the whole thing.

= For obvious reasons, I'm not that excited about that.


Especially because, short of spinning up a significant bit= of new work, I don't see how the outcome will be any different. I'= m not looking for just for a code point registration for something that'= ;s de facto. I'm endeavoring to bring some level of commonality to a si= tuation that happens in practice now so as to hopefully improve interoperab= ility.

Again, I'm fine= to see an informational document with a code point registration, but the i= mport of a Proposed Standard is that the IETF thinks this is a good idea, a= nd ISTM that the design you have proposed is not in fact have security prop= erties we would otherwise want.


In working = on the document I did try to educate myself somewhat on things that would b= e less than straightforward. When doing that I came across the recently pub= lished RFC 8740, which "updates RFC 7540 [HTTP/2] by forbidding TLS 1.= 3 post-handshake authentication."
Ah, good. So this just applies to HTTP 1.1.

-Ekr




On Mon, Mar 30,= 2020 at 12:13 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Mar 3= 0, 2020 at 10:38 AM Brian Campbell <bcampbell@pingidentity.com> wrote:

Thanks for the review and feed= back, Eric. My attempts at answers/responses are inline below.

On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>
Overall, I agree that something like this is needed. However,
I have tw= o concerns about the mechanism described here.

First, as you note in= S B.1., if the header is not properly
sanitized, there is a trivial att= ack and there are stronger
mechanism that do not require sanitization:
=C2=A0 =C2=A0"Client-Cert" header that would appear to the = backend to have come
=C2=A0 =C2=A0from the reverse proxy.=C2=A0 Although= numerous other methods of
=C2=A0 =C2=A0detecting/preventing header inje= ction are possible; such as the use
=C2=A0 =C2=A0of a unique secret valu= e as part of the header name or value or the
=C2=A0 =C2=A0application of= a signature, HMAC, or AEAD, there is no common general
=C2=A0 =C2=A0sta= ndardized mechanism.=C2=A0 The potential problem of client header
=C2=A0= =C2=A0injection is not at all unique to the functionality of this draft an= d
=C2=A0 =C2=A0it would therefor be inappropriate for this draft to defi= ne a one-off
=C2=A0 =C2=A0solution.=C2=A0 In the absence of a generic st= andardized solution existing
=C2=A0 =C2=A0currently, stripping/sanitizin= g the headers is the de facto means of
=C2=A0 =C2=A0protecting against h= eader injection in practice today.=C2=A0 Sanitizing

This seems like = an odd argument to make: if a strong mechanism is
in order, we should de= sign one and make it generic, not just throw
and continue to use weaker = mechanisms.

Ironically, that text= was written (at least in part) in an attempt to head off having this very = argument with you. We (you and I specifically) have been down this road bef= ore discussing essentially the same issue with respect to (the now defunct = for unrelated reasons) https://datatracker.ietf.org/doc/draft-= ietf-tokbind-ttrp/ and there sure didn't seem to be be sufficient a= ppetite to work on a generic solution.

Well, I don't know why you think that I would have= found it more persuasive this time around.

=
Maybe that's changed a= nd there is more of an appetite now? Maybe. There was some talk at the secd= ispatch session of the prospect of spinning up or splitting off a WG to wor= k on reverse proxy stuff. But a lot more than talk is needed and I maintain= that, in the absence of something generic being defined and widely availab= le, the de facto is sufficiently good and appropriate for a document/draft = like this.=C2=A0

Well, if what you want is a code point registration for something that&#= 39;s de facto, then sure, but if you want to have an IETF PS, then the solu= tion should reflect what we ordinarily consider to be best practice.
<= div>

=C2=A0

Second, I think it's quite unwise to only pass the EE cer= t. This
means that the server will be unable to independently evaluatethe cert chain, which (1) is unduly restrictive on the architecture
be= cause it forces the proxy to do it and (2) means that there
is no backst= op in the case where the proxy makes errors or
has a not-very-good valid= ator. You should pass the whole chain.

Passing the end-entity cert vs. including intermediates or the whole = chain is something that's up for discussion should this document find a= home where it can be worked on and progressed. As with most things, there = are tradeoffs involved.

What you describe as = unduly restrictive, however, could also be viewed as properly constraining = different components to doing the most appropriate functionality. The backe= nd server doing the validation would mean it has to evaluate the cert chain= on every request (which is likely prohibitively expensive with multiple pu= blic key opperations) and/or have some complicated caching. And allowing ei= ther piece to do the validation could also increase the likelihood that thi= ngs are set up such that neither actually does it.

ISTM that we have quite a bit of exper= ience with MITM proxies (a slightly different setting) and the quality of c= hecking varies wildly, so I would prefer to leave the origin server with th= e ability to do this work.



=C2=A0
This also implies= that you should have a way to pass extensions
such as SCTs and stapled = OCSP responses.

I was under the (= maybe naive) impression that such things were largely or even exclusively f= or the server side and not applicable or defined for the client side?
=

That's the situation= now, but it might not be in the future.


=C2=A0

Finally, two points about TLS integr= ation.

1. You should define how this works in the case of resumption=
of a connection that had client auth. Should the proxy attach the
ch= ain from the original connection?

Is such a resumed connection still considered to be client authenticated? = I thought so and thus my assumption/expectation was that yes the proxy woul= d attach the chain from the original connection. Is that problematic for so= me reason? Or are you just saying that it needs to be stated explicitly in = the document?

I= 'm saying that it needs to be in the document.=C2=A0

=C2=A0

2. How do you handle pos= t-handshake client authentication? Specifically:
(a) How do you handle t= he situation in which part of the HTTP
request is covered by the client = cert?

(b) Post-handshake client authentication allows for the client=
to authenticate with multiple certificates one after the other.
How = is this propagated to the server?

I'd been thinking that post-handshake authentication and renegotiation= were forbidden so these questions were out of scope. But I guess that only= applies to HTTP/2?

=
I'm not aware of any restriction on post-handshake auth for H2 (H2= was designed before TLS 1.3).

-Ekr

=

So= , off-the-cuff I'd say that for (a) the header is only passed on reques= ts that are covered in full by the cert. But that pragmatically it's su= per difficult or impossible with the APIs in the average environment to fig= ure out what application data came before or after the cert auth and so it&= #39;ll end up being however a particular proxy implementation treats this s= ituation currently but just with a standard header. For (b) I'd say on= ly propagate the most recent one.

Having give= n my half-assed answers though, I'd welcome input if you think there ar= e better answers.
=C2=A0

=C2=A0=

On= Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=3D40pingidentity.com@= dmarc.ietf.org> wrote:
Hello SecDispatchers and Chairs thereof= ,

I'd like to request some time on the agenda= in Vancouver to present on https://datatrac= ker.ietf.org/doc/draft-bdc-something-something-certificate/ in an effor= t to gauge interest and potentially find an appropriate venue for the work = to proceed (or just put it and its ridiculously long title out of its miser= y).

Client-Cert HTTP Header: Conveying Client Certificate Informat= ion from
=C2=A0 =C2=A0 =C2=A0TLS Terminating Reverse Proxies to Origin S= erver Applications

Abstract

=C2=A0 =C2=A0This document defines t= he HTTP header field "Client-Cert" that allows
=C2=A0 =C2=A0a = TLS terminating reverse proxy to convey information about the
=C2=A0 =C2= =A0client certificate of a mutually-authenticated TLS connection to an
= =C2=A0 =C2=A0origin server in a common and predictable manner.
Discussion around the value of having something like this defi= ned happened in the OAuth WG a bit before the Singapore meeting (no doubt t= hat's not the only time but it's the one in which I was involved re= cently) and an AD nudged me to secdispatch - ht= tps://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ = falls somewhere in the middle of that long and sometimes contentious thread= . I was unable to get a draft published prior to the I-D submission cut-off= for Singapore and got a short "if time allows" presentation slot= at the meeting. The judgment coming out of that meeting was "needs dr= aft".

I did get an actual draft publishe= d a bit after Singapore (the one with the ridiculously long title previousl= y mentioned) and there's been some, if not exactly an overwhelming amou= nt of, discussion and support of it on this very list: https://mailarchive.ietf.org/arch/search/?q=3D= %22draft-bdc-something-something-certificate%22

Thanks.
Brian Campbell


=





=




CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited..=C2=A0 If you have received this communication in er= ror, please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank you.__= _____________________________________________
Secdispatch mailing list
Secdispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/secdispatch

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.
CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you. --0000000000004574df05a21c0e3c-- From nobody Mon Mar 30 19:06:40 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCD3A17EF for ; Mon, 30 Mar 2020 19:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2jd4jZAJ6cu for ; Mon, 30 Mar 2020 19:06:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2D58B3A17EE for ; Mon, 30 Mar 2020 19:06:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02V26T3c007967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 22:06:32 -0400 Date: Mon, 30 Mar 2020 19:06:29 -0700 From: Benjamin Kaduk To: ietf-http-wg@w3.org Cc: secdispatch@ietf.org Message-ID: <20200331020629.GD50174@kduck.mit.edu> References: <20200329043333.GO18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200329043333.GO18021@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 02:06:36 -0000 On Sat, Mar 28, 2020 at 11:37:48PM -0500, Nico Williams wrote: > I've just submitted draft-williams-http-accept-auth-and-redirect-00 [0] > to deal with the problem of the mutual exclusivity of 3xx and 401. > > This problem arises when, for example, one mixes in some organization, > both Negotiate [RFC4559] and redirect-based authentication flows. This > problem is rather vexing: the server has to decide which to go with > without knowing which the user-agent supports! > > The solution seems simple: let the user-agent tell the server what > authentication schemes it supports. (Indeed, one common hack is to > glean this from the user-agent string.) As well, let the server mix > redirection and authentication requests. > > As well, while we're at it, why not codify redirect-based > authentication. In particular, the PowerShell HTTP command-line client, > Invoke-WebRequest [1] has an option to copy Authorization headers from > redirect responses to redirected requests, which seems like just the > ticket: > > | -PreserveAuthorizationOnRedirect > | > | Indicates the cmdlet should preserve the Authorization header, when > | present, across redirections. > | > | By default, the cmdlet strips the Authorization header before > | redirecting. Specifying this parameter disables this logic for cases > | where the header needs to be sent to the redirection location. > > ISTR seeing a prohibition on copying headers from redirect responses to > redirected requests, but I can't find this now. Digest [RFC2617] > actually describes the Authorization-copying behavior in a paragraph > that straddles pages 17 and 18, using the "domain" parameter of Digest > to effect a redirection. > > This I-D then adds an Accept-Auth request header, and an HTTP Interestingly, I was just thinking about whether such an Accept-Auth header would be useful in the context of Rick's SASL proposal that was presented at SECDISPATCH last week. Perhaps along with a way for the server to annotate that various (e.g., linked) resources will require a given authentication mechanism, there might be a route to improving the UX in this space ... though there's a long way for it to go, so I don't know that these in and of themselves will make a huge difference. -Ben > authentication scheme named Redirect, and codifies other ways to mix > redirection and authentication requests. > > This I-D seems trivial enough to go the ISE route, but perhaps some WG, > such as HTTPbis, might be interested in taking a closer look, reviewing, > possibly leading to request not to publish (if, e.g., there's already a > solution I've missed or this is problematic for some reason), or to > adopting the work. > > Cc'ed is secdispatch@ietf.org, in case they want to dispatch this I-D. > Reply-To is set to HTTPbis. > > See also [2]. > > Feedback would be greatly appreciated. Stay safe! > > [0] https://tools.ietf.org/html/draft-williams-http-accept-auth-and-redirect-00 > https://www.ietf.org/internet-drafts/draft-williams-http-accept-auth-and-redirect-00.txt > > [1] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7 > > [2] https://mailarchive.ietf.org/arch/msg/art/T4nP5Rv91yuE0ew8p0vJh2fX1IM/ > > Nico > -- > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch From nobody Mon Mar 30 22:00:14 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D689E3A1B01 for ; Mon, 30 Mar 2020 22:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzDHwLxr_brR for ; Mon, 30 Mar 2020 22:00:08 -0700 (PDT) Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 5DC463A0C75 for ; Mon, 30 Mar 2020 22:00:02 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A21B5100D13; Tue, 31 Mar 2020 05:00:01 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-9-10.trex.outbound.svc.cluster.local [100.96.9.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1581E100880; Tue, 31 Mar 2020 05:00:01 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 31 Mar 2020 05:00:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Tasty-Descriptive: 00ee9aeb2ef1f99c_1585630801490_1776198837 X-MC-Loop-Signature: 1585630801490:1937684565 X-MC-Ingress-Time: 1585630801489 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id A534AB26A8; Mon, 30 Mar 2020 22:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HaDnLC1lgnBScE FtrjjXypZY9aw=; b=nBAzay9qPq8b4WrmWNM18HQ3nZZTVWiVGtTyu745t4wkT3 JXKwwcF/EkC13E1CNR1JOIIcQ5Ke1ICGGqq3mKOm00c8r0VU75qMvbu5LKvAOtrc q8GJw1T+tn/B5/dnf/XGd0Ml7emWTta6Np9xtzi1/z1cRGhJWTOqrkMWinoN8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 6FD91B26A2; Mon, 30 Mar 2020 21:59:57 -0700 (PDT) Date: Mon, 30 Mar 2020 23:59:54 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Benjamin Kaduk Cc: ietf-http-wg@w3.org, secdispatch@ietf.org Message-ID: <20200331045953.GP18021@localhost> References: <20200329043333.GO18021@localhost> <20200331020629.GD50174@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331020629.GD50174@kduck.mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 05:00:13 -0000 On Mon, Mar 30, 2020 at 07:06:29PM -0700, Benjamin Kaduk wrote: > On Sat, Mar 28, 2020 at 11:37:48PM -0500, Nico Williams wrote: > > This I-D then adds an Accept-Auth request header, and an HTTP > > Interestingly, I was just thinking about whether such an Accept-Auth > header would be useful in the context of Rick's SASL proposal that was > presented at SECDISPATCH last week. Perhaps along with a way for the > server to annotate that various (e.g., linked) resources will require > a given authentication mechanism, there might be a route to improving The server isn't going to want to authenticate the user differently for different resources -- authorize differently, yes, but probably still with the same scheme. > the UX in this space ... though there's a long way for it to go, so I > don't know that these in and of themselves will make a huge > difference. I don't quite follow. There's lots more work to do about UX? Sure. But I know this header will make a huge difference for sites where there's a mix of Negotiate and Bearer -- it's absolutely essential for the server to know which (if either, possibly both) are supported. So I'd very much like to move forward with registering the header by requesting Expert Review for it. What about the Redirect scheme? Have I missed something important? That will require IETF Review. I've added security considerations text in my GH repo for this, nicowilliams/accept-auth-and-redirect, FYI. Nico -- From nobody Mon Mar 30 22:51:03 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E4F3A0CF6 for ; Mon, 30 Mar 2020 22:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdYMU8rTl39h for ; Mon, 30 Mar 2020 22:51:01 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) (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 261793A0CF5 for ; Mon, 30 Mar 2020 22:51:00 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 389001006B4; Tue, 31 Mar 2020 05:51:00 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-12-20.trex.outbound.svc.cluster.local [100.96.12.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AE05D100855; Tue, 31 Mar 2020 05:50:59 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 31 Mar 2020 05:51:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Invention-Thread: 45385e151954189e_1585633859981_3342648246 X-MC-Loop-Signature: 1585633859980:2500628170 X-MC-Ingress-Time: 1585633859980 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id 71B31B26B2; Mon, 30 Mar 2020 22:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JpfdRNB65hMvWF vzGTnrbDejUzI=; b=hUlrdilRPvftVdRYCu9hm5PO0yzvMDRDq2puRp7f8Xi9yp jEpFg4dezD6pdGL2qYF+RyaDpeHMmLJQAQg1afLhT9TDuYEjWwVRhftbl7oL5TKU 9h8FRRV6fDN1naJraPf8itsZSDnsrvmRSN/ATRt3bG9/OO26jmFEnGsIqb34Q= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTPSA id C4E40B26AC; Mon, 30 Mar 2020 22:50:57 -0700 (PDT) Date: Tue, 31 Mar 2020 00:50:55 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Benjamin Kaduk Cc: ietf-http-wg@w3.org, secdispatch@ietf.org Message-ID: <20200331055054.GQ18021@localhost> References: <20200329043333.GO18021@localhost> <20200331020629.GD50174@kduck.mit.edu> <20200331045953.GP18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331045953.GP18021@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgleelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 05:51:03 -0000 On Mon, Mar 30, 2020 at 11:59:54PM -0500, Nico Williams wrote: > On Mon, Mar 30, 2020 at 07:06:29PM -0700, Benjamin Kaduk wrote: > ... > > What about the Redirect scheme? Have I missed something important? > That will require IETF Review. I've added security considerations text > in my GH repo for this, nicowilliams/accept-auth-and-redirect, FYI. One thought that occurs is that the Authorization header should only be preserved from the last redirect: the one back to the original origin. And a new header could be preserved in all the other hops to enable communication between the origin and the auth services via the user-agent. This way there would be no way for an origin to confuse an auth service via an Authorization header. After all, that's for the user-agent to authenticate to the auth service. We shouldn't give the Authorization header two different uses. On the last redirect, however, we really should want to preserve the Authorization header, as it will -presumably- be authenticating the user to the relying party with a token issued by the last hop. Nico -- From nobody Tue Mar 31 15:29:21 2020 Return-Path: X-Original-To: secdispatch@ietfa.amsl.com Delivered-To: secdispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C503A0BDB for ; Tue, 31 Mar 2020 15:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3HwRgEtbUcK for ; Tue, 31 Mar 2020 15:29:17 -0700 (PDT) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 C05583A0BD9 for ; Tue, 31 Mar 2020 15:29:17 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D1AD420E27; Tue, 31 Mar 2020 22:29:16 +0000 (UTC) Received: from pdx1-sub0-mail-a83.g.dreamhost.com (100-96-44-34.trex.outbound.svc.cluster.local [100.96.44.34]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5FA2320BD2; Tue, 31 Mar 2020 22:29:16 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a83.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 31 Mar 2020 22:29:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Slimy-Daffy: 314eb42b3a3fec66_1585693756637_2551645543 X-MC-Loop-Signature: 1585693756637:630118915 X-MC-Ingress-Time: 1585693756636 Received: from pdx1-sub0-mail-a83.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a83.g.dreamhost.com (Postfix) with ESMTP id 1C765B0CFA; Tue, 31 Mar 2020 15:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gyyv1+pgqMrube EJO5roYp9KgOs=; b=kkuR1la7Y/P6OBpb0yLEjd+L3r8A/ShUAWJ/itICIV5U7D 7jkoF3u4pgH8mTYTDxvNAlxj+FInYlAHQPXp+XJb0GpeZIvhaBD5/16XdKw6TnBc kAwU9EuVMOe09341zytPeRY/vosJL3J/ooaTZhE+CvEeXnTxQt8hPJOt0r2To= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a83.g.dreamhost.com (Postfix) with ESMTPSA id BAD4BB0D13; Tue, 31 Mar 2020 15:29:14 -0700 (PDT) Date: Tue, 31 Mar 2020 17:29:12 -0500 X-DH-BACKEND: pdx1-sub0-mail-a83 From: Nico Williams To: Benjamin Kaduk Cc: ietf-http-wg@w3.org, secdispatch@ietf.org Message-ID: <20200331222910.GV18021@localhost> References: <20200329043333.GO18021@localhost> <20200331020629.GD50174@kduck.mit.edu> <20200331045953.GP18021@localhost> <20200331055054.GQ18021@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200331055054.GQ18021@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgddufeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem X-BeenThere: secdispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 22:29:19 -0000 I've submitted a -01 with these changes: - better documented the motivation for the new Accept headers (improved interop without having to modify HTTP implementations, just applications) - removed special values of Accept-Auth - added Accept-Redirect and Accept-Redirect-Auth headers - for the Redirect auth scheme, limit preservation of the Authorization header and add an Authorization-Request header that is always preserved - expanded discussion of redirect-based auth protocols - improved Security and IANA Considerations text - misc changes The new Accept headers and the new auth scheme are now much more separable. This I-D could now be split into two I-Ds. Nico --