From nobody Sun Jun 2 13:40:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716ED1200F1 for ; Sun, 2 Jun 2019 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 ZZIp5hkPeKI9 for ; Sun, 2 Jun 2019 13:39:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450EB120047 for ; Sun, 2 Jun 2019 13:39:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A8BC33808A for ; Sun, 2 Jun 2019 16:38:43 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A822560 for ; Sun, 2 Jun 2019 16:39:53 -0400 (EDT) To: anima@ietf.org References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> From: Michael Richardson Message-ID: <534d165e-536e-cc6d-f897-cb6f96a875fc@sandelman.ca> Date: Sun, 2 Jun 2019 16:39:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 20:40:00 -0000 On 2019-05-29 11:06 a.m., Fries, Steffen wrote: > Hi, > > As this is the last call, it may not be to late to ask the question. I read the draft a couple of times and was stumbling upon the following: > > In Figure 1 of the BRSKI draft, for the communication between the Domain Registrar (RA) and the Key Infrastructure (CA), EST is stated. >>From my understanding of the description EST as enrollment protocol between an RA and the CA is meant exemplary but not prescriptive? From the protocol flow for the enrollment itself I understood BRSKI describes the flow until the Domain Registrar but is open regarding the protocol applied between the domain registrar and the CA. It may be EST. Yes, it may. I don't think, other than the figure, we say anything else. Would an "e.g." in the figure help? From nobody Sun Jun 2 13:47:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0B11200F9 for ; Sun, 2 Jun 2019 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 4yFpIyJdEGvB for ; Sun, 2 Jun 2019 13:47:13 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DA412008C for ; Sun, 2 Jun 2019 13:47:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17E693808A for ; Sun, 2 Jun 2019 16:46:00 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0E731560 for ; Sun, 2 Jun 2019 16:47:10 -0400 (EDT) To: anima@ietf.org References: <31898.1558925443@localhost> <00ce01d5143f$db431740$91c945c0$@augustcellars.com> From: Michael Richardson Message-ID: <13ef9ed1-b3c4-006d-8634-4b912cc81470@sandelman.ca> Date: Sun, 2 Jun 2019 16:47:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <00ce01d5143f$db431740$91c945c0$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Pinning of raw public keys in Constrained Vouchers X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 20:47:15 -0000 On 2019-05-26 11:54 p.m., Jim Schaad wrote: >> Couldn't we send a hash of identity in (2) and (3), and to do this we need >> a >> new element in the constrained voucher. This I've given the mouthful name >> of: proximity-registrar-sha256-of-subject-public-key-info >> and: pinned-sha256-of-subject-public-key-info >> (knowing that the YANG->SID process will turn this into a small integer). > Fixing on a single hash function would probably be frowned upon by the IESG. > The lack of algorithm flexibility would be an issue. I've been thinking about this a bit. Algorithm flexibility involves two things: 1) ability to encode other algorithms. This is easy, write some new YANG. That involves more than a simple IANA action, but is equivalent to a more complex action, i.e. "Specification Required". Ultimately, it involves allocating a SID, which could be a rather simple IANA action. 2) deciding how/when to use the new algorithm. The voucher-request travels from the pledge to the MASA, with the Registrar examining, (auditing, encapsulating, signing), but not needing to understand everything. So a new algorithm goes by without a lot of trouble. The pledge creates the hash from the AKE. The voucher travels from MASA to the pledge, and the Registrar again just observes. The pledge can be programmed to use whatever algorithms the MASA supported at the time the pledge is manufactured. So I feel satisfied that we can be agile. The manufacturer simply writes new software and installs it. Except for allocating a SID, it can be done unilaterally. From nobody Sun Jun 2 23:34:45 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE79120130 for ; Sun, 2 Jun 2019 23:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 H87dqr-booFu for ; Sun, 2 Jun 2019 23:34:40 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 7ECB712012C for ; Sun, 2 Jun 2019 23:34:40 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x536YcFC017208 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 3 Jun 2019 08:34:38 +0200 Received: from DEFTHW99ERKMSX.ww902.siemens.net (defthw99erkmsx.ww902.siemens.net [139.22.70.147]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x536YaA6002172 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 3 Jun 2019 08:34:36 +0200 Received: from DEFTHW99ER6MSX.ww902.siemens.net (139.22.70.65) by DEFTHW99ERKMSX.ww902.siemens.net (139.22.70.147) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 3 Jun 2019 08:34:35 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ER6MSX.ww902.siemens.net ([139.22.70.65]) with mapi id 14.03.0435.000; Mon, 3 Jun 2019 08:34:35 +0200 From: "Fries, Steffen" To: "anima@ietf.org" Thread-Topic: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard Thread-Index: AQHVEBsnSObOmAdIkUSiNyOqoj43mqaCPatwgAaHQYCAAMefwA== Date: Mon, 3 Jun 2019 06:34:34 +0000 Message-ID: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <534d165e-536e-cc6d-f897-cb6f96a875fc@sandelman.ca> In-Reply-To: <534d165e-536e-cc6d-f897-cb6f96a875fc@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 06:34:43 -0000 Hi Michael, Yes, definitely. This would help. Thanks. Best regards Steffen > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Sonntag, 2. Juni 2019 22:40 > To: anima@ietf.org > Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures > (BRSKI)) to Proposed Standard >=20 > On 2019-05-29 11:06 a.m., Fries, Steffen wrote: > > Hi, > > > > As this is the last call, it may not be to late to ask the question. I = read the draft a couple of times and was stumbling upon the > following: > > > > In Figure 1 of the BRSKI draft, for the communication between the Domai= n Registrar (RA) and the Key Infrastructure (CA), EST is > stated. > >>From my understanding of the description EST as enrollment protocol bet= ween an RA and the CA is meant exemplary but not > prescriptive? From the protocol flow for the enrollment itself I understo= od BRSKI describes the flow until the Domain Registrar but is > open regarding the protocol applied between the domain registrar and the = CA. It may be EST. >=20 > Yes, it may. I don't think, other than the figure, we say anything else. > Would an "e.g." in the figure help? >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jun 3 11:20:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9A12011C for ; Mon, 3 Jun 2019 11:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 775RzHiDg0I8 for ; Mon, 3 Jun 2019 11:20:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F833120045 for ; Mon, 3 Jun 2019 11:20:35 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id C80EB3808A; Mon, 3 Jun 2019 14:19:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F382616A5; Mon, 3 Jun 2019 14:20:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F0FFFE69; Mon, 3 Jun 2019 14:20:33 -0400 (EDT) From: Michael Richardson To: "Fries\, Steffen" cc: "anima\@ietf.org" In-Reply-To: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <534d165e-536e-cc6d-f897-cb6f96a875fc@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 18:20:38 -0000 --=-=-= Content-Type: text/plain Fries, Steffen wrote: > Yes, definitely. This would help. Thanks. https://github.com/anima-wg/anima-bootstrap/blob/master/component-diagram.txt edited, will be in -21. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz1ZPEACgkQgItw+93Q 3WV6LAf/ShcYA0fVAU/UUrSmQES+Os4erldQiNiDVmo/olw88qx2D49MDHgTt28e nYdfv9YD/UFzQZehiLJF7I0wxqIPaTagWaBn5ho6Q49R2XYNQ7CeEQAoQ+B8xdf9 6aAIvsMLofkhYzf2kneYpf+qrPELsunP1pQ3K4eKqwXejDsUKXGCDMJpbUAoAB/r isCYJDnU1pR08KkEi2F+mPPAjs9orYWqEZ0IEZEcolmFC5IeFC4m66bHibOkafqC 5uWsKqWKp9AupxXF2B3RpyKLYJHzRGEscbRmZMAQITZwOg7sm+P/Ce1qoEpg9sSe 2A9lNq/8oEdvqzezehVqx4XP6+cdNA== =s3aG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 3 18:26:40 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EA7120086; Mon, 3 Jun 2019 18:26:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155961159866.24403.1727847275384145521.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2019 18:26:38 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 105 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 01:26:39 -0000 A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll homenet netconf detnet Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: The WG prefers to have meetings on Monday/Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Tue Jun 4 00:09:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DF81200A4 for ; Tue, 4 Jun 2019 00:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_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 8yW8DFxWhp4I for ; Tue, 4 Jun 2019 00:09:13 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 89A4612006D for ; Tue, 4 Jun 2019 00:09:13 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x5479BMd013331 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Jun 2019 09:09:11 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x5479AVj000802 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Jun 2019 09:09:10 +0200 Received: from DEFTHW99ER1MSX.ww902.siemens.net (139.22.70.71) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.435.0; Tue, 4 Jun 2019 09:09:10 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ER1MSX.ww902.siemens.net ([139.22.70.71]) with mapi id 14.03.0435.000; Tue, 4 Jun 2019 09:09:10 +0200 From: "Fries, Steffen" To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard Thread-Index: AQHVEBsnSObOmAdIkUSiNyOqoj43mqaCPatwgAaHQYCAAMefwIAAo8eAgAD4FiA= Date: Tue, 4 Jun 2019 07:09:09 +0000 Message-ID: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <534d165e-536e-cc6d-f897-cb6f96a875fc@sandelman.ca> <11096.1559586033@localhost> In-Reply-To: <11096.1559586033@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 07:09:16 -0000 Hi Michael, Cristal clear. Thank you for the prompt response. Best regards Steffen > -----Original Message----- > From: Michael Richardson > Fries, Steffen wrote: > > Yes, definitely. This would help. Thanks. >=20 > https://github.com/anima-wg/anima-bootstrap/blob/master/component-diagram= .txt >=20 > edited, will be in -21. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Tue Jun 4 08:09:49 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEC312007C for ; Tue, 4 Jun 2019 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 IhDKK9I64JQt for ; Tue, 4 Jun 2019 08:09:45 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4700E120025 for ; Tue, 4 Jun 2019 08:09:44 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id DD5A138184 for ; Tue, 4 Jun 2019 11:08:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 404AD1056; Tue, 4 Jun 2019 11:09:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3DD6FDC9 for ; Tue, 4 Jun 2019 11:09:43 -0400 (EDT) From: Michael Richardson To: anima@ietf.org Reply-to: anima@ietf.org In-Reply-To: References: <8432c42a-6c4d-6597-accf-4ba13a4bc821@lounge.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] teap-brski X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 15:09:48 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain In a private thread on teap-BRSKI, it was asked how the BRSKI Registrar ("server", aka "authentication server" in 1X terminology) validates the provisional TLS connection with the pledge (aka "supplicant"). While there are a number of possible operational modes for BRSKI, but in all of them, the authentication of the pledge IDevID comes back to RFC7030, https://tools.ietf.org/html/rfc7030#section-3.3.2 The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. i.e. the Registrar has a list of trust anchors for the manufacturers that it expects to have join. This clearly is a difficulty for most residential applications and an operational headache for industrial uses. So the question then becomes, how does the Explicit TA database get easily extended? My suggestion, and this is entirely an implementation detail, is that a Registrar accept, but fail, connections from devices with unknown manufacturers, and then ask a human. I've never liked the "TOFU" term, because many use it to mean "SSH-client" like, and but SSH clients do not trust on first use. They ask human on first use, and then pin (AHFUTP is way less pronounceable than TOFU). And it's AHFUTP is what we want. A registrar could go further, contacting the MASA and attempting to obtain a voucher. A registrar could assign some higher value to a MASA that can be validating via public WebPKI when asking a human. There is an extension point here that we could consider: a Registrar could ask the MASA for a list of trust anchors used to sign IDevID. This could be the /.well-known/est/cacerts end point; it's certainly correct from the MASA point of view, but maybe it's an abuse. I don't feel strongly either way. This would validate the Manufacturer's IDevID CA using the TLS connection validated by the WebPKI. Many would find this acceptable, but perhaps some would not. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz2ibYACgkQgItw+93Q 3WWPRQf+Ovs45r8KW5XX9h3Vy0fCf6+sro83+6Iw/NIxO3vrr5udaAWCxygYi1xK l4cmUg3hNZ0med50L9UbQz0ED7Y8IKBAgrHbnVM54Fbk+fmujOM63nA53INu8qof tzocgPKXA4EuK5BGhOEoE1p/usdLcZApooO4dp4IbKrIVZxx6pUXET2DLWSvr5uI b7C6Sok9AnMdSTovNXTbT8/3o+3OQMNgJwk6r5M9pnyxZNCAoxL5JSIgW5IqssKX 3rElRuazkZSJ/nq0FMFu47Yzu9WZYMwCVOs+y8Lnvsc7G9/faG8+ejf8ZdTjQTDb y04C8eezRTv82MCYIssocgLSM1dGhQ== =amDA -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Jun 4 09:33:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314D120077; Tue, 4 Jun 2019 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 ULHfc--_giub; Tue, 4 Jun 2019 09:33:05 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA27D12004A; Tue, 4 Jun 2019 09:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12092; q=dns/txt; s=iport; t=1559665985; x=1560875585; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=3YgtNhDW49qbfttOiDtBrtv/E40dH8yDtzHb5kVDtjs=; b=NJyb4ba9YJpDsCrvsLKTggVa8CQxjKr6JwOaFioVaBGB9JTHn6u0q6jS B3XFG2+IPeqRKSpzCnGoA39TWEuJ+4wdUU9YVi0aCNZ7ZknPPA4QQNyRW aiNBddYL8oFUax1QXpg8V6Is536MluUvnPtY6VR+2Pu+4Nmb6PzUFP9cL E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAAB/nPZc/xbLJq1dCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgWWBD1OBGVIgEiiEFIh7jBqSXYd7AgcBAQEJAwEBGAEMCgEBhEA?= =?us-ascii?q?CgnU4EwEDAQEEAQECAQRtHAyFSgEBAQECAQEBIUsLBQsLGCMHAgInHxEGE4M?= =?us-ascii?q?iAYF7Dw+nNIExhDIBE0FAhF0QgTSBUIohgX+BEScfgkw+gmEBAQMBgTMDgzE?= =?us-ascii?q?ygiYEi2eHPFSVDgmCEIIZgQaDIox1G4IjaIYNg1uKBJQYjBCDBgIEBgUCFYF?= =?us-ascii?q?mIYFYMxoIGxU7KgGCDQEzCTWCCIM5hRSFQT0DMI8AAiQHgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.60,550,1549929600"; d="asc'?scan'208,217";a="12733105" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jun 2019 16:33:02 +0000 Received: from [10.61.227.242] ([10.61.227.242]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x54GX1ft015713 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 16:33:02 GMT From: Eliot Lear Message-Id: <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D5690984-1C98-477D-B494-B3CE0ABC264A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 4 Jun 2019 18:33:00 +0200 In-Reply-To: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> Cc: ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima@ietf.org, anima-chairs@ietf.org, tte+ietf@cs.fau.de To: IETF discussion list References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.227.242, [10.61.227.242] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 16:33:08 -0000 --Apple-Mail=_D5690984-1C98-477D-B494-B3CE0ABC264A Content-Type: multipart/alternative; boundary="Apple-Mail=_369453F2-69E1-4B49-9301-01DFDF74586B" --Apple-Mail=_369453F2-69E1-4B49-9301-01DFDF74586B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just on this text: In Section 10.3 the following text exists: o A Trust-On-First-Use (TOFU) mechanism. A human would be queried upon seeing a manufacturer's trust anchor for the first time, and then the trust anchor would be installed to the trusted store. There are risks with this; even if the key to name is validated using something like the WebPKI, there remains the possibility that the name is a look alike: e.g, c1sco.com, .. First, this isn=E2=80=99t REALLY Trust-On-First-Use, and I would prefer = that the term be replaced with something like "out-of-band approval". = This would also be a good area for certification services to step in to = indicate the trustworthiness of a manufacturer. Eliot > On 21 May 2019, at 23:21, The IESG wrote: >=20 >=20 > The IESG has received a request from the Autonomic Networking = Integrated > Model and Approach WG (anima) to consider the following document: - > 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' > as Proposed Standard >=20 > This is a second Last Call. IoT Directorate review was done after the = ANIMA > WG Last Call and consensus to request the publication, and that review = resulted > in substantial changes to the document. >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2019-06-04. 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. >=20 > Abstract >=20 >=20 > This document specifies automated bootstrapping of an Autonomic > Control Plane. To do this a remote secure key infrastructure = (BRSKI) > is created using manufacturer installed X.509 certificate, in > combination with a manufacturer's authorizing service, both online > and offline. Bootstrapping a new device can occur using a routable > address and a cloud service, or using only link-local connectivity, > or on limited/disconnected networks. Support for lower security > models, including devices with minimal identity, is described for > legacy reasons but not encouraged. Bootstrapping is complete when > the cryptographic identity of the new key infrastructure is > successfully deployed to the device but the established secure > connection can be used to deploy a locally issued certificate to the > device as well. >=20 >=20 >=20 >=20 > The file can be obtained via > = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ >=20 > IESG discussion can be tracked via > = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/b= allot/ >=20 > The following IPR Declarations may be related to this I-D: >=20 > https://datatracker.ietf.org/ipr/2816/ > https://datatracker.ietf.org/ipr/3233/ > https://datatracker.ietf.org/ipr/2463/ >=20 >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc8368: Using an Autonomic Control Plane for Stable Connectivity = of Network Operations, Administration, and Maintenance (OAM) = (Informational - IETF stream) >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_369453F2-69E1-4B49-9301-01DFDF74586B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = on this text:

In = Section 10.3 the following text exists:

   o  A = Trust-On-First-Use (TOFU) mechanism.  A human would be = queried
      upon seeing a manufacturer's trust = anchor for the first time, and
      then the trust = anchor would be installed to the trusted store.
  =     There are risks with this; even if the key to name is = validated
      using something like the WebPKI, there = remains the possibility
      that the name is a = look alike: e.g, c1sco.com, = ..

First, this = isn=E2=80=99t REALLY Trust-On-First-Use, and I would prefer that the = term be replaced with something like "out-of-band approval".  This = would also be a good area for certification services to step in to = indicate the trustworthiness of a manufacturer.

Eliot

On = 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:


The IESG has received a request from the Autonomic Networking = Integrated
Model and Approach WG (anima) to consider the = following document: -
'Bootstrapping Remote Secure Key = Infrastructures (BRSKI)'
=  <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed = Standard

This is a second Last Call. IoT = Directorate review was done after the ANIMA
WG Last Call = and consensus to request the publication, and that review resulted
in substantial changes to the document.  

The IESG plans to make a decision in the next = few weeks, and solicits final
comments on this action. = Please send substantive comments to the
ietf@ietf.org mailing lists = by 2019-06-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In = either case, please retain the beginning of
the Subject = line to allow automated sorting.

Abstract


  This document = specifies automated bootstrapping of an Autonomic
=   Control Plane.  To do this a remote secure key = infrastructure (BRSKI)
  is created using = manufacturer installed X.509 certificate, in
=   combination with a manufacturer's authorizing service, both = online
  and offline.  Bootstrapping a new = device can occur using a routable
  address and = a cloud service, or using only link-local connectivity,
=   or on limited/disconnected networks.  Support for lower = security
  models, including devices with = minimal identity, is described for
  legacy = reasons but not encouraged.  Bootstrapping is complete when
  the cryptographic identity of the new key = infrastructure is
  successfully deployed to = the device but the established secure
=   connection can be used to deploy a locally issued = certificate to the
  device as well.




The= file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/

IESG discussion can be = tracked via
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/ballot/

The following IPR = Declarations may be related to this I-D:

=   https://datatracker.ietf.org/ipr/2816/
=   https://datatracker.ietf.org/ipr/3233/
=   https://datatracker.ietf.org/ipr/2463/



The document contains these = normative downward references.
See RFC 3967 for additional = information:
   rfc8368: Using an = Autonomic Control Plane for Stable Connectivity of Network Operations, = Administration, and Maintenance (OAM) (Informational - IETF stream)



_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

= --Apple-Mail=_369453F2-69E1-4B49-9301-01DFDF74586B-- --Apple-Mail=_D5690984-1C98-477D-B494-B3CE0ABC264A 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPadPAAKCRBugA9nE248 uNP/AKDiGdhKSDYvwvWL8C+fWeN9GC4DjQCeI7g5BmD9pbc5ao1+msuxBLKS6KE= =xlsH -----END PGP SIGNATURE----- --Apple-Mail=_D5690984-1C98-477D-B494-B3CE0ABC264A-- From nobody Tue Jun 4 12:28:55 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE087120397; Tue, 4 Jun 2019 12:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OOyPuefPeeBw; Tue, 4 Jun 2019 12:28:52 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3CD1202E7; Tue, 4 Jun 2019 12:28:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DE4B354807D; Tue, 4 Jun 2019 21:28:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CBFCC440041; Tue, 4 Jun 2019 21:28:43 +0200 (CEST) Date: Tue, 4 Jun 2019 21:28:43 +0200 From: Toerless Eckert To: Eliot Lear Cc: IETF discussion list , ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, tte+ietf@cs.fau.de Message-ID: <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 19:28:54 -0000 Thanks, Eliot, re-reading 10.3, my impression is: a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2. The sentence stubs in 103 mentioning TOFU also don't seem to add value, the text doesn't become IMHO worse if they are simply removed. And i am sure there can easily be similar non-cyptographic leap of faiths in sales integration, or consortium memberships trust chaing establishment. b) The text could IMHO be crisper: "will have no problem collaborating with it's MASA" -> "will have no problem collaborating with it's malicious MASA" -> "the domain (registrar) still needs to trust the manufacturer" -> "the domain (registrar) still needs to authenticate the MASA" ? (i hope the latter is the correct interpretation of the text) Cheers Toerless On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: > Just on this text: > > In Section 10.3 the following text exists: > > o A Trust-On-First-Use (TOFU) mechanism. A human would be queried > upon seeing a manufacturer's trust anchor for the first time, and > then the trust anchor would be installed to the trusted store. > There are risks with this; even if the key to name is validated > using something like the WebPKI, there remains the possibility > that the name is a look alike: e.g, c1sco.com, .. > > First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval". This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer. > > Eliot > > > On 21 May 2019, at 23:21, The IESG wrote: > > > > > > The IESG has received a request from the Autonomic Networking Integrated > > Model and Approach WG (anima) to consider the following document: - > > 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' > > as Proposed Standard > > > > This is a second Last Call. IoT Directorate review was done after the ANIMA > > WG Last Call and consensus to request the publication, and that review resulted > > in substantial changes to the document. > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please retain the beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document specifies automated bootstrapping of an Autonomic > > Control Plane. To do this a remote secure key infrastructure (BRSKI) > > is created using manufacturer installed X.509 certificate, in > > combination with a manufacturer's authorizing service, both online > > and offline. Bootstrapping a new device can occur using a routable > > address and a cloud service, or using only link-local connectivity, > > or on limited/disconnected networks. Support for lower security > > models, including devices with minimal identity, is described for > > legacy reasons but not encouraged. Bootstrapping is complete when > > the cryptographic identity of the new key infrastructure is > > successfully deployed to the device but the established secure > > connection can be used to deploy a locally issued certificate to the > > device as well. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ > > > > The following IPR Declarations may be related to this I-D: > > > > https://datatracker.ietf.org/ipr/2816/ > > https://datatracker.ietf.org/ipr/3233/ > > https://datatracker.ietf.org/ipr/2463/ > > > > > > > > The document contains these normative downward references. > > See RFC 3967 for additional information: > > rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream) > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Tue Jun 4 19:09:48 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3726D120086; Tue, 4 Jun 2019 19:09:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155970058617.28046.13456954371938127846.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2019 19:09:46 -0700 Archived-At: Subject: [Anima] anima - Update to a Meeting Session Request for IETF 105 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 02:09:46 -0000 An update to a meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man ace Second Priority: roll homenet netconf detnet Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: The WG prefers to have meetings on Monday/Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Tue Jun 4 21:03:03 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 709AE1205D9; Tue, 4 Jun 2019 21:02:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <155970737536.28026.7190851289288084775@ietfa.amsl.com> Date: Tue, 04 Jun 2019 21:02:55 -0700 Archived-At: Subject: [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-20 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 04:02:56 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document is now "ready with nits". In my previous review of draft-ietf-anima-bootstrapping-keyinfra-16, I raised a number of concerns. The new version draft-ietf-anima-bootstrapping-keyinfra-20 addresses these concerns in two main ways: an applicability statement that restricts usage of the protocol to the "Autonomous Networking" scenario, and an improved security section. My main request is that the applicability discussion does not present the trade-off between between ease of bootstrap and increased manufacturer control. This should be easy to fix. The new version introduces applicability restriction in the Introduction, stating that the draft "provides for the needs of the ISP and Enterprise focused ANIMA Autonomic Control Plane (ACP)" and that other scenarios will require separate applicability statements. This is developed in section 8, "Applicability to the Autonomic Control Plane". This is a welcome change. It addresses some of the concerns raised in the previous review, such as use of BRSKI in consumer IOT scenarios. The previous review also raised a series of concerns related to the balance of power between manufacturer and owner of the device. These concerns are discussed in section 9, Privacy Considerations. The text in sections 9.2 points out that leakage of information is limited to the one-time bootstrap of the device. Section 9.3 addresses concerns expressed during the review about resale of devices, and points out that any mechanism intended to prevent theft will also prevent resale. That's true, but the mechanism designed to enable legitimate sales is only vaguely sketched: "the initial owner could inform the manufacturer of the sale, or the manufacturer may just permit resales unless told otherwise." Could and may, but there is no protocol element describing either option. Similarly, the section addresses manufacturer decisions to "end of life" a device by essentially stating that such devices will only be usable if they are never reset to factory default. Section 9.4 goes on explaining how the protocol can be used to thwart grey-market sales and resales, and simply state that it is legitimate for manufacturers to do that. As a whole, these three subsections of section 9 read very much like a justification of the original design. They could be summarized by stating that involving the manufacturer in the one-time bootstrapping provides new device owners with an automated and secure way to bootstrap devices, at the cost of increased manufacturer control on the devices' lifetime and resale. That trade-off may not be acceptable by every potental owner. Section 9.5 describes an interesting mitigation. It explains that manufacturer controls could be bypassed by replacing the certificate built in the device, and pointing it to a new MASA. That's obviously true, but I don't believe that the mechanisms for doing that are stated in the draft. In the absence of that mechanism, I would suggest to present the tradeoff between ease of bootstrap and increased manufacturer control in the introduction, perhaps in the same paragraph that states the domain of applicability of the draft. The security section covers several of the issues pointed out in the previous review. Section 10.1 explains how MASA availability issues (e.g. DoS attacks) are mitigated (10.1) by availability of nonceless vouchers. Section 10.2 explains how attacks by fake registrars could be detected by examining audit logs from the MASA. Section 10.3 discusses attacks by misbehaving MASA, and effectively conclude that they are not worse than if the device was bootstrapped without MASA. Continuous availability of MASA private key is discussed in 10.4. My previous review asked whether devices were expected to issue random numbers, and whether they should be equipped with appropriate random number generators. The protocol itself does not rely on random numbers generated by the device -- it only requires that the device be capable of generating a nonce. On the other hand, the protocol relies on HTTPS and thus TLS, which itself does require devices capable of generating cryptographically secure random numbers. The concern there is that BRSKI is engaged after the device is "reset to factory condition". This is probably easily mitigated, but might require a mention somewhere. A small nit about section 2.3 example:Text of first example says "The assertion leaf is indicated as 'proximity'", but there is no "assertion" leaf in the example voucher. Is this leftover from previous draft version? I also noticed a number of typos, especially in the added text. Running a spell check would help. From nobody Wed Jun 5 04:09:18 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA61F120113; Wed, 5 Jun 2019 04:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 bDqRhirjfRu7; Wed, 5 Jun 2019 04:09:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF6612008A; Wed, 5 Jun 2019 04:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5676; q=dns/txt; s=iport; t=1559732954; x=1560942554; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=U1nKX5EhQyDDeYNPIVehe3biMoSMyJdooWUAfIvjTYw=; b=NvstyiT8a7Z4bHK0E/uOam10KT7Ebp8JBJJoPBenYHw6ym08xaFv2MnD 9ZbCV4f2Un/w4G70Ph5BoKoz0BhbffvWz3oUPQcdNcNDVpX/JrQ3pDKSL sKNghJnBzO1VVYqfCbghYCHmQGRe+80/oH43NkmlJceLrG3jsM+Fbi8TE 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AADTofdc/xbLJq1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCe1IgEiiND4wamHKBZwIHAQEBCQMBARgNCgEBhEA?= =?us-ascii?q?Cgng4EwEDAQEEAQECAQRtHAyFSgEBAQECAQEBJUcLBQsLDgojCycwBhODIgG?= =?us-ascii?q?Bew8PpwUzhDIBE0FAhFcKBoE0gVCKIoF/gREnH4JMPoJhAQEDAYEzAw+DVII?= =?us-ascii?q?mBItrhz9UlRIJghCCGoEGgyKMeBuCI4Z3g1uKCpQgjBiDBgIEBgUCFYFmIYF?= =?us-ascii?q?YMxoIGxU7KgGCDQEzPoIIiE2FQT0DMI1NAiQHgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.60,550,1549929600"; d="asc'?scan'208";a="12823959" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jun 2019 11:09:11 +0000 Received: from [10.61.210.184] ([10.61.210.184]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x55B99Y7003477 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Jun 2019 11:09:10 GMT From: Eliot Lear Message-Id: <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D79B6626-762C-42D9-A038-6570953CD9A6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 13:09:09 +0200 In-Reply-To: <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> Cc: IETF discussion list , ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, anima@ietf.org, tte+ietf@cs.fau.de To: Toerless Eckert References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.210.184, [10.61.210.184] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 11:09:17 -0000 --Apple-Mail=_D79B6626-762C-42D9-A038-6570953CD9A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Toerless, > On 4 Jun 2019, at 21:28, Toerless Eckert wrote: >=20 > Thanks, Eliot, >=20 > re-reading 10.3, my impression is: >=20 > a) The use of TOFU in 10.3 seems to exceed the explanatory definition = in 1.2. > The sentence stubs in 103 mentioning TOFU also don't seem to add = value, the text > doesn't become IMHO worse if they are simply removed. And i am sure > there can easily be similar non-cyptographic leap of faiths in sales = integration, > or consortium memberships trust chaing establishment. My point is that those are no longer leaps of faith. Eliot >=20 > b) The text could IMHO be crisper: >=20 > "will have no problem collaborating with it's MASA" -> > "will have no problem collaborating with it's malicious MASA" -> >=20 > "the domain (registrar) still needs to trust the manufacturer" -> > "the domain (registrar) still needs to authenticate the MASA" ? > (i hope the latter is the correct interpretation of the text) >=20 > Cheers > Toerless >=20 > On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >> Just on this text: >>=20 >> In Section 10.3 the following text exists: >>=20 >> o A Trust-On-First-Use (TOFU) mechanism. A human would be queried >> upon seeing a manufacturer's trust anchor for the first time, = and >> then the trust anchor would be installed to the trusted store. >> There are risks with this; even if the key to name is validated >> using something like the WebPKI, there remains the possibility >> that the name is a look alike: e.g, c1sco.com, .. >>=20 >> First, this isn???t REALLY Trust-On-First-Use, and I would prefer = that the term be replaced with something like "out-of-band approval". = This would also be a good area for certification services to step in to = indicate the trustworthiness of a manufacturer. >>=20 >> Eliot >>=20 >>> On 21 May 2019, at 23:21, The IESG wrote: >>>=20 >>>=20 >>> The IESG has received a request from the Autonomic Networking = Integrated >>> Model and Approach WG (anima) to consider the following document: - >>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' >>> as Proposed = Standard >>>=20 >>> This is a second Last Call. IoT Directorate review was done after = the ANIMA >>> WG Last Call and consensus to request the publication, and that = review resulted >>> in substantial changes to the document. >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits final >>> comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2019-06-04. 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. >>>=20 >>> Abstract >>>=20 >>>=20 >>> This document specifies automated bootstrapping of an Autonomic >>> Control Plane. To do this a remote secure key infrastructure = (BRSKI) >>> is created using manufacturer installed X.509 certificate, in >>> combination with a manufacturer's authorizing service, both online >>> and offline. Bootstrapping a new device can occur using a routable >>> address and a cloud service, or using only link-local connectivity, >>> or on limited/disconnected networks. Support for lower security >>> models, including devices with minimal identity, is described for >>> legacy reasons but not encouraged. Bootstrapping is complete when >>> the cryptographic identity of the new key infrastructure is >>> successfully deployed to the device but the established secure >>> connection can be used to deploy a locally issued certificate to = the >>> device as well. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ >>>=20 >>> IESG discussion can be tracked via >>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/b= allot/ >>>=20 >>> The following IPR Declarations may be related to this I-D: >>>=20 >>> https://datatracker.ietf.org/ipr/2816/ >>> https://datatracker.ietf.org/ipr/3233/ >>> https://datatracker.ietf.org/ipr/2463/ >>>=20 >>>=20 >>>=20 >>> The document contains these normative downward references. >>> See RFC 3967 for additional information: >>> rfc8368: Using an Autonomic Control Plane for Stable Connectivity = of Network Operations, Administration, and Maintenance (OAM) = (Informational - IETF stream) >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > -- > --- > tte@cs.fau.de --Apple-Mail=_D79B6626-762C-42D9-A038-6570953CD9A6 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXPei1QAKCRBugA9nE248 uFpuAJwKU+DrTsHKue2JB664RYKLwGiRgQCg8LNnmw/7N//ZCUOfppnUR+YH4tk= =u2K/ -----END PGP SIGNATURE----- --Apple-Mail=_D79B6626-762C-42D9-A038-6570953CD9A6-- From nobody Thu Jun 6 07:13:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3874812004F; Thu, 6 Jun 2019 07:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 kFtSrxV0AKU3; Thu, 6 Jun 2019 07:13:13 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 9F5D112006D; Thu, 6 Jun 2019 07:13:13 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-146-89.san.res.rr.com [76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PSO004EEKU09W@wwwlocal.goatley.com>; Thu, 06 Jun 2019 09:13:12 -0500 (CDT) Received: from thinny.local ([65.222.135.102]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PSO00P2WKTG79@trixy.bergandi.net>; Thu, 06 Jun 2019 07:13:03 -0700 (PDT) Received: from unknown ([65.222.135.102] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 06 Jun 2019 07:13:03 -0700 Date: Thu, 06 Jun 2019 07:13:01 -0700 From: Dan Harkins To: anima@ietf.org, emu@ietf.org Message-id: <50c726dd-011d-9c52-6d79-caeb2ee0ef3b@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=65.222.135.102) X-PMAS-External-Auth: unknown [65.222.135.102] (EHLO thinny.local) X-PMAS-Software: PreciseMail V3.3 [190605] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [Anima] teap-brski X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 14:13:15 -0000   Hello,   In a private thread on teap-brski the topic of co-location of the TEAP server and the BRSKI registrar was brought up. It was suggested that the discussion move to these lists to get more input from the experts.   In draft-lear-eap-teap-brski-02 the architecture shows a the TEAP server and the BRSKI registrar as separate while mentioning that they can be co-located. The following assumes they are not co-located.   The BRSKI pledge in this draft is called a "device" and the device establishes a provisional TLS connection (through TEAP) to the TEAP server over 802.1X or something similar. The device does not connect to the registrar. The device then creates a voucher request and sends it to the TEAP server using a newly defined TEAP TLV. The registrar signs the request, forwards it onto a MASA, and sends the voucher it gets back from the MASA to the device using another newly defined TEAP TLV.   So the question is, will this even work? If the TEAP server and BRSKI registrar are separate entities then the voucher will include the TEAP server's EE certificate but it will be signed by the registrar's EE certificate. From my admittedly limited understanding of BRSKI I think the MASA will reject this voucher request because it fails the "proximity" check (if I understand the proximity check correctly). The MASA will treat the registrar as a man-in-the-middle.   BRSKI folks: is this correct? Will a voucher request be rejected from a deployment like this?   EMU folks: if the answer from the BRSKI folks is that this doesn't work then is there any sort of weird tunneling or "phase 2" trickery that can be added to TEAP to get this to work or should we just explicitly state that the TEAP server and the registrar are the same entity (they authenticate with the same certificate)?   Thanks,   Dan. From nobody Thu Jun 6 22:04:20 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5231200F6 for ; Thu, 6 Jun 2019 22:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90ZbL7S5MJTw for ; Thu, 6 Jun 2019 22:04:16 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 63D1812000F for ; Thu, 6 Jun 2019 22:04:16 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id u22so489555pfm.3 for ; Thu, 06 Jun 2019 22:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0GNqEY5ZkROV0dOU4uvo8KepFGGiXSQ01DVQqpjnBgg=; b=vGvI+/4e1xV/qQzx46jJAywhb562WX6hw5JbJxhGZCpCkirWerOLG8AWkfk/RWlHJg zdDU8D2ezat+nDWge4TzQksjcBqqKqxbvYRx1KCdKnVfWIHz5U9Euth2Hkw3FglmpwWP vWfaPm1QZP84tXrbNVz7+dmEI2YAWqK+2Ok9+JvIZ5f3u6eAa8wvV07olOeMHhrFqltR aBo4uylgT9njiSKKiB9h1XVCYQKJHxP7EsyexbIOIqeCiXADW3RvLJETH32TKw1l7jBP r18XpSeGazfCXu/QBSiBAgbyKOHZf0ReReswp5Mcv2lBz3T5msrRjUAY9VBO+EssKdkX RCMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0GNqEY5ZkROV0dOU4uvo8KepFGGiXSQ01DVQqpjnBgg=; b=AEYbLBSw2YevUgM3ymFFiE5OPPMJLNTnzC9oWBCKRvEg0vTETEYn8ofGVwr5wxUvNG 7s15ClbE1+xsodEjGiiwUSwxkHB751TgO3doHNSaM1njPdkgCt/GoqTrWrnCX1TuU4/4 JaK3TexGWKffuy0kdq9hYerNPNSPLhbjGi2W7iLajKxUla7kMQYn0RamIrdZrebWvh6s MG85Ieo7xIsw3DGCrvoQnnUfK+PaaYRNb82vEic61b83/MJWm3qKlQRaQPjEgLC3BZtG wrhZACvm7P8HcS9kTpsVbvV/aLpsyBtz01D/EcTnaBSPgkYy9EQMgBbUh/3JeNEjfF9R EHnA== X-Gm-Message-State: APjAAAWLS+ETQXEk64r5cue7egAIkxjv0wxV6QHOmMyi809JZe6H9oWC uSfy7piKvHe68U/hwUgiFxjSQj+/ X-Google-Smtp-Source: APXvYqxGWPe1IwsC2VK5SI+xaE5hBn8hb89JJg6AM44aRTa0KA+zkcOd1XCDPx2JOmbLJENY/tCqiQ== X-Received: by 2002:a62:e403:: with SMTP id r3mr26163418pfh.37.1559883855565; Thu, 06 Jun 2019 22:04:15 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id y6sm1119070pfo.38.2019.06.06.22.04.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jun 2019 22:04:14 -0700 (PDT) To: mohamed.boucadair@orange.com Cc: "Liubing (Leo)" , Anima WG References: <155538136830.10806.5525996910171440427@ietfa.amsl.com> <52c5425c-2e55-f95b-bca2-ccfba7ac03e8@gmail.com> <787AE7BB302AE849A7480A190F8B93302EA657EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Brian E Carpenter Message-ID: <65cf7c3a-3fe8-42c3-df74-1f1362a04f48@gmail.com> Date: Fri, 7 Jun 2019 17:04:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA657EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 05:04:19 -0000 Hi Med, Finally some feedback on your excellent comments. I only mention points where I have not accepted your point for the next version. > Controlled networks may not even be connected to the Internet. > I suggest to delete =E2=80=9Cof the Internet=E2=80=9D. That's true, but in a sense it's true of every IETF standard. If people want to use private protocols on a disconnected network, they are of course free to do so. However, I prefer to mention this aspect in the main Introduction, not in the Abstract. > Intent Based Networking... Commentaire [Med6]: Not sure why this > is mentioned. IBN is not specific to a service, and hence cannot be > limited to a single domain. I don't agree, not as I understand the discussion so far on intent. It isn't specific to a service, but it is specific to a human point of control such as a NOC. (Of course, intent could be nested inside a higher level intent, i.e. nested scopes.) > specific tunneling and encapsulation techniques may only be > usable within a given domain... Commentaire [Med7]: inter-AS VPNs > are also widely used. Sure, that's why it's "may". > a limited use requirement potentially adds complexity...=20 > Commentaire [Med9]: This depends on the design of the protocol > targeting a managed network. See for example, > https://tools.ietf.org/html/rfc6947#section-4.2.3 Agreed, that's why it's "potentially". > 6. Functional Requirements of Limited Domains... > Commentaire [Med12]: I would remove this part from the draft. The authors don't agree. This is not a specification, of course, but it's intended as a pointer to possible future work. > A basic assumption is that domains should be created and managed as > automatically as possible, with minimal human configuration required. > We therefore discuss requirements for automating domain creation and > management... > Commentaire [Med13]: This is depoyment-specific. Will reword slightly, but do we really want *new* manual management jobs?= > Clearly, the boundary of a limited domain will almost always also act > as a security boundary... > Commentaire [Med15]: If such nodes is allowed by the structure of the l= imited domain. > Some closed networks may not hosts such nodes. Yes, this is the argument I've had with the BRSKI people about running BRSKI with no access to the Internet. But that's why we say "almost alway= s". Thanks and regards. There will be a new version. Brian Carpenter On 25-Apr-19 21:31, mohamed.boucadair@orange.com wrote: > Hi Brian,=20 >=20 > FWIW, you may find some comments to this I-D at:=20 >=20 > * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/dra= ft-carpenter-limited-domains-07-rev%20Med.pdf=20 > * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draf= t-carpenter-limited-domains-07-rev%20Med.doc=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De=C2=A0: Anima [mailto:anima-bounces@ietf.org] De la part de Brian E = Carpenter >> Envoy=C3=A9=C2=A0: mardi 16 avril 2019 04:43 >> =C3=80=C2=A0: Anima WG >> Cc=C2=A0: Liubing (Leo) >> Objet=C2=A0: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-= 07.txt >> >> Hi, >> >> Another update following recent comments. The main changes were >> moving the taxonomy to an appendix, some new examples, and editorial >> improvements. Please send any new comments that you may have to >> int-area@ietf.org >> >> At the moment the authors plan to submit this draft soon to the >> Independent Submissions stream, but we'd be glad to hear any >> alternative suggestions. >> >> Regards >> Brian + Bing >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-carpenter-limited-domains-07.txt >> Date: Mon, 15 Apr 2019 19:22:48 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Limited Domains and Internet Protocols >> Authors : Brian Carpenter >> Bing Liu >> Filename : draft-carpenter-limited-domains-07.txt >> Pages : 25 >> Date : 2019-04-15 >> >> Abstract: >> There is a noticeable trend towards network requirements, behaviour= s >> and semantics that are specific to a limited region of the Internet= >> and a particular set of requirements. Policies, default parameters= , >> the options supported, the style of network management and security= >> requirements may vary. This document reviews examples of such >> limited domains, also known as controlled environments, and emergin= g >> solutions, and includes a related taxonomy. It then briefly >> discusses the standardization of protocols for limited domains. >> Finally, it shows the needs for a precise definition of limited >> domain membership and for mechanisms to allow nodes to join a domai= n >> securely and to find other members, including boundary nodes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-carpenter-limited-domains-07 >> https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-= 07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-carpenter-limited-domains-07= >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Fri Jun 7 00:19:15 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9B1201A0 for ; Fri, 7 Jun 2019 00:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Wwr0OAXdZlnZ for ; Fri, 7 Jun 2019 00:19:12 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B19312019B for ; Fri, 7 Jun 2019 00:19:12 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45Kv661sCvz5wm8; Fri, 7 Jun 2019 09:19:10 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 45Kv6615mdzDq7V; Fri, 7 Jun 2019 09:19:10 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([fe80::9108:27dc:3496:8db3%21]) with mapi id 14.03.0439.000; Fri, 7 Jun 2019 09:19:09 +0200 From: To: Brian E Carpenter CC: Anima WG , "Liubing (Leo)" Thread-Topic: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt Thread-Index: AQHVHO58qcQZ33R3oEKpXQxgp9p2RKaPv7ZA Date: Fri, 7 Jun 2019 07:19:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA32E6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155538136830.10806.5525996910171440427@ietfa.amsl.com> <52c5425c-2e55-f95b-bca2-ccfba7ac03e8@gmail.com> <787AE7BB302AE849A7480A190F8B93302EA657EB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <65cf7c3a-3fe8-42c3-df74-1f1362a04f48@gmail.com> In-Reply-To: <65cf7c3a-3fe8-42c3-df74-1f1362a04f48@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-07.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 07:19:14 -0000 SGkgQnJpYW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmb2xsb3ctdXAuIA0KDQpQbGVhc2Ugc2Vl IGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZcKgOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBh cnQgZGUgQnJpYW4gRSBDYXJwZW50ZXINCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSA3IGp1aW4gMjAx OSAwNzowNA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6IEFuaW1h IFdHOyBMaXViaW5nIChMZW8pDQo+IE9iamV0wqA6IFJlOiBbQW5pbWFdIEZ3ZDogSS1EIEFjdGlv bjogZHJhZnQtY2FycGVudGVyLWxpbWl0ZWQtZG9tYWlucy0NCj4gMDcudHh0DQo+IA0KPiBIaSBN ZWQsDQo+IA0KPiBGaW5hbGx5IHNvbWUgZmVlZGJhY2sgb24geW91ciBleGNlbGxlbnQgY29tbWVu dHMuIEkgb25seSBtZW50aW9uIHBvaW50cw0KPiB3aGVyZSBJIGhhdmUgbm90IGFjY2VwdGVkIHlv dXIgcG9pbnQgZm9yIHRoZSBuZXh0IHZlcnNpb24uDQo+IA0KPiA+IENvbnRyb2xsZWQgbmV0d29y a3MgbWF5IG5vdCBldmVuIGJlIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQuDQo+ID4gSSBzdWdn ZXN0IHRvIGRlbGV0ZSDigJxvZiB0aGUgSW50ZXJuZXTigJ0uDQo+IA0KPiBUaGF0J3MgdHJ1ZSwg YnV0IGluIGEgc2Vuc2UgaXQncyB0cnVlIG9mIGV2ZXJ5IElFVEYgc3RhbmRhcmQuIElmDQo+IHBl b3BsZSB3YW50IHRvIHVzZSBwcml2YXRlIHByb3RvY29scyBvbiBhIGRpc2Nvbm5lY3RlZCBuZXR3 b3JrLA0KPiB0aGV5IGFyZSBvZiBjb3Vyc2UgZnJlZSB0byBkbyBzby4NCg0KW01lZF0gTXkgaGlk ZGVuIGNvbW1lbnQgd2FzIHRoYXQgKiogaW50ZXJvcGVyYWJpbGl0eSAqKiBpcyBuZWVkZWQgZXZl biBmb3IgY2xvc2VkIG5ldHdvcmtzLiBXZSBjYW5ub3QgaW1wbHkgdGhhdCBzdWNoIG5ldHdvcmtz IHNob3VsZCB1c2UgcHJpdmF0ZSBwcm90b2NvbHMgYmVjYXVzZSB0aGV5IGFyZSBub3QgY29ubmVj dGVkIHRvIHRoZSBJbnRlcm5ldC4gDQoNCiBIb3dldmVyLCBJIHByZWZlciB0byBtZW50aW9uIHRo aXMNCj4gYXNwZWN0IGluIHRoZSBtYWluIEludHJvZHVjdGlvbiwgbm90IGluIHRoZSBBYnN0cmFj dC4NCg0KW01lZF0gT0ssIHRoYW5rcy4gSG9wZSB5b3Ugd2lsbCByZWZsZWN0IHRoZSBhYm92ZSBj b21tZW50IGFib3V0IGludGVyb3BlcmFiaWxpdHkuIA0KDQo+IA0KPiA+IEludGVudCBCYXNlZCBO ZXR3b3JraW5nLi4uIENvbW1lbnRhaXJlIFtNZWQ2XTogTm90IHN1cmUgd2h5IHRoaXMNCj4gPiBp cyBtZW50aW9uZWQuIElCTiBpcyBub3Qgc3BlY2lmaWMgdG8gYSBzZXJ2aWNlLCBhbmQgaGVuY2Ug Y2Fubm90IGJlDQo+ID4gbGltaXRlZCB0byBhIHNpbmdsZSBkb21haW4uDQo+IA0KPiBJIGRvbid0 IGFncmVlLCBub3QgYXMgSSB1bmRlcnN0YW5kIHRoZSBkaXNjdXNzaW9uIHNvIGZhciBvbiBpbnRl bnQuDQo+IEl0IGlzbid0IHNwZWNpZmljIHRvIGEgc2VydmljZSwgYnV0IGl0IGlzIHNwZWNpZmlj IHRvIGEgaHVtYW4gcG9pbnQNCj4gb2YgY29udHJvbCBzdWNoIGFzIGEgTk9DLiAoT2YgY291cnNl LCBpbnRlbnQgY291bGQgYmUgbmVzdGVkIGluc2lkZQ0KPiBhIGhpZ2hlciBsZXZlbCBpbnRlbnQs IGkuZS4gbmVzdGVkIHNjb3Blcy4pDQoNCltNZWRdIFRoZSBpc3N1ZSBJIGhhZCB3aXRoIHRoYXQg dGV4dCBpcyBpdCBhc3N1bWVzIHRoYXQgaW50ZW50IGFyZSBuZWNlc3NhcmlseSBmb3Igc2Vydmlj ZXMgd2l0aCBsaW1pdGVkIHNjb3Blcywgd2hpbGUgaXQgaXMgY29tcGxldGVseSBmaW5lIHRvIHVz ZSBpdCBmb3Igc2VydmljZXMgd2l0aCAqKiBnbG9iYWwgKiogcmVhY2hhYmlsaXR5LiANCg0KSU1I TywgSUJOIGlzIGEgZGltZW5zaW9uIHdoaWNoIGlzIG5vdCB0aWVkIHRvIGNsb3NlZCBuZXR3b3Jr cy4gICANCg0KPiANCj4gPiBzcGVjaWZpYyB0dW5uZWxpbmcgYW5kIGVuY2Fwc3VsYXRpb24gdGVj aG5pcXVlcyBtYXkgb25seSBiZQ0KPiA+IHVzYWJsZSB3aXRoaW4gYSBnaXZlbiBkb21haW4uLi4g Q29tbWVudGFpcmUgW01lZDddOiBpbnRlci1BUyBWUE5zDQo+ID4gYXJlIGFsc28gd2lkZWx5IHVz ZWQuDQo+IA0KPiBTdXJlLCB0aGF0J3Mgd2h5IGl0J3MgIm1heSIuDQoNCltNZWRdIFllcywgYnV0 IHRoZXJlIGlzIHRoYXQgIm9ubHkiIGluIHlvdXIgdGV4dCA6LSkNCg0KPiANCj4gPiBhIGxpbWl0 ZWQgdXNlIHJlcXVpcmVtZW50IHBvdGVudGlhbGx5IGFkZHMgY29tcGxleGl0eS4uLg0KPiA+IENv bW1lbnRhaXJlIFtNZWQ5XTogVGhpcyBkZXBlbmRzIG9uIHRoZSBkZXNpZ24gb2YgdGhlIHByb3Rv Y29sDQo+ID4gdGFyZ2V0aW5nIGEgbWFuYWdlZCBuZXR3b3JrLiBTZWUgZm9yIGV4YW1wbGUsDQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NDcjc2VjdGlvbi00LjIuMw0KPiAN Cj4gQWdyZWVkLCB0aGF0J3Mgd2h5IGl0J3MgInBvdGVudGlhbGx5Ii4NCj4gDQo+ID4gNi4gRnVu Y3Rpb25hbCBSZXF1aXJlbWVudHMgb2YgTGltaXRlZCBEb21haW5zLi4uDQo+ID4gQ29tbWVudGFp cmUgW01lZDEyXTogSSB3b3VsZCByZW1vdmUgdGhpcyBwYXJ0IGZyb20gdGhlIGRyYWZ0Lg0KPiAN Cj4gVGhlIGF1dGhvcnMgZG9uJ3QgYWdyZWUuIFRoaXMgaXMgbm90IGEgc3BlY2lmaWNhdGlvbiwg b2YgY291cnNlLA0KPiBidXQgaXQncyBpbnRlbmRlZCBhcyBhIHBvaW50ZXIgdG8gcG9zc2libGUg ZnV0dXJlIHdvcmsuDQoNCltNZWRdIFRoZSBjb25jZXJuIEkgaGFkIHdpdGggdGhhdCB0ZXh0IGl0 IGlzIGRyYXduIGZyb20gYSBwZXJzcGVjdGl2ZSB3aGljaCBtYXkgbm90IGFwcGx5IHRvIGV2ZXJ5 IGNvbnRyb2xsZWQvbGltaXRlZCBkb21haW4uIA0KDQpJJ20gd29ya2luZyBvbiB1c2UgY2FzZXMg Zm9yIHdoaWNoIHlvdXIgbGlzdCBpcyBncmVhdCwgZS5nLiwgQkdQIGF1dG9tYXRpb24gd2l0aGlu IG1hc3NpdmVseSBzY2FsZSBkYXRhIGNlbnRlcnMsIGJ1dCBpZiBJIHdvdWxkIGxpa2UgdG8gcnVu IGEgZmxlZXQgb2YgZHJvbmVzIGZvciBzb21lIHVzYWdlLCBJIGRvbid0IG5lY2Vzc2FyaWx5IG5l ZWQgYSAiZG9tYWluIGlkZW50aXR5IiBvciAicm9sZSB2ZXJpZmljYXRpb24iIGFzIGl0IHRoZSBi b290c3RyYXBwaW5nIG9mIHRoZSBkcm9uZXMgd2lsbCBiZSB3aXRoIGFuIGV4dGVybmFsIGNvbnRy b2wuIA0KDQo+IA0KPiA+IEEgYmFzaWMgYXNzdW1wdGlvbiBpcyB0aGF0IGRvbWFpbnMgc2hvdWxk IGJlIGNyZWF0ZWQgYW5kIG1hbmFnZWQgYXMNCj4gPiBhdXRvbWF0aWNhbGx5IGFzIHBvc3NpYmxl LCB3aXRoIG1pbmltYWwgaHVtYW4gY29uZmlndXJhdGlvbiByZXF1aXJlZC4NCj4gPiBXZSB0aGVy ZWZvcmUgZGlzY3VzcyByZXF1aXJlbWVudHMgZm9yIGF1dG9tYXRpbmcgZG9tYWluIGNyZWF0aW9u IGFuZA0KPiA+IG1hbmFnZW1lbnQuLi4NCj4gPiBDb21tZW50YWlyZSBbTWVkMTNdOiBUaGlzIGlz IGRlcG95bWVudC1zcGVjaWZpYy4NCj4gDQo+IFdpbGwgcmV3b3JkIHNsaWdodGx5LCBidXQgZG8g d2UgcmVhbGx5IHdhbnQgKm5ldyogbWFudWFsIG1hbmFnZW1lbnQgam9icz8NCg0KW01lZF0gSXQg ZGVwZW5kcyBvbiB0aGUgImxpbWl0ZWQgZG9tYWluIiBzY29wZSBhbmQgcHVycG9zZS4gTWFudWFs IG9wZXJhdGlvbnMgY2FuIGJlIHBlcmZlY3RseSBmaW5lIHZzLiB0aGUgaGVhdmluZXNzIG9mIHNl dHRpbmcgYW5kIGNvbmZpZ3VyaW5nIGNvbXBsZXggc2NoZW1lcy4NCg0KPiANCj4gPiBDbGVhcmx5 LCB0aGUgYm91bmRhcnkgb2YgYSBsaW1pdGVkIGRvbWFpbiB3aWxsIGFsbW9zdCBhbHdheXMgYWxz byBhY3QNCj4gPiBhcyBhIHNlY3VyaXR5IGJvdW5kYXJ5Li4uDQo+ID4gQ29tbWVudGFpcmUgW01l ZDE1XTogSWYgc3VjaCBub2RlcyBpcyBhbGxvd2VkIGJ5IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlDQo+ IGxpbWl0ZWQgZG9tYWluLg0KPiA+IFNvbWUgY2xvc2VkIG5ldHdvcmtzIG1heSBub3QgaG9zdHMg c3VjaCBub2Rlcy4NCj4gDQo+IFllcywgdGhpcyBpcyB0aGUgYXJndW1lbnQgSSd2ZSBoYWQgd2l0 aCB0aGUgQlJTS0kgcGVvcGxlIGFib3V0IHJ1bm5pbmcNCj4gQlJTS0kgd2l0aCBubyBhY2Nlc3Mg dG8gdGhlIEludGVybmV0LiBCdXQgdGhhdCdzIHdoeSB3ZSBzYXkgImFsbW9zdA0KPiBhbHdheXMi Lg0KPiANCg0KW01lZF0gWWVhaCwgYnV0IHRoZSB0ZXh0IGFzc3VtZXMgdGhhdCBzdWNoICJyb2xl IiBpcyBhbHdheXMgcHJlc2VudCBpbiBhIGxpbWl0ZWQgZG9tYWluLiBQbGVhc2UgY29uc2lkZXIg dHdlYWtpbmcgdGhlIHRleHQuIFRoYW5rcy4gDQoNCj4gVGhhbmtzIGFuZCByZWdhcmRzLiBUaGVy ZSB3aWxsIGJlIGEgbmV3IHZlcnNpb24uDQo+IA0KPiAgICBCcmlhbiBDYXJwZW50ZXINCj4gDQo+ IE9uIDI1LUFwci0xOSAyMTozMSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN Cj4gPiBIaSBCcmlhbiwNCj4gPg0KPiA+IEZXSVcsIHlvdSBtYXkgZmluZCBzb21lIGNvbW1lbnRz IHRvIHRoaXMgSS1EIGF0Og0KPiA+DQo+ID4gKiBwZGY6IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3Vj YWRhaXIvSUVURi1EcmFmdHMtDQo+IFJldmlld3MvYmxvYi9tYXN0ZXIvZHJhZnQtY2FycGVudGVy LWxpbWl0ZWQtZG9tYWlucy0wNy1yZXYlMjBNZWQucGRmDQo+ID4gKiBkb2M6IGh0dHBzOi8vZ2l0 aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMtDQo+IFJldmlld3MvcmF3L21hc3Rlci9kcmFm dC1jYXJwZW50ZXItbGltaXRlZC1kb21haW5zLTA3LXJldiUyME1lZC5kb2MNCj4gPg0KPiA+IENo ZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g Pj4gRGXCoDogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIEJyaWFuIEUNCj4gQ2FycGVudGVyDQo+ID4+IEVudm95w6nCoDogbWFyZGkgMTYgYXZyaWwg MjAxOSAwNDo0Mw0KPiA+PiDDgMKgOiBBbmltYSBXRw0KPiA+PiBDY8KgOiBMaXViaW5nIChMZW8p DQo+ID4+IE9iamV0wqA6IFtBbmltYV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1jYXJwZW50ZXIt bGltaXRlZC1kb21haW5zLTA3LnR4dA0KPiA+Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gQW5vdGhl ciB1cGRhdGUgZm9sbG93aW5nIHJlY2VudCBjb21tZW50cy4gVGhlIG1haW4gY2hhbmdlcyB3ZXJl DQo+ID4+IG1vdmluZyB0aGUgdGF4b25vbXkgdG8gYW4gYXBwZW5kaXgsIHNvbWUgbmV3IGV4YW1w bGVzLCBhbmQgZWRpdG9yaWFsDQo+ID4+IGltcHJvdmVtZW50cy4gUGxlYXNlIHNlbmQgYW55IG5l dyBjb21tZW50cyB0aGF0IHlvdSBtYXkgaGF2ZSB0bw0KPiA+PiBpbnQtYXJlYUBpZXRmLm9yZw0K PiA+Pg0KPiA+PiBBdCB0aGUgbW9tZW50IHRoZSBhdXRob3JzIHBsYW4gdG8gc3VibWl0IHRoaXMg ZHJhZnQgc29vbiB0byB0aGUNCj4gPj4gSW5kZXBlbmRlbnQgU3VibWlzc2lvbnMgc3RyZWFtLCBi dXQgd2UnZCBiZSBnbGFkIHRvIGhlYXIgYW55DQo+ID4+IGFsdGVybmF0aXZlIHN1Z2dlc3Rpb25z Lg0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ICAgIEJyaWFuICsgQmluZw0KPiA+Pg0KPiA+PiAt LS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KPiA+PiBTdWJqZWN0OiBJLUQgQWN0 aW9uOiBkcmFmdC1jYXJwZW50ZXItbGltaXRlZC1kb21haW5zLTA3LnR4dA0KPiA+PiBEYXRlOiBN b24sIDE1IEFwciAyMDE5IDE5OjIyOjQ4IC0wNzAwDQo+ID4+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPiA+PiBSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+ID4+ IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPj4NCj4gPj4NCj4gPj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ ID4+IGRpcmVjdG9yaWVzLg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IExpbWl0ZWQgRG9tYWlucyBhbmQgSW50ZXJuZXQgUHJvdG9jb2xzDQo+ID4+ICAgICAgICAg QXV0aG9ycyAgICAgICAgIDogQnJpYW4gQ2FycGVudGVyDQo+ID4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgQmluZyBMaXUNCj4gPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWNhcnBlbnRl ci1saW1pdGVkLWRvbWFpbnMtMDcudHh0DQo+ID4+IAlQYWdlcyAgICAgICAgICAgOiAyNQ0KPiA+ PiAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0wNC0xNQ0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4g Pj4gICAgVGhlcmUgaXMgYSBub3RpY2VhYmxlIHRyZW5kIHRvd2FyZHMgbmV0d29yayByZXF1aXJl bWVudHMsIGJlaGF2aW91cnMNCj4gPj4gICAgYW5kIHNlbWFudGljcyB0aGF0IGFyZSBzcGVjaWZp YyB0byBhIGxpbWl0ZWQgcmVnaW9uIG9mIHRoZSBJbnRlcm5ldA0KPiA+PiAgICBhbmQgYSBwYXJ0 aWN1bGFyIHNldCBvZiByZXF1aXJlbWVudHMuICBQb2xpY2llcywgZGVmYXVsdCBwYXJhbWV0ZXJz LA0KPiA+PiAgICB0aGUgb3B0aW9ucyBzdXBwb3J0ZWQsIHRoZSBzdHlsZSBvZiBuZXR3b3JrIG1h bmFnZW1lbnQgYW5kIHNlY3VyaXR5DQo+ID4+ICAgIHJlcXVpcmVtZW50cyBtYXkgdmFyeS4gIFRo aXMgZG9jdW1lbnQgcmV2aWV3cyBleGFtcGxlcyBvZiBzdWNoDQo+ID4+ICAgIGxpbWl0ZWQgZG9t YWlucywgYWxzbyBrbm93biBhcyBjb250cm9sbGVkIGVudmlyb25tZW50cywgYW5kIGVtZXJnaW5n DQo+ID4+ICAgIHNvbHV0aW9ucywgYW5kIGluY2x1ZGVzIGEgcmVsYXRlZCB0YXhvbm9teS4gIEl0 IHRoZW4gYnJpZWZseQ0KPiA+PiAgICBkaXNjdXNzZXMgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBw cm90b2NvbHMgZm9yIGxpbWl0ZWQgZG9tYWlucy4NCj4gPj4gICAgRmluYWxseSwgaXQgc2hvd3Mg dGhlIG5lZWRzIGZvciBhIHByZWNpc2UgZGVmaW5pdGlvbiBvZiBsaW1pdGVkDQo+ID4+ICAgIGRv bWFpbiBtZW1iZXJzaGlwIGFuZCBmb3IgbWVjaGFuaXNtcyB0byBhbGxvdyBub2RlcyB0byBqb2lu IGEgZG9tYWluDQo+ID4+ICAgIHNlY3VyZWx5IGFuZCB0byBmaW5kIG90aGVyIG1lbWJlcnMsIGlu Y2x1ZGluZyBib3VuZGFyeSBub2Rlcy4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhcnBlbnRlci1saW1pdGVkLWRvbWFpbnMvDQo+ID4+ DQo+ID4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4g Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhcnBlbnRlci1saW1pdGVkLWRv bWFpbnMtMDcNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1jYXJwZW50ZXItbGltaXRlZC1kb21haW5zLQ0KPiAwNw0KPiA+Pg0KPiA+PiBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jYXJwZW50ZXItbGltaXRlZC1kb21haW5zLTA3 DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gPj4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0K PiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+ID4+IEktRC1Bbm5vdW5jZUBpZXRm Lm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5v dW5jZQ0KPiA+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbA0KPiA+PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNp dGVzLnR4dA0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gPj4gQW5pbWFAaWV0Zi5vcmcN Cj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBB bmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Fri Jun 7 14:17:31 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191E120044; Fri, 7 Jun 2019 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0TKkHu3UTs4B; Fri, 7 Jun 2019 14:17:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0DE120141; Fri, 7 Jun 2019 14:17:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EC9CB54806D; Fri, 7 Jun 2019 23:17:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D9A23440041; Fri, 7 Jun 2019 23:17:20 +0200 (CEST) Date: Fri, 7 Jun 2019 23:17:20 +0200 From: Toerless Eckert To: Eliot Lear Cc: ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org Message-ID: <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 21:17:30 -0000 Ok, now i got you (i hope ;-). I really liked the c1sco example (not sure if we should mention a real company name in such an rfc someone not reading the draft might take offense, maybe examp1e.com insted though). But taking your thought into account: There is a fundamental difference betwen TOFU and out-of-band-authentication/approval (pick a term), and the fact that different such mechanisms may have (often human) weaknesses does not change this fundamental difference ?? Maybe you want to propose text ? Cheers Toerless On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: > Hi Toerless, > > > On 4 Jun 2019, at 21:28, Toerless Eckert wrote: > > > > Thanks, Eliot, > > > > re-reading 10.3, my impression is: > > > > a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2. > > The sentence stubs in 103 mentioning TOFU also don't seem to add value, the text > > doesn't become IMHO worse if they are simply removed. And i am sure > > there can easily be similar non-cyptographic leap of faiths in sales integration, > > or consortium memberships trust chaing establishment. > > My point is that those are no longer leaps of faith. > > Eliot > > > > > b) The text could IMHO be crisper: > > > > "will have no problem collaborating with it's MASA" -> > > "will have no problem collaborating with it's malicious MASA" -> > > > > "the domain (registrar) still needs to trust the manufacturer" -> > > "the domain (registrar) still needs to authenticate the MASA" ? > > (i hope the latter is the correct interpretation of the text) > > > > Cheers > > Toerless > > > > On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: > >> Just on this text: > >> > >> In Section 10.3 the following text exists: > >> > >> o A Trust-On-First-Use (TOFU) mechanism. A human would be queried > >> upon seeing a manufacturer's trust anchor for the first time, and > >> then the trust anchor would be installed to the trusted store. > >> There are risks with this; even if the key to name is validated > >> using something like the WebPKI, there remains the possibility > >> that the name is a look alike: e.g, c1sco.com, .. > >> > >> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval". This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer. > >> > >> Eliot > >> > >>> On 21 May 2019, at 23:21, The IESG wrote: > >>> > >>> > >>> The IESG has received a request from the Autonomic Networking Integrated > >>> Model and Approach WG (anima) to consider the following document: - > >>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' > >>> as Proposed Standard > >>> > >>> This is a second Last Call. IoT Directorate review was done after the ANIMA > >>> WG Last Call and consensus to request the publication, and that review resulted > >>> in substantial changes to the document. > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits final > >>> comments on this action. Please send substantive comments to the > >>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may be > >>> sent to iesg@ietf.org instead. In either case, please retain the beginning of > >>> the Subject line to allow automated sorting. > >>> > >>> Abstract > >>> > >>> > >>> This document specifies automated bootstrapping of an Autonomic > >>> Control Plane. To do this a remote secure key infrastructure (BRSKI) > >>> is created using manufacturer installed X.509 certificate, in > >>> combination with a manufacturer's authorizing service, both online > >>> and offline. Bootstrapping a new device can occur using a routable > >>> address and a cloud service, or using only link-local connectivity, > >>> or on limited/disconnected networks. Support for lower security > >>> models, including devices with minimal identity, is described for > >>> legacy reasons but not encouraged. Bootstrapping is complete when > >>> the cryptographic identity of the new key infrastructure is > >>> successfully deployed to the device but the established secure > >>> connection can be used to deploy a locally issued certificate to the > >>> device as well. > >>> > >>> > >>> > >>> > >>> The file can be obtained via > >>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > >>> > >>> IESG discussion can be tracked via > >>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ > >>> > >>> The following IPR Declarations may be related to this I-D: > >>> > >>> https://datatracker.ietf.org/ipr/2816/ > >>> https://datatracker.ietf.org/ipr/3233/ > >>> https://datatracker.ietf.org/ipr/2463/ > >>> > >>> > >>> > >>> The document contains these normative downward references. > >>> See RFC 3967 for additional information: > >>> rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream) > >>> > >>> > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >> > > > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Sat Jun 8 06:37:35 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCB61200B2; Sat, 8 Jun 2019 06:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 rdZb5wPspBR8; Sat, 8 Jun 2019 06:37:30 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DA01200A1; Sat, 8 Jun 2019 06:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6661; q=dns/txt; s=iport; t=1560001050; x=1561210650; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8RbUz7tuJV5B7lySmxgLYLpQ27OaUErUsGc7O51jxF8=; b=EGN/pryYo4P1rEvuVEEZEMTcrv0PfMEgNwD8bhvuaWKIDNYRhbc/UoPd QIHpMVDdSMchFIBQajIa5bjF/d9sKYLlxdiuD6h2l71x24kccQpWeua57 npTyebKbPfewaZoR6UUNMDeUa3LezvcpvE+lNDvo4xjCrzdjF3MfSka+B A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAADsuftc/xbLJq1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYJ6UjIohBWIe4tfJZh0gWcJAQEBDAE?= =?us-ascii?q?BGA0KAQGEQAKDDTcGDgEDAQEEAQECAQRtHAyFSgEBAQECAQEBIQRHCwULCw4?= =?us-ascii?q?KAgIRDgcCAicwBhODIgGBew8Ppxx+M4QyARNBhSuBDCgBiRKCYIF/gREnDBO?= =?us-ascii?q?CTD6CYQEBAwGBGBsDDxg/gksygiYEiz0zh0KVdQmCEYIbhCmKTYIxG4IlaYY?= =?us-ascii?q?TjXqUJowggwcCBAYFAhWBZSIdgTszGggbFTsqAYINATMJNYFYMIM5hRSFQT0?= =?us-ascii?q?DMI1QAg0XB4IPFgEB?= X-IronPort-AV: E=Sophos;i="5.63,567,1557187200"; d="scan'208";a="12935599" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2019 13:37:20 +0000 Received: from ams3-vpn-dhcp2071.cisco.com (ams3-vpn-dhcp2071.cisco.com [10.61.72.23]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x58DbIVO007766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Jun 2019 13:37:19 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Eliot Lear In-Reply-To: <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> Date: Sat, 8 Jun 2019 15:37:16 +0200 Cc: ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.72.23, ams3-vpn-dhcp2071.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 13:37:33 -0000 > On 7 Jun 2019, at 23:17, Toerless Eckert wrote: >=20 > Ok, now i got you (i hope ;-). >=20 > I really liked the c1sco example (not sure if we should mention a real > company name in such an rfc someone not reading the draft might take > offense, maybe examp1e.com insted though). This is a bit tricky with the glyph attack, but certainly the base = should be example.com. >=20 > But taking your thought into account: There is a fundamental = difference > betwen TOFU and out-of-band-authentication/approval (pick a term), > and the fact that different such mechanisms may have (often human) > weaknesses does not change this fundamental difference ?? I think the key is that humans oughtn=E2=80=99t rely solely on a visual = inspection of whatever is presented in front of them, but rather that = they might rely on alternative inputs, such as recommendations made by = the registrar provider, or federated services. >=20 > Maybe you want to propose text ? Manual approval by administrator or selection by administrator. Eliot >=20 > Cheers > Toerless >=20 > On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: >> Hi Toerless, >>=20 >>> On 4 Jun 2019, at 21:28, Toerless Eckert wrote: >>>=20 >>> Thanks, Eliot, >>>=20 >>> re-reading 10.3, my impression is: >>>=20 >>> a) The use of TOFU in 10.3 seems to exceed the explanatory = definition in 1.2. >>> The sentence stubs in 103 mentioning TOFU also don't seem to add = value, the text >>> doesn't become IMHO worse if they are simply removed. And i am sure >>> there can easily be similar non-cyptographic leap of faiths in sales = integration, >>> or consortium memberships trust chaing establishment. >>=20 >> My point is that those are no longer leaps of faith. >>=20 >> Eliot >>=20 >>>=20 >>> b) The text could IMHO be crisper: >>>=20 >>> "will have no problem collaborating with it's MASA" -> >>> "will have no problem collaborating with it's malicious MASA" -> >>>=20 >>> "the domain (registrar) still needs to trust the manufacturer" -> >>> "the domain (registrar) still needs to authenticate the MASA" ? >>> (i hope the latter is the correct interpretation of the text) >>>=20 >>> Cheers >>> Toerless >>>=20 >>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >>>> Just on this text: >>>>=20 >>>> In Section 10.3 the following text exists: >>>>=20 >>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be = queried >>>> upon seeing a manufacturer's trust anchor for the first time, = and >>>> then the trust anchor would be installed to the trusted store. >>>> There are risks with this; even if the key to name is validated >>>> using something like the WebPKI, there remains the possibility >>>> that the name is a look alike: e.g, c1sco.com, .. >>>>=20 >>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer = that the term be replaced with something like "out-of-band approval". = This would also be a good area for certification services to step in to = indicate the trustworthiness of a manufacturer. >>>>=20 >>>> Eliot >>>>=20 >>>>> On 21 May 2019, at 23:21, The IESG = wrote: >>>>>=20 >>>>>=20 >>>>> The IESG has received a request from the Autonomic Networking = Integrated >>>>> Model and Approach WG (anima) to consider the following document: = - >>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' >>>>> as Proposed = Standard >>>>>=20 >>>>> This is a second Last Call. IoT Directorate review was done after = the ANIMA >>>>> WG Last Call and consensus to request the publication, and that = review resulted >>>>> in substantial changes to the document. >>>>>=20 >>>>> The IESG plans to make a decision in the next few weeks, and = solicits final >>>>> comments on this action. Please send substantive comments to the >>>>> ietf@ietf.org mailing lists by 2019-06-04. 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. >>>>>=20 >>>>> Abstract >>>>>=20 >>>>>=20 >>>>> This document specifies automated bootstrapping of an Autonomic >>>>> Control Plane. To do this a remote secure key infrastructure = (BRSKI) >>>>> is created using manufacturer installed X.509 certificate, in >>>>> combination with a manufacturer's authorizing service, both online >>>>> and offline. Bootstrapping a new device can occur using a = routable >>>>> address and a cloud service, or using only link-local = connectivity, >>>>> or on limited/disconnected networks. Support for lower security >>>>> models, including devices with minimal identity, is described for >>>>> legacy reasons but not encouraged. Bootstrapping is complete when >>>>> the cryptographic identity of the new key infrastructure is >>>>> successfully deployed to the device but the established secure >>>>> connection can be used to deploy a locally issued certificate to = the >>>>> device as well. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The file can be obtained via >>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ >>>>>=20 >>>>> IESG discussion can be tracked via >>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/b= allot/ >>>>>=20 >>>>> The following IPR Declarations may be related to this I-D: >>>>>=20 >>>>> https://datatracker.ietf.org/ipr/2816/ >>>>> https://datatracker.ietf.org/ipr/3233/ >>>>> https://datatracker.ietf.org/ipr/2463/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The document contains these normative downward references. >>>>> See RFC 3967 for additional information: >>>>> rfc8368: Using an Autonomic Control Plane for Stable Connectivity = of Network Operations, Administration, and Maintenance (OAM) = (Informational - IETF stream) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>=20 >>>=20 >>>=20 >>>=20 >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>=20 >>>=20 >>> -- >>> --- >>> tte@cs.fau.de >>=20 >=20 >=20 >=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 > --=20 > --- > tte@cs.fau.de From nobody Sat Jun 8 16:21:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AE212010E; Sat, 8 Jun 2019 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-ut1wkWHiMq; Sat, 8 Jun 2019 16:20:52 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 E7E81120058; Sat, 8 Jun 2019 16:20:51 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id t16so3156682pfe.11; Sat, 08 Jun 2019 16:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5oXnb143G6mZDgHWNQHmxYE6t8j85KfAFK89Cj5W73E=; b=peXIRApx0h18TtFWtypG9ULXAzF37k39hQoi0OFjo0RFhgWeieOn9RzAsClNvtUvjd Oj04BECr4oyecbMQJeN7FR+Z1QgLfpeIsjqfrMo/gxy1fLbf60a+/EK7LkpJ7arORPok xwAtfBmnNP3RFtT0Q0W2l67tyxdUXIDAKL8Zvxn4NdoHbUpIFxK2Uv0Q/qdPI4Sis7W8 lvdNk3p7ziIH5pZPmVwGVBnjIAQjJsaZ12NPE2IjhJbWxauO4L8qSEnsYfTXj7Uvio3k zdyJ9QQHlR4dPXNCpVLYqC6qa6CjoLQozE6F3wb1swDBgSekVrrsymbG0gKdAoFI5Zo/ r2hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5oXnb143G6mZDgHWNQHmxYE6t8j85KfAFK89Cj5W73E=; b=oaWCMCPW9i2sLh7s0odydEYpUbfq7EcmA52RknY4KsebDssMFaVgQFpgYU5o5obLE6 AK/hwIQtH6iJBfb9dbW+GeFX/SjXpOlD14dc8Gol94XTyUR6ZBN+htcmIcfVD61AkgKo quDFKvd5+uo/8ds4gTyIapGI+mPmwTAp7y26kFYRnzYvBxiyAIdGEFwg/FYgifMh6g2N zstKdZYGxFzqiXK19lN5o4sxiBtVr0V6kjic4Nf7/UE+Jo80MxZrdjVsMo2YcOxjzjJM KgbC3S9TcG/JHxzvp9+WXYa2vptE7W2jUP+2c2oHO6cW+08zHMb4SsKAAOhw9EOvkbeJ sKEA== X-Gm-Message-State: APjAAAWu4jh+6qNk5Lf+HMMt3f+nY2tT/15DvA1/qBFP30ob5olfV/PT L1surK+xF2JCFWZ0iy6eM4Rnh8Ev X-Google-Smtp-Source: APXvYqzT/w+ksiBNap0PgUkPFWbOVTW21q3J050sw4r5SUAGDZ042fhhGhKoHKeQ9ONwBmovELgNfQ== X-Received: by 2002:a63:ce08:: with SMTP id y8mr798065pgf.38.1560036051032; Sat, 08 Jun 2019 16:20:51 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id l38sm5592522pje.12.2019.06.08.16.20.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jun 2019 16:20:50 -0700 (PDT) To: Eliot Lear , Toerless Eckert Cc: ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> From: Brian E Carpenter Message-ID: <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> Date: Sun, 9 Jun 2019 11:20:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 23:20:55 -0000 On 09-Jun-19 01:37, Eliot Lear wrote: >=20 >=20 >> On 7 Jun 2019, at 23:17, Toerless Eckert wrote: >> >> Ok, now i got you (i hope ;-). >> >> I really liked the c1sco example (not sure if we should mention a real= >> company name in such an rfc someone not reading the draft might take >> offense, maybe examp1e.com insted though). >=20 > This is a bit tricky with the glyph attack, but certainly the base shou= ld be > example.com. Can you use null.example.com and nu11.example.com? Brian >> But taking your thought into account: There is a fundamental differenc= e >> betwen TOFU and out-of-band-authentication/approval (pick a term), >> and the fact that different such mechanisms may have (often human) >> weaknesses does not change this fundamental difference ?? >=20 >=20 > I think the key is that humans oughtn=E2=80=99t rely solely on a visual= inspection of whatever is presented in front of them, but rather that th= ey might rely on alternative inputs, such as recommendations made by the = registrar provider, or federated services. >=20 >=20 >> >> Maybe you want to propose text ? >=20 > Manual approval by administrator or selection by administrator. >=20 > Eliot >> >> Cheers >> Toerless >> >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: >>> Hi Toerless, >>> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert wrote: >>>> >>>> Thanks, Eliot, >>>> >>>> re-reading 10.3, my impression is: >>>> >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory definitio= n in 1.2. >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add val= ue, the text >>>> doesn't become IMHO worse if they are simply removed. And i am sure >>>> there can easily be similar non-cyptographic leap of faiths in sales= integration, >>>> or consortium memberships trust chaing establishment. >>> >>> My point is that those are no longer leaps of faith. >>> >>> Eliot >>> >>>> >>>> b) The text could IMHO be crisper: >>>> >>>> "will have no problem collaborating with it's MASA" -> >>>> "will have no problem collaborating with it's malicious MASA" -> >>>> >>>> "the domain (registrar) still needs to trust the manufacturer" -> >>>> "the domain (registrar) still needs to authenticate the MASA" ? >>>> (i hope the latter is the correct interpretation of the text) >>>> >>>> Cheers >>>> Toerless >>>> >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >>>>> Just on this text: >>>>> >>>>> In Section 10.3 the following text exists: >>>>> >>>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be querie= d >>>>> upon seeing a manufacturer's trust anchor for the first time, a= nd >>>>> then the trust anchor would be installed to the trusted store. >>>>> There are risks with this; even if the key to name is validated= >>>>> using something like the WebPKI, there remains the possibility >>>>> that the name is a look alike: e.g, c1sco.com, .. >>>>> >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer t= hat the term be replaced with something like "out-of-band approval". Thi= s would also be a good area for certification services to step in to indi= cate the trustworthiness of a manufacturer. >>>>> >>>>> Eliot >>>>> >>>>>> On 21 May 2019, at 23:21, The IESG wrote= : >>>>>> >>>>>> >>>>>> The IESG has received a request from the Autonomic Networking Inte= grated >>>>>> Model and Approach WG (anima) to consider the following document: = - >>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' >>>>>> as Proposed Stand= ard >>>>>> >>>>>> This is a second Last Call. IoT Directorate review was done after = the ANIMA >>>>>> WG Last Call and consensus to request the publication, and that re= view resulted >>>>>> in substantial changes to the document. >>>>>> >>>>>> The IESG plans to make a decision in the next few weeks, and solic= its final >>>>>> comments on this action. Please send substantive comments to the >>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments= may be >>>>>> sent to iesg@ietf.org instead. In either case, please retain the b= eginning of >>>>>> the Subject line to allow automated sorting. >>>>>> >>>>>> Abstract >>>>>> >>>>>> >>>>>> This document specifies automated bootstrapping of an Autonomic >>>>>> Control Plane. To do this a remote secure key infrastructure (BRS= KI) >>>>>> is created using manufacturer installed X.509 certificate, in >>>>>> combination with a manufacturer's authorizing service, both online= >>>>>> and offline. Bootstrapping a new device can occur using a routabl= e >>>>>> address and a cloud service, or using only link-local connectivity= , >>>>>> or on limited/disconnected networks. Support for lower security >>>>>> models, including devices with minimal identity, is described for >>>>>> legacy reasons but not encouraged. Bootstrapping is complete when= >>>>>> the cryptographic identity of the new key infrastructure is >>>>>> successfully deployed to the device but the established secure >>>>>> connection can be used to deploy a locally issued certificate to t= he >>>>>> device as well. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The file can be obtained via >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-ke= yinfra/ >>>>>> >>>>>> IESG discussion can be tracked via >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-ke= yinfra/ballot/ >>>>>> >>>>>> The following IPR Declarations may be related to this I-D: >>>>>> >>>>>> https://datatracker.ietf.org/ipr/2816/ >>>>>> https://datatracker.ietf.org/ipr/3233/ >>>>>> https://datatracker.ietf.org/ipr/2463/ >>>>>> >>>>>> >>>>>> >>>>>> The document contains these normative downward references. >>>>>> See RFC 3967 for additional information: >>>>>> rfc8368: Using an Autonomic Control Plane for Stable Connectivity= of Network Operations, Administration, and Maintenance (OAM) (Informatio= nal - IETF stream) >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>> >>>> >>>> -- >>>> --- >>>> tte@cs.fau.de >>> >> >> >> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> --=20 >> --- >> tte@cs.fau.de >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Jun 10 04:17:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B0A120046 for ; Mon, 10 Jun 2019 04:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jto20N9QAEdK for ; Mon, 10 Jun 2019 04:17:33 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536A812016D for ; Mon, 10 Jun 2019 04:17:31 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id t28so7521332lje.9 for ; Mon, 10 Jun 2019 04:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ybVzbF/fqDs33T6qXFAQ70eNL94t7hhCYxvgjr/UEcU=; b=mDFJexFxMizH5TfPV2ZoJjpVzRz0Ktc/DngHsEK5Je9kD7XiKdaPa1Nj7z9Ds13DJ6 7YxN/xlgZTaRbZRMz2F1sQni2MyRjH7QuWUsIStfrfUDIEZ/aBq5UJXngP79L2n3aH/j W7LiJp1hcYpPtvmHZMvs/UJ58qPzc10NZIt/27djeWUPMl3wvAT9zg9ZDSm8NFhEiTyb iKJP+q6pSLaal5NcrpdSOlZk9ozqy4mYpB5k5rm0TB3Ww3TSPLBAE2lvRy+lx7FCUEk1 23Vajyp7wSj2xZdP3Hi4K9oxK+tTLhZYiCKUxUXdSE01EUBVbhD/KiteBbeTfGlLRPIc y4iw== 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=ybVzbF/fqDs33T6qXFAQ70eNL94t7hhCYxvgjr/UEcU=; b=NspUsrArJhR1+RqqDbyKlfW8it8CwqptqWrpIGV0m0vJs3Qgwg5Cn2lZOzHjKIK9CQ 64nPbpoyBKV6nGV5obMH4cPJETMrRhmnIq6OirJ+yHPt0vGvGpGCjO+Bcu/kWM759oJk bfuTXDWYjSC2Zamabyuy/SzXHzcAy44sWNlvkJSEnLJjKP1dOHE/8GxOAX+v5aZLQHI4 7E2UHmT6B8ANDKbD3WezZUR8Tb3Ni9hT7usFtmFymP44ZgBIcfKMo8Y8I7DR5hOQCkei tIyGzdda+8F50+cobzq0vzUTIVB92L6WdvZ/HTlzUOmqY6eiUe8dgy/iSlQ6JJ0tsGDF aiLg== X-Gm-Message-State: APjAAAX6EXZQOF7XaA9Jo3BziSGadX5OK2DfLsaK9MvV26SVT+A/Z5N3 0jXc9x1Wjhr0OqW4H+UUKB0CLYv80ai4qtFgu1etKA== X-Google-Smtp-Source: APXvYqz2jJjgzVkjYNgC6HKcBLUITHhwhrLhzvWLQu1TsbwjJT7mnzEiXS+RxQDazfYy5shwKL/73yw9SMa8VgF2Sto= X-Received: by 2002:a2e:9152:: with SMTP id q18mr17144234ljg.77.1560165448931; Mon, 10 Jun 2019 04:17:28 -0700 (PDT) MIME-Version: 1.0 References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> In-Reply-To: <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> From: Eric Rescorla Date: Mon, 10 Jun 2019 04:16:52 -0700 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , Toerless Eckert , Ignas Bagdonas , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="0000000000006006e5058af653ed" Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 11:17:36 -0000 --0000000000006006e5058af653ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 8, 2019 at 4:21 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 09-Jun-19 01:37, Eliot Lear wrote: > > > > > >> On 7 Jun 2019, at 23:17, Toerless Eckert wrote: > >> > >> Ok, now i got you (i hope ;-). > >> > >> I really liked the c1sco example (not sure if we should mention a real > >> company name in such an rfc someone not reading the draft might take > >> offense, maybe examp1e.com insted though). > > > > This is a bit tricky with the glyph attack, but certainly the base > should be > > example.com. > > Can you use null.example.com and nu11.example.com? > That's a little unfortunate from the perspective of this attack because .com is a public suffix [0] whereas example.com is not. -Ekr [0] https://publicsuffix.org/ > > Brian > > >> But taking your thought into account: There is a fundamental differenc= e > >> betwen TOFU and out-of-band-authentication/approval (pick a term), > >> and the fact that different such mechanisms may have (often human) > >> weaknesses does not change this fundamental difference ?? > > > > > > I think the key is that humans oughtn=E2=80=99t rely solely on a visual > inspection of whatever is presented in front of them, but rather that the= y > might rely on alternative inputs, such as recommendations made by the > registrar provider, or federated services. > > > > > >> > >> Maybe you want to propose text ? > > > > Manual approval by administrator or selection by administrator. > > > > Eliot > >> > >> Cheers > >> Toerless > >> > >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: > >>> Hi Toerless, > >>> > >>>> On 4 Jun 2019, at 21:28, Toerless Eckert wrote: > >>>> > >>>> Thanks, Eliot, > >>>> > >>>> re-reading 10.3, my impression is: > >>>> > >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory definitio= n > in 1.2. > >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add > value, the text > >>>> doesn't become IMHO worse if they are simply removed. And i am sure > >>>> there can easily be similar non-cyptographic leap of faiths in sales > integration, > >>>> or consortium memberships trust chaing establishment. > >>> > >>> My point is that those are no longer leaps of faith. > >>> > >>> Eliot > >>> > >>>> > >>>> b) The text could IMHO be crisper: > >>>> > >>>> "will have no problem collaborating with it's MASA" -> > >>>> "will have no problem collaborating with it's malicious MASA" -> > >>>> > >>>> "the domain (registrar) still needs to trust the manufacturer" -> > >>>> "the domain (registrar) still needs to authenticate the MASA" ? > >>>> (i hope the latter is the correct interpretation of the text) > >>>> > >>>> Cheers > >>>> Toerless > >>>> > >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: > >>>>> Just on this text: > >>>>> > >>>>> In Section 10.3 the following text exists: > >>>>> > >>>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be querie= d > >>>>> upon seeing a manufacturer's trust anchor for the first time, a= nd > >>>>> then the trust anchor would be installed to the trusted store. > >>>>> There are risks with this; even if the key to name is validated > >>>>> using something like the WebPKI, there remains the possibility > >>>>> that the name is a look alike: e.g, c1sco.com, .. > >>>>> > >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer > that the term be replaced with something like "out-of-band approval". Th= is > would also be a good area for certification services to step in to indica= te > the trustworthiness of a manufacturer. > >>>>> > >>>>> Eliot > >>>>> > >>>>>> On 21 May 2019, at 23:21, The IESG wrote= : > >>>>>> > >>>>>> > >>>>>> The IESG has received a request from the Autonomic Networking > Integrated > >>>>>> Model and Approach WG (anima) to consider the following document: = - > >>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' > >>>>>> as Proposed > Standard > >>>>>> > >>>>>> This is a second Last Call. IoT Directorate review was done after > the ANIMA > >>>>>> WG Last Call and consensus to request the publication, and that > review resulted > >>>>>> in substantial changes to the document. > >>>>>> > >>>>>> The IESG plans to make a decision in the next few weeks, and > solicits final > >>>>>> comments on this action. Please send substantive comments to the > >>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments > may be > >>>>>> sent to iesg@ietf.org instead. In either case, please retain the > beginning of > >>>>>> the Subject line to allow automated sorting. > >>>>>> > >>>>>> Abstract > >>>>>> > >>>>>> > >>>>>> This document specifies automated bootstrapping of an Autonomic > >>>>>> Control Plane. To do this a remote secure key infrastructure > (BRSKI) > >>>>>> is created using manufacturer installed X.509 certificate, in > >>>>>> combination with a manufacturer's authorizing service, both online > >>>>>> and offline. Bootstrapping a new device can occur using a routabl= e > >>>>>> address and a cloud service, or using only link-local connectivity= , > >>>>>> or on limited/disconnected networks. Support for lower security > >>>>>> models, including devices with minimal identity, is described for > >>>>>> legacy reasons but not encouraged. Bootstrapping is complete when > >>>>>> the cryptographic identity of the new key infrastructure is > >>>>>> successfully deployed to the device but the established secure > >>>>>> connection can be used to deploy a locally issued certificate to t= he > >>>>>> device as well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The file can be obtained via > >>>>>> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > >>>>>> > >>>>>> IESG discussion can be tracked via > >>>>>> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/= ballot/ > >>>>>> > >>>>>> The following IPR Declarations may be related to this I-D: > >>>>>> > >>>>>> https://datatracker.ietf.org/ipr/2816/ > >>>>>> https://datatracker.ietf.org/ipr/3233/ > >>>>>> https://datatracker.ietf.org/ipr/2463/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> The document contains these normative downward references. > >>>>>> See RFC 3967 for additional information: > >>>>>> rfc8368: Using an Autonomic Control Plane for Stable Connectivity > of Network Operations, Administration, and Maintenance (OAM) (Information= al > - IETF stream) > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Anima mailing list > >>>>>> Anima@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/anima > >>>>> > >>>> > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/anima > >>>> > >>>> > >>>> -- > >>>> --- > >>>> tte@cs.fau.de > >>> > >> > >> > >> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >> > >> > >> -- > >> --- > >> tte@cs.fau.de > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > --0000000000006006e5058af653ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jun 8, 2019 at 4:21 PM Brian = E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 09-Jun-19 01:37, Eliot Lear wrote:
>
>
>> On 7 Jun 2019, at 23:17, Toerless Eckert <tte@cs.fau.de> wrote:
>>
>> Ok, now i got you (i hope ;-).
>>
>> I really liked the c1sco example (not sure if we should mention a = real
>> company name in such an rfc someone not reading the draft might ta= ke
>> offense, maybe examp1e.com insted though).
>
> This is a bit tricky with the glyph attack, but certainly the base sho= uld be
> ex= ample.com.

Can you use null.example.com and nu11.example.com?

That's a little unfortunate from the perspective of t= his attack because .com is a public suffix [0] whereas example.com is not.

-Ekr
=


=C2=A0 =C2=A0 Brian

>> But taking your thought into account: There is a fundamental diffe= rence
>> betwen TOFU and out-of-band-authentication/approval (pick a term),=
>> and the fact that different such mechanisms may have (often human)=
>> weaknesses does not change this fundamental difference ??
>
>
> I think the key is that humans oughtn=E2=80=99t rely solely on a visua= l inspection of whatever is presented in front of them, but rather that the= y might rely on alternative inputs, such as recommendations made by the reg= istrar provider, or federated services.
>
>
>>
>> Maybe you want to propose text ?
>
> Manual approval by administrator or selection by administrator.
>
> Eliot
>>
>> Cheers
>>=C2=A0 =C2=A0Toerless
>>
>> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>>> Hi Toerless,
>>>
>>>> On 4 Jun 2019, at 21:28, Toerless Eckert <tte@cs.fau.de> wrote:
>>>>
>>>> Thanks, Eliot,
>>>>
>>>> re-reading 10.3, my impression is:
>>>>
>>>> a) The use of TOFU in 10.3 seems to exceed the explanatory= definition in 1.2.
>>>> The sentence stubs in 103 mentioning TOFU also don't s= eem to add value, the text
>>>> doesn't become IMHO worse if they are simply removed. = And i am sure
>>>> there can easily be similar non-cyptographic leap of faith= s in sales integration,
>>>> or consortium memberships trust chaing establishment.
>>>
>>> My point is that those are no longer leaps of faith.
>>>
>>> Eliot
>>>
>>>>
>>>> b) The text could IMHO be crisper:
>>>>
>>>> "will have no problem collaborating with it's MAS= A" ->
>>>> "will have no problem collaborating with it's mal= icious MASA" ->
>>>>
>>>> "the domain (registrar) still needs to trust the manu= facturer" ->
>>>> "the domain (registrar) still needs to authenticate t= he MASA" ?
>>>> (i hope the latter is the correct interpretation of the te= xt)
>>>>
>>>> Cheers
>>>>=C2=A0 =C2=A0Toerless
>>>>
>>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote= :
>>>>> Just on this text:
>>>>>
>>>>> In Section 10.3 the following text exists:
>>>>>
>>>>>=C2=A0 o=C2=A0 A Trust-On-First-Use (TOFU) mechanism.= =C2=A0 A human would be queried
>>>>>=C2=A0 =C2=A0 =C2=A0upon seeing a manufacturer's tr= ust anchor for the first time, and
>>>>>=C2=A0 =C2=A0 =C2=A0then the trust anchor would be inst= alled to the trusted store.
>>>>>=C2=A0 =C2=A0 =C2=A0There are risks with this; even if = the key to name is validated
>>>>>=C2=A0 =C2=A0 =C2=A0using something like the WebPKI, th= ere remains the possibility
>>>>>=C2=A0 =C2=A0 =C2=A0that the name is a look alike: e.g,= c1sco.co= m, ..
>>>>>
>>>>> First, this isn???t REALLY Trust-On-First-Use, and I w= ould prefer that the term be replaced with something like "out-of-band= approval".=C2=A0 This would also be a good area for certification ser= vices to step in to indicate the trustworthiness of a manufacturer.
>>>>>
>>>>> Eliot
>>>>>
>>>>>> On 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:
>>>>>>
>>>>>>
>>>>>> The IESG has received a request from the Autonomic= Networking Integrated
>>>>>> Model and Approach WG (anima) to consider the foll= owing document: -
>>>>>> 'Bootstrapping Remote Secure Key Infrastructur= es (BRSKI)'
>>>>>> <draft-ietf-anima-bootstrapping-keyinfra-20.txt= > as Proposed Standard
>>>>>>
>>>>>> This is a second Last Call. IoT Directorate review= was done after the ANIMA
>>>>>> WG Last Call and consensus to request the publicat= ion, and that review resulted
>>>>>> in substantial changes to the document.
>>>>>>
>>>>>> The IESG plans to make a decision in the next few = weeks, and solicits final
>>>>>> comments on this action. Please send substantive c= omments to the
>>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may= be
>>>>>> sent to iesg@ietf.org instead. In either case, please retain the begin= ning of
>>>>>> the Subject line to allow automated sorting.
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>>
>>>>>> This document specifies automated bootstrapping of= an Autonomic
>>>>>> Control Plane.=C2=A0 To do this a remote secure ke= y infrastructure (BRSKI)
>>>>>> is created using manufacturer installed X.509 cert= ificate, in
>>>>>> combination with a manufacturer's authorizing = service, both online
>>>>>> and offline.=C2=A0 Bootstrapping a new device can = occur using a routable
>>>>>> address and a cloud service, or using only link-lo= cal connectivity,
>>>>>> or on limited/disconnected networks.=C2=A0 Support= for lower security
>>>>>> models, including devices with minimal identity, i= s described for
>>>>>> legacy reasons but not encouraged.=C2=A0 Bootstrap= ping is complete when
>>>>>> the cryptographic identity of the new key infrastr= ucture is
>>>>>> successfully deployed to the device but the establ= ished secure
>>>>>> connection can be used to deploy a locally issued = certificate to the
>>>>>> device as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The file can be obtained via
>>>>>> ht= tps://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/=
>>>>>>
>>>>>> IESG discussion can be tracked via
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinf= ra/ballot/
>>>>>>
>>>>>> The following IPR Declarations may be related to t= his I-D:
>>>>>>
>>>>>> https://datatracker.ietf.org/ipr/2816= /
>>>>>> https://datatracker.ietf.org/ipr/3233= /
>>>>>> https://datatracker.ietf.org/ipr/2463= /
>>>>>>
>>>>>>
>>>>>>
>>>>>> The document contains these normative downward ref= erences.
>>>>>> See RFC 3967 for additional information:
>>>>>>=C2=A0 rfc8368: Using an Autonomic Control Plane fo= r Stable Connectivity of Network Operations, Administration, and Maintenanc= e (OAM) (Informational - IETF stream)
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> Anima mailing list
>>>>>> Anima@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/anima
>>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> An= ima@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/anima
>>>>
>>>>
>>>> --
>>>> ---
>>>> tte@cs.= fau.de
>>>
>>
>>
>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/anima<= /a>
>>
>>
>> --
>> ---
>> tte@cs.fau.de
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima
>

--0000000000006006e5058af653ed-- From nobody Mon Jun 10 07:49:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168791201A2 for ; Mon, 10 Jun 2019 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 dN4pqtiyzCID for ; Mon, 10 Jun 2019 07:49:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD79C12006A for ; Mon, 10 Jun 2019 07:49:50 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 189AF38187; Mon, 10 Jun 2019 10:48:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C6D78BB8; Mon, 10 Jun 2019 10:49:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C485614; Mon, 10 Jun 2019 10:49:48 -0400 (EDT) From: Michael Richardson To: Anima WG , Eric Rescorla In-Reply-To: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 14:49:53 -0000 --=-=-= Content-Type: text/plain {I've clipped the CC list} Eric Rescorla wrote: >> On 09-Jun-19 01:37, Eliot Lear wrote: >> > >> > >> >> On 7 Jun 2019, at 23:17, Toerless Eckert wrote: >> >> >> >> Ok, now i got you (i hope ;-). >> >> >> >> I really liked the c1sco example (not sure if we should mention a real >> >> company name in such an rfc someone not reading the draft might take >> >> offense, maybe examp1e.com insted though). >> > >> > This is a bit tricky with the glyph attack, but certainly the base >> should be >> > example.com. >> >> Can you use null.example.com and nu11.example.com? >> > That's a little unfortunate from the perspective of this attack because > ..com is a public suffix [0] whereas example.com is not. > -Ekr > [0] https://publicsuffix.org/ okay, I'm trying to understand the relevance of this from the point of an example in an RFC. We need to put the example under example.*, but we can't use examp1e.com, because it's not an example domain. Brian suggested the example null vs nu11. This is not about super-cookies, etc. and it doesn't suggest any kind of process involving the list of publicsuffixes. I've opened issue: https://github.com/anima-wg/anima-bootstrap/issues/131 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz+bgwACgkQgItw+93Q 3WVZWAf8Cpw7c+O+XHqLfny9Gpt1C1Iqk+IkvVIZvntLK18++74Ob0hzTe5MktET QJIF8619mrZFFp+3+wKWXyw3nZ5bDalZIvDXh/70AHjsdKfhmdPLNR7PaUEaLc6j nPB3LaWUQ1+BQ0k08am3spxtTSi7TeBZYVJPooFAR8XIEEEK/NMUYR6sRRSUIKVr ntXi9182fzMNaFu67fDlQH1ZZktlhB5Op/8CrAJar7olVNrq2+FyLeIXmJGppRNf KUFZsetvkoYHfQh/kF4b+LeoyY+qqH2BlnspzjM9iWXKHbbAMcQ4tW59zZXyuaZz 5NzuUX43NPv8iBK6YU+PX1VkYN/k2Q== =Awpx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 10 09:22:30 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8F712000F for ; Mon, 10 Jun 2019 09:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiUyM0Dq6O7R for ; Mon, 10 Jun 2019 09:22:25 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608B0120128 for ; Mon, 10 Jun 2019 09:22:25 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id x25so3950509ljh.2 for ; Mon, 10 Jun 2019 09:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LFaGczcqM/5M7Tzl9RmN5/FWrMzMRTonoHTzBn5AjNg=; b=JdKEA6EdFbPZ+zMngQgXkUNjb/yUN6K4qqUcki9CHgX0FBlbpI+q7R7lZ5Dy1FsHlp dfhrHJuA83yV7OO+bqgPnobLDkAcppF/u1plxrDcWh5k7UZu0WDVLluLGxGgnxVTf0uq lLSAEQQW16ipFDmMRAdPt6vkKqKaOqC6sVYVzohNd9w/Gh3O/UTGkPcrU+qkFSeEsSmN Mif2UIGZqTsUIYh6GMXntu0dudnvTtWlrXp9Q4c06qOjUS66mlPi9yh+dFu/76MspR0e FGSrUXnDM1wGXyXQhlhBt5JuooKEQOmFNGmaH+zFKKE64ZQv23gYm7oE28FfB2RJyiLg bi7w== 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=LFaGczcqM/5M7Tzl9RmN5/FWrMzMRTonoHTzBn5AjNg=; b=k4M1qFAuVpvKhI2T3Q+8mtceNebXfDZPa8r1ju63K2bpMfQ8fUQtdtPT2inehC6GiG d8teNN/EDp+fbRyF5vJ3LmowwlMhkTH99WH3hmLX6WVN/CA3VzL2UKrK6teLn6E6v5mF LqjSij10/2iFpap2Hqu+EhMO1bZgBSVu2b9R7nFLmabSP21w9p2RawJ02IU6qG9Gx1VZ 72+nONe2Z3juxNZ5R0t9WJ/HbFdDUMLDr9xCEIj1KiWjsG8ZiMep3Odb0wWklwbCPP9K AEt3dgWbbK+XeoGapBVpOBpIc1C1shEEO76kCMnAJ3osM5mJE8UUHn6ybuNEItuxoEqc wCjw== X-Gm-Message-State: APjAAAWbWLHqz0/IPAxP4aVe6EGrIRBMyq5eSsKXuK3DwKWYPNxstcZ0 V+bpApK+XhArHsjV+TMbWNWNLtUqH2a5b+BGvkvk1HK8pPIebA== X-Google-Smtp-Source: APXvYqwjsQbvuKhDI0iZtrwXCUrOG0Zl2+hdCWHW0WuI9S7LAzf9xCrxoVJdXy33BY/fRDPlmIfoRM+wbnTCoLtpyEI= X-Received: by 2002:a2e:9152:: with SMTP id q18mr18043300ljg.77.1560183743619; Mon, 10 Jun 2019 09:22:23 -0700 (PDT) MIME-Version: 1.0 References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> In-Reply-To: <6636.1560178188@localhost> From: Eric Rescorla Date: Mon, 10 Jun 2019 09:21:47 -0700 Message-ID: To: Michael Richardson Cc: Anima WG Content-Type: multipart/alternative; boundary="000000000000d2bde1058afa959a" Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 16:22:27 -0000 --000000000000d2bde1058afa959a Content-Type: text/plain; charset="UTF-8" On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson wrote: > > {I've clipped the CC list} > > Eric Rescorla wrote: > >> On 09-Jun-19 01:37, Eliot Lear wrote: > >> > > >> > > >> >> On 7 Jun 2019, at 23:17, Toerless Eckert wrote: > >> >> > >> >> Ok, now i got you (i hope ;-). > >> >> > >> >> I really liked the c1sco example (not sure if we should mention > a real > >> >> company name in such an rfc someone not reading the draft might > take > >> >> offense, maybe examp1e.com insted though). > >> > > >> > This is a bit tricky with the glyph attack, but certainly the base > >> should be > >> > example.com. > >> > >> Can you use null.example.com and nu11.example.com? > >> > > > That's a little unfortunate from the perspective of this attack > because > > ..com is a public suffix [0] whereas example.com is not. > > > -Ekr > > > [0] https://publicsuffix.org/ > > okay, I'm trying to understand the relevance of this from the point of an > example in an RFC. > > We need to put the example under example.*, but we can't use examp1e.com, > because it's not an example domain. > > Brian suggested the example null vs nu11. > This is not about super-cookies, etc. and it doesn't suggest any kind of > process involving the list of publicsuffixes. > The general shape of this kind of attack is that the attacker wants to impersonate A and so gets a domain with name A' that looks like A. However, this depends on A' being something the attacker can register. The public suffix list embodies the concept (more or less) of "anyone can register here". By contrast, a.example.com is (I assume) owned by example.com and so your average attacker can't do anything with b.example.com. -Ekr --000000000000d2bde1058afa959a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 10, 2019 at 7:49 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

{I've clipped the CC list}

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 >> On 09-Jun-19 01:37, Eliot Lear wrote:
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> >> On 7 Jun 2019, at 23:17, Toerless Eckert &l= t;tte@cs.fau.de> = wrote:
=C2=A0 =C2=A0 >> >>
=C2=A0 =C2=A0 >> >> Ok, now i got you (i hope ;-).
=C2=A0 =C2=A0 >> >>
=C2=A0 =C2=A0 >> >> I really liked the c1sco example (not sure = if we should mention a real
=C2=A0 =C2=A0 >> >> company name in such an rfc someone not rea= ding the draft might take
=C2=A0 =C2=A0 >> >> offense, maybe examp1e.com insted though).
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > This is a bit tricky with the glyph attack, but= certainly the base
=C2=A0 =C2=A0 >> should be
=C2=A0 =C2=A0 >> > example.com.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Can you use null.example.com and nu11.example.com?
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > That's a little unfortunate from the perspective of = this attack because
=C2=A0 =C2=A0 > ..com is a public suffix [0] whereas example.com is not.
=C2=A0 =C2=A0 > -Ekr

=C2=A0 =C2=A0 > [0] https://publicsuffix.org/

okay, I'm trying to understand the relevance of this from the point of = an
example in an RFC.

We need to put the example under example.*, but we can't use examp1e.com,<= br> because it's not an example domain.

Brian suggested the example null vs nu11.
This is not about super-cookies, etc. and it doesn't suggest any kind o= f
process involving the list of publicsuffixes.

The general shape of this kind of attack is that the attacker w= ants to impersonate A and so gets a domain with name A' that looks like A.= =20 However, this depends on A' being something the attacker can register.= =20 The public suffix list embodies the concept (more or less) of "anyone= =20 can register here". By contrast, a.example.com is (I assume) owned by example.com and so your average attacker c= an't do anything with b.example.com.

-Ekr
--000000000000d2bde1058afa959a-- From nobody Mon Jun 10 13:48:50 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EE21200FE for ; Mon, 10 Jun 2019 13:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.809 X-Spam-Level: X-Spam-Status: No, score=0.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy3nNo_1NdkE for ; Mon, 10 Jun 2019 13:48:46 -0700 (PDT) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 292C01200F1 for ; Mon, 10 Jun 2019 13:48:41 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id a3so5652046pgb.3 for ; Mon, 10 Jun 2019 13:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=I3ZgEmx9cUz5cIb7Gez/G5ngOgXGO1/8LPd1NE+HDMc=; b=fXIvsJ0RAzoE4xHpZiZY956mpUFDb/iSfzltAbVgZlsyWLN0W5wPnwo+m95f7TETfd ZSiWdMAIuPGHCuFm+Bax+CGyakJhwKFQXejPCL+IgmaxGCVElGGXz4aaTdMKDjKLs6Lt 268yOfqp+wz1EzQmJKy8GJJcffHFAbwF+PLJ262zbWzxevUH//0WD/o8HRdTPJjVa4vG NCRNRqjmOSV2aPCHVlVbj6fFN1Us7RUryHDUzDqDyYu77US4EoYfLXI5pyZbeCfGT748 MM0BgFPda/yJREZl6PwZXvMAOrtKHbNq5nZ6hznfI4MMP3HT/8CHbwzmBnSW3lCX8vNJ 1XdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=I3ZgEmx9cUz5cIb7Gez/G5ngOgXGO1/8LPd1NE+HDMc=; b=lhSmb6RJblkzSt9tya/tUSBwx7KudfQv5tAI+o4x3B8Crx9+IvnkpISsNP5JIv0eGJ wjyJQ6L3g0hmlnp8/JLd72qnYaC/bgEiu1JQ6bfBMigkfRm/4Jk+wOmiuHmZ3po8WxOj pd3CV43FIbboH2SxE0eMe6eZ7MgczTk5ji9/nt6Wsd3qebeDJmAypzRCfYnauZl9V4tJ AvFEtfw7MrUoU0MOfchst2IWLPcgly2ZFtOOzNvuenr3TuVbz21X/fnUT15UJ4+8CmUB TjuBW8v/oMslxxK5ix6dYf/BF3Z6Upib2LQ6MJBdBZKb7noZ09RXGrnDYqgPzNckAv1h RL5g== X-Gm-Message-State: APjAAAUn05n0tKMMHNYRLBfwilgaLlUz+JFZRibQ658+gBFxwzaHAoag EtsXaouS6rlT0lzZyJ3JklSDp1HF X-Google-Smtp-Source: APXvYqy+SIsSvhTz6R/L8kju1e3iAxbJS3ju4bZ9XyqJJQpGOBuxmFAXkzORPBOUv4sKU5jExEOTlA== X-Received: by 2002:a17:90a:7184:: with SMTP id i4mr23468966pjk.49.1560199720328; Mon, 10 Jun 2019 13:48:40 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id o126sm12112062pfb.134.2019.06.10.13.48.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 13:48:39 -0700 (PDT) To: Eric Rescorla , Michael Richardson Cc: Anima WG References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> From: Brian E Carpenter Message-ID: Date: Tue, 11 Jun 2019 08:48:35 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 20:48:49 -0000 On 11-Jun-19 04:21, Eric Rescorla wrote: >=20 >=20 > On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson > wrote: >=20 >=20 > {I've clipped the CC list} >=20 > Eric Rescorla > wrote: > =C2=A0 =C2=A0 >> On 09-Jun-19 01:37, Eliot Lear wrote: > =C2=A0 =C2=A0 >> > > =C2=A0 =C2=A0 >> > > =C2=A0 =C2=A0 >> >> On 7 Jun 2019, at 23:17, Toerless Eckert > wrote: > =C2=A0 =C2=A0 >> >> > =C2=A0 =C2=A0 >> >> Ok, now i got you (i hope ;-). > =C2=A0 =C2=A0 >> >> > =C2=A0 =C2=A0 >> >> I really liked the c1sco example (not sure if w= e should mention a real > =C2=A0 =C2=A0 >> >> company name in such an rfc someone not reading= the draft might take > =C2=A0 =C2=A0 >> >> offense, maybe examp1e.com = insted though). > =C2=A0 =C2=A0 >> > > =C2=A0 =C2=A0 >> > This is a bit tricky with the glyph attack, but = certainly the base > =C2=A0 =C2=A0 >> should be > =C2=A0 =C2=A0 >> > example.com . > =C2=A0 =C2=A0 >> > =C2=A0 =C2=A0 >> Can you use null.example.com and nu11.example.com ? > =C2=A0 =C2=A0 >> >=20 > =C2=A0 =C2=A0 > That's a little unfortunate from the perspective of= this attack because > =C2=A0 =C2=A0 > ..com is a public suffix [0] whereas example.com is not. >=20 > =C2=A0 =C2=A0 > -Ekr >=20 > =C2=A0 =C2=A0 > [0] https://publicsuffix.org/ >=20 > okay, I'm trying to understand the relevance of this from the point= of an > example in an RFC. >=20 > We need to put the example under example.*, but we can't use examp1= e.com , > because it's not an example domain. >=20 > Brian suggested the example null vs nu11. > This is not about super-cookies, etc. and it doesn't suggest any ki= nd of > process involving the list of publicsuffixes. >=20 >=20 > The general shape of this kind of attack is that the attacker wants to = impersonate A and so gets a domain with name A' that looks like A. Howeve= r, this depends on A' being something the attacker can register. The publ= ic suffix list embodies the concept (more or less) of "anyone can registe= r here". By contrast, a.example.com is (I assume) = owned by example.com and so your average attacker ca= n't do anything with b.example.com . However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so we= *really* can't use it. examp1e.net is 133.242.206.244 and actually respo= nds to HTTP. You're right that in theory subdomains are unrealistic examples, but does= that matter for an illustrative example? Brian From nobody Mon Jun 10 13:52:49 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0C112004F for ; Mon, 10 Jun 2019 13:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=1.886, RAZOR2_CHECK=0.922, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_5Unn1wgB0u for ; Mon, 10 Jun 2019 13:52:45 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 C74FE120018 for ; Mon, 10 Jun 2019 13:52:44 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id k18so9303937ljc.11 for ; Mon, 10 Jun 2019 13:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H2PNQDYzfoEHXvDadGa+JRhOoXhNBG8hclwmtOUUz6E=; b=Te4hub2oYvR9QjTaQPHFXhwjX9fk2VWnpVfPcViUO14zhYRELSu+mfzoQMCZJj+fIQ iR6RHfDkkWOEh1KdGV9ZZOuLn2VrAs9w9C+AqZLVWxViOA89idSSzlnCk1ny5rOlYJdt hahrdVnbHWDe3OzDU57pTkm+VWReBRFu3NWEUBhwCjYayWdwaVTaX8k/DuhaAlw3ioAp EJcrQrqpyyzGl1XkzpDcsJX3uvfAVGxOk4n3R96MAl3kvzOLu+MNSBhxjr2Sxj7MmtJc YpX7DHBoxg3u5r1xT1YeReiL0eT0mvHy7tohemUHJV69gYtmwon6ADMo96SkcMxn/6/G czHw== 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=H2PNQDYzfoEHXvDadGa+JRhOoXhNBG8hclwmtOUUz6E=; b=jJi1w1z8LguwmJ08BLu5qPIT0ng7jaVAZq37iur86KiYOKLSoldEtXOcWaqtII+wFV bF6lGVGjZzSjy1lPg3MA/Zhru2yUKeGck64ZIOQgnqfTp8Lxgu3CLwIThPRRPGTiC+Qd RX4Us+rWq6atsYa9hGTifOCzSMxkHXJ9JwS4A99NnW4ayycLpRqxld/lJFBz0E58iB/Z 8xT/24LcPmKgIk3UQV6HTPQI8IvbdIIgctoAQpB7P1mG3DcJPK/ooyo1XqCIlqfZoUC8 f6uEVwMIvMl6YOwgZKw26cbu5OtXHZqWQ+ojfq0vqKBMEGIf8jJt2asgJlm9pE9AWuuf VI4A== X-Gm-Message-State: APjAAAXnI2gQezf62MBwrjmdPXzIFLcraGpm6mtcI3phfxvYqNuNtmnl AK1HrqdCdlyAev52Jf891W3dnFUGloWjcwFILz/ThQ== X-Google-Smtp-Source: APXvYqz+MIsqLVpkStSHOEo/mDNsbRbCDIO0M2aGYK1h5LrUvZm6aMIv/O/qVfH1K7KCCqkEUsrXsvs7CJfyQlEakZ4= X-Received: by 2002:a2e:81c4:: with SMTP id s4mr26228760ljg.182.1560199962984; Mon, 10 Jun 2019 13:52:42 -0700 (PDT) MIME-Version: 1.0 References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> In-Reply-To: From: Eric Rescorla Date: Mon, 10 Jun 2019 13:52:06 -0700 Message-ID: To: Brian E Carpenter Cc: Michael Richardson , Anima WG Content-Type: multipart/alternative; boundary="000000000000929201058afe5c2b" Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 20:52:48 -0000 --000000000000929201058afe5c2b Content-Type: text/plain; charset="UTF-8" On Mon, Jun 10, 2019 at 1:48 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 11-Jun-19 04:21, Eric Rescorla wrote: > > > > > > On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson < > mcr+ietf@sandelman.ca > wrote: > > > > > > {I've clipped the CC list} > > > > Eric Rescorla > wrote: > > >> On 09-Jun-19 01:37, Eliot Lear wrote: > > >> > > > >> > > > >> >> On 7 Jun 2019, at 23:17, Toerless Eckert > wrote: > > >> >> > > >> >> Ok, now i got you (i hope ;-). > > >> >> > > >> >> I really liked the c1sco example (not sure if we should > mention a real > > >> >> company name in such an rfc someone not reading the draft > might take > > >> >> offense, maybe examp1e.com insted > though). > > >> > > > >> > This is a bit tricky with the glyph attack, but certainly > the base > > >> should be > > >> > example.com . > > >> > > >> Can you use null.example.com and > nu11.example.com ? > > >> > > > > > That's a little unfortunate from the perspective of this > attack because > > > ..com is a public suffix [0] whereas example.com < > http://example.com> is not. > > > > > -Ekr > > > > > [0] https://publicsuffix.org/ > > > > okay, I'm trying to understand the relevance of this from the point > of an > > example in an RFC. > > > > We need to put the example under example.*, but we can't use > examp1e.com , > > because it's not an example domain. > > > > Brian suggested the example null vs nu11. > > This is not about super-cookies, etc. and it doesn't suggest any > kind of > > process involving the list of publicsuffixes. > > > > > > The general shape of this kind of attack is that the attacker wants to > impersonate A and so gets a domain with name A' that looks like A. However, > this depends on A' being something the attacker can register. The public > suffix list embodies the concept (more or less) of "anyone can register > here". By contrast, a.example.com is (I assume) > owned by example.com and so your average attacker > can't do anything with b.example.com . > > However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so we > *really* can't use it. examp1e.net is 133.242.206.244 and actually > responds to HTTP. > > You're right that in theory subdomains are unrealistic examples, but does > that > matter for an illustrative example? > Why not instead use two domain names that end in .example? E.g., demo.example and dem0.example -Ekr > Brian > > --000000000000929201058afe5c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 10, 2019 at 1:48 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 11-Jun-19 04:21, Eric Rescorla wrote:
>
>
> On Mon, Jun 10, 2019 at 7:49 AM Michael Richardson <mcr+ietf@sandelman.ca <= ;mailto:mcr%= 2Bietf@sandelman.ca>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0{I've clipped the CC list}
>
>=C2=A0 =C2=A0 =C2=A0Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> On 09-Jun-19 01:37, Eliot Le= ar wrote:
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >> On 7 Jun 2019, at 2= 3:17, Toerless Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de>> wrote:
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >> Ok, now i got you (= i hope ;-).
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >> I really liked the = c1sco example (not sure if we should mention a real
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >> company name in suc= h an rfc someone not reading the draft might take
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >> offense, maybe examp1e.com= <http://examp1e.com> insted though).
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> >
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> > This is a bit tricky wi= th the glyph attack, but certainly the base
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> should be
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> > example.com <http://example.co= m>.
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >> Can you use null.example.com <http://null.example.com> and nu11.example.com <http://nu11.e= xample.com>?
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 >>
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 > That's a little unfortunate = from the perspective of this attack because
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 > ..com is a public suffix [0] whe= reas ex= ample.com <http://example.com> is not.
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 > -Ekr
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 > [0] https://publicsuffix.org/
>
>=C2=A0 =C2=A0 =C2=A0okay, I'm trying to understand the relevance of= this from the point of an
>=C2=A0 =C2=A0 =C2=A0example in an RFC.
>
>=C2=A0 =C2=A0 =C2=A0We need to put the example under example.*, but we = can't use examp1e.com <http://examp1e.com>,
>=C2=A0 =C2=A0 =C2=A0because it's not an example domain.
>
>=C2=A0 =C2=A0 =C2=A0Brian suggested the example null vs nu11.
>=C2=A0 =C2=A0 =C2=A0This is not about super-cookies, etc. and it doesn&= #39;t suggest any kind of
>=C2=A0 =C2=A0 =C2=A0process involving the list of publicsuffixes.
>
>
> The general shape of this kind of attack is that the attacker wants to= impersonate A and so gets a domain with name A' that looks like A. How= ever, this depends on A' being something the attacker can register. The= public suffix list embodies the concept (more or less) of "anyone can= register here". By contrast, a.example.com <http://a.example.com>= is (I assume) owned by example.com <http://example.com> and so your averag= e attacker can't do anything with b.example.com <http://b.example.com= >.

However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so we *rea= lly* can't use it. examp1e.net is 133.242.206.244 and actually responds to= HTTP.

You're right that in theory subdomains are unrealistic examples, but do= es that
matter for an illustrative example?

Why= not instead use two domain names that end in .example? E.g.,=C2=A0 demo.ex= ample and dem0.example

-Ekr



=C2=A0 =C2=A0 Brian

--000000000000929201058afe5c2b-- From nobody Mon Jun 10 14:55:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241D11200E0; Mon, 10 Jun 2019 14:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 header.b=ZAuXNXvZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uyOLztX+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5WCP-2R0tu9; Mon, 10 Jun 2019 14:55:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D0912001E; Mon, 10 Jun 2019 14:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26670; q=dns/txt; s=iport; t=1560203727; x=1561413327; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hssLA52mksYM6WZ4hoUIYSDq1rSrH6luFxLMR8atTi4=; b=ZAuXNXvZh8qa0PPuoU4b+i8Xy4ynNev43kE8yyzQtwWPuDaTtzBASq31 RIEUS1WEuaLqOVdLcWTh4GARJ8V0OsPsvKbKoWqN1MvvwLEqpNWaGmvL/ +VGAKRqA9910/ZN7PipIQa192P0iGQIM6kYkpL+zYFVv57b8N0H1FiQbD Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ANP6fSBBE0OAWxGGIgKXiUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAABU0f5c/5ldJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ4vJCwDalUgBAsoCoQLg0cDhFKKDYJXlzKBLoEkA1QJAQE?= =?us-ascii?q?BDAEBGAEMCAIBAYRAAheCXSM0CQ4BAwEBBAEBAgEEbRwMhUoBAQEBAwEBEBE?= =?us-ascii?q?KEwEBKQMMCwQCAQgOAwEDAQEoAwICAiULFAMGCAIEARIIGoMBgR1NAx0BAgy?= =?us-ascii?q?dbAKBOIhfcYExgk8qAQEFhQYYgg8DBoE0AYRvhm0XgUA/gRFGgkw+gmEBAQI?= =?us-ascii?q?BgTcRGCsJglQygiaLZx2CJIRsgh+GH4xvagkCgg+FaVuNGZcbjROHE48nAgQ?= =?us-ascii?q?CBAUCDgEBBYFPOIFYcBU7gmyCD4NwhRSFP3IBAYEnjDgCJAeBBAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,576,1557187200"; d="scan'208,217";a="282255518" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jun 2019 21:55:24 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5ALtOli022608 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Jun 2019 21:55:24 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Jun 2019 16:55:23 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 10 Jun 2019 16:55:23 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 10 Jun 2019 16:55:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hssLA52mksYM6WZ4hoUIYSDq1rSrH6luFxLMR8atTi4=; b=uyOLztX+jODx80OcaDmsrvh0PPrmYMBEvybpM590SC+YNa8vHxeXJW9Beu2CbySVkxU6v3OUETRCY8FCLqAeHiV4Vjzan20PGeafWr7XcodTWa9VyKgPh8BYSQr+Libfy9mVtZu97WoZ07fQo5k8X4So0F9souK/3VoRMa+druQ= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB2827.namprd11.prod.outlook.com (20.176.100.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Mon, 10 Jun 2019 21:55:22 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::d46b:d11:c52a:f807]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::d46b:d11:c52a:f807%7]) with mapi id 15.20.1965.017; Mon, 10 Jun 2019 21:55:22 +0000 From: "Owen Friel (ofriel)" To: Dan Harkins , "anima@ietf.org" , "emu@ietf.org" Thread-Topic: [Emu] teap-brski Thread-Index: AQHVHHIBAxJTiV6W80uQlmK2H+9Z36aVaMXA Date: Mon, 10 Jun 2019 21:55:21 +0000 Message-ID: References: <50c726dd-011d-9c52-6d79-caeb2ee0ef3b@lounge.org> In-Reply-To: <50c726dd-011d-9c52-6d79-caeb2ee0ef3b@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c202e87b-c117-4967-4df9-08d6edee5601 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB2827; x-ms-traffictypediagnostic: DM6PR11MB2827: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(13464003)(99286004)(966005)(5660300002)(14454004)(2906002)(73956011)(110136005)(256004)(14444005)(71200400001)(33656002)(52536014)(71190400001)(790700001)(606006)(66066001)(74316002)(3846002)(6116002)(186003)(446003)(53936002)(102836004)(86362001)(6246003)(6506007)(229853002)(66556008)(2201001)(11346002)(2501003)(486006)(68736007)(53546011)(64756008)(476003)(66476007)(66446008)(26005)(55016002)(236005)(6306002)(9686003)(54896002)(76116006)(66946007)(8676002)(25786009)(81156014)(8936002)(6436002)(76176011)(478600001)(7696005)(81166006)(316002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2827; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nttULXgnppmScLQgQJkgLJXQwm7sMgHB6dGj5ExNXIViE+OthMMD/kGoJdYeLiwfpG5I/+QJXIcnyatFRm82jRJ6tSrkSj9CTi0go15wjEgqHxNImlOFpc18S9VN1mC5VVMQ5Y+ErK66oecx47Jq10JvuV0l1XnL8z06G69vTBeVALQ72vZazRIhZN8SlKMxsOFyEoO/wjuICaxPr+KuRA5TmCnvjq2cHDn5BZzRjoKZMX4xd7ktJqONjaK1g7hQZDdRhENTM1k68ehAmSZCDfWsYT7eU+S+UQUBhpknXDETDcbHAscZopjdSV02Mb48KyHEtZ3Si/1GrpT+TTCWfhHY/GvCL+qlkzZ8xHoAXEhYOK49FD1G4Ad4yqEc6jhFi+DcyXW03NevgsUCHvCPo9aIGV+7CgLRE+it3CNIM/A= Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3385E9075778EA632C6B289DDB130DM6PR11MB3385namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c202e87b-c117-4967-4df9-08d6edee5601 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 21:55:21.9589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2827 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Anima] [Emu] teap-brski X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 21:55:30 -0000 --_000_DM6PR11MB3385E9075778EA632C6B289DDB130DM6PR11MB3385namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRW11IDxlbXUtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhbiBIYXJraW5zDQpTZW50OiAwNiBKdW5lIDIwMTkg MTU6MTMNClRvOiBhbmltYUBpZXRmLm9yZzsgZW11QGlldGYub3JnDQpTdWJqZWN0OiBbRW11XSB0 ZWFwLWJyc2tpDQoNCg0KDQoNCg0KICBIZWxsbywNCg0KDQoNCiAgSW4gYSBwcml2YXRlIHRocmVh ZCBvbiB0ZWFwLWJyc2tpIHRoZSB0b3BpYyBvZiBjby1sb2NhdGlvbiBvZiB0aGUgVEVBUCBzZXJ2 ZXIgYW5kIHRoZSBCUlNLSSByZWdpc3RyYXIgd2FzIGJyb3VnaHQgdXAuIEl0IHdhcyBzdWdnZXN0 ZWQgdGhhdCB0aGUgZGlzY3Vzc2lvbiBtb3ZlIHRvIHRoZXNlIGxpc3RzIHRvIGdldCBtb3JlIGlu cHV0IGZyb20gdGhlIGV4cGVydHMuDQoNCg0KDQogIEluIGRyYWZ0LWxlYXItZWFwLXRlYXAtYnJz a2ktMDIgdGhlIGFyY2hpdGVjdHVyZSBzaG93cyBhIHRoZSBURUFQIHNlcnZlciBhbmQgdGhlIEJS U0tJIHJlZ2lzdHJhciBhcyBzZXBhcmF0ZSB3aGlsZSBtZW50aW9uaW5nIHRoYXQgdGhleSBjYW4g YmUgY28tbG9jYXRlZC4NCg0KVGhlIGZvbGxvd2luZyBhc3N1bWVzIHRoZXkgYXJlIG5vdCBjby1s b2NhdGVkLg0KDQoNCg0KICBUaGUgQlJTS0kgcGxlZGdlIGluIHRoaXMgZHJhZnQgaXMgY2FsbGVk IGEgImRldmljZSIgYW5kIHRoZSBkZXZpY2UgZXN0YWJsaXNoZXMgYSBwcm92aXNpb25hbCBUTFMg Y29ubmVjdGlvbiAodGhyb3VnaCBURUFQKSB0byB0aGUgVEVBUCBzZXJ2ZXIgb3ZlciA4MDIuMVgg b3Igc29tZXRoaW5nIHNpbWlsYXIuIFRoZSBkZXZpY2UgZG9lcyBub3QgY29ubmVjdCB0byB0aGUg cmVnaXN0cmFyLiBUaGUgZGV2aWNlIHRoZW4gY3JlYXRlcyBhIHZvdWNoZXIgcmVxdWVzdCBhbmQg c2VuZHMgaXQgdG8gdGhlIFRFQVAgc2VydmVyIHVzaW5nIGEgbmV3bHkgZGVmaW5lZCBURUFQIFRM Vi4gVGhlIHJlZ2lzdHJhciBzaWducyB0aGUgcmVxdWVzdCwgZm9yd2FyZHMgaXQgb250byBhIE1B U0EsIGFuZCBzZW5kcyB0aGUgdm91Y2hlciBpdCBnZXRzIGJhY2sgZnJvbSB0aGUgTUFTQSB0byB0 aGUgZGV2aWNlIHVzaW5nIGFub3RoZXIgbmV3bHkgZGVmaW5lZCBURUFQIFRMVi4NCg0KDQoNCiAg U28gdGhlIHF1ZXN0aW9uIGlzLCB3aWxsIHRoaXMgZXZlbiB3b3JrPyBJZiB0aGUgVEVBUCBzZXJ2 ZXIgYW5kIEJSU0tJIHJlZ2lzdHJhciBhcmUgc2VwYXJhdGUgZW50aXRpZXMgdGhlbiB0aGUgdm91 Y2hlciB3aWxsIGluY2x1ZGUgdGhlIFRFQVAgc2VydmVyJ3MgRUUgY2VydGlmaWNhdGUgYnV0IGl0 IHdpbGwgYmUgc2lnbmVkIGJ5IHRoZSByZWdpc3RyYXIncyBFRSBjZXJ0aWZpY2F0ZS4gRnJvbSBt eSBhZG1pdHRlZGx5IGxpbWl0ZWQgdW5kZXJzdGFuZGluZyBvZiBCUlNLSSBJIHRoaW5rIHRoZSBN QVNBIHdpbGwgcmVqZWN0IHRoaXMgdm91Y2hlciByZXF1ZXN0IGJlY2F1c2UgaXQgZmFpbHMgdGhl ICJwcm94aW1pdHkiIGNoZWNrIChpZiBJIHVuZGVyc3RhbmQgdGhlIHByb3hpbWl0eSBjaGVjayBj b3JyZWN0bHkpLiBUaGUgTUFTQSB3aWxsIHRyZWF0IHRoZSByZWdpc3RyYXIgYXMgYSBtYW4taW4t dGhlLW1pZGRsZS4NCg0KDQoNCiAgQlJTS0kgZm9sa3M6IGlzIHRoaXMgY29ycmVjdD8gV2lsbCBh IHZvdWNoZXIgcmVxdWVzdCBiZSByZWplY3RlZCBmcm9tIGEgZGVwbG95bWVudCBsaWtlIHRoaXM/ DQoNCg0KDQpbb2ZyaWVsXSBJIGJlbGlldmUgdGhpcyB3aWxsIGZhaWwgdGhlIHByb3hpbWl0eSBj aGVjayBhcyBvdXRsaW5lZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhLTIwI3NlY3Rpb24tNS41LjUNCg0KDQoNCkhv d2V2ZXIsIHRoZXJlIGlzIGFuIGludGVyZXN0aW5nIGRlZmluaXRpb24gaW4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0y MCNzZWN0aW9uLTMuNA0KDQoNCg0KICAgICAgICBsZWFmIHByaW9yLXNpZ25lZC12b3VjaGVyLXJl cXVlc3Qgew0KDQogICAgICAgICAgdHlwZSBiaW5hcnk7DQoNCiAgICAgICAgICBkZXNjcmlwdGlv bg0KDQogICAgICAgICAgICAiSWYgaXQgaXMgbmVjZXNzYXJ5IHRvIGNoYW5nZSBhIHZvdWNoZXIs IG9yIHJlLXNpZ24gYW5kDQoNCiAgICAgICAgICAgICBmb3J3YXJkIGEgdm91Y2hlciB0aGF0IHdh cyBwcmV2aW91c2x5IHByb3ZpZGVkIGFsb25nIGENCg0KICAgICAgICAgICAgIHByb3RvY29sIHBh dGgsIHRoZW4gdGhlIHByZXZpb3VzbHkgc2lnbmVkIHZvdWNoZXIgU0hPVUxEIGJlDQoNCiAgICAg ICAgICAgICBpbmNsdWRlZCBpbiB0aGlzIGZpZWxkLg0KDQoNCg0KICAgICAgICAgICAgIEZvciBl eGFtcGxlLCBhIHBsZWRnZSBtaWdodCBzaWduIGEgdm91Y2hlciByZXF1ZXN0DQoNCiAgICAgICAg ICAgICB3aXRoIGEgcHJveGltaXR5LXJlZ2lzdHJhci1jZXJ0LCBhbmQgdGhlIHJlZ2lzdHJhcg0K DQogICAgICAgICAgICAgdGhlbiBpbmNsdWRlcyBpdCBpbiB0aGUgcHJpb3Itc2lnbmVkLXZvdWNo ZXItcmVxdWVzdCBmaWVsZC4NCg0KICAgICAgICAgICAgIFRoaXMgaXMgYSBzaW1wbGUgbWVjaGFu aXNtIGZvciBhIGNoYWluIG9mIHRydXN0ZWQNCg0KICAgICAgICAgICAgIHBhcnRpZXMgdG8gY2hh bmdlIGEgdm91Y2hlciByZXF1ZXN0LCB3aGlsZQ0KDQogICAgICAgICAgICAgbWFpbnRhaW5pbmcg dGhlIHByaW9yIHNpZ25hdHVyZSBpbmZvcm1hdGlvbi4NCg0KDQoNCiAgICAgICAgICAgICBUaGUg UmVnaXN0cmFyIGFuZCBNQVNBIE1BWSBleGFtaW5lIHRoZSBwcmlvciBzaWduZWQNCg0KICAgICAg ICAgICAgIHZvdWNoZXIgaW5mb3JtYXRpb24gZm9yIHRoZQ0KDQogICAgICAgICAgICAgcHVycG9z ZXMgb2YgcG9saWN5IGRlY2lzaW9ucy4gRm9yIGV4YW1wbGUgdGhpcyBpbmZvcm1hdGlvbg0KDQog ICAgICAgICAgICAgY291bGQgYmUgdXNlZnVsIHRvIGEgTUFTQSB0byBkZXRlcm1pbmUgdGhhdCBi b3RoIHBsZWRnZSBhbmQNCg0KICAgICAgICAgICAgIHJlZ2lzdHJhciBhZ3JlZSBvbiBwcm94aW1p dHkgYXNzZXJ0aW9ucy4gVGhlIE1BU0EgU0hPVUxEDQoNCiAgICAgICAgICAgICByZW1vdmUgYWxs IHByaW9yLXNpZ25lZC12b3VjaGVyLXJlcXVlc3QgaW5mb3JtYXRpb24gd2hlbg0KDQogICAgICAg ICAgICAgc2lnbmluZyBhIHZvdWNoZXIgZm9yIGltcHJpbnRpbmcgc28gYXMgdG8gbWluaW1pemUg dGhlDQoNCiAgICAgICAgICAgICBmaW5hbCB2b3VjaGVyIHNpemUuIjsNCg0KICAgICAgICB9DQoN Cg0KDQpNb3N0IG5vdGFibGU6IOKAnFRoaXMgaXMgYSBzaW1wbGUgbWVjaGFuaXNtIGZvciBhIGNo YWluIG9mIHRydXN0ZWQgcGFydGllcyB0byBjaGFuZ2UgYSB2b3VjaGVyIHJlcXVlc3QsIHdoaWxl IG1haW50YWluaW5nIHRoZSBwcmlvciBzaWduYXR1cmUgaW5mb3JtYXRpb24u4oCdDQoNCg0KDQpT byB3aXRoIHNvbWUgZXh0cmEgZGVmaW5pdGlvbiwgb25lIGNvdWxkIGVudmlzYWdlIHRoZSBURUFQ IHNlcnZlciBzaWduaW5nIHRoZSBWb3VjaGVyIHJlcXVlc3QgdXNpbmcgaXRzIGNlcnQgYW5kIGlu Y2x1ZGluZyB0aGUgUGxlZGdl4oCZcyB2b3VjaGVyIHJlcXVlc3QgaW4gaXRzIHByaW9yLXNpZ25l ZC12b3VjaGVyLXJlcXVlc3QgYW5kIHNlbmRpbmcgaXQgdG8gdGhlIFJBLCBhbmQgdGhlbiB0aGUg UkEgaW4gdHVybiBzaWduaW5nIHRoZSByZXF1ZXN0IHVzaW5nIGl0cyBvd24gY2VydCwgYW5kIGlu Y2x1ZGluZyB0aGUgVEVBUCBzZXJ2ZXLigJlzIHZvdWNoZXIgcmVxdWVzdCBpbiBpdHMgcHJpb3It c2lnbmVkLXZvdWNoZXItcmVxdWVzdC4gVGhlIHBsZWRnZSBjb3VsZCBhbHNvIGFzc2VydCB0aGUg VEVBUCBFRSBjZXJ0IGluIGl0cyB2b3VjaGVyIHJlcXVlc3QsIHdpdGggdGhlIFRFQVAgc2VydmVy IGFzc2VydGluZyB0aGUgUkHigJlzIGNlcnQgaW4gaXRzIHZvdWNoZXIgcmVxdWVzdC4gVGhlIE1B U0EgY291bGQgaW4gdGhlb3J5IHRoZW4gdmFsaWRhdGUgdGhlIGZ1bGwgY2hhaW4gb2YgdHJ1c3Qg YmFjay4NCg0KDQoNCk5vdywgdGhhdOKAmXMgcmVhZGluZyBhIGxvdCBpbnRvIHRoYXQgb25lIHN0 YXRlbWVudCwgYW5kIHRoZSByZXN0IG9mIEJSU0tJIGNlcnRhaW5seSBkb2VzbuKAmXQgZGVzY3Jp YmUgb3BlcmF0aW9uIGxpa2UgdGhhdCwgYW5kIGl0cyBmYXIgZWFzaWVyIHRvIG1hbmRhdGUgdGhh dCB0aGUgVEVBUCBzZXJ2ZXIgKmlzKiB0aGUgUmVnaXN0cmFyLg0KDQoNCg0KDQoNCg0KDQogIEVN VSBmb2xrczogaWYgdGhlIGFuc3dlciBmcm9tIHRoZSBCUlNLSSBmb2xrcyBpcyB0aGF0IHRoaXMg ZG9lc24ndCB3b3JrIHRoZW4gaXMgdGhlcmUgYW55IHNvcnQgb2Ygd2VpcmQgdHVubmVsaW5nIG9y ICJwaGFzZSAyIiB0cmlja2VyeSB0aGF0IGNhbiBiZSBhZGRlZCB0byBURUFQIHRvIGdldCB0aGlz IHRvIHdvcmsgb3Igc2hvdWxkIHdlIGp1c3QgZXhwbGljaXRseSBzdGF0ZSB0aGF0IHRoZSBURUFQ IHNlcnZlciBhbmQgdGhlIHJlZ2lzdHJhciBhcmUgdGhlIHNhbWUgZW50aXR5ICh0aGV5IGF1dGhl bnRpY2F0ZSB3aXRoIHRoZSBzYW1lIGNlcnRpZmljYXRlKT8NCg0KDQoNCiAgVGhhbmtzLA0KDQoN Cg0KICBEYW4uDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRW11IG1haWxpbmcgbGlzdA0KDQpFbXVAaWV0Zi5vcmc8bWFpbHRvOkVt dUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUN Cg== --_000_DM6PR11MB3385E9075778EA632C6B289DDB130DM6PR11MB3385namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0 LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4uZ3JleQ0KCXttc28tc3R5bGUtbmFt ZTpncmV5O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgzMDkwNjI2OTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjIxMjA0MzA2IC04OTQ0MDg0NTIg MTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1 NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiBFbXUgJmx0O2VtdS1ib3VuY2VzQGlldGYub3JnJmd0OyBPbiBCZWhhbGYgT2Yg RGFuIEhhcmtpbnM8YnI+DQpTZW50OiAwNiBKdW5lIDIwMTkgMTU6MTM8YnI+DQpUbzogYW5pbWFA aWV0Zi5vcmc7IGVtdUBpZXRmLm9yZzxicj4NClN1YmplY3Q6IFtFbXVdIHRlYXAtYnJza2k8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyBIZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7IEluIGEgcHJpdmF0ZSB0aHJlYWQgb24gdGVhcC1icnNraSB0aGUgdG9waWMgb2YgY28t bG9jYXRpb24gb2YgdGhlIFRFQVAgc2VydmVyIGFuZCB0aGUgQlJTS0kgcmVnaXN0cmFyIHdhcyBi cm91Z2h0IHVwLiBJdCB3YXMgc3VnZ2VzdGVkIHRoYXQgdGhlIGRpc2N1c3Npb24gbW92ZSB0byB0 aGVzZSBsaXN0cyB0byBnZXQgbW9yZSBpbnB1dCBmcm9tIHRoZSBleHBlcnRzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgSW4gZHJhZnQtbGVhci1lYXAtdGVhcC1icnNraS0w MiB0aGUgYXJjaGl0ZWN0dXJlIHNob3dzIGEgdGhlIFRFQVAgc2VydmVyIGFuZCB0aGUgQlJTS0kg cmVnaXN0cmFyIGFzIHNlcGFyYXRlIHdoaWxlIG1lbnRpb25pbmcgdGhhdCB0aGV5IGNhbiBiZSBj by1sb2NhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGZv bGxvd2luZyBhc3N1bWVzIHRoZXkgYXJlIG5vdCBjby1sb2NhdGVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsgVGhlIEJSU0tJIHBsZWRnZSBpbiB0aGlzIGRyYWZ0IGlzIGNh bGxlZCBhICZxdW90O2RldmljZSZxdW90OyBhbmQgdGhlIGRldmljZSBlc3RhYmxpc2hlcyBhIHBy b3Zpc2lvbmFsIFRMUyBjb25uZWN0aW9uICh0aHJvdWdoIFRFQVApIHRvIHRoZSBURUFQIHNlcnZl ciBvdmVyIDgwMi4xWCBvciBzb21ldGhpbmcgc2ltaWxhci4gVGhlIGRldmljZSBkb2VzIG5vdCBj b25uZWN0IHRvIHRoZSByZWdpc3RyYXIuIFRoZSBkZXZpY2UNCiB0aGVuIGNyZWF0ZXMgYSB2b3Vj aGVyIHJlcXVlc3QgYW5kIHNlbmRzIGl0IHRvIHRoZSBURUFQIHNlcnZlciB1c2luZyBhIG5ld2x5 IGRlZmluZWQgVEVBUCBUTFYuIFRoZSByZWdpc3RyYXIgc2lnbnMgdGhlIHJlcXVlc3QsIGZvcndh cmRzIGl0IG9udG8gYSBNQVNBLCBhbmQgc2VuZHMgdGhlIHZvdWNoZXIgaXQgZ2V0cyBiYWNrIGZy b20gdGhlIE1BU0EgdG8gdGhlIGRldmljZSB1c2luZyBhbm90aGVyIG5ld2x5IGRlZmluZWQgVEVB UCBUTFYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyBTbyB0aGUgcXVlc3Rp b24gaXMsIHdpbGwgdGhpcyBldmVuIHdvcms/IElmIHRoZSBURUFQIHNlcnZlciBhbmQgQlJTS0kg cmVnaXN0cmFyIGFyZSBzZXBhcmF0ZSBlbnRpdGllcyB0aGVuIHRoZSB2b3VjaGVyIHdpbGwgaW5j bHVkZSB0aGUgVEVBUCBzZXJ2ZXIncyBFRSBjZXJ0aWZpY2F0ZSBidXQgaXQgd2lsbCBiZSBzaWdu ZWQgYnkgdGhlIHJlZ2lzdHJhcidzIEVFIGNlcnRpZmljYXRlLiBGcm9tIG15IGFkbWl0dGVkbHkN CiBsaW1pdGVkIHVuZGVyc3RhbmRpbmcgb2YgQlJTS0kgSSB0aGluayB0aGUgTUFTQSB3aWxsIHJl amVjdCB0aGlzIHZvdWNoZXIgcmVxdWVzdCBiZWNhdXNlIGl0IGZhaWxzIHRoZSAmcXVvdDtwcm94 aW1pdHkmcXVvdDsgY2hlY2sgKGlmIEkgdW5kZXJzdGFuZCB0aGUgcHJveGltaXR5IGNoZWNrIGNv cnJlY3RseSkuIFRoZSBNQVNBIHdpbGwgdHJlYXQgdGhlIHJlZ2lzdHJhciBhcyBhIG1hbi1pbi10 aGUtbWlkZGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgQlJTS0kgZm9s a3M6IGlzIHRoaXMgY29ycmVjdD8gV2lsbCBhIHZvdWNoZXIgcmVxdWVzdCBiZSByZWplY3RlZCBm cm9tIGEgZGVwbG95bWVudCBsaWtlIHRoaXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+W29mcmllbF0gSSBiZWxpZXZlIHRoaXMgd2lsbCBmYWlsIHRoZSBwcm94aW1pdHkgY2hlY2sg YXMgb3V0bGluZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMjAjc2VjdGlvbi01LjUuNSI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5n LWtleWluZnJhLTIwI3NlY3Rpb24tNS41LjU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkhvd2V2ZXIsIHRoZXJlIGlzIGFuIGludGVyZXN0aW5nIGRlZmluaXRpb24g aW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFuaW1h LWJvb3RzdHJhcHBpbmcta2V5aW5mcmEtMjAjc2VjdGlvbi0zLjQiPg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0yMCNz ZWN0aW9uLTMuNDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBwcmlvci1zaWduZWQtdm91Y2hlci1yZXF1ZXN0IHs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlw ZSBiaW5hcnk7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0lmIGl0IGlzIG5lY2Vzc2FyeSB0byBj aGFuZ2UgYSB2b3VjaGVyLCBvciByZS1zaWduIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3J3YXJkIGEg dm91Y2hlciB0aGF0IHdhcyBwcmV2aW91c2x5IHByb3ZpZGVkIGFsb25nIGE8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcHJvdG9jb2wgcGF0aCwgdGhlbiB0aGUgcHJldmlvdXNseSBzaWduZWQgdm91Y2hlciBTSE9V TEQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5jbHVkZWQgaW4gdGhpcyBmaWVsZC48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRm9yIGV4YW1wbGUsIGEgcGxlZGdlIG1pZ2h0IHNpZ24gYSB2b3VjaGVyIHJlcXVl c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgd2l0aCBhIHByb3hpbWl0eS1yZWdpc3RyYXItY2VydCwgYW5kIHRo ZSByZWdpc3RyYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiBpbmNsdWRlcyBpdCBpbiB0aGUgcHJpb3It c2lnbmVkLXZvdWNoZXItcmVxdWVzdCBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBpcyBhIHNp bXBsZSBtZWNoYW5pc20gZm9yIGEgY2hhaW4gb2YgdHJ1c3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJ0 aWVzIHRvIGNoYW5nZSBhIHZvdWNoZXIgcmVxdWVzdCwgd2hpbGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFp bnRhaW5pbmcgdGhlIHByaW9yIHNpZ25hdHVyZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhlIFJlZ2lzdHJhciBhbmQgTUFTQSBNQVkgZXhhbWluZSB0aGUgcHJpb3Igc2lnbmVk PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHZvdWNoZXIgaW5mb3JtYXRpb24gZm9yIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBwdXJwb3NlcyBvZiBwb2xpY3kgZGVjaXNpb25zLiBGb3IgZXhhbXBsZSB0aGlzIGluZm9ybWF0 aW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvdWxkIGJlIHVzZWZ1bCB0byBhIE1BU0EgdG8gZGV0ZXJtaW5l IHRoYXQgYm90aCBwbGVkZ2UgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZ2lzdHJhciBhZ3JlZSBvbiBw cm94aW1pdHkgYXNzZXJ0aW9ucy4gVGhlIE1BU0EgU0hPVUxEPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlbW92 ZSBhbGwgcHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCBpbmZvcm1hdGlvbiB3aGVuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHNpZ25pbmcgYSB2b3VjaGVyIGZvciBpbXByaW50aW5nIHNvIGFzIHRvIG1pbmlt aXplIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmaW5hbCB2b3VjaGVyIHNpemUuJnF1b3Q7OzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+TW9zdCBub3RhYmxlOiDigJxUaGlzIGlzIGEgc2ltcGxlIG1l Y2hhbmlzbSBmb3IgYSBjaGFpbiBvZiB0cnVzdGVkIHBhcnRpZXMgdG8gY2hhbmdlIGEgdm91Y2hl ciByZXF1ZXN0LCB3aGlsZSBtYWludGFpbmluZyB0aGUgcHJpb3Igc2lnbmF0dXJlIGluZm9ybWF0 aW9uLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TbyB3aXRoIHNv bWUgZXh0cmEgZGVmaW5pdGlvbiwgb25lIGNvdWxkIGVudmlzYWdlIHRoZSBURUFQIHNlcnZlciBz aWduaW5nIHRoZSBWb3VjaGVyIHJlcXVlc3QgdXNpbmcgaXRzIGNlcnQgYW5kIGluY2x1ZGluZyB0 aGUgUGxlZGdl4oCZcyB2b3VjaGVyIHJlcXVlc3QgaW4gaXRzIHByaW9yLXNpZ25lZC12b3VjaGVy LXJlcXVlc3QgYW5kIHNlbmRpbmcgaXQgdG8gdGhlDQogUkEsIGFuZCB0aGVuIHRoZSBSQSBpbiB0 dXJuIHNpZ25pbmcgdGhlIHJlcXVlc3QgdXNpbmcgaXRzIG93biBjZXJ0LCBhbmQgaW5jbHVkaW5n IHRoZSBURUFQIHNlcnZlcuKAmXMgdm91Y2hlciByZXF1ZXN0IGluIGl0cyBwcmlvci1zaWduZWQt dm91Y2hlci1yZXF1ZXN0LiBUaGUgcGxlZGdlIGNvdWxkIGFsc28gYXNzZXJ0IHRoZSBURUFQIEVF IGNlcnQgaW4gaXRzIHZvdWNoZXIgcmVxdWVzdCwgd2l0aCB0aGUgVEVBUCBzZXJ2ZXIgYXNzZXJ0 aW5nIHRoZQ0KIFJB4oCZcyBjZXJ0IGluIGl0cyB2b3VjaGVyIHJlcXVlc3QuIFRoZSBNQVNBIGNv dWxkIGluIHRoZW9yeSB0aGVuIHZhbGlkYXRlIHRoZSBmdWxsIGNoYWluIG9mIHRydXN0IGJhY2su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5vdywgdGhhdOKAmXMgcmVh ZGluZyBhIGxvdCBpbnRvIHRoYXQgb25lIHN0YXRlbWVudCwgYW5kIHRoZSByZXN0IG9mIEJSU0tJ IGNlcnRhaW5seSBkb2VzbuKAmXQgZGVzY3JpYmUgb3BlcmF0aW9uIGxpa2UgdGhhdCwgYW5kIGl0 cyBmYXIgZWFzaWVyIHRvIG1hbmRhdGUgdGhhdCB0aGUgVEVBUCBzZXJ2ZXIgKjxiPmlzPC9iPiog dGhlIFJlZ2lzdHJhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgRU1VIGZvbGtz OiBpZiB0aGUgYW5zd2VyIGZyb20gdGhlIEJSU0tJIGZvbGtzIGlzIHRoYXQgdGhpcyBkb2Vzbid0 IHdvcmsgdGhlbiBpcyB0aGVyZSBhbnkgc29ydCBvZiB3ZWlyZCB0dW5uZWxpbmcgb3IgJnF1b3Q7 cGhhc2UgMiZxdW90OyB0cmlja2VyeSB0aGF0IGNhbiBiZSBhZGRlZCB0byBURUFQIHRvIGdldCB0 aGlzIHRvIHdvcmsgb3Igc2hvdWxkIHdlIGp1c3QgZXhwbGljaXRseSBzdGF0ZSB0aGF0IHRoZSBU RUFQDQogc2VydmVyIGFuZCB0aGUgcmVnaXN0cmFyIGFyZSB0aGUgc2FtZSBlbnRpdHkgKHRoZXkg YXV0aGVudGljYXRlIHdpdGggdGhlIHNhbWUgY2VydGlmaWNhdGUpPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsgRGFuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5FbXUgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48YSBocmVmPSJtYWlsdG86RW11QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+RW11QGlldGYub3JnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11Ij48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lbXU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DM6PR11MB3385E9075778EA632C6B289DDB130DM6PR11MB3385namp_-- From nobody Mon Jun 10 16:14:36 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C9120086 for ; Mon, 10 Jun 2019 16:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 TKxv3ToJCA0b for ; Mon, 10 Jun 2019 16:14:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C347120025 for ; Mon, 10 Jun 2019 16:14:30 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F86538187; Mon, 10 Jun 2019 19:13:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3D079EAE; Mon, 10 Jun 2019 19:14:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3A460BB8; Mon, 10 Jun 2019 19:14:29 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , Anima WG In-Reply-To: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 23:14:34 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: mcr> Brian suggested the example null vs nu11. mcr> This is not about super-cookies, etc. and it doesn't suggest any kind of mcr> process involving the list of publicsuffixes. ekr> The general shape of this kind of attack is that the attacker wants ekr> to impersonate A and so gets a domain with name A' that looks like ekr> A. However, this depends on A' being something the attacker can ekr> register. The public suffix list embodies the concept (more or less) ekr> of "anyone can register here". By contrast, a.example.com ekr> is (I assume) owned by example.com ekr> and so your average attacker can't do anything ekr> with b.example.com . bc> However, examp1e.com is 2001:470:1f07:1126::555:1212 or 64.57.183.2 so bc> we *really* can't use it. examp1e.net is 133.242.206.244 and actually bc> responds to HTTP. yes, some nice people have been sending example.* traffic to /dev/null. > You're right that in theory subdomains are unrealistic examples, but does that > matter for an illustrative example? Exactly. We are just trying to avoid c1sco.com / cisco.com as the example. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz+5FQACgkQgItw+93Q 3WU7aAgApZvMs0GZwkKpBHCIViRyRkKk6menX7LHM6XvA9lOkhpSQ8eeukOTQw4M v9RtfR/yb4/UnpOhrET6oAchzb49NNzcDc/dD5d5ZfodPVOQr4fMNnx1196Ny2p/ /Zl/Uy5CW5ovCC5NXToP22HsE99TonDTrz+5K8SOQESiRGpOl4Z0ymvzPqncnpGG 9zK8U+Bnh6+X3crbpzPYLrwYRE3FdY5raH4Yx8Tes57pFJF0g4I0gDd/O7QKXrNW 3LQLREd/eM3RlWsRoJ0dJ2OlvNnbde/q91ZEQi/Ylu6re2+2AYFD5ZU4rs+1/Dh6 j3K7vHBTMgtMaIRp1luXTz4oWCekQw== =SPqs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 10 16:15:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C679120025 for ; Mon, 10 Jun 2019 16:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 poKUjBVvLjlW for ; Mon, 10 Jun 2019 16:15:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41100120086 for ; Mon, 10 Jun 2019 16:15:05 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id BF5FD38187; Mon, 10 Jun 2019 19:13:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F0710EAE; Mon, 10 Jun 2019 19:15:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EED06BB8; Mon, 10 Jun 2019 19:15:03 -0400 (EDT) From: Michael Richardson To: Eric Rescorla , Anima WG In-Reply-To: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 23:15:06 -0000 --=-=-= Content-Type: text/plain Eric Rescorla wrote: >> You're right that in theory subdomains are unrealistic examples, but does >> that >> matter for an illustrative example? > Why not instead use two domain names that end in .example? E.g., > demo.example and dem0.example works for me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz+5HcACgkQgItw+93Q 3WWisQf+M/R7lDnE06ecs1BYB8dt5boW9EQxSnyW944aS4M5swsZcDNfM+C/TALf LJ0lyMYJDhu89yHOWF2mFMssVGDl9kNjINxwgkEBYOkCegYMUD9b4+G5sJLqkEbP QE5R849c8VZPFqRL4EmpZ76DGZtxgFphIUjErCeJKOcMB+/zy9bfqgz93gzmfQLU 9gFFdJCACqkXzsMys4FyFUVi0z8BqFlg3s2MSJokgmetdZHx+L1QZrVdm3rAisZW jUw+PqWjyakSMyw0VPvYcDCPb+Z8Aq38H6WHKrWKBgGzMCHBK4yt7wsqKyLwL70g U+c1kcp//nfFn0ZGBmQrKFVZ6Qpwrw== =GEHD -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 10 16:38:50 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B339120048 for ; Mon, 10 Jun 2019 16:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWUzBW385lg4 for ; Mon, 10 Jun 2019 16:38:47 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 BE7251200E5 for ; Mon, 10 Jun 2019 16:38:47 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id r7so302789pfl.3 for ; Mon, 10 Jun 2019 16:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=rdyGLM37iMVC4GjFxTSLIZD8nA7okmSJHcn6GjQaEJ8=; b=A+JWi2elMVWGKsC5IB2LWwpteIUeejP+BmUPrbh3C4ZLHcddF/JDvuF4uCiepx6u5X RV0fPYLXj/3YdX8CgJvMEsKc4pCSUxt09KWefXnwpKpVxzNDFg3+E/KbVdvzQGYWE3LF PuzJJ13EoWsQxJi1RmVQ85pjl6HC0OLVmDv8IUZfclwcO0PIuusstcE7QNsAXkNPIiL/ d2WMFW8QMt7j+GXfnQONvJovc1pKlF4C+R0RsWIr01YXNqLIh8csV9i1rmH4wMUhp4Oo qG3r15oCior19vc5sxKPGHgCo8QSCvacSXrx28xLKPq8mf5idvvBHR7jNggrV7CK1r+n hE6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rdyGLM37iMVC4GjFxTSLIZD8nA7okmSJHcn6GjQaEJ8=; b=oB/5KoV73Zi/1UGvFm+S50EoWThDxoxrHWJdxxyBVJpMpoOUpKp8+SVE2ZI4p2F9RX nZSuHklMdCRwFtmTG7An5nTnlg5mgAJYVwOj+z5SqCcW46VFLQaPwQkWIC/3tRYUvuMh p6ldFrK5GnSJE588UmuD9HFDBosal77O+979EjtVOqVKJzHYefKHVUFrd7NCJ5xItM3Y bWm3TMdDrY1fn5f1IoAUxLNCEeVblRccwOOOu4URfQLNtcW15ceWzBJ+6t4d7t1Mmgmm dadvVgwqodQg2C/mn5+F920IEY0HCUjDqyntsVCKMwkxQsljfjM9PXvZ4ClcAhpVKE4N 56dA== X-Gm-Message-State: APjAAAXGuEHGIeicjAVHE7PUinX0BeaoMy4iffOy/dfXPFa11gAAi0Bu jQFAH8t+4RPmieGT8r668o4EtOR4 X-Google-Smtp-Source: APXvYqwFfl2VbJYzfTbPeSBoLejGh8AFEz4chlw/gd5/N42eaVzP2HDCyY/2Cp58rmxcmaTyh5tOeA== X-Received: by 2002:a62:5cc6:: with SMTP id q189mr76723391pfb.114.1560209927032; Mon, 10 Jun 2019 16:38:47 -0700 (PDT) Received: from [130.216.36.115] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.115]) by smtp.gmail.com with ESMTPSA id x125sm15804824pfd.2.2019.06.10.16.38.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 16:38:46 -0700 (PDT) To: Michael Richardson , Eric Rescorla , Anima WG References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> <20970.1560208503@localhost> From: Brian E Carpenter Message-ID: <54faee93-9476-80f1-e16c-839af53ef066@gmail.com> Date: Tue, 11 Jun 2019 11:38:42 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20970.1560208503@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 23:38:49 -0000 On 11-Jun-19 11:15, Michael Richardson wrote: > > Eric Rescorla wrote: > >> You're right that in theory subdomains are unrealistic examples, but does > >> that > >> matter for an illustrative example? > > > Why not instead use two domain names that end in .example? E.g., > > demo.example and dem0.example > > works for me. Absolutely, I had forgotten that .example. was reserved by RFC2606. Brian From nobody Mon Jun 10 17:36:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226E11200C1 for ; Mon, 10 Jun 2019 17:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 Q0-hJ6_WG5Dy for ; Mon, 10 Jun 2019 17:36:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DE6D120094 for ; Mon, 10 Jun 2019 17:36:28 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id C970A38187; Mon, 10 Jun 2019 20:35:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2120BEAE; Mon, 10 Jun 2019 20:36:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1E3E0C0C; Mon, 10 Jun 2019 20:36:26 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Eric Rescorla , Anima WG In-Reply-To: <54faee93-9476-80f1-e16c-839af53ef066@gmail.com> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <6636.1560178188@localhost> <20970.1560208503@localhost> <54faee93-9476-80f1-e16c-839af53ef066@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: Mon, 10 Jun 2019 20:36:26 -0400 Message-ID: <11114.1560213386@localhost> Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 00:36:31 -0000 Brian E Carpenter wrote: >> Eric Rescorla wrote: >> >> You're right that in theory subdomains are unrealistic examples,= but does >> >> that >> >> matter for an illustrative example? >> >> > Why not instead use two domain names that end in .example? E.g., >> > demo.example and dem0.example >> >> works for me. > Absolutely, I had forgotten that .example. was reserved by RFC2606. I upcased "demO" so that it looks like "dem0". From nobody Mon Jun 10 18:02:13 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252ED1200C1; Mon, 10 Jun 2019 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGB3alRl65OX; Mon, 10 Jun 2019 18:02:08 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 594CA120048; Mon, 10 Jun 2019 18:02:08 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id x15so6310771pfq.0; Mon, 10 Jun 2019 18:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CXSl67vD/W9vJjDvHTOD4wWa+eFMiHCfOchdSLCn6I8=; b=EAnZAU9sfLHVtqdLoU3Cue6l2yJE8wPmUh3Kz4VukOhMVLHY211MMor+9sdTwtX/JN WtfhXtdDfDq1TXryXJy4IT3nw+WJtnse1f7fbAWb8YGBKaiRQgvVm+n+CRQq1uSKGZkY QAxL1ZQ7t56o7v/OuwRByaRmEutNC08PLXT84sAyw1D24OEeBfvvDRRX1Kn6Bs32EILF yu9HL5GrABjgdvddfH5jgvNgebXKU1V1+ZYA5L8L7tIwKy6olacb3bC0AnRrk5NLnGuM Wvk09ewN5aU1rRUqfmsj0FXH9bW/xLRXdNlYhT7LyIfcV9rrWzL5tDX/DUJ+2OF8Lj6v TRlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CXSl67vD/W9vJjDvHTOD4wWa+eFMiHCfOchdSLCn6I8=; b=tZ8iQjv5sCPKzEsK/ooezo3X5QNawBBOskyMYuIEaD7NqB3yPqO2aV655SeNBCM4/9 uhwoXzLdMDkYBuQ2miDt540VXDtRHup7AFElspHhVwr2ow4WwpQuEaAy/dvUEEXGkDmO IHHzC6F1fjj+gt0/RJXRAE2AyTqK4qHekaJBeR3Qtdw0p74a/yD7eGC6glHZhhqzhSYL rhedqff2xebIxXQma71JVQkJB56V6fjCuKZfeJAf2t44+KP+h+3rlj82lvH/ujUYwpEn q50K8cKEnNcJa2HbYfm60IKHXzIAR2JFgW+C9lqEyTgfFZOsWSf+iHEvvO+qK4N4S2Dt /aNw== X-Gm-Message-State: APjAAAVr1xIqt/p5fBZESPr82sHAk6HwrmbGszwo9dI6Df5HJx8GaVlz 2gl8zKrEKTAO6UITcHCaAJTNWw9z X-Google-Smtp-Source: APXvYqyEPRKSJy6LXqhKOHuBFyBzrkQOsYc0uGHU0bZlS9Hrn8Jh7iYNPKfdfUWi5zslx0//SEFt+g== X-Received: by 2002:aa7:80ce:: with SMTP id a14mr45934594pfn.249.1560214927385; Mon, 10 Jun 2019 18:02:07 -0700 (PDT) Received: from [130.216.36.115] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.115]) by smtp.gmail.com with ESMTPSA id g2sm26174342pfb.95.2019.06.10.18.02.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 18:02:06 -0700 (PDT) To: Alissa Cooper , The IESG Cc: anima-chairs@ietf.org, anima@ietf.org References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> Date: Tue, 11 Jun 2019 13:02:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 01:02:11 -0000 Hi all, I've taken the liberty of posting an update to the draft charter at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried to respond to all the IESG comments, and in particular: (a) I deleted Intent from the summarised reference model framework, since the reference model doesn't usefully define Intent. (b) I tried to make the statement about workload throttling more implementable. (c) I still think that the laundry list of *possible* work items is useful (it helps to define the scope) but I've tried make it clear that it is only the "indicative scope of possible work items". It really isn't mission creep; all the items mentioned relate directly to the ANI and AF topics. (d) I intentionally removed the reference to not covering machine learning and AI. It isn't suggested anywhere in the reference model, so why even mention it? (e) I fixed nits and tuned the wording in several places. I hope this helps. We really need a new charter before Montreal. WG Chairs and AD, over to you... Regards Brian Carpenter On 02-May-19 08:39, Brian E Carpenter wrote: > Hi Alissa, > > On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: > ... >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> (1) "Acceptance of work items by the WG will be scheduled/throttled so that >> contributors can target them to enter WG last call after not more than a number >> of IETF meeting cycles agreed by the AD." >> >> I don't understand the implications of this. What happens if the adopted work >> items have not entered WGLC after the agreed number of cycles? If the answer is >> anything other than "the WG abandons the work," I don't understand how this is >> a throttling mechanism. A throttling mechanism would need an explicit limit on >> the number of adopted work items at any one time, I think. > > I agree that the text is a bit illogical. In a sense it's unnecessary, because > every WG should be matching its workload to its capacity. Maybe that's all > we should say, rather than trying to describe a slightly vague algorithm? > >> (2) The proposed work items is a very large and somewhat unbounded list of >> items, whereas the purpose of writing a charter is to scope the work of the WG >> and hopefully set out a realistic work plan that will be accompanied by >> deployment. For a WG that has produced 5 documents in the last 5 years, I think >> the charter needs to more narrowly focus on the most highly prioritized work >> items. Once those are nearing completion, it seems as though evaluation of what >> is needed next based on deployment experience would then dictate the next set >> of items for another re-charter. > > I think the point here is that now that the relatively small number of > infrastructure documents are almost finished, the next stage opens up > the possibilities for a much wider range of work that builds on the > infrastructure. The priorities aren't even obvious. So this goes with > the previous point, and to quite some extent the criteria will be > whether the WG has capacity more than which topic has priority. > > That's why there's a bucket list of work items and a short list of > immediate milestones. > > Would this help? > > s/Proposed work items include.../Possible work items include.../ > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> It would be good to see milestones with dates before this gets approved. >> >> I think this charter would benefit from an English edit pass before going out for external review. > > I'll volunteer, when the open issues have been resolved. > >> What is "compounding environment"? > > An excellent question. > > Brian > From nobody Tue Jun 11 01:40:16 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343CE120108; Tue, 11 Jun 2019 01:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 R7qIN0iUnf3F; Tue, 11 Jun 2019 01:40:10 -0700 (PDT) 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 C43AA1200E3; Tue, 11 Jun 2019 01:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24680; q=dns/txt; s=iport; t=1560242410; x=1561452010; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=hTfyLV9s33enk7Q8md6xamrBpwrY+cRUrk2Tt9+Kp7k=; b=dF9eQWkLxblxFAn2g38MR4gmmnFw2hKGtXHryt5dfFA51wiUcT9nOaU1 6r1PhpPn+Y/9dgCUNhVwrDt5M0pAzI9sQz3K77qxu1T5ylLDeLCKmnuWy OSXa1WK5L1QiU1O3LwHNAz4lt7PkSqeJu6HfI5tyy7a/rcVrv1PXEHdN+ E=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAChZ/9c/xbLJq1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYJ6gQQohBWIe4wFmGEUgWcCBwEBAQk?= =?us-ascii?q?DAQEYAQwKAQGEQAKDGzYHDgEDAQEEAQECAQRtHAyFSgEBAQMBAQEhBEcLBQs?= =?us-ascii?q?LDgoVDgQDAgInHxEGE4MiAYF7Dw+oTn4zhDIBE0FAhGMQgTQBgU+HRIJggX+?= =?us-ascii?q?BEScfgkw+gmEBAQIBAYEYGwMPV4JLMoImBItwggeFPFaVIgmCEoIbgQaDI4x?= =?us-ascii?q?/G4IlaYYTg16KHY95hDCCRolbgwcCBAYFAhWBVggpKoEuMxoIGxU7KgGCDQE?= =?us-ascii?q?zCTWBWDCDOYUUhUE9AzCNLgINFweCDxYBAQ?= X-IronPort-AV: E=Sophos;i="5.63,578,1557187200"; d="asc'?scan'208,217";a="12968883" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2019 08:40:06 +0000 Received: from [10.61.194.73] ([10.61.194.73]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5B8e5jG025046 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Jun 2019 08:40:06 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E64CFF32-6C18-4696-990B-699F5EF58E2D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Jun 2019 10:40:03 +0200 In-Reply-To: Cc: Brian E Carpenter , Toerless Eckert , Ignas Bagdonas , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, Anima WG To: Eric Rescorla References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.194.73, [10.61.194.73] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 08:40:15 -0000 --Apple-Mail=_E64CFF32-6C18-4696-990B-699F5EF58E2D Content-Type: multipart/alternative; boundary="Apple-Mail=_9920DDB4-936B-4E35-AD21-ACEF72A39837" --Apple-Mail=_9920DDB4-936B-4E35-AD21-ACEF72A39837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi > On 10 Jun 2019, at 13:16, Eric Rescorla wrote: >=20 >=20 > That's a little unfortunate from the perspective of this attack = because .com is a public suffix [0] whereas example.com = is not. >=20 After a private exchange, I understand the nature of Eric's concern. The = issue is that you want to demonstrate separate administrative entities, = and subdomains generally wouldn=E2=80=99t that point clear. The problem = is that the obvious examp1e is already registered. Thoughts? Eliot > -Ekr >=20 > [0] https://publicsuffix.org/ >=20 > Brian >=20 > >> But taking your thought into account: There is a fundamental = difference > >> betwen TOFU and out-of-band-authentication/approval (pick a term), > >> and the fact that different such mechanisms may have (often human) > >> weaknesses does not change this fundamental difference ?? > > > > > > I think the key is that humans oughtn=E2=80=99t rely solely on a = visual inspection of whatever is presented in front of them, but rather = that they might rely on alternative inputs, such as recommendations made = by the registrar provider, or federated services. > > > > > >> > >> Maybe you want to propose text ? > > > > Manual approval by administrator or selection by administrator. > > > > Eliot > >> > >> Cheers > >> Toerless > >> > >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: > >>> Hi Toerless, > >>> > >>>> On 4 Jun 2019, at 21:28, Toerless Eckert > wrote: > >>>> > >>>> Thanks, Eliot, > >>>> > >>>> re-reading 10.3, my impression is: > >>>> > >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory = definition in 1.2. > >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add = value, the text > >>>> doesn't become IMHO worse if they are simply removed. And i am = sure > >>>> there can easily be similar non-cyptographic leap of faiths in = sales integration, > >>>> or consortium memberships trust chaing establishment. > >>> > >>> My point is that those are no longer leaps of faith. > >>> > >>> Eliot > >>> > >>>> > >>>> b) The text could IMHO be crisper: > >>>> > >>>> "will have no problem collaborating with it's MASA" -> > >>>> "will have no problem collaborating with it's malicious MASA" -> > >>>> > >>>> "the domain (registrar) still needs to trust the manufacturer" -> > >>>> "the domain (registrar) still needs to authenticate the MASA" ? > >>>> (i hope the latter is the correct interpretation of the text) > >>>> > >>>> Cheers > >>>> Toerless > >>>> > >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: > >>>>> Just on this text: > >>>>> > >>>>> In Section 10.3 the following text exists: > >>>>> > >>>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be = queried > >>>>> upon seeing a manufacturer's trust anchor for the first = time, and > >>>>> then the trust anchor would be installed to the trusted = store. > >>>>> There are risks with this; even if the key to name is = validated > >>>>> using something like the WebPKI, there remains the = possibility > >>>>> that the name is a look alike: e.g, c1sco.com = , .. > >>>>> > >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would = prefer that the term be replaced with something like "out-of-band = approval". This would also be a good area for certification services to = step in to indicate the trustworthiness of a manufacturer. > >>>>> > >>>>> Eliot > >>>>> > >>>>>> On 21 May 2019, at 23:21, The IESG > wrote: > >>>>>> > >>>>>> > >>>>>> The IESG has received a request from the Autonomic Networking = Integrated > >>>>>> Model and Approach WG (anima) to consider the following = document: - > >>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' > >>>>>> as Proposed = Standard > >>>>>> > >>>>>> This is a second Last Call. IoT Directorate review was done = after the ANIMA > >>>>>> WG Last Call and consensus to request the publication, and that = review resulted > >>>>>> in substantial changes to the document. > >>>>>> > >>>>>> The IESG plans to make a decision in the next few weeks, and = solicits final > >>>>>> comments on this action. Please send substantive comments to = the > >>>>>> ietf@ietf.org mailing lists by = 2019-06-04. Exceptionally, comments may be > >>>>>> sent to iesg@ietf.org instead. In either = case, please retain the beginning of > >>>>>> the Subject line to allow automated sorting. > >>>>>> > >>>>>> Abstract > >>>>>> > >>>>>> > >>>>>> This document specifies automated bootstrapping of an Autonomic > >>>>>> Control Plane. To do this a remote secure key infrastructure = (BRSKI) > >>>>>> is created using manufacturer installed X.509 certificate, in > >>>>>> combination with a manufacturer's authorizing service, both = online > >>>>>> and offline. Bootstrapping a new device can occur using a = routable > >>>>>> address and a cloud service, or using only link-local = connectivity, > >>>>>> or on limited/disconnected networks. Support for lower = security > >>>>>> models, including devices with minimal identity, is described = for > >>>>>> legacy reasons but not encouraged. Bootstrapping is complete = when > >>>>>> the cryptographic identity of the new key infrastructure is > >>>>>> successfully deployed to the device but the established secure > >>>>>> connection can be used to deploy a locally issued certificate = to the > >>>>>> device as well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The file can be obtained via > >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ = > >>>>>> > >>>>>> IESG discussion can be tracked via > >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/b= allot/ = > >>>>>> > >>>>>> The following IPR Declarations may be related to this I-D: > >>>>>> > >>>>>> https://datatracker.ietf.org/ipr/2816/ = > >>>>>> https://datatracker.ietf.org/ipr/3233/ = > >>>>>> https://datatracker.ietf.org/ipr/2463/ = > >>>>>> > >>>>>> > >>>>>> > >>>>>> The document contains these normative downward references. > >>>>>> See RFC 3967 for additional information: > >>>>>> rfc8368: Using an Autonomic Control Plane for Stable = Connectivity of Network Operations, Administration, and Maintenance = (OAM) (Informational - IETF stream) > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Anima mailing list > >>>>>> Anima@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/anima = > >>>>> > >>>> > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/anima = > >>>> > >>>> > >>>> -- > >>>> --- > >>>> tte@cs.fau.de > >>> > >> > >> > >> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima = > >> > >> > >> -- > >> --- > >> tte@cs.fau.de > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima = > > >=20 --Apple-Mail=_9920DDB4-936B-4E35-AD21-ACEF72A39837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi

On 10 Jun 2019, at 13:16, Eric Rescorla <ekr@rtfm.com> = wrote:


That's a = little unfortunate from the perspective of this attack because .com is a = public suffix [0] whereas example.com is not.



After a private = exchange, I understand the nature of Eric's concern. The issue is that = you want to demonstrate separate administrative entities, and subdomains = generally wouldn=E2=80=99t that point clear.  The problem is that = the obvious examp1e is already registered.  Thoughts?

Eliot

-Ekr

[0] https://publicsuffix.org/

    Brian

>> But taking your thought into account: There is a fundamental = difference
>> betwen TOFU and out-of-band-authentication/approval (pick a = term),
>> and the fact that different such mechanisms may have (often = human)
>> weaknesses does not change this fundamental difference ??
>
>
> I think the key is that humans oughtn=E2=80=99t rely solely on a = visual inspection of whatever is presented in front of them, but rather = that they might rely on alternative inputs, such as recommendations made = by the registrar provider, or federated services.
>
>
>>
>> Maybe you want to propose text ?
>
> Manual approval by administrator or selection by administrator.
>
> Eliot
>>
>> Cheers
>>   Toerless
>>
>> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>>> Hi Toerless,
>>>
>>>> On 4 Jun 2019, at 21:28, Toerless Eckert <tte@cs.fau.de> wrote:
>>>>
>>>> Thanks, Eliot,
>>>>
>>>> re-reading 10.3, my impression is:
>>>>
>>>> a) The use of TOFU in 10.3 seems to exceed the = explanatory definition in 1.2.
>>>> The sentence stubs in 103 mentioning TOFU also don't = seem to add value, the text
>>>> doesn't become IMHO worse if they are simply removed. = And i am sure
>>>> there can easily be similar non-cyptographic leap of = faiths in sales integration,
>>>> or consortium memberships trust chaing = establishment.
>>>
>>> My point is that those are no longer leaps of faith.
>>>
>>> Eliot
>>>
>>>>
>>>> b) The text could IMHO be crisper:
>>>>
>>>> "will have no problem collaborating with it's MASA" = ->
>>>> "will have no problem collaborating with it's malicious = MASA" ->
>>>>
>>>> "the domain (registrar) still needs to trust the = manufacturer" ->
>>>> "the domain (registrar) still needs to authenticate the = MASA" ?
>>>> (i hope the latter is the correct interpretation of the = text)
>>>>
>>>> Cheers
>>>>   Toerless
>>>>
>>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear = wrote:
>>>>> Just on this text:
>>>>>
>>>>> In Section 10.3 the following text exists:
>>>>>
>>>>>  o  A Trust-On-First-Use (TOFU) = mechanism.  A human would be queried
>>>>>     upon seeing a manufacturer's = trust anchor for the first time, and
>>>>>     then the trust anchor would be = installed to the trusted store.
>>>>>     There are risks with this; even = if the key to name is validated
>>>>>     using something like the WebPKI, = there remains the possibility
>>>>>     that the name is a look alike: = e.g, c1sco.com, ..
>>>>>
>>>>> First, this isn???t REALLY Trust-On-First-Use, and = I would prefer that the term be replaced with something like = "out-of-band approval".  This would also be a good area for = certification services to step in to indicate the trustworthiness of a = manufacturer.
>>>>>
>>>>> Eliot
>>>>>
>>>>>> On 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:
>>>>>>
>>>>>>
>>>>>> The IESG has received a request from the = Autonomic Networking Integrated
>>>>>> Model and Approach WG (anima) to consider the = following document: -
>>>>>> 'Bootstrapping Remote Secure Key = Infrastructures (BRSKI)'
>>>>>> = <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed = Standard
>>>>>>
>>>>>> This is a second Last Call. IoT Directorate = review was done after the ANIMA
>>>>>> WG Last Call and consensus to request the = publication, and that review resulted
>>>>>> in substantial changes to the document.
>>>>>>
>>>>>> The IESG plans to make a decision in the next = few weeks, and solicits final
>>>>>> comments on this action. Please send = substantive comments to the
>>>>>> ietf@ietf.org mailing lists by = 2019-06-04. Exceptionally, comments may be
>>>>>> sent to iesg@ietf.org instead. In either case, = please retain the beginning of
>>>>>> the Subject line to allow automated sorting.
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>>
>>>>>> This document specifies automated bootstrapping = of an Autonomic
>>>>>> Control Plane.  To do this a remote secure = key infrastructure (BRSKI)
>>>>>> is created using manufacturer installed X.509 = certificate, in
>>>>>> combination with a manufacturer's authorizing = service, both online
>>>>>> and offline.  Bootstrapping a new device = can occur using a routable
>>>>>> address and a cloud service, or using only = link-local connectivity,
>>>>>> or on limited/disconnected networks.  = Support for lower security
>>>>>> models, including devices with minimal = identity, is described for
>>>>>> legacy reasons but not encouraged.  = Bootstrapping is complete when
>>>>>> the cryptographic identity of the new key = infrastructure is
>>>>>> successfully deployed to the device but the = established secure
>>>>>> connection can be used to deploy a locally = issued certificate to the
>>>>>> device as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The file can be obtained via
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/
>>>>>>
>>>>>> IESG discussion can be tracked via
= >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/ballot/
>>>>>>
>>>>>> The following IPR Declarations may be related = to this I-D:
>>>>>>
>>>>>> https://datatracker.ietf.org/ipr/2816/ >>>>>> https://datatracker.ietf.org/ipr/3233/ >>>>>> https://datatracker.ietf.org/ipr/2463/ >>>>>>
>>>>>>
>>>>>>
>>>>>> The document contains these normative downward = references.
>>>>>> See RFC 3967 for additional information:
>>>>>>  rfc8368: Using an Autonomic Control Plane = for Stable Connectivity of Network Operations, Administration, and = Maintenance (OAM) (Informational - IETF stream)
>>>>>>
>>>>>>
>>>>>>
>>>>>> = _______________________________________________
>>>>>> Anima mailing list
>>>>>> Anima@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> Anima@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>
>>>>
>>>> --
>>>> ---
>>>> tte@cs.fau.de
>>>
>>
>>
>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>> --
>> ---
>> tte@cs.fau.de
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>


= --Apple-Mail=_9920DDB4-936B-4E35-AD21-ACEF72A39837-- --Apple-Mail=_E64CFF32-6C18-4696-990B-699F5EF58E2D 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlz/aOMACgkQh7ZrRtnS ejMa+AgAzJSiAhdQV0m//OI3yXx5oTxZsBqM8yb+oPBbYPUiXuFXrBjuGn71oqRw CsdSJ4xaZX7MYB9b6n2GG0ZaDHNHmlO8uF9tf+Z2lCe4T6oLjhKXy+IwAQJ1uF/P iRbWm+WPEs3blNYlmkNDG6z4e0ky1esgSuhUKpk12EKamKgl4QeqqYvmIVQgDsgM 0l5OoLBX98w+2na4ZHEnl/72Xqu84TaRs63RYN4LIgCSkjfnaKDoQl4Buv76kQUt WaeCKttl2H7lTqnPQZTtUQObr/S4KasHefjf1Lgd/VyQwKLbkqlJf4igia6AyHjE l7ttAYWIS4YYcc4W2iSGzBFqsNi5Rg== =SDOT -----END PGP SIGNATURE----- --Apple-Mail=_E64CFF32-6C18-4696-990B-699F5EF58E2D-- From nobody Tue Jun 11 04:34:19 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972A12011F; Tue, 11 Jun 2019 04:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 Y-uNfPopIzxy; Tue, 11 Jun 2019 04:34:16 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5974312004F; Tue, 11 Jun 2019 04:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5356; q=dns/txt; s=iport; t=1560252855; x=1561462455; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=bx0eROFUzFeNm0JnS1BUWAmqhqe1wrFhb7rK9ct3T/w=; b=j3N2prX8aM6ZernG7HlbYt7b7lnVk9AiqKzCDu7xfCDA8SEjsU47+qf3 uIjylgOR5h5CaBJaC8WGtxtefgL2Z3eLr9RQZ1Z7BtahyNy2kfG8jZQQF EBR1S3fNfb0nSOjR4U6XE0HblBdoXOjT/fiO1JGbfhXFn4wglKbBwVikm 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABdkf9c/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBZoEUUQEgEiiNEItgJX6IRY8eFIFnAgcBAQE?= =?us-ascii?q?JAwEBGAsMAQGEQAKDITYHDgEDAQEEAQECAQRtHAyFSgEBAQECAQEBawEGBQU?= =?us-ascii?q?LCxguIQYwBhODIgGBagMODw+qFoVHgkMNghMKBoE0AYFPiiSBf4ERJwwTghc?= =?us-ascii?q?1PoIaRwEBgTsOg1SCJgSLXA+II5RkPgmCEoIbgQaDJIkVg2sbgiWKXYoejj+?= =?us-ascii?q?Fa4Fkij+DBwIEBgUCFYFWBC2BWDMaCBsVOyoBgkE+gghuAQUCh1eFQT0DMAG?= =?us-ascii?q?NPoJRAQE?= X-IronPort-AV: E=Sophos;i="5.63,579,1557187200"; d="asc'?scan'208";a="13031947" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2019 11:34:13 +0000 Received: from [10.61.194.73] ([10.61.194.73]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x5BBYBpX004548 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Jun 2019 11:34:12 GMT From: Eliot Lear Message-Id: <2F845DEE-FCB1-4E28-9487-1BC3C8A72AEE@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8E26F357-5EC5-4456-8102-3C00BA99BFCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Jun 2019 13:34:09 +0200 In-Reply-To: <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> Cc: Alissa Cooper , The IESG , anima-chairs@ietf.org, anima@ietf.org To: Brian E Carpenter References: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> <37fbdddd-601d-e7ad-f582-3288ead2e752@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.194.73, [10.61.194.73] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] Alissa Cooper's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 11:34:18 -0000 --Apple-Mail=_8E26F357-5EC5-4456-8102-3C00BA99BFCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, I like what I see. This permits the pacing of work as we discussed = during the F2F in Prague with the area director, and allows for building = on the foundational work that is now completing. Eliot > On 11 Jun 2019, at 03:02, Brian E Carpenter = wrote: >=20 > Hi all, >=20 > I've taken the liberty of posting an update to the draft charter > at https://trac.ietf.org/trac/anima/wiki/Recharter2019. I tried > to respond to all the IESG comments, and in particular: >=20 > (a) I deleted Intent from the summarised reference model framework, > since the reference model doesn't usefully define Intent. >=20 > (b) I tried to make the statement about workload throttling more > implementable. >=20 > (c) I still think that the laundry list of *possible* work items > is useful (it helps to define the scope) but I've tried make it > clear that it is only the "indicative scope of possible work items". > It really isn't mission creep; all the items mentioned relate > directly to the ANI and AF topics. >=20 > (d) I intentionally removed the reference to not covering machine > learning and AI. It isn't suggested anywhere in the reference model, > so why even mention it? >=20 > (e) I fixed nits and tuned the wording in several places. >=20 > I hope this helps. We really need a new charter before Montreal. > WG Chairs and AD, over to you... >=20 > Regards > Brian Carpenter >=20 > On 02-May-19 08:39, Brian E Carpenter wrote: >> Hi Alissa, >>=20 >> On 02-May-19 08:05, Alissa Cooper via Datatracker wrote: >> ... >>> = ---------------------------------------------------------------------- >>> BLOCK: >>> = ---------------------------------------------------------------------- >>>=20 >>> (1) "Acceptance of work items by the WG will be scheduled/throttled = so that >>> contributors can target them to enter WG last call after not more = than a number >>> of IETF meeting cycles agreed by the AD." >>>=20 >>> I don't understand the implications of this. What happens if the = adopted work >>> items have not entered WGLC after the agreed number of cycles? If = the answer is >>> anything other than "the WG abandons the work," I don't understand = how this is >>> a throttling mechanism. A throttling mechanism would need an = explicit limit on >>> the number of adopted work items at any one time, I think. >>=20 >> I agree that the text is a bit illogical. In a sense it's = unnecessary, because >> every WG should be matching its workload to its capacity. Maybe = that's all >> we should say, rather than trying to describe a slightly vague = algorithm? >>=20 >>> (2) The proposed work items is a very large and somewhat unbounded = list of >>> items, whereas the purpose of writing a charter is to scope the work = of the WG >>> and hopefully set out a realistic work plan that will be accompanied = by >>> deployment. For a WG that has produced 5 documents in the last 5 = years, I think >>> the charter needs to more narrowly focus on the most highly = prioritized work >>> items. Once those are nearing completion, it seems as though = evaluation of what >>> is needed next based on deployment experience would then dictate the = next set >>> of items for another re-charter. >>=20 >> I think the point here is that now that the relatively small number = of >> infrastructure documents are almost finished, the next stage opens up >> the possibilities for a much wider range of work that builds on the >> infrastructure. The priorities aren't even obvious. So this goes with >> the previous point, and to quite some extent the criteria will be >> whether the WG has capacity more than which topic has priority. >>=20 >> That's why there's a bucket list of work items and a short list of >> immediate milestones. >>=20 >> Would this help? >>=20 >> s/Proposed work items include.../Possible work items include.../ >>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> It would be good to see milestones with dates before this gets = approved. >>>=20 >>> I think this charter would benefit from an English edit pass before = going out for external review. >>=20 >> I'll volunteer, when the open issues have been resolved. >>=20 >>> What is "compounding environment"? >>=20 >> An excellent question. >>=20 >> Brian >>=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_8E26F357-5EC5-4456-8102-3C00BA99BFCE 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXP+RsQAKCRBugA9nE248 uC7iAKCUsxSZ7Bo6iI+yGuTXughg/KbuvgCffqv0/Lm+JP0uP0CUr1g5Qnk+qGI= =m7Nr -----END PGP SIGNATURE----- --Apple-Mail=_8E26F357-5EC5-4456-8102-3C00BA99BFCE-- From nobody Tue Jun 11 04:40:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A8120180 for ; Tue, 11 Jun 2019 04:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzrftcrLOUg9 for ; Tue, 11 Jun 2019 04:39:53 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 BC0B3120144 for ; Tue, 11 Jun 2019 04:39:49 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id p24so9046412lfo.6 for ; Tue, 11 Jun 2019 04:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VYfMAWp7sO1GfgTPpDUfxFAAVK+471hMiwpaj0b8XpA=; b=Cg6nH17wS5fmIj5W8SKSbN5aJE9zZ+1h/J9ZWJwgBkXimA8iHhQZ2bjmrvzM7hBi7+ drKQDoOWvyoZmnYY1MnQSiuO+eSPn699iJfJ8GYoTd7B1zUaKBsvNa6GWy1CoFuKVL8l 6/jEpzcv5qTHRrO8kkedrbmHbx7FVaqhxMIJJ4Nlwklche2UiWQ6jyaZzwvI7xzBaukx alMqnqJpuxpvO3JZ9gxo62+JeLjzK0qIA5g7XUev+4qWVPAw7ZWh0mkbr4535lE9Scsz /Egt2nXExyYZfU/LI2lbIdP7p6vXBPiWW83kFw2OK3DYNN840/KEitLPiCustWNSHJFV 5smg== 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=VYfMAWp7sO1GfgTPpDUfxFAAVK+471hMiwpaj0b8XpA=; b=RG5TEjkTDzK3bzvLjQqTxPx5xjjOFjKQCwvrfVxSUg/WDg9ZRH7giMxiSqhNLn4XPp jDTk57owLxwXWhATxdu+Plp/793itR/eRcR6tzYz83AG0ZB0oBV60cYIGoJ/Ei73c87E h/Ur/fOkoBnnGksYlzHb2QjTGFAQhFgQKfFHmf5w3oVM8V0C4rUZ7r/sbcbCVRcYqZCJ /ju7KEgbWDv1FdpyyDbecFu5tAS9GlltVkhuh5YVa6ciMK/3FDL6Yk3dgqNQAr2VV8rW j0babmUFDhFIKBxqdVE5jtFDhHLD/Io+cqZYNI5gAV0z1txBWGrUQawORke8Wukw45e4 DRgQ== X-Gm-Message-State: APjAAAXDPqRJVUMjX0d9uCTyU4kCV4knvok/ttMcsls77xQDxxQCI3QH VYp+sQI3yNqf0qknIWxnekPrAS3A6COda7CqOuktIg== X-Google-Smtp-Source: APXvYqxB5vppFSOTnkyWnn0LW6fOzDDeeA1ifYgUNQ23pfw590GT43uljI5Zol50ylaRqNFb26PFqq+BNqi83Ai31mk= X-Received: by 2002:ac2:5922:: with SMTP id v2mr37286489lfi.180.1560253187971; Tue, 11 Jun 2019 04:39:47 -0700 (PDT) MIME-Version: 1.0 References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> In-Reply-To: From: Eric Rescorla Date: Tue, 11 Jun 2019 04:39:11 -0700 Message-ID: To: Eliot Lear Cc: Brian E Carpenter , Toerless Eckert , Ignas Bagdonas , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, Anima WG Content-Type: multipart/alternative; boundary="000000000000077652058b0ac124" Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 11:40:04 -0000 --000000000000077652058b0ac124 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I mentioned in another email exchange, why not use two domains under .example? On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear wrote: > Hi > > On 10 Jun 2019, at 13:16, Eric Rescorla wrote: > > > That's a little unfortunate from the perspective of this attack because > .com is a public suffix [0] whereas example.com is not. > > > > After a private exchange, I understand the nature of Eric's concern. The > issue is that you want to demonstrate separate administrative entities, a= nd > subdomains generally wouldn=E2=80=99t that point clear. The problem is t= hat the > obvious examp1e is already registered. Thoughts? > > Eliot > > -Ekr > > [0] https://publicsuffix.org/ > >> >> Brian >> >> >> But taking your thought into account: There is a fundamental differen= ce >> >> betwen TOFU and out-of-band-authentication/approval (pick a term), >> >> and the fact that different such mechanisms may have (often human) >> >> weaknesses does not change this fundamental difference ?? >> > >> > >> > I think the key is that humans oughtn=E2=80=99t rely solely on a visua= l >> inspection of whatever is presented in front of them, but rather that th= ey >> might rely on alternative inputs, such as recommendations made by the >> registrar provider, or federated services. >> > >> > >> >> >> >> Maybe you want to propose text ? >> > >> > Manual approval by administrator or selection by administrator. >> > >> > Eliot >> >> >> >> Cheers >> >> Toerless >> >> >> >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: >> >>> Hi Toerless, >> >>> >> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert wrote: >> >>>> >> >>>> Thanks, Eliot, >> >>>> >> >>>> re-reading 10.3, my impression is: >> >>>> >> >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory >> definition in 1.2. >> >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add >> value, the text >> >>>> doesn't become IMHO worse if they are simply removed. And i am sure >> >>>> there can easily be similar non-cyptographic leap of faiths in sale= s >> integration, >> >>>> or consortium memberships trust chaing establishment. >> >>> >> >>> My point is that those are no longer leaps of faith. >> >>> >> >>> Eliot >> >>> >> >>>> >> >>>> b) The text could IMHO be crisper: >> >>>> >> >>>> "will have no problem collaborating with it's MASA" -> >> >>>> "will have no problem collaborating with it's malicious MASA" -> >> >>>> >> >>>> "the domain (registrar) still needs to trust the manufacturer" -> >> >>>> "the domain (registrar) still needs to authenticate the MASA" ? >> >>>> (i hope the latter is the correct interpretation of the text) >> >>>> >> >>>> Cheers >> >>>> Toerless >> >>>> >> >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >> >>>>> Just on this text: >> >>>>> >> >>>>> In Section 10.3 the following text exists: >> >>>>> >> >>>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be queri= ed >> >>>>> upon seeing a manufacturer's trust anchor for the first time, >> and >> >>>>> then the trust anchor would be installed to the trusted store. >> >>>>> There are risks with this; even if the key to name is validate= d >> >>>>> using something like the WebPKI, there remains the possibility >> >>>>> that the name is a look alike: e.g, c1sco.com, .. >> >>>>> >> >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would prefer >> that the term be replaced with something like "out-of-band approval". T= his >> would also be a good area for certification services to step in to indic= ate >> the trustworthiness of a manufacturer. >> >>>>> >> >>>>> Eliot >> >>>>> >> >>>>>> On 21 May 2019, at 23:21, The IESG >> wrote: >> >>>>>> >> >>>>>> >> >>>>>> The IESG has received a request from the Autonomic Networking >> Integrated >> >>>>>> Model and Approach WG (anima) to consider the following document:= - >> >>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' >> >>>>>> as Proposed >> Standard >> >>>>>> >> >>>>>> This is a second Last Call. IoT Directorate review was done after >> the ANIMA >> >>>>>> WG Last Call and consensus to request the publication, and that >> review resulted >> >>>>>> in substantial changes to the document. >> >>>>>> >> >>>>>> The IESG plans to make a decision in the next few weeks, and >> solicits final >> >>>>>> comments on this action. Please send substantive comments to the >> >>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, >> comments may be >> >>>>>> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >> >>>>>> the Subject line to allow automated sorting. >> >>>>>> >> >>>>>> Abstract >> >>>>>> >> >>>>>> >> >>>>>> This document specifies automated bootstrapping of an Autonomic >> >>>>>> Control Plane. To do this a remote secure key infrastructure >> (BRSKI) >> >>>>>> is created using manufacturer installed X.509 certificate, in >> >>>>>> combination with a manufacturer's authorizing service, both onlin= e >> >>>>>> and offline. Bootstrapping a new device can occur using a routab= le >> >>>>>> address and a cloud service, or using only link-local connectivit= y, >> >>>>>> or on limited/disconnected networks. Support for lower security >> >>>>>> models, including devices with minimal identity, is described for >> >>>>>> legacy reasons but not encouraged. Bootstrapping is complete whe= n >> >>>>>> the cryptographic identity of the new key infrastructure is >> >>>>>> successfully deployed to the device but the established secure >> >>>>>> connection can be used to deploy a locally issued certificate to >> the >> >>>>>> device as well. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The file can be obtained via >> >>>>>> >> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra= / >> >>>>>> >> >>>>>> IESG discussion can be tracked via >> >>>>>> >> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra= /ballot/ >> >>>>>> >> >>>>>> The following IPR Declarations may be related to this I-D: >> >>>>>> >> >>>>>> https://datatracker.ietf.org/ipr/2816/ >> >>>>>> https://datatracker.ietf.org/ipr/3233/ >> >>>>>> https://datatracker.ietf.org/ipr/2463/ >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The document contains these normative downward references. >> >>>>>> See RFC 3967 for additional information: >> >>>>>> rfc8368: Using an Autonomic Control Plane for Stable Connectivit= y >> of Network Operations, Administration, and Maintenance (OAM) (Informatio= nal >> - IETF stream) >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Anima mailing list >> >>>>>> Anima@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>>> _______________________________________________ >> >>>>> Anima mailing list >> >>>>> Anima@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>> >> >>>> >> >>>> -- >> >>>> --- >> >>>> tte@cs.fau.de >> >>> >> >> >> >> >> >> >> >>> _______________________________________________ >> >>> Anima mailing list >> >>> Anima@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> >> >> >> -- >> >> --- >> >> tte@cs.fau.de >> > >> > _______________________________________________ >> > Anima mailing list >> > Anima@ietf.org >> > https://www.ietf.org/mailman/listinfo/anima >> > >> >> > --000000000000077652058b0ac124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I mentioned in another email exchange, why not use two = domains under .example?

On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <<= a href=3D"mailto:lear@cisco.com">lear@cisco.com> wrote:
H= i

On 10 Jun 2019, at 13:16, Eric= Rescorla <ekr@rtfm.co= m> wrote:


That's a little unfortunate from the perspective of = this attack because .com is a public suffix [0] whereas example.com is not.

<= /div>


Afte= r a private exchange, I understand the nature of Eric's concern. The is= sue is that you want to demonstrate separate administrative entities, and s= ubdomains generally wouldn=E2=80=99t that point clear.=C2=A0 The problem is= that the obvious examp1e is already registered.=C2=A0 Thoughts?
=
Eliot

-Ekr


=C2=A0 =C2=A0 Brian

>> But taking your thought into account: There is a fundamental diffe= rence
>> betwen TOFU and out-of-band-authentication/approval (pick a term),=
>> and the fact that different such mechanisms may have (often human)=
>> weaknesses does not change this fundamental difference ??
>
>
> I think the key is that humans oughtn=E2=80=99t rely solely on a visua= l inspection of whatever is presented in front of them, but rather that the= y might rely on alternative inputs, such as recommendations made by the reg= istrar provider, or federated services.
>
>
>>
>> Maybe you want to propose text ?
>
> Manual approval by administrator or selection by administrator.
>
> Eliot
>>
>> Cheers
>>=C2=A0 =C2=A0Toerless
>>
>> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>>> Hi Toerless,
>>>
>>>> On 4 Jun 2019, at 21:28, Toerless Eckert <tte@cs.fau.de> wrote:
>>>>
>>>> Thanks, Eliot,
>>>>
>>>> re-reading 10.3, my impression is:
>>>>
>>>> a) The use of TOFU in 10.3 seems to exceed the explanatory= definition in 1.2.
>>>> The sentence stubs in 103 mentioning TOFU also don't s= eem to add value, the text
>>>> doesn't become IMHO worse if they are simply removed. = And i am sure
>>>> there can easily be similar non-cyptographic leap of faith= s in sales integration,
>>>> or consortium memberships trust chaing establishment.
>>>
>>> My point is that those are no longer leaps of faith.
>>>
>>> Eliot
>>>
>>>>
>>>> b) The text could IMHO be crisper:
>>>>
>>>> "will have no problem collaborating with it's MAS= A" ->
>>>> "will have no problem collaborating with it's mal= icious MASA" ->
>>>>
>>>> "the domain (registrar) still needs to trust the manu= facturer" ->
>>>> "the domain (registrar) still needs to authenticate t= he MASA" ?
>>>> (i hope the latter is the correct interpretation of the te= xt)
>>>>
>>>> Cheers
>>>>=C2=A0 =C2=A0Toerless
>>>>
>>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote= :
>>>>> Just on this text:
>>>>>
>>>>> In Section 10.3 the following text exists:
>>>>>
>>>>>=C2=A0 o=C2=A0 A Trust-On-First-Use (TOFU) mechanism.= =C2=A0 A human would be queried
>>>>>=C2=A0 =C2=A0 =C2=A0upon seeing a manufacturer's tr= ust anchor for the first time, and
>>>>>=C2=A0 =C2=A0 =C2=A0then the trust anchor would be inst= alled to the trusted store.
>>>>>=C2=A0 =C2=A0 =C2=A0There are risks with this; even if = the key to name is validated
>>>>>=C2=A0 =C2=A0 =C2=A0using something like the WebPKI, th= ere remains the possibility
>>>>>=C2=A0 =C2=A0 =C2=A0that the name is a look alike: e.g,= c1sco.c= om, ..
>>>>>
>>>>> First, this isn???t REALLY Trust-On-First-Use, and I w= ould prefer that the term be replaced with something like "out-of-band= approval".=C2=A0 This would also be a good area for certification ser= vices to step in to indicate the trustworthiness of a manufacturer.
>>>>>
>>>>> Eliot
>>>>>
>>>>>> On 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:
>>>>>>
>>>>>>
>>>>>> The IESG has received a request from the Autonomic= Networking Integrated
>>>>>> Model and Approach WG (anima) to consider the foll= owing document: -
>>>>>> 'Bootstrapping Remote Secure Key Infrastructur= es (BRSKI)'
>>>>>> <draft-ietf-anima-bootstrapping-keyinfra-20.txt= > as Proposed Standard
>>>>>>
>>>>>> This is a second Last Call. IoT Directorate review= was done after the ANIMA
>>>>>> WG Last Call and consensus to request the publicat= ion, and that review resulted
>>>>>> in substantial changes to the document.
>>>>>>
>>>>>> The IESG plans to make a decision in the next few = weeks, and solicits final
>>>>>> comments on this action. Please send substantive c= omments to the
>>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally, comments may= be
>>>>>> sent to iesg@ietf.org instead. In either case, please retain the begin= ning of
>>>>>> the Subject line to allow automated sorting.
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>>
>>>>>> This document specifies automated bootstrapping of= an Autonomic
>>>>>> Control Plane.=C2=A0 To do this a remote secure ke= y infrastructure (BRSKI)
>>>>>> is created using manufacturer installed X.509 cert= ificate, in
>>>>>> combination with a manufacturer's authorizing = service, both online
>>>>>> and offline.=C2=A0 Bootstrapping a new device can = occur using a routable
>>>>>> address and a cloud service, or using only link-lo= cal connectivity,
>>>>>> or on limited/disconnected networks.=C2=A0 Support= for lower security
>>>>>> models, including devices with minimal identity, i= s described for
>>>>>> legacy reasons but not encouraged.=C2=A0 Bootstrap= ping is complete when
>>>>>> the cryptographic identity of the new key infrastr= ucture is
>>>>>> successfully deployed to the device but the establ= ished secure
>>>>>> connection can be used to deploy a locally issued = certificate to the
>>>>>> device as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The file can be obtained via
>>>>>> ht= tps://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/=
>>>>>>
>>>>>> IESG discussion can be tracked via
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinf= ra/ballot/
>>>>>>
>>>>>> The following IPR Declarations may be related to t= his I-D:
>>>>>>
>>>>>> https://datatracker.ietf.org/ipr/2816= /
>>>>>> https://datatracker.ietf.org/ipr/3233= /
>>>>>> https://datatracker.ietf.org/ipr/2463= /
>>>>>>
>>>>>>
>>>>>>
>>>>>> The document contains these normative downward ref= erences.
>>>>>> See RFC 3967 for additional information:
>>>>>>=C2=A0 rfc8368: Using an Autonomic Control Plane fo= r Stable Connectivity of Network Operations, Administration, and Maintenanc= e (OAM) (Informational - IETF stream)
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> Anima mailing list
>>>>>> Anima@ietf.org
>>>>>> https://www.ietf.org/mailman/lis= tinfo/anima
>>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> An= ima@ietf.org
>>>>> https://www.ietf.org/mailman/listinf= o/anima
>>>>
>>>>
>>>> --
>>>> ---
>>>> tte@cs.= fau.de
>>>
>>
>>
>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/anima<= /a>
>>
>>
>> --
>> ---
>> tte@cs.fau.de
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima
>


--000000000000077652058b0ac124-- From nobody Tue Jun 11 05:00:35 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4793312004F; Tue, 11 Jun 2019 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 LxppmrnLxH-6; Tue, 11 Jun 2019 05:00:24 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FB1120043; Tue, 11 Jun 2019 05:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26208; q=dns/txt; s=iport; t=1560254424; x=1561464024; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=UOcA45UoGSIHZn49+pRinck0oITkW27KuzGSUZCTh/o=; b=L6m/q8BB7HWOy0HsXK2xljCDm/6hDW3TPCgVC/OPRCzt7i5zIuZ/xl2l wn8cNbJoiOru4HLbK1Q/VR9oFbswqR/3h1q3Rzxo/RDjgvJJgX0ZbvW74 6ORj7biGPf1HM1NqfGeCAiSk06Vh92AdBh0+m0esFNSIDoYmnExyE73BV w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABHl/9c/xbLJq1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYJ6UQEgEiiEFYh7i2AlmGEUgWcCBwE?= =?us-ascii?q?BAQkDAQEYAQwKAQGEQAKDITYHDgEDAQEEAQECAQRtHAyFSgEBAQECAQEBIQR?= =?us-ascii?q?HCwULCw4KFQsDBAMCAicfEQYTgyIBgXsPD6hqfjOEMgETQUCEYhCBNAGBT4d?= =?us-ascii?q?EgmCBf4ERJwwTgkw+gmEBAQIBAYEYEgEIAwcBB1eCSzKCJgSLcoIHhT9WlSI?= =?us-ascii?q?JghKCG4EGgySNABuCJWmGFINgih6PeoQwgkeJXIMHAgQGBQIVgVYFLCo9cTM?= =?us-ascii?q?aCBsVOyoBgg0BMwk1gVgwgzmFFIVBPQMwjT4CDRcHgg8WAQE?= X-IronPort-AV: E=Sophos;i="5.63,579,1557187200"; d="asc'?scan'208,217";a="13032472" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2019 12:00:21 +0000 Received: from [10.61.194.73] ([10.61.194.73]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5BC0KpG001335 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Jun 2019 12:00:20 GMT From: Eliot Lear Message-Id: <93C9118A-994C-4311-8882-D7AF9EEC1548@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FF328D14-8BDE-45F0-866C-0D5680C57B94"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Jun 2019 14:00:18 +0200 In-Reply-To: Cc: Brian E Carpenter , Toerless Eckert , Ignas Bagdonas , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list , anima-chairs@ietf.org, Anima WG To: Eric Rescorla References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.194.73, [10.61.194.73] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 12:00:27 -0000 --Apple-Mail=_FF328D14-8BDE-45F0-866C-0D5680C57B94 Content-Type: multipart/alternative; boundary="Apple-Mail=_E179AF7B-6F23-4E7E-89E0-FFF3C2C2A461" --Apple-Mail=_E179AF7B-6F23-4E7E-89E0-FFF3C2C2A461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jun 2019, at 13:39, Eric Rescorla wrote: >=20 > As I mentioned in another email exchange, why not use two domains = under .example? I missed that. That would be fine with a good example. Eliot >=20 > On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear > wrote: > Hi >=20 >> On 10 Jun 2019, at 13:16, Eric Rescorla > wrote: >>=20 >>=20 >> That's a little unfortunate from the perspective of this attack = because .com is a public suffix [0] whereas example.com = is not. >>=20 >=20 >=20 > After a private exchange, I understand the nature of Eric's concern. = The issue is that you want to demonstrate separate administrative = entities, and subdomains generally wouldn=E2=80=99t that point clear. = The problem is that the obvious examp1e is already registered. = Thoughts? >=20 > Eliot >=20 >> -Ekr >>=20 >> [0] https://publicsuffix.org/ >>=20 >> Brian >>=20 >> >> But taking your thought into account: There is a fundamental = difference >> >> betwen TOFU and out-of-band-authentication/approval (pick a term), >> >> and the fact that different such mechanisms may have (often human) >> >> weaknesses does not change this fundamental difference ?? >> > >> > >> > I think the key is that humans oughtn=E2=80=99t rely solely on a = visual inspection of whatever is presented in front of them, but rather = that they might rely on alternative inputs, such as recommendations made = by the registrar provider, or federated services. >> > >> > >> >> >> >> Maybe you want to propose text ? >> > >> > Manual approval by administrator or selection by administrator. >> > >> > Eliot >> >> >> >> Cheers >> >> Toerless >> >> >> >> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote: >> >>> Hi Toerless, >> >>> >> >>>> On 4 Jun 2019, at 21:28, Toerless Eckert > wrote: >> >>>> >> >>>> Thanks, Eliot, >> >>>> >> >>>> re-reading 10.3, my impression is: >> >>>> >> >>>> a) The use of TOFU in 10.3 seems to exceed the explanatory = definition in 1.2. >> >>>> The sentence stubs in 103 mentioning TOFU also don't seem to add = value, the text >> >>>> doesn't become IMHO worse if they are simply removed. And i am = sure >> >>>> there can easily be similar non-cyptographic leap of faiths in = sales integration, >> >>>> or consortium memberships trust chaing establishment. >> >>> >> >>> My point is that those are no longer leaps of faith. >> >>> >> >>> Eliot >> >>> >> >>>> >> >>>> b) The text could IMHO be crisper: >> >>>> >> >>>> "will have no problem collaborating with it's MASA" -> >> >>>> "will have no problem collaborating with it's malicious MASA" -> >> >>>> >> >>>> "the domain (registrar) still needs to trust the manufacturer" = -> >> >>>> "the domain (registrar) still needs to authenticate the MASA" ? >> >>>> (i hope the latter is the correct interpretation of the text) >> >>>> >> >>>> Cheers >> >>>> Toerless >> >>>> >> >>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote: >> >>>>> Just on this text: >> >>>>> >> >>>>> In Section 10.3 the following text exists: >> >>>>> >> >>>>> o A Trust-On-First-Use (TOFU) mechanism. A human would be = queried >> >>>>> upon seeing a manufacturer's trust anchor for the first = time, and >> >>>>> then the trust anchor would be installed to the trusted = store. >> >>>>> There are risks with this; even if the key to name is = validated >> >>>>> using something like the WebPKI, there remains the = possibility >> >>>>> that the name is a look alike: e.g, c1sco.com = , .. >> >>>>> >> >>>>> First, this isn???t REALLY Trust-On-First-Use, and I would = prefer that the term be replaced with something like "out-of-band = approval". This would also be a good area for certification services to = step in to indicate the trustworthiness of a manufacturer. >> >>>>> >> >>>>> Eliot >> >>>>> >> >>>>>> On 21 May 2019, at 23:21, The IESG > wrote: >> >>>>>> >> >>>>>> >> >>>>>> The IESG has received a request from the Autonomic Networking = Integrated >> >>>>>> Model and Approach WG (anima) to consider the following = document: - >> >>>>>> 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)' >> >>>>>> as Proposed = Standard >> >>>>>> >> >>>>>> This is a second Last Call. IoT Directorate review was done = after the ANIMA >> >>>>>> WG Last Call and consensus to request the publication, and = that review resulted >> >>>>>> in substantial changes to the document. >> >>>>>> >> >>>>>> The IESG plans to make a decision in the next few weeks, and = solicits final >> >>>>>> comments on this action. Please send substantive comments to = the >> >>>>>> ietf@ietf.org mailing lists by = 2019-06-04. Exceptionally, comments may be >> >>>>>> sent to iesg@ietf.org instead. In = either case, please retain the beginning of >> >>>>>> the Subject line to allow automated sorting. >> >>>>>> >> >>>>>> Abstract >> >>>>>> >> >>>>>> >> >>>>>> This document specifies automated bootstrapping of an = Autonomic >> >>>>>> Control Plane. To do this a remote secure key infrastructure = (BRSKI) >> >>>>>> is created using manufacturer installed X.509 certificate, in >> >>>>>> combination with a manufacturer's authorizing service, both = online >> >>>>>> and offline. Bootstrapping a new device can occur using a = routable >> >>>>>> address and a cloud service, or using only link-local = connectivity, >> >>>>>> or on limited/disconnected networks. Support for lower = security >> >>>>>> models, including devices with minimal identity, is described = for >> >>>>>> legacy reasons but not encouraged. Bootstrapping is complete = when >> >>>>>> the cryptographic identity of the new key infrastructure is >> >>>>>> successfully deployed to the device but the established secure >> >>>>>> connection can be used to deploy a locally issued certificate = to the >> >>>>>> device as well. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The file can be obtained via >> >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ = >> >>>>>> >> >>>>>> IESG discussion can be tracked via >> >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/b= allot/ = >> >>>>>> >> >>>>>> The following IPR Declarations may be related to this I-D: >> >>>>>> >> >>>>>> https://datatracker.ietf.org/ipr/2816/ = >> >>>>>> https://datatracker.ietf.org/ipr/3233/ = >> >>>>>> https://datatracker.ietf.org/ipr/2463/ = >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The document contains these normative downward references. >> >>>>>> See RFC 3967 for additional information: >> >>>>>> rfc8368: Using an Autonomic Control Plane for Stable = Connectivity of Network Operations, Administration, and Maintenance = (OAM) (Informational - IETF stream) >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Anima mailing list >> >>>>>> Anima@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/anima = >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>>> _______________________________________________ >> >>>>> Anima mailing list >> >>>>> Anima@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/anima = >> >>>> >> >>>> >> >>>> -- >> >>>> --- >> >>>> tte@cs.fau.de >> >>> >> >> >> >> >> >> >> >>> _______________________________________________ >> >>> Anima mailing list >> >>> Anima@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/anima = >> >> >> >> >> >> -- >> >> --- >> >> tte@cs.fau.de >> > >> > _______________________________________________ >> > Anima mailing list >> > Anima@ietf.org >> > https://www.ietf.org/mailman/listinfo/anima = >> > >>=20 >=20 --Apple-Mail=_E179AF7B-6F23-4E7E-89E0-FFF3C2C2A461 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Jun 2019, at 13:39, Eric Rescorla <ekr@rtfm.com> = wrote:

As I mentioned in another email = exchange, why not use two domains under .example?

I missed = that.  That would be fine with a good example.

Eliot


On Tue, Jun = 11, 2019 at 1:40 AM Eliot Lear <lear@cisco.com> wrote:
Hi

On 10 Jun 2019, at 13:16, Eric Rescorla <ekr@rtfm.com> wrote:


That's a = little unfortunate from the perspective of this attack because .com is a = public suffix [0] whereas example.com is not.



After a private exchange, I understand the nature of Eric's = concern. The issue is that you want to demonstrate separate = administrative entities, and subdomains generally wouldn=E2=80=99t that = point clear.  The problem is that the obvious examp1e is already = registered.  Thoughts?

Eliot

-Ekr

[0] https://publicsuffix.org/

    Brian

>> But taking your thought into account: There is a fundamental = difference
>> betwen TOFU and out-of-band-authentication/approval (pick a = term),
>> and the fact that different such mechanisms may have (often = human)
>> weaknesses does not change this fundamental difference ??
>
>
> I think the key is that humans oughtn=E2=80=99t rely solely on a = visual inspection of whatever is presented in front of them, but rather = that they might rely on alternative inputs, such as recommendations made = by the registrar provider, or federated services.
>
>
>>
>> Maybe you want to propose text ?
>
> Manual approval by administrator or selection by administrator.
>
> Eliot
>>
>> Cheers
>>   Toerless
>>
>> On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
>>> Hi Toerless,
>>>
>>>> On 4 Jun 2019, at 21:28, Toerless Eckert <tte@cs.fau.de> wrote:
>>>>
>>>> Thanks, Eliot,
>>>>
>>>> re-reading 10.3, my impression is:
>>>>
>>>> a) The use of TOFU in 10.3 seems to exceed the = explanatory definition in 1.2.
>>>> The sentence stubs in 103 mentioning TOFU also don't = seem to add value, the text
>>>> doesn't become IMHO worse if they are simply removed. = And i am sure
>>>> there can easily be similar non-cyptographic leap of = faiths in sales integration,
>>>> or consortium memberships trust chaing = establishment.
>>>
>>> My point is that those are no longer leaps of faith.
>>>
>>> Eliot
>>>
>>>>
>>>> b) The text could IMHO be crisper:
>>>>
>>>> "will have no problem collaborating with it's MASA" = ->
>>>> "will have no problem collaborating with it's malicious = MASA" ->
>>>>
>>>> "the domain (registrar) still needs to trust the = manufacturer" ->
>>>> "the domain (registrar) still needs to authenticate the = MASA" ?
>>>> (i hope the latter is the correct interpretation of the = text)
>>>>
>>>> Cheers
>>>>   Toerless
>>>>
>>>> On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear = wrote:
>>>>> Just on this text:
>>>>>
>>>>> In Section 10.3 the following text exists:
>>>>>
>>>>>  o  A Trust-On-First-Use (TOFU) = mechanism.  A human would be queried
>>>>>     upon seeing a manufacturer's = trust anchor for the first time, and
>>>>>     then the trust anchor would be = installed to the trusted store.
>>>>>     There are risks with this; even = if the key to name is validated
>>>>>     using something like the WebPKI, = there remains the possibility
>>>>>     that the name is a look alike: = e.g, c1sco.com, ..
>>>>>
>>>>> First, this isn???t REALLY Trust-On-First-Use, and = I would prefer that the term be replaced with something like = "out-of-band approval".  This would also be a good area for = certification services to step in to indicate the trustworthiness of a = manufacturer.
>>>>>
>>>>> Eliot
>>>>>
>>>>>> On 21 May 2019, at 23:21, The IESG <iesg-secretary@ietf.org> wrote:
>>>>>>
>>>>>>
>>>>>> The IESG has received a request from the = Autonomic Networking Integrated
>>>>>> Model and Approach WG (anima) to consider the = following document: -
>>>>>> 'Bootstrapping Remote Secure Key = Infrastructures (BRSKI)'
>>>>>> = <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed = Standard
>>>>>>
>>>>>> This is a second Last Call. IoT Directorate = review was done after the ANIMA
>>>>>> WG Last Call and consensus to request the = publication, and that review resulted
>>>>>> in substantial changes to the document.
>>>>>>
>>>>>> The IESG plans to make a decision in the next = few weeks, and solicits final
>>>>>> comments on this action. Please send = substantive comments to the
>>>>>> ietf@ietf.org mailing lists by = 2019-06-04. Exceptionally, comments may be
>>>>>> sent to iesg@ietf.org instead. In either case, = please retain the beginning of
>>>>>> the Subject line to allow automated sorting.
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>>
>>>>>> This document specifies automated bootstrapping = of an Autonomic
>>>>>> Control Plane.  To do this a remote secure = key infrastructure (BRSKI)
>>>>>> is created using manufacturer installed X.509 = certificate, in
>>>>>> combination with a manufacturer's authorizing = service, both online
>>>>>> and offline.  Bootstrapping a new device = can occur using a routable
>>>>>> address and a cloud service, or using only = link-local connectivity,
>>>>>> or on limited/disconnected networks.  = Support for lower security
>>>>>> models, including devices with minimal = identity, is described for
>>>>>> legacy reasons but not encouraged.  = Bootstrapping is complete when
>>>>>> the cryptographic identity of the new key = infrastructure is
>>>>>> successfully deployed to the device but the = established secure
>>>>>> connection can be used to deploy a locally = issued certificate to the
>>>>>> device as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The file can be obtained via
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/
>>>>>>
>>>>>> IESG discussion can be tracked via
= >>>>>> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping= -keyinfra/ballot/
>>>>>>
>>>>>> The following IPR Declarations may be related = to this I-D:
>>>>>>
>>>>>> https://datatracker.ietf.org/ipr/2816/ >>>>>> https://datatracker.ietf.org/ipr/3233/ >>>>>> https://datatracker.ietf.org/ipr/2463/ >>>>>>
>>>>>>
>>>>>>
>>>>>> The document contains these normative downward = references.
>>>>>> See RFC 3967 for additional information:
>>>>>>  rfc8368: Using an Autonomic Control Plane = for Stable Connectivity of Network Operations, Administration, and = Maintenance (OAM) (Informational - IETF stream)
>>>>>>
>>>>>>
>>>>>>
>>>>>> = _______________________________________________
>>>>>> Anima mailing list
>>>>>> Anima@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> Anima@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>
>>>>
>>>> --
>>>> ---
>>>> tte@cs.fau.de
>>>
>>
>>
>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>> --
>> ---
>> tte@cs.fau.de
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>



= --Apple-Mail=_E179AF7B-6F23-4E7E-89E0-FFF3C2C2A461-- --Apple-Mail=_FF328D14-8BDE-45F0-866C-0D5680C57B94 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXP+X0gAKCRBugA9nE248 uENXAKCPyyIzblbVOhtEWG7mgtexF1IBagCeLkRw50gBMOgYi5GGxrACSPHPsKM= =YrNm -----END PGP SIGNATURE----- --Apple-Mail=_FF328D14-8BDE-45F0-866C-0D5680C57B94-- From nobody Tue Jun 11 10:47:19 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6E12015E for ; Tue, 11 Jun 2019 10:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 Gec51oWtkUvC for ; Tue, 11 Jun 2019 10:47:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CACC1201A1 for ; Tue, 11 Jun 2019 10:47:13 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 38BE938186; Tue, 11 Jun 2019 13:45:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7253A1001; Tue, 11 Jun 2019 13:47:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6F48ACBE; Tue, 11 Jun 2019 13:47:11 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, ietf-http-wg@w3.org cc: Carsten Bormann , draft-ietf-pkix-est@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 17:47:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable {a little bit surprised that the IETF HTTP list is on w3c. Makes sense From=20a cross-effort point of view. I guess the IETF global white list mi= ght not work for me} RFC7030 (Enrollment over Secure Transport) includes language like (section 4.1.3): https://tools.ietf.org/html/rfc7030#section-4.1.3 A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" [RFC2045]. draft-ietf-anima-bootstrap-keyinfra (now in IETF Last Call), extends EST. It creates a few more end points, and transfers RFC8366 format artifacts over those end points. RFC8366 defines them to be CMS signed objects, in DER (not PEM) format. Another document in ANIMA models the artifacts as COSE signed CBOR (also CMS signed CBOR). All binary objects. In doing interop testing we had some surprises about whether we should see base64 encoding of objects "on-the-wire". Some implementations have what I consider to be typical HTTP client and server code. The application sticks binary in, an appropriate Content-Transfer-Encoding is added, and the binary is adapted. On the client, if there is an encoding, it is removed, and the client sees binary plus a Content-Type. Other implementations were doing something more optimal: observing the base64, but noticing that there is only one possible Content-Type, and the Content-Transfer-Encoding is implicit, and so emitting base64 with an implicit text/plain content type. In addition, people make mistakes, and the desire to write test cases with curl --data (vs --data-binary) easily has led some of us astray at times. While we think that constrained devices should speak the constrained protoc= ol (see below), in some cases code-constrained devices speak HTTPS, and wish to do away with any base64 layer of encoding, as a naive use of it can come with unknown memory requirements. Some questions: 1) Is Content-Transfer-Encoding even valid in HTTP1.x? RFC2616 and RFC7230 speak about Transfer-Encoding, and this relates to Chunked or not. https://tools.ietf.org/html/rfc2616#section-14.41 https://tools.ietf.org/html/rfc2616#section-19.4.5 says: HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client. RFC7230 does not include the above text making CTE unwanted. This made it rather hard to track down the truth :-) 2) Assuming the answer to (1) is no, what should we make of RFC7030 that says to use it, and to base64 binary objects? Would it be reasonable to assume that this is an error, to permit an absent (or CTE: Binary) to mean binary for RFC7030? There is clearly an interoperability issue here if existing implementations do not understand this. Did we miss a cross-area review, or did we do this on purpose? RFC7030 is terribly repetitive about CTE suggesting it needed to hit people over the head with a hammer. 3) What should draft-ietf-anima-bootstrapping-keyinfra do going forward? We make use of RFC7030 functionality, and after bootstrap, we can't be sure that the EST server we use for certificate renewal is the same (brand of) EST server as before, so just because we did BRSKI, doesn't mean we can assume a binary version of 7030. Should BRSKI end-points: a) omit CTE, and assume binary. b) permit CTE, suggest it say, "binary" c) permit CTE, support "binary" or "base64" d) permit CTE, support "base64" only (like RFC7030). Some implementors received pressure within to reduce the number of bytes on the wire significantly. The use of implicit Content-Type and CTE was a result, rather than saving 25% by going base64->binary. Constrained users are directed to draft-ietf-ace-est-coaps (replaces 7030), and draft-ietf-anima-constrained-voucher (replaces 8366, and BRSKI), which uses CBOR, COSE and COAP. Note that the constrained-voucher version of BRSKI uses the standard BRSKI-MASA protocol between registrar and MASA. That path has no "legacy" RFC7030 end points, and so should be modern HTTPS. Because it transfers both RFC8366 and the three formats of constrained voucher (all binary artifacts), it relies on Content-Type: and Accept: in both directions to signal the format present, and the desired format response. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz/6R8ACgkQgItw+93Q 3WWSNggAsdxNA9eQbZUo0578flg+Y/Ew7sWqQ24NRJVIhSNP7Vc1U9oGgMHL3HPl I/3cMh+b6/v8eMtEgbshLTgi5t0oZtG/1P5248RYeg8OW4/z52CrlwQa7b9O3Cj6 QySIsCrCVxen9M9Q3aaztp39a7/4afLmyfHQ+JvBVdOFWYRW4CV9zGuA5ciqMIST gZMi/Wqz/14xmhEkwnbVtrYuYHGlCLRE7CqJkwojx3yFHPX0Uaw0XyG8/gyNTlpu 6Y7VpAuv3mmZmFiGVo7BX/DXS3c8hug0ce9vNeb0jdtL1NwWNzeDEXgXJPyzZlC9 a1MZorYKoTNUeSUluJjRPUAjEa0rNA== =ZuKS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 11 13:40:10 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793F21200B3 for ; Tue, 11 Jun 2019 13:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcB3j3ol-Gha for ; Tue, 11 Jun 2019 13:40:06 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 5402D120090 for ; Tue, 11 Jun 2019 13:40:06 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id i189so8149382pfg.10 for ; Tue, 11 Jun 2019 13:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BePWWikrjzsp90Ro07u9+kKmFbfGmMjXfB6/gtL+qg8=; b=QWEgyF77VkxGqOMOrrC7burUW+P/0y7a8OZWJTfrnP/MncnqVVy5N0SlFlol1+fnnV TiuU5pME1YamXwJm3+SgDKoZPghzIEie+7PCEK/lpoiTNfx5rb3vSZqv/wM/MHIOtXA8 BDxKM111ga5lBbCTung9PPpXE2SuerPuWFlEpQ8nexcqmJEGSor4hIyhUSYP6bFiNVde YP2b+Oes1/3tjZYjQ1xbh+z4CGXN4Y22DUUte0mceAhH9UgfL/ttX5tGSeVR7UMPn15F AfcU9tuDaIY0r40rB2wCD6HKsnIlhPmbYA1gEmOmzKSQRe9z/vK8NxqtaVqGkv24eqY8 rDZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BePWWikrjzsp90Ro07u9+kKmFbfGmMjXfB6/gtL+qg8=; b=qoQ2YbzJCRtV9uztfKLw0qztgXxFT1M3ZZ9ayQTRy+UM8aMsrEXtxbD2PiJEVhY6PU 9d1LBgZH+LmwbeznJzorylP2Y67VhfgwmB0LehvlhFATM9Yz2oyNA2Z7AozA/y0wMcBm YyclpX69gzqEaSjxUWWgyRqvSCKA5nyxUGDBBincrWyLJJB2QubbQrp74lSTOSbUeCEe VZK/JhzHubSqUpWPBbVnh0dmuNTHoEvp0pOisKNDyqVmZ3dP6qS36BEXPsgycmH1j/j3 kAYfrjZL6Gga1vSmD+v+HK7kR2bXoq/SYJHWyw9nMLYJ2RxnxtIsASuLAVd50E9lftoB x45w== X-Gm-Message-State: APjAAAXnqmExK+swjleU7+LWJ0zV85+A7CnghOPsDYmOQdbgnLeGRffK 0dvlSoy9+pESAAyWGpYrA1GHwvJv X-Google-Smtp-Source: APXvYqxho45G0VIEacSHz2jj9ZSecB5cfB80gmd5g1mWUB7oeEliDof/zFh4t9YyUOrvkt4v2QgbPw== X-Received: by 2002:a17:90a:9a95:: with SMTP id e21mr27845337pjp.98.1560285605908; Tue, 11 Jun 2019 13:40:05 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id v18sm1542812pfg.182.2019.06.11.13.40.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 13:40:05 -0700 (PDT) From: Brian E Carpenter To: Anima WG Cc: "Liubing (Leo)" References: <156028515344.30847.13113098174964617575@ietfa.amsl.com> Message-ID: Date: Wed, 12 Jun 2019 08:40:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <156028515344.30847.13113098174964617575@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-limited-domains-08.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 20:40:09 -0000 Hi, We've updated this draft according to comments received. At the moment the authors plan to submit it to the Independent Submissions RFC stream. If anybody thinks it should be an IETF stream document, please let us know. Regards Brian & Bing -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-limited-domains-08.txt Date: Tue, 11 Jun 2019 13:32:33 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Limited Domains and Internet Protocols Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-limited-domains-08.txt Pages : 27 Date : 2019-06-11 Abstract: There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains, also known as controlled environments, and emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of limited domain membership and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-limited-domains-08 https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 12 08:02:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621121200FF for ; Wed, 12 Jun 2019 08:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 84KHS9VLrf3u for ; Wed, 12 Jun 2019 08:02:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6541B1200E9 for ; Wed, 12 Jun 2019 08:02:00 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E6239380BE; Wed, 12 Jun 2019 11:00:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9046EF4A; Wed, 12 Jun 2019 11:01:58 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8EAAA55A; Wed, 12 Jun 2019 11:01:58 -0400 (EDT) From: Michael Richardson to: anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann In-Reply-To: <32410.1560275231@localhost> References: <32410.1560275231@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 15:02:04 -0000 --=-=-= Content-Type: text/plain {resending, now that I'm subscribed to ietf-http-wg. If you aren't on that list, the IETF global white list won't help you} RFC7030 (Enrollment over Secure Transport) includes language like (section 4.1.3): https://tools.ietf.org/html/rfc7030#section-4.1.3 A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" [RFC2045]. draft-ietf-anima-bootstrap-keyinfra (now in IETF Last Call), extends EST. It creates a few more end points, and transfers RFC8366 format artifacts over those end points. RFC8366 defines them to be CMS signed objects, in DER (not PEM) format. Another document in ANIMA models the artifacts as COSE signed CBOR (also CMS signed CBOR). All binary objects. In doing interop testing we had some surprises about whether we should see base64 encoding of objects "on-the-wire". Some implementations have what I consider to be typical HTTP client and server code. The application sticks binary in, an appropriate Content-Transfer-Encoding is added, and the binary is adapted. On the client, if there is an encoding, it is removed, and the client sees binary plus a Content-Type. Other implementations were doing something more optimal: observing the base64, but noticing that there is only one possible Content-Type, and the Content-Transfer-Encoding is implicit, and so emitting base64 with an implicit text/plain content type. In addition, people make mistakes, and the desire to write test cases with curl --data (vs --data-binary) easily has led some of us astray at times. While we think that constrained devices should speak the constrained protocol (see below), in some cases code-constrained devices speak HTTPS, and wish to do away with any base64 layer of encoding, as a naive use of it can come with unknown memory requirements. Some questions: 1) Is Content-Transfer-Encoding even valid in HTTP1.x? RFC2616 and RFC7230 speak about Transfer-Encoding, and this relates to Chunked or not. https://tools.ietf.org/html/rfc2616#section-14.41 https://tools.ietf.org/html/rfc2616#section-19.4.5 says: HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client. RFC7230 does not include the above text making CTE unwanted. This made it rather hard to track down the truth :-) 2) Assuming the answer to (1) is no, what should we make of RFC7030 that says to use it, and to base64 binary objects? Would it be reasonable to assume that this is an error, to permit an absent (or CTE: Binary) to mean binary for RFC7030? There is clearly an interoperability issue here if existing implementations do not understand this. Did we miss a cross-area review, or did we do this on purpose? RFC7030 is terribly repetitive about CTE suggesting it needed to hit people over the head with a hammer. 3) What should draft-ietf-anima-bootstrapping-keyinfra do going forward? We make use of RFC7030 functionality, and after bootstrap, we can't be sure that the EST server we use for certificate renewal is the same (brand of) EST server as before, so just because we did BRSKI, doesn't mean we can assume a binary version of 7030. Should BRSKI end-points: a) omit CTE, and assume binary. b) permit CTE, suggest it say, "binary" c) permit CTE, support "binary" or "base64" d) permit CTE, support "base64" only (like RFC7030). Some implementors received pressure within to reduce the number of bytes on the wire significantly. The use of implicit Content-Type and CTE was a result, rather than saving 25% by going base64->binary. Constrained users are directed to draft-ietf-ace-est-coaps (replaces 7030), and draft-ietf-anima-constrained-voucher (replaces 8366, and BRSKI), which uses CBOR, COSE and COAP. Note that the constrained-voucher version of BRSKI uses the standard BRSKI-MASA protocol between registrar and MASA. That path has no "legacy" RFC7030 end points, and so should be modern HTTPS. Because it transfers both RFC8366 and the three formats of constrained voucher (all binary artifacts), it relies on Content-Type: and Accept: in both directions to signal the format present, and the desired format response. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0BE+YACgkQgItw+93Q 3WVYnAgAjIh+UDfQIVytzPuE+rk3jEkiLQ4uwhFYB45H1ufUutN2Fdr7h9bM/z4D /8sRuOQ3BUlkcqO3ifoXczHcPdTUfIV9g1wHB9mPZ7XSMqzmO5mYg+6tIWmXbTbe m7rBfoksOjyL0HM2INUifvZEt1bg+x7aa22R4VR+W8YHGU112bM1oGzjJD/RMfTj DYjz43KEGtD7TggVVJDFryt6fxTo5g3/34X/vI60G4wxfdnSS+ALJqEN+gH2fvAo YbGWNpIeBRH1BJvA23SwEzLwHSpNy3BCcaJNmAoq1A1WF37fcTjqB9MDFWm+Xyvp M6SighsG/qRhAkUeQKp4Y7/T25raRQ== =sG9r -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 12 10:27:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E81201C9 for ; Wed, 12 Jun 2019 10:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SWX0-HGoU8Jp for ; Wed, 12 Jun 2019 10:27:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 1D2A81201CC for ; Wed, 12 Jun 2019 10:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1560360409; bh=rnLN2IKBsOaxa8b1590xFDg0KSBLkNn/EwrBPteiF6s=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=CLAZu0jkIBQNwUbw9RrAe0WLnu6sAr/xmWC/mYIyB4HhFwt1t9pX6S9yLISmz7G66 s1ZDezAM7ucAVyUBxvqSV91geGl4WYM27jFPlYmB0ZxJTaeJbKZmAccg+N4T5lHZVo INfXMTEWijSP/ln2wSv28N/G7Hcp1wsROkHNgD50= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.155.95]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIMbO-1hpM6f1Xe8-00EJdL; Wed, 12 Jun 2019 19:26:49 +0200 To: Michael Richardson , anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann References: <32410.1560275231@localhost> <15839.1560351718@localhost> From: Julian Reschke Message-ID: <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> Date: Wed, 12 Jun 2019 19:26:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <15839.1560351718@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:9EMm2EyOTz1sv4sTFePuYNwhM5Fxv1WfefPUNLfh5oLjGPDWfeC 56rQoL4f6AQne6javfHRw9Iv/EW+LNM6CcvqsKS1Y3WmnYBz0pd0oMk78L6TEid7EE7pdva +RcO34ZnTp/pGuPyorWLdvJbPZEcrZPE8UY3a5/wjhL2LVgtSySGD+6Uvinzl2P4YXKalUD 2MkbUzaLKPRuiB4hT4y/g== X-UI-Out-Filterresults: notjunk:1;V03:K0:r2TMYhP1ZRE=:BPWKx95DjstySgbAGE/O/3 nytbI36GZGSnUhNHPFfF0V3fr+s0XGiztwHqIMYJMXpEAGEXMQh8LsXxgRftFSGdVVyg4z6NE y39KfF68HEFsBlZknQLtbi7hauLbDf2tI4bS+vt/+iQgNnq0z0QEisR3jQKkiig1s15V52oRp fU9Rtzf8fj7jE4DPjYnZikuBQNV+KcccDdVPhB9GNWA4NRQ+iICyA6rH2cwBSAkwsXELIwRnO zwd0rS7872e5W5Ozkf6/trSOUGoOJk+q2lt3dwrju0jJvdRqMM1ie1pGFeonfAsBUxoa9Zz+K gD8hDzePorW7Q3FPP7A43TNOzQHBro1CJYlB4WnZ4H6kDxM7Xeh7FcCEULF4zfxZ/m6nSMyXx 3pPSaqpK9npELiH8iGf+yIvIrDKgmdFTFjpzbhcI5faEWNhyTIHYtopD7dOi4rnXoBuuYjIEM TNbqqVFsz2txEMAdW/hB9WbtvT2LqFnkHRkIsvMRlVWAwqpWr/YEZ+VWbaiLqu3PjuQr4XTfl eSDGdu+hXVi+Ym+RTUHGktu6zWyZ99jXiji4QsL8X+AQozTBL3S/8IMgkjqyLrrFJs5c4z7nY Lvms0ElorG55VUwJcY7CTumejcX640N9JJswmbeJ+TbO15kcLLu8mqdjx3tzYd9SyRl6bTWHS /EIiJ1d4JD5fLZRph78HiqjtI3/BcoIFYGMp+5PRbNstaQZglR57o+FpjqyLqKZlG7dpPjpqN yMzW5sWn21n1GtStOajR/zkrX8uRpufKl8puNdhe3ZL5usdRLY031w6INuxTlNVf6CPthp7NE 6v7GBL5559t1yGrHfPgaxOjPWsxCW4kRLfsY5hUtdwHjOuVmLZ8AUBwFL8IyFYcCYbsDpyeC8 3sjdpaU4vVZXt2dWwtM0LankOjfwHxyVXx4U2HQW3XxT2kuV0ed5DozOZSP3zmkQS4/6VD3jY byGP7y4sPDGacrTUf6ecrzQ3F3vGKmdc0erQ9GM9mAgm/fBPBfEfQ Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 17:27:11 -0000 On 12.06.2019 17:01, Michael Richardson wrote: > > {resending, now that I'm subscribed to ietf-http-wg. If you aren't > on that list, the IETF global white list won't help you} > > RFC7030 (Enrollment over Secure Transport) includes language like (secti= on > 4.1.3): https://tools.ietf.org/html/rfc7030#section-4.1.3 > > A successful response MUST be a certs-only CMC Simple PKI Response, > as defined in [RFC5272], containing the certificates described in th= e > following paragraph. The HTTP content-type of > "application/pkcs7-mime" is used. The Simple PKI Response is sent > with a Content-Transfer-Encoding of "base64" [RFC2045]. > > draft-ietf-anima-bootstrap-keyinfra (now in IETF Last Call), extends EST= . > It creates a few more end points, and transfers RFC8366 format artifacts > over those end points. RFC8366 defines them to be CMS signed objects, > in DER (not PEM) format. Another document in ANIMA models the artifacts > as COSE signed CBOR (also CMS signed CBOR). All binary objects. > > In doing interop testing we had some surprises about whether we should s= ee > base64 encoding of objects "on-the-wire". > > Some implementations have what I consider to be typical HTTP client and > server code. The application sticks binary in, an appropriate > Content-Transfer-Encoding is added, and the binary is adapted. On the > client, if there is an encoding, it is removed, and the client sees bina= ry > plus a Content-Type. > > Other implementations were doing something more optimal: observing the > base64, but noticing that there is only one possible Content-Type, and > the Content-Transfer-Encoding is implicit, and so emitting base64 with a= n > implicit text/plain content type. > > In addition, people make mistakes, and the desire to write test cases wi= th > curl --data (vs --data-binary) easily has led some of us astray at times= . > > While we think that constrained devices should speak the constrained pro= tocol > (see below), in some cases code-constrained devices speak HTTPS, and > wish to do away with any base64 layer of encoding, as a naive use of it > can come with unknown memory requirements. > > Some questions: > > 1) Is Content-Transfer-Encoding even valid in HTTP1.x? > RFC2616 and RFC7230 > speak about Transfer-Encoding, and this relates to Chunked or not. > https://tools.ietf.org/html/rfc2616#section-14.41 > > https://tools.ietf.org/html/rfc2616#section-19.4.5 says: > HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC > 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUS= T > remove any non-identity CTE ("quoted-printable" or "base64") encodin= g > prior to delivering the response message to an HTTP client. > > RFC7230 does not include the above text making CTE unwanted. > This made it rather hard to track down the truth :-) There is no Content-Transfer-Encoding header field in HTTP. It is simply not needed. > 2) Assuming the answer to (1) is no, what should we make of RFC7030 > that says to use it, and to base64 binary objects? Raise an erratum :-). > Would it be reasonable to assume that this is an error, to > permit an absent (or CTE: Binary) to mean binary for RFC7030? > There is clearly an interoperability issue here if existing > implementations do not understand this. > > Did we miss a cross-area review, or did we do this on purpose? > RFC7030 is terribly repetitive about CTE suggesting it needed > to hit people over the head with a hammer. I'm sure I haven't looked at that spec. Anybody from this WG should have spotted this. > 3) What should draft-ietf-anima-bootstrapping-keyinfra do going forward? > We make use of RFC7030 functionality, and after bootstrap, we can't > be sure that the EST server we use for certificate renewal is the > same (brand of) EST server as before, so just because we did BRSKI, > doesn't mean we can assume a binary version of 7030. > > Should BRSKI end-points: > a) omit CTE, and assume binary. Yes. > ... Best regards, Julian From nobody Wed Jun 12 13:50:09 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9622412013C for ; Wed, 12 Jun 2019 13:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do80R_WiQo56 for ; Wed, 12 Jun 2019 13:50:05 -0700 (PDT) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 F41681200F8 for ; Wed, 12 Jun 2019 13:50:04 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id a186so10363785pfa.5; Wed, 12 Jun 2019 13:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=OUG7NqQ1fkYdvTDAZ14UIHZgOva3EMZkVQZIVcSEefk=; b=jJFsnZp5rrBI4/yLCsBcXM5JKQ5mi/3VH/IQFeraJk9y9c2/QqCw+FbDY+5IR9MI2r cUiBwMu/WNJoqyNI8fJICeUHIdPIuNqg8BhEKkSwmVqUDBHabXkH94hYQmtisCwHcMue Q5/8nNka7olennKbXmmN+V+yoa6Byj050KjquDWiA7WVJiXL+QRw4BRcgljkcquMJwHu LQNvn+FV/JFEWjMiW5MwVvqriyiIqBwKYl44XvU8ZyhhCAFbu+gRPLyrkF4CMEMjzt4/ +IJesWtsaFKisbWA8J916cbS/aDolfVvheMXVtuzr7p+leir6+234eCUIrqQkWzWLQJM OZgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OUG7NqQ1fkYdvTDAZ14UIHZgOva3EMZkVQZIVcSEefk=; b=dmnjbc8NSpeCH3MSI/ZDFrsdbKYjmjG427TZXBmi6S7t/rQ3TiQsd4tlQTlQSzPrU1 CWDYcJR6uxbwlemmkK+hCGNa5CCpJt3J/q2g4VENSXBJnnnVGhYXE8FyutOHzqO5W2aA 23Ak/4f0GHKk/ZnOYutnMgB2fjYRwH3TyMQ8LGw+mOLK9jdOtzsN/+Q1RdZGbpRikLuC VhyIUYGenN4iMBe1m4AUcESL3+cJ6FmvQlAIRNyB44aHkKUCcRKhH2mnrPM6/++0PwaJ 2U96DclertWohd9CB0kejfQR3WS0RqnZ3rMwXVNk4jNWPP26vuBs62ZTByfpZC3q4qHZ k4ZA== X-Gm-Message-State: APjAAAWLyV7uyjK1dYLc7EF+hIVLuuuDMhwOgAGqmC7AIUOmzYwj+Aab xUKH4o06ETGyALAQ5GyYD3Y= X-Google-Smtp-Source: APXvYqymEv+4L8kBEHKzGGSnOBi7cSU1kM6ZOyxBuvt8O8ms5lQYBW5tsPlGFUcH9w5F06wa3WbB4w== X-Received: by 2002:a17:90a:338b:: with SMTP id n11mr1070698pjb.21.1560372604408; Wed, 12 Jun 2019 13:50:04 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id m16sm470887pfd.127.2019.06.12.13.50.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jun 2019 13:50:03 -0700 (PDT) To: Julian Reschke , Michael Richardson , anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> From: Brian E Carpenter Message-ID: <9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com> Date: Thu, 13 Jun 2019 08:49:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 20:50:08 -0000 Hi Julian, On 13-Jun-19 05:26, Julian Reschke wrote: > On 12.06.2019 17:01, Michael Richardson wrote: >> >> {resending, now that I'm subscribed to ietf-http-wg. If you aren't >> on that list, the IETF global white list won't help you} >> >> RFC7030 (Enrollment over Secure Transport) includes language like (section >> 4.1.3): https://tools.ietf.org/html/rfc7030#section-4.1.3 >> >> A successful response MUST be a certs-only CMC Simple PKI Response, >> as defined in [RFC5272], containing the certificates described in the >> following paragraph. The HTTP content-type of >> "application/pkcs7-mime" is used. The Simple PKI Response is sent >> with a Content-Transfer-Encoding of "base64" [RFC2045]. >> >> draft-ietf-anima-bootstrap-keyinfra (now in IETF Last Call), extends EST. >> It creates a few more end points, and transfers RFC8366 format artifacts >> over those end points. RFC8366 defines them to be CMS signed objects, >> in DER (not PEM) format. Another document in ANIMA models the artifacts >> as COSE signed CBOR (also CMS signed CBOR). All binary objects. >> >> In doing interop testing we had some surprises about whether we should see >> base64 encoding of objects "on-the-wire". >> >> Some implementations have what I consider to be typical HTTP client and >> server code. The application sticks binary in, an appropriate >> Content-Transfer-Encoding is added, and the binary is adapted. On the >> client, if there is an encoding, it is removed, and the client sees binary >> plus a Content-Type. >> >> Other implementations were doing something more optimal: observing the >> base64, but noticing that there is only one possible Content-Type, and >> the Content-Transfer-Encoding is implicit, and so emitting base64 with an >> implicit text/plain content type. >> >> In addition, people make mistakes, and the desire to write test cases with >> curl --data (vs --data-binary) easily has led some of us astray at times. >> >> While we think that constrained devices should speak the constrained protocol >> (see below), in some cases code-constrained devices speak HTTPS, and >> wish to do away with any base64 layer of encoding, as a naive use of it >> can come with unknown memory requirements. >> >> Some questions: >> >> 1) Is Content-Transfer-Encoding even valid in HTTP1.x? >> RFC2616 and RFC7230 >> speak about Transfer-Encoding, and this relates to Chunked or not. >> https://tools.ietf.org/html/rfc2616#section-14.41 >> >> https://tools.ietf.org/html/rfc2616#section-19.4.5 says: >> HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC >> 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST >> remove any non-identity CTE ("quoted-printable" or "base64") encoding >> prior to delivering the response message to an HTTP client. >> >> RFC7230 does not include the above text making CTE unwanted. >> This made it rather hard to track down the truth :-) > > There is no Content-Transfer-Encoding header field in HTTP. It is simply > not needed. Just as a matter of curiosity, what happened in HTTP1.1 to the fragment in RFC2616 that says (under Content-MD5): "The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers)." This seems to be a source of confusion, e.g. https://stackoverflow.com/questions/5169434/content-transfer-encoding-in-file-uploading-request . RFC7030 uses a content type of application/pkcs7-mime. So is it allowed to specify a MIME header? Brian > >> 2) Assuming the answer to (1) is no, what should we make of RFC7030 >> that says to use it, and to base64 binary objects? > > Raise an erratum :-). > >> Would it be reasonable to assume that this is an error, to >> permit an absent (or CTE: Binary) to mean binary for RFC7030? >> There is clearly an interoperability issue here if existing >> implementations do not understand this. >> >> Did we miss a cross-area review, or did we do this on purpose? >> RFC7030 is terribly repetitive about CTE suggesting it needed >> to hit people over the head with a hammer. > > I'm sure I haven't looked at that spec. Anybody from this WG should have > spotted this. > >> 3) What should draft-ietf-anima-bootstrapping-keyinfra do going forward? >> We make use of RFC7030 functionality, and after bootstrap, we can't >> be sure that the EST server we use for certificate renewal is the >> same (brand of) EST server as before, so just because we did BRSKI, >> doesn't mean we can assume a binary version of 7030. >> >> Should BRSKI end-points: >> a) omit CTE, and assume binary. > > Yes. > >> ... > > Best regards, Julian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Jun 12 15:14:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99512018C for ; Wed, 12 Jun 2019 15:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 FR3gSaRQbQKT for ; Wed, 12 Jun 2019 15:14:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D84120219 for ; Wed, 12 Jun 2019 15:14:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 69ED738183; Wed, 12 Jun 2019 18:12:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6AE601301; Wed, 12 Jun 2019 18:14:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 696DA91F; Wed, 12 Jun 2019 18:14:17 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Julian Reschke , anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann In-Reply-To: <9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com> References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 22:14:22 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> There is no Content-Transfer-Encoding header field in HTTP. It is simply >> not needed. > Just as a matter of curiosity, what happened in HTTP1.1 to the fragment in > RFC2616 that says (under Content-MD5): > "The entity-body for composite > types MAY contain many body-parts, each with its own MIME and HTTP > headers (including Content-MD5, Content-Transfer-Encoding, and > Content-Encoding headers)." yes, I was going to bring this up next :-) > This seems to be a source of confusion, e.g. > https://stackoverflow.com/questions/5169434/content-transfer-encoding-in-file-uploading-request > . RFC7030 uses a content type of application/pkcs7-mime. So is it > allowed to specify a MIME header? I also found that while googling. I went through the effort of doing a multipart *reply* in HTTP for draft-ietf-anima-constrained-voucher, and I really found it hard to determine what the MIME rules for *HTTP* were... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0BeTkACgkQgItw+93Q 3WXyMQf/dJkCv70jYffY6QPOJh/gyIhpg3SZe1ObxN1qwLG3oJxidBXIOsJ5R4K0 PNFxEOxiQCdqZ8bJLNj4HNn2FhqB2Ykb/mr/Ld+1zeYBsvOd4l6wnAwtfh/V0Bmg /3cXTfeU1FKNbLunDOVN1XXoxiv82kXQ4pTBDcBKAw6fj2xeX+dWPFkBKgO3CyCP s/M7JiVMUcnpEpvgiB65swOe9lpHCkvEAJ+ms8i3hfv8aYB1gPmdtAiv7e//f6X0 5pjNuwP1T/KPQRTAuQns+H92UeLBncAr7sXBoGGApDGVp570qWinfCvO5KS3cRSc KE06g5hvY7VyB+0bwBX9cjbJWYsirg== =igB+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 12 16:54:34 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828BE120230 for ; Wed, 12 Jun 2019 16:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PhHfw5n4d8OK for ; Wed, 12 Jun 2019 16:54:23 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9611112023B for ; Wed, 12 Jun 2019 16:54:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Jun 2019 16:54:15 -0700 From: To: 'Michael Richardson' , 'Thomas Werner' , 'consultancy' , References: <28559.1558924665@localhost> In-Reply-To: <28559.1558924665@localhost> Date: Wed, 12 Jun 2019 16:54:11 -0700 Message-ID: <011d01d5217a$240e6eb0$6c2b4c10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI6C3zosouMnyM+R/zZmAatMjR9kqXO3PwA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] constrained voucher examples updated --- voucher looks wrong X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 23:54:32 -0000 Is the intention that there will be a mapping of public key to signature algorithm and it will be a one-to-one mapping? Just double checking how to decide what algorithm to use for signing and verifying. The current text would only address a single set of public keys. Jim -----Original Message----- From: Michael Richardson Sent: Sunday, May 26, 2019 7:38 PM To: Thomas Werner ; consultancy ; anima@ietf.org Cc: Jim Schaad Subject: constrained voucher examples updated --- voucher looks wrong I have updated the appendix to draft-ietf-anima-constrained-voucher, which contains the COSE signed CBOR vouchers. I have included base64 of the binary, as well as CBOR diagnostic format. Please see: https://github.com/anima-wg/constrained-voucher/blob/master/constrained-vouc her.txt#L2218 I am including the private (EC) keys in PKCS1 form ("BEGIN EC PRIVATE KEY"), perhaps I should use PKCS8/RFC5208 format ("BEGIN PRIVATE KEY") instead? Thomas, and Jim, would you take a crack at validating the voucher-request and parboiled (Registrar signed) voucher requests from these files? The raw binary files are at: https://github.com/anima-wg/constrained-voucher/tree/master/examples along with the public keys. It's just COSE signatures. In doing this, I've discovered a bug in my code, and I believe it needs to be fixed. Specifically, it appears at line: https://github.com/anima-wg/constrained-voucher/blob/master/constrained-vouc her.txt#L2478 You'll notice: "00-D0-E5-F2-00-02", 11: "rIe_64PzENXdd32FApWcMQ", 12: "MII B5TCCAWugAwIBAgIBATAKBggqhkjOPQQDAjBzMRIwEAYKCZImiZPyLGQBGRY that is, I've pinned the *base64* encoding of the registrar's DER encoded certificate, rather than the DER encoding itself. This is clearly wrong, but I do it consistently and tolerantly so I don't notice. I will be fixing this. However, the signature on the resulting object should be correct, even if the contents are semantically wrong. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Wed Jun 12 23:19:33 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ECB120199 for ; Wed, 12 Jun 2019 23:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 R5_0KC67QXRc for ; Wed, 12 Jun 2019 23:19:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 11533120088 for ; Wed, 12 Jun 2019 23:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1560406756; bh=nHmnRIg4ysvifKaLLS2uVP6Af8zcTbjQ63f0zBD7+x0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=D5NI+9u52Cu84JH1Wn0oFfaAayXtApvFOb5hnwT0wsADNC9wtQtkyICIcHQiJJcw0 4NJMjqgrbKrUlS6tpz6zXiwZPjKPQoulBOrbsyMQUzAcdYe3sBXh8cQDZ1Cqi5Lx5s I1LrJbhWOYkdKjuzRAsCoQ5v9KpcAY+HLKhavhCM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.54.242]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MfpSb-1iGhVi432n-00gHew; Thu, 13 Jun 2019 08:19:16 +0200 To: Michael Richardson , Brian E Carpenter Cc: anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org, Carsten Bormann References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <9fcce3cd-c3cb-bd60-a55c-af21da621b88@gmail.com> <4930.1560377657@localhost> From: Julian Reschke Message-ID: Date: Thu, 13 Jun 2019 08:19:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4930.1560377657@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:LwHUIL08ag7SwFzFiDBWM69EraKDJFhuix1CC1ZTQgYCjUU4Cpo yIZH3BQXcQgV3ozt52PJbeVUWPQk8Ey8d6CmqJNu+7IpZ5Slh5mAmZR0TrtpE7BMNi9myBv EV3zjeEmUSdQ6D35cGxSBRlYKClPC7X1ZFYVO0cXeynd1BVSbZ8Q/uRRWuhoKAea91DEDca ZgPdFJfoWVEi9rNt07/JA== X-UI-Out-Filterresults: notjunk:1;V03:K0:xAHrkmJqQ9w=:orQEuX6X+95WuKrGJW2Jrv DRU8M4xV1EHCAdAqj9bm7T+bAAVks8DUycbPn8J5PXgs0KYKvrAXbnyoL2V+A6JVCc5lqxRyS Nbc3MsXjEyPBbZtamz7H10px5cFqr9s+eP0pS8q50c/SD+UvC6vnsqTi5bQBTf5tMOY5dYAHl P8p1NIVRTx1deoNMAphPnJfgddXmRs+P56gMlb0tkKjA184cYaGJ+qMmJlVRqJ+XDEt8G0Mql AYI/XXw8nj4RfuWBYyv/Sggi86dAHVE5bgyKuVDxNmFFhs3LRiz7dq9BZzJpODJNuuKaIlWu9 MnBCidUxblNguIDbs9QGCHZ3VcVzpzRZp+TjpPfFYatBw65MatdiU74P0yu8BkPXtJjfNwLET XY1HIFbSWrTJDp2sllsQuGdzjRSllCX8+sMj9pbmmHuZHO4kUG13f504gMNDeueb4tkqguR4u TCeJGwEJSlQkPvn9vtOrODxvYBz4Rhc4swOEsnqzAe9yft+dVJ2pczMTCcyfbuXCuJW97R97x HZ7soHR30xxi1MDd9c8GF663/GJhTHUZTezGYMEIiLd5HnpZIJaPNiZNSTC/ZxgFLCIZOH4ql +DrNz5SIDLempQpf8w9bbBzjFN30g+ElZc35RNHa7Lyr42xIPTyNiwhGSqNpnb22rnkcyNkzI PnSAdqIORcoWnCU5YDmk1YVxwXwema8WrzAg9jB1ewFda8IgR49XNbw4hbWhaYd6sHMdp/diT JZ7b9Ia6F/43yTZL/hXBlMBFwx2QqHO/ldWBSdeuw73ha7t1n371M4PGzZg1iYJFGl2BeKPhc MQwUCrHTTb7fH7FgCz9ZfEnZyWsQ4g2iY2LGXvLVIsZfx0FR5OqOd7E8nXADijJIr9t3CZzMk etDf9Av7mon8tK+pdfKyb5uKPSOi3xZBC/YBPOY+sEeIwZFwLjc6k8p4eowBLzkk06vYv5r+m sXddJrc7kq97nupLRzZ+QyWp+3sYflkAkhJNkREEdkRyZYQuEYaDTEJ3t86Q4T0LOQO4z5C2X Bg== Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 06:19:32 -0000 On 13.06.2019 00:14, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> There is no Content-Transfer-Encoding header field in HTTP. It i= s simply > >> not needed. > > > Just as a matter of curiosity, what happened in HTTP1.1 to the fr= agment in > > RFC2616 that says (under Content-MD5): > > > "The entity-body for composite > > types MAY contain many body-parts, each with its own MIME and HTT= P > > headers (including Content-MD5, Content-Transfer-Encoding, and > > Content-Encoding headers)." > > yes, I was going to bring this up next :-) That's about header fields in payloads of type multipart/*. The text is gone in later specs, because Content-MD5 is. > ... Best regards, Julian From nobody Wed Jun 12 23:28:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CDD120088 for ; Wed, 12 Jun 2019 23:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuGkWA3Nx_Wr for ; Wed, 12 Jun 2019 23:28:01 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EC2120199 for ; Wed, 12 Jun 2019 23:27:58 -0700 (PDT) Received: from client-0045.vpn.uni-bremen.de (client-0045.vpn.uni-bremen.de [134.102.107.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45PYhD1SrszyYc; Thu, 13 Jun 2019 08:27:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> Date: Thu, 13 Jun 2019 08:27:55 +0200 Cc: Michael Richardson , anima@ietf.org, ietf-http-wg@w3.org, draft-ietf-pkix-est@ietf.org X-Mao-Original-Outgoing-Id: 582100073.5914871-5bce2e092151ac0bd5a2ea4fb65730f6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 06:28:03 -0000 On Jun 12, 2019, at 19:26, Julian Reschke wrote: >=20 >> 2) Assuming the answer to (1) is no, what should we make of RFC7030 >> that says to use it, and to base64 binary objects? >=20 > Raise an erratum :-). Not sure about the smiley here. This is an erratum. Now how to resolve this depends on what option causes the smallest = damage. RFC 7030 is supposed to be a widely deployed protocol, so it should not = be hard to find out what people out there are actually doing. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 13 04:20:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CED1202C0 for ; Thu, 13 Jun 2019 04:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 ymRvHEnlLuL3 for ; Thu, 13 Jun 2019 04:20:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAC41202BB for ; Thu, 13 Jun 2019 04:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1519; q=dns/txt; s=iport; t=1560424817; x=1561634417; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=F8gUGXLPo8Sf1l6VTvqcKUqk66DDpj7lN6NDPMX0UMU=; b=BHrcgvwnvncthjq9TfFD9ZRoUhCJVYqMj2o/0ipPjatcTT4Otra0Slnw r1l76e7a4IgzO8uV6DKN2gTZWoIu78UGI8cw4btcOUXbX/cEeMmc6XpBr R8V0EGKdeKfW7ZLs/J3wmpl1crAfppS59ZFkxgzVGd2FIc4GUC1SdMF5e U=; X-Files: signature.asc : 195 X-IronPort-AV: E=Sophos;i="5.63,369,1557187200"; d="asc'?scan'208";a="13117205" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jun 2019 11:20:15 +0000 Received: from dhcp-10-61-101-199.cisco.com (dhcp-10-61-101-199.cisco.com [10.61.101.199]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5DBKDtL022123 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Jun 2019 11:20:14 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_ED1D5ED7-D6D5-48BF-9687-DCA15A2F6A4B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 13 Jun 2019 13:20:12 +0200 In-Reply-To: Cc: Julian Reschke , draft-ietf-pkix-est@ietf.org, Michael Richardson , ietf-http-wg@w3.org, Anima WG , "Panos Kampanakis (pkampana)" To: Carsten Bormann References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.101.199, dhcp-10-61-101-199.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 11:20:20 -0000 --Apple-Mail=_ED1D5ED7-D6D5-48BF-9687-DCA15A2F6A4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am looking at libest and it certainly generates the header. > On 13 Jun 2019, at 08:27, Carsten Bormann wrote: >=20 > On Jun 12, 2019, at 19:26, Julian Reschke = wrote: >>=20 >>> 2) Assuming the answer to (1) is no, what should we make of RFC7030 >>> that says to use it, and to base64 binary objects? >>=20 >> Raise an erratum :-). >=20 > Not sure about the smiley here. This is an erratum. > Now how to resolve this depends on what option causes the smallest = damage. >=20 > RFC 7030 is supposed to be a widely deployed protocol, so it should = not be hard to find out what people out there are actually doing. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --Apple-Mail=_ED1D5ED7-D6D5-48BF-9687-DCA15A2F6A4B 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----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXQIxbAAKCRBugA9nE248 uK2qAJ0W/HHwkQw2Vh6vOZSeOimq5fP8FwCg03clbB7DQP27nn6PTF+SSCMtb4A= =NY38 -----END PGP SIGNATURE----- --Apple-Mail=_ED1D5ED7-D6D5-48BF-9687-DCA15A2F6A4B-- From nobody Thu Jun 13 05:01:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDD51202C2; Thu, 13 Jun 2019 05:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 header.b=GEGx01ek; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GmSq0GGO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 584L-Bc6GxZI; Thu, 13 Jun 2019 05:01:03 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10291202BC; Thu, 13 Jun 2019 05:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4561; q=dns/txt; s=iport; t=1560427262; x=1561636862; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wZSdDM+50J0isx9GlvsS9/BA8GKOAuhkYQV0tE+JXKg=; b=GEGx01ekEqeza9MwJyBpqBBSlU61Mj6aattjovDOEH2AQ0wXggI+VeQn owBu/af67DPAL8UIkmjByMd19jUFBIqDES67i392oyKW4TDUB0FnVEByN TuTOXDRnMUQsZUD5ztPf23v7epkyzqUTNSlfT7ltlITo99PgqNGV6wGo/ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AvnE02BBq/Q0OZCCAyriMUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAABAOgJd/4wNJK1dCRsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBPSQFJwNqVSAECyiHXQOEUooPgleJQ41wgS6BJAN?= =?us-ascii?q?UCQEBAQwBARgNCAIBAYRAAoJJIzQJDgEDAQEEAQECAQRtHAyFSgEBAQQBARA?= =?us-ascii?q?oBgEBLAsBCwQCAQgRBAEBHwULIQYLFAkIAgQBDQUIGoMBgWoDHQECDJ8HAoE?= =?us-ascii?q?4iF+CIoJ5AQEFgTIBE0GCeQ0Lgg8DBoE0AYtcF4FAP4ERRoJMPoIaRwEBAgE?= =?us-ascii?q?BgTMDKYM6giaMARycdT4JAoIQhkeJGoQGgiaHAo4EjRuHGoFnjVECBAIEBQI?= =?us-ascii?q?OAQEFgU84RIEUcBU7gjgBM4IPN24BAoJIhRSFP3IBgSiMcIJSAQE?= X-IronPort-AV: E=Sophos;i="5.63,369,1557187200"; d="scan'208";a="283848440" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jun 2019 12:01:01 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x5DC10iJ015370 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jun 2019 12:01:00 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Jun 2019 07:01:00 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Jun 2019 07:00:59 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 13 Jun 2019 07:00:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nM4E8K2rNRg8FbN68MKeIM0lbj3JWGu5biEo4v8cAeM=; b=GmSq0GGO8KgRRTXNYs2gjEGAWOys5UgqPY+eZ/A7/t1xgOlmqR/1s3juHANPsH0uKo4FBiclJUM0qrezvVLqFPhNktCVKR6Y2bo0yGy+ENecxehifE8+h79QMrnNQ+kl2u2PgWMk0OIdnccjAFgu3ii2Ec6U6Mo/c0m9Mos6Z2w= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB3531.namprd11.prod.outlook.com (20.177.220.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Thu, 13 Jun 2019 12:00:58 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::d46b:d11:c52a:f807]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::d46b:d11:c52a:f807%7]) with mapi id 15.20.1987.010; Thu, 13 Jun 2019 12:00:58 +0000 From: "Owen Friel (ofriel)" To: "ietf@ietf.org" , IETF-Announce CC: "ibagdona@gmail.com" , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "anima@ietf.org" , "anima-chairs@ietf.org" , "tte+ietf@cs.fau.de" Thread-Topic: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard Thread-Index: AQHVEBsofBre3RTjrUagbjUqNxTB/qaZnrzA Date: Thu, 13 Jun 2019 12:00:58 +0000 Message-ID: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> In-Reply-To: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1250:a17c:7d2f:424f:dab6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e90b97c-aeb3-4de6-850b-08d6eff6cbf1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB3531; x-ms-traffictypediagnostic: DM6PR11MB3531: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(39860400002)(366004)(396003)(60444003)(13464003)(189003)(199004)(2906002)(76116006)(2501003)(66946007)(81166006)(81156014)(73956011)(102836004)(8676002)(66446008)(64756008)(11346002)(66556008)(446003)(46003)(66476007)(8936002)(33656002)(476003)(71200400001)(71190400001)(486006)(99286004)(6246003)(14444005)(256004)(4326008)(25786009)(186003)(76176011)(6506007)(53546011)(6116002)(53936002)(68736007)(54906003)(316002)(110136005)(7696005)(5660300002)(86362001)(6436002)(55016002)(52536014)(14454004)(478600001)(966005)(9686003)(6306002)(229853002)(7736002)(305945005)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3531; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ikhi+Oax5bZ+uJFGSMYqHVxI+5c5mcMa+ax72Mewu3toBkGXeQl7yf96V6Y81mdi8/mG8a0DZ0bwfGMrf9VhrqcxxD0lE1g/VVvXcM8tGh7S54+rY7gDzFwrIPMwe36ntmEKMmlhEjowXxSSpzZjgsq5N1XPZT9Ji9Qg3EvN/DPieaSOQMBlYm/BwQqy4m5ytHknp3RNFevVE1Q6SHjdp6UuEQn+jPE7eoEhE3MyTZx4y0YcajDZ10wC3dtwRV6CtG0aO4FwQk5GyQXvbmX91gNJQGjWkCKjkb7NUWVGMqPM8Q0p06dUii5gmve1Z0ZfqGtGjzPQ39/O/tWl8YHDE0D/66pHv/HaLGUcbxY/llheuoRXNQ88GnV1jGbJGKRd94A66n1CpIjIDirzASr+HNhCuZtsEd2soBzhn977CjM= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6e90b97c-aeb3-4de6-850b-08d6eff6cbf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 12:00:58.1540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3531 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 12:01:06 -0000 Hi, Late feedback, but its ambiguous in the draft how vendor default Cloud Regi= strar https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-2= 0#section-2.7 and redirects as described in https://tools.ietf.org/html/dra= ft-ietf-anima-bootstrapping-keyinfra-20#section-5.6 should interact. Should the cloud registrar redirect immediately in response to the voucher = request, so that the pledge then sends the voucher request via a local doma= in RA? Should the cloud registrar issue a voucher, and then the redirect happens d= uring the EST enrol flow? When redirected, what trust anchor database should the pledge use? It seems like: - the cloud registrar should redirect to the local Registrar immediately an= d not issue a voucher (and this assumes a level of sales channel integratio= n / ownership tracking so that the cloud registrar knows which registrar ow= ns the pledge) - the pledge should use the implicit trust anchor database for the initial = connection to the cloud registrar, but then revert to standard provisional = TLS connection for the initial connection to the local Registrar - the pledge may include a proximity-registrar-cert in the new voucher requ= est to the local Registrar Doing the redirect immediately facilitates proximity assertions in the vouc= her request and associated audit logs in the MASA, and allows the MASA to d= iscover the local domain CA from the voucher request signature. Maybe a cla= rifying sentence in section 2.7 would help? Regards, Owen -----Original Message----- From: Anima On Behalf Of The IESG Sent: 21 May 2019 22:21 To: IETF-Announce Cc: ibagdona@gmail.com; draft-ietf-anima-bootstrapping-keyinfra@ietf.org; a= nima@ietf.org; anima-chairs@ietf.org; tte+ietf@cs.fau.de Subject: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Sta= ndard The IESG has received a request from the Autonomic Networking Integrated Mo= del and Approach WG (anima) to consider the following document: - 'Bootstra= pping Remote Secure Key Infrastructures (BRSKI)' as Proposed Standard This is a second Last Call. IoT Directorate review was done after the ANIMA= WG Last Call and consensus to request the publication, and that review res= ulted in substantial changes to the document. =20 The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2019-06-04. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ba= llot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2816/ https://datatracker.ietf.org/ipr/3233/ https://datatracker.ietf.org/ipr/2463/ The document contains these normative downward references. See RFC 3967 for additional information:=20 rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Ne= twork Operations, Administration, and Maintenance (OAM) (Informational - IE= TF stream) _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Thu Jun 13 07:29:25 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B817B1202D8 for ; Thu, 13 Jun 2019 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gALnJNr2JpDK for ; Thu, 13 Jun 2019 07:29:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C66120111 for ; Thu, 13 Jun 2019 07:29:09 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 965B2380BE; Thu, 13 Jun 2019 10:27:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 97E0DFD8; Thu, 13 Jun 2019 10:29:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 956F6F4A; Thu, 13 Jun 2019 10:29:08 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Carsten Bormann , Julian Reschke , draft-ietf-pkix-est@ietf.org, ietf-http-wg@w3.org, Anima WG , "Panos Kampanakis \(pkampana\)" In-Reply-To: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 14:29:24 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > I am looking at libest and it certainly generates the header. How does it react to the absense of the header? (or the header containing "binary") Does it process binary directly in that case? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0CXbQACgkQgItw+93Q 3WWmzAf7B7Li+28LMjBkJye+zWzhVxdu8kyiOu0dkkkHJuI5zqZNuxe3VybtIHqP 0OR9UxKAaIYbOhe+rzAOZWSQ0lha9B9KVn/EsZRCThjH99QBHiFwOS5Q2kz4nih6 qNNW/lL8rPo2nNrzm/gueIToJRZ2+kKbG27/3yExiZ+sqxBY6S3ewbK/EpH9//BP A5qHd+aZQJrB3eSOVpJSQZEUsBXjzcXCW7801Cea4rOb7rO7+d33slXrQkWcPFbQ fF/o/adbpFSdSg02nbC7xOryIZelKLrdS8zr7B5r0pMvQOFT9AGHhb7HapDn/KEO m6T1TIkFwQBUPSRMAsiW6wQklO2iCQ== =dvRW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 13 07:54:11 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8B1201EF; Thu, 13 Jun 2019 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ziZUkzM1y8C1; Thu, 13 Jun 2019 07:54:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23434120328; Thu, 13 Jun 2019 07:53:47 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 91BDA380BE; Thu, 13 Jun 2019 10:52:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 804F1FD8; Thu, 13 Jun 2019 10:53:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7DC7EF4A; Thu, 13 Jun 2019 10:53:46 -0400 (EDT) From: Michael Richardson To: "Owen Friel \(ofriel\)" cc: "ietf\@ietf.org" , IETF-Announce , "ibagdona\@gmail.com" , "draft-ietf-anima-bootstrapping-keyinfra\@ietf.org" , "anima-chairs\@ietf.org" , "anima\@ietf.org" , "tte+ietf\@cs.fau.de" In-Reply-To: References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 14:54:03 -0000 --=-=-= Content-Type: text/plain Owen Friel (ofriel) wrote: > Late feedback, but its ambiguous in the draft how vendor default Cloud > Registrar > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7 > and redirects as described in > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6 > should interact. > Should the cloud registrar redirect immediately in response to the > voucher request, so that the pledge then sends the voucher request via > a local domain RA? The cloud registrar concept is not intended to be a normative part of BRSKI. We went through a bunch of text to try to make that clear, but maybe we have still failed. We are simply saying that a pledge MAY do something else, such as direct EST back to the manufacturer, and you are astute to realize that the manufacturer might redirect to the customer's Internet visible Registrar. Please feel free to start a document that explains this, as I have this as part of a back of the envelope design as well. We think it's a large ocean, and we think that NETMOD ZERO TOUCH has some really good ideas here too. We are also trying to keep the door open to completely autonomous networks, where even the Registrar bootstraps itself: draft> In such a future situation, the device might use this draft> management interface to learn that it should configure itself to draft> become the local registrar. As such, I think that your questions and feedback are "future work" 5.6 has the text: draft> In order to avoid infinite redirect loops, which a malicious draft> registrar might do in order to keep the pledge from discovering the draft> correct registrar, the pledge MUST NOT follow more than one draft> redirection (3xx code) to another web origins. EST supports draft> redirection but requires user input; this change allows the pledge to draft> follow a single redirection without a user interaction. We had to say something about redirection, because EST supports it. We decided that we would permit a single redirection, but we did not have a definite operational reason for this, we just felt it was important. In most cases, the pledge connects to the Registrar using a proxy, so the pledge actually cannot decide to connect elsewhere. It always connects through the proxy, and the proxy does not interpret the URL. So, the only useful redirection that makes sense is to a different URL and/or virtual Host: on the same end point. This might be done for reasons of load balancing, or to leverage the EST domain concept. We did not want to predict or proscribe something here, just to make the pledge did not get into an infinite redirect loop, yet still permit 3xx codes to be useful in the future. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0CY3oACgkQgItw+93Q 3WUciQgAltf8nCitQAEbuMEuUv22IcXyBMgq+i0wz02ITmwzvThTqvRKK87V7aaM ZwXIqrv5vDWdQYfeSOr2nOMnmY+nJ7kGuvYrhHqMtiAa8FZpELWGDCbXVEQUsQYA 1/7805sLu0rcLSQrY7rNoVvOWCLQNeZgBMHeNlceCn2KjNp3ij2pdH+sxA3JKqTN GgtGF2jhtv12eIbYk+Fg+30pyvwPq70Rngzo8Bj74APMzneNa8Qc7g7Xue2sxSeG Ldp4vgUeV+R/hb2NRahdmY12PbI/5a7oKQ8/SGJT4rP51SLVlRAluZz7Pv4enU0w rqodfDJyCGC4j3gqvZMQapjLHG0v7g== =Cx/P -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 13 09:19:16 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98437120199; Thu, 13 Jun 2019 09:19:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156044275451.12681.11478498087850055628@ietfa.amsl.com> Date: Thu, 13 Jun 2019 09:19:14 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-21.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 16:19:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-21.txt Pages : 96 Date : 2019-06-13 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-21 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 13 09:23:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66F1201C3 for ; Thu, 13 Jun 2019 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NP8Vumvbg0Qv for ; Thu, 13 Jun 2019 09:23:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CA41200FF for ; Thu, 13 Jun 2019 09:23:36 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A76DF380BE for ; Thu, 13 Jun 2019 12:22:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A8B22FD8; Thu, 13 Jun 2019 12:23:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A6389F4A for ; Thu, 13 Jun 2019 12:23:34 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <156044275451.12681.11478498087850055628@ietfa.amsl.com> References: <156044275451.12681.11478498087850055628@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-21.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 16:23:39 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-21.txt > Pages : 96 > Date : 2019-06-13 ... > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-21 I have reposted the document primarily to update an author's email that has changed, and who is not getting last call review comments. There are three minor edits relating to review comments that you can see in the diff. In addition, the examples are being updated, and I see that the automated conversion has not entirely done the job that I desired, with some excess BEGIN CMS lines, and some lines not wrapped at all. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0CeIYACgkQgItw+93Q 3WVrSgf/WuOjm6kZhccjwNRbPjXM992RWbFPd1T2PdlHSMFErxwsO6XFvMrtiy1k 7Y5YKRaVu33i9HitWpf2D9JuHA7hbBjD98X0PYOyZH5R/lu3161aHoVvlRFBAjQ2 jai0TDFOwjgIT08tFs28NiqcZF4y4GRTU3aAYwaGPAU79/X0CysvDO5qYcNytL2o 7cRikq2KwLH8z+bCHKOkWvfzKFCxfWgbUei3BRClg0w9U8aejEk9jY3Xn4lYg3wk Or9dbUKJ+B/1ICY6dKhyoGsOXBampz0CpYOhH7dMm7x2syg0TW+yPP5QGsWW7kX9 karTp4NxRIM6JTZ43h6m/5cbfFv2wg== =MtWJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 13 10:18:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B591202D5 for ; Thu, 13 Jun 2019 10:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 header.b=hIHkKdLn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ax8+GpwH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW7JFMxuYXUm for ; Thu, 13 Jun 2019 10:18:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612D0120232 for ; Thu, 13 Jun 2019 10:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8275; q=dns/txt; s=iport; t=1560446321; x=1561655921; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XhLSO/HGUNOw+INotjmzdU1+MVvvUJnAvcFzEiCXwnE=; b=hIHkKdLnHjERcdPmkNYwbMxWLggXEwwCgTEMW7lBNRy+1RupztE+HkHK RYnxzBFGAjO6cBzQc3/+zpVTONh7f9/Wd2RGzLPjXEP/PPTWr9sKS3GNW TZcRWX8Jj4VxgQpmrHAlzOx4Z5Y52gedp7O/+n6yzWP4gd4Pb4BJedOuC s=; IronPort-PHdr: =?us-ascii?q?9a23=3AUQIlTxMyTFSfGq2bPvMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAD5hAJd/4oNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ4vUANqVSAECygKh1MDjmKCV5JghFO?= =?us-ascii?q?BLoEkA1QJAQEBDAEBIwoCAQGBS4J1AoJJIzYHDgEDAQEEAQECAQRtHAyFSgE?= =?us-ascii?q?BAQECARIbEwEBNwEECwIBCBEEAQEBJwcyFAkIAgQBCQQFCBqDAYEdTQMODwE?= =?us-ascii?q?CDJ9+AoE4iF+CIoJ5AQEFgUZBgnkYgg8DBoE0AYtcF4FAP4ERRoIeLj6CGkc?= =?us-ascii?q?CAwGBRxgrCYMGgiaOCIUgligJAoIQhkeNIJcsiVmDQocajzgCBAIEBQIOAQE?= =?us-ascii?q?FgVYBMIFYcBWDJ4IPg3CFFIU/coEpjmsBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,369,1557187200"; d="scan'208,217";a="287019059" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jun 2019 17:18:37 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x5DHIb13002692 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Jun 2019 17:18:37 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Jun 2019 12:18:36 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Jun 2019 13:18:31 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 13 Jun 2019 12:18:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oC717UqnbcKtyK371/bYKKB3caiwaWpwItp9YA+xw6U=; b=Ax8+GpwHWdnMZFat0qdYO9h2aNoIKVb4SuWkBunFSHnrV48ca4aC0griM5U7oGZI9wP+Nsqsf0ra162F4dJKzD5GgVYXT+xP2PsQvZXYwNMBHRGf3Xv/75tw/3QZYLOqnQRpfkPLceLRsizute2L9E3n+d31HJy9ZsV7twPUZAw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2817.namprd11.prod.outlook.com (52.135.246.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Thu, 13 Jun 2019 17:18:30 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1987.012; Thu, 13 Jun 2019 17:18:30 +0000 From: "Panos Kampanakis (pkampana)" To: Michael Richardson , Eliot Lear CC: Carsten Bormann , Julian Reschke , "draft-ietf-pkix-est@ietf.org" , "ietf-http-wg@w3.org" , Anima WG Thread-Topic: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI Thread-Index: AQHVIdoDl1v+cVRF/keZkXS6xeh3nKaZpQQAgAAHCkA= Date: Thu, 13 Jun 2019 17:18:30 +0000 Message-ID: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> In-Reply-To: <909.1560436148@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05ff792d-48ad-4455-8bee-08d6f02327fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2817; x-ms-traffictypediagnostic: BN7PR11MB2817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(39860400002)(396003)(199004)(189003)(966005)(316002)(52536014)(25786009)(4326008)(2906002)(8936002)(229853002)(3846002)(26005)(6116002)(6306002)(9686003)(5660300002)(305945005)(74316002)(7736002)(478600001)(76176011)(68736007)(186003)(7696005)(6636002)(81156014)(81166006)(8676002)(6246003)(53936002)(66066001)(256004)(86362001)(71190400001)(71200400001)(6506007)(6436002)(33656002)(102836004)(55016002)(14454004)(30864003)(76116006)(476003)(486006)(73956011)(66446008)(64756008)(66556008)(66476007)(99286004)(110136005)(54906003)(11346002)(66946007)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2817; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: feFYD5yynxl2VUnYZrBtbu7FnfgA3L05oZzEkQZV9HLI65Azq8eMgKgRtg+WX5uXLK+vW6hCVxPtPCBbt+yk1YXgdQyu6WI84n23XPylILefT+3PNqpH4Rh7Y+8BIUL9kEcySh/CIxGgGrhut/7NqUi5LAKOhC43go93hNc25mVXJ5TbDItwj9bum/vTaQswOWgejG9BXKg4Sf91zJb2/zJvghRMtQby84gM4A2Mhj/a50duvEGrOc4jfeYfnfsgmtiCgGxHURbAZGrLoXz/YIfvRC+rStk9YVqX7MKWpSdnY+ydMXu8RwK8qIPhjKVMxqYku5+1ZMUk5Z+ahTwPWs0Y+CpbPEeMcK4P8jdn0jS/x9rqxjvFw5uVFliukK/EqQnFTo7WQyWer47oLWIfRaGyL4aPZXbCeIb8k0Uv3W8= Content-Type: multipart/alternative; boundary="_000_BN7PR11MB25473A12F646FAC8C19C1118C9EF0BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 05ff792d-48ad-4455-8bee-08d6f02327fb X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 17:18:30.2623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2817 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 17:18:52 -0000 --_000_BN7PR11MB25473A12F646FAC8C19C1118C9EF0BN7PR11MB2547namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The libest server or proxy will generate the CTE header as specified in RFC= 7030. The libest client will parse it, but it will not reject the response = if the header is not there. It expects base64 encoded PKCS#7, not binary th= ough. Note that in https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est= / we assume all cert payloads are binary. Now, I don't know how other EST clients would act. There are many out there= by now that we can't safely tell if they would act up. The commercial and enterprise CAs I tested with interoped fine with the lib= est client and they were not all sending the CTE field. They payload was ba= se64 though. To address the erratum, I would lean towards a recommendation against using= the CTE header based on the referenced standards and state that base64 enc= oding is implied. Rgs, Panos _____________________________________________ From: Michael Richardson > Sent: Thursday, June 13, 2019 10:29 AM To: Eliot Lear > Cc: Carsten Bormann >; Julian Reschke >; draft-ietf-pkix-est@iet= f.org; ietf-http-wg@w3.org; Anima WG >; Panos K= ampanakis (pkampana) > Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI * PGP Signed by an unknown key Eliot Lear > wrote: > I am looking at libest and it certainly generates the header. How does it react to the absense of the header? (or the header containing "binary") Does it process binary directly in that case? -- Michael Richardson >, S= andelman Software Works -=3D IPv6 IoT consulting =3D- * Unknown Key * 0xDDD0DD65 --_000_BN7PR11MB25473A12F646FAC8C19C1118C9EF0BN7PR11MB2547namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The libest server or proxy will generate the C= TE header as specified in RFC7030. The libest client will parse it, but it = will not reject the response if the header is not there. It expects base64 = encoded PKCS#7, not binary though. Note that in https://datatracker.ietf.org/doc/draft-i= etf-ace-coap-est/ we assume all cert payloads are binary.
 
Now, I don’t know how other EST clients = would act. There are many out there by now that we can’t safely tell = if they would act up.
 
The commercial and enterprise CAs I tested wit= h interoped fine with the libest client and they were not all sending the C= TE field. They payload was base64 though.
 
To address the erratum, I would lean towards a= recommendation against using the CTE header based on the referenced standa= rds and state that base64 encoding is implied.
 
Rgs,
Panos
 
_____________________________________________
From: Michael Richardson <mcr+ietf@sandelman.ca&g= t;
Sent: Thursday, June 13, 2019 10:29 AM
To: Eliot Lear <lear@cisco.com>
Cc: Carsten Bormann <cabo@tzi.org>; Julian Reschke <julian.reschke= @gmx.de>; draft-ietf-pkix-est@ietf.org; ietf-http= -wg@w3.org; Anima WG <<= font color=3D"#0563C1">anima@ietf.org>; Panos Kampanak= is (pkampana) <pkampana@cisco.com>
Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA= BRSKI
 
 
* PGP = Signed by an unknown key
 =
 =
Eliot = Lear <lear@= cisco.com> wrote:
 =    > I am looking at libest and it certainly generates the hea= der.
 =
How do= es it react to the absense of the header?
(or th= e header containing "binary")
Does i= t process binary directly in that case?
 =
--
Michae= l Richardson <mcr+IETF@sandelman.ca>, Sandelman Sof= tware Works
-=3D = IPv6 IoT consulting =3D-
 =
 =
 =
 =
* Unkn= own Key
* 0xDD= D0DD65
 
 
 --_000_BN7PR11MB25473A12F646FAC8C19C1118C9EF0BN7PR11MB2547namp_-- From nobody Thu Jun 13 13:33:39 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9B6120447 for ; Thu, 13 Jun 2019 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYKw7M36p5_6 for ; Thu, 13 Jun 2019 13:33:36 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0: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 B0A5C1202AA for ; Thu, 13 Jun 2019 13:33:36 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id s21so142438pga.12; Thu, 13 Jun 2019 13:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Um9M4nk5OXY6VJF1kJPzMjTwQXoFscI8WKV5NEtdbD4=; b=Bqnm63BNWfA+gGAosX4Zi5xXoqqMrgDRBh6eBxNLWmsaCJD/dRXOh13TWhZ0pHwwYT VdP+1xW6+pEvO6txl1K3j4yhvWTrlYvT8TRjMJN8j09ZRBYAwXtJrDFPH2md0rKImImf gYRz6ItGZcMcAY7hq5pazDz8yfKJe7rTTRtj2/GV0cYClcUMO8IbScQi2sM8RAdqFiUu Bk33Bo9ErEjf4MBt0RKq6Nasnx4LlAOrB/dhicEGroPSJAUgMgQA4olDZopW20vBezet LTnzhLC2GbBOlo+wHgZTS+RrXyOHhtp4Z0jD8AiqxCC+2Xb53s9qrmvIjFJCIhRRT1Ud E+mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Um9M4nk5OXY6VJF1kJPzMjTwQXoFscI8WKV5NEtdbD4=; b=adxYkOgDQWrqSblJxbNg5cZogKTN7ZGioGF4N+ms8sZbz20HusKHazd8lUknJP/znR O/K5dtOQh+Rc00dA7Oxp7yNWRuWafF23M6DI8FMu70/kPVHs5r+qecAWHn54ZFpdieGz Uj5n4ZOM2fhX0nqPT+hkraawklrxamFnXIlVgkZIfrQhNgElKeoteFjwvb97+DSpyMlD uZ9Mt0VCf1CvKhNJGUNiLI88e0Lhgz589bBk1p1F0pnJKUda+kRGpegEAC+iNr19TZjP z0bUWRQ4aiIUwMitewe+qY5X1I/FnohyopMVxkk0Ycpg0FYgejxneMYph81qaK5r0xEA h+Dw== X-Gm-Message-State: APjAAAUJqbeXvZVa/d8Doh29L0C4E3DSxlVI70m5g03WbnMiufTQEViO Zsiwl9KeR1a0NMrNQb/4W9LmHiEc X-Google-Smtp-Source: APXvYqyTTGrAUmD8ZhTW4s5lW6TUiz8/npRc2fDBTeuMfFowmA4FuJozfvqkXsQcugbkHlF2g3ZQoA== X-Received: by 2002:a17:90a:1b4a:: with SMTP id q68mr7361995pjq.61.1560458015681; Thu, 13 Jun 2019 13:33:35 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id u5sm610273pgp.19.2019.06.13.13.33.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 13:33:34 -0700 (PDT) To: "Panos Kampanakis (pkampana)" , Michael Richardson , Eliot Lear Cc: Julian Reschke , "draft-ietf-pkix-est@ietf.org" , Carsten Bormann , "ietf-http-wg@w3.org" , Anima WG References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> From: Brian E Carpenter Message-ID: <1b9a76bb-4b95-8e30-1fec-bb1fb011fab5@gmail.com> Date: Fri, 14 Jun 2019 08:33:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 20:33:39 -0000 On 14-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: > The libest server or proxy will generate the CTE header as specified in= RFC7030. The libest client will parse it, but it will not reject the res= ponse if the header is not there. It expects base64 encoded PKCS#7, not b= inary though. Note that in _https://datatracker.ietf.org/doc/draft-ietf-a= ce-coap-est/_ we assume all cert payloads are binary. > =C2=A0 > Now, I don=E2=80=99t know how other EST clients would act. There are ma= ny out there by now that we can=E2=80=99t safely tell if they would act u= p. > =C2=A0 > The commercial and enterprise CAs I tested with interoped fine with the= libest client and they were not all sending the CTE field. They payload = was base64 though. > =C2=A0 > To address the erratum, I would lean towards a recommendation against u= sing the CTE header based on the referenced standards and state that base= 64 encoding is implied. https://tools.ietf.org/html/rfc7231#appendix-A from June 2014 makes it al= l very plain. However, there is a small problem of running code. There's already an erratum: https://www.rfc-editor.org/errata/eid5107 For whatever reason, it is sitting in state "reported" since 2017. Brian From nobody Fri Jun 14 11:35:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFB120431 for ; Fri, 14 Jun 2019 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 jvhB9FM23x10 for ; Fri, 14 Jun 2019 11:35:12 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3DE12011C for ; Fri, 14 Jun 2019 11:35:12 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Jun 2019 11:35:06 -0700 From: To: 'Michael Richardson' , 'Thomas Werner' , 'consultancy' , References: <28559.1558924665@localhost> In-Reply-To: <28559.1558924665@localhost> Date: Fri, 14 Jun 2019 11:35:04 -0700 Message-ID: <007101d522df$e41217a0$ac3646e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQI6C3zosouMnyM+R/zZmAatMjR9kqXRqA9g X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] constrained voucher examples updated --- voucher looks wrong X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 18:35:15 -0000 So for kicks I did a quick run through the CMS side of things Looking at the example in A.3.1 - there does not appear to be any content in the message. It has a content type of 'data', but the content itself is detached. Is this intended? Jim -----Original Message----- From: Michael Richardson Sent: Sunday, May 26, 2019 7:38 PM To: Thomas Werner ; consultancy ; anima@ietf.org Cc: Jim Schaad Subject: constrained voucher examples updated --- voucher looks wrong I have updated the appendix to draft-ietf-anima-constrained-voucher, which contains the COSE signed CBOR vouchers. I have included base64 of the binary, as well as CBOR diagnostic format. Please see: https://github.com/anima-wg/constrained-voucher/blob/master/constrained-vouc her.txt#L2218 I am including the private (EC) keys in PKCS1 form ("BEGIN EC PRIVATE KEY"), perhaps I should use PKCS8/RFC5208 format ("BEGIN PRIVATE KEY") instead? Thomas, and Jim, would you take a crack at validating the voucher-request and parboiled (Registrar signed) voucher requests from these files? The raw binary files are at: https://github.com/anima-wg/constrained-voucher/tree/master/examples along with the public keys. It's just COSE signatures. In doing this, I've discovered a bug in my code, and I believe it needs to be fixed. Specifically, it appears at line: https://github.com/anima-wg/constrained-voucher/blob/master/constrained-vouc her.txt#L2478 You'll notice: "00-D0-E5-F2-00-02", 11: "rIe_64PzENXdd32FApWcMQ", 12: "MII B5TCCAWugAwIBAgIBATAKBggqhkjOPQQDAjBzMRIwEAYKCZImiZPyLGQBGRY that is, I've pinned the *base64* encoding of the registrar's DER encoded certificate, rather than the DER encoding itself. This is clearly wrong, but I do it consistently and tolerantly so I don't notice. I will be fixing this. However, the signature on the resulting object should be correct, even if the contents are semantically wrong. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Mon Jun 17 08:55:33 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA621201CE for ; Mon, 17 Jun 2019 08:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 5V_8DWvCvzna for ; Mon, 17 Jun 2019 08:55:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6631C120254 for ; Mon, 17 Jun 2019 08:55:27 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id B040E1F450; Mon, 17 Jun 2019 15:55:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CEEF13810; Mon, 17 Jun 2019 11:55:35 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, lamps@ietf.org, Sean Turner cc: max pritikin , Benjamin Kaduk , Ignas Bagdonas X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 11:55:35 -0400 Message-ID: <6535.1560786935@dooku.sandelman.ca> Archived-At: Subject: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 15:55:32 -0000 --=-=-= Content-Type: text/plain I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? 2) is this appropriate for LAMPS? 3) independant submission seems wrong. 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0Ht/cACgkQlUzhVv38 QpCkgAf/c6Kza/QrrSPw+pa7JmxIjKquG7RafXr31ao9cSlgUHrYbmlAUSXlgiLA gmVRiZxpEJY2NANpPlXTqBB/cacBzTW54wLKJSRRxfBWT/8r0nodo9aOJ3iBUWSQ 40k74FPZ5e4RggSEBxKzLoG7v06U0ldVLRqkRcP42hiMRY5vVppLnOvP0PyQyGyN zXoZ4camPVZkBGQBETzxax0FlybtfSsiFLBIAxJ8JtAzG9Sj6999zk4KjRzLU9S0 y0KtbpRTULx+2cc5zzQi/5fVpLAaM0C8XDKet1WPTVpqopjY7glbjjqGUknf4sZe HftXviolyGTK3s2/g7aA7aedKgBqIw== =eQSM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 09:20:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2787912033E for ; Mon, 17 Jun 2019 09:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0piQIB1Xbfbg for ; Mon, 17 Jun 2019 09:20:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335D2120356 for ; Mon, 17 Jun 2019 09:20:11 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id A19C41F450; Mon, 17 Jun 2019 16:20:08 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 7DE563810; Mon, 17 Jun 2019 12:20:17 -0400 (EDT) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" cc: Eliot Lear , Carsten Bormann , Julian Reschke , "draft-ietf-pkix-est\@ietf.org" , "ietf-http-wg\@w3.org" , Anima WG In-reply-to: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> Comments: In-reply-to "Panos Kampanakis (pkampana)" message dated "Thu, 13 Jun 2019 17:18:30 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 12:20:17 -0400 Message-ID: <8921.1560788417@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:20:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Now, I don=E2=80=99t know how other EST clients would act. There are many= out > there by now that we can=E2=80=99t safely tell if they would act up. > The commercial and enterprise CAs I tested with interoped fine with > the libest client and they were not all sending the CTE field. They > payload was base64 though. I didn't read this well enough before. So effectively, the CTE header has effectively been dropped, but the payload is now assumed to be base64, regardless. This suggests that we can not use the CTE header as a signal. One has to assume base64 encoded values for the RFC7030 end-points. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0HvcAACgkQlUzhVv38 QpDFVgf/YpDiW9lww+VQ4rlGQW42Ztk2H+LBaYnc8qM/BiSDo9eSHrnc1UmKJVl+ LinG0+gJ5+n2V6gKZhHYpuc5qBpWTlc7ua1gKqEixAm9DSwhRrxtAJk8ZRfmG4HP R2BrzY6yoffWMuBWi243ji8lSl0qDkw9/177eU4SKhBaJJ5d0e+IM7gFUu/jYcUS bpOUMZe2biB0TOjZsICQO1v7y5Y7XNR2vzpX5ypKgdiYfQD5Uovj+gb1KWponNWy pZP3yxAOXj515YjYSOosZZRBQJM4e/xZLR/hBPjqKIsDGNPPHdGc6O61d2+ysWDp f4nrQNNFrrBgBtTCVPn/uVfdSDb9bg== =3EVx -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 09:21:45 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C356B120297 for ; Mon, 17 Jun 2019 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDTQmXtAOFgS for ; Mon, 17 Jun 2019 09:21:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9C0120362 for ; Mon, 17 Jun 2019 09:21:26 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 057421F450; Mon, 17 Jun 2019 16:21:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 24EE23810; Mon, 17 Jun 2019 12:21:35 -0400 (EDT) From: Michael Richardson To: "ietf-http-wg@w3.org" , Anima WG , lamps@ietf.org In-reply-to: <1b9a76bb-4b95-8e30-1fec-bb1fb011fab5@gmail.com> References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <1b9a76bb-4b95-8e30-1fec-bb1fb011fab5@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Fri, 14 Jun 2019 08:33:29 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8961.1560788495.1@dooku.sandelman.ca> Date: Mon, 17 Jun 2019 12:21:35 -0400 Message-ID: <8962.1560788495@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:21:45 -0000 Brian E Carpenter wrote: > https://tools.ietf.org/html/rfc7231#appendix-A from June 2014 makes it > all very plain. However, there is a small problem of running code. > There's already an erratum: https://www.rfc-editor.org/errata/eid5107 > For whatever reason, it is sitting in state "reported" since 2017. I'd like to get this unstuck. I think that LAMPS is the place to do this, but I could be wrong. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Mon Jun 17 09:31:48 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD3D12035B for ; Mon, 17 Jun 2019 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexLPMvax6c8 for ; Mon, 17 Jun 2019 09:31:44 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E06120354 for ; Mon, 17 Jun 2019 09:31:43 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 62CD01F450; Mon, 17 Jun 2019 16:31:42 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8BA133810; Mon, 17 Jun 2019 12:31:52 -0400 (EDT) From: Michael Richardson to: anima@ietf.org, spams@ietf.org, Ignas Bagdonas , max pritikin , Benjamin Kaduk In-reply-to: <6535.1560786935@dooku.sandelman.ca> References: <6535.1560786935@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 11:55:35 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 12:31:52 -0400 Message-ID: <10505.1560789112@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:31:47 -0000 --=-=-= Content-Type: text/plain Resending with correct LAMPS ML name of "SPASMS". I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? 2) is this appropriate for LAMPS? 3) independant submission seems wrong. 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0HwHgACgkQlUzhVv38 QpBNmgf/d9mE2uNG7j30MqWDeaigDN6gc71jfb25iwlSQ9iKnJT6doinoorkCtDa hOGsUJnTXKT+1zOrmrp7/xdzqadSwnNOBPVM77r1t8/nHH5qBoApck0IZPi0W5az +XKLb5NtnV+UA4bLFXkPTu4RXg6bGlV/hkeCglBICr4Lk3pnG83YIHBNtAUL5snv 7oRk4Ncb2C/Xipd0OOMImaJ7XxY+D2ndxQBr+71ETUp3S7d5Sb3WUlR+ya1+DmQI kwcBajxxBo3i5a7fVLK+L+FZ4Bjq1q7GdoXo7ZEC+PhENVSeNpsapHv0wKRgDLfk cVvOigm3y2ilzKeYC5LRnz7yx0d+Mw== =Im9p -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 09:58:22 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1687120136; Mon, 17 Jun 2019 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak2LfH9lnilV; Mon, 17 Jun 2019 09:58:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAE41200E3; Mon, 17 Jun 2019 09:58:16 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.133]) by relay.sandelman.ca (Postfix) with ESMTPS id C6E941F450; Mon, 17 Jun 2019 16:58:14 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CB0EF3810; Mon, 17 Jun 2019 12:58:24 -0400 (EDT) From: Michael Richardson to: spasm@ietf.org, anima@ietf.org In-reply-to: <10505.1560789112@dooku.sandelman.ca> References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 12:31:52 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 12:58:24 -0400 Message-ID: <12718.1560790704@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:58:20 -0000 --=-=-= Content-Type: text/plain Resending a third time, with correct LAMPS ML name of "SPASM" (no trailing S!). My sincere appologies. I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? 2) is this appropriate for LAMPS? 3) independant submission seems wrong. 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- [[End of PGP Signed Part]] _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0HxrAACgkQlUzhVv38 QpC+zgf/QPmRfr9t1sVZO/CGyDIHoN4ODQkn7cAOpemhep3YD0NJsWxhHI9oQ9o7 0wR4JUoDtAmtg7wR/+zmOSRRu1I4lZNXVCXdDJzqjIgceUAbwcacoyFkX2bQW3NH 8cm1jiuaUm/dblzxMvAkMSquLnXXBlaQ+VlU8yG64sBcM6A01JLVGg4wke6W8whJ deNiEYXT0KxsiQnyPy9M3Mk0QuYbRt6F+9GL+NjqbXlJfHXXWrJ41Xct8mwCwO60 yMxqdC4+mP30d3F7IiWqOjmY+kopsxwFdYFsqWLqqZVNQyLp1sOJ5Kwrxc4hGJXr 7t5B/bMiU4HAJXCs+7ARlkHNp4RCiw== =nSk0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 10:18:26 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B919812027F for ; Mon, 17 Jun 2019 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 header.b=PFXtbiSd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tU7+IuFA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUX4oxapkM3N for ; Mon, 17 Jun 2019 10:18:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937BB120265 for ; Mon, 17 Jun 2019 10:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1560791889; x=1562001489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K1PikxvNu4mJFkwUfspWBloiYgBfToCAKqAT0XzmI/A=; b=PFXtbiSdQg8GmEmvJs47hbQUiBXqLRgq4o1A74GgdQKz4MVpqy8DW+f7 o2KhdoINQAGqNVXB8ECShcOwjfbCmeqJkvsZTvTGGLNnlDpVlPvEnF8/E jg7Pr9qxeXNy99ISb482imxpRk7HFbADeLukL4Bp3Y80cxb7GhVYE7D0c w=; IronPort-PHdr: =?us-ascii?q?9a23=3AtkKzsBMH8aZn9NksIJMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjjL/fvdyU8FexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADEygdd/4gNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT1QA2pVIAQLKAqEDINHA4RSihGCV5c2gS6BJANUCQEBAQw?= =?us-ascii?q?BAS0CAQGBS4J1AheCNSM0CQ4BAwEBBAEBAgEEbRwMhUoBAQEDARIREQwBATc?= =?us-ascii?q?BBAcEAgEIEQQBAQMCJgICAjAVCAgCBAoEBQgagwGBagMODwECnX0CgTiIX3G?= =?us-ascii?q?BMYJ5AQEFhHsYghAJgQwoAYtdF4FAP4FXgh4uPoIagiwVgnMygiaODi2NPo1?= =?us-ascii?q?mCQKCEJNtgieLDYl8iVuaJQIEAgQFAg4BAQWBUDiBWHAVgyeCDwwXg02KU3K?= =?us-ascii?q?BKY1+AYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,386,1557187200"; d="scan'208";a="356091216" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2019 17:18:08 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5HHI8kN003637 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jun 2019 17:18:08 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 12:18:07 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 12:18:06 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Jun 2019 12:18:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K1PikxvNu4mJFkwUfspWBloiYgBfToCAKqAT0XzmI/A=; b=tU7+IuFAczGu0AXIpMtemqDI5Y4WPQgrLtd1EoiUFr7b+M51l331YYr/A6H0o4BT07ab77dWw/HGdvRrksUxAaF+L3prDiCZUynEl16Ed/YueomcD8v8b8qmklLbBMxSqHFeI0CiR6fI5iD5V829Pilc44g5bmMahAWOHNHRw+Y= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2817.namprd11.prod.outlook.com (52.135.246.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.15; Mon, 17 Jun 2019 17:18:05 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::89af:3fb4:eae5:18b2%7]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 17:18:05 +0000 From: "Panos Kampanakis (pkampana)" To: Michael Richardson CC: Eliot Lear , Carsten Bormann , "Julian Reschke" , "draft-ietf-pkix-est@ietf.org" , "ietf-http-wg@w3.org" , Anima WG Thread-Topic: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI Thread-Index: AQHVIdoDl1v+cVRF/keZkXS6xeh3nKaZpQQAgAZoZW+AAAIRgA== Date: Mon, 17 Jun 2019 17:18:05 +0000 Message-ID: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> In-Reply-To: <8921.1560788417@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93dac53a-b1f5-4b56-4cb4-08d6f347c2b8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2817; x-ms-traffictypediagnostic: BN7PR11MB2817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(136003)(396003)(366004)(13464003)(189003)(199004)(74316002)(4326008)(6246003)(68736007)(478600001)(99286004)(446003)(26005)(66066001)(102836004)(71200400001)(5660300002)(54906003)(76176011)(11346002)(71190400001)(14454004)(316002)(6506007)(186003)(53546011)(33656002)(7696005)(53936002)(6116002)(9686003)(305945005)(7736002)(2906002)(86362001)(486006)(73956011)(76116006)(3846002)(25786009)(81156014)(66446008)(66556008)(64756008)(66476007)(256004)(66946007)(6436002)(81166006)(8676002)(8936002)(476003)(52536014)(55016002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2817; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uoFQPvX3/LFEmIrypywG9zU/Cu/M+wTA7m+p9oh+hrz7beOjX8DJ9pmekrEbKUrsFGR/NO2it0/+D//Bczl6mwiZJIccO9P909O74BBdKYXsdJZBbGId58FFKocd3iovRN7Mnv9Zvm0z5qVQLw8Li9L9Bp+8BcB/cacYDB1rS13MJUk19ooSK7KNM7izthDJ/cei2pAQGlXMqhxjP+evz+slaFp/fjJPo2uwDYSADtO1qX0YbT2YGIsTDVBcpDCn6oJra3vcHawVMYVwfCSaryJE4DbvuT/0hdOvbQvCOhvPJUvkSFnd4vCoBSTw0XdFKLTc5KKsQ4u7qb7NVLmL0CjkC8Rpk31ZgdwIm1g0mI6i6/5+AlhpzKQPHtHe2BbS0aFNvzSaZ2bhYLQFTFIZdN7lfLqioFTXBDLvnPKjkS8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 93dac53a-b1f5-4b56-4cb4-08d6f347c2b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 17:18:05.2780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2817 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 17:18:24 -0000 PiBTbyBlZmZlY3RpdmVseSwgdGhlIENURSBoZWFkZXIgaGFzIGVmZmVjdGl2ZWx5IGJlZW4gZHJv cHBlZCwgYnV0IHRoZSBwYXlsb2FkIGlzIG5vdyBhc3N1bWVkIHRvIGJlIGJhc2U2NCwgcmVnYXJk bGVzcy4NCj4gVGhpcyBzdWdnZXN0cyB0aGF0IHdlIGNhbiBub3QgdXNlIHRoZSBDVEUgaGVhZGVy IGFzIGEgc2lnbmFsLg0KDQpJIGFtIG5vdCBzdXJlIEkgY2FuIHNwZWFrIGFib3V0IGFsbCBpbXBs ZW1lbnRhdGlvbnMgb3V0IHRoZXJlLCBidXQgdGhhdCBpcyB3aGF0IEkgc2F3IGluIG15IGludGVy b3AgdGVzdGluZy4NCg0KPiBPbmUgaGFzIHRvIGFzc3VtZSBiYXNlNjQgZW5jb2RlZCB2YWx1ZXMg Zm9yIHRoZSBSRkM3MDMwIGVuZC1wb2ludHMuDQoNCkluIGFsbCB0ZXN0cyBJIGRpZCB5ZXMuDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KU2VudDogTW9uZGF5LCBKdW5lIDE3LCAyMDE5IDEyOjIw IFBNDQpUbzogUGFub3MgS2FtcGFuYWtpcyAocGthbXBhbmEpIDxwa2FtcGFuYUBjaXNjby5jb20+ DQpDYzogRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20+OyBDYXJzdGVuIEJvcm1hbm4gPGNhYm9A dHppLm9yZz47IEp1bGlhbiBSZXNjaGtlIDxqdWxpYW4ucmVzY2hrZUBnbXguZGU+OyBkcmFmdC1p ZXRmLXBraXgtZXN0QGlldGYub3JnOyBpZXRmLWh0dHAtd2dAdzMub3JnOyBBbmltYSBXRyA8YW5p bWFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FuaW1hXSBDb250ZW50LVRyYW5zZmVyLUVuY29k aW5nIGFuZCBIVFRQIDEueCBpbiBBTklNQSBCUlNLSQ0KDQoqIFBHUCBTaWduZWQgYnkgYW4gdW5r bm93biBrZXkNCg0KDQo+IE5vdywgSSBkb27igJl0IGtub3cgaG93IG90aGVyIEVTVCBjbGllbnRz IHdvdWxkIGFjdC4gVGhlcmUgYXJlIG1hbnkgb3V0DQo+IHRoZXJlIGJ5IG5vdyB0aGF0IHdlIGNh buKAmXQgc2FmZWx5IHRlbGwgaWYgdGhleSB3b3VsZCBhY3QgdXAuDQo+IFRoZSBjb21tZXJjaWFs IGFuZCBlbnRlcnByaXNlIENBcyBJIHRlc3RlZCB3aXRoIGludGVyb3BlZCBmaW5lIHdpdGgNCj4g dGhlIGxpYmVzdCBjbGllbnQgYW5kIHRoZXkgd2VyZSBub3QgYWxsIHNlbmRpbmcgdGhlIENURSBm aWVsZC4gVGhleQ0KPiBwYXlsb2FkIHdhcyBiYXNlNjQgdGhvdWdoLg0KDQpJIGRpZG4ndCByZWFk IHRoaXMgd2VsbCBlbm91Z2ggYmVmb3JlLg0KDQpTbyBlZmZlY3RpdmVseSwgdGhlIENURSBoZWFk ZXIgaGFzIGVmZmVjdGl2ZWx5IGJlZW4gZHJvcHBlZCwgYnV0IHRoZSBwYXlsb2FkIGlzIG5vdyBh c3N1bWVkIHRvIGJlIGJhc2U2NCwgcmVnYXJkbGVzcy4NCg0KVGhpcyBzdWdnZXN0cyB0aGF0IHdl IGNhbiBub3QgdXNlIHRoZSBDVEUgaGVhZGVyIGFzIGEgc2lnbmFsLg0KT25lIGhhcyB0byBhc3N1 bWUgYmFzZTY0IGVuY29kZWQgdmFsdWVzIGZvciB0aGUgUkZDNzAzMCBlbmQtcG9pbnRzLg0KDQot LQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4g U29mdHdhcmUgV29ya3MgIC09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS0NCg0KDQoNCg0KKiBVbmtu b3duIEtleQ0KKiAweEZERkM0MjkwDQo= From nobody Mon Jun 17 13:44:52 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFB6120431 for ; Mon, 17 Jun 2019 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjYXHJ0GXqTb for ; Mon, 17 Jun 2019 13:44:48 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 740921203F3 for ; Mon, 17 Jun 2019 13:44:48 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id b7so4628888pls.6; Mon, 17 Jun 2019 13:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dENyHE9uA+ezvFczIuF9miBNRlR84E9Ptdi6ZFvBNQk=; b=Jxhd5nOXeSrY02QRvcwXLc9oR5RQqURtK9j0U+Qs1/YOdLxTR7MyxBiGa8c3bQalxh HQIUMJO5YVK/DHqlxjuH2iJo8KisQIcBhVD1qSeZbPSN1z6csX6K/j8CRtaGE2t6eNSu igEp5ueME9VXQlqBseTQiDIspM3rxFNAlrbnV/LgUROmLXTS9X87WytMN+qFxNX7DWGI sgxciLbGdblf4fuWb8qnrQUk+4HgXYEp/40A93eYT5D24WKHpMCE5id7z1P+y+SPXdMd CITEM7IgyeelE+D16IACekFz2ETjzEmgJV/KtBZGAe6CD6omgttiSlhGgMdZHRpStCUe DLNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dENyHE9uA+ezvFczIuF9miBNRlR84E9Ptdi6ZFvBNQk=; b=hLzaE4qOsbrQI54/nYOkb47jLMIltjjmkaPVk1ksClvOaIksQJwRL7h2eJ3tXp3aGf hc19dlwcz9X1Np+rdWnodwfAAaCcwNsu10PJiXL+K0OFT7NaB+ctP6HKxTAX9IobTE16 A7B0rd//KxkeKU5ZP3P411jPbqbHD5ktJYNyuUS/YUEyZOHL0OQJP2OfYptCgQOsHYl8 R4BXgzwaIK+k5gyFa0G3/NJ2uo3N8yJAALTyIGusRx9RVfG5ftAN46byJeB17P9w21A7 OHABUhHBoCzvbquZZoq7V7do8S5wsYxGFNaQ4saa+BeBXGrtmeuz7CySLtRykqJoc90T kLww== X-Gm-Message-State: APjAAAXeEl//ZB6kM0OpXdcpVvfhbintbqGDNcPMjxwOo4gceYg+kZjN Ww4PmwG86k8MyoIUgcPoWLIiN913 X-Google-Smtp-Source: APXvYqx4sprXCdtfWfJO1mG6Rn+Zlncz3bzlo5SLRYqj1oQezXUQhFz3M01gYgLPoWeNPCl4P1ExWg== X-Received: by 2002:a17:902:8ec3:: with SMTP id x3mr23020548plo.313.1560804287670; Mon, 17 Jun 2019 13:44:47 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id t8sm2243714pfq.31.2019.06.17.13.44.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 13:44:46 -0700 (PDT) To: "Panos Kampanakis (pkampana)" , Michael Richardson Cc: Eliot Lear , Julian Reschke , "draft-ietf-pkix-est@ietf.org" , "ietf-http-wg@w3.org" , Carsten Bormann , Anima WG References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: Date: Tue, 18 Jun 2019 08:44:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 20:44:51 -0000 On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: >> So effectively, the CTE header has effectively been dropped, but the p= ayload is now assumed to be base64, regardless. >> This suggests that we can not use the CTE header as a signal. I went and looked at RFC4648 for my own education, and then spent a few m= inutes trying to design a Turing machine that can distinguish a binary bit strin= g from a base64 bit string. Fail. You can determine that a bit string is definit= ely not base64 if it contains at least one character outside the base64 alpha= bet, but not the converse. So it needs a signal. Not having a signal would be = wide open to malicious misuse, IMHO. Indicating the length of the payload woul= d be enough, I think. Brian >=20 > I am not sure I can speak about all implementations out there, but that= is what I saw in my interop testing. >=20 >> One has to assume base64 encoded values for the RFC7030 end-points. >=20 > In all tests I did yes. >=20 >=20 > -----Original Message----- > From: Michael Richardson > Sent: Monday, June 17, 2019 12:20 PM > To: Panos Kampanakis (pkampana) > Cc: Eliot Lear ; Carsten Bormann ; Julian= Reschke ; draft-ietf-pkix-est@ietf.org; ietf-http= -wg@w3.org; Anima WG > Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BR= SKI >=20 > * PGP Signed by an unknown key >=20 >=20 >> Now, I don=E2=80=99t know how other EST clients would act. There are m= any out >> there by now that we can=E2=80=99t safely tell if they would act up. >> The commercial and enterprise CAs I tested with interoped fine with >> the libest client and they were not all sending the CTE field. They >> payload was base64 though. >=20 > I didn't read this well enough before. >=20 > So effectively, the CTE header has effectively been dropped, but the pa= yload is now assumed to be base64, regardless. >=20 > This suggests that we can not use the CTE header as a signal. > One has to assume base64 encoded values for the RFC7030 end-points. >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 > * Unknown Key > * 0xFDFC4290 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Jun 17 18:23:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2212034F; Mon, 17 Jun 2019 18:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, 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 5hMVyqCSxGyE; Mon, 17 Jun 2019 18:23:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4D6120344; Mon, 17 Jun 2019 18:23:47 -0700 (PDT) Received: from dooku.sandelman.ca (static-68-179-115-177.ptr.terago.net [68.179.115.177]) by relay.sandelman.ca (Postfix) with ESMTPS id 879651F450; Tue, 18 Jun 2019 01:23:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0D69948CE; Mon, 17 Jun 2019 21:23:29 -0400 (EDT) From: Michael Richardson To: Anima WG , spasm@ietf.org In-reply-to: References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> Comments: In-reply-to Brian E Carpenter message dated "Tue, 18 Jun 2019 08:44:43 +1200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 21:23:29 -0400 Message-ID: <10970.1560821009@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 01:23:50 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: >>> So effectively, the CTE header has effectively been dropped, but the >>> payload is now assumed to be base64, regardless. This suggests that >>> we can not use the CTE header as a signal. > I went and looked at RFC4648 for my own education, and then spent a few > minutes trying to design a Turing machine that can distinguish a binary > bit string from a base64 bit string. Fail. You can determine that a bit > string is definitely not base64 if it contains at least one character > outside the base64 alphabet, but not the converse. So it needs a > signal. Not having a signal would be wide open to malicious misuse, > IMHO. Indicating the length of the payload would be enough, I think. So I conclude that we can't patch RFC7030. We can drop the Content-Transfer-Encoding headers (and it seems that many have done that anyway), but we are stuck with a base64 encoded payload for the four end-points that 7030 describes. We could create new end-points that are not base64 encoded, but that does not seem that important. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0IPRAACgkQlUzhVv38 QpCY/gf+JhgBBvJAo1ve6cD4zTY2mgohlRuF/mYkQ4FW4Hp74IP6K5Bjb9kMrqMe VclwLow8BqjIo5UgY9th+W0FaTJnnrHPxpRE0TpIAOP83zlKfX+X1ZPRMYn0ACSW EgIjAGNi2Yl55ZO9yeRG9LNN6kIfF2/HB2DHDHb+IYDQlM/XKIqtAYr1Sm2MPsTm oXfThJzjqRdDt7xVEQ4skVcz3fmY46C/t2LDaaqxGjjHMDKdYmxV6zdrgTaOq3G1 MdEN2nQ34uYBOy8gtom6IUg3ibfRUHPdw0FRE7F75GfiGOt8/KQb4mT4vfMkEWD8 dOgNYiipBywjmV2eDjdRm6ORpnTz7Q== =P9Uc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 19:14:27 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033EE120234; Mon, 17 Jun 2019 19:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, 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 XkQdRe5sNpRo; Mon, 17 Jun 2019 19:14:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E13B12003F; Mon, 17 Jun 2019 19:14:15 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 3C9E31F450; Tue, 18 Jun 2019 02:14:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3DB4948CE; Mon, 17 Jun 2019 22:14:23 -0400 (EDT) From: Michael Richardson to: spasm@ietf.org, anima@ietf.org In-reply-to: <12718.1560790704@dooku.sandelman.ca> References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 12:58:24 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 22:14:23 -0400 Message-ID: <15737.1560824063@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 02:14:18 -0000 --=-=-= Content-Type: text/plain I have posted a -01 version of the document at: https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ Instead of trying to turn it binary, I just enshrine that the payload is base64 encoded DER: This document updates [RFC7030] to require the POST request and payload response of all endpoints in to be [RFC4648] section 4 Base64 encoded DER. This format is to be used regardless of whether there is any Content-Transfer-Encoding header, and any value in that header is to be ignored. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0ISP4ACgkQlUzhVv38 QpBLcQgAhHpfDEswz3AFrhFEtoYSu03MA6TPBZQjaSD7Sm7pyTFW5P82UH9/ZNkt ieWP6vsi8CmV6J/W5QO9FBTrWBR53DjmKjCFIjFLVIpHMaXbTw6Cwo5tzDrMS2a2 HMacAiLrPDVmVMpWakh6xPqG/9gaPrZaIiPcLZhEz+D1mkkZb75d8Z2jvo0O24eu HrSJzYVewWtP4l+lx9dg42yHmG791TsLDzZbijIRG3JRpdzPtBcV7Cc7A/+HUx5+ fX6sYYK281Y+Guj//BwDU+SV9F1B8bP3VZYjKLnHBowsWE47a8ijbXRO7mZnE0KP Zfei+2lPTg5aLbTElazijJeogXTGEw== =jZTg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 19:31:08 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F27FB12003F; Mon, 17 Jun 2019 19:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156082505889.22421.17259177670136772748@ietfa.amsl.com> Date: Mon, 17 Jun 2019 19:30:58 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-22.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 02:30:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-22.txt Pages : 97 Date : 2019-06-17 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-22 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 17 19:34:29 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77931120336; Mon, 17 Jun 2019 19:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, 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 Lz6V6h9YfKk4; Mon, 17 Jun 2019 19:34:26 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9124A1200F8; Mon, 17 Jun 2019 19:34:25 -0700 (PDT) Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 6471B1F450; Tue, 18 Jun 2019 02:34:23 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5697848CE; Mon, 17 Jun 2019 22:34:33 -0400 (EDT) From: Michael Richardson to: Anima WG , spasm@ietf.org In-reply-to: <10970.1560821009@dooku.sandelman.ca> References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> <10970.1560821009@dooku.sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Mon, 17 Jun 2019 21:23:29 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Mon, 17 Jun 2019 22:34:33 -0400 Message-ID: <18219.1560825273@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 02:34:27 -0000 --=-=-= Content-Type: text/plain > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and > Approach WG of the IETF. > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Filename : draft-ietf-anima-bootstrapping-keyinfra-22.txt > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-22 I have added a section 6: 6. Clarification of transfer-encoding [RFC7030] defines it's endpoints to include a "Content-Transfer- Encoding" heading, and the payloads to be [RFC4648] Base64 encoded DER. When used within BRSKI, the original RFC7030 EST endpoints remain Base64 encoded, but the new BRSKI end points which send and receive binary artifacts (specifically, ../voucherrequest) are binary. That is, no encoding is used. In the BRSKI context, the EST "Content-Transfer-Encoding" header if present, SHOULD be ignored. This header does not need to included. I have not made an informative reference to ietf-lamps-rfc7030est-clarify yet. I will stop now for awhile, to wait for consensus to catch up :-) I think that this change needs a WG Consensus Call, and some discussion with area director. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0ITbUACgkQlUzhVv38 QpARMAf+J+cZApxqfNCs0Vrr8fzCje8rwX5tovHvXDD5sxrDwKe0WpunW6giAfDq pMCC0nDnsBLcVzDJg9z09KDBLYHBFlhFMREg0FJ43Ny9Jv4un66ZcqegahzGrNfV N7eH4yov/ZCDb+xAVC9HulaM+/zlnW590uzCz8q9+aGM147kayc21AJl/hjZ/bMD pLflaMz4PZix5GPWmB1xUmsUXdyc8AXEMkQFifS7ENi+FbH3cUy2tv+LfJDFWAJf 553V7N0wGMrxBmFyTdFH13JK2kxNqJh+2kEM6po2Z8C5FuaLrD71Z+wpJ58Qm7ts bnrA7uqhZGMT2X+PJ+28HfiDw1bL0g== =tZQ/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 17 21:46:18 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4791202F3 for ; Mon, 17 Jun 2019 21:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 c5suOFNEIgFC for ; Mon, 17 Jun 2019 21:46:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D9B2512004A for ; Mon, 17 Jun 2019 21:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1560833155; bh=5wQCTDl6KZ1KfhekCwDiSfDuq9ZD4N2mkyB0822XU9g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=MKyC9nXUGjKuiEU9Q9W9SB6YR6fuXCkWB3f+LwYlNaAXwqEJntmaeJyvUWv5cAdBK TQwYHDygZ8QzCmUU7aQL1WQoQqsk4dKxaUMsSN2uPDPHK2tumCgJZZh7O83KpwjeIS hYhkO26LSAupMAr+wvdJAPR5RhKWS80QB6+ln124= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.54.221]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MJXEd-1hbiQa3PRr-0037fg; Tue, 18 Jun 2019 06:45:55 +0200 To: Brian E Carpenter , "Panos Kampanakis (pkampana)" , Michael Richardson Cc: Eliot Lear , "draft-ietf-pkix-est@ietf.org" , "ietf-http-wg@w3.org" , Carsten Bormann , Anima WG References: <32410.1560275231@localhost> <15839.1560351718@localhost> <8a538f76-787d-de13-97f1-16195daae8ce@gmx.de> <909.1560436148@localhost> <8921.1560788417@dooku.sandelman.ca> From: Julian Reschke Message-ID: <9b676fbb-a13f-3c00-dee2-289f529ba5d9@gmx.de> Date: Tue, 18 Jun 2019 06:45:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:upEfb1NyuzyXdjoTFh5wLUtFtVhqH4eQzgielYGLy1l0DRB6UhJ lfxIIihldG/xKaMUGr2cYGzlqaWg5Pdkq6Z5ku/LhadvYjFsaAQfuAdQlGibcbr9myHcwlQ hMAObMvF+I1ZSU0TjoMIAvfaF7PvfnDjk2lafj1li0cWuKQP522KMus38YyzPi2ya6uKdXM G3AuFBSlgAVbWVF5+L3mA== X-UI-Out-Filterresults: notjunk:1;V03:K0:DVnEkpOGPaM=:OEH0fhLomxcpBZvnycIUT4 QM/QoHE/e2Ek5Z4U5g4/9BEBHjTGFV93ADUy1tVjpc55XEXhwiLbmnPv5JnQXpiU9ouIS4P7e qlNQ1UCLjNNkU2rWbJBGEokA+8gZ7LbZIhykxTGaHB+79NLv7bUvfjR7VUchmubBYm4YxLJdX ARun6sIOR8rEG9d1JVKk5tbk563hJ913LsdHURl5kdQRE7LeG5yTweEFrx0d/w2YXf96SsDwu FXrIx6W43IttOqEB4Fz9RMwOXx22zrQ1lMlM+6U4aDPadMEUEtMlO024jNCuh8attv0TAJOse Gyzf4bXBlQJIosE+eUsc8dhRQ2vVYOJXVYt8pD3SW11iTXqybousho+4bpjMNQmPVQdCPRdpG VFbiS+8E6QZiF91zjZL/XuShDADucfscevV/J6OlqGd7pIXmoJXU5lrRp1hhA8CjRmtsiop1L EdldI2hTVsVumb27s7jlqr+48n7dImcTl6BpeN6qR9O1g1JyWKoorSCXkGfqS6oNplgHa1hEY iU00uLOUg5aA9qJmXa5h1pX9jrF0UXVOLfAvQ2ohS714aF8cIBTsN7yTjOHLzToqvFEn4tvjB wEmIiIR3o2gnqnOd//UnwrFvbYBbdKgbQfsKy0uNFphQ8+660RyhIYI3FmwzodxJr6h83Q63f q3xCqn3rUcq1v9ldElpLCtWl8wM1IUx5tZSM6tzWFjPeS+KF0OWPyxGtA/Jt/Icx9FQpVN08q 19nt708e2yyD/uhnrnuW8yYcdqu9NxEr6yUsanKQ9gd4VXqfs2g0D31TXYFyaIVBAf1mhk5G/ H10TVs46l0kjKMB410I3Mg4jrXsHyX1tdcMgojczijT5/vJe94KF0a825z27P4BZFPowb9Jcm WHErRdCg7zL+vuAt2ttMk0Bc2OMNfDNnwQf6J4ZjC5GCULqrgbrLJbDt1fbg3IFfnOBX3RAFJ +MGBhd21D8PnC0yQspZnui7a8RSZWbQ4yGyBbr2am3ZDBVoW59MJl Archived-At: Subject: Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 04:46:16 -0000 On 17.06.2019 22:44, Brian E Carpenter wrote: > On 18-Jun-19 05:18, Panos Kampanakis (pkampana) wrote: >>> So effectively, the CTE header has effectively been dropped, but the p= ayload is now assumed to be base64, regardless. >>> This suggests that we can not use the CTE header as a signal. > > I went and looked at RFC4648 for my own education, and then spent a few = minutes > trying to design a Turing machine that can distinguish a binary bit stri= ng from > a base64 bit string. Fail. You can determine that a bit string is defini= tely > not base64 if it contains at least one character outside the base64 alph= abet, > but not the converse. So it needs a signal. Not having a signal would be= wide > open to malicious misuse, IMHO. Indicating the length of the payload wou= ld be > enough, I think. I agree that using heuristics should be avoided. But how does Content-Length help here? Best regards, Julian From nobody Tue Jun 18 15:12:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38560120301; Tue, 18 Jun 2019 15:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 SRR4rRY8N0zY; Tue, 18 Jun 2019 15:12:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5272A1202ED; Tue, 18 Jun 2019 15:12:32 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [209.82.62.2]) by relay.sandelman.ca (Postfix) with ESMTPS id C01F61F450; Tue, 18 Jun 2019 22:12:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CA4681328; Tue, 18 Jun 2019 18:12:33 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, spasm@ietf.org In-reply-to: <156086304414.8416.1010829894869123324.idtracker@ietfa.amsl.com> References: <156086304414.8416.1010829894869123324.idtracker@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Tue, 18 Jun 2019 06:04:04 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 18 Jun 2019 18:12:33 -0400 Message-ID: <5700.1560895953@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] New Version Notification for draft-richardson-lamps-rfc7030est-clarify-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 22:12:35 -0000 -------- --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A new version of I-D, draft-richardson-lamps-rfc7030est-clarify-02.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Diff: > https://www.ietf.org/rfcdiff?url2=draft-richardson-lamps-rfc7030est-clarify-02 This version does not attempt to bring binary objects at all to EST. It just notes that the CTE header does not belong, should not be sent, should be ignored, and that the payload is base64, and shall always be. The GRASP registration is dropped, since there is no need for clients to know about different generations of EST servers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0JYdEACgkQlUzhVv38 QpBtdAf9HEmUTobeosdALwi8aAH4AB3Wj3d/8GeIVvw5Schk9PcoAo51ODd+YEdZ YRw9Svov/HWm3lZWi0GZ7oudnbFHmCXl9k1qJXP7+A3i3N6igQtZ2ZhetvofVNd0 /fQxmFebwwe4BU9yuRAvILewMxV1ll9EtxIACdxCJHvz538wLtgpn/bwviC1Fuq9 9oIab1Mfo6N7kJTDMMAl/BQw942FcglQm4D+yi5ykrrY0lgIX9ig6BxHiCKoLI/E xLXD0Ia4wudXnM7EkihPDvFZqBTAUeGDcTOJNFBu4tCelhiuHevlUL2TQj6fXGh+ xDPNWhUzZ/muobkgLLSLNffOMJiLNA== =DmkS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 18 18:15:12 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BEB12034A; Tue, 18 Jun 2019 18:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 evIzwroXg_KC; Tue, 18 Jun 2019 18:15:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771E31201F3; Tue, 18 Jun 2019 18:15:08 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Jun 2019 18:15:02 -0700 From: Jim Schaad To: 'Michael Richardson' , , References: <6535.1560786935@dooku.sandelman.ca> <10505.1560789112@dooku.sandelman.ca> <12718.1560790704@dooku.sandelman.ca> In-Reply-To: <12718.1560790704@dooku.sandelman.ca> Date: Tue, 18 Jun 2019 18:15:00 -0700 Message-ID: <040a01d5263c$6c51efa0$44f5cee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJb28LO5lo2KeiH1QNaqQhKxPp0VgIQkln/AZkBSSGld1fWQA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Anima] [lamps] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 01:15:11 -0000 -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: Monday, June 17, 2019 9:58 AM To: spasm@ietf.org; anima@ietf.org Subject: Re: [lamps] [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI Resending a third time, with correct LAMPS ML name of "SPASM" (no trailing S!). My sincere appologies. I have posted the draft https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ this morning. It attempts to address the errata posted by Sean Turner in 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and base64. You can see my other query to httpbis at: https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 In doing BRSKI (draft-ietf-anima-bootstrapping-keyinfra) interop testing we had a number of confusions about whether or things are base64 encoded, and if they are always base64 encoded, why send the CTE header, and if BRSKI is binary or base64 encoded! Given that RFC7030 is somewhat well deployed, acting on the errata that Sean Turner noted is a bit difficult! (As a process thing, it's a problem that his 2017 errata seems to have gone into /dev/null). I am posting the core of the proposal at the bottom of this email. It tries to leverage the Postel doctrine in a way. Some questions/issues: 1) does this belong in secdispatch? [JLS] I would say yes if only because that is the "new process" that is being used. 2) is this appropriate for LAMPS? [JLS] If I was running secdispatch this is where I would send it. 3) independant submission seems wrong. [JLS] An Individual submission would be ok (direct to AD). However an Independent submission is a complete non-starter. Cannot update a standards track document via the ISE. Jim 4) ANIMA BRSKI needs to clarify things itself, and I will add a section on this, but I'm hesistant to add a normative reference here. I have an idea of appropriate text that I will post on Tuesday. Getting clarity here is really the most important thing for me. 5) I don't have a simple answer for the /csrattrs API. Maybe it needs to be solved by creating a new end point. or it could be done with Accept: header. ps: it's ironic to me, this is perhaps something that could also be solved by versioning the API in the URL. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (DER-encoded), and omit the Content-Transfer-Encoding header. How the client knows what kind of server it is dealing with is communicating with is detailed in the next section. An amended server, when it receives a request that has no Content- Transfer-Encoding header, or has a Content-Transfer-Encoding header with the "binary" attribute, MUST respond in the same binary format. When an amended server receives a request in CTE-base64 form, then it MAY respond in kind. It is reasonable for a server to be configured to ignore or fail requests of this form, either via run-time configuration, or via a compile-time option. A main reason to do this is to avoid a permutation that requires testing in the future when no legacy EST clients are expected to connect. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- [[End of PGP Signed Part]] _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Sat Jun 22 20:43:31 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21071200C5 for ; Sat, 22 Jun 2019 20:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9mNP02q2GiF for ; Sat, 22 Jun 2019 20:43:28 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 E97D7120088 for ; Sat, 22 Jun 2019 20:43:27 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id d126so5593384pfd.2 for ; Sat, 22 Jun 2019 20:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=FXCnxQJFxcoXus6sS15VpwJJHZ7UjXTW6B3QuBsp8eQ=; b=TPGdHzno14l3H25aZgI4LkCGs5Ml/HpGalCXKDoKk2uqmsNu+NaC8/5Hy2DstgwaEx jBTD2ojoC9jKTS+HRfPvIXzN0YLDhhJXjcve8VyCyuqD/w+1CJBTlaVdUChfJJTNwXeW cSSxU6kW7JyO2CNhDOeGjIJ9oNTUZTrc0I6cL49E6pUsj64p+SHI2xLObrS6A+uYrPCR rCfRwAYamsazBqTlhHSwIWeoTPKoGqLUH6JXv7QLF8rAQcd2ByaWY++vOOq1+bkbFQsh zj/TeFFDrBQwBU8tfKZodUY/wTgwyy+823snRjQ/riD658p9q5fJRMuioxpmLsmECQZy bxkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=FXCnxQJFxcoXus6sS15VpwJJHZ7UjXTW6B3QuBsp8eQ=; b=s5/nEKxmbL3SftFH3A2npQvnFBb5+zNfWgL7ANwqb3ooH7ErVw2e7eRYc0uwBkqpeM orf7HaoOfMlvJ3m+HvmbQ/i2u1oq7yqOhuDW60smQ+UE1s6CLoCoGhCPGnqnZii7omkJ QEw0tw4/yxSwGb8qwze81dSDeLx48XNNNbDRzQmmlA3XCYMJWTTKTfOYeBQiCuzVoeiC aFb227J4muCEyktxjQHI8sAXil6KIUSTz6Xv6UoOnnG2qDJ1czDtfwarkUZi8xCdygA7 /yR/ZHdgxixVEXWmsyma8MejCWwTkE7E6d3v/Q/jm7tkv3kAdVUuShoV3ii4LCOPyPU3 76lA== X-Gm-Message-State: APjAAAWKjYb1b6qbjhaedLx9lLEENOGusckMO1Gfq1WpNQx2mwabakqc LTFUn6Gpb/z9N5d3qHxYLKZhNtKi X-Google-Smtp-Source: APXvYqxSoobGu7Pl/mgZF0BbUxiHIZaNbIN3ynrkwr0qZhGyCiIhBD8AWm56iSCkBfnewVowoyyHjA== X-Received: by 2002:a17:90a:350c:: with SMTP id q12mr16580676pjb.46.1561261407252; Sat, 22 Jun 2019 20:43:27 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id 14sm10427814pfj.36.2019.06.22.20.43.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jun 2019 20:43:26 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <01abc2c1-99e9-c047-fc09-6656ceda3b4c@gmail.com> Date: Sun, 23 Jun 2019 15:43:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Anima] draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 03:43:30 -0000 Hi, I'd like to ask whether the WG thinks it's time to advance the=20 GRASP API towards publication. The Python implementation has been stable for a long time (and was independently tested by Robin J=C3=A4ger)= =2E As the main drafts from Anima phase 1 are moving slowly forward, it seems appropriate for the API to be following along. Like most IETF work on APIs, it is intended to be Informational, and it fits the current= WG charter as part of the GRASP work. https://tools.ietf.org/html/draft-ietf-anima-grasp-api Regards Brian Carpenter From nobody Wed Jun 26 02:59:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F24D1200B4; Wed, 26 Jun 2019 02:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTJ1gS1Nza-t; Wed, 26 Jun 2019 02:59:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072EC12009E; Wed, 26 Jun 2019 02:59:14 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7575B46246AFA52B2F4E; Wed, 26 Jun 2019 10:59:12 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 26 Jun 2019 10:59:11 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Wed, 26 Jun 2019 17:59:05 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8w== Date: Wed, 26 Jun 2019 09:59:04 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92999E4E84NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 09:59:17 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92999E4E84NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs' email. Please note that ema= il to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B92999E4E84NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all anima,

 


We have been allocated two sessions =
of 2 + 1.5 hour for the ANIMA WG meeting for IETF-105 (Montreal) - Tues=
day Morning session I and Afternoon session I. We are now starting to colle=
ct agenda items for the sessions. Please send your request for agenda by Ju=
ly 11th, Thursday, to anima-chairs=
@ietf.org and both chairs’ email. Please note that email to a sin=
gle chair may cause single failure.


 


For this coming meeting, we would li=
ke have the 1.5 hour session for BRSHI and Voucher relevant topics and the =
2 hour session for the others. As normal, the priority among these non-char=
ter work items would be: these that have active discussion in mail list, th=
en these have submitted drafts, and topics without drafts.


 


As you may observed, so far, our re-=
charter progress still not in the procedure. Until we have the new charter =
in the place by the IETF 105 week, we still not be able to adopt any new wo=
rk.


 


Please send us (anima-chairs at ietf.org<https://ietf.org/>;) requests for time slot by J=
uly 11th, Thursday and include:


 


Name of time slot:=



Name of draft(s):<=
/pre>

Time requested:

Presenter name(s):=



 


More details about the IETF 105, Mon=
treal can be found at:


 


https://www.ietf.org/how/meetings/105/=



 


Again, presenters and draft authors =
please invoke active discussions in the ANIMA list. Mail list is a very goo=
d place to discuss and reach consensus on technical issues.


 


Best regards,

 


Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B92999E4E84NKGEML515MBSchi_-- From nobody Fri Jun 28 00:41:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEAE1202A9; Fri, 28 Jun 2019 00:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWf8tfV8aT52; Fri, 28 Jun 2019 00:40:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CA61200EC; Fri, 28 Jun 2019 00:40:58 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3D993D0EB5E0095C8E76; Fri, 28 Jun 2019 08:40:56 +0100 (IST) Received: from lhreml507-mbb.china.huawei.com ([10.201.109.48]) by lhreml709-cah.china.huawei.com ([10.201.108.32]) with mapi id 14.03.0415.000; Fri, 28 Jun 2019 08:40:46 +0100 From: Xun Xiao To: Sheng Jiang , "anima-chairs@ietf.org" , "tte+anima@cs.fau.de" CC: "anima@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wBfgzqA Date: Fri, 28 Jun 2019 07:40:46 +0000 Message-ID: <67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39@lhreml507-mbb> References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.65.137] Content-Type: multipart/alternative; boundary="_000_67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39lhreml507mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 07:41:01 -0000 --_000_67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39lhreml507mbb_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi WG chairs, We would like to have a time slot: Name of time slot: Tuesday Morning session I Name of draft(s): Information Distribution in Autonomic Networking Time requested: 10 mins Presenter name(s): Bing Liu Thanks a lot! Best Regards, Xun Xiao (=1B$B>S?W=1B(B) Advanced Wireless Technology Lab Munich Research Center Huawei Technologies Co.,Ltd. From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Wednesday, 26 June 2019 11:59 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal Hi, all anima, We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG meetin= g for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon session= I. We are now starting to collect agenda items for the sessions. Please se= nd your request for agenda by July 11th, Thursday, to anima-chairs@ietf.org= and both chairs=1B$B!G=1B(B email. Please no= te that email to a single chair may cause single failure. For this coming meeting, we would like have the 1.5 hour session for BRSHI = and Voucher relevant topics and the 2 hour session for the others. As norma= l, the priority among these non-charter work items would be: these that hav= e active discussion in mail list, then these have submitted drafts, and top= ics without drafts. As you may observed, so far, our re-charter progress still not in the proce= dure. Until we have the new charter in the place by the IETF 105 week, we s= till not be able to adopt any new work. Please send us (anima-chairs at ietf.org;) requests for time slot by July 11th, Thursday and= include: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 105, Montreal can be found at: https://www.ietf.org/how/meetings/105/ Again, presenters and draft authors please invoke active discussions in the= ANIMA list. Mail list is a very good place to discuss and reach consensus = on technical issues. Best regards, Sheng --_000_67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39lhreml507mbb_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi WG= chairs,

=  

We wo= uld like to have a time slot:

=  

Name = of time slot: Tuesday Morning session I

Name = of draft(s): Information Distribution in Autonomic Networking

Time = requested: 10 mins

Prese= nter name(s): Bing Liu

=  

Thank= s a lot!

=  

Best Regards,

 

Xun Xiao (=1B$B>S?W=1B(B)

Advanced Wireless Technology Lab

Munich Research Center

Huawei Technologies Co.,Ltd.=

=  

From: = Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, 26 June 2019 11:59
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

 = 

Hi, all anima,
 
We have been allocated two sessions of 2 + 1.5 =
hour for the ANIMA WG meeting for IETF-105 (Montreal) - Tuesday Morning ses=
sion I and Afternoon session I. We are now starting to collect agenda items=
 for the sessions. Please send your request for agenda by July 11th, Thursd=
ay, to anima-chairs@ietf.org a=
nd both chairs=1B$B!G=1B(B email. Please note that email to a single chair =
may cause single failure.
 
For this coming meeting, we would like have the 1.5=
 hour session for BRSHI and Voucher relevant topics and the 2 hour session =
for the others. As normal, the priority among these non-charter work items =
would be: these that have active discussion in mail list, then these have s=
ubmitted drafts, and topics without drafts.
 
As you may observed, so far, our re-charter progres=
s still not in the procedure. Until we have the new charter in the place by=
 the IETF 105 week, we still not be able to adopt any new work.<=
/span>
 
Please send us (anima-chairs at ietf.org<ht=
tps://ietf.org/>;) requests for time slot by July 11th, Thurs=
day and include:
 
Name of time slot:
Name of draft(s):
Time requested:
Presenter name(s):
 
More details about the IETF 105, Montreal can be fo=
und at:
 
=
https://www.ietf.org/how/meetings/105/
 
Again, presenters and draft authors please invoke a=
ctive discussions in the ANIMA list. Mail list is a very good place to disc=
uss and reach consensus on technical issues.
 
Best regards,
 
Sheng
--_000_67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39lhreml507mbb_-- From nobody Fri Jun 28 16:09:04 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A714120976; Fri, 28 Jun 2019 15:58:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268902.11015.12262619618632306312.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:09 -0700 Archived-At: Subject: [Anima] anima - Requested sessions have been scheduled for IETF 105 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:07:28 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:00 requested) Tuesday, 23 July 2019, Morning Session I 1000-1200 Room Name: Duluth size: 150 --------------------------------------------- anima Session 2 (1:30 requested) Tuesday, 23 July 2019, Afternoon Session I 1330-1500 Room Name: Centre Ville size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/anima.ics Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6man 6lo nmrg 6tisch ace Second Priority: roll homenet netconf detnet Third Priority: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: The WG prefers to have meetings on Monday/Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Fri Jun 28 16:21:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4191202AE; Fri, 28 Jun 2019 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9d5KfqBl7x1; Fri, 28 Jun 2019 16:21:09 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6566120273; Fri, 28 Jun 2019 16:21:06 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id bi6so4045799plb.12; Fri, 28 Jun 2019 16:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BgZoHDWQYt6U6/MD4KGy18XxJxwMmRY0/uc+0Xe6Ms8=; b=BZAMvciO/w0ZOfQiM5ChPOUficoYCMiGTe+Nc40BXTqpxiZdVeKqBIfINHJ3AngLPp 6fC1dRpUxN36JrauwKHDlSY0JV4WqicKCWpVEnNobps2lBhWIOVcHJhkDE/epcMnTaSu s5QQUjivJmIMGsNIB4woM84dtM2vgLyFliIB57zWkR+QTdRWpiGuM4acsDIg5KAnHufn +GgZ/0Y3wedbnGEKneF+6bEdkJlxq8UsPX8HbMdpzssu9UHKIJyRYf0MZB7GmrZ5Vs8V yZxzwaipGqCAd7hx36MOmiuOjlNYKnYNxlHFli9sa50RwCZqxnry3xtNkxE4G09IZT6I bL1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BgZoHDWQYt6U6/MD4KGy18XxJxwMmRY0/uc+0Xe6Ms8=; b=J5g6VrLChhXYrjOWKIyVrT7kdtsa7Vp/Zo+SbnwMbbr4NyFdnt7MGcpB2vsoNitCht rEXmkfK/nfYnUY+kSvw4wZbBG+WUVs+ihT3MlP8pwJYGEAReZH6yi2h0CJiCjgznc9uy VUYh8bcCiWY6ciGtYCymFievsY9/14uln0PT5N2p9Sz3UQffa7KpxgRzrmeROGgwuXaH J1tAiETfDYZb+zLquDGe0FhEOZgIxooSBcjHN9X5EuoSTOHMhga0yOYr5932244huWXx FiPTDTr2tr8WsgqJ96H19/e4UUGTRoflqVRaRCa+RJq51rrRJGVZkf44vgAyY0jKbkqb tEGQ== X-Gm-Message-State: APjAAAXM2Hxr2HqAA63NycM/AzmqbLoNbJ4G9UJ7nVs1xO1f+VhDYIOf 4OgCckxukf4R0eysrHNT1ag7DMRY X-Google-Smtp-Source: APXvYqzDKmE37c3CvvJetCZGNMXHHtC3in4xAfdOrPkqkJoXCyoW+KJW7Xc56gfztNmwNfiR0qAVcQ== X-Received: by 2002:a17:902:1003:: with SMTP id b3mr14658703pla.172.1561764065908; Fri, 28 Jun 2019 16:21:05 -0700 (PDT) Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id w12sm2335806pgp.56.2019.06.28.16.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 16:21:05 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" , anima-ads@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <346b299e-9588-2c0b-5455-6140ccbf36c1@gmail.com> Date: Sat, 29 Jun 2019 11:21:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:21:12 -0000 Hi Sheng and Toerless, and ADs, This is quite difficult without knowing if the new charter has been appro= ved. Is this on the IESG agenda? If not, why not?? We've been waiting mon= ths. If we do have the new charter I would like to propose several topics for = WG adoption: draft-carpenter-anima-asa-guidelines - previously presented, only discuss= ion needed draft-carpenter-anima-grasp-bulk - previously presented, only discussion= needed draft-carpenter-anima-l2acp-scenarios - not previously presented, 10 minu= tes requested in any case. Possibly this also fits under the old charter.= In any case I would like to propose that draft-ietf-anima-grasp-api shoul= d move to WG Last Call under the old charter. Again, that has been previo= usly presented, only discussion is needed. Regards Brian Carpenter On 26-Jun-19 21:59, Sheng Jiang wrote: > Hi, all anima, >=20 > =C2=A0 >=20 > We have been allocated two sessions of 2 + 1.5 hour for the ANIMA WG me= eting for IETF-105 (Montreal) - Tuesday Morning session I and Afternoon s= ession I. We are now starting to collect agenda items for the sessions. P= lease send your request for agenda by July 11th, Thursday, to anima-chair= s@ietf.org and both chairs=E2=80=99 email.= Please note that email to a single chair may cause single failure. >=20 > =C2=A0 >=20 > For this coming meeting, we would like have the 1.5 hour session for BR= SHI and Voucher relevant topics and the 2 hour session for the others. As= normal, the priority among these non-charter work items would be: these = that have active discussion in mail list, then these have submitted draft= s, and topics without drafts. >=20 > =C2=A0 >=20 > As you may observed, so far, our re-charter progress still not in the p= rocedure. Until we have the new charter in the place by the IETF 105 week= , we still not be able to adopt any new work. >=20 > =C2=A0 >=20 > Please send us (anima-chairs at ietf.org ;) requests for time slot by July 11th, Thurs= day and include: >=20 > =C2=A0 >=20 > Name of time slot: >=20 > Name of draft(s): >=20 > Time requested: >=20 > Presenter name(s): >=20 > =C2=A0 >=20 > More details about the IETF 105, Montreal can be found at: >=20 > =C2=A0 >=20 > https://www.ietf.org/how/meetings/105/ >=20 > =C2=A0 >=20 > Again, presenters and draft authors please invoke active discussions in= the ANIMA list. Mail list is a very good place to discuss and reach cons= ensus on technical issues. >=20 > =C2=A0 >=20 > Best regards, >=20 > =C2=A0 >=20 > Sheng >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Sat Jun 29 02:06:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0427912012A; Sat, 29 Jun 2019 02:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.1 X-Spam-Level: X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei9Stw7IkINQ; Sat, 29 Jun 2019 02:05:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F7212004E; Sat, 29 Jun 2019 02:05:56 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 68179D69737FEABDAA70; Sat, 29 Jun 2019 10:05:54 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Jun 2019 10:05:50 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Sat, 29 Jun 2019 17:02:42 +0800 From: Sheng Jiang To: Xun Xiao , "anima-chairs@ietf.org" , "tte+anima@cs.fau.de" CC: "anima@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 105, Montreal Thread-Index: AdUsBboo3xRyHh3hSnChcqD+G5sU8wBfgzqAADVY6dA= Date: Sat, 29 Jun 2019 09:02:42 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92999E8E08@NKGEML515-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92999E4E84@NKGEML515-MBS.china.huawei.com> <67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39@lhreml507-mbb> In-Reply-To: <67C6AE5A0CF6AD45A8571ED3F6E802E4138F8F39@lhreml507-mbb> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92999E8E08NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 105, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 09:05:59 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92999E8E08NKGEML515MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFhpYW8sDQoNClRoYW5rcyBmb3IgeW91ciBlbWFpbC4gWW91ciBhcHBsaWNhdGlvbiBhcmUg bm90ZWQuIEkgYmVsaWV2ZSB3ZSBoYXZlIHN1ZmZpY2llbnQgdGltZSBmb3IgdGhpcyBjb21pbmcg bWVldGluZy4NCg0KU2hlbmcNCg0KDQpGcm9tOiBYdW4gWGlhbw0KU2VudDogRnJpZGF5LCBKdW5l IDI4LCAyMDE5IDM6NDEgUE0NClRvOiBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29t PjsgYW5pbWEtY2hhaXJzQGlldGYub3JnOyB0dGUrYW5pbWFAY3MuZmF1LmRlDQpDYzogYW5pbWFA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBDYWxsIGZvciBhZ2VuZGEgQU5JTUEgQCBJRVRGIDEwNSwg TW9udHJlYWwNCg0KSGkgV0cgY2hhaXJzLA0KDQpXZSB3b3VsZCBsaWtlIHRvIGhhdmUgYSB0aW1l IHNsb3Q6DQoNCk5hbWUgb2YgdGltZSBzbG90OiBUdWVzZGF5IE1vcm5pbmcgc2Vzc2lvbiBJDQpO YW1lIG9mIGRyYWZ0KHMpOiBJbmZvcm1hdGlvbiBEaXN0cmlidXRpb24gaW4gQXV0b25vbWljIE5l dHdvcmtpbmcNClRpbWUgcmVxdWVzdGVkOiAxMCBtaW5zDQpQcmVzZW50ZXIgbmFtZShzKTogQmlu ZyBMaXUNCg0KVGhhbmtzIGEgbG90IQ0KDQpCZXN0IFJlZ2FyZHMsDQoNClh1biBYaWFvICjQpNG4 KQ0KQWR2YW5jZWQgV2lyZWxlc3MgVGVjaG5vbG9neSBMYWINCk11bmljaCBSZXNlYXJjaCBDZW50 ZXINCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4NCg0KRnJvbTogQW5pbWEgW21haWx0bzph bmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2hlbmcgSmlhbmcNClNlbnQ6IFdl ZG5lc2RheSwgMjYgSnVuZSAyMDE5IDExOjU5DQpUbzogYW5pbWFAaWV0Zi5vcmc8bWFpbHRvOmFu aW1hQGlldGYub3JnPg0KQ2M6IGFuaW1hLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86YW5pbWEtY2hh aXJzQGlldGYub3JnPg0KU3ViamVjdDogW0FuaW1hXSBDYWxsIGZvciBhZ2VuZGEgQU5JTUEgQCBJ RVRGIDEwNSwgTW9udHJlYWwNCg0KDQpIaSwgYWxsIGFuaW1hLA0KDQoNCg0KV2UgaGF2ZSBiZWVu IGFsbG9jYXRlZCB0d28gc2Vzc2lvbnMgb2YgMiArIDEuNSBob3VyIGZvciB0aGUgQU5JTUEgV0cg bWVldGluZyBmb3IgSUVURi0xMDUgKE1vbnRyZWFsKSAtIFR1ZXNkYXkgTW9ybmluZyBzZXNzaW9u IEkgYW5kIEFmdGVybm9vbiBzZXNzaW9uIEkuIFdlIGFyZSBub3cgc3RhcnRpbmcgdG8gY29sbGVj dCBhZ2VuZGEgaXRlbXMgZm9yIHRoZSBzZXNzaW9ucy4gUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0 IGZvciBhZ2VuZGEgYnkgSnVseSAxMXRoLCBUaHVyc2RheSwgdG8gYW5pbWEtY2hhaXJzQGlldGYu b3JnPG1haWx0bzphbmltYS1jaGFpcnNAaWV0Zi5vcmc+IGFuZCBib3RoIGNoYWlyc6GvIGVtYWls LiBQbGVhc2Ugbm90ZSB0aGF0IGVtYWlsIHRvIGEgc2luZ2xlIGNoYWlyIG1heSBjYXVzZSBzaW5n bGUgZmFpbHVyZS4NCg0KDQoNCkZvciB0aGlzIGNvbWluZyBtZWV0aW5nLCB3ZSB3b3VsZCBsaWtl IGhhdmUgdGhlIDEuNSBob3VyIHNlc3Npb24gZm9yIEJSU0hJIGFuZCBWb3VjaGVyIHJlbGV2YW50 IHRvcGljcyBhbmQgdGhlIDIgaG91ciBzZXNzaW9uIGZvciB0aGUgb3RoZXJzLiBBcyBub3JtYWws IHRoZSBwcmlvcml0eSBhbW9uZyB0aGVzZSBub24tY2hhcnRlciB3b3JrIGl0ZW1zIHdvdWxkIGJl OiB0aGVzZSB0aGF0IGhhdmUgYWN0aXZlIGRpc2N1c3Npb24gaW4gbWFpbCBsaXN0LCB0aGVuIHRo ZXNlIGhhdmUgc3VibWl0dGVkIGRyYWZ0cywgYW5kIHRvcGljcyB3aXRob3V0IGRyYWZ0cy4NCg0K DQoNCkFzIHlvdSBtYXkgb2JzZXJ2ZWQsIHNvIGZhciwgb3VyIHJlLWNoYXJ0ZXIgcHJvZ3Jlc3Mg c3RpbGwgbm90IGluIHRoZSBwcm9jZWR1cmUuIFVudGlsIHdlIGhhdmUgdGhlIG5ldyBjaGFydGVy IGluIHRoZSBwbGFjZSBieSB0aGUgSUVURiAxMDUgd2Vlaywgd2Ugc3RpbGwgbm90IGJlIGFibGUg dG8gYWRvcHQgYW55IG5ldyB3b3JrLg0KDQoNCg0KUGxlYXNlIHNlbmQgdXMgKGFuaW1hLWNoYWly cyBhdCBpZXRmLm9yZzxodHRwczovL2lldGYub3JnLz48aHR0cDovL2lldGYub3JnJTNDaHR0cHMv aWV0Zi5vcmcvJTNFKT47KSByZXF1ZXN0cyBmb3IgdGltZSBzbG90IGJ5IEp1bHkgMTF0aCwgVGh1 cnNkYXkgYW5kIGluY2x1ZGU6DQoNCg0KDQpOYW1lIG9mIHRpbWUgc2xvdDoNCg0KTmFtZSBvZiBk cmFmdChzKToNCg0KVGltZSByZXF1ZXN0ZWQ6DQoNClByZXNlbnRlciBuYW1lKHMpOg0KDQoNCg0K TW9yZSBkZXRhaWxzIGFib3V0IHRoZSBJRVRGIDEwNSwgTW9udHJlYWwgY2FuIGJlIGZvdW5kIGF0 Og0KDQoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdzLzEwNS8NCg0KDQoNCkFn YWluLCBwcmVzZW50ZXJzIGFuZCBkcmFmdCBhdXRob3JzIHBsZWFzZSBpbnZva2UgYWN0aXZlIGRp c2N1c3Npb25zIGluIHRoZSBBTklNQSBsaXN0LiBNYWlsIGxpc3QgaXMgYSB2ZXJ5IGdvb2QgcGxh Y2UgdG8gZGlzY3VzcyBhbmQgcmVhY2ggY29uc2Vuc3VzIG9uIHRlY2huaWNhbCBpc3N1ZXMuDQoN Cg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KDQpTaGVuZw0K --_000_5D36713D8A4E7348A7E10DF7437A4B92999E8E08NKGEML515MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Xia= o,

&n= bsp;

Thanks = for your email. Your application are noted. I believe we have sufficient ti= me for this coming meeting.

&n= bsp;

Sheng

 

 

From: Xun Xiao
Sent: Friday, June 28, 2019 3:41 PM
To: Sheng Jiang <jiangsheng@huawei.com>; anima-chairs@ietf.org= ; tte+anima@cs.fau.de
Cc: anima@ietf.org
Subject: RE: Call for agenda ANIMA @ IETF 105, Montreal

 

Hi WG chairs,

 

We would like to have a time slot:

 

Name of time slot: Tuesday Morning session I

Name of draft(s): Information Distribution in Autonomic Networkin= g

Time requested: 10 mins

Presenter name(s): Bing Liu

 

Thanks a lot!

 

Best Regards,

 

Xun Xiao (=D0=A4=D1=B8)

Advanced Wireless Techn= ology Lab

Munich Research Center<= o:p>

Huawei Technologies Co.= ,Ltd.

 

From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang
Sent: Wednesday, 26 June 2019 11:59
To: anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 105, Montreal

 

Hi, all anima,

 


We have been allocated two sessions =
of 2 + 1.5 hour for the ANIMA WG meeting for IETF-105 (Montreal) - Tues=
day Morning session I and Afternoon session I. We are now starting to colle=
ct agenda items for the sessions. Please send your request for agenda by Ju=
ly 11th, Thursday, to anima-chairs=
@ietf.org and both chairs=A1=AF email. Please note that email to a sing=
le chair may cause single failure.


 


For this coming meeting, we would li=
ke have the 1.5 hour session for BRSHI and Voucher relevant topics and the =
2 hour session for the others. As normal, the priority among these non-char=
ter work items would be: these that have active discussion in mail list, th=
en these have submitted drafts, and topics without drafts.


 


As you may observed, so far, our re-=
charter progress still not in the procedure. Until we have the new charter =
in the place by the IETF 105 week, we still not be able to adopt any new wo=
rk.


 


Please send us (anima-chairs at ietf.org<https://ietf.org/>;) requests for time slot by J=
uly 11th, Thursday and include:


 


Name of time slot:=



Name of draft(s):<=
/pre>

Time requested:

Presenter name(s):=



 


More details about the IETF 105, Mon=
treal can be found at:


 


https://www.ietf.org/how/meetings/105/=



 


Again, presenters and draft authors =
please invoke active discussions in the ANIMA list. Mail list is a very goo=
d place to discuss and reach consensus on technical issues.


 


Best regards,

 


Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B92999E8E08NKGEML515MBSchi_--