From nobody Wed Feb 3 20:10:51 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF683A0C3D; Wed, 3 Feb 2021 20:10:50 -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 JKYfNaoomKcR; Wed, 3 Feb 2021 20:10:47 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29CBA3A0C32; Wed, 3 Feb 2021 20:10:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E80C9389A6; Wed, 3 Feb 2021 23:13:38 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cSREVZWweZiY; Wed, 3 Feb 2021 23:13:37 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 143AD389AC; Wed, 3 Feb 2021 23:13:37 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2392348F; Wed, 3 Feb 2021 23:10:43 -0500 (EST) From: Michael Richardson To: spasm@ietf.org, saag@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 04:10:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I thought I had cross-posted this, but apparently I did not: https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/ FC5280 uses the term "intermediate certificates", and they are presumably issues by "intermediate" certification authorities. That term does not appear, although: "intermediate CA certificates" occurs. RFC4949 defines "intermediate CA" However, the usage in RFC4949 seems entirely related to cross-certification, rather than a PKI that has multiple layers of certification authority! RFC4949 defines "subordinate CA" in a way that implies it is part of the sa= me organization. RFC5280 uses the term "subordinate" in section 3.2, but later in referring = to RFC1422, notes that in X509v3, we don't need the same structure. In reading it, it feels that the term subordinate should refer to v1 certificates only. At this point, in 2020, can someone give me some guidance on using these te= rms? My intuition, which I have started to document at: https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerat= ions-01.html#name-number-of-levels-of-certifi is that if the Trust Anchor (Level one) and the Level Two Certification Authority are under control of the same organization, then the Level Two is an "intermediate" certification authority. However, if the Anchor (level N) and the Level N+1 certification authority are in different organizations (such as for an "Enterprise Certificate"), then the Level N+1 is a subordinate CA. This question comes from working on draft-ietf-anima-constrained-voucher, in which we have a number of choices on which certificate (or public key) to pin our constrained-RFC8366 voucher. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAbc8IACgkQgItw+93Q 3WU3zQf8C3q2zDYFZolcewZjM2HpwmQtn9ZFVI0Slob4jQdDZ31bmkOMvgoC7wT8 PLKs6cicvvPXVn4mScvokC81RiMsItfFRhRdKyrKtww1qAvjz0BkOyJ8vuE2WMP0 GWasvq1aqvR4CjFnyq1nVL/VbLv8Pxq3biEkOn4gE1RHb/R/oGd6uqGap51GH6Q4 wPVGoS/fXaNfMP0SCXU/oRk0IRR6yZ3xPnyoGSb/rEBM2H/4O/5h/khReJF/5/3B FpSjhK61/uU+sVQP1TOIjEv89kJekVIA8Uv9yLryEWGlO6/yudGxcv5t98A1Rkqp O1M3Vem/SmmI+ePznBjL89m1gArHtQ== =VWNS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 3 20:48:16 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72A63A0CF6 for ; Wed, 3 Feb 2021 20:48:14 -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 JsjzCEhdab0o for ; Wed, 3 Feb 2021 20:48:12 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 C91E93A0CEB for ; Wed, 3 Feb 2021 20:48:12 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4035C19911A; Wed, 3 Feb 2021 23:48:11 -0500 (EST) Date: Wed, 3 Feb 2021 23:48:11 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: Reply-To: saag@ietf.org References: <30833.1612411843@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30833.1612411843@localhost> Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 04:48:15 -0000 On Wed, Feb 03, 2021 at 11:10:43PM -0500, Michael Richardson wrote: > I thought I had cross-posted this, but apparently I did not: > > https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/ > > RFC5280 uses the term "intermediate certificates", and they are > RFC4949 defines "intermediate CA" > RFC4949 defines "subordinate CA" in a way that implies it is part of the same > RFC5280 uses the term "subordinate" in section 3.2, but later in referring to > > At this point, in 2020, can someone give me some guidance on using these terms? FWIW, in the context of OpenSSL, Postfix, etc., I see/use the terms "root CA certificate", "intermediate CA certificate" and "end-entity certificate". Where "root CA certificates" are self-signed, "end-entity certificates" are the certificates of the peer, and everything in between is just intermediate certificates. >From a verifier perspective there is little reason to make distictions on a more granular level. Note that what may be an intermediate CA certificate (or even end-entity certificate) in one context may the trust anchor in another. So the above terms are strictly about the chain of issuance, separate from any question of which element in the chain happens to be the trust anchor. > My intuition, which I have started to document at: > https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerations-01.html#name-number-of-levels-of-certifi > > is that if the Trust Anchor (Level one) and the Level Two Certification > Authority are under control of the same organization, then the Level Two is > an "intermediate" certification authority. > > However, if the Anchor (level N) and the Level N+1 certification authority > are in different organizations (such as for an "Enterprise Certificate"), > then the Level N+1 is a subordinate CA. Again, from the vantage point of the verifier, there's no practical way to know. Some of the Let's Encrypt CA certs are issued by DST others by ISRG. In common usage, I typically see these referred to as intermediate certificates, but e.g. the ISRG CPS appears to prefer "subordinate": https://letsencrypt.org/documents/isrg-cp-v2.5/ 6.1.1.1 CA key pair generation For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL: explicitly distinguishing between arm's length subordinates and subordinates affiliated with the root CA. There's no mention of intermediate certificates, rather The taxonomy appears to be 6.1.5 Key sizes (1) Root CA Certificates (2) Subordinate CA Certificates (3) Subscriber Certificates So as I see it, "intermediate" and "subordinate" are essentially synonymous, with some technical communities using the former and others the latter to mean basically the same thing. -- Viktor. From nobody Wed Feb 3 23:46:21 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E743A13A5; Wed, 3 Feb 2021 23:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvv79wpucIBH; Wed, 3 Feb 2021 23:46:17 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80055.outbound.protection.outlook.com [40.107.8.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AD43A13A4; Wed, 3 Feb 2021 23:46:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nQbfJiLQ/SPm8YAPF7rWvKeLJ7e+fT2QxZ38UfFHuPrF8IffONX/ucCFOfubLKFZXviL86aPrIdWIoRK359EFmb/VhYyM0fP1v1ZIolhYB/9FZQDBMH9xTkN/5mVz1KpSS33gTJGM513u+27IHrU2Tp6peYEzOIhNdlGy4nvDOhCAP1kWVb/WfcksuAPnMO2/U7pviLp0lS5uGfl2vhseklnLCDFUzdSDMjA+N7F3jqzpDTPGbUUMFByiErGepbF9uGXxlIAziH12+qcp6Fx09NP5pWuvWZwU1rBUAebxwGQgR42he+mGO5gAGh0LjXwCqECGs3PwFmWODzxOdYuNw== 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=6YtlCLwy5WzSkTJz4g7Do+swrYzTN7588TeFryDdIc0=; b=He/k5D92BBS+dczuZtZSrKq/b284W+S68qj3fFjO8CINCf9CPPXbVJKSrT/OSRHXLjWCa3TmGtPXmLcGDgTVTZZOPBBZrJjCNfFnL/65GMmUR6t+/Qhw31PZ56Be80uI2lw9M3kKhKLJtmToI+TxjZ9WtnmaOZOJSdjBSwTK5nYae+DhFrFAgw2vaKgFIr6/07wZkW/xlFl1+yVt68Dd78qhw9qAkDUc+qnRYVad2f9NQhkHF8/5sTobmII7ImlXvuDP/7guiYIcvn0J0F02fFlfxGFgktHsj7bcyinshhKoJfebvtGB3W63Q9qxL2YSSEXi6WdWNv9bXlWE0t5Iwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6YtlCLwy5WzSkTJz4g7Do+swrYzTN7588TeFryDdIc0=; b=kPGUv9avLA+kzFJVir+xMyV1DbZMhc7F9+51Q/m86zPi/87U7eIb58iNQaUWz8BqD+FKtJjKXxqxCZEJxBYknWnU62HjHOC8AAEo8hCC9qIhaYgktQIdxGZn52UyW5DT5rdibiIZhBG1KfwmiCXOap/Qoz6/yzoDSsPmyKdKw7I= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3281.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.19; Thu, 4 Feb 2021 07:46:13 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::d199:e33a:ff08:75b1]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::d199:e33a:ff08:75b1%3]) with mapi id 15.20.3784.024; Thu, 4 Feb 2021 07:46:13 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: "spasm@ietf.org" , "saag@ietf.org" Thread-Topic: [lamps] subordinate vs intermediate certification authority Thread-Index: AQHW+qvQK8MOdlfojUuVDnFuO1n7hKpHl3mA Date: Thu, 4 Feb 2021 07:46:13 +0000 Message-ID: References: <30833.1612411843@localhost> In-Reply-To: <30833.1612411843@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-02-04T07:46:12Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=11943578-3948-49cc-9f57-6fb9776ac483; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.160] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3b279ebf-c101-400d-694c-08d8c8e0f24e x-ms-traffictypediagnostic: AM0PR10MB3281: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DvzCoWZqfMo8A4WxNSvKWX1T/mHRHOfiNmsb0yrODzKDObBHt1pZ/HPzKPXUqy4FHKgaEYLe7H5YM8ITv95jEHRo+xiVIbhHjWfbHBkXdM4y6DwxBDu843wxuvlHwOJKB0jAqQmzXHOY2fq2wmAYk6g9YjOIvVZzucNru8RV0MSJ2hiaU9gkxNwVbIhLWsPnEGTmwWjPXAPkXqgUVhvH7F96WNBkP7TMdr9Y56689QLjmW5jKNPAZ1hjT/NqYmwwsI7KqxrfWK4/DuxrF5P9hsWtQihbDyJqEJ2OGBjV98KotPkWBIPeibFcM2XWtCRakxnxRO5ZM6K58I2Dv+iIY7nTAA9xAgoexsLyHpwTcyh0HVbSTEtI80l7qUvbYwybduBWpZOnoiX+7WDKPV8NPavnMmKORLBFTi9BY1upBXE8qtLIjK8g0/rhw+wJ+nME6ZgxOClSa16/0GG5+MdmDAlyxLl05W7vypaCN2plVeZaA1afp2mC43PFGhmPN/6cMMR4yOWVMPx2QvOsqQKV08xvKSV/n9tTJz1meJa/UpZXuvBxp+9RD+gcsk8qIxLoLOsD8ueWo7ZY/gZn7jlZusz11e+KRcmoymb9z/IK0BSjmhirQiZfzMHevX8hv9p2reIGF0rUINFtinpy5WrFNw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(33656002)(16799955002)(5660300002)(8676002)(6506007)(55236004)(7696005)(71200400001)(86362001)(2906002)(9686003)(83080400002)(55016002)(66946007)(478600001)(52536014)(4326008)(45080400002)(66574015)(26005)(8936002)(186003)(54906003)(316002)(966005)(64756008)(66556008)(66476007)(66446008)(76116006)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?7UoqVeGUh95R7ZFPB8o19sDETqzoXlGG7VEzjsmMlOyu9iGPUpYoIGpNgZ?= =?iso-8859-1?Q?tY35YMOhuAXj3aaKHiCrYVqWXndatu5llZLENnQ2iifyEvct4Eh1SBqy90?= =?iso-8859-1?Q?UirAYKC/YsNYvTiERqwDTcwZAsy/7+iZ3guONX/PaqgZUa5tYeWZri6TEz?= =?iso-8859-1?Q?VYWz/aoQt/E5fQ8YFp1C+xY0jnYutgFjX1pYzsViX6ScLCbNFyuLP6sgpr?= =?iso-8859-1?Q?4sp82cpE0ON3iIr5v8ojLc09Ghqt9pPCTmrdoNGMfQLmZcl9LiTkNRp79K?= =?iso-8859-1?Q?gC5SRUb5mpX5LezMvIWu831F1xKQiNcvPrYf9X04lq8z3cmp3SBfJP+U69?= =?iso-8859-1?Q?C3zvYsAZBbrOW8cwLfqbyhw/kaqSFyco4Z5NNuMv421Ziq72BLyt7SwQ+3?= =?iso-8859-1?Q?FgEr9dd+Mxgqj1YfAjpv3w43TtH4DDeBcVTj27EAQQp08OifDcLafygC99?= =?iso-8859-1?Q?HYSYqI4Ag4f7dS7XfbuHkloKfy+sJ9cg+ZwZs6l8te8dJKQy/VQPCfzts8?= =?iso-8859-1?Q?OoOdmAbNExweax1MMyzVBHSLX5CLrriMf380j3OtHXskC51oMqTx9Wm4jZ?= =?iso-8859-1?Q?JTEgX5XjqRMw3+NLmjHp4HPajrryqYBT1rNBaUcvLe4e73rGALgkxnjtlL?= =?iso-8859-1?Q?04PdsQhfHDUwKyix/zueBy8z+yNQnoRfJca/bz6b8714IVcNDTkpmeXG4X?= =?iso-8859-1?Q?K1P/eGWtu7JvzzhqWtflxUjtNALZnqk0HmglCgR7itL/ZHgc/Ox1FQOet1?= =?iso-8859-1?Q?1K82/6lSiV/ri718wZocV4JRipIsygokfziOCtqHuyDywwyQxaQCmriWY5?= =?iso-8859-1?Q?qoMY6IPFsZUALBmijmGup76n8ks6WCkoj9g/7KbKOsxdq95bhdj9wRGzl/?= =?iso-8859-1?Q?O/uEJJ3blneU+4/8loalEz6jmeQZL7IuTTo8jyXYg/6TBlGhri5pm8A1GF?= =?iso-8859-1?Q?+F3w5wiMRKndTtYgTu71LAyh5GOcZFw3ngPJTmyTw2x0EiRIKwzphq90dX?= =?iso-8859-1?Q?xLUqkrtZub35QTovtf9cPnninXysHJnjOsFnRSJ9jelFUQUp+SHkya97Km?= =?iso-8859-1?Q?fRuK/haTqliXV5Paux+5rMu7t1ZbDvpqiUQ/jOdF7Nb7?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3b279ebf-c101-400d-694c-08d8c8e0f24e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2021 07:46:13.5860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oqFbwik/HhgAo8AlMt/Rb2wJwfVgIYhRx9fTaV9vJC4g9ufa1IcVjztmEwxQmBVqf6IxLGfkKMy6aEi50+GKPN5PALBa784oXeShHuu2Ufw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3281 Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 07:46:19 -0000 Michael I also recognized the lack of clear definitions of these terms. May be the definitions in the NIST glossary help. https://csrc.nist.gov/glossary/term/Intermediate_Certification_Authority "intermediate CA A CA that is signed by a superior CA (e.g., a Root CA or another Intermedia= te CA) and signs CAs (e.g., another Intermediate or Subordinate CA). The In= termediate CA exists in the middle of a trust chain between the Trust Ancho= r, or Root, and the subscriber certificate issuing Subordinate CAs. From CN= SSI 4009-2015 CNSSI 1300 A CA that is subordinate to another CA, and has a CA subordinate to itself.= From NIST SP 800-32" https://csrc.nist.gov/glossary/term/superior_CA "superior CA In a hierarchical PKI, a CA who has certified the certificate signature key= of another CA, and who constrains the activities of that CA. (See subordin= ate CA). From NIST SP 800-32" https://csrc.nist.gov/glossary/term/subordinate_CA "subordinate CA In a hierarchical PKI, a CA whose certificate signature key is certified by= another CA, and whose activities are constrained by that other CA. (See su= perior CA). From NIST SP 800-32" The definition of intermediate CA from the NIST glossary differs to the one= in RFC 4949, but I think it fits better for todays use. The definition of = subordinate CA seems to fit well also with RFC 4949. I often read the term "Issuing CA" referring to those CAs issuing end entit= y certificates. https://www.omnisecu.com/security/public-key-infrastructure/certificate-aut= hority-ca-hierarchy.php But I am not aware of any official definition. Sometime the term issuing CA= is also used more general to refer to the CA that's issued any certificate= , not only an end entities. Hendrik > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von Michael Richardson >=20 > I thought I had cross-posted this, but apparently I did not: >=20 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmaila > rchive.ietf.org%2Farch%2Fmsg%2Fanima%2F3tNwWb9gBacdYMTr1TtXzSa_3 > _Q%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C255 > 1cabf1d654a19be8308d8c8c2f242%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1%7C0%7C637480086901728875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200 > 0&sdata=3DGtWLDA9UZnBbTgy4SPKe5GP2PcTnjz9x5SnL2HRxwZY%3D&a > mp;reserved=3D0 >=20 > FC5280 uses the term "intermediate certificates", and they are presumably > issues by "intermediate" certification authorities. >=20 > That term does not appear, although: > "intermediate CA certificates" > occurs. >=20 > RFC4949 defines "intermediate CA" > However, the usage in RFC4949 seems entirely related to cross-certificati= on, > rather than a PKI that has multiple layers of certification authority! >=20 > RFC4949 defines "subordinate CA" in a way that implies it is part of the = same > organization. > RFC5280 uses the term "subordinate" in section 3.2, but later in referrin= g to > RFC1422, notes that in X509v3, we don't need the same structure. > In reading it, it feels that the term subordinate should refer to v1 cert= ificates > only. >=20 > At this point, in 2020, can someone give me some guidance on using these > terms? >=20 > My intuition, which I have started to document at: >=20 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .ietf.org%2Farchive%2Fid%2Fdraft-richardson-t2trg-idevid-considerations- > 01.html%23name-number-of-levels-of- > certifi&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C2551 > cabf1d654a19be8308d8c8c2f242%7C38ae3bcd95794fd4addab42e1495d55a%7 > C1%7C0%7C637480086901728875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200 > 0&sdata=3DabLRY9YWMtjjKzmrCsVgRV8pJj8At2rF74vGzTITV%2B4%3D&a > mp;reserved=3D0 >=20 > is that if the Trust Anchor (Level one) and the Level Two Certification > Authority are under control of the same organization, then the Level Two = is > an "intermediate" certification authority. >=20 > However, if the Anchor (level N) and the Level N+1 certification authorit= y are > in different organizations (such as for an "Enterprise Certificate"), the= n the > Level N+1 is a subordinate CA. >=20 > This question comes from working on draft-ietf-anima-constrained-voucher, > in which we have a number of choices on which certificate (or public key)= to > pin our constrained-RFC8366 voucher. >=20 > -- > Michael Richardson . o O ( IPv6 I=F8T consultin= g ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 From nobody Thu Feb 4 09:13:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035513A169D for ; Thu, 4 Feb 2021 09:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ofe3rV5RA3r4 for ; Thu, 4 Feb 2021 09:13:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580F03A169C for ; Thu, 4 Feb 2021 09:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CD44A389AC for ; Thu, 4 Feb 2021 12:16:18 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oGPitKz1aFnW for ; Thu, 4 Feb 2021 12:16:18 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F40F389AB for ; Thu, 4 Feb 2021 12:16:18 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4BB3B440 for ; Thu, 4 Feb 2021 12:13:22 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <30833.1612411843@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 17:13:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > On Wed, Feb 03, 2021 at 11:10:43PM -0500, Michael Richardson wrote: >> I thought I had cross-posted this, but apparently I did not: >> >> https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_= 3_Q/ >> >> RFC5280 uses the term "intermediate certificates", and they are >> RFC4949 defines "intermediate CA" RFC4949 defines "subordinate CA" in >> a way that implies it is part of the same RFC5280 uses the term >> "subordinate" in section 3.2, but later in referring to >> >> At this point, in 2020, can someone give me some guidance on using >> these terms? > FWIW, in the context of OpenSSL, Postfix, etc., I see/use the terms > "root CA certificate", "intermediate CA certificate" and "end-entity > certificate". Where "root CA certificates" are self-signed, > "end-entity certificates" are the certificates of the peer, and > everything in between is just intermediate certificates. > From a verifier perspective there is little reason to make distictions > on a more granular level. Yes, I agree that there is no important distinction from a chain validation point of view. >> However, if the Anchor (level N) and the Level N+1 certification >> authority are in different organizations (such as for an "Enterprise >> Certificate"), then the Level N+1 is a subordinate CA. > Again, from the vantage point of the verifier, there's no practical w= ay > to know. Some of the Let's Encrypt CA certs are issued by DST others > by ISRG. In common usage, I typically see these referred to as > intermediate certificates, but e.g. the ISRG CPS appears to prefer > "subordinate": That seems to be consistent with my hypothesis that the term "subordinate" represents a split in administrative authority. > So as I see it, "intermediate" and "subordinate" are essentially > synonymous, with some technical communities using the former and othe= rs > the latter to mean basically the same thing. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAcKzIACgkQgItw+93Q 3WU2/ggAue3F+JQsp2/3XqZAAfBIOBfC/FNNA/eKNkrm3ue09+uGcVR0BDXMxkrv jnCLrrSXUzaa1EboZ+MgdPhwvatwDLuqML8ToGP7SLvGjS8zipjmjx92GxK259XW bjBRsWROchZXHDPfNqrKOZhSlPe3uEz0+rtq0dzAKQFdrAgie2wXLIsD28qKeI22 ZSd+Wwc3vcAf5bjTtda+AS3So6/9h1NP5dW9jlz6BMl0MCtaNEgibsoXvUDP7Bqh AoYrfBqpmda2M5ZlePJ/tmxLV/1BgN+Pedbx9972s6YlmkL6Fzv1Zd7To8WmcIT+ Fn69Txgmiu8ApsKWOejrlNowbBRlog== =nrIb -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 4 12:38:42 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F653A17D8 for ; Thu, 4 Feb 2021 12:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j1JeiLP9qQ-P for ; Thu, 4 Feb 2021 12:38:40 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 369B03A17D6 for ; Thu, 4 Feb 2021 12:38:40 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 790F61999E8; Thu, 4 Feb 2021 15:38:38 -0500 (EST) Date: Thu, 4 Feb 2021 15:38:38 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: Reply-To: saag@ietf.org References: <30833.1612411843@localhost> <12683.1612458802@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12683.1612458802@localhost> Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:38:42 -0000 On Thu, Feb 04, 2021 at 12:13:22PM -0500, Michael Richardson wrote: > > > However, if the Anchor (level N) and the Level N+1 certification > > > authority are in different organizations (such as for an "Enterprise > > > Certificate"), then the Level N+1 is a subordinate CA. > > > > Again, from the vantage point of the verifier, there's no practical way > > to know. Some of the Let's Encrypt CA certs are issued by DST others > > by ISRG. In common usage, I typically see these referred to as > > intermediate certificates, but e.g. the ISRG CPS appears to prefer > > "subordinate": > > That seems to be consistent with my hypothesis that the term "subordinate" > represents a split in administrative authority. Sort of, only they explicitly distinguish between affiliate and unaffiliated subordinate CAs, thus implying that the "split" in question is not always a feature of subordinate CAs. The NIST terminology mentioned in this thread makes intermediate a subclass of subordinate, where intermediate CAs issue subordinate CA certs, rather than end-entity certs. My take is that the terminology is all over the place, and I mostly don't care, but where you need to be precise, you need to carefully state the definitions that hold in your document... -- Viktor. From nobody Fri Feb 5 05:16:59 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8052F3A10AD; Fri, 5 Feb 2021 05:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K16E_JnmxLsL; Fri, 5 Feb 2021 05:16:55 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 71DC63A10AC; Fri, 5 Feb 2021 05:16:55 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 2003D3741797; Fri, 5 Feb 2021 13:16:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NzNf9h1ZskjK; Fri, 5 Feb 2021 08:16:52 -0500 (EST) Received: from mpaclmbpt16.local (c-76-25-82-103.hsd1.co.comcast.net [76.25.82.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 764CB37407EA; Fri, 5 Feb 2021 08:16:52 -0500 (EST) To: saag@ietf.org, LAMPS References: <30833.1612411843@localhost> From: "Dr. Pala" Message-ID: <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> Date: Fri, 5 Feb 2021 06:16:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <30833.1612411843@localhost> Content-Type: multipart/alternative; boundary="------------847E93771384AC8898E19781" Content-Language: en-US Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 13:16:58 -0000 This is a multi-part message in MIME format. --------------847E93771384AC8898E19781 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Michael, all, I would not add specific significance to terminology that has been used interchangeably for many years. In the public eye "Intermediate CA" or "Subordinate CA" are equivalent (used in different contexts, though). If you want to make the distinction because in your work you want to differentiate if a CA is run by the same organization that runs the Trust Anchors, I would suggest you make it very explicit in the text so as not to confuse people. Developers and Practitioners (see the note on OpenSSL's conventions) seem to support more the "Intermediate CA" for technical conversations while "Subordinate CA" is usually referred to in the context of PKI policies. RFC3647 talks about subordinate organizations instead - maybe that is the concept you need to use? What is weird about the question is the different logical levels that you are trying to put together: business relationships and certification chains. I hope this helps, Cheers, Max On 2/3/21 9:10 PM, Michael Richardson wrote: > I thought I had cross-posted this, but apparently I did not: > https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/ > > FC5280 uses the term "intermediate certificates", and they are presumably > issues by "intermediate" certification authorities. > > That term does not appear, although: > "intermediate CA certificates" > occurs. > > RFC4949 defines "intermediate CA" > However, the usage in RFC4949 seems entirely related to cross-certification, > rather than a PKI that has multiple layers of certification authority! > > RFC4949 defines "subordinate CA" in a way that implies it is part of the same > organization. > RFC5280 uses the term "subordinate" in section 3.2, but later in referring to > RFC1422, notes that in X509v3, we don't need the same structure. > In reading it, it feels that the term subordinate should refer to v1 > certificates only. > > At this point, in 2020, can someone give me some guidance on using these terms? > > My intuition, which I have started to document at: > https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerations-01.html#name-number-of-levels-of-certifi > > is that if the Trust Anchor (Level one) and the Level Two Certification > Authority are under control of the same organization, then the Level Two is > an "intermediate" certification authority. > > However, if the Anchor (level N) and the Level N+1 certification authority > are in different organizations (such as for an "Enterprise Certificate"), > then the Level N+1 is a subordinate CA. > > This question comes from working on draft-ietf-anima-constrained-voucher, > in which we have a number of choices on which certificate (or public key) to > pin our constrained-RFC8366 voucher. > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------847E93771384AC8898E19781 Content-Type: multipart/related; boundary="------------3D929DE761027B9F4E2D0E3B" --------------3D929DE761027B9F4E2D0E3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Michael, all,

I would not add specific significance to terminology that has been used interchangeably for many years. In the public eye "Intermediate CA" or "Subordinate CA" are equivalent (used in different contexts, though). If you want to make the distinction because in your work you want to differentiate if a CA is run by the same organization that runs the Trust Anchors, I would suggest you make it very explicit in the text so as not to confuse people.

Developers and Practitioners (see the note on OpenSSL's conventions) seem to support more the "Intermediate CA" for technical conversations while "Subordinate CA" is usually referred to in the context of PKI policies.

RFC3647 talks about subordinate organizations instead - maybe that is the concept you need to use? What is weird about the question is the different logical levels that you are trying to put together: business relationships and certification chains.

I hope this helps,

Cheers,
Max

On 2/3/21 9:10 PM, Michael Richardson wrote:
I thought I had cross-posted this, but apparently I did not:
  https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/

FC5280 uses the term "intermediate certificates", and they are presumably
issues by "intermediate" certification authorities.

That term does not appear, although:
     "intermediate CA certificates"
occurs.

RFC4949 defines "intermediate CA"
However, the usage in RFC4949 seems entirely related to cross-certification,
rather than a PKI that has multiple layers of certification authority!

RFC4949 defines "subordinate CA" in a way that implies it is part of the same
organization.
RFC5280 uses the term "subordinate" in section 3.2, but later in referring to
RFC1422, notes that in X509v3, we don't need the same structure.
In reading it, it feels that the term subordinate should refer to v1
certificates only.

At this point, in 2020, can someone give me some guidance on using these terms?

My intuition, which I have started to document at:
   https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerations-01.html#name-number-of-levels-of-certifi

is that if the Trust Anchor (Level one) and the Level Two Certification
Authority are under control of the same organization, then the Level Two is
an "intermediate" certification authority.

However, if the Anchor (level N) and the Level N+1 certification authority
are in different organizations (such as for an "Enterprise Certificate"),
then the Level N+1 is a subordinate CA.

This question comes from working on draft-ietf-anima-constrained-voucher,
in which we have a number of choices on which certificate (or public key) to
pin our constrained-RFC8366 voucher.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide






_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------3D929DE761027B9F4E2D0E3B Content-Type: image/png; name="ckhdfkchkaobcdfd.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ckhdfkchkaobcdfd.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------3D929DE761027B9F4E2D0E3B-- --------------847E93771384AC8898E19781-- From nobody Sat Feb 6 12:42:17 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65F3A2BCC; Sat, 6 Feb 2021 12:42:15 -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 45M3JHsyZ0iE; Sat, 6 Feb 2021 12:42:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4543A2BCA; Sat, 6 Feb 2021 12:42:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BCC9389A9; Sat, 6 Feb 2021 15:45:16 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eiBt7iXOtsDl; Sat, 6 Feb 2021 15:45:15 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40DC0389A7; Sat, 6 Feb 2021 15:45:15 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 28F69585; Sat, 6 Feb 2021 15:42:11 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , "saag\@ietf.org" cc: "Brockhaus\, Hendrik" In-Reply-To: References: <30833.1612411843@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 20:42:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the many emails on this; I think that it was useful to me. Brockhaus, Hendrik wrote: > I also recognized the lack of clear definitions of these terms. > May be the definitions in the NIST glossary help. Thanks, that's a good place to go. I think that the NIST definitions are probably good enough for now. (I wish revising RFC4949 was cheaper) > From NIST SP 800-32" > https://csrc.nist.gov/glossary/term/subordinate_CA "subordinate CA In= a > hierarchical PKI, a CA whose certificate signature key is certified by > another CA, and whose activities are constrained by that other CA. (S= ee > superior CA). From NIST SP 800-32" > The definition of intermediate CA from the NIST glossary differs to t= he > one in RFC 4949, but I think it fits better for todays use. The > definition of subordinate CA seems to fit well also with RFC 4949. ... my conclusion is that mostly, the terms are interchangeable, but that "subordinate" might be used when there is a clearer "constrained". For instance, if there were a Path Constraint by the superior CA. Or: all subordinate CAs are intermediate CAs, but not vv. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAe/yIACgkQgItw+93Q 3WV0WQf+OXNtAx6ydlsHF4ZeXgo7xRy4lQssIBs+TyxKjEV+jNQTNGXulB97mMXr 3eTEgho6QE0uLqGtdxHmnM6TH0BqwfSjL1WFAb5amR0Z2HHmXoy2AfF7mEECWC+Q USoILYOfmwwx4CB2TcPne0DjD9vJRRTzmNA9LMEcKdnAb63PeRMTbgiZkIaidvZB /1NFLndoJRjE00H+H55SiN5zxhcHU1Y+3ZgueaCbkv8VcAFQQbAhohOhyhMOgKdE Kwda8vN95EMFzODgB77HK5pMKmV09/Yfv9UnXizcIW6ptvStyxi10KYHTAabvAGP Y2FYg1RurMIK48bpOnKTozz7G8DDCg== =/i3B -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 12:49:04 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645243A2BD0 for ; Sat, 6 Feb 2021 12:49:03 -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 JLzk20rxN3gl for ; Sat, 6 Feb 2021 12:49:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333623A2BD1 for ; Sat, 6 Feb 2021 12:49:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F26EC389A9 for ; Sat, 6 Feb 2021 15:52:03 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WsoAYHPX5Oxt for ; Sat, 6 Feb 2021 15:52:03 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 88C77389A7 for ; Sat, 6 Feb 2021 15:52:03 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6AAEF585 for ; Sat, 6 Feb 2021 15:48:59 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <30833.1612411843@localhost> <12683.1612458802@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 20:49:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > The NIST terminology mentioned in this thread makes intermediate a > subclass of subordinate, where intermediate CAs issue subordinate CA > certs, rather than end-entity certs. Yes, this comment made me go back and re-read the definition again, and a light went on. > My take is that the terminology is all over the place, and I mostly > don't care, but where you need to be precise, you need to carefully > state the definitions that hold in your document... It sure seems like might be a place where doing it once (in a new document)= might help. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAfALsACgkQgItw+93Q 3WWdLggAtZ8OSCWR8QYyWBqO6L2tNRD4sElP0yHAmsTLeFo4N6bMJz/6E4vl+wtu Gqnb/wTrTBpWNO3vkkKyzFUa2yRrtm4qKgUQEbuTDtHGZHESy7WKW7C2jDRzsUIC WhRkvAurHrm44gZ3E3cuQwptSjpjxUtmFJHF605uyD61H1CBd7fYmrhuq7XMmP28 uAceojqiJ7MvVrVC9cDRibxveD3s1ybB8zGWJvILiATEG+oQmoslXl4627goIklg noBsFTGruJkXo/g/vjlHHq31k3tc++ktu1c0SFHDOsWoqBBKusk+Pxtoh/IMmEG7 Og0amDlrNQ0s64SZceuvAlGC131PLA== =E364 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 12:59:43 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9233A2BF9; Sat, 6 Feb 2021 12:59:41 -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 ZgIqH8Dk16_M; Sat, 6 Feb 2021 12:59:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC2D3A2BF6; Sat, 6 Feb 2021 12:59:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F622389A9; Sat, 6 Feb 2021 16:02:42 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hDdSY-R-YSTU; Sat, 6 Feb 2021 16:02:41 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D0BA7389A7; Sat, 6 Feb 2021 16:02:41 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AD6A7585; Sat, 6 Feb 2021 15:59:37 -0500 (EST) From: Michael Richardson To: "Dr. Pala" cc: saag@ietf.org, LAMPS In-Reply-To: <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 20:59:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dr. Pala wrote: > Developers and Practitioners (see the note on OpenSSL's conventions) > seem to support more the "Intermediate CA" for technical conversations > while "Subordinate CA" is usually referred to in the context of PKI > policies. I think that this is the key point which you are supporting. > RFC3647 talks about subordinate organizations instead - maybe that is > the concept you need to use? What is weird about the question is the > different logical levels that you are trying to put together: business > relationships and certification chains. The issue comes up with pinning as it relates to ownership. It's not a problem if every organization that can own Things has it's own private CA. Pinning that CA works great. Pinning some other EE is very much more specific, but also, may be too ephe= meral. Where it gets complex is when organizations have outsourced the CA function= elsewhere. It's meaningless to pin LetsEncrypt or GoDaddy. It might be meaningful to pin a Subordinate CA signed by some public CA though. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAfAzkACgkQgItw+93Q 3WWUfAf9Gm1wDa2Z46Oc3GHHjXb5be0Mar3zSWXJ+11yLW8w9jnFZOEML+j2Eghy unz9yawHQmPy5z5Od93SKx+PMfGEEoC+tEZOfkoDOWlHvPJB30xsRwwqLVIN5P+q u1xeCrWHJ/Z2Ho1/bLwhDUV3tDzfvji79SxbzRIj1b3BOBbG2pfSw9T/axB/9+3w ukH7tQAzgr+qm/Sp9Bwj7/0bKTav4zciHXrU9P6A8g7wqmFT8QvGTyzmStEJ0lHc U1KdEJDC5ebOSYwKqeASS9HLbcg0Z47rBRikf+XzkJvfmRCnBDxbwrRDlyMoP/LT A5CIox5491u0dqBHy/qTpfTIHOn6sw== =W4B1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 6 13:34:08 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31F3A2C5B for ; Sat, 6 Feb 2021 13:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.997] 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 t1ahpW-KOtEL for ; Sat, 6 Feb 2021 13:34:05 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 BBAAC3A2C5A for ; Sat, 6 Feb 2021 13:34:04 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 324551A1FA4; Sat, 6 Feb 2021 16:34:02 -0500 (EST) Date: Sat, 6 Feb 2021 16:34:02 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: Reply-To: saag@ietf.org References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6108.1612645177@localhost> Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 21:34:07 -0000 On Sat, Feb 06, 2021 at 03:59:37PM -0500, Michael Richardson wrote: > The issue comes up with pinning as it relates to ownership. It's not > a problem if every organization that can own Things has it's own > private CA. Pinning that CA works great. Pinning some other EE is > very much more specific, but also, may be too ephemeral. > > Where it gets complex is when organizations have outsourced the CA > function elsewhere. It's meaningless to pin LetsEncrypt or GoDaddy. > It might be meaningful to pin a Subordinate CA signed by some public > CA though. Are you trying to get at generalising the issue described at: http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html (where I track sloppy SMTP server operators who've pinned the now retired Let's Encrypt "X3" CA, and have failed to keep up with the times)? The number of MX hosts with such TLSA RRs is falling as they eventually notice (or the issue is brought to their attention). And, fortunately, with DANE TLSA RRs published in their DNS zone, they can update the pin on their end, without having to ask the world to update some local copy. There is a tiny population of SMTP operators who've attempted to publish TLSA RRs that pin the EE public key of a provider's SMTP server they don't control. That's a mistake, and they eventually figure this out and drop unmaintainable TLSA RRs for servers they don't control. -- Viktor. From nobody Sat Feb 6 18:04:42 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA84F3A2E64 for ; Sat, 6 Feb 2021 18:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yu0j1MWmGvGC for ; Sat, 6 Feb 2021 18:04:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A18D3A2E61 for ; Sat, 6 Feb 2021 18:04:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D5333389A9 for ; Sat, 6 Feb 2021 21:07:40 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id akeoLwR4J-Vp for ; Sat, 6 Feb 2021 21:07:39 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 18988389A7 for ; Sat, 6 Feb 2021 21:07:39 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 26451C65 for ; Sat, 6 Feb 2021 21:04:34 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 02:04:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > On Sat, Feb 06, 2021 at 03:59:37PM -0500, Michael Richardson wrote: >> The issue comes up with pinning as it relates to ownership. It's not >> a problem if every organization that can own Things has it's own >> private CA. Pinning that CA works great. Pinning some other EE is >> very much more specific, but also, may be too ephemeral. >> >> Where it gets complex is when organizations have outsourced the CA >> function elsewhere. It's meaningless to pin LetsEncrypt or GoDaddy. >> It might be meaningful to pin a Subordinate CA signed by some public >> CA though. > Are you trying to get at generalising the issue described at: > http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html Hi, that's a very interesting read, and I also haven't seen the diagram at: https://letsencrypt.org/certificates/#intermediate-certificates I also really like the rounded box with the wave bottom to represent a cert= ificate. I've been looking for a good icon for certificates, it seems for years :-) > (where I track sloppy SMTP server operators who've pinned the now > retired Let's Encrypt "X3" CA, and have failed to keep up with the > times)? As I understand your page, this is case where example.com is declaring via DANE-TA what their intended CA is. Because of the way that LE is changing their PKI structure, the declared pin point is no longer the "DST Root CA X= 3", but now R3/E1/R4/E1. But, why would they pin that, rather than X1/X2? Ah, I guess because X1/X2 also sign CAs other than LetsEncrypt. So this is where the issue is similar. The difference is that the pinning is not being declared by the serving ent= ity, but rather by the client entity. (Mostly, this is not TOFU, btw) > The number of MX hosts with such TLSA RRs is falling as they eventual= ly > notice (or the issue is brought to their attention). And, fortunatel= y, > with DANE TLSA RRs published in their DNS zone, they can update the p= in > on their end, without having to ask the world to update some local > copy. Yes, it makes sense to do it this way here. > There is a tiny population of SMTP operators who've attempted to > publish TLSA RRs that pin the EE public key of a provider's SMTP serv= er > they don't control. That's a mistake, and they eventually figure this > out and drop unmaintainable TLSA RRs for servers they don't control. An analogy, perhaps imperfect, to email operations would be an MUA which was attempting to pin the key of their IMAPS/SMTP-submit server. For a provider to which they believe they have a relationship with, in the sense that their provider owns their mailbox. This analogy could go further, and perhaps it should continue in DANISH. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAfSrEACgkQgItw+93Q 3WXabwf/ZpDKR86jU5C6vUNqVKmoiKtt0w3tLiO2iqmeYgVXsGgIjWHrndIHNBrm vYtnexUgaSTqgxQL+BxzjePpNEsEo0SPMJ6vkDrtBT9WyaWBOuJMUWkLA27TRDdN ySVbXXbVItshalaMto7LMmsAISjGYjQrnII8L4rZQKKh8oWWgFeVxLAd+cmGUz47 4Ab/wZNeL9ZMD5MTg2YLe1ZN6FsSgy3Z/L2hGBOKOlCk8zR9qeQam9zxOJunLW7s qSA2ESBXT6druos6iptWeFjFifHclCfMz0snXlmmNpipd3Q5ixHQuTUk2I5ufO1R TfVVac3Sy/qT76l65uqtol21cOBUpQ== =76sr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 7 19:33:17 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D273A113C; Tue, 2 Feb 2021 12:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7rung3_0e_1; Tue, 2 Feb 2021 12:07:12 -0800 (PST) Received: from vmi146817.contaboserver.net (vmi146817.contaboserver.net [173.249.7.138]) (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 998273A113E; Tue, 2 Feb 2021 12:07:09 -0800 (PST) Received: from [192.168.2.9] (ppp089210046222.access.hol.gr [89.210.46.222]) by vmi146817.contaboserver.net (Postfix) with ESMTPSA id B44852F26FF; Tue, 2 Feb 2021 21:06:36 +0100 (CET) Authentication-Results: vmi146817.contaboserver.net; spf=pass (sender IP is 89.210.46.222) smtp.mailfrom=info@ieee-csr.org smtp.helo=[192.168.2.9] Received-SPF: pass (vmi146817.contaboserver.net: connection is authenticated) From: "info@ieee-csr.org" Content-Type: multipart/alternative; boundary="Apple-Mail=_15C5905D-14E0-4855-9E07-CCBA0814AB56" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 2 Feb 2021 22:06:34 +0200 Message-Id: To: info@ieee-csr.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-PPP-Message-ID: <161229642687.2761.13135248650190527096@vmi146817.contaboserver.net> X-PPP-Vhost: ieee-csr.org Archived-At: X-Mailman-Approved-At: Sun, 07 Feb 2021 19:33:16 -0800 Subject: [saag] [CFP] 2021 IEEE International Conference on Cyber Security and Resilience (Virtual Event) -- Deadline approaching X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 20:07:16 -0000 --Apple-Mail=_15C5905D-14E0-4855-9E07-CCBA0814AB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Please accept our apologies for cross-postings] [UPDATE: CSR IS NOW A VIRTUAL EVENT] = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D C a l l F o r P a p e r s 2021 IEEE International Conference on Cyber Security and Resilience = (IEEE CSR 2021) Virtual Conference | July 26-28, 2021 https://www.ieee-csr.org/ =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D The IEEE International Conference on Cyber Security and Resilience (IEEE = CSR) is an annual event sponsored by the IEEE Systems, Man, and = Cybernetics (SMC) Society. DESCRIPTION & SCOPE ------------------- The technological and industrial revolution brought by complex = Cyber-Physical Systems (CPSs) comes with new threats and cyber-attacks = that exploit their inherent complexity and heterogeneity. Systems under = attack, should exhibit cyber resilience, i.e. a mixture of strategies, = methods, and techniques to support complex CPS adaptive capacity during = cyber-attacks. The conference focuses on theoretical and practical = aspects of the security, privacy, trust, and resilience of networks, = systems, and services as well as novel ways for dealing with their = vulnerabilities and mitigating sophisticated cyber-attacks. TOPICS OF INTEREST ------------------ Prospective authors are encouraged to submit previously unpublished = contributions from a broad range of topics, which include but are not = limited to the following: Cyber security =E2=80=BA DLT/smart contract security =E2=80=BA Cyber-security and AI =E2=80=BA Cyber-threat intelligence =E2=80=BA Malicious cryptography =E2=80=BA Moving target defense =E2=80=BA Network intrusion detection =E2=80=BA Post-quantum security =E2=80=BA Privacy and data protection Cyber resilience =E2=80=BA AI for resilience management =E2=80=BA Attack resilient architectures =E2=80=BA Cyber-range platforms =E2=80=BA Cyber-risk forecasting =E2=80=BA Cyber-security training =E2=80=BA Dynamic risk management =E2=80=BA Gamification in security =E2=80=BA SDN security Complex CPS security =E2=80=BA Automotive security =E2=80=BA Critical infrastructure security =E2=80=BA ICS security =E2=80=BA Industrial IoT security =E2=80=BA IoT and cloud forensics =E2=80=BA Smart cities security =E2=80=BA Smart grid security =E2=80=BA Virtualization security The complete list of topics can be found at the PDF version of the CFP: = https://www.ieee-csr.org/IEEE_CSR_CFP.pdf = =20 IMPORTANT DATES --------------- Paper submission deadline: February 15, 2021 Authors' notification: April 12, 2021 Camera-ready submission: May 10, 2021 Early registration deadline: May 31, 2021 SUBMISSION GUIDELINES --------------------- The IEEE CSR 2021 conference will accept high-quality regular research = papers, Systematization of Knowledge (SoK) papers, and industrial = papers. The IEEE CSR 2021 also hosts workshops that specialize into the = conference=E2=80=99s areas or focus on high-quality applied research and = innovation results obtained from cyber-security and resilience projects. Submitted manuscripts should not exceed 6 pages (plus 2 extra pages, = being subject to overlength page charges) and should be of sufficient = detail to be evaluated by expert reviewers in the field. The conference = (including workshops) proceedings will be published by IEEE and will be = included in IEEE Xplore. The authors of selected accepted papers will be invited to submit an = extended version to special issues of international journals. Detailed = information about the paper submission and guidelines to authors have = been posted on the IEEE CSR 2021 conference website = https://www.ieee-csr.org . CONFERENCE CHAIRS ----------------- Stavros Shiaeles, University of Portsmouth (stavros.shiaeles@port.ac.uk = ) Nicholas Kolokotronis, University of Peloponnese (nkolok@uop.gr = ) Emanuele Bellini, University of Campania (emanuele.bellini@ieee.org = ) CONTACT US ---------- info@ieee-csr.org = --Apple-Mail=_15C5905D-14E0-4855-9E07-CCBA0814AB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Please accept our apologies = for cross-postings]
[UPDATE: CSR = IS NOW A VIRTUAL EVENT]


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
C a l l   F o r   P = a p e r s

2021 IEEE International = Conference on Cyber Security and Resilience (IEEE CSR 2021)
Virtual Conference | July 26-28, 2021

https://www.ieee-csr.org/ 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


The IEEE International Conference on Cyber Security and = Resilience (IEEE CSR) is an annual event sponsored by the IEEE Systems, = Man, and Cybernetics (SMC) Society.


DESCRIPTION & SCOPE
-------------------
The technological and industrial revolution brought by = complex Cyber-Physical Systems (CPSs) comes with new threats and = cyber-attacks that exploit their inherent complexity and heterogeneity. = Systems under attack, should exhibit cyber resilience, i.e. a = mixture of strategies, methods, and techniques to support complex CPS = adaptive capacity during cyber-attacks. The conference focuses on = theoretical and practical aspects of the security, privacy, trust, and = resilience of networks, systems, and services as well as novel ways = for dealing with their vulnerabilities and mitigating sophisticated = cyber-attacks.


TOPICS OF = INTEREST
------------------
Prospective = authors are encouraged to submit previously unpublished contributions = from a broad range of topics, which include but are not limited to the = following:

Cyber security
=E2=80=BA DLT/smart contract security
=E2=80=BA Cyber-security and AI
=E2=80=BA Cyber-threat intelligence
=E2=80=BA = Malicious cryptography
=E2=80=BA Moving target defense
=E2=80=BA Network intrusion detection
=E2=80=BA = Post-quantum security
=E2=80=BA Privacy and data = protection

Cyber = resilience
=E2=80=BA AI for resilience management
=E2=80=BA Attack resilient architectures
=E2=80=BA= Cyber-range platforms
=E2=80=BA Cyber-risk forecasting
=E2=80=BA Cyber-security training
=E2=80=BA = Dynamic risk management
=E2=80=BA Gamification in = security
=E2=80=BA SDN security

Complex CPS security
=E2=80=BA = Automotive security
=E2=80=BA Critical infrastructure = security
=E2=80=BA ICS security
=E2=80=BA = Industrial IoT security
=E2=80=BA IoT and cloud = forensics
=E2=80=BA Smart cities security
=E2=80= =BA Smart grid security
=E2=80=BA Virtualization = security

The complete list of topics can be = found at the PDF version of the CFP: https://www.ieee-csr.org/IEEE_CSR_CFP.pdf 


IMPORTANT DATES
---------------
Paper submission deadline: = February 15, 2021
Authors' notification: April 12, 2021
Camera-ready submission: May 10, 2021
Early = registration deadline: May 31, 2021


SUBMISSION GUIDELINES
---------------------
The IEEE CSR 2021 conference will accept high-quality regular = research papers, Systematization of Knowledge (SoK) papers, and = industrial papers. The IEEE CSR 2021 also hosts workshops that = specialize into the conference=E2=80=99s areas or focus = on high-quality applied research and innovation results obtained = from cyber-security and resilience projects.

Submitted manuscripts should not exceed 6 pages (plus 2 extra = pages, being subject to overlength page charges) and should be of = sufficient detail to be evaluated by expert reviewers in the = field. The conference (including workshops) proceedings will be = published by IEEE and will be included in IEEE = Xplore.
The authors of selected accepted papers will be invited to = submit an extended version to special issues of international = journals. Detailed information about the paper submission and = guidelines to authors have been posted on the IEEE CSR 2021 conference = website https://www.ieee-csr.org.


CONFERENCE CHAIRS
-----------------
Stavros Shiaeles, University of Portsmouth (stavros.shiaeles@port.ac.uk)
Nicholas = Kolokotronis, University of Peloponnese (nkolok@uop.gr)
Emanuele Bellini, University = of Campania (emanuele.bellini@ieee.org)


CONTACT US
----------
info@ieee-csr.org
= --Apple-Mail=_15C5905D-14E0-4855-9E07-CCBA0814AB56-- From nobody Mon Feb 8 08:49:13 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF93A11D7; Mon, 8 Feb 2021 08:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fE5k7yk6jSrB; Mon, 8 Feb 2021 08:49:09 -0800 (PST) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.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 821463A11CB; Mon, 8 Feb 2021 08:49:09 -0800 (PST) Received: by mail-pg1-f174.google.com with SMTP id o63so10589840pgo.6; Mon, 08 Feb 2021 08:49:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/PmIdNiSFVMYarXRVUE4N7d0ZMet8Qr6NOF9pg+w6KA=; b=TYFpCcAYAR2yvIKijSH0Q20pSfv+dPsNV80umeUi2IXr0fdPWkMprVYEPZqMgujjKu aPiV0aYI81qjfE5Nla6h9lmx/S5v6k6dTSUjcemhOPx2SlWD4c1QmcZXyT1COFCLAo5Z WOYlSbv36T/ffKVEsE5zTvGn798Ti8jR/71H9HplSgHBI7YcElSqoEw4fWCubcYNTvzo MNKqw0yjh7iaC4poiGvlk/WZjbscOS3QnEyR94JTq3O9+y5y0iTMB6KE/kRJxTt8VZHj DLlk+xBRo777stpHVUw36Cmnc3XEV8Do9pog14ACgQsX+A/TK3MNIxEhMtM8JcIcjFgJ bXFw== X-Gm-Message-State: AOAM533Ee2JmNNTaklC5kReys+nG7ustVvgfCtYtdltM+HtI1pxTQYHc Lr7SnrXnxSt7UPPDtNLwxcf/wKs9Euo= X-Google-Smtp-Source: ABdhPJw1DVbWuczsZj9jyE4NqAyxzEkpFoR51w6W5AT4qyfoNqdV5+iTPKw86XqClO/4fksFlPa/xA== X-Received: by 2002:a62:e407:0:b029:1dc:1ef6:b2da with SMTP id r7-20020a62e4070000b02901dc1ef6b2damr7366126pfh.67.1612802948586; Mon, 08 Feb 2021 08:49:08 -0800 (PST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id l2sm17041752pju.25.2021.02.08.08.49.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 08:49:07 -0800 (PST) Received: by mail-pl1-f173.google.com with SMTP id g3so8138271plp.2; Mon, 08 Feb 2021 08:49:07 -0800 (PST) X-Received: by 2002:a17:902:464:b029:e2:ebb4:9251 with SMTP id 91-20020a1709020464b02900e2ebb49251mr2087047ple.29.1612802947750; Mon, 08 Feb 2021 08:49:07 -0800 (PST) MIME-Version: 1.0 References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> In-Reply-To: <6108.1612645177@localhost> From: Ryan Sleevi Date: Mon, 8 Feb 2021 11:48:57 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Michael Richardson Cc: "Dr. Pala" , LAMPS , saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb219005bad5f2ba" Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 16:49:11 -0000 --000000000000cb219005bad5f2ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 6, 2021 at 4:00 PM Michael Richardson wrote: > > Dr. Pala wrote: > > Developers and Practitioners (see the note on OpenSSL's conventions= ) > > seem to support more the "Intermediate CA" for technical > conversations > > while "Subordinate CA" is usually referred to in the context of PKI > > policies. > > I think that this is the key point which you are supporting. > > > RFC3647 talks about subordinate organizations instead - maybe that = is > > the concept you need to use? What is weird about the question is th= e > > different logical levels that you are trying to put together: > business > > relationships and certification chains. > > The issue comes up with pinning as it relates to ownership. > It's not a problem if every organization that can own Things has it's own > private CA. Pinning that CA works great. > Pinning some other EE is very much more specific, but also, may be too > ephemeral. > > Where it gets complex is when organizations have outsourced the CA > function elsewhere. > It's meaningless to pin LetsEncrypt or GoDaddy. It might be meaningful t= o > pin a Subordinate CA signed by some public CA though. > No one, anywhere, should ever pin to a CA that they don=E2=80=99t directly = control, and even then, they still shouldn=E2=80=99t :) Pinning is just a poor-man=E2=80=99s attempt at a server controlling the cl= ient=E2=80=99s trust anchors, and thus inevitably runs into issues, since client policy is inherently _client_ policy. Especially important is never pinning to a so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their very existen= ce is predicated on client policy that is intentionally not controlled/controllable by servers. I stand by the statement that is mostly misguided to highlight any distinction between these terms (subordinate and intermediate). The model of PKI that 3647 envisioned, tied to The Directory, doesn=E2=80=99t exist. = While it provides a useful framework, the model of policy and business relationships is not a generic model in practice, unfortunately, and so one cannot just liberally sprinkle the terms in and expect there to be a distinction of note to the reader. In general, it should be a red flag if such a distinction is necessary, because it=E2=80=99s indicative of an assumption of human-/business-/policy= -based practices, vs technical practices, and thus inevitably going to cause significant interoperability issues, as both humans and policies are rarely all alike and identical. --000000000000cb219005bad5f2ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 6, 2021 at 4:00 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:<= br>

Dr. Pala <madwol= f@openca.org> wrote:
=C2=A0 =C2=A0 > Developers and Practitioners (see the note on OpenSSL= 9;s conventions)
=C2=A0 =C2=A0 > seem to support more the "Intermediate CA" for= technical conversations
=C2=A0 =C2=A0 > while "Subordinate CA" is usually referred to = in the context of PKI
=C2=A0 =C2=A0 > policies.

I think that this is the key point which you are supporting.

=C2=A0 =C2=A0 > RFC3647 talks about subordinate organizations instead - = maybe that is
=C2=A0 =C2=A0 > the concept you need to use? What is weird about the que= stion is the
=C2=A0 =C2=A0 > different logical levels that you are trying to put toge= ther: business
=C2=A0 =C2=A0 > relationships and certification chains.

The issue comes up with pinning as it relates to ownership.
It's not a problem if every organization that can own Things has it'= ;s own
private CA.=C2=A0 Pinning that CA works great.
Pinning some other EE is very much more specific, but also, may be too ephe= meral.

Where it gets complex is when organizations have outsourced the CA function= elsewhere.
It's meaningless to pin LetsEncrypt or GoDaddy.=C2=A0 It might be meani= ngful to
pin a Subordinate CA signed by some public CA though.

No one, anywhere, should ever pin = to a CA that they don=E2=80=99t directly control, and even then, they still= shouldn=E2=80=99t :)

Pi= nning is just a poor-man=E2=80=99s attempt at a server controlling the clie= nt=E2=80=99s trust anchors, and thus inevitably runs into issues, since cli= ent policy is inherently _client_ policy. Especially important is never pin= ning to a so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their ve= ry existence is predicated on client policy that is intentionally not contr= olled/controllable by servers.

I stand by the statement that is mostly misguided to highlight any d= istinction between these terms (subordinate and intermediate). The model of= PKI that 3647 envisioned, tied to The Directory, doesn=E2=80=99t exist. Wh= ile it provides a useful framework, the model of policy and business relati= onships is not a generic model in practice, unfortunately, and so one canno= t just liberally sprinkle the terms in and expect there to be a distinction= of note to the reader.

= In general, it should be a red flag if such a distinction is necessary, bec= ause it=E2=80=99s indicative of an assumption of human-/business-/policy-ba= sed practices, vs technical practices, and thus inevitably going to cause s= ignificant interoperability issues, as both humans and policies are rarely = all alike and identical.
--000000000000cb219005bad5f2ba-- From nobody Mon Feb 8 09:13:51 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA53A138C; Mon, 8 Feb 2021 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP_TBmL4xRml; Mon, 8 Feb 2021 09:13:47 -0800 (PST) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 798A33A10F6; Mon, 8 Feb 2021 09:13:47 -0800 (PST) Received: by mail-yb1-f179.google.com with SMTP id p193so1575496yba.4; Mon, 08 Feb 2021 09:13:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s4WblOnNPSthSXULpKE2D7aCKxRsiy3G6JBo0TZRx1k=; b=EIBiqfjo9Cl98V8fG0WnH53AJ7xyaLn+lIAVLZc0J9pqBrwNvsUh0G7xNYyDTZab2C +ZyAO16FET9X9W0TfWSwHl+O0WChwp0SPTWf9GTrqfAZckiDX4oAeO6KBnP6zHzmewGP o9DGqTrOgdX53eCXVv1dG34IwIuD82meil81spOPEAXoQ3NhyV3gI8EVtFFpeLOc+5l/ wdJVQ2Ud4coc58gxm1MgZDqnrT2aNu7JgflY9BokvNk6UDCN5TBI/pWh1aOB8t75XZUh KEooJx0Nkvcy20LMICuQ2mXugqNmlhra3Dutci5zkEWqbjZDnXqeJJj0n1tTe5UR8yq2 gJhg== X-Gm-Message-State: AOAM5300vRnLlB1J73fL+I9B+SApIWihsdLxyweTyQYyBOgOnQAU47IG Z/4QLuL5IrmJkiHxWDf05Sn2xKim9qCUnW9NChE= X-Google-Smtp-Source: ABdhPJzS4SVBI3RASd9+KvzXGhIk0chpwKLfQsy5BFt6Nm4qxwzwT8ujPeKFZdp8OtKbnr6GwxROsl2Puo5jrL5kLmU= X-Received: by 2002:a25:c5c1:: with SMTP id v184mr26934187ybe.56.1612804426627; Mon, 08 Feb 2021 09:13:46 -0800 (PST) MIME-Version: 1.0 References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 8 Feb 2021 12:13:36 -0500 Message-ID: To: Ryan Sleevi Cc: Michael Richardson , LAMPS , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000f0fd1805bad64a64" Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 17:13:49 -0000 --000000000000f0fd1805bad64a64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 8, 2021 at 11:49 AM Ryan Sleevi wrote: > > > On Sat, Feb 6, 2021 at 4:00 PM Michael Richardson > wrote: > >> >> Dr. Pala wrote: >> > Developers and Practitioners (see the note on OpenSSL's convention= s) >> > seem to support more the "Intermediate CA" for technical >> conversations >> > while "Subordinate CA" is usually referred to in the context of PK= I >> > policies. >> >> I think that this is the key point which you are supporting. >> >> > RFC3647 talks about subordinate organizations instead - maybe that >> is >> > the concept you need to use? What is weird about the question is t= he >> > different logical levels that you are trying to put together: >> business >> > relationships and certification chains. >> >> The issue comes up with pinning as it relates to ownership. >> It's not a problem if every organization that can own Things has it's ow= n >> private CA. Pinning that CA works great. >> Pinning some other EE is very much more specific, but also, may be too >> ephemeral. >> >> Where it gets complex is when organizations have outsourced the CA >> function elsewhere. >> It's meaningless to pin LetsEncrypt or GoDaddy. It might be meaningful = to >> pin a Subordinate CA signed by some public CA though. >> > > No one, anywhere, should ever pin to a CA that they don=E2=80=99t directl= y > control, and even then, they still shouldn=E2=80=99t :) > Almost agree. Should not pin to a PKIX CA. > Pinning is just a poor-man=E2=80=99s attempt at a server controlling the = client=E2=80=99s > trust anchors, and thus inevitably runs into issues, since client policy = is > inherently _client_ policy. Especially important is never pinning to a > so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their very exist= ence is predicated > on client policy that is intentionally not controlled/controllable by > servers. > I agree. Pinning is a great idea in principle and PKIX pinning turns out to be a lousy idea in practice. The fundamental problem is that every PKIX cert is written from the assumption it will expire. And that is why trust anchors in PKIX aren't actually PKIX certificates. This is true even when PKIX syntax is used for distribution. --000000000000f0fd1805bad64a64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2021 at 11:49 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On S= at, Feb 6, 2021 at 4:00 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Dr. Pala <madwol= f@openca.org> wrote:
=C2=A0 =C2=A0 > Developers and Practitioners (see the note on OpenSSL= 9;s conventions)
=C2=A0 =C2=A0 > seem to support more the "Intermediate CA" for= technical conversations
=C2=A0 =C2=A0 > while "Subordinate CA" is usually referred to = in the context of PKI
=C2=A0 =C2=A0 > policies.

I think that this is the key point which you are supporting.

=C2=A0 =C2=A0 > RFC3647 talks about subordinate organizations instead - = maybe that is
=C2=A0 =C2=A0 > the concept you need to use? What is weird about the que= stion is the
=C2=A0 =C2=A0 > different logical levels that you are trying to put toge= ther: business
=C2=A0 =C2=A0 > relationships and certification chains.

The issue comes up with pinning as it relates to ownership.
It's not a problem if every organization that can own Things has it'= ;s own
private CA.=C2=A0 Pinning that CA works great.
Pinning some other EE is very much more specific, but also, may be too ephe= meral.

Where it gets complex is when organizations have outsourced the CA function= elsewhere.
It's meaningless to pin LetsEncrypt or GoDaddy.=C2=A0 It might be meani= ngful to
pin a Subordinate CA signed by some public CA though.

No one, anywhere, should ever pin = to a CA that they don=E2=80=99t directly control, and even then, they still= shouldn=E2=80=99t :)

Almost agree. Should no= t pin to a PKIX CA.

=C2=A0
Pinning is just a poor-man=E2=80=99s attempt at a server controlling the = client=E2=80=99s trust anchors, and thus inevitably runs into issues, since= client policy is inherently _client_ policy. Especially important is never= pinning to a so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because thei= r very existence is predicated on client policy that is intentionally not c= ontrolled/controllable by servers.

<= /div>
I agree.

=

Pinning is a great idea in pri= nciple and PKIX pinning turns out to be a lousy idea in practice. The funda= mental problem is that every PKIX cert is written from the assumption it wi= ll expire. And that is why trust anchors in PKIX aren't actually PKIX c= ertificates. This is true even when PKIX syntax is used for distribution.


--000000000000f0fd1805bad64a64-- From nobody Mon Feb 8 09:44:40 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98853A13F1 for ; Mon, 8 Feb 2021 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nnBJ3DakIBQJ for ; Mon, 8 Feb 2021 09:44:37 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 B6A603A13F0 for ; Mon, 8 Feb 2021 09:44:37 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id A96D21A31D2; Mon, 8 Feb 2021 12:44:36 -0500 (EST) Date: Mon, 8 Feb 2021 12:44:36 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: Reply-To: saag@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 17:44:39 -0000 On Mon, Feb 08, 2021 at 11:48:57AM -0500, Ryan Sleevi wrote: > > Where it gets complex is when organizations have outsourced the CA > > function elsewhere. It's meaningless to pin LetsEncrypt or GoDaddy. > > It might be meaningful to pin a Subordinate CA signed by some public > > CA though. > > No one, anywhere, should ever pin to a CA that they don’t directly control, > and even then, they still shouldn’t :) > > Pinning is just a poor-man’s attempt at a server controlling the client’s > trust anchors, and thus inevitably runs into issues, since client policy is > inherently _client_ policy. Especially important is never pinning to a > so-called “public” CA, precisely because their very existence is predicated > on client policy that is intentionally not controlled/controllable by > servers. With DANE-TA(2), the server is *asserting* the trust-anchor that's relevant for validation of its certificate. It is not a pin as such. The real trust-anchor is the DNSKEY RRset that ultimately signs the chain leading to validated TLSA records. Clients that implement DANE-TA(2) support will use whatever appears in the TLSA record, so there's no assumption of client policy. (Indeed less assumption of client policy than with WebPKI, where one must tacitly assume that the CA one has elected to issue one's certs is trusted by the relevant clients). That said, a few operators have on some occasion been too sloppy to ensure that the actual certificate they deploy matches the trust anchor listed in their own TLSA records. This is entirely a server-side issue: operational negligence, unrelated to client policy. One can criticise choosing to publish TLSA RRs that "pin" one's own issuer CA as a potentially fragile configuration, and indeed I rather recommend DANE-EE(3) instead, and this is what most DANE users use. Thus, use of DANE-TA(2) is not a potential conflict with client policy, and with care, e.g. by delaying new EE cert deployment when the issuer CA keys change, until new TLSA RRs have been published for a few TTLs, one can use DANE-TA(2) safely even with a third-party issuing CA (most typically Let's Encrypt these days). However, I don't recommend this except perhaps as a fallback, just in case the DANE-EE(3) rollover is botched. On Mon, Feb 08, 2021 at 12:13:36PM -0500, Phillip Hallam-Baker wrote: > > No one, anywhere, should ever pin to a CA that they don’t directly > > control, and even then, they still shouldn’t :) > > Almost agree. Should not pin to a PKIX CA. Perhaps this is the short version of what I tried to spell out in more detail. -- Viktor. From nobody Mon Feb 8 10:40:40 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C23A14A9; Mon, 8 Feb 2021 10:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 neqR4VQyh8a2; Mon, 8 Feb 2021 10:40:37 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3353A14A5; Mon, 8 Feb 2021 10:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6668; q=dns/txt; s=iport; t=1612809637; x=1614019237; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Wa2D2mINJeFan+5d5tMhirq61HxkjqwM3gDiyTJkgmQ=; b=P4Xo0tFNWNwsFNS0oJiEi0wrgfS0mmufh40FgwOA7XzOZKLHH2if4DNU eX4l59ECFh57MXAPVQYLiO1K4ddt/9uvYw7TBSV8vkiJ3lVm6S8Azyu3y 8SodVuKNWcrNNg0rkt5xMqFC+eN3eUMVbkQjo5fPMjS6exUgH2O4Ce6b5 A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CkBABHhSFg/xbLJq1iHgEBCxIMggQLgSOCUAQBJxKEc?= =?us-ascii?q?okEiFgDh3CMOYgdBAcBAQEKAwEBLwQBAYRLAoIDJjcGDgIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEcYVuhXIBBAEjVhALQgICVwaDOQGCZiCuSHaBMoVZhF0QgTiBU?= =?us-ascii?q?4UrhkVBggCBOByCVj6EJoMxNIIsBIJABYEsMoEiGZFIjB6cQoMEgymBOpcgA?= =?us-ascii?q?x+TNY9tjzOiIWKDcgIEBgUCFoFsJIFXMxoIGxVlAYI/PRIZDZxsQANnAgYBC?= =?us-ascii?q?QEBAwmJUS2CGgEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,163,1610409600"; d="asc'?scan'208,217";a="30879408" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Feb 2021 18:40:32 +0000 Received: from [10.61.193.214] ([10.61.193.214]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 118IeVY4016410 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 18:40:32 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F083B323-15FB-460A-A96F-3A916455EE7A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 8 Feb 2021 18:59:43 +0100 In-Reply-To: Cc: Michael Richardson , LAMPS , saag@ietf.org To: Ryan Sleevi References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.193.214, [10.61.193.214] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 18:40:39 -0000 --Apple-Mail=_F083B323-15FB-460A-A96F-3A916455EE7A Content-Type: multipart/alternative; boundary="Apple-Mail=_961C78F3-F3A7-4A33-989D-51948524F06B" --Apple-Mail=_961C78F3-F3A7-4A33-989D-51948524F06B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ryan, >=20 > No one, anywhere, should ever pin to a CA that they don=E2=80=99t = directly control, and even then, they still shouldn=E2=80=99t :) >=20 > Pinning is just a poor-man=E2=80=99s attempt at a server controlling = the client=E2=80=99s trust anchors, and thus inevitably runs into = issues, since client policy is inherently _client_ policy. Especially = important is never pinning to a so-called =E2=80=9Cpublic=E2=80=9D CA, = precisely because their very existence is predicated on client policy = that is intentionally not controlled/controllable by servers. I think we=E2=80=99ve lost the point of the discussion. In this case, = the client starts with just one CA in its trusted root cache, and maybe = not any. These are small devices, and that one cert is a manufacturer = CA. When we are talking about pinning we are talking about an environment in = which a public CA cert is somehow involved. That =E2=80=9Csomehow=E2=80=9D= is very much up in the air. Another way of addressing this is with a = domain constraint, but the problem with such a constraint is that the = device needs to understand DNS, and it may or may not, in which case = some sort of other method is needed to signal that a particular = intermediate needs to be in the chain for validation. The manufacturer is the only trusted element in this picture, as far as = the device is concerned, but it IS trusted in this scenario to = explicitly configure trust for the device. Thus it is in a very good = position to signal that a particular intermediate certificate must be = present in the chain. How to do that? That=E2=80=99s the question of the hour, as I see it. And how to do it = such that it doesn=E2=80=99t completely cause various libraries to cough = up blood? BIGGER question. Eliot --Apple-Mail=_961C78F3-F3A7-4A33-989D-51948524F06B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ryan,


No one, anywhere, should ever pin to a CA that = they don=E2=80=99t directly control, and even then, they still = shouldn=E2=80=99t :)



Pinning is = just a poor-man=E2=80=99s attempt at a server controlling the client=E2=80= =99s trust anchors, and thus inevitably runs into issues, since client = policy is inherently _client_ policy. Especially important is never = pinning to a so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because = their very existence is predicated on client policy that is = intentionally not controlled/controllable by = servers.

I = think we=E2=80=99ve lost the point of the discussion.  In this = case, the client starts with just one CA in its trusted root cache, and = maybe not any.  These are small devices, and that one cert is a = manufacturer CA.

When we are talking = about pinning we are talking about an environment in which a public CA = cert is somehow involved.  That = =E2=80=9Csomehow=E2=80=9D is very much up in the air. Another way of = addressing this is with a domain constraint, but the problem with = such a constraint is that the device needs to understand DNS, and it may = or may not, in which case some sort of other method is needed to signal = that a particular intermediate needs to be in the chain for = validation.

The manufacturer is the = only trusted element in this picture, as far as the device is concerned, = but it IS trusted in this scenario to explicitly configure trust for the device. =  Thus it is in a very good position to signal that a particular = intermediate certificate must be present in the chain.  How to do = that?

That=E2=80=99s the = question of the hour, as I see it.  And how to do it such that it = doesn=E2=80=99t completely cause various libraries to cough up blood? =  BIGGER question.

Eliot
= --Apple-Mail=_961C78F3-F3A7-4A33-989D-51948524F06B-- --Apple-Mail=_F083B323-15FB-460A-A96F-3A916455EE7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAhfA8ACgkQh7ZrRtnS ejNzLwf9GrG+mP0jYvij+I0eIiH75TYJikToor9wlJR6Cb00iBzIUUTRdx2nfGvP ZR4kwChJB9PQP7B6K2D7sMFQxJdslW/6uzp0fxWeMBzaNjycdv4fqW6p1MK+QODl Y1KdMpKxROcMOPkQkvBFtRgPVMF5fQyn3BHPZ/CoYkk445Q8ZXseOs1+KbxmngfR +auZiFR/qn7NeGxt/PPv4GH/xFV9RHqUnvcmFdyBDjnW4E0BQ0JYrx84wPyeCtO9 wFPbDRsAop5obKYT8kf5dU3bs2kP+dXC+ecl+sMJYZ2cntyb9TjDOI8ww3NUzKJv Ebt7L3/4P2MkfTJyIgMaOKFBZkGp6Q== =YEbR -----END PGP SIGNATURE----- --Apple-Mail=_F083B323-15FB-460A-A96F-3A916455EE7A-- From nobody Mon Feb 8 10:41:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68553A14A5 for ; Mon, 8 Feb 2021 10:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0PLqc9oBYv0 for ; Mon, 8 Feb 2021 10:41:27 -0800 (PST) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (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 3655F3A14A9 for ; Mon, 8 Feb 2021 10:41:27 -0800 (PST) Received: by mail-yb1-f179.google.com with SMTP id v5so6843874ybi.3 for ; Mon, 08 Feb 2021 10:41:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gaVFWaWUDLp08nFZICVj7l0dlB5x366avWyIZwwhAcc=; b=VwIC/oMWpI20mJVsA3VJ1VjMfB7ofWcXNcLS5qWSuMXpZCBP0wtNaCZU/35ZfwCyyg GvL94QPTaLv/QIL6bVdGt4XMMggYfdTTvIo/iQMwQtuOZ4h/rY0wKPz3873f+CVKTYmY +b4DNgf8VeiIc/vvKkHVWx3LbKY63ucrydw+uiOLsqIvIkbAg6uJwQcKoqMjn+TsHskT MZDGvcOQfpQqyFW9ZSSiNBbi12/VLbyfymlpDMl30grmsb5wGP5qNpl2R/Y7hgt066hb SBV1Jz07abkG/wKeA3yIyNNexBa2ohTYVVYkicC318pf89XbtnALtGEF90asarPXk2/N 8p1g== X-Gm-Message-State: AOAM530ZpNjSw0zXJwHdKiSgiKNu6J7l7o0qZ0oERvRlkmrPUGW0eGku 9oWwvViMfXiyJ7WY1emCExyT2jHRV74qXJhNufdItkyma8s= X-Google-Smtp-Source: ABdhPJySUvyAK07fhSPoQ9lYav+NX4VfYl8lDh1fgAy9KMN2iCMEJgl+atWAZxp8YHy6iNE+9icaquWne3wT1NYBM1Q= X-Received: by 2002:a25:d3c9:: with SMTP id e192mr26738860ybf.522.1612809685992; Mon, 08 Feb 2021 10:41:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 8 Feb 2021 13:41:15 -0500 Message-ID: To: IETF SAAG Content-Type: multipart/alternative; boundary="0000000000006c89e905bad7843e" Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 18:41:29 -0000 --0000000000006c89e905bad7843e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 8, 2021 at 12:44 PM Viktor Dukhovni wrote: > On Mon, Feb 08, 2021 at 11:48:57AM -0500, Ryan Sleevi wrote: > > > > Where it gets complex is when organizations have outsourced the CA > > > function elsewhere. It's meaningless to pin LetsEncrypt or GoDaddy. > > > It might be meaningful to pin a Subordinate CA signed by some public > > > CA though. > > > > No one, anywhere, should ever pin to a CA that they don=E2=80=99t direc= tly > control, > > and even then, they still shouldn=E2=80=99t :) > > > > Pinning is just a poor-man=E2=80=99s attempt at a server controlling th= e client=E2=80=99s > > trust anchors, and thus inevitably runs into issues, since client polic= y > is > > inherently _client_ policy. Especially important is never pinning to a > > so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their very exi= stence is > predicated > > on client policy that is intentionally not controlled/controllable by > > servers. > > With DANE-TA(2), the server is *asserting* the trust-anchor that's > relevant for validation of its certificate. It is not a pin as such. > The real trust-anchor is the DNSKEY RRset that ultimately signs the > chain leading to validated TLSA records. > Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello. All you have is a chain of trust up to the ICANN yacht club root of trust. You don't own a DNS name, you rent it. And companies that charge $250,000 to apply to register a name have shown themselves to be untrustworthy. Clients that implement DANE-TA(2) support will use whatever appears in > the TLSA record, so there's no assumption of client policy. (Indeed > less assumption of client policy than with WebPKI, where one must > tacitly assume that the CA one has elected to issue one's certs is > trusted by the relevant clients). > And ten years after DANE started, those widely deployed clients would be? That said, a few operators have on some occasion been too sloppy to > ensure that the actual certificate they deploy matches the trust anchor > listed in their own TLSA records. This is entirely a server-side issue: > operational negligence, unrelated to client policy. > No, it is a protocol failure. There are no incompetent users, only incompetent service providers. There are no incompetent administrators, only incompetent protocol architects. The sine qua non for all security policy is to automate the management of the services so that the policy advertisements are always up to date. On Mon, Feb 08, 2021 at 12:13:36PM -0500, Phillip Hallam-Baker wrote: > > > > No one, anywhere, should ever pin to a CA that they don=E2=80=99t dir= ectly > > > control, and even then, they still shouldn=E2=80=99t :) > > > > Almost agree. Should not pin to a PKIX CA. > > Perhaps this is the short version of what I tried to spell out in more > detail. > DNSSEC is simply the WebPKI with a minimum of two trusted parties per path (ICANN + TLD registry). Oh and a heck of a lot more registries. If people want to pin keys to a name, the only way to do that in a practical way is to make the naming system and PKI co-extensive. That is not a feature that can be added to DNSSEC or to PKIX. --0000000000006c89e905bad7843e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2021 at 12:44 PM Viktor Dukhovni <= ;ietf-dane@dukhovni.org> w= rote:
On Mon, Fe= b 08, 2021 at 11:48:57AM -0500, Ryan Sleevi wrote:

> > Where it gets complex is when organizations have outsourced the C= A
> > function elsewhere.=C2=A0 It's meaningless to pin LetsEncrypt= or GoDaddy.
> > It might be meaningful to pin a Subordinate CA signed by some pub= lic
> > CA though.
>
> No one, anywhere, should ever pin to a CA that they don=E2=80=99t dire= ctly control,
> and even then, they still shouldn=E2=80=99t :)
>
> Pinning is just a poor-man=E2=80=99s attempt at a server controlling t= he client=E2=80=99s
> trust anchors, and thus inevitably runs into issues, since client poli= cy is
> inherently _client_ policy. Especially important is never pinning to a=
> so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their very ex= istence is predicated
> on client policy that is intentionally not controlled/controllable by<= br> > servers.

With DANE-TA(2), the server is *asserting* the trust-anchor that's
relevant for validation of its certificate.=C2=A0 It is not a pin as such.<= br> The real trust-anchor is the DNSKEY RRset that ultimately signs the
chain leading to validated TLSA records.

Using DNS to ancho= r WebPKI certs is like trying to nail oak posts to jello.

All you have is a chain of trust up to t= he ICANN yacht club root of trust. You don't own a DNS name, you rent i= t. And companies that charge $250,000 to apply to register a name have show= n themselves to be untrustworthy.


Clients that implement DANE-TA(2) support will use whatever appears in
the TLSA record, so there's no assumption of client policy.=C2=A0 (Inde= ed
less assumption of client policy than with WebPKI, where one must
tacitly assume that the CA one has elected to issue one's certs is
trusted by the relevant clients).

And ten years after DANE = started, those widely deployed clients would be?

=

That said, a few operators have on some occasion been too sloppy to
ensure that the actual certificate they deploy matches the trust anchor
listed in their own TLSA records.=C2=A0 This is entirely a server-side issu= e:
operational negligence, unrelated to client policy.
No, it = is a protocol failure. There are no incompetent users, only incompetent ser= vice providers. There are no incompetent administrators, only incompetent p= rotocol architects.

The s= ine qua non for all security policy is to automate the management of the se= rvices so that the policy advertisements are always up to date.

<= /div>
On Mon, Feb 08, 2021= at 12:13:36PM -0500, Phillip Hallam-Baker wrote:

> > No one, anywhere, should ever pin to a CA that they don=E2=80=99t= directly
> > control, and even then, they still shouldn=E2=80=99t :)
>
> Almost agree. Should not pin to a PKIX CA.

Perhaps this is the short version of what I tried to spell out in more
detail.

DNSSEC is simply=C2=A0the WebPKI with a minimum of = two trusted parties per path (ICANN=C2=A0+ TLD registry). Oh and a heck of = a lot more registries.

If= people want to pin keys to a name, the only way to do that in a practical = way is to make the naming system and PKI co-extensive. That is not a featur= e that can be added to DNSSEC or to PKIX.=C2=A0

=C2=A0<= /div>
--0000000000006c89e905bad7843e-- From nobody Mon Feb 8 10:46:29 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF643A14AD; Mon, 8 Feb 2021 10:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRY4PooQEk5y; Mon, 8 Feb 2021 10:46:25 -0800 (PST) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (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 64F9A3A14AB; Mon, 8 Feb 2021 10:46:25 -0800 (PST) Received: by mail-yb1-f170.google.com with SMTP id w204so15634557ybg.2; Mon, 08 Feb 2021 10:46:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0eKAos57NQK4nnCfS4rBeVr9EQiT13CNabrMdKTEeUo=; b=MECSYmF6VzO2Zm9Jz1zB3K8vm1vY9Nj+HsPe5eHgW1RQV9ScY9doxP4t3JHe+yP7EC PbArb3XtYES3htkymfNX1jNvrVmy6+S3/thWp+H7o3tNBHUQ18xIOFbrDWBjqAQaGkNs DeqX6QUF5/gIdoRt52kEuOan0CasZpzxbc4phb6ILzqbiWRhTPRvg1z7W4KD02Erv0bd tb7qPawfBi1RT+uzEGFTrrwYXkEEJabWITHVAC+TG0hhABYyyI64KfR4rH9E7V60NyWY fzJyt8G4/Zv4kn9/j9LgUz7hJd3zNrMeyiZf0ZOzplrwn2jBlLch/7kIW84cm3BpHlfL FnRQ== X-Gm-Message-State: AOAM531aVMJvo1e8GtnDdYqwlsLAyHUrQsFWukBJpZziaPsvM+iUgCL7 SImcmbL9icmWcWm1zZyxONN8F372lgCA+kzJWMw= X-Google-Smtp-Source: ABdhPJyGSlPEWWRsiufdSgfQUA3Og+ZkY+UffnGoDGupQWk/t0reOhr38cdT8VJu7wEl8uWpkM3fLlITWyzgjhJwBUM= X-Received: by 2002:a5b:444:: with SMTP id s4mr27962495ybp.172.1612809984629; Mon, 08 Feb 2021 10:46:24 -0800 (PST) MIME-Version: 1.0 References: <30833.1612411843@localhost> <5a88fc8c-dbd2-cc77-2b06-db0fd9da4da4@openca.org> <6108.1612645177@localhost> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 8 Feb 2021 13:46:14 -0500 Message-ID: To: Eliot Lear Cc: Ryan Sleevi , LAMPS , Michael Richardson , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000395eb505bad7962e" Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 18:46:27 -0000 --000000000000395eb505bad7962e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 8, 2021 at 1:40 PM Eliot Lear wrote: > Ryan, > > > No one, anywhere, should ever pin to a CA that they don=E2=80=99t directl= y > control, and even then, they still shouldn=E2=80=99t :) > > > > > Pinning is just a poor-man=E2=80=99s attempt at a server controlling the = client=E2=80=99s > trust anchors, and thus inevitably runs into issues, since client policy = is > inherently _client_ policy. Especially important is never pinning to a > so-called =E2=80=9Cpublic=E2=80=9D CA, precisely because their very exist= ence is predicated > on client policy that is intentionally not controlled/controllable by > servers. > > > I think we=E2=80=99ve lost the point of the discussion. In this case, th= e client > starts with just one CA in its trusted root cache, and maybe not any. > These are small devices, and that one cert is a manufacturer CA. > > When we are talking about pinning we are talking about an environment in > which a public CA cert is *somehow* involved. That =E2=80=9Csomehow=E2= =80=9D is very > much up in the air. Another way of addressing this is with a domain > constraint, but the problem with such a constraint is that the device nee= ds > to understand DNS, and it may or may not, in which case some sort of othe= r > method is needed to signal that a particular intermediate needs to be in > the chain for validation. > > The manufacturer is the only trusted element in this picture, as far as > the device is concerned, but it IS trusted in this scenario to > *explicitly* configure trust for the device. Thus it is in a very good > position to signal that a particular intermediate certificate must be > present in the chain. How to do that? > > That=E2=80=99s the question of the hour, as I see it. And how to do it s= uch that > it doesn=E2=80=99t completely cause various libraries to cough up blood? = BIGGER > question. > If I had to deliver something in 12 months, I would take Microsoft's Certificate Trust Lists as a starting point. The better answer for IoT PKI is to start from scratch with trust assertions that don't expire, a naming system in which permanent name allocation is cheap and to make use of threshold cryptography to address the fact that end users can't trust manufacturer keys and manufacturers would be nuts to accept the liability of issuing end user keys. Something like the Mathematical Mesh. --000000000000395eb505bad7962e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2021 at 1:40 PM Eliot Lear <lear= =3D40cisco.com@dmarc.ietf.org= > wrote:
=
Ryan,


No one, anywhere, should ever pin to a C= A that they don=E2=80=99t directly control, and even then, they still shoul= dn=E2=80=99t :)


=

Pinning is just a poor-man=E2= =80=99s attempt at a server controlling the client=E2=80=99s trust anchors,= and thus inevitably runs into issues, since client policy is inherently _c= lient_ policy. Especially important is never pinning to a so-called =E2=80= =9Cpublic=E2=80=9D CA, precisely because their very existence is predicated= on client policy that is intentionally not controlled/controllable by serv= ers.

I think we=E2=80=99= ve lost the point of the discussion.=C2=A0 In this case, the client starts = with just one CA in its trusted root cache, and maybe not any.=C2=A0 These = are small devices, and that one cert is a manufacturer CA.

When we are talking about pinning we are talking about an environm= ent in which a public CA cert is somehow=C2=A0involved.=C2=A0 That = =E2=80=9Csomehow=E2=80=9D is very much up in the air. Another way of addres= sing this is with=C2=A0a domain constraint, but the problem with such a con= straint is that the device needs to understand DNS, and it may or may not, = in which case some sort of other method is needed to signal that a particul= ar intermediate needs to be in the chain for validation.

The manufacturer is the only trusted element in this picture, as far= as the device is concerned, but it IS trusted in this scenario to expli= citly=C2=A0configure trust for the device.=C2=A0 Thus it is in a very g= ood position to signal that a particular intermediate certificate must be p= resent in the chain.=C2=A0 How to do that?

T= hat=E2=80=99s the question of the hour, as I see it.=C2=A0 And how to do it= such that it doesn=E2=80=99t completely cause various libraries to cough u= p blood?=C2=A0 BIGGER question.

If I had to deliver= something in 12 months, I would take Microsoft's Certificate Trust Lis= ts as a starting point.

The better answer for IoT PKI is to start from scra= tch with trust assertions that don't expire, a naming system in which p= ermanent name allocation is cheap and to make use of threshold cryptography= to address the fact that end users can't trust manufacturer keys and m= anufacturers would be nuts to accept the liability of issuing end user keys= .

Something like the Math= ematical Mesh.
=


=C2=A0
--000000000000395eb505bad7962e-- From nobody Mon Feb 8 12:03:39 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479B03A1551 for ; Mon, 8 Feb 2021 12:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MONEY_NOHTML=1.467, SPF_HELO_NONE=0.001, SPF_PASS=-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 lWIYrepZEOqz for ; Mon, 8 Feb 2021 12:03:36 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 CE7183A1552 for ; Mon, 8 Feb 2021 12:03:36 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 02BCE1A34EE; Mon, 8 Feb 2021 15:03:36 -0500 (EST) Date: Mon, 8 Feb 2021 15:03:35 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: Reply-To: saag@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [saag] [lamps] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 20:03:38 -0000 On Mon, Feb 08, 2021 at 01:41:15PM -0500, Phillip Hallam-Baker wrote: > > With DANE-TA(2), the server is *asserting* the trust-anchor that's > > relevant for validation of its certificate. It is not a pin as such. > > The real trust-anchor is the DNSKEY RRset that ultimately signs the > > chain leading to validated TLSA records. > > Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello. [ Colourful aside ignored. ] > All you have is a chain of trust up to the ICANN yacht club root of trust. > You don't own a DNS name, you rent it. And companies that charge $250,000 > to apply to register a name have shown themselves to be untrustworthy. At least I know who it chains to. > > Clients that implement DANE-TA(2) support will use whatever appears in > > the TLSA record, so there's no assumption of client policy. (Indeed > > less assumption of client policy than with WebPKI, where one must > > tacitly assume that the CA one has elected to issue one's certs is > > trusted by the relevant clients). > > And ten years after DANE started, those widely deployed clients would be? Postfix, Exim, Power-MTA, Halon MTA, Cisco ESA, Microsoft Azure hosted Exchange (scheduled to go live this month), gmx.de, Protonmail, Postini, mailbox.org, ... Of ~14 million DNSSEC signed domains, 2.54 million have DANE TLSA RRs for their MX hosts. > > This is entirely a server-side issue: operational negligence, > > unrelated to client policy. > > No, it is a protocol failure. There are no incompetent users, only > incompetent service providers. There are no incompetent > administrators, only incompetent protocol architects. I disagree, but the protocol failure, if you really insist on calling it one, resulted from a compromise, where some folks wanted DANE to be simple and just support DANE-EE(3), but some others wanted more features, and so DANE has four certificate usages, of which only 2 are suitable for SMTP, but almost everyone is wisely using DANE-EE(3). Once I release "danebot" (in alpha now), which makes it easy to manage DANE-EE(3) reliably with Let's Encrypt, more users will switch to DANE-EE(3) and DANE-TA(2) should become increasingly rare. > The sine qua non for all security policy is to automate the management > of the services so that the policy advertisements are always up to > date. 100% agreement, hence "danebot" coming to github soon. > > Perhaps this is the short version of what I tried to spell out in more > > detail. > > DNSSEC is simply the WebPKI with a minimum of two trusted parties per path > (ICANN + TLD registry). Oh and a heck of a lot more registries. A system that eliminates redundant third parties in asserting domain control. The same ICANN root and registrars are also trusted parties in DV cert issuance. > If people want to pin keys to a name, the only way to do that in a > practical way is to make the naming system and PKI co-extensive. That is > not a feature that can be added to DNSSEC or to PKIX. If the names are *DNS* names, then the parties that can delegate and transfer control of domains are the natural parties to publish assertions about trusted keys for those domains. Some would redesign the domain hierarchy with various block-chain like schemes, I don't expect these to succeed, but have no prior objections to exploring other trust models. Whatever the model, it should not have redundant trusted 3rd-parties publishing assertions that the principals can publish directly. -- Viktor. From nobody Tue Feb 9 09:03:54 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6600D3A1006; Tue, 9 Feb 2021 09:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uePlrylah0ps; Tue, 9 Feb 2021 09:03:50 -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 44F553A1001; Tue, 9 Feb 2021 09:03:49 -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 119H3hJo018481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Feb 2021 12:03:48 -0500 Date: Tue, 9 Feb 2021 09:03:43 -0800 From: Benjamin Kaduk To: saag@ietf.org Cc: sec-ads@ietf.org Message-ID: <20210209170343.GW21@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [saag] call for agenda items for SAAG@IETF110 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 17:03:52 -0000 Hi all, We requested a 2-hour slot for SAAG at the virtual IETF 110. Please let Roman and I know if you have any topic(s) that you would like to cover during the session. We are also happy to accept advance volunteers to help take minutes :) Thanks, Ben From nobody Tue Feb 9 22:26:01 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BE53A1423 for ; Tue, 9 Feb 2021 22:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4ys_H1MTPGEf for ; Tue, 9 Feb 2021 22:25:58 -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 BA14A3A1422 for ; Tue, 9 Feb 2021 22:25:58 -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 11A6Pqoi002862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 10 Feb 2021 01:25:56 -0500 Date: Tue, 9 Feb 2021 22:25:51 -0800 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20210210062551.GI21@kduck.mit.edu> References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161257199785.16601.5458969087152796022@ietfa.amsl.com> Archived-At: Subject: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 06:26:01 -0000 You may recall that this draft has a storied history, and that the results of the third WGLC included adding a note for the IETF LC that the IETF consensus (or lack thereof) is unknown and needs to be explicitly determined for this draft (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/). -Ben On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote: > > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: - 'Considerations around > Transport Header Confidentiality, Network > Operations, and the Evolution of Internet Transport Protocols' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > To protect user data and privacy, Internet transport protocols have > supported payload encryption and authentication for some time. Such > encryption and authentication is now also starting to be applied to > the transport protocol headers. This helps avoid transport protocol > ossification by middleboxes, mitigate attacks against the transport > protocol, and protect metadata about the communication. Current > operational practice in some networks inspect transport header > information within the network, but this is no longer possible when > those transport headers are encrypted. > > This document discusses the possible impact when network traffic uses > a protocol with an encrypted transport header. It suggests issues to > consider when designing new transport protocols or features. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Wed Feb 10 14:08:50 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E83A1540 for ; Wed, 10 Feb 2021 14:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnVSSi8Yg0oF for ; Wed, 10 Feb 2021 14:08:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD133A153E for ; Wed, 10 Feb 2021 14:08:41 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:8956:4518:7147:354b] (unknown [IPv6:2800:810:464:2b9:8956:4518:7147:354b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 98BE5283BEA; Wed, 10 Feb 2021 22:08:30 +0000 (UTC) To: Benjamin Kaduk , saag@ietf.org References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> From: Fernando Gont Message-ID: Date: Wed, 10 Feb 2021 19:08:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20210210062551.GI21@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 22:08:49 -0000 Hello, Ben, For some reason, I failed to find the relevant email message on the last-call list :-/ Some very specific comments on some parts: * Section 5.1: For example, an endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide explicit transport layer information that can be observed and used by network devices on the path. This is not as easy as it sounds. If you convey this information in multiple places (e.g. the transport protocol itself (that you cannot see), and e.g. IPv6 options), then the two might not much -- and devices could e.g. enforce a security policy on contents (e.g., the info in the IPv6 options), that the destination endpoint might possibly e.g. ignore. * Section 5.1: Protocol methods can be designed to probe to discover whether the specific option(s) can be used along the current path, enabling use on arbitrary paths. This might be a problem of "English as a second language", but the above text sounds to me like you can enable use of this feature on arbitrary paths.... where's I'd probably argue that what you can do is to *disable* the feature on paths where the feature cannot be used, such that you may still communicate (albeit without using the aforementioned feature). Another simpler fix might be s/arbitrary/specific/ At the end of the day, when it comes to new features (i.e., features that folks do not currently rely on), the folks operating the networks trump everything else. -- same as when folks decide to tunnel things on e.g. UDP, but then find out they are rate limited.... Thanks, Fernando On 10/2/21 03:25, Benjamin Kaduk wrote: > You may recall that this draft has a storied history, and that the results > of the third WGLC included adding a note for the IETF LC that the IETF > consensus (or lack thereof) is unknown and needs to be explicitly > determined for this draft > (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/). > > -Ben > > On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote: >> >> The IESG has received a request from the Transport Area Working Group WG >> (tsvwg) to consider the following document: - 'Considerations around >> Transport Header Confidentiality, Network >> Operations, and the Evolution of Internet Transport Protocols' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may >> be sent to iesg@ietf.org instead. In either case, please retain the beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> To protect user data and privacy, Internet transport protocols have >> supported payload encryption and authentication for some time. Such >> encryption and authentication is now also starting to be applied to >> the transport protocol headers. This helps avoid transport protocol >> ossification by middleboxes, mitigate attacks against the transport >> protocol, and protect metadata about the communication. Current >> operational practice in some networks inspect transport header >> information within the network, but this is no longer possible when >> those transport headers are encrypted. >> >> This document discusses the possible impact when network traffic uses >> a protocol with an encrypted transport header. It suggests issues to >> consider when designing new transport protocols or features. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Feb 10 14:53:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D355D3A0C2E; Wed, 10 Feb 2021 14:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dell.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 LCZYhna1b24b; Wed, 10 Feb 2021 14:53:29 -0800 (PST) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9C93A0C87; Wed, 10 Feb 2021 14:53:28 -0800 (PST) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11AMqSSV000601; Wed, 10 Feb 2021 17:53:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=0/hjQojr1Wu/tFA2fNtdF4jaDrMImEpbjC5cI/yplmQ=; b=LfJDuqS8WtzOk4lOlCawmWKIlxi1B1u7EGJh0VLx05SmsVGrD2kvYwKrCmiLgpmCuQpS S2idDalQ5z+9WHBvpTzM3OLfzfJcAfTBfnZclzF2ajGEEhM2OOF2nTKrqps2m1XKjdvH VJiJ2wHnhYfy1N95pPYe37yN61ImcwSe7dmLUExLlQUHJkxhSturm+fPmX/fkfG6Tcd7 3s2NmOKVy11ffl2EJ1qDahnlsao163zxq9OcO9GUYr5l3mai9DVD3Gr6diZ3qnMbmGaO JbU+DZYFSXtAAZGC2GSOZSZmhoInZWiD8wCbj3Hv7TWpif3MH3Sm/ccREy9/dzJ8s26u 9Q== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 36hq26y14k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Feb 2021 17:53:26 -0500 Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11AMk5OI098012; Wed, 10 Feb 2021 17:53:25 -0500 Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) by mx0b-00154901.pphosted.com with ESMTP id 36hp91j86u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Feb 2021 17:53:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j5+trsAvDhZEofI3+X7gF51S2cUfof+wuYPyhXjDexIylqPjmfO9ILTvB5IgRbNP2R4Nk1/a2BCDBqm7rXJM5GJfEyReoT7gVqPbr3u86NC90oEMUlivFihK5bTxomJK3kw7D+vDwpHFMopTqy1bbUNBA1SQNS+/CS2QlZw0J1DhSnM17XPYrvuZGORr9RFFn7O2ASFOGnCMgcnJcKc/eKvAZGdbTBHE8KYLkihkyMrWeD6ysyl6otwMcU6JpgRqJtEeJxyZRh8vxmDbt1diW7sRgXGLXla+OoAS0MdECKBvvRS/iGfNnmI4V80EhbmQ2u0w/QSTNUURNXZAFLqTYA== 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=0/hjQojr1Wu/tFA2fNtdF4jaDrMImEpbjC5cI/yplmQ=; b=HZ8Sf+9F5ljSDBJT2LY96GFGqUcwvwyvXRuNESes0QfZmu+mx0LvCznKM0eb9hlKBWMLxFpCqi+SehS8rDBQW1hnJ3y5h3SSXIwUPPLNiZva/zpchHaLP7C1WXnvV0HuRdYfm4GYCQD81Jl/5uTjnBm1aKqo2QbolEyAiSklOXzrGJbG0yMqE3movGV41hUDv2bPGdH2GaXsRDLplTKmB08gEQfw8vjAx30B8IR4uhNo7BPxsKN8tj53oCA8KoB2ck+G2VCP5MqKIHw7D5+3FYyjkrnmuLqC9WVbECa40tCuM0OUdTSLBm4XvXS2BFHgg7yxR3yyOXBGHigxuHJ8Mw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3933.namprd19.prod.outlook.com (2603:10b6:208:1e0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20; Wed, 10 Feb 2021 22:53:23 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::5423:2c81:dffb:f76a]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::5423:2c81:dffb:f76a%7]) with mapi id 15.20.3846.026; Wed, 10 Feb 2021 22:53:23 +0000 From: "Black, David" To: Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC Thread-Index: AQHW/CCa+/200/fqF06+pbFziQd+z6pQ8uaAgAEHV4CAAAxS4A== Date: Wed, 10 Feb 2021 22:53:23 +0000 Message-ID: References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2021-02-10T22:53:01.1037552Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=a42433aa-3dd2-4cf4-82e7-cc05d90cfeb5; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual authentication-results: gont.com.ar; dkim=none (message not signed) header.d=none;gont.com.ar; dmarc=none action=none header.from=dell.com; x-originating-ip: [72.74.71.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d46d8af1-b056-41b6-6d53-08d8ce16ab48 x-ms-traffictypediagnostic: MN2PR19MB3933: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tpHe4GPCcvKhK5EyGd+sa1D/uWghtz0Y0Az/Om2DH+JInZx4uAV9y00hj+0Cl5j/hjCzK9EP0tCvHUio5SGP51wpX8Ct5A7IF4S0qC0/4baDjmiRfQj6qio7UvdOz5RRNfQ2+KTpeys4fy8vWaLvtonHnCuC1dtnUIoMuTCXWIT/HX4JYOJogl7xqXkjHm4Y7oEvYm438kRCKQoDRFZ9lmF/w2rvgAV+hec4wGkkCgq9VRMCfgZBkiyNygeOZmqtdfrip6LP2IRQozwkMYVqVqRxf75QwFWWjLiAdIl/jN9LBrpyUEIs2wGsvzNLgXWZ//3W5aBwiAggdVMNeOTNB06N/Ms8smqfBOSdCzgHj1AAZP53QR/5CdPUVpjmzXgNa3v/VmTlPbLMz0hROTTW1aFMIfEiHD0QLk40GJ4wDbUZXCXSRls73lkG+D+cH9ULHio8W+ofO38tlyoITaWVwO1o9S4DSUDCsCIugo+4TK1NCtCS7TFnXK6AhAE43oTTLzbONhiAC03ZbbRVQRARiPkyrbhtsLgSLKpx5WcLAxpHWsEcbFdL9x99qNhwio6naFS/MpRcZiZp7yD1SNJIshWkcyzOUbRQWQJXV0YDqM0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(376002)(136003)(39860400002)(71200400001)(66574015)(4326008)(64756008)(76116006)(966005)(5660300002)(66946007)(110136005)(52536014)(6506007)(478600001)(83380400001)(107886003)(8676002)(53546011)(2906002)(66476007)(86362001)(186003)(26005)(9686003)(8936002)(786003)(7696005)(66556008)(66446008)(316002)(33656002)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?UcmMtoWOHkBXlYdyBpulBq+l/IKoBYKcaByIBDyqboCdbNGOYg5ld09kXhWU?= =?us-ascii?Q?9TFTOXHpQL+Apz4Au4HGOtRn9n/s5MR2M/QPkeQGOrxPwzsPTKLj54folruf?= =?us-ascii?Q?upRCJuMYg4Sr5w5ayXfrhtT0yLkGxdqDtUJlPPh8NTVmAaJMupJKux27clDa?= =?us-ascii?Q?aDy21B31SZmg+AZvcfiNpJgIQtnetc9WcAfquMkqOh6c4P5yR5PZndW1Wk9Y?= =?us-ascii?Q?9K4auh6kynjE+c/1BV3IJ1fqdFCM2z8ocsG4Sd/JZd/kij1t12OVs7Qk2zOe?= =?us-ascii?Q?FVh/TnbNWIxu6jf662aTgjMuLafETeQyzfllzA3uIrvWP6wfLDhT++xSX9K/?= =?us-ascii?Q?JqWQZ5Lpecu74AnrYJEP7hkN0Y+qmInVY3oI4FeYdPeGDq88ey64g16LtQop?= =?us-ascii?Q?CABylvxSaRKDiEjh19FRhiAeQg4Uk1tWHJ8aSdcFjcTW7tqJmgzf666/J+J4?= =?us-ascii?Q?WEEPuyUw3rFLujPFbBbvzLLIQFCuSXutcCkqyDJW1QyJ31DHTpFJRu79DM69?= =?us-ascii?Q?eHSPb2yhWODElOc2p7COEDtv/eFB18tEGKuaeWRM2k8NkWco9xnzgNstYfUU?= =?us-ascii?Q?cJfQvdJLk4Cz2s2aUfhZj1UPoZPg16qGfLqcFj3tB6BQgsKXHmc5rQ1mzNR4?= =?us-ascii?Q?4qR1x2YX0y1mUCmEJ3Hp7565QiOlXGN4ycAB29DQ+rgye0WTraCfKP2jmasC?= =?us-ascii?Q?GmxU/jt5xToxCN+Mh/2Q+ADghMiAVkXYRR2dZkrpPz3+QEY+s+wRtnBfOTPs?= =?us-ascii?Q?bVOFL3CWR53FvvdsWPHihx10g/pAZmufqEXPyfkUGymnDUicv/37WRhsz43B?= =?us-ascii?Q?PX/kOTiQSdIhTxeEu9RAkgCfk43NiBeBfvc5kirpoRP1Be8ZHnSwgcg0fKim?= =?us-ascii?Q?6H07CvmBZpjRm2E1rKLZS5i6oqKh7q8FyR9LVIxAlpCEDmzCR3qiAifrHQxI?= =?us-ascii?Q?PBizGn+Vb7vV21qW8M3L0Q8PohpbL1HEZsXFNApW5pd0QIUwfuQbxl9az0R8?= =?us-ascii?Q?ACGDYcNm4G7swwVH8jJxdZM26c/VpAEtEOqbcpYJ/dzabL8iibZ4kzItgBj0?= =?us-ascii?Q?5o+twdXUfl2eCoYJgsyc8HLdMNuCsxX+XAfBHhMU8SCEfcSvvSr3ihwZyFGz?= =?us-ascii?Q?Q8vPykcpQ9nJAgl1xEo/ijYFErUa4uMj+8tVKsXgcPc3Me8RmTt8Q/cHsqZ4?= =?us-ascii?Q?ZmyiDGHTFG10xHjyhB2fTqDQWWIZGxuiAZkc7s3ZUx47OOalbiDLaFAC/69J?= =?us-ascii?Q?4A9kgC/2zVkXV+P5n5mAh9EwVlHQPhU5YrGcyKcCwVe22Ofh0mWn6bspc5GD?= =?us-ascii?Q?VpmY9xhI2DgQmbPZMj4eEdgM?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d46d8af1-b056-41b6-6d53-08d8ce16ab48 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2021 22:53:23.0540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zKVTGRMllC0OfFrynKkIseK8PF1CSsBTUUcFgudX1SX+pKKP41lbbMI83WomnSyHSXihOjrAWTfz5SCVnKJz+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3933 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-10_11:2021-02-10, 2021-02-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 clxscore=1011 adultscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102100198 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 phishscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102100199 Archived-At: Subject: Re: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 22:53:31 -0000 Adding TSVWG list, Thanks, --David -----Original Message----- From: saag On Behalf Of Fernando Gont Sent: Wednesday, February 10, 2021 5:08 PM To: Benjamin Kaduk; saag@ietf.org Subject: Re: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Opera= tions, and the Evolution of Internet Transport Protocols) to Informational = RFC [EXTERNAL EMAIL]=20 Hello, Ben, For some reason, I failed to find the relevant email message on the last-ca= ll list :-/ Some very specific comments on some parts: * Section 5.1: For example, an endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide explicit transport layer information that can be observed and used by network devices on the path. This is not as easy as it sounds. If you convey this information in=20 multiple places (e.g. the transport protocol itself (that you cannot=20 see), and e.g. IPv6 options), then the two might not much -- and devices=20 could e.g. enforce a security policy on contents (e.g., the info in the=20 IPv6 options), that the destination endpoint might possibly e.g. ignore. * Section 5.1: Protocol methods can be designed to probe to discover whether the specific option(s) can be used along the current path, enabling use on arbitrary paths. This might be a problem of "English as a second language", but the above=20 text sounds to me like you can enable use of this feature on arbitrary=20 paths.... where's I'd probably argue that what you can do is to=20 *disable* the feature on paths where the feature cannot be used, such=20 that you may still communicate (albeit without using the aforementioned=20 feature). Another simpler fix might be s/arbitrary/specific/ At the end of the day, when it comes to new features (i.e., features=20 that folks do not currently rely on), the folks operating the networks=20 trump everything else. -- same as when folks decide to tunnel things on=20 e.g. UDP, but then find out they are rate limited.... Thanks, Fernando On 10/2/21 03:25, Benjamin Kaduk wrote: > You may recall that this draft has a storied history, and that the result= s > of the third WGLC included adding a note for the IETF LC that the IETF > consensus (or lack thereof) is unknown and needs to be explicitly > determined for this draft > (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/)= . >=20 > -Ben >=20 > On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote: >> >> The IESG has received a request from the Transport Area Working Group WG >> (tsvwg) to consider the following document: - 'Considerations around >> Transport Header Confidentiality, Network >> Operations, and the Evolution of Internet Transport Protocols' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits fi= nal >> comments on this action. Please send substantive comments to the >> last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments = may >> be sent to iesg@ietf.org instead. In either case, please retain the begi= nning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> To protect user data and privacy, Internet transport protocols have >> supported payload encryption and authentication for some time. Such >> encryption and authentication is now also starting to be applied to >> the transport protocol headers. This helps avoid transport protocol >> ossification by middleboxes, mitigate attacks against the transport >> protocol, and protect metadata about the communication. Current >> operational practice in some networks inspect transport header >> information within the network, but this is no longer possible when >> those transport headers are encrypted. >> >> This document discusses the possible impact when network traffic use= s >> a protocol with an encrypted transport header. It suggests issues t= o >> consider when designing new transport protocols or features. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ >> >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Thu Feb 11 01:51:41 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3093A141A; Thu, 11 Feb 2021 01:51:39 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvOytF87P3Pl; Thu, 11 Feb 2021 01:51:29 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 897603A1415; Thu, 11 Feb 2021 01:51:14 -0800 (PST) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4EF1C1B00179; Thu, 11 Feb 2021 09:51:02 +0000 (GMT) To: "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> From: Gorry Fairhurst Message-ID: <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> Date: Thu, 11 Feb 2021 09:50:58 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 09:51:40 -0000 Thanks Fernando, Please see below: On 10/02/2021 22:53, Black, David wrote: > Adding TSVWG list, Thanks, --David > > -----Original Message----- > From: saag On Behalf Of Fernando Gont > Sent: Wednesday, February 10, 2021 5:08 PM > To: Benjamin Kaduk; saag@ietf.org > Subject: Re: [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC > > > [EXTERNAL EMAIL] > > Hello, Ben, > > For some reason, I failed to find the relevant email message on the last-call list :-/ > > > Some very specific comments on some parts: > > * Section 5.1: > > For example, an > endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide > explicit transport layer information that can be observed and used by > network devices on the path. > > This is not as easy as it sounds. If you convey this information in > multiple places (e.g. the transport protocol itself (that you cannot > see), and e.g. IPv6 options, then the two might not much -- and devices > could e.g. enforce a security policy on contents (e.g., the info in the > IPv6 options), that the destination endpoint might possibly e.g. ignore. This sounds similar to the case of explicitly exposing other information. In this case, the network will make decisions on what it sees or infers - without knowledge of the contents of the encrypted part Would you like to propose some text to help explain this? > * Section 5.1: > > Protocol methods can be designed to > probe to discover whether the specific option(s) can be used along > the current path, enabling use on arbitrary paths. > > This might be a problem of "English as a second language", but the above > text sounds to me like you can enable use of this feature on arbitrary > paths.... where's I'd probably argue that what you can do is to > *disable* the feature on paths where the feature cannot be used, such > that you may still communicate (albeit without using the aforementioned > feature). > > Another simpler fix might be s/arbitrary/specific/ The whole para currently reads:    An arbitrary path can include one or more network devices that drop    packets that include a specific header or option used for this    purpose (see [RFC7872]).  This could impact the proper functioning of    the protocols using the path.  Protocol methods can be designed to    probe to discover whether the specific option(s) can be used along    the current path, enabling use on arbitrary paths. I think this last sentence can indeed be improved, and I suggest something like:    Protocol methods can be designed to    probe to discover whether the specific option(s) can be used along    the current path, enabling or disabling their use on the path. Is that better? > At the end of the day, when it comes to new features (i.e., features > that folks do not currently rely on), the folks operating the networks > trump everything else. -- same as when folks decide to tunnel things on > e.g. UDP, but then find out they are rate limited.... Agree. > Thanks, > Fernando > Best wishes, Gorry > > > On 10/2/21 03:25, Benjamin Kaduk wrote: >> You may recall that this draft has a storied history, and that the results >> of the third WGLC included adding a note for the IETF LC that the IETF >> consensus (or lack thereof) is unknown and needs to be explicitly >> determined for this draft >> (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/). >> >> -Ben >> >> On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote: >>> The IESG has received a request from the Transport Area Working Group WG >>> (tsvwg) to consider the following document: - 'Considerations around >>> Transport Header Confidentiality, Network >>> Operations, and the Evolution of Internet Transport Protocols' >>> as Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits final >>> comments on this action. Please send substantive comments to the >>> last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the beginning >>> of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> To protect user data and privacy, Internet transport protocols have >>> supported payload encryption and authentication for some time. Such >>> encryption and authentication is now also starting to be applied to >>> the transport protocol headers. This helps avoid transport protocol >>> ossification by middleboxes, mitigate attacks against the transport >>> protocol, and protect metadata about the communication. Current >>> operational practice in some networks inspect transport header >>> information within the network, but this is no longer possible when >>> those transport headers are encrypted. >>> >>> This document discusses the possible impact when network traffic uses >>> a protocol with an encrypted transport header. It suggests issues to >>> consider when designing new transport protocols or features. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > From nobody Thu Feb 11 09:58:28 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B523A180E; Thu, 11 Feb 2021 09:58: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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdbumpY3Z2cE; Thu, 11 Feb 2021 09:58:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341533A180D; Thu, 11 Feb 2021 09:58:18 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 608772809AE; Thu, 11 Feb 2021 17:58:14 +0000 (UTC) To: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> Date: Thu, 11 Feb 2021 14:58:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 17:58:23 -0000 On 11/2/21 06:50, Gorry Fairhurst wrote: [....] >> >> Some very specific comments on some parts: >> >> * Section 5.1: >> >>      For example, an >>      endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide >>      explicit transport layer information that can be observed and >> used by >>      network devices on the path. >> >> This is not as easy as it sounds. If you convey this information in >> multiple places (e.g. the transport protocol itself (that you cannot >> see), and e.g. IPv6 options, then the two might not much -- and devices >> could e.g. enforce a security policy on contents (e.g., the info in the >> IPv6 options), that the destination endpoint might possibly e.g. ignore. > > This sounds similar to the case of explicitly exposing other > information. Yes. ANything where you have two copies of the same information, and different parties are likely to act on different copies, is prone to the same thing. (I guess, unless you can enforce that the two match, and have a strong requirement that all parties check that, and otherwise drop the packet -- something that in practice, many don't) > In this case, the network will make decisions on what it > sees or infers - without knowledge of the contents of the encrypted part > Would you like to propose some text to help explain this? I'd be happy to. I'll craft text and come back to you on this one. >> * Section 5.1: >> >>      Protocol methods can be designed to >>      probe to discover whether the specific option(s) can be used along >>      the current path, enabling use on arbitrary paths. >> >> This might be a problem of "English as a second language", but the above >> text sounds to me like you can enable use of this feature on arbitrary >> paths.... where's I'd probably argue that what you can do is to >> *disable* the feature on paths where the feature cannot be used, such >> that you may still communicate (albeit without using the aforementioned >> feature). >> >> Another simpler fix might be s/arbitrary/specific/ > > The whole para currently reads: > >    An arbitrary path can include one or more network devices that drop >    packets that include a specific header or option used for this >    purpose (see [RFC7872]).  This could impact the proper functioning of >    the protocols using the path.  Protocol methods can be designed to >    probe to discover whether the specific option(s) can be used along >    the current path, enabling use on arbitrary paths. > > I think this last sentence can indeed be improved, and I suggest > something like: > >    Protocol methods can be designed to >    probe to discover whether the specific option(s) can be used along >    the current path, enabling or disabling their use on the path. > > Is that better? That's perfect, and indeed addressed my comment. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 11 10:19:14 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC993A182C for ; Thu, 11 Feb 2021 10:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 l2Eqv_kJkyM4 for ; Thu, 11 Feb 2021 10:19:01 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 625793A1821 for ; Thu, 11 Feb 2021 10:19:01 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id sa23so11553772ejb.0 for ; Thu, 11 Feb 2021 10:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z9mFnEKdTD2LMHifmwkEZGNK8TKLLe2nUvSujHM4R2U=; b=Mz68MWTejFWP/lkqKKomXp3gXvT/AsG/SLEzNVUeYLGUGVJv9vRmHNG2+P6PdLyUDt bimzpWmJVLJQWLCRcoao8gf69X3bDxBvpLIqgZ/qmeb+7PaFfGS6z/7/c6nfwYdgtLZX Y7PYZ1DAuyUyo5/e5NBdvapcK3CUlBZrAah0nWuCSiSO13ejKS9gKhqCsMzZc22Uf5Vo X/XjcayWTKVOdUeQSWYv2yxzPKZNDqiq7Ae7fpNTS4q7QavTfbI2qDguDp49c6K24FqG I7/JhqLWnOM3O6r8X/IYBcuX5JiHpZKE0bNPpAoWkb0upjRBLxpcsg9RDmvHy6knzaLB tBUg== 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=Z9mFnEKdTD2LMHifmwkEZGNK8TKLLe2nUvSujHM4R2U=; b=LBxnQ2a/8oeI6hdAQZ+RfOEGYmyDLCNNB6eY7tJnEmMaco+o9Mf5qv9APfNuJmkiM0 PsK7JY0m81VKknP3TT666mLDYiLVpbqVKYPzd24ixRDrc/pw+My3jgev47Gsfg+661aN 37EWz0b/MNb4dw2fPFWjPCzshtw4cK8udIzWlitlQP8ZeSqj51BE6L0uziiByb/mk9HX vOlHz7nZr5y4SIDFjGvjsHxPYwQ68GimUdpNhV8jgQK3jCMnW28j4kC+1VB6mS3BfPYm NAaBSarUR0iuof9P02zeldaVUW8AXCCprYYbdYsl5xjv4vE3SqVWxCSDgfAINIgzDoIF HYig== X-Gm-Message-State: AOAM5339yZOc9ZpR+Awcc1ZaMro95CoB0yhiCf2G7VmScN/l3HqgZz6G wKx3rhd1+T0ySTM4aC2bVsY+QjgM8nwCaYYV9P8ipQ== X-Google-Smtp-Source: ABdhPJzXKNk5qIbvdzcW6MqH1b404HFYTOAGLYsoVrSiGJ9b2h4MrhTNVe4sC78Ect6SYk1haa0NyXGKIaJpxPOIgms= X-Received: by 2002:a17:906:16d0:: with SMTP id t16mr9328829ejd.259.1613067534731; Thu, 11 Feb 2021 10:18:54 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> In-Reply-To: <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> From: Tom Herbert Date: Thu, 11 Feb 2021 11:18:43 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 18:19:12 -0000 On Thu, Feb 11, 2021 at 10:58 AM Fernando Gont wrote: > > On 11/2/21 06:50, Gorry Fairhurst wrote: > [....] > >> > >> Some very specific comments on some parts: > >> > >> * Section 5.1: > >> > >> For example, an > >> endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide > >> explicit transport layer information that can be observed and > >> used by > >> network devices on the path. > >> > >> This is not as easy as it sounds. If you convey this information in > >> multiple places (e.g. the transport protocol itself (that you cannot > >> see), and e.g. IPv6 options, then the two might not much -- and devices > >> could e.g. enforce a security policy on contents (e.g., the info in the > >> IPv6 options), that the destination endpoint might possibly e.g. ignore. > > > > This sounds similar to the case of explicitly exposing other > > information. > > Yes. ANything where you have two copies of the same information, and > different parties are likely to act on different copies, is prone to the > same thing. > Fernando, When the transport layer is encrypted, network devices would only see the plaintext EH and that is only what that is what they can act on. At the destination, we could try to rectify transport information in HBH with decrypted plaintext transport headers, but I suspect that wouldn't typically be done. The HBH information is only operationally useful to the network, not the transport endpoints that have access to the transport header. The only point of the end host comparing the data would be to enforce the network's security policy, but it's not common that end hosts actually know what the network security policies are. Tom > (I guess, unless you can enforce that the two match, and have a strong > requirement that all parties check that, and otherwise drop the packet > -- something that in practice, many don't) > > > > > In this case, the network will make decisions on what it > > sees or infers - without knowledge of the contents of the encrypted part > > Would you like to propose some text to help explain this? > > I'd be happy to. I'll craft text and come back to you on this one. > > > > > >> * Section 5.1: > >> > >> Protocol methods can be designed to > >> probe to discover whether the specific option(s) can be used along > >> the current path, enabling use on arbitrary paths. > >> > >> This might be a problem of "English as a second language", but the above > >> text sounds to me like you can enable use of this feature on arbitrary > >> paths.... where's I'd probably argue that what you can do is to > >> *disable* the feature on paths where the feature cannot be used, such > >> that you may still communicate (albeit without using the aforementioned > >> feature). > >> > >> Another simpler fix might be s/arbitrary/specific/ > > > > The whole para currently reads: > > > > An arbitrary path can include one or more network devices that drop > > packets that include a specific header or option used for this > > purpose (see [RFC7872]). This could impact the proper functioning of > > the protocols using the path. Protocol methods can be designed to > > probe to discover whether the specific option(s) can be used along > > the current path, enabling use on arbitrary paths. > > > > I think this last sentence can indeed be improved, and I suggest > > something like: > > > > Protocol methods can be designed to > > probe to discover whether the specific option(s) can be used along > > the current path, enabling or disabling their use on the path. > > > > Is that better? > > That's perfect, and indeed addressed my comment. > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Feb 11 10:40:34 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A2F3A184E; Thu, 11 Feb 2021 10:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8joHuNJQ6z-r; Thu, 11 Feb 2021 10:40:22 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519643A1845; Thu, 11 Feb 2021 10:40:22 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9A68E283DAC; Thu, 11 Feb 2021 18:40:15 +0000 (UTC) To: Tom Herbert Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> From: Fernando Gont Message-ID: <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> Date: Thu, 11 Feb 2021 15:40:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 18:40:27 -0000 On 11/2/21 15:18, Tom Herbert wrote: [...] > > When the transport layer is encrypted, network devices would only see > the plaintext EH and that is only what that is what they can act on. > At the destination, we could try to rectify transport information in > HBH with decrypted plaintext transport headers, but I suspect that > wouldn't typically be done. The HBH information is only operationally > useful to the network, not the transport endpoints that have access to > the transport header. Then this is what an attacker would do: He/she would advertise on a HBH option something that looks sensible to the guy enforcing a network-based security policy, and then at transport would do what he/she needs to do. :-) e.g., HBH could advertise that my packets are directed to ports 80/443, while in transport they are actually directed to port, say, 22. > The only point of the end host comparing the > data would be to enforce the network's security policy, but it's not > common that end hosts actually know what the network security policies > are. The point for the end-node comparing both values is so that it makes sense in the first place to enforce a security policy based on e.g. HBH-conveyed information. Otherwise, the operator/admin knows that attackers will do what I'd suggested above, and they wouldnt even bother to try to enforce security policy which is circumvent-able "by design", so to speak :-) If consistence cannot be guaranteed, then the mechanism won't be useful for enforcing security policies. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 11 11:11:05 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A343A187A; Thu, 11 Feb 2021 11:11:01 -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, RCVD_IN_DNSWL_BLOCKED=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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 tbr_M4Mstzhc; Thu, 11 Feb 2021 11:10:59 -0800 (PST) Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A9A3A1879; Thu, 11 Feb 2021 11:10:59 -0800 (PST) Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 9E09210F2C0; Thu, 11 Feb 2021 14:10:58 -0500 (EST) (envelope-from heard@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=tFG2N3YTRooPsRcDNpbxAvdKaJ0=; b=Xj8DFC mHr1DoeWAbWGs/tjnJqoTyOoiB69kdShPV5cnH3UTpLJRPd/chi+2rp331E9/SYd 7Mg7e1JhircMxuRdezgHDTopYX5SoXymYr8dNA1N5VDIHenDp5cTYhyqTfqAycnK p/ipDCoxiuYE0b3gPJfeYey9xmHKTiz2KUnn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=fdN1jOTlcMVS+9E+U3XCz5s8ywRIcyEt aYEhvFrfy4GCv9X1en9MhP46Qe8t4BPhXAvRXVgg0be0Zs1HHtBEJ6cwf9cAUBN4 bGIvN0GyTEa+SjkDg3rdu/ogUK41nIRfxdGo3JncJQ8nieZfwSCeQZSwqu1lc5l1 IXWeNo6hJ+g= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 9515110F2BA; Thu, 11 Feb 2021 14:10:57 -0500 (EST) (envelope-from heard@pobox.com) Received: from mail-il1-f182.google.com (unknown [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 2D9A110F2AF; Thu, 11 Feb 2021 14:10:55 -0500 (EST) (envelope-from heard@pobox.com) Received: by mail-il1-f182.google.com with SMTP id y15so6048958ilj.11; Thu, 11 Feb 2021 11:10:55 -0800 (PST) X-Gm-Message-State: AOAM531562rK0BHs1Gvhx3Ltgw6PGyiCpcv9izp9n4NF89TAw4nYvYzT 9xk9PSEpxMF4x+VAqu2hLu5YdUNfAVFP7WO+fOw= X-Google-Smtp-Source: ABdhPJzuOaEw0R02RguSJW5a495FFgnf5dOjArqf6jZowzRzUsXNmFDuYRuH99xj76RaIw5dKPt6c6wWxEKHb9h9mjc= X-Received: by 2002:a05:6e02:152f:: with SMTP id i15mr7014410ilu.183.1613070653952; Thu, 11 Feb 2021 11:10:53 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> In-Reply-To: <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> From: "C. M. Heard" Date: Thu, 11 Feb 2021 11:10:42 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Tom Herbert , Gorry Fairhurst , "tsvwg@ietf.org" , Benjamin Kaduk , "saag@ietf.org" , Fernando Gont Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: DD83828A-6C9C-11EB-8116-E43E2BB96649-06080547!pb-smtp20.pobox.com Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:11:01 -0000 On Thu, Feb 11, 2021 at 10:41 AM Fernando Gont wrote: > > On 11/2/21 15:18, Tom Herbert wrote: > [...] > > > > When the transport layer is encrypted, network devices would only see > > the plaintext EH and that is only what that is what they can act on. > > At the destination, we could try to rectify transport information in > > HBH with decrypted plaintext transport headers, but I suspect that > > wouldn't typically be done. The HBH information is only operationally > > useful to the network, not the transport endpoints that have access to > > the transport header. > > Then this is what an attacker would do: > He/she would advertise on a HBH option something that looks sensible to > the guy enforcing a network-based security policy, and then at transport > would do what he/she needs to do. :-) > > > e.g., HBH could advertise that my packets are directed to ports 80/443, > while in transport they are actually directed to port, say, 22. Wasn't this the sort of problem that AH was intended to solve? Mike Heard From nobody Thu Feb 11 11:11:31 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B9D3A18C0 for ; Thu, 11 Feb 2021 11:11:23 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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=herbertland-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 eWvGAfWCqlWN for ; Thu, 11 Feb 2021 11:11:21 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 DBFC63A188D for ; Thu, 11 Feb 2021 11:11:19 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id y8so8110266ede.6 for ; Thu, 11 Feb 2021 11:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YO2SRXdPlFo/91MEMU1J2NLIKIA86vTYJL5dEfcVYf0=; b=GZ19Vk1CtJnBVyKyTUDKEVP7en6h6MR3SXmmqWQlMnTGrcWor8LhfT5mljjkH5fWJO W6Mt/K+9T0Ld2gzKFH7PXuycRh+fnELN6sD0ssSCAf6LnO6UFvSCjUQXwbo2ak6Q+aVW n9JEcykSVesb5kwsQxwCJpX2CcLGt2+a+vmXwni6jDuTi1Ssip4C9Y+DClJlzGQzbQMF TkcMJmarHfFabqGqQMBwBAtkEfjxRe04FTC8FJiYv4Q/IMZD8y4PNndap9dD21QshChk jXSK/V9ULv5gPEYqhEi4aPAxk+mnFd0XIS5/65r/3ztzKTxnF8z7tEuV35HgaPS33fI4 pTTw== 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=YO2SRXdPlFo/91MEMU1J2NLIKIA86vTYJL5dEfcVYf0=; b=CprA2dO5BWNhz4MQrDRkLX7MyH7Lm7dWzhqkOyJaFApNLRaJV8I9fCulJgKVsKat0I oO3znP3PecxIG+rJ+bvaHjKGZBk/ZjJOU4iXSMQIb5XqtDY5PQYk6gzgz874lJh8v8W6 JGwUMfkSbYs5MFNC0A4EnROEQWQslMZPqIz2wN9sDrK+LuVYMwbPQ4I1R+kGcFJtnhsP CXU9dF2TdeupjdKW5EowNLwKaIRgmWnPoLdzK8Xp03pqu4/EKmgjR+qVCzFBVZMUiUVT krP/ehHfx+8+7nmn4EzlzTW1TSr0+mxggD8rS7ZlzhALPZShOYPpWAfZsr+VVyhcZGXp 13TQ== X-Gm-Message-State: AOAM531MJfOKyjLt/tWvFb0ycnPswIlgxRUM0ReZRpFdQAynU8MvQNJi oSOlbKKCAL1ZGdVBW0mEd6GQv7Y8fv2ILkCqj1qmLw== X-Google-Smtp-Source: ABdhPJxdK9Uh5PiFArnt3/wUxaTvlXtFceba01VImx6L4A80eahwH4hCGuOyvbr2YVu0IWDH2RaajEb4gHYsU4IT/6s= X-Received: by 2002:a05:6402:3070:: with SMTP id bs16mr9585052edb.22.1613070678236; Thu, 11 Feb 2021 11:11:18 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> In-Reply-To: <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> From: Tom Herbert Date: Thu, 11 Feb 2021 12:11:07 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:11:29 -0000 On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont wrote: > > On 11/2/21 15:18, Tom Herbert wrote: > [...] > > > > When the transport layer is encrypted, network devices would only see > > the plaintext EH and that is only what that is what they can act on. > > At the destination, we could try to rectify transport information in > > HBH with decrypted plaintext transport headers, but I suspect that > > wouldn't typically be done. The HBH information is only operationally > > useful to the network, not the transport endpoints that have access to > > the transport header. > > Then this is what an attacker would do: > He/she would advertise on a HBH option something that looks sensible to > the guy enforcing a network-based security policy, and then at transport > would do what he/she needs to do. :-) > > > e.g., HBH could advertise that my packets are directed to ports 80/443, > while in transport they are actually directed to port, say, 22. > It's more likely that information in the HBH would be generic and abstract, afterall the whole point of encrypting the transport header is to hide information from the network that it doesn't require, not to just blindly volunteer the same information somewhere else in the packet. Port numbers, for instance, are not required for delivery and in fact are prone to misinterpretation in the network (RFC7605)-- IMO it makes no sense to put those in a HBH option. Regardless of HBH though, if the preponderence of transport headers are encrytped then network security policiy that relies on the information will need to change. Tom > > > > The only point of the end host comparing the > > data would be to enforce the network's security policy, but it's not > > common that end hosts actually know what the network security policies > > are. > > The point for the end-node comparing both values is so that it makes > sense in the first place to enforce a security policy based on e.g. > HBH-conveyed information. > > Otherwise, the operator/admin knows that attackers will do what I'd > suggested above, and they wouldnt even bother to try to enforce security > policy which is circumvent-able "by design", so to speak :-) > > If consistence cannot be guaranteed, then the mechanism won't be useful > for enforcing security policies. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Feb 11 11:28:07 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDF3A1899; Thu, 11 Feb 2021 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzEtAwzeV5Tb; Thu, 11 Feb 2021 11:28:02 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4713A1898; Thu, 11 Feb 2021 11:28:02 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3DFA4283A13; Thu, 11 Feb 2021 19:27:53 +0000 (UTC) To: Tom Herbert Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> From: Fernando Gont Message-ID: <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> Date: Thu, 11 Feb 2021 16:27:47 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:28:05 -0000 On 11/2/21 16:11, Tom Herbert wrote: > On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont wrote: >> >> On 11/2/21 15:18, Tom Herbert wrote: >> [...] >>> >>> When the transport layer is encrypted, network devices would only see >>> the plaintext EH and that is only what that is what they can act on. >>> At the destination, we could try to rectify transport information in >>> HBH with decrypted plaintext transport headers, but I suspect that >>> wouldn't typically be done. The HBH information is only operationally >>> useful to the network, not the transport endpoints that have access to >>> the transport header. >> >> Then this is what an attacker would do: >> He/she would advertise on a HBH option something that looks sensible to >> the guy enforcing a network-based security policy, and then at transport >> would do what he/she needs to do. :-) >> >> >> e.g., HBH could advertise that my packets are directed to ports 80/443, >> while in transport they are actually directed to port, say, 22. >> > It's more likely that information in the HBH would be generic and > abstract, afterall the whole point of encrypting the transport header > is to hide information from the network that it doesn't require, not > to just blindly volunteer the same information somewhere else in the > packet. Port numbers, for instance, are not required for delivery and > in fact are prone to misinterpretation in the network (RFC7605)-- IMO > it makes no sense to put those in a HBH option. > > Regardless of HBH though, if the preponderence of transport headers > are encrytped then network security policiy that relies on the > information will need to change. The folks running networks might as well argue that if you want your protocol to be successfully deployed (or at all deployed), your protocol might need to change. It's a tussle. ANd I see valid arguments on both sides. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 11 11:43:39 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E123A18B0 for ; Thu, 11 Feb 2021 11:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 89OvL5eWJc6g for ; Thu, 11 Feb 2021 11:43:33 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 B6A4A3A18B2 for ; Thu, 11 Feb 2021 11:43:32 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id s5so8176623edw.8 for ; Thu, 11 Feb 2021 11:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0jygqf0GD78AcMehZjtbZQJoMxcDzKe6UAGycWDfsV4=; b=rhR+I3A119NXhIL0H1Qkh9Jo33wFMjycmSS5fwUfxEYqgj8w4mLVJobLC6ZmbW65HZ /ZwciTG0r+pL3/J9slwPLjHC9a0KSg9FCJcSy6sI5Jd1H8BHwWUwLqA/camiYJ/CQYwW 02mEhiqrkEZRLk2DmFyYLeldaLMMNboMJt/NeuBnQTBYSNoiNsxKmAd4W93Jlio2/Zrj z58jFhuGa1zgfzPjXcJCZYSW5O4PQAn4c1VM+kBUkaVDufMbQ8cMWUdTw6d0tXgu/6zT LQEEUr42VhHgBKVgBs5enepoxSafd2+t4SD9TVuk6Ee9BlqapAwdam4OyHYcoDk34kO9 wg5g== 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=0jygqf0GD78AcMehZjtbZQJoMxcDzKe6UAGycWDfsV4=; b=XdVQzviB3LqipoAItOpHFeOnwVzw0vq3Z+npndXFlQ2v6DeimxUkcQIUQmnuh/EAOk ZkRvH2vQW+6LjdGRlqPSTFQ0eVQhkKDQMI2X7FlsWizX6ScHpqy0QmCoXccz+gNzGhQ9 MTCaKo5mtVs0JdchrBLRyu9B+FNuQOduig0nGNawj8a0+7nPufE1IBT0kVNvbuAZspxR sOSoQGW2CFUe19wznAsClZUHE9K6xIIEYagmTvd+AoUHtvZeMHWwAcXrydDYbQzQGv/F bo5+P/GM3h1i8P6FqwolHwmLkTIlP5+6gLQrPeGF0uBJRHLegt5zlp98tq7WeaV1jutv q4FA== X-Gm-Message-State: AOAM532Hl3CYtZfN7RBecr+xrvnkuODezmyM+7tKvQ76M5ib16QQ1WcU jfv2F+spz/+KriuxIMcsMdvittC/h7DaZApnkz1mEA== X-Google-Smtp-Source: ABdhPJzz0r1/KipVW/Q5Atc/z6X+vDHk8cCZkSf+G9p4meI2pRDt+DXXRIlB0ol51zeYvDCLD6WmcjEzDJl1yxz90DI= X-Received: by 2002:aa7:c418:: with SMTP id j24mr9982019edq.293.1613072610635; Thu, 11 Feb 2021 11:43:30 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> In-Reply-To: <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> From: Tom Herbert Date: Thu, 11 Feb 2021 12:43:19 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 19:43:34 -0000 On Thu, Feb 11, 2021 at 12:28 PM Fernando Gont wrote: > > On 11/2/21 16:11, Tom Herbert wrote: > > On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont wrote: > >> > >> On 11/2/21 15:18, Tom Herbert wrote: > >> [...] > >>> > >>> When the transport layer is encrypted, network devices would only see > >>> the plaintext EH and that is only what that is what they can act on. > >>> At the destination, we could try to rectify transport information in > >>> HBH with decrypted plaintext transport headers, but I suspect that > >>> wouldn't typically be done. The HBH information is only operationally > >>> useful to the network, not the transport endpoints that have access to > >>> the transport header. > >> > >> Then this is what an attacker would do: > >> He/she would advertise on a HBH option something that looks sensible to > >> the guy enforcing a network-based security policy, and then at transport > >> would do what he/she needs to do. :-) > >> > >> > >> e.g., HBH could advertise that my packets are directed to ports 80/443, > >> while in transport they are actually directed to port, say, 22. > >> > > It's more likely that information in the HBH would be generic and > > abstract, afterall the whole point of encrypting the transport header > > is to hide information from the network that it doesn't require, not > > to just blindly volunteer the same information somewhere else in the > > packet. Port numbers, for instance, are not required for delivery and > > in fact are prone to misinterpretation in the network (RFC7605)-- IMO > > it makes no sense to put those in a HBH option. > > > > Regardless of HBH though, if the preponderence of transport headers > > are encrytped then network security policiy that relies on the > > information will need to change. > > The folks running networks might as well argue that if you want your > protocol to be successfully deployed (or at all deployed), your protocol > might need to change. > Perhaps, but in order to change the protocol to satisfy the requirements of folks running networks, we'd need to know *what* the requirements are. For instance, if someone were to say that networks require more information than what is in the IP header to successfully deliver packets, then I will immediately ask that they specify *exactly* what information they need. Until/unless that is answered we are left guessing as to what may or may not be acceptable in various networks and the tussle continues. > It's a tussle. ANd I see valid arguments on both sides. > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Feb 11 13:19:52 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91E3A14F6; Thu, 11 Feb 2021 13:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jsel2gouvUsT; Thu, 11 Feb 2021 13:19:46 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6903A14D2; Thu, 11 Feb 2021 13:19:34 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6602628040A; Thu, 11 Feb 2021 21:19:30 +0000 (UTC) To: Tom Herbert Cc: Gorry Fairhurst , "Black, David" , Fernando Gont , Benjamin Kaduk , "saag@ietf.org" , "tsvwg@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> From: Fernando Gont Message-ID: <06c475b7-abdf-cd64-86f7-cd9a046ee4ed@si6networks.com> Date: Thu, 11 Feb 2021 18:19:20 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:19:50 -0000 On 11/2/21 16:43, Tom Herbert wrote: > On Thu, Feb 11, 2021 at 12:28 PM Fernando Gont wrote: >> >> On 11/2/21 16:11, Tom Herbert wrote: >>> On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont wrote: >>>> >>>> On 11/2/21 15:18, Tom Herbert wrote: >>>> [...] [....] >>> >>> Regardless of HBH though, if the preponderence of transport headers >>> are encrytped then network security policiy that relies on the >>> information will need to change. >> >> The folks running networks might as well argue that if you want your >> protocol to be successfully deployed (or at all deployed), your protocol >> might need to change. >> > Perhaps, but in order to change the protocol to satisfy the > requirements of folks running networks, we'd need to know *what* the > requirements are. src IP address, dst ip address, upper layer protocol type, src port number, dst port number > For instance, if someone were to say that networks > require more information than what is in the IP header to successfully > deliver packets, That assumes that networks just blindly forward packets based on the dst (and possibly src) addresses. But operational practice suggests that that's not the case. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 11 13:44:40 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C83A0BF5; Thu, 11 Feb 2021 13:44:35 -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 3U2iz3kT6BWK; Thu, 11 Feb 2021 13:44:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269883A0BF1; Thu, 11 Feb 2021 13:44:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5237438A16; Thu, 11 Feb 2021 16:47:54 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qP8YqVGsDZVG; Thu, 11 Feb 2021 16:47:53 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BEEDE38A15; Thu, 11 Feb 2021 16:47:53 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 98CE2320; Thu, 11 Feb 2021 16:44:30 -0500 (EST) From: Michael Richardson To: Fernando Gont , "tsvwg@ietf.org" , "saag@ietf.org" In-Reply-To: <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Feb 2021 16:44:30 -0500 Message-ID: <3717.1613079870@localhost> Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:44:36 -0000 Fernando Gont wrote: >> When the transport layer is encrypted, network devices would only s= ee >> the plaintext EH and that is only what that is what they can act on= . >> At the destination, we could try to rectify transport information i= n >> HBH with decrypted plaintext transport headers, but I suspect that >> wouldn't typically be done. The HBH information is only operational= ly >> useful to the network, not the transport endpoints that have access= to >> the transport header. > Then this is what an attacker would do: He/she would advertise on a = HBH > option something that looks sensible to the guy enforcing a > network-based security policy, and then at transport would do what > he/she needs to do. :-) > e.g., HBH could advertise that my packets are directed to ports 80/4= 43, > while in transport they are actually directed to port, say, 22. That's silly amount of subterfuge. Since you have the cooperation of the target machine, just run SSH on port= 443. In fact, https://packages.debian.org/buster/sslh does this for you. Network middle boxes need to get the *($%#$% out of transport protocols. Back in 1996 (!) I explained how to have authorized audit boxes for IPsec using securityhop-by-securityhop ESP and end-to-end AH. It requires the blessing of the end points, and we regularly do way more complex and stupider things in TLS today. People thought my solution was crazy. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Thu Feb 11 14:11:35 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BA3A0D08; Thu, 11 Feb 2021 14:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0ZB5Zl3w-uv; Thu, 11 Feb 2021 14:11:24 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A71B3A0D20; Thu, 11 Feb 2021 14:11:24 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 773A2283B44; Thu, 11 Feb 2021 22:11:21 +0000 (UTC) To: Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <3717.1613079870@localhost> From: Fernando Gont Message-ID: Date: Thu, 11 Feb 2021 19:04:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3717.1613079870@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:11:30 -0000 On 11/2/21 18:44, Michael Richardson wrote: > Fernando Gont wrote: > >> When the transport layer is encrypted, network devices would only see > >> the plaintext EH and that is only what that is what they can act on. > >> At the destination, we could try to rectify transport information in > >> HBH with decrypted plaintext transport headers, but I suspect that > >> wouldn't typically be done. The HBH information is only operationally > >> useful to the network, not the transport endpoints that have access to > >> the transport header. > > > Then this is what an attacker would do: He/she would advertise on a HBH > > option something that looks sensible to the guy enforcing a > > network-based security policy, and then at transport would do what > > he/she needs to do. :-) > > > e.g., HBH could advertise that my packets are directed to ports 80/443, > > while in transport they are actually directed to port, say, 22. > > That's silly amount of subterfuge. > Since you have the cooperation of the target machine, Not always. And not always you're so free to change the service port. > just run SSH on port 443. > In fact, https://packages.debian.org/buster/sslh does this for you. Indeed. But that's not the point. The point is that if the network wants to block specific traffic, I needs to tell what the traffic is about. > Network middle boxes need to get the *($%#$% out of transport protocols. There are operational reasons for which the peek at transport. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Feb 11 14:31:58 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE563A0D5C; Thu, 11 Feb 2021 14:31:56 -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 InqeBygHaN8C; Thu, 11 Feb 2021 14:31:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00883A0D55; Thu, 11 Feb 2021 14:31:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E6C4738A3E; Thu, 11 Feb 2021 17:35:14 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DxzCNfxnaMxJ; Thu, 11 Feb 2021 17:35:14 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 722B838A3C; Thu, 11 Feb 2021 17:35:14 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30450320; Thu, 11 Feb 2021 17:31:51 -0500 (EST) From: Michael Richardson To: "tsvwg\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:31:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tom Herbert wrote: > Perhaps, but in order to change the protocol to satisfy the > requirements of folks running networks, we'd need to know *what* the > requirements are. For instance, if someone were to say that networks > require more information than what is in the IP header to successfully > deliver packets, then I will immediately ask that they specify > *exactly* what information they need. Until/unless that is answered we > are left guessing as to what may or may not be acceptable in various > networks and the tussle continues. 15+ years, when "transport-friendly ESP" was litigated (and to my surprise got a protocol number), the 3G people went on and on about how much better they could do if we (the IPsec people) would show them TCP information. I asked, repeatedly, for details of this supposed improvement. I got nothing in justification. My request was simple: if you want me to increase my risk, then show me what the benefit is. (_Show me the money_) I now know that really, they were dealing with ad-hoc solutions to bufferbloat, but they didn't know that then. BTW: nobody uses TF-ESP. It's totally and completely dead. There was never any benefit worth the risk. Fernando says they need src/dst port, but I disagree. They want every bit they can get, including the encrypted insides of TLS, b= ut they have no idea really, what legal things they actually want to do with i= t. Showing your layer-4 header is unlawful search in my opinion. The pen-registry only needs to have the destination number to connect the c= all. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAlsFYACgkQgItw+93Q 3WVB9wf/dDYL2Yn0ub1mUI1wcZNuIlqcZHc42JpKpUeSZp9DqUqHV9FS+UhxuPgG FbNa7MmzXgI6vUZEr2FHkOPKR8enw5hVcbUKCkP3Yyec+pK5HzlN8G8amyu8e4+u f6hZwcq6fedE7IRC2kaP90/mp5DKcVp3Lg4hNnwyd3BBMURpdyEg3673PNfJ4p6a 6BW6jcOVCxGgDHfQ9bga45dhNaf11bffzHVyUEGWbwzrsWf23mL+dVGrjR++taTN klNKpZ7F++lxoRbN+4tfkIVezjFLG30dX/idliMlQ9nA/LljAp2PDBSoV+h0EP6D 4FpVBZ2GXupKdFFDABz+xuZSts7SLw== =m+wo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 11 15:19:46 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4B3A0E06 for ; Thu, 11 Feb 2021 15:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 EdFhKlRLBQH2 for ; Thu, 11 Feb 2021 15:19:42 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 472BA3A0E08 for ; Thu, 11 Feb 2021 15:19:42 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id s11so8788754edd.5 for ; Thu, 11 Feb 2021 15:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kj+JDKq7Y3EI54fOd3TqP+uF9d9KW6IL6hYvNFJ9vno=; b=W47DwsUv8Pqwc+VDJNQ/RFJO6bTvZTpByvuF5GVBthSQ3dUy/qs37EO7rddHGsYnz8 cZM4lN40S4BsMvNxPyU+12DnmMq4Fkf4OrvIT78bttkdOliRrb95DLXCHXw0y7LqgpY/ vnTXmi3NT5bIPmelsq4ew7QOxAHX/x+2ijx5gHQXU114exvW8fHOaomw5Cn0pJaB7GkY lYgJuzS172LzK94J4CN1AX2okLkV4teIPHWxV9XvjY6fMCGa6jLj9/WZ/if8WyPgQeMt 9bpFQx6z3twK5YgBLZgGanr7IbO6+8qnSeMvVmXeYPMnrBxKvxc2PzNotWdeFj6PZ6gx UlpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kj+JDKq7Y3EI54fOd3TqP+uF9d9KW6IL6hYvNFJ9vno=; b=U8HiUG9cRXvdNzNdJIPE7l6rhtO4vJeHwhtcttd8AC1QCuzbSpxZwkOfPaBK50yB0z c0beMItqnV87v4JgyS7xWgcR5KcNwijVOvswPWvlwY0wHvxhK2s58QbvzYnhGkSsj5I9 2ntHI7cXWjOyPpSgG05/LguQadHuGfsMi3cLqDqCouCdxguH6oaBNfA5jXu2P9RaPYaF ZkV/I3VNyX4f9ZKZs5plHlPBly13sOjx77EF6NCo/o7ZcFuWWjKLr7mT7hF9cAIXn8cF rwA+HXPk31uTKAfUv+Nt4o7R46/frAZPYyzgzcXu+t5IBDBQIrguBXkLT3yrqwdm+24i 5sFA== X-Gm-Message-State: AOAM530+OoBTgYLwQ9yDRwwOiEpxF+GItyQI17j/7ctXyYC8dq634TTi PB5PWusdmZ28PKpm22t0tvAmHngma3R4bEq8kAjQF0avi0xEtA== X-Google-Smtp-Source: ABdhPJz2TpYZRaAs5eOAKWp4kC3Z23hQ3OxT83Yu8zSpVYCkcimy5J82vsrT2FprC/AJ4Vl/b5htqN5j3znuitMLBU8= X-Received: by 2002:a05:6402:3070:: with SMTP id bs16mr525881edb.22.1613085580762; Thu, 11 Feb 2021 15:19:40 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> In-Reply-To: <16740.1613082711@localhost> From: Tom Herbert Date: Thu, 11 Feb 2021 16:19:29 -0700 Message-ID: To: Michael Richardson Cc: "tsvwg@ietf.org" , "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 23:19:44 -0000 On Thu, Feb 11, 2021 at 3:32 PM Michael Richardson wrote: > > > Tom Herbert wrote: > > Perhaps, but in order to change the protocol to satisfy the > > requirements of folks running networks, we'd need to know *what* th= e > > requirements are. For instance, if someone were to say that network= s > > require more information than what is in the IP header to successfu= lly > > deliver packets, then I will immediately ask that they specify > > *exactly* what information they need. Until/unless that is answered= we > > are left guessing as to what may or may not be acceptable in variou= s > > networks and the tussle continues. > > 15+ years, when "transport-friendly ESP" was litigated (and to my surpris= e > got a protocol number), the 3G people went on and on about how much bette= r > they could do if we (the IPsec people) would show them TCP information. > I asked, repeatedly, for details of this supposed improvement. > I got nothing in justification. My request was simple: if you want me to > increase my risk, then show me what the benefit is. > (_Show me the money_) > I now know that really, they were dealing with ad-hoc solutions to > bufferbloat, but they didn't know that then. > > BTW: nobody uses TF-ESP. It's totally and completely dead. There was neve= r > any benefit worth the risk. > > Fernando says they need src/dst port, but I disagree. > They want every bit they can get, including the encrypted insides of TLS,= but > they have no idea really, what legal things they actually want to do with= it. > That's why I chose my words carefully and asked that "they specify *exactly* what information they need". What MUST a host stack or application expose to the network concerning it's traffic? (i.e. we need the draft describing this in normative language). It's also hard not to notice how similar these discussions are with those that occurred when TLS was being brought up. Some network providers argued vehemently that if they aren't able to inspect HTTP payload they can't provide the services and security their customers need. They lost those arguments, as I suspect similar arguments that transport layer shouldn't be encrypted will also fail. Tom > Showing your layer-4 header is unlawful search in my opinion. > The pen-registry only needs to have the destination number to connect the= call. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > From nobody Thu Feb 11 17:56:12 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38C3A1060; Thu, 11 Feb 2021 17:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmnAovTJEo89; Thu, 11 Feb 2021 17:56:06 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21913A105F; Thu, 11 Feb 2021 17:56:05 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 476E6283B7D; Fri, 12 Feb 2021 01:55:56 +0000 (UTC) To: Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> From: Fernando Gont Message-ID: <0590c44a-847d-a171-39b1-cb5e685bb9db@gont.com.ar> Date: Thu, 11 Feb 2021 22:55:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <16740.1613082711@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 01:56:11 -0000 On 11/2/21 19:31, Michael Richardson wrote: > > Tom Herbert wrote: > > Perhaps, but in order to change the protocol to satisfy the > > requirements of folks running networks, we'd need to know *what* the > > requirements are. For instance, if someone were to say that networks > > require more information than what is in the IP header to successfully > > deliver packets, then I will immediately ask that they specify > > *exactly* what information they need. Until/unless that is answered we > > are left guessing as to what may or may not be acceptable in various > > networks and the tussle continues. > > 15+ years, when "transport-friendly ESP" was litigated (and to my surprise > got a protocol number), the 3G people went on and on about how much better > they could do if we (the IPsec people) would show them TCP information. > I asked, repeatedly, for details of this supposed improvement. > I got nothing in justification. My request was simple: if you want me to > increase my risk, then show me what the benefit is. Well, this is how operators' version of it: RFC7872. -- i.e.: "Your ESP packets probably don't go through. **Show me the money**". > (_Show me the money_) > I now know that really, they were dealing with ad-hoc solutions to > bufferbloat, but they didn't know that then. > > BTW: nobody uses TF-ESP. It's totally and completely dead. There was never > any benefit worth the risk. > > Fernando says they need src/dst port, but I disagree. Ask operators. That's what I did. > They want every bit they can get, including the encrypted insides of TLS, but > they have no idea really, what legal things they actually want to do with it. There's folks that probably want as much as they can get.. But the vast majory of them want IP `transport header, for load-balancing, variety of ACLs, et al. [...] > The pen-registry only needs to have the destination number to connect the call. For networks where packets flow frelly between any arbitrary nodes, yes. I doubt such networks exists, except in specific walled gardens. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Thu Feb 11 18:08:57 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5663A1076; Thu, 11 Feb 2021 18:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVvKlhzrUdcj; Thu, 11 Feb 2021 18:08:48 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17AC3A1072; Thu, 11 Feb 2021 18:08:46 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A8ECD283B7D; Fri, 12 Feb 2021 02:08:40 +0000 (UTC) To: Tom Herbert , Michael Richardson Cc: "tsvwg@ietf.org" , "saag@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> From: Fernando Gont Message-ID: Date: Thu, 11 Feb 2021 23:07:14 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 02:08:53 -0000 On 11/2/21 20:19, Tom Herbert wrote: > On Thu, Feb 11, 2021 at 3:32 PM Michael Richardson > wrote: [....] > > It's also hard not to notice how similar these discussions are with > those that occurred when TLS was being brought up. Some network > providers argued vehemently that if they aren't able to inspect HTTP > payload they can't provide the services and security their customers > need. They lost those arguments, as I suspect similar arguments that > transport layer shouldn't be encrypted will also fail. FWIW, I'm certainly *not* arguing that the transport layer should not be encrypted. I'm simply pointing out that operators do more things with packets that blindly forward packets on a per-packet and per-dst-address basis. And that that, there are consequences of them not being able to access IP+transport metadata. When it comes to QUIC, it could well be the case that then only thing they care in this respect is IP header + UDP header... and e.g. rate limit as they do for some other UDP traffic. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri Feb 12 06:47:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D3E3A1702 for ; Fri, 12 Feb 2021 06:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 FHp0OLj_lJyg for ; Fri, 12 Feb 2021 06:47:26 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 A89F43A16FC for ; Fri, 12 Feb 2021 06:47:25 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id q2so11143233eds.11 for ; Fri, 12 Feb 2021 06:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gDvGb+D4mddrs63XHzubiStBzaVffuOvCMev4NRJt3A=; b=GMFhWg+3kGM758C61Hh+y+yB7FvdzPGsT0vcFefGxJhLgSBJm+ruqpOtZtHBWZ0Mje VgEejObTpvhOCfebJgZVIURNouQiNUWuFpn/F3gCYdhZvZGbJ4/gxqeEp5GD789kzuwm xi1zL9K4Xb9PGQXyt1aBW5Ujuel0QC43VJB+Psnu/ubxoNHs+sb0vnWU3K+tI29khgVZ eZTzlOmlIBiHnnnZW2rIT13mcFlgVFnwHhst8DEkJ8ZlQl/TEDIYea3MojnKwv+nQNXW 58H3IW6UdvIAKnBilFZCBFmr0Uyt4eILTa1oIr0ndVI7ehY+muHhikrzsrgTELpEJUdR Lgow== 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=gDvGb+D4mddrs63XHzubiStBzaVffuOvCMev4NRJt3A=; b=jH/elSX5Rnfb8w/5j+j43h3hnshSoSpbviimgg4+A/oGlpXvsbFwY8ZQfZi3b30Jpz nGvr/2Bdig5pr22BbfG8BCgiN+z2TpaBLlPZxG7pfo7pIrQJaqmI2JCpto1sE4cOPpA0 UDeppUyfVfR4Aq1w2DOOG08saKzA59zWUN5X7BAHFeEvXDOxmO7LFEVBGUhKAuN1gBXF tni/VeNGLxKr99+MO745Fy/hjiXyL+Enx7JuPLV16gwQNx+jzwdGJ6vvNGJaXMn21R8P ddg0zYRjG08LCzYXLvWKXarL2qYKkPzKcAxbVkQTuxLUqja8qocFsYyS/Vg15cgd4wcJ 6zrQ== X-Gm-Message-State: AOAM530O2mieY/9nPn6bILAGWUVSri72Xth+1KTpur3fTviWdO6ZnaY8 Xu+O+3R7eyB/Me392cioOlInXPmHxWSpe5+EDt0Gm/7sc7A= X-Google-Smtp-Source: ABdhPJyEFCGU1isd+4i74BcvBHUlKp2/jeCKidqKDW4LCMniHvjx3GSa/DOKvBRNoRsAYNq5Z72wQGmaNvPCOS3Ki6U= X-Received: by 2002:aa7:c418:: with SMTP id j24mr3782300edq.293.1613141243789; Fri, 12 Feb 2021 06:47:23 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> In-Reply-To: From: Tom Herbert Date: Fri, 12 Feb 2021 07:47:12 -0700 Message-ID: To: Fernando Gont Cc: Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 14:47:30 -0000 On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont wrote: > > On 11/2/21 20:19, Tom Herbert wrote: > > On Thu, Feb 11, 2021 at 3:32 PM Michael Richardson > > wrote: > [....] > > > > It's also hard not to notice how similar these discussions are with > > those that occurred when TLS was being brought up. Some network > > providers argued vehemently that if they aren't able to inspect HTTP > > payload they can't provide the services and security their customers > > need. They lost those arguments, as I suspect similar arguments that > > transport layer shouldn't be encrypted will also fail. > > FWIW, I'm certainly *not* arguing that the transport layer should not be > encrypted. I'm simply pointing out that operators do more things with > packets that blindly forward packets on a per-packet and per-dst-address > basis. And that that, there are consequences of them not being able to > access IP+transport metadata. > Fernando, Yes, this draft describes those consequences. But what has not been adequately discussed IMO has been the negative consequences of network devices acting on transport layer information. In particular, this leads to protocol ossification and creates a myriad of impediments for application developers trying to build applications to work across the whole Internet. For instance, if you say that QUIC is the only UDP protocol allowed on the Internet., i.e. identified by UDP port 443, then how could we ever deploy a new UDP protocol? This also leads to arms escalation between application developers and network operators, for instance if I do know that UDP port number 443 is the only port number allowed the network then I'll simply wrap my new UDP protocol in a UDP datagram to 443. You might complain that such things might be purposely bypassing your network security, yes they do, however host developers have no obligation to abide by some arcane set of network security policies that are unwritten and inconsistent across the Internet. I do believe that network operators and their users could benefit from getting more information in a packet than just Ip addresses. But I also believe that exposure of information should be volutary as opposed to mandatory, and it should be be very clear what the value is the to the user in exposing information. IMO, HBH is the best vehicle to express this information and there is some good work in Network tokens, FAST, and APN around this. Tom > When it comes to QUIC, it could well be the case that then only thing > they care in this respect is IP header + UDP header... and e.g. rate > limit as they do for some other UDP traffic. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > From nobody Fri Feb 12 10:05:48 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58EB3A1848; Fri, 12 Feb 2021 10:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHPZIsucWRUe; Fri, 12 Feb 2021 10:05:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 275D83A1847; Fri, 12 Feb 2021 10:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613153122; bh=iR5cIUYp+ZRsiOEgFqMDSoWEr5JFEw6viIVGxYxvyJA=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=bdUfoX1y1FBGNLXZJItcvXsif89V0aoqW7LaJjT26JN6ZzVEasXABYafPNTjkv1t3 Qh52UKMV75VB3e/zhz3BL4yu//2kK+N49k8nlhBz/26ij+BipU7BYLD7Tgu567vWtp TC07y32sk/XUVsNqoSlARa3n8OHoePqvN6XiKYT8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.150.123.71] ([80.187.113.71]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUGe1-1lJ6yf2QT5-00RHH8; Fri, 12 Feb 2021 19:05:22 +0100 Date: Fri, 12 Feb 2021 09:23:04 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org, Tom Herbert , Fernando Gont CC: Gorry Fairhurst , "tsvwg@ietf.org" , Benjamin Kaduk , "saag@ietf.org" , Fernando Gont From: Sebastian Moeller Message-ID: <0EA379CE-077D-4822-8991-62C1FD2D96DB@gmx.de> X-Provags-ID: V03:K1:BsOmdCGS2P3O7YhtvcIIUM0ctY5/3JB3+y4RY7voao2OwZN8I/R RNvhS8OZ6WVITQhKWFr3YgbSLmcQ2JmG/RD3otvvfDpx/qO7M9HhnAbLqisMGxy0RkOD7aa n/FJxBBXW4Ws2JYe+4Zlt5jIUmR5yRPI5bNd200i9llG9P+aFnyosp4Gord34HHdKCF58DJ uuYZfZS8z9rYYlfnND8Bw== X-UI-Out-Filterresults: notjunk:1;V03:K0:bWd/u47e9wo=:kcnnwofuzcGkItWmghUPlm oPUEXxhVqhvQaWTF3Q1j+43xeiMs8i5HCSV/YTpcfTbHok5bcEbRPb+kCbjOUw3SgAsdvZVeV bdwoNBE3KbBH6AR50NdpPsxnMCedof4YXeE7yj6e4xZ1I1JUxmJ0bLHPpYGlj8bsdQf4Li5pN QNgjrjId2MCEswObtr4rYVb30N1YgnMXDPMXdkcHBMaHNAY2U0UCYonFY//GzpFYTHksadBcD rcJ2wM30wf7fwdVqXijwR0nMAe2BGAkwlppR+RG9iyA1a3q0T3Rrh7HEe02rNF7r0MrNyQ7Xo aNE62+9qgF9S1zX9Zd7+ozspyS0gy4V7uSJFdmCOcUQ2j1q9y3I6SjXlFUwgTlh4w3Z8/lqGy pzJps3HJfF8xYOZQtpZrfytRU+tiMYZF1aIZgRPV5EjbdjkAoBw7PDE8JsJ35yNUz4Nb+D8d1 L8u6JOwwbuLJ/5uPcT5ARiXSe4jsy9X0810a+l+0jQTEbvMt3HrNsL9JjYloUdf0qTLI1tKME q6QODNR4RGPoNOomg34CqzYrx04H2cMz3Ia+TvDYA+IyGOvsD2EoP37Kf0583gTp+wf0tpE+D IM147R7uZjHtfLu0uae7wNvTOOTkUp5J0sQo72ZPNhxw05YHxCdDQGyLWYo3ClHp6ngYUd1c4 M4ZS07sZoJxDK4iHOEJjajINdsHga3G5MY2m9bARlDtgeXMlUOhl0z+aFGPAV3oEeEq89cCld 28nt2LKgmH58lrh/Yz6YTGptQlM61mmZZfbR/v9xd3qyGZWQ7W8ZYGbXYqpQDyzNlnHnFCkcG 2bbFVB8/NAEcA08sUlX3ZVqZp6rv6Qzu0Ktd2YTWeD+yu+eA4Rs2Hw1K8p4y+FsKR9BMViqrf 0W3cIGxXS/VNiI3udQ6Q== Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:05:43 -0000 Hi Tom, More below inline, prefixed with [SM]=2E On 11 February 2021 20:43:19 CET, Tom Herbert wrot= e: >On Thu, Feb 11, 2021 at 12:28 PM Fernando Gont >wrote: >> >> On 11/2/21 16:11, Tom Herbert wrote: >> > On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont > wrote: >> >> >> >> On 11/2/21 15:18, Tom Herbert wrote: >> >> [=2E=2E=2E] >> >>> >> >>> When the transport layer is encrypted, network devices would only >see >> >>> the plaintext EH and that is only what that is what they can act >on=2E >> >>> At the destination, we could try to rectify transport information >in >> >>> HBH with decrypted plaintext transport headers, but I suspect >that >> >>> wouldn't typically be done=2E The HBH information is only >operationally >> >>> useful to the network, not the transport endpoints that have >access to >> >>> the transport header=2E >> >> >> >> Then this is what an attacker would do: >> >> He/she would advertise on a HBH option something that looks >sensible to >> >> the guy enforcing a network-based security policy, and then at >transport >> >> would do what he/she needs to do=2E :-) >> >> >> >> >> >> e=2Eg=2E, HBH could advertise that my packets are directed to ports >80/443, >> >> while in transport they are actually directed to port, say, 22=2E >> >> >> > It's more likely that information in the HBH would be generic and >> > abstract, afterall the whole point of encrypting the transport >header >> > is to hide information from the network that it doesn't require, >not >> > to just blindly volunteer the same information somewhere else in >the >> > packet=2E Port numbers, for instance, are not required for delivery >and >> > in fact are prone to misinterpretation in the network (RFC7605)-- >IMO >> > it makes no sense to put those in a HBH option=2E >> > >> > Regardless of HBH though, if the preponderence of transport headers >> > are encrytped then network security policiy that relies on the >> > information will need to change=2E >> >> The folks running networks might as well argue that if you want your >> protocol to be successfully deployed (or at all deployed), your >protocol >> might need to change=2E >> >Perhaps, but in order to change the protocol to satisfy the >requirements of folks running networks, we'd need to know *what* the >requirements are=2E For instance, if someone were to say that networks >require more information than what is in the IP header to successfully >deliver packets, then I will immediately ask that they specify >*exactly* what information they need=2E [SM] While I only run my own home network, and hence only marginally quali= fy network operator at best, I do use per-flow queueing, currently based on= a 5-tupel, ot dst/src IP addresses, protocol, and dst/src port=2E That wor= ks amazingly well, so if possible I would like to be able to keep getting a= ccess to a stable representation of the port numbers, but I do not care whe= ther these stable representations are veridical or hashed, and I don't care= about an occasional hash collision=2E Since I am vaguely familiar with game theory, I would very much like to be= able to access the same field as used by the protocol itself (as anything = that can be gamed for an undeserved advantage, will be gamed)=2E That is so= mething like IPv6's flowlabel is less ideal than the real port numbers=2E Best Regards Sebadtian Until/unless that is answered we >are left guessing as to what may or may not be acceptable in various >networks and the tussle continues=2E > >> It's a tussle=2E ANd I see valid arguments on both sides=2E >> >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks=2Ecom >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From nobody Fri Feb 12 14:35:00 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E93A101C; Fri, 12 Feb 2021 14:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32D0kfGcieND; Fri, 12 Feb 2021 14:34:52 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B063A0C83; Fri, 12 Feb 2021 14:34:51 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5CAE028396E; Fri, 12 Feb 2021 22:34:48 +0000 (UTC) To: Tom Herbert , Fernando Gont Cc: Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> From: Fernando Gont Message-ID: <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com> Date: Fri, 12 Feb 2021 19:34:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 22:34:59 -0000 Hi, Tom, On 12/2/21 11:47, Tom Herbert wrote: > On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont wrote: >> [....] >> >> FWIW, I'm certainly *not* arguing that the transport layer should not be >> encrypted. I'm simply pointing out that operators do more things with >> packets that blindly forward packets on a per-packet and per-dst-address >> basis. And that that, there are consequences of them not being able to >> access IP+transport metadata. >> > Fernando, > > Yes, this draft describes those consequences. But what has not been > adequately discussed IMO has been the negative consequences of network > devices acting on transport layer information. In particular, this > leads to protocol ossification and creates a myriad of impediments for > application developers trying to build applications to work across the > whole Internet. For instance, if you say that QUIC is the only UDP The fact that QUIC employs UDP should probably already say a lot. :-) (yes, they were right, and very pragmatic about it) > protocol allowed on the Internet., i.e. identified by UDP port 443, > then how could we ever deploy a new UDP protocol? Please see above. > This also leads to > arms escalation between application developers and network operators, > for instance if I do know that UDP port number 443 is the only port > number allowed the network then I'll simply wrap my new UDP protocol > in a UDP datagram to 443. You might complain that such things might be > purposely bypassing your network security, yes they do, however host > developers have no obligation to abide by some arcane set of network > security policies that are unwritten and inconsistent across the > Internet. And operators might as well argue that they won't leave their production networks open to attack for the sake of not constraining future protocol development.... > I do believe that network operators and their users could benefit from > getting more information in a packet than just Ip addresses. But I > also believe that exposure of information should be volutary as > opposed to mandatory, and it should be be very clear what the value is > the to the user in exposing information. If it's voluntary, in many (most?) cases it cannot be relied upon, and hence is not of much use. > IMO, HBH is the best vehicle > to express this information and there is some good work in Network > tokens, FAST, and APN around this. RFC7872 seems to suggest otherwise. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Feb 12 16:35:25 2021 Return-Path: X-Original-To: saag@ietf.org Delivered-To: saag@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D23A1179; Fri, 12 Feb 2021 16:33:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640284.31337.16679119773743679281@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:22 -0800 Archived-At: Subject: [saag] saag - Requested session has been scheduled for IETF 110 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:31 -0000 Dear Benjamin Kaduk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. saag Session 1 (2:00 requested) Thursday, 11 March 2021, Session I 1300-1500 Room Name: Room 8 size: 508 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/saag.ics Request Information: --------------------------------------------------------- Working Group Name: Security Area Open Meeting Area Name: Security Area Session Requester: Benjamin Kaduk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: ace acme cfrg cose curdle dots emu gnap i2nsf ipsecme kitten lake lamps mls oauth openpgp privacypass rats sacm secdispatch secevent suit teep tls tokbind trans Technology Overlap: dmarc dprive sidrops uta pearg Key Participant Conflict: irtfopen People who must be present: Benjamin Kaduk Roman Danyliw Resources Requested: Special Requests: Normally we ask for Thursday "after lunch", but for the virtual meeting any time on Thursday should be fine. --------------------------------------------------------- From nobody Fri Feb 12 17:53:28 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FBA3A120B for ; Fri, 12 Feb 2021 17:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 JUDMfSA2kpin for ; Fri, 12 Feb 2021 17:53:15 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 233B43A11E4 for ; Fri, 12 Feb 2021 17:53:14 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id q10so1966416edt.7 for ; Fri, 12 Feb 2021 17:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SzNwPlfE+pd0+XJE5zuFp267bS8cuvdiY5V1PmK52xE=; b=iBPW7Srf1EvkzUklcpD1b/OW2vPnjUpJkEWXyM0+8Dwjc/i1MCurWeOXFjQJUsWOWZ 06QL8hMhBMxXdxCmNb4ihpG/y7qqOEb5gt8fWMs1hve8anGn8CxG6eE7flk6d1sf3a5d ulVHxuVrdfsbwgo2gw2Hf7lrE1D20Zg6zh454Z9KpY0mdzBBVLM/mi9n0Guyu7XUiuBf YhKyS5rujHi4eyiqoPQNeAtgHSogH9Hd52+Eo2ikhvNI6YOSC0IUtklvValDiWNnRl7B K8y05n5iixgunuIaLFGrsRAx+mWrlbdfiWv8MrW1arEOYXsnZRszwM8Sd6UMS3EMTxrC JwCA== 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=SzNwPlfE+pd0+XJE5zuFp267bS8cuvdiY5V1PmK52xE=; b=SYVwSria4q3fkfAu/vnqpSLiPM3D952tN1BfF7CkGeoz988YEi3fBouG+2cqOdjBJO ASK6gj6w4/DrEPG7jJGwCUUqPXN2mNGK9cZXI+802mR1e56KMk5TH7celvEBlmXJQwUP XQOwfSS/3Wlt1fwVco6go9NHhwrRd8ct9HSbbQi0XvT3WD8kHEXSvYvCmK76dZ4brM+2 EC/PfayCkZOiLmp6txic61Hvxok61VC22mtI4K+m6dK5qr0apOB3msHL9E/SKEL54sGa QtO1xD+aGIulFRNInXs6HX0bnW/4K/Py4pVKCO5O3YH2XbYX8cMCpFKPqoYbQThV8FzB 34Lg== X-Gm-Message-State: AOAM531BnM8ZE0Hj5Dk3H6ZA2DWlENKQWH5DkgAX397MeZxhQuREHEHW PwxoGjDhmWkweRfF7Q9EJ2WkT7NNbJ3eADJ2sXXvJg== X-Google-Smtp-Source: ABdhPJzm2Vz/d4ooEwYMI/saC4x6UbcbNLaiNjSRK9gz8JadaB9kQP5U3PgjqgF7ZBIU0R4Cgwvo4aDlk9TvCkWX3mQ= X-Received: by 2002:aa7:cb0d:: with SMTP id s13mr6027615edt.221.1613181193480; Fri, 12 Feb 2021 17:53:13 -0800 (PST) MIME-Version: 1.0 References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com> In-Reply-To: <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com> From: Tom Herbert Date: Fri, 12 Feb 2021 18:53:02 -0700 Message-ID: To: Fernando Gont Cc: Fernando Gont , Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 01:53:23 -0000 On Fri, Feb 12, 2021 at 3:34 PM Fernando Gont wrote: > > Hi, Tom, > > On 12/2/21 11:47, Tom Herbert wrote: > > On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont wrote: > >> > [....] > >> > >> FWIW, I'm certainly *not* arguing that the transport layer should not be > >> encrypted. I'm simply pointing out that operators do more things with > >> packets that blindly forward packets on a per-packet and per-dst-address > >> basis. And that that, there are consequences of them not being able to > >> access IP+transport metadata. > >> > > Fernando, > > > > Yes, this draft describes those consequences. But what has not been > > adequately discussed IMO has been the negative consequences of network > > devices acting on transport layer information. In particular, this > > leads to protocol ossification and creates a myriad of impediments for > > application developers trying to build applications to work across the > > whole Internet. For instance, if you say that QUIC is the only UDP > > The fact that QUIC employs UDP should probably already say a lot. :-) > > (yes, they were right, and very pragmatic about it) > > > > > protocol allowed on the Internet., i.e. identified by UDP port 443, > > then how could we ever deploy a new UDP protocol? > > Please see above. > > > > > This also leads to > > arms escalation between application developers and network operators, > > for instance if I do know that UDP port number 443 is the only port > > number allowed the network then I'll simply wrap my new UDP protocol > > in a UDP datagram to 443. You might complain that such things might be > > purposely bypassing your network security, yes they do, however host > > developers have no obligation to abide by some arcane set of network > > security policies that are unwritten and inconsistent across the > > Internet. > > And operators might as well argue that they won't leave their production > networks open to attack for the sake of not constraining future protocol > development.... > > > > > I do believe that network operators and their users could benefit from > > getting more information in a packet than just Ip addresses. But I > > also believe that exposure of information should be volutary as > > opposed to mandatory, and it should be be very clear what the value is > > the to the user in exposing information. > > If it's voluntary, in many (most?) cases it cannot be relied upon, and > hence is not of much use. > > > > > IMO, HBH is the best vehicle > > to express this information and there is some good work in Network > > tokens, FAST, and APN around this. > > RFC7872 seems to suggest otherwise. > I disagree. RFC7872 was one snapshot in time and is now coming up on five years since it was published; since then RFC8200 was published with relaxed requirements for intermediate nodes and there is a lot more active work on extension headers. Besides that, we don't need or expect 100% of the Internet to support EH, we can use it opportunistically when we know the path works (e.g. the destination is a server within the user's provider network that supports the features). Tom > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Fri Feb 12 18:21:11 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4A3A1255; Fri, 12 Feb 2021 18:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQgsyGHvxdnr; Fri, 12 Feb 2021 18:21:06 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524D83A1220; Fri, 12 Feb 2021 18:21:03 -0800 (PST) Received: from [IPv6:2800:810:464:2b9:4181:442:5061:d73f] (unknown [IPv6:2800:810:464:2b9:4181:442:5061:d73f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CD2982808A6; Sat, 13 Feb 2021 02:20:59 +0000 (UTC) To: Tom Herbert Cc: Fernando Gont , Michael Richardson , "tsvwg@ietf.org" , "saag@ietf.org" References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> <16740.1613082711@localhost> <0856c5b2-57a7-cb6f-e74b-c2d1af568c28@si6networks.com> From: Fernando Gont Message-ID: <8556e4ca-39a3-7e65-d60c-0ada1412fe46@si6networks.com> Date: Fri, 12 Feb 2021 23:07:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [tsvwg] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 02:21:09 -0000 On 12/2/21 22:53, Tom Herbert wrote: [....] >>> IMO, HBH is the best vehicle >>> to express this information and there is some good work in Network >>> tokens, FAST, and APN around this. >> >> RFC7872 seems to suggest otherwise. >> > I disagree. RFC7872 was one snapshot in time and is now coming up on > five years since it was published; since then RFC8200 was published > with relaxed requirements for intermediate nodes and there is a lot > more active work on extension headers. There's a lot of active work on EHs, yes. You can use them in limited domains. But you'll likely have a bitter experience otherwise. (To share you my own: I recently replaced my IPv4-transport tunnels with IPv6-transport tunnels... but but some failed. Why? Because, Linux employs (by default) a tunnel encapsulation limit option, which requires a DO header to be inserted. And such packets often get dropped) You may get the same when trying to use ESP, too. RFC8200 changed the processing of HBH. But there are general implications of EHs (in general) -- RFC8200 has changed nothing about that (and in fact, it couldn't have). > Besides that, we don't need or > expect 100% of the Internet to support EH, we can use it > opportunistically when we know the path works (e.g. the destination is > a server within the user's provider network that supports the > features). That's indeed a different scenario (a so-called "limited domain") -- i.e. your network, your rules. But I believe the discussion here is about the implications on an Internet-wide scope. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Feb 22 13:29:33 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4A3A2068 for ; Mon, 22 Feb 2021 13:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GOnMtfZu3dZd for ; Mon, 22 Feb 2021 13:29:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37E13A1193 for ; Mon, 22 Feb 2021 13:29:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AF6C038A75; Mon, 22 Feb 2021 16:33:32 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HcH7hJaKC1IV; Mon, 22 Feb 2021 16:33:32 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 321DE38A74; Mon, 22 Feb 2021 16:33:32 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8E37A5B2; Mon, 22 Feb 2021 16:29:27 -0500 (EST) From: Michael Richardson To: saag@ietf.org cc: "Jonathan Hoyland" In-Reply-To: <161402913142.668.8084091230406313422@ietfa.amsl.com> References: <161402913142.668.8084091230406313422@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] New Version Notification for draft-richardson-saag-onpath-attacker-02.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 21:29:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable internet-drafts@ietf.org wrote: > A new version of I-D, draft-richardson-saag-onpath-attacker-02.txt has > been successfully submitted by Michael Richardson and posted to the > IETF repository. 1) Jonathan Hoyland has agreed to co-author. 2) He did a bunch of clean up of my typos. After some thought, I prefer Mallory-in-the-Middle, and I think that we can make "Mallory-in-the-Rough" work, even for those who kn= ow nothing about golf. A goof I just noticed is that it claims "Standards Track", but of course, it has to be Informational! Name: draft-richardson-saag-onpath-attacker Revision: 02 Title: A taxonomy of eavesdropping attacks Document date: 2021-02-22 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-richardson-saag-onpat= h-attacker-02.txt Status: https://datatracker.ietf.org/doc/draft-richardson-saag-onpa= th-attacker/ Html: https://www.ietf.org/archive/id/draft-richardson-saag-onpat= h-attacker-02.html Htmlized: https://tools.ietf.org/html/draft-richardson-saag-onpath-at= tacker-02 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-saag-o= npath-attacker-02 Abstract: The terms on-path attacker and Man-in-the-Middle Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. This document offers an update on terminology for network attacks. A consistent set of terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmA0IjcACgkQgItw+93Q 3WWJmAf+Ouxbd9G781wyoqc2paQhVV6QoQRoo0P1HQ6RofPv9KTUWzJyHwgPT1Z0 F3/P2MJnhu3DzgWNFnD23xqVuwRqG666BD9+rRGsh+0vcARBJQDv76xk3jENoBEe vlSo1hyufTwEC0Bp02+4hBxUYBqQAO0EDIwPGmW8J5D36Z6qDzp3D9fLppI2yuU8 eiQ/6apqdPdzbYaM+1Ym61EytwhFgVf1YuSfu476Q4sHdDWK40jBw51MI+wM5N3Y dzniWAam0CFrzXKvKSL2t7X6dQNkT5yQlyJ4NuT8pXAHvcFgyyplXJbUMYqKCkzb m8pimbzQY48hNQExTZo+DP7xHWdJhQ== =vSXd -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 24 15:55:02 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DBE3A114B; Wed, 24 Feb 2021 15:54:55 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4qhiNmFccng; Wed, 24 Feb 2021 15:54:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3603F3A0FD0; Wed, 24 Feb 2021 15:54:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8079538A0C; Wed, 24 Feb 2021 18:59:04 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G-5j2W_1rRqX; Wed, 24 Feb 2021 18:59:03 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA5A5389EF; Wed, 24 Feb 2021 18:59:03 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3F2AC9A8; Wed, 24 Feb 2021 18:54:51 -0500 (EST) To: saag@ietf.org, spasm@ietf.org References: <30833.1612411843@localhost> From: Michael Richardson Message-ID: Date: Wed, 24 Feb 2021 18:54:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <30833.1612411843@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] subordinate vs intermediate certification authority X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 23:54:56 -0000 Thank you folks for the discussion. On 2021-02-03 11:10 p.m., Michael Richardson wrote: > > I thought I had cross-posted this, but apparently I did not: > https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/ > > FC5280 uses the term "intermediate certificates", and they are presumably > issues by "intermediate" certification authorities. > > That term does not appear, although: > "intermediate CA certificates" > occurs. > > RFC4949 defines "intermediate CA" > However, the usage in RFC4949 seems entirely related to cross-certification, > rather than a PKI that has multiple layers of certification authority! Based upon the discussion on the list, the NIST references, and a look at the US GOV Federal https://fpki.idmanagement.gov/tools/fpkigraph/ It seems that actually the Intermediate CA has extensive use related to cross-certification. To the extent that the term has been used in our documents, it is usually associated with path validation, and this is usually important when bridge CAs are involved. I will use the term subordinate CA when speaking about a multi-level PKI. If I had the opportunity to update RFC4949 and RFC5280, it would be to add subordinate/superior CA to the document, with references to the NIST documents. From nobody Sun Feb 28 15:08:43 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50593A0CE8 for ; Sun, 28 Feb 2021 15:08:41 -0800 (PST) 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 hJOPaDp1uojm for ; Sun, 28 Feb 2021 15:08:40 -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 60B243A0CE5 for ; Sun, 28 Feb 2021 15:08:40 -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 11SN8X8H024262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 28 Feb 2021 18:08:38 -0500 Date: Sun, 28 Feb 2021 15:08:33 -0800 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20210228230833.GF21@kduck.mit.edu> References: <161418118269.26748.8995127112399706832@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <161418118269.26748.8995127112399706832@ietfa.amsl.com> Archived-At: Subject: [saag] Fwd: Last Call: (YANG Schema Item iDentifier (YANG SID)) to Proposed Standard X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2021 23:08:42 -0000 Hi all, This appears (on qiuick skim) to be a proposal to create a registry and assign globally unique uint64 values to items in (unrelated) YANG modules. In a sense this would be a new global naming system and as such might have some unexpected properties. Please send comments to last-call@ as usual, if you take a look. -Ben On Wed, Feb 24, 2021 at 07:39:42AM -0800, The IESG wrote: > > The IESG has received a request from the Constrained RESTful Environments WG > (core) to consider the following document: - 'YANG Schema Item iDentifier > (YANG SID)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-03-17. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit > unsigned integers used to identify YANG items. This document defines > the semantics, the registration, and assignment processes of YANG > SIDs. To enable the implementation of these processes, this document > also defines a file format used to persist and publish assigned YANG > SIDs. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-core-sid/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce