From nobody Wed May 1 06:53: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 7C941120128; Wed, 1 May 2019 06:53:22 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 9-tJet6LHXB2; Wed, 1 May 2019 06:53:20 -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 D759A12013F; Wed, 1 May 2019 06:53:19 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A0993548919; Wed, 1 May 2019 15:53:13 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 914B9440041; Wed, 1 May 2019 15:53:13 +0200 (CEST) Date: Wed, 1 May 2019 15:53:13 +0200 From: Toerless Eckert To: Barry Leiba Cc: Martin Vigoureux , The IESG , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20190501135313.gpp3zyuf3ujtgr4y@faui48f.informatik.uni-erlangen.de> References: <155655905154.15849.12085215696912730275.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Martin Vigoureux'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: Wed, 01 May 2019 13:53:23 -0000 Martin, Barry, *: On Mon, Apr 29, 2019 at 02:59:10PM -0400, Barry Leiba wrote: > > I am under the impression that there is a small ambiguity in the charter, which > > shouldn't be hard to resolve: > > > > ANIMA work will rely on the framework described in > > draft-ietf-anima-reference-model. [...] The three areas of the framework are > > [...] and (3) Intent. > > > > ANIMA will not work on Intent [...] without explicit rechartering. > > > > The first piece seems to allow for working on Intent while the second clearly > > not (within the current charter). > > I tripped over that also when I first read it, but then understood: > the WG will rely on the framework, which includes a set of things. > Not all of those things will be worked on via this charter. In > particular, "intent" is one of the things that won't be. Indeeed. ANIMA was started from the framework for autonomous networking from NMRG. That included intent. In the past years of ANIMA work we came to the conclusion that intent is as desirable as it we thought originally, but that there is not enough clarity yet to standardize how to do it. Nobody could come up non-contentious real standardizable examples. So effectively we are trying to make progress with intent definitions in NMRG and then bring it back to ANIMA later for standardization. > As I read it, I think the charter is OK. I suppose it could be > clarified this way: > > OLD > ANIMA work will rely on the framework described in > draft-ietf-anima-reference-model. Work not related to this framework is welcome > for review, but WG adoption of such work requires explicit rechartering. The > three areas of the framework are (1) the Autonomic Networking Infrastructure > (ANI), (2) Autonomic Functions (AF) built from software modules called > Autonomic Service Agents (ASA) and (3) Intent. > > NEW > ANIMA work will rely on the framework described in > draft-ietf-anima-reference-model, though only parts of the framework are > in scope for this charter, as detailed below. Work not related to > this framework > is welcome for review, but WG adoption of such work requires explicit > rechartering. > The three areas of the framework are (1) the Autonomic Networking Infrastructure > (ANI), (2) Autonomic Functions (AF) built from software modules called > Autonomic Service Agents (ASA) and (3) Intent. > END Yes. I like that. Martin, is that ok. for you ? > > I'm not sure to understand what the following means: > > > > 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. > > As I read it, it means that the working group won't take on so much > work that the work they do take on doesn't get done. Acceptance is > based on negotiating a schedule (based on meeting cycles), and if the > schedule isn't met, new work items can't be accepted. Exactly. This was just added to give recognition to the fact that we are trying to learn from our first round charter experience to become more agile and managing author resources better. Thanks Toerless > > Barry From nobody Wed May 1 07:14: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 896D61200CE; Wed, 1 May 2019 07:14:44 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 NqIfqWOHnOXU; Wed, 1 May 2019 07:14:43 -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 BD20D12013A; Wed, 1 May 2019 07:14:42 -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 8BEB8548874; Wed, 1 May 2019 16:14:37 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 77F7E440041; Wed, 1 May 2019 16:14:37 +0200 (CEST) Date: Wed, 1 May 2019 16:14:37 +0200 From: Toerless Eckert To: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" Cc: Barry Leiba , "anima-chairs@ietf.org" , The IESG , "anima@ietf.org" Message-ID: <20190501141437.tedkbtbcp5seapco@faui48f.informatik.uni-erlangen.de> References: <155655905154.15849.12085215696912730275.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Martin Vigoureux'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: Wed, 01 May 2019 14:14:44 -0000 Thanks, Martin, inline On Mon, Apr 29, 2019 at 08:50:16PM +0000, Vigoureux, Martin (Nokia - FR/Paris-Saclay) wrote: > Hi Barry, > > I had reached the same conclusion, but I think not everyone might and as you highlight it shouldn't be difficult to make sure that there is no misunderstanding of what is in scope and out of scope of the charter. On the first item, would Barry's rewrite proposal resolve your concern ? If not, do you have a specific textual suggestion ? > On the second item, I am afraid that this charter might be setting expectations on the pace (though not quantified) at which documents will be processed between adoption and LC. Yes, although i would call it more "preference" than "expectation". We had from day 1 of ANIMA expectations from our ADs for speedy delivery of implementable results helping operators (rightfully so given how ANIMA is in OPS) versus an ongoing influx of more researchy participants (rightfully so given ANIMA was created from NMRG output). In this context we felt it to be useful to emphasise to both constituents (OPS/IESG and participants) how we need to manage our process to meet expecations. Cheers Toerless > -m > > -----Original Message----- > From: Barry Leiba > Sent: Monday, April 29, 2019 20:59 > To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) > Cc: The IESG ; anima-chairs@ietf.org; anima@ietf.org > Subject: Re: Martin Vigoureux's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) > > > I am under the impression that there is a small ambiguity in the > > charter, which shouldn't be hard to resolve: > > > > ANIMA work will rely on the framework described in > > draft-ietf-anima-reference-model. [...] The three areas of the framework are > > [...] and (3) Intent. > > > > ANIMA will not work on Intent [...] without explicit rechartering. > > > > The first piece seems to allow for working on Intent while the second > > clearly not (within the current charter). > > I tripped over that also when I first read it, but then understood: > the WG will rely on the framework, which includes a set of things. > Not all of those things will be worked on via this charter. In particular, "intent" is one of the things that won't be. > > As I read it, I think the charter is OK. I suppose it could be clarified this way: > > OLD > ANIMA work will rely on the framework described in draft-ietf-anima-reference-model. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The three areas of the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA) and (3) Intent. > > NEW > ANIMA work will rely on the framework described in draft-ietf-anima-reference-model, though only parts of the framework are in scope for this charter, as detailed below. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. > The three areas of the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA) and (3) Intent. > > END > > > I'm not sure to understand what the following means: > > > > 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. > > As I read it, it means that the working group won't take on so much work that the work they do take on doesn't get done. Acceptance is based on negotiating a schedule (based on meeting cycles), and if the schedule isn't met, new work items can't be accepted. > > Barry > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed May 1 13:05:11 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 9D44412011E; Wed, 1 May 2019 13:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: anima-chairs@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 13:05:09 -0700 Archived-At: Subject: [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 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 20:05:10 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-anima-01-05: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-anima/ ---------------------------------------------------------------------- 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. (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. ---------------------------------------------------------------------- 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. What is "compounding environment"? From nobody Wed May 1 13:39:57 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 6E435120170; Wed, 1 May 2019 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aNhbOJbaZaQ; Wed, 1 May 2019 13:39:53 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 BADAE120094; Wed, 1 May 2019 13:39:53 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id j11so9094625pff.13; Wed, 01 May 2019 13:39:53 -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=dQeVwTxImQ+upo90g7Jv/bxWCqQq49Iugr0/5KASPi8=; b=DZVTNTnorvaywxdimo1bGaJmdHbNfHEoJV2GF+TUkqll3bYyOJFcluGfbSYjf7ikUZ Wyug9MSeoKB9Ud0YzBoVtAnkpPtbB0mymPMmisCepKyyj1FgrVHCLdPmHxaP0uOQ7y0E 5BpjO9wW1djEyo1yvVWua1B1y2Cxlco230TAYdK43CzhfATPnQCiJ/J/gjDXfOnyI84d VF9lqMsN1ezcML/O0RCplypn7AhEcWHWwVsKDZWQd1OgR09j/ZpeVTfbaGHec1R6uZiP /bfIadoVvrYepJ6CKTCbyerRmW6EHQARo/TZpV4MLofNYZuqlkiYloP35axVD2C8P4Sk QM3Q== 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=dQeVwTxImQ+upo90g7Jv/bxWCqQq49Iugr0/5KASPi8=; b=INImcXhocI/+PIewjOSDjFgJTU/tVD+hDwbSs/+Rrq6RwzQDZUEOjnoYzQJeGjfFYK odp6wEcMbYv0GdQ9XGhYRdivU0BOJpvB/qVUWVgFTzq5aefPj8OWHc3PIWCsQnIg9M8T KQt5epHAMULu4326QmTL/K+ddX1SjI5eimVjH52fY8+YDLER2t6U4XneZleVtUEULMlT NFPxGYZDqL7h9V4ipvZYqPYOxhs1cCVGgaD68ZM6EJfQKO+Ryzl3tGIBMyhqgWgpPQo7 fnp63y/oLeRNghDsDZBn1xb3LNh8gajhT7KIZw3k7zDHtuUb4zqk0nbW0b/iU0Um7LRl 4hsg== X-Gm-Message-State: APjAAAVFfLkUEDupLNOrJptFw76SvVdNG1vjf/tfN28jbSCxh/YIdx83 WrKYoML0IxLbn7zxAeMQomTVkJ5X X-Google-Smtp-Source: APXvYqx5lO1I5TJs0WoJLD6XtJKtvlz8iE6yyqNedAGyaas02pks28QmD3FLBISYwzGhyY6yQ4MKVg== X-Received: by 2002:a65:6496:: with SMTP id e22mr19571pgv.249.1556743192750; Wed, 01 May 2019 13:39:52 -0700 (PDT) Received: from [192.168.178.30] ([118.148.72.205]) by smtp.gmail.com with ESMTPSA id 144sm7802273pfy.49.2019.05.01.13.39.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 13:39:51 -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 Message-ID: Date: Thu, 2 May 2019 08:39:47 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155674110957.1005.941357960327662977.idtracker@ietfa.amsl.com> 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: Wed, 01 May 2019 20:39:56 -0000 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 Wed May 1 14:07:17 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 7E129120021; Wed, 1 May 2019 14:07:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: anima-chairs@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155674483550.725.15616249817593750930.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 14:07:15 -0700 Archived-At: Subject: [Anima] Roman Danyliw's No Objection on charter-ietf-anima-01-05: (with COMMENT) 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, 01 May 2019 21:07:16 -0000 Roman Danyliw has entered the following ballot position for charter-ietf-anima-01-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-anima/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa’s positions on clarifying the throttling mechanism (BLOCK #1) and concerns about the size of the proposed scope relative to historical publication rates (BLOCK #2) I also have a few editorial nits: s/signalling/signaling/ s/management,autonomic/ management, autonomic/ s/the the/the/ From nobody Thu May 2 05:43:44 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 763A81200E6; Thu, 2 May 2019 05:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZZJYZTvmg7T; Thu, 2 May 2019 05:43:39 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150130.outbound.protection.outlook.com [40.107.15.130]) (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 35A6312002F; Thu, 2 May 2019 05:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ruZ3CriJ99HkR9jLae9xQJwLCft8j6Zxkpc6KVZ/l/I=; b=inWtMjljMHfoZ5O+tc3m8nx3YItIY+KhjPViIn5tiE1tCiaVcveYWCpcfwLP3c5XCoCKh0ETC6ohlcCSnRH3OzrvhSCRk0iomdlQziJyIp0NevI98UVzUe/iVih8b4vSwA+5FmMqcKBwh45fezNBMcwWo/H6F9HyPSua0IHjTS4= Received: from DB7PR07MB4999.eurprd07.prod.outlook.com (20.177.193.88) by DB7PR07MB5132.eurprd07.prod.outlook.com (20.178.43.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Thu, 2 May 2019 12:43:36 +0000 Received: from DB7PR07MB4999.eurprd07.prod.outlook.com ([fe80::f071:7c23:7183:a10]) by DB7PR07MB4999.eurprd07.prod.outlook.com ([fe80::f071:7c23:7183:a10%7]) with mapi id 15.20.1856.008; Thu, 2 May 2019 12:43:36 +0000 From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" To: Toerless Eckert CC: Barry Leiba , "anima-chairs@ietf.org" , The IESG , "anima@ietf.org" Thread-Topic: [Anima] Martin Vigoureux's Block on charter-ietf-anima-01-05: (with BLOCK and COMMENT) Thread-Index: AQHU/r2qeVtUT0VZv0+XOOddPeqMHaZTmQJAgAK57YCAASaI4A== Date: Thu, 2 May 2019 12:43:36 +0000 Message-ID: References: <155655905154.15849.12085215696912730275.idtracker@ietfa.amsl.com> <20190501141437.tedkbtbcp5seapco@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190501141437.tedkbtbcp5seapco@faui48f.informatik.uni-erlangen.de> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; x-originating-ip: [91.166.61.139] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 087f8e68-23a5-4c33-b2e2-08d6cefbcba0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5132; x-ms-traffictypediagnostic: DB7PR07MB5132: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(136003)(396003)(39860400002)(199004)(189003)(51444003)(13464003)(71200400001)(256004)(71190400001)(66066001)(305945005)(4326008)(561944003)(54906003)(7736002)(6246003)(316002)(26005)(81156014)(81166006)(53936002)(8936002)(102836004)(53546011)(6506007)(6916009)(52536014)(186003)(66556008)(66946007)(64756008)(66476007)(66446008)(76116006)(73956011)(229853002)(25786009)(476003)(446003)(11346002)(8676002)(33656002)(9686003)(74316002)(6436002)(6306002)(486006)(68736007)(55016002)(508600001)(7696005)(966005)(14454004)(99286004)(6116002)(86362001)(5660300002)(3846002)(2906002)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5132; H:DB7PR07MB4999.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: M97NEt1hgvsSTkH2E9lAKnfBFaGQJlmWmKM/oue+v9WvhEKXWhsD34GRPmySBGT8PK9i5stXvSea22elZnSQlaAa2D3ljsulINNi2K0hrjsh9m4wZ9x3i675SjqC3hFyaNTLrXVwRsGd6JUnrWz71nlxu8ON2qLlCbZcdPlipSGYnbUFEP5/AkOBGWU14QN20/ZtB28Ori34q6AemusNaZIehD/fACBstKB+v/QNILRaNMhW4RdRebRrQ9BjlTZBhiuAp3CDlhtrVwUwmMgafxnz8bc6kP3wwX4wBIxIC1HlzwdOx0wLfinCAuhcRnnRDdZuwJteGVl0NWD9PUdqkVc8OWmFpdNyU/VuulB40mQIRcGJh3rc9Etv/IF2BwmANzdsDj9f3+PMvCHI3+Ft2VQfF26JTbZEmjS2dPcfvR8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 087f8e68-23a5-4c33-b2e2-08d6cefbcba0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 12:43:36.5944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5132 Archived-At: Subject: Re: [Anima] Martin Vigoureux'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: Thu, 02 May 2019 12:43:42 -0000 Hi Toerless, Please see in-line. Thanks -m -----Original Message----- From: Toerless Eckert =20 Sent: Wednesday, May 1, 2019 16:15 To: Vigoureux, Martin (Nokia - FR/Paris-Saclay) Cc: Barry Leiba ; anima-chairs@ietf.org; The IESG = ; anima@ietf.org Subject: Re: [Anima] Martin Vigoureux's Block on charter-ietf-anima-01-05: = (with BLOCK and COMMENT) Thanks, Martin, inline On Mon, Apr 29, 2019 at 08:50:16PM +0000, Vigoureux, Martin (Nokia - FR/Par= is-Saclay) wrote: > Hi Barry, >=20 > I had reached the same conclusion, but I think not everyone might and as = you highlight it shouldn't be difficult to make sure that there is no misun= derstanding of what is in scope and out of scope of the charter. On the first item, would Barry's rewrite proposal resolve your concern ? If not, do you have a specific textual suggestion ? I'd replace paragraphs 3 to 6 with the following 4 paragraphs: The reference model for autonomic networking developed by the ANIMA WG is d= efined in draft-ietf-anima-reference-model. This reference model includes, = but is not limited to, the Autonomic Networking Infrastructure (ANI) and Au= tonomic Functions (AF) built from software modules called Autonomic Service= Agents (ASA). The ANI is specified through prior ANIMA work. It is composed of the Autono= mic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructure= s (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling= Protocol (GRASP). ANIMA will work on closing gaps and extend ANI and its c= omponents. ANIMA will start to define Autonomic Functions (AF) to enable service autom= ation in networks; it will also work on generic aspects of ASA including de= sign guidelines and lifecycle management including coordination and depende= ncy management. Work not related to the framework is welcome for review, but WG adoption of= such work requires explicit rechartering. Also, ANIMA will not work on Int= ent or machine learning and other AI techniques without explicit recharteri= ng. Also, the implications of that sentence are not clear: It will rely on Network Management Research Group (NMRG) to define the next steps for Intent. Does it mean that NMRG work on intent can/will be reused by ANIMA for the w= ork defined by this charter, or does it mean that ANIMA expects NMRG to wor= k on Intent such that when ANIMA recharters again it will have material at = hand to work on Intent? The former case would somehow contradict the "no work on intent" rule, and = the latter would be setting what NMRG shall work on (but it would be strang= e that ANIMA specifies the work items of NMRG). But maybe the intent of that sentence is something completely different. So= at best it requires some clarification, or maybe simply needs to be remove= d. > On the second item, I am afraid that this charter might be setting expect= ations on the pace (though not quantified) at which documents will be proce= ssed between adoption and LC. Yes, although i would call it more "preference" than "expectation". We had from day 1 of ANIMA expectations from our ADs for speedy delivery of= implementable results helping operators (rightfully so given how ANIMA is = in OPS) versus an ongoing influx of more researchy participants (rightfully= so given ANIMA was created from NMRG output). In this context we felt it to be useful to emphasise to both constituents (= OPS/IESG and participants) how we need to manage our process to meet expeca= tions. Understood, but the rule is not defined clearly enough, and in fact I agree= with Alissa on this. I think that Brian's suggestion is the best option. Cheers Toerless > -m >=20 > -----Original Message----- > From: Barry Leiba > Sent: Monday, April 29, 2019 20:59 > To: Vigoureux, Martin (Nokia - FR/Paris-Saclay)=20 > > Cc: The IESG ; anima-chairs@ietf.org; anima@ietf.org > Subject: Re: Martin Vigoureux's Block on charter-ietf-anima-01-05:=20 > (with BLOCK and COMMENT) >=20 > > I am under the impression that there is a small ambiguity in the=20 > > charter, which shouldn't be hard to resolve: > > > > ANIMA work will rely on the framework described in > > draft-ietf-anima-reference-model. [...] The three areas of the frame= work are > > [...] and (3) Intent. > > > > ANIMA will not work on Intent [...] without explicit rechartering. > > > > The first piece seems to allow for working on Intent while the=20 > > second clearly not (within the current charter). >=20 > I tripped over that also when I first read it, but then understood: > the WG will rely on the framework, which includes a set of things. > Not all of those things will be worked on via this charter. In particula= r, "intent" is one of the things that won't be. >=20 > As I read it, I think the charter is OK. I suppose it could be clarified= this way: >=20 > OLD > ANIMA work will rely on the framework described in draft-ietf-anima-refer= ence-model. Work not related to this framework is welcome for review, but W= G adoption of such work requires explicit rechartering. The three areas of = the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Au= tonomic Functions (AF) built from software modules called Autonomic Service= Agents (ASA) and (3) Intent. >=20 > NEW > ANIMA work will rely on the framework described in draft-ietf-anima-refer= ence-model, though only parts of the framework are in scope for this charte= r, as detailed below. Work not related to this framework is welcome for re= view, but WG adoption of such work requires explicit rechartering. > The three areas of the framework are (1) the Autonomic Networking Infrast= ructure (ANI), (2) Autonomic Functions (AF) built from software modules cal= led Autonomic Service Agents (ASA) and (3) Intent. >=20 > END >=20 > > I'm not sure to understand what the following means: > > > > Acceptance of work items by the WG will be scheduled/throttled so th= at > > contributors can target them to enter WG last call after not more th= an a number > > of IETF meeting cycles agreed by the AD. >=20 > As I read it, it means that the working group won't take on so much work = that the work they do take on doesn't get done. Acceptance is based on neg= otiating a schedule (based on meeting cycles), and if the schedule isn't me= t, new work items can't be accepted. >=20 > Barry > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu May 2 06:35:06 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 842EF120135; Thu, 2 May 2019 06:34:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: anima-chairs@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155680409850.24913.10148059482735119482.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 06:34:58 -0700 Archived-At: Subject: [Anima] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-anima-01-05=3A_=28with_COMMENT=29?= 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, 02 May 2019 13:34:59 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-anima-01-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-anima/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's second point that the charter is very broad and it could be more productive to use the tool of having a charter to focus down to a few more specific items. However, I don't know the work of this group well enough to provide any more detailed guidance on that. From nobody Fri May 3 08:45: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 EF84A1200CE for ; Fri, 3 May 2019 08:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0epaSMpAvrW for ; Fri, 3 May 2019 08:45:21 -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 D2F60120045 for ; Fri, 3 May 2019 08:45:20 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x43FjIwn002787 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 May 2019 17:45:18 +0200 Received: from DEFTHW99ERLMSX.ww902.siemens.net (defthw99erlmsx.ww902.siemens.net [139.22.70.136]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x43FjHgA005632 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 May 2019 17:45:18 +0200 Received: from DEFTHW99ER9MSX.ww902.siemens.net (139.22.70.94) by DEFTHW99ERLMSX.ww902.siemens.net (139.22.70.136) with Microsoft SMTP Server (TLS) id 14.3.435.0; Fri, 3 May 2019 17:45:17 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.87]) by DEFTHW99ER9MSX.ww902.siemens.net ([139.22.70.94]) with mapi id 14.03.0435.000; Fri, 3 May 2019 17:45:16 +0200 From: "Fries, Steffen" To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] evaluation of pinned-domain-cert equality in BRSKI Thread-Index: AQHU+7SQcR2Pto7dGkS91rRXXXE+06ZZJyhw Date: Fri, 3 May 2019 15:45:16 +0000 Message-ID: References: <17916.1556230586@localhost> In-Reply-To: <17916.1556230586@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.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] evaluation of pinned-domain-cert equality in 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: Fri, 03 May 2019 15:45:24 -0000 Hi Michael,=20 My comments are inline. > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Freitag, 26. April 2019 00:16 > To: anima@ietf.org > Subject: [Anima] evaluation of pinned-domain-cert equality in BRSKI >=20 >=20 > Due to a design concern my MASA looks up domain registrars by public key = rather than certificate(DN). I think that I did this because of > constrained voucher concerns. > A test registrar resigned the certificate used for pinning, and used that= as part of the BRSKI protocol. The private key was not > replaced, so it had the same public key inside the certificate. >=20 > The resulting voucher was pinned to the original certificate, rather than= the certificate that was present. This was then rejected by the > pledge because the certificate pinned was not the same as the registrar t= hat was proximal. >=20 > Before I fix the bug in the MASA such that it always pins with the certif= icate provided, I thought I'd ask some questions. It could be > that my pledge was wrong instead. >=20 > 1) how should a pledge compare pinned-domain-cert to TLS Server Certifica= te. > a) compare Issuer + DN+subjectAltName. > b) compare subjectPublicKeyInfo > c) byte-wise comparison of DER encoded form. >=20 > [I am doing c] In case a) a nonceless voucher would need to be renewed if the issuing CA f= or the registrars TLS certificate has been updated or changed. Update could= be handled by a compare to the rootCA instead of the issuing CA, but this = would lead to the point you stated below. Also, it would require the rootCA= to be part of the voucher=20 Case b) seems similar to c) but the nonceless voucher needs to be updated a= fter renewal of the registrar certificate assumed the key pair is renewed a= nd not only a re-certification of the existing public key is done. In case c) this would mean that you need to renew any nonceless voucher, wh= ich the registrar already possessed after update of the registrars TLS serv= er certificate. >=20 > 2) how should a MASA audit a voucher-request that comes from a JRC that h= as > the same public key, but a different certificate? >=20 > a) it is the same owner, if the old certificate is still valid, then > keep it. > b) it is the same owner, keep the new certificate on file, replacing t= he > previous certificate > c) it is the same owner, keep whichever certificate has a later notAft= er. > d) it is the same owner, only if the issuer+DN are the same. In which > case keep the one with ... > i) a newer PKIX serial number (no, ramdomized serial numbers) > ii) latest notAfter > iii) ??? If the same public key is used, I would propose d) II under the assumption = that DN is the subject name including the domain name. In addition, the SAN= may also be included if a TLS server certificate is intended to represent = multiple domains (for the high availability use case mentioned below). > I note that a high-availability multi-node JRC might have: > a) different certificates with the same DN, and different public keys > b) different certificates with the same DN, and the same public keys, > because rewewal times were skewed. (They will become the same at= the > next sync) > c) different certificates with different DNs b) may not be wanted as the it requires to share the private key on differe= nt instances.=20 c) may not be beneficial in high availability scenarios if the subject DN c= hanges. Here it may be possible to utilize multiple SANs to address the usa= ge of the certificate for multiple domains, keeping the same DN to support = load balancing=20 >=20 > {I note that doing Issuer+DN comparisons is difficult to get right if the= Issuer public key is not easily obtained from a trusted store} >=20 > Now, you might say that the pledge should never expect the TLS Server Cer= tificate to ever differ, byte-for-byte from the pinned- > domain-cert, and that would be reasonable for a completely online situati= on. agree > But in the case of offline vouchers, it's entirely reasonable that the JR= C has rolled it's certificate. In such a situation, either one needs > (1a) or > (1b) above. If we are doing (1a), then we get back to something we thoug= ht we got away from, which was pinning the CA+DN. We > have underspecified this. >=20 > If we go with (1b), then there are some crypto-hygiene operational consid= erations to consider, but I think they are probably > acceptable given that vouchers can be re-issued easily. I think for both cases the re-issuing of vouchers depending on changes of t= he LRC certificate would be necessary Best regards Steffen >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D IPv6 IoT consulting =3D- From nobody Sat May 11 18:51:09 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 3B2ED120094; Sat, 11 May 2019 18:51:07 -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.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <155762586707.24832.10034751105191518432@ietfa.amsl.com> Date: Sat, 11 May 2019 18:51:07 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-20.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: Sun, 12 May 2019 01:51:07 -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-20.txt Pages : 100 Date : 2019-05-11 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-20 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 13 10:01: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 3845B12016F for ; Mon, 13 May 2019 10:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JobP6FbzlWO for ; Mon, 13 May 2019 10:01:07 -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 177A1120175 for ; Mon, 13 May 2019 10:01:06 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id CC73C3826E; Mon, 13 May 2019 13:00:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EC92D101C; Mon, 13 May 2019 13:01:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EA29AC07; Mon, 13 May 2019 13:01:03 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: Ignas Bagdonas In-Reply-To: <155762586707.24832.10034751105191518432@ietfa.amsl.com> References: <155762586707.24832.10034751105191518432@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: [Anima] ready for second WGLC draft-ietf-anima-bootstrapping-keyinfra-20.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: Mon, 13 May 2019 17:01:09 -0000 --=-=-= Content-Type: text/plain internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-20 1) we have clarified MIME types based upon feedback from Thomas Werner of Siemens (who has implemented) 2) some clarifications of serial-number usage. 3) put the $ back on "$transport-proto" as it is valid CDDL. 4) removed unsigned pledge voucher requests 5) example pledge certificates updated with assigned OID (other example vouchers/requests based upon this change still todo before AUTH48) better formatting for these. The document is ready for a second WGLC. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzZos8ACgkQgItw+93Q 3WW4fAgAq5DpAuPFaqItOoETX2NF4PR9jo8l2F8oxFLkjGHirofg6c+hE55V7+S+ 1katERnS2ojnp14V3F0ZuraZhTfPv5CHqan5fXg97bt/PEKdnzC5pa2OTPPA8UTB jW7sowrAXC3x+mFxq76hZ7KmKHq1jEFRJOduzsF3G6y3QDxqICImIljuOgLl88Za 4paFLkmHlhTAgFh7kwYG+vPRVioOq2C2iVuzMAJOxpSGIerTvZDKNRdnwjVo4YNS M7pwPNbOu/wEDBcx4EQe2WDlT+J9bDvL1opus4G8H5XHHIg8hFznP/GV+cYtr13r j1r5/qMbdu/ZSRKQYv7HZgVGHDyTaA== =tApQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 17 12:12: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 D8938120117 for ; Fri, 17 May 2019 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNmKtSz42VZS for ; Fri, 17 May 2019 12:12:43 -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 9F9E912008F for ; Fri, 17 May 2019 12:12:42 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id D0E3F3826B; Fri, 17 May 2019 15:11:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 71C4DDC1; Fri, 17 May 2019 15:12:40 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6F54EB3D; Fri, 17 May 2019 15:12:40 -0400 (EDT) From: Michael Richardson To: anima@ietf.org cc: "Werner\, Thomas" , max pritikin 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] implementer question about BRSKI telemetry return(s) 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, 17 May 2019 19:12:46 -0000 --=-=-= Content-Type: text/plain Max, Thomas, I've just opened issue: https://github.com/anima-wg/anima-bootstrap/issues/130 5.9.4 Enrollment Status Telemetry says: In the case of a SUCCESS the Reason string is omitted. The SubjectKeyIdentifier is included so that the server can record the successful certificate distribution. the section does not explain how the SubjectKeyIdentifier is communicated to the server. It could be taken from the new TLSClientCertificate, if we mean that, we should probably say so. The section is also vague as to server; whether it means JRC or MASA. I think it means the Registrar, but reading the section alone (out of context) makes one wonder. I've now realized that I have probably confused enroll_status (5.9) and voucher_status (5.7) in my brain. I was thinking that the voucher_status gets sent back to the MASA. It is not, we would seem to basically signal to the MASA that the voucher was accepted by asking for the audit log. That's fine in a success situation, but not as useful in a fail situation. I feel that we are missing something here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzfB6gACgkQgItw+93Q 3WUGwQf/YWBXbEVIoC3H/xvJcXqUVJvShNo39qe6N+tB0Eyt4tVwp49RavlXLVYc LST2NrqwOB7IsBTp5D4/z1xtScDR9AxEl9AZu6VyjekDD3OhO6pwZhAPIqkLAgoK J1JT1PcZO7dhmNjOlFwlxrT0udI6mpa8MsHYyL+o7ssNZEqRl8umIxi+nl8JEW9C GBJX4TDlDrJu71c4GqSdVmUMTYyz7RAdsvB6wa9Q3e+eqa/729pNdqPtve2FUAHq 3Y1fvVjtTol7gY7QFpuOW/8stijudjiFaaTSMJon3jADAJ+VoxTmKSPBMtJi/2Tr GtIEZ7x2lt5QkNP+MCFpSLeJEryoIg== =KkBW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 21 14:21:17 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 7BAC21200D6; Tue, 21 May 2019 14:21:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ibagdona@gmail.com, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, Toerless Eckert , tte+ietf@cs.fau.de, anima@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2019 14:21:15 -0700 Archived-At: Subject: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard 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, 21 May 2019 21:21:15 -0000 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) From nobody Sun May 26 19:37: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 F0463120227 for ; Sun, 26 May 2019 19:37:49 -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 xGsJFX8bcGBX for ; Sun, 26 May 2019 19:37:47 -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 CCA1A12021D for ; Sun, 26 May 2019 19:37: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 52E253808A; Sun, 26 May 2019 22:36:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D36E0D91; Sun, 26 May 2019 22:37:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D218683B; Sun, 26 May 2019 22:37:45 -0400 (EDT) From: Michael Richardson To: Thomas Werner , consultancy , anima@ietf.org cc: Jim Schaad 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] 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: Mon, 27 May 2019 02:37:50 -0000 --=-=-= Content-Type: text/plain 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-voucher.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-voucher.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 =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzrTXkACgkQgItw+93Q 3WVSKgf6A7ysrgJFDkvf583Rm4Dq5nNvWqz/r40hKiEeTaYxDfb3VAQxf/89HGAZ pGuak32YrXAyXPedJ2YEDSXmgxcuVziHCdxwKCwbKU87t6HUJDsYjSauZAV8Xfut r4JzMoAaKkxHyPxCAcQ3EsO25bkefuL/uKSygPKSrfGelyXmAWNlXy7/x0/purXo WsbDtSQjBvqu42YRU1PGyXrJlD/F/3jxi63O8kP4YaZHPQ+dOoSRxEwem+Xth9/R X27Y3/XD9ABxwlojENr7zOiAahCcrVbaPwaVjX37FKSQIR9XN2Q1MQr8lhVKlZgT VIZecqQraibz3f3i7cXwc59YwdvOUQ== =aW2b -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 26 19:50: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 0C1A3120234 for ; Sun, 26 May 2019 19:50:49 -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 iLBMHnMi0j1T for ; Sun, 26 May 2019 19:50:47 -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 2159412022E for ; Sun, 26 May 2019 19:50:46 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D3AB3808A; Sun, 26 May 2019 22:49:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1052DD91; Sun, 26 May 2019 22:50:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0EF1283B; Sun, 26 May 2019 22:50:43 -0400 (EDT) From: Michael Richardson To: anima@ietf.org CC: Esko Dijk , Jim Schaad , =?utf-8?Q?G=C3=B6ran_Selander?= 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] 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: Mon, 27 May 2019 02:50:49 -0000 --=-=-= Content-Type: text/plain I've been trying to improve the text to better explain pinning of registrar keys (rather than certificates), in order to resolve https://github.com/anima-wg/constrained-voucher/issues/18 and also to remove as many bytes on the wire required to do constrained enrollment, the question came up. The registrar identity crosses the wire three times! 1) the registrar sends it's identity (whether raw public key or certificate) during the DTLS or EDHOC handshake, 2) the pledge sends the registrar's identity in the voucher-request (signed), 3) then the MASA sends the registrar's identity in the voucher (signed). 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). A sha256 hash is 32-bytes in size. A 256-bit ECDSA key is about 32-bytes in size. An equivalent 2048-bit RSA key is 256 bytes in size. So the hash only wins if we use bigger ECDSA keys, or if we use RSA. (okay, so there are a few bytes for the subject-public-key-info (SPKI) wrapping, which also provides algorithm agility) We could truncate the hash if we felt this was still secure enough We could add the length of the thing (the RPK) being hashed if that would help with pre-image attacks, but that's mostly already there in the SPKI encoding, but I suppose an attacker might find a way to prepad with nonsense DER. Please help me decide if this is a useful thing to do. If it's useful, is it useful enough to drop the pinned-domain-subject-key-info? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzrUIIACgkQgItw+93Q 3WVcpwf9FkDWjm/wAn5leLD6F2Q7zx/gtwlFX14XlnB0lCfK/t0C3iCwqkHgpPYu VupyNG9Ru0RqMNAZMLsF52odIEok84q3+vPXkP++P74vOm7QBCSWDc81ITJC09hA yWg75Hve05XWyqOq6kJu7+41M92h5412eZB5uK2jhDtXvdueRhgVnS1Z4SgbWKkn 9HEV2/zOCnh3/mZ5c2xvqwILEYClMdUgaUt8TdLXZ+bmaeRcP6ec0K2/J0hGhL+/ mRXC9QkJ0Uyr5x9LYppOl2vA+DFSWb5iGMFgU9adCLT9Om043m4UpYxBxvPDnDO9 iSWB8+CHV5vn4iew4X6Sz957uzJ24Q== =2PMR -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 26 20:54: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 27D9412020A for ; Sun, 26 May 2019 20:54:27 -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 lng1Y31LLFB7 for ; Sun, 26 May 2019 20:54:25 -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 BB3B3120033 for ; Sun, 26 May 2019 20:54:24 -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; Sun, 26 May 2019 20:54:18 -0700 From: Jim Schaad To: 'Michael Richardson' , CC: 'Esko Dijk' , =?iso-8859-1?Q?'G=F6ran_Selander'?= References: <31898.1558925443@localhost> In-Reply-To: <31898.1558925443@localhost> Date: Sun, 26 May 2019 20:54:13 -0700 Message-ID: <00ce01d5143f$db431740$91c945c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLNajvIr2XmtF3M0/1jKCqm5c7co6SNqK/g X-Originating-IP: [73.180.8.170] 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: Mon, 27 May 2019 03:54:27 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Sunday, May 26, 2019 7:51 PM > To: anima@ietf.org > Cc: Esko Dijk ; Jim Schaad > ; G=F6ran Selander = > Subject: Pinning of raw public keys in Constrained Vouchers >=20 >=20 > I've been trying to improve the text to better explain pinning of registrar > keys (rather than certificates), in order to resolve > https://github.com/anima-wg/constrained-voucher/issues/18 >=20 > and also to remove as many bytes on the wire required to do = constrained > enrollment, the question came up. The registrar identity crosses the = wire > three times! >=20 > 1) the registrar sends it's identity (whether raw public key or > certificate) during the DTLS or EDHOC handshake, >=20 > 2) the pledge sends the registrar's identity in the voucher-request (signed), >=20 > 3) then the MASA sends the registrar's identity in the voucher = (signed). >=20 > 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. >=20 > A sha256 hash is 32-bytes in size. > A 256-bit ECDSA key is about 32-bytes in size. > An equivalent 2048-bit RSA key is 256 bytes in size. > So the hash only wins if we use bigger ECDSA keys, or if we use RSA. > (okay, so there are a few bytes for the subject-public-key-info (SPKI) > wrapping, which also provides algorithm agility) >=20 > We could truncate the hash if we felt this was still secure enough We could > add the length of the thing (the RPK) being hashed if that would help = with > pre-image attacks, but that's mostly already there in the SPKI = encoding, but I > suppose an attacker might find a way to prepad with nonsense DER. As I remember things: * Adding the random value would make the collision resistance attack = simpler for the registrar. It has some random bytes that do not have to have = any structure to create two different public keys with the same hash value. * Adding the random value might make a second pre-image attack more difficult, but I doubt it. You have more bytes as input, but that is generally not the biggest issue for finding a second pre-image = collision. * You don't care about pre-image resistance if you are making the input public. Generally, one would want to person doing the signing to add the random bytes to make the collision resistance attack harder. However, as one = would need to transport the random bytes this would not make things better. I cannot speak to the level of security that is required for your = solution. However, strength is directly related to the size of the hash value. =20 Jim >=20 > Please help me decide if this is a useful thing to do. > If it's useful, is it useful enough to drop the pinned-domain-subject-key-info? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Mon May 27 07:30:23 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 12477120123 for ; Mon, 27 May 2019 07:30: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 1iZQ_jkq1Kci for ; Mon, 27 May 2019 07:30:19 -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 EE43F12002F for ; Mon, 27 May 2019 07:30:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DC43380BE; Mon, 27 May 2019 10:29:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8B954F39; Mon, 27 May 2019 10:30:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 88A5FB93; Mon, 27 May 2019 10:30:16 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: anima@ietf.org, 'Esko Dijk' , =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3F'G=3DF6ran=5FSelander'=3F=3D?= In-Reply-To: <00ce01d5143f$db431740$91c945c0$@augustcellars.com> References: <31898.1558925443@localhost> <00ce01d5143f$db431740$91c945c0$@augustcellars.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] 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: Mon, 27 May 2019 14:30:21 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: >> 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). jim> Fixing on a single hash function would probably be frowned upon by the IESG. jim> The lack of algorithm flexibility would be an issue. So extending to other hash functions is just a question of amending the YANG. There aren't hundreds of hash functions, and SID values should provide space for at least 30 code points here. Perhaps explaining how the algorithms can be agile in the Security Considerations. >> A sha256 hash is 32-bytes in size. >> A 256-bit ECDSA key is about 32-bytes in size. >> An equivalent 2048-bit RSA key is 256 bytes in size. >> So the hash only wins if we use bigger ECDSA keys, or if we use RSA. >> (okay, so there are a few bytes for the subject-public-key-info (SPKI) >> wrapping, which also provides algorithm agility) >> >> We could truncate the hash if we felt this was still secure enough We >> could >> add the length of the thing (the RPK) being hashed if that would help with >> pre-image attacks, but that's mostly already there in the SPKI encoding, >> but I >> suppose an attacker might find a way to prepad with nonsense DER. jim> As I remember things: jim> * Adding the random value would make the collision resistance attack simpler jim> for the registrar. It has some random bytes that do not have to have any jim> structure to create two different public keys with the same hash jim> value. Sorry, do you mean, simpler for an attack on the registrar? I'm saying that the subject-public-key-info starts with an AlgorithmIdentifier, which is a sequence. An attacker could add additional items to the sequence in order to make a second pre-image attack (usually that requires additional bytes, changing the length of the item). This depends upon the victim verifier ignoring the extra bytes somehow; a Postel Principle parser might do that, and if I were building a pull-parser for this, I might do that. In practice, most constrained implementations avoid DER parsing by accepting a known sequence of bytes for the subject-public-key-info and use memcmp(). I.e. they are extremely conservative in what they accept, to the point of violating the specification one could argue. jim> * Adding the random value might make a second pre-image attack more jim> difficult, but I doubt it. You have more bytes as input, but that is jim> generally not the biggest issue for finding a second pre-image jim> collision. jim> * You don't care about pre-image resistance if you are making the input jim> public. What do you mean by the part about public? Yes, in DTLS 1.2, the certificates are visible, and an active attacker can see them. jim> I cannot speak to the level of security that is required for your solution. jim> However, strength is directly related to the size of the hash value. We make certificates by doing sha256 hashes of the subject-public-key-info and other names, and having the CA sign that. I think that it makes no sense to truncate the hash going into a 256-bit sized signature, since ECDSA signs 256-bit values. I am not sure how to evaluate the strengh required here. It's a CBOR value, so it has a length, and I suppose we could define a way to truncate the value in a standard direction, and then decide later. I think that a non-truncated hash ought to be as strong as sending the key itself, and having two code paths is not a win here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzr9HgACgkQgItw+93Q 3WVXvAf/VBXrh50vRIvsgebhx4jdQY4H2shY0qH/aGax/XlFj1f0gaRYRnmIHKw4 zf940xAwXCMEZOQamehVLRGDcaIrlgnQOFvQL6YaH7EJNHlgnIiUgy5tXCC5zZDY p2lK30K1v1+K9FVw/1nE+m6M2Rfx8UdpwPybYsgbMuAXUmGeiWe/gohYRFJXVc8H LNTcz2M3xizWPFDVZs1rJJ1XHaxIsfCZ2AXKqgKSckxO1Hi8eOMsIKLJhZAoAhoo SwS/JrwFTmlkKX8O3G61PsUftW9WuQBmnvN64vY2vsJ8dYtQZFd26iqb+nlZ0mxm 1sYXISVRequTc69I6kM20S0BxQEU4Q== =ViF6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 27 11:12:41 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 94717120089 for ; Mon, 27 May 2019 11:12:39 -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 cxxvVpJt5d2w for ; Mon, 27 May 2019 11:12:36 -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 4D0BC120019 for ; Mon, 27 May 2019 11:12:36 -0700 (PDT) Received: from Jude (192.168.1.155) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 27 May 2019 11:12:29 -0700 From: Jim Schaad To: 'Michael Richardson' CC: , 'Esko Dijk' , '=?iso-8859-1?Q?'G=F6ran_Selander'?=' References: <31898.1558925443@localhost> <00ce01d5143f$db431740$91c945c0$@augustcellars.com> <19275.1558967416@localhost> In-Reply-To: <19275.1558967416@localhost> Date: Mon, 27 May 2019 11:12:25 -0700 Message-ID: <00fb01d514b7$befd4e20$3cf7ea60$@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: AQLNajvIr2XmtF3M0/1jKCqm5c7cowCzRMdcAo62hPakdIPUoA== X-Originating-IP: [192.168.1.155] 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: Mon, 27 May 2019 18:12:40 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Monday, May 27, 2019 7:30 AM > To: Jim Schaad > Cc: anima@ietf.org; 'Esko Dijk' ; =?iso-8859- > 1?Q?'G=F6ran_Selander'?= > Subject: Re: Pinning of raw public keys in Constrained Vouchers > > > Jim Schaad wrote: > >> 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). > > jim> Fixing on a single hash function would probably be frowned upon by > the IESG. > jim> The lack of algorithm flexibility would be an issue. > > So extending to other hash functions is just a question of amending the > YANG. > There aren't hundreds of hash functions, and SID values should provide > space > for at least 30 code points here. Perhaps explaining how the algorithms can > be agile in the Security Considerations. > > >> A sha256 hash is 32-bytes in size. > >> A 256-bit ECDSA key is about 32-bytes in size. > >> An equivalent 2048-bit RSA key is 256 bytes in size. > >> So the hash only wins if we use bigger ECDSA keys, or if we use RSA. > >> (okay, so there are a few bytes for the subject-public-key-info (SPKI) > >> wrapping, which also provides algorithm agility) > >> > >> We could truncate the hash if we felt this was still secure enough We > >> could > >> add the length of the thing (the RPK) being hashed if that would help > with > >> pre-image attacks, but that's mostly already there in the SPKI encoding, > >> but I > >> suppose an attacker might find a way to prepad with nonsense DER. > > jim> As I remember things: > > jim> * Adding the random value would make the collision resistance attack > simpler > jim> for the registrar. It has some random bytes that do not have to have > any > jim> structure to create two different public keys with the same hash > jim> value. > > Sorry, do you mean, simpler for an attack on the registrar? No, I mean a simpler attack by the registrar. > > I'm saying that the subject-public-key-info starts with an AlgorithmIdentifier, > which is a sequence. An attacker could add additional items to the sequence > in order to make a second pre-image attack (usually that requires additional > bytes, changing the length of the item). > This depends upon the victim verifier ignoring the extra bytes somehow; a > Postel Principle parser might do that, and if I were building a pull-parser for > this, I might do that. Given that this is a DER encoded item, there is no way for a victim to ignore the extra bytes inside of the SPKI structure. If it does then then it is completely incorrectly doing the parsing. You would not even be able to have trailing bytes that might or might not be part of the SPKI object. Even if you did BER indefinite length encoding, you would not be able to ignore the extra bytes, but you would have bytes to play with as you can have different encodings that represent the same output value. > > In practice, most constrained implementations avoid DER parsing by > accepting a known sequence of bytes for the subject-public-key-info and use > memcmp(). > I.e. they are extremely conservative in what they accept, to the point of > violating the specification one could argue. I don't know that I would say that this is a violation of the spec. You are saying does this match what I expect to see and since it is DER a memcmp is a fine way to do this. The issue here would be that you need to make sure that you have correctly identified the border of the SPKI in the containing object. That is, you cannot put in extra bytes in the surrounding object and do the memcmp based on the size in memory rather than the size in the PDU. > > jim> * Adding the random value might make a second pre-image attack > more > jim> difficult, but I doubt it. You have more bytes as input, but that is > jim> generally not the biggest issue for finding a second pre-image > jim> collision. > > jim> * You don't care about pre-image resistance if you are making the > input > jim> public. > > What do you mean by the part about public? > Yes, in DTLS 1.2, the certificates are visible, and an active attacker can see > them. Yes that is what I mean. There is no issue about the attacker getting the hashed bytes from the hash structure. There are some cases where the content is not available to the attacker and doing an inversion is what is desired. An example of this is creating key values from passwords. > > jim> I cannot speak to the level of security that is required for your > solution. > jim> However, strength is directly related to the size of the hash value. > > We make certificates by doing sha256 hashes of the subject-public-key-info > and other names, and having the CA sign that. I think that it makes no sense > to truncate the hash going into a 256-bit sized signature, since ECDSA signs > 256-bit values. I am not sure how to evaluate the strengh required here. > It's a CBOR value, so it has a length, and I suppose we could define a way to > truncate the value in a standard direction, and then decide later. The first sentence has me slightly worried. Is the CA computing the hash or is the hash being provided to the CA? > > I think that a non-truncated hash ought to be as strong as sending the key > itself, and having two code paths is not a win here. One attack is a birthday attack. This is O(2^(n/2)) in terms of inputs to be evaluated. That is if you compute 2^(n/2) hash values you have a 50/50 chance of finding a collision. This means that it takes 2^128 attempts for a 256-bit hash value, but only 2^64 for a 128-bit hash value, even if you truncate as SHA-256 value to 128 bits rather than using a 128-bit hash function (such as AES-CBC). The idea that 64-bit authentication values are fine is the current thinking in the CoRE and ACE groups as that is the size of authentication value that is being used for encryption of items. Part of this is based on the assumption that these values are only of interest for short term and not historically. TLS on the other hand is worried about long term (i.e. recorded for later use) and thus has gone with longer authentication values as a general rule. In COSE we are saying that a truncated hash is fine for identifying certificates, but that is operating as a filter rather than an identifier. Jim > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Mon May 27 11:23: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 067F9120077 for ; Mon, 27 May 2019 11:23:19 -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 MwE6_ZDnLmYj for ; Mon, 27 May 2019 11:23:17 -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 14681120041 for ; Mon, 27 May 2019 11:23:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E1120380BE for ; Mon, 27 May 2019 14:22:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 75C53F39; Mon, 27 May 2019 14:23:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 730B9CB3 for ; Mon, 27 May 2019 14:23:14 -0400 (EDT) From: Michael Richardson To: anima@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] early allocation for id-ct-animaCBORVoucher 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, 27 May 2019 18:23:19 -0000 --=-=-= Content-Type: text/plain draft-ietf-anima-constrained-voucher has an IANA consideration, at: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-03#section-9.4 which says: ## The SMI Security for S/MIME CMS Content Type Registry This document registers an OID in the "SMI Security for S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with the value: Decimal Description References ------- -------------------------------------- ---------- TBD1 id-ct-animaCBORVoucher [ThisRFC] We need this for interop testing that is already ongoing. Can this go to an early allocation? Thank you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzsKxIACgkQgItw+93Q 3WX5jgf+MCzhdMlX8/6RBjiiVA0bIzkcjskuxhMurzITv7/TNwCBT3+cC97xmhx8 nx5+hkOECNxZyNykhs3dz2VS+7rfpaFtfLa1FYTOTHtkL+xIrxB8l5yWb6gwXgI6 7ESJzlUGLpynPEqZAYnnIiaAd2QPF50dy76XpoCZnDMwTt0Kgo8s59Zdp5QosZLZ ZMK0X+ncuM/sk+GxO2EoAC+QRzWNbY1WlC7j1RZmdfsCGGbwALm+00alOfgT+q84 STzJrQOnx8XZyChGZZFjdSQfhAoOZMDEDodx3N4NChNyK90oruDCjvL6nIvoGuuw WuaTjVvIzGoPFVQh3UCNHZjkXajRLQ== =lhFn -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 29 08:07: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 E464112016C for ; Wed, 29 May 2019 08:07:14 -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 QUnNXO_lohMH for ; Wed, 29 May 2019 08:07:10 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 3F23012015E for ; Wed, 29 May 2019 08:06:59 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x4TF6umQ020644 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 29 May 2019 17:06:56 +0200 Received: from DEFTHW99ERHMSX.ww902.siemens.net (defthw99erhmsx.ww902.siemens.net [139.22.70.133]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x4TF6u4u028528 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 29 May 2019 17:06:56 +0200 Received: from DEFTHW99ERPMSX.ww902.siemens.net (139.22.70.202) by DEFTHW99ERHMSX.ww902.siemens.net (139.22.70.133) with Microsoft SMTP Server (TLS) id 14.3.435.0; Wed, 29 May 2019 17:06:56 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ERPMSX.ww902.siemens.net ([139.22.70.202]) with mapi id 14.03.0435.000; Wed, 29 May 2019 17:06:55 +0200 From: "Fries, Steffen" To: "anima@ietf.org" Thread-Topic: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard Thread-Index: AQHVEBsnSObOmAdIkUSiNyOqoj43mqaCPatw Date: Wed, 29 May 2019 15:06:54 +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: 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: Wed, 29 May 2019 15:07:15 -0000 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:=20 In Figure 1 of the BRSKI draft, for the communication between the Domain Re= gistrar (RA) and the Key Infrastructure (CA), EST is stated.=20 >From my understanding of the description EST as enrollment protocol between= an RA and the CA is meant exemplary but not prescriptive? From the protoco= l flow for the enrollment itself I understood BRSKI describes the flow unti= l the Domain Registrar but is open regarding the protocol applied between t= he domain registrar and the CA. It may be EST.=20 Is my understanding right? If yes, would it be appropriate to state "e.g., = EST (RFC 7030)" in the figure to make clear it is an example? Best regards Steffen > -----Original Message----- > From: Anima On Behalf Of The IESG > Sent: Dienstag, 21. Mai 2019 23:21 > To: 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 > Subject: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures > (BRSKI)) to Proposed Standard >=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 (B= RSKI)' > as Proposed Standard >=20 > This is a second Last Call. IoT Directorate review was done after the ANI= MA 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 fin= al 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/= ballot/ >=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 From nobody Wed May 29 08:37: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 2BF9A1201F1 for ; Wed, 29 May 2019 08:37:19 -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 xFXWMH-f4jNb for ; Wed, 29 May 2019 08:37:16 -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 9C7CB1201E7 for ; Wed, 29 May 2019 08:37:14 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E74343826E; Wed, 29 May 2019 11:36:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0FED3F60; Wed, 29 May 2019 11:37:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0E7D78EF; Wed, 29 May 2019 11:37:11 -0400 (EDT) From: Michael Richardson To: Jim Schaad cc: anima@ietf.org, 'Esko Dijk' , =?us-ascii?Q?'=3D=3Fiso-8859-1=3FQ=3F'G=3DF6ran=5FSelander'=3F=3D'?= In-Reply-To: <00fb01d514b7$befd4e20$3cf7ea60$@augustcellars.com> References: <31898.1558925443@localhost> <00ce01d5143f$db431740$91c945c0$@augustcellars.com> <19275.1558967416@localhost> <00fb01d514b7$befd4e20$3cf7ea60$@augustcellars.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] 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: Wed, 29 May 2019 15:37:19 -0000 --=-=-= Content-Type: text/plain Jim Schaad wrote: jim> As I remember things: jim> * Adding the random value would make the collision resistance attack jim> simpler for the registrar. It has some random bytes that do not jim> have to have any structure to create two different public keys with jim> the same hash value. >> Sorry, do you mean, simpler for an attack on the registrar? > No, I mean a simpler attack by the registrar. Yes, I'd call it the malicious registrar. The attack would take an existing (nonceless) voucher that pinned the device to a specific registrar, and then try to create a registrar with a keypair that hashes the same. This would be used for offline registrars. If we pin the public key then this can not happen. > Given that this is a DER encoded item, there is no way for a victim to > ignore the extra bytes inside of the SPKI structure. If it does then then > it is completely incorrectly doing the parsing. You would not even be able > to have trailing bytes that might or might not be part of the SPKI object. > Even if you did BER indefinite length encoding, you would not be able to > ignore the extra bytes, but you would have bytes to play with as you can > have different encodings that represent the same output value. Are we are agreeing, but using different terms? So yes, an attacker could resort to non-DER encoding (BER encoding) to give it bytes to play with. That would be non-DER though. My reading of the ASN.1 is that one could include arbitrary additional parameters in the algorithm SEQUENCE, (correctly DER encoded) and use those bytes to do the pre-image attack... except that it would fail because constrained devices are using memcmp(). >> In practice, most constrained implementations avoid DER parsing by >> accepting a known sequence of bytes for the subject-public-key-info and >> use memcmp(). >> I.e. they are extremely conservative in what they accept, to the point of >> violating the specification one could argue. jim> I don't know that I would say that this is a violation of the spec. You jim> are saying does this match what I expect to see and since it is DER a memcmp jim> is a fine way to do this. well, because it locks the list of parameters to be 0. AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Perhaps we have never extended any, but the extension point is right here. >> We make certificates by doing sha256 hashes of the subject-public-key-info >> and other names, and having the CA sign that. I think that it makes no >> sense to truncate the hash going into a 256-bit sized signature, since >. ECDSA signs 256-bit values. I am not sure how to evaluate the strengh required here. >> It's a CBOR value, so it has a length, and I suppose we could define a way to >> truncate the value in a standard direction, and then decide later. > The first sentence has me slightly worried. Is the CA computing the hash or > is the hash being provided to the CA? I think that in traditional CA processing, we provide the public key (in a CSR) to the CA, and it computes the hash. My point here is that if we were concerned (as I concern myself above) with pre-image attacks against sha256 under signature, then we should be concerned about certificates, period :-) I think that we can also intelligently advise pledge to carefully check the DER encoding is minimal, and using memcmp() works very well here. Stupider implementation wins here :-) >> I think that a non-truncated hash ought to be as strong as sending the key >> itself, and having two code paths is not a win here. > One attack is a birthday attack. This is O(2^(n/2)) in terms of inputs to > be evaluated. That is if you compute 2^(n/2) hash values you have a 50/50 > chance of finding a collision. This means that it takes 2^128 attempts for > a 256-bit hash value, but only 2^64 for a 128-bit hash value, even if you > truncate as SHA-256 value to 128 bits rather than using a 128-bit hash > function (such as AES-CBC). The idea that 64-bit authentication values are > fine is the current thinking in the CoRE and ACE groups as that is the size > of authentication value that is being used for encryption of items. Part of > this is based on the assumption that these values are only of interest for > short term and not historically. TLS on the other hand is worried about > long term (i.e. recorded for later use) and thus has gone with longer > authentication values as a general rule. In COSE we are saying that a > truncated hash is fine for identifying certificates, but that is operating > as a filter rather than an identifier. I have not paid enough attention to the HMAC algorithms in COSE... just reading rfc8152. Truncated to 64-bits. Hmm. We wouldn't have a keyed-hash, just a hash, which makes it more vulnerable to off-line dictionary attacks I think. But, I think you are perhaps referring to the kid usage? In online uses of the voucher, it has a limited time when it is useful, and in the online usage, there is also a freshness nonce. So it seems that we could truncate the hash efficiently. It would be inappropriate to generate off-line nonceless (constrained) vouchers with this method, but I think that is something we can write down intelligently. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzupyYACgkQgItw+93Q 3WUKzgf9ExGIyxmAX23KpzYWqSwF0/My45Jx4bW3tq4/6iOR0VVYwBlfa/QFu/Al hYG94C3y3mU5LURSstQMCPu+9//Mjj0+uKTJKTWTEvhWNPkhaZS2rtXv9aCBpzXj dNjl5ElIrKRxqh546O3bQfOS1l2sMvo1lB6Wv0l6vCkcw5pRKEUewkKNufFdiWhK PdGX/ajwWaa6WUmBkb1f7FVxBek5Ih3g+fHeVxHhCXnqg9LO4yHN1G8ucyB9LDj5 /6DIdY8RSJ06UBKVs696xTrs3B+8yQaDkoNDKLt7jR49GuIiSEZPoyxjLWyUqQ5V aCPPCjr4zQugGO7PhCY/tjIvXkJnEA== =OGf9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 29 09:30:46 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 41ABD120115 for ; Wed, 29 May 2019 09:30: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, 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 b26wZwS-p964 for ; Wed, 29 May 2019 09:30:41 -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 BDEAB12019F for ; Wed, 29 May 2019 09:30:40 -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, 29 May 2019 09:30:33 -0700 From: Jim Schaad To: 'Michael Richardson' CC: , 'Esko Dijk' , '=?iso-8859-1?Q?'G=F6ran_Selander'?=' References: <31898.1558925443@localhost> <00ce01d5143f$db431740$91c945c0$@augustcellars.com> <19275.1558967416@localhost> <00fb01d514b7$befd4e20$3cf7ea60$@augustcellars.com> <25038.1559144231@localhost> In-Reply-To: <25038.1559144231@localhost> Date: Wed, 29 May 2019 09:30:29 -0700 Message-ID: <01e301d5163b$d649a5d0$82dcf170$@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: AQLNajvIr2XmtF3M0/1jKCqm5c7cowCzRMdcAo62hPYCG0H1ygKstBnLpFFRg6A= X-Originating-IP: [73.180.8.170] 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: Wed, 29 May 2019 16:30:44 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Wednesday, May 29, 2019 8:37 AM > To: Jim Schaad > Cc: anima@ietf.org; 'Esko Dijk' ; '=?iso-8859- > 1?Q?'G=F6ran_Selander'?=' > Subject: Re: Pinning of raw public keys in Constrained Vouchers > > > Jim Schaad wrote: > jim> As I remember things: > jim> * Adding the random value would make the collision resistance attack > jim> simpler for the registrar. It has some random bytes that do not > jim> have to have any structure to create two different public keys with > jim> the same hash value. > > >> Sorry, do you mean, simpler for an attack on the registrar? > > > No, I mean a simpler attack by the registrar. > > Yes, I'd call it the malicious registrar. > > The attack would take an existing (nonceless) voucher that pinned the device > to a specific registrar, and then try to create a registrar with a keypair that > hashes the same. This would be used for offline registrars. > If we pin the public key then this can not happen. > > > Given that this is a DER encoded item, there is no way for a victim to > > ignore the extra bytes inside of the SPKI structure. If it does then then > > it is completely incorrectly doing the parsing. You would not even be able > > to have trailing bytes that might or might not be part of the SPKI object. > > Even if you did BER indefinite length encoding, you would not be able to > > ignore the extra bytes, but you would have bytes to play with as you can > > have different encodings that represent the same output value. > > Are we are agreeing, but using different terms? > So yes, an attacker could resort to non-DER encoding (BER encoding) to give > it bytes to play with. That would be non-DER though. > My reading of the ASN.1 is that one could include arbitrary additional > parameters in the algorithm SEQUENCE, (correctly DER encoded) and use > those bytes to do the pre-image attack... except that it would fail because > constrained devices are using memcmp(). No - there are constraints on what can occur in the ANY field (1988 syntax) that are defined by the OID of the algorithm. Thus while the structure allows for arbitrary additional parameters, they are restricted by the algorithm to a single (usually absent or NULL) value. > > >> In practice, most constrained implementations avoid DER parsing by > >> accepting a known sequence of bytes for the subject-public-key-info > and > >> use memcmp(). > >> I.e. they are extremely conservative in what they accept, to the point of > >> violating the specification one could argue. > > jim> I don't know that I would say that this is a violation of the spec. You > jim> are saying does this match what I expect to see and since it is DER a > memcmp > jim> is a fine way to do this. > > well, because it locks the list of parameters to be 0. > > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > > Perhaps we have never extended any, but the extension point is right here. This is the syntax that I normally use: AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), parameters ALGORITHM-TYPE. &Params({AlgorithmSet}{@algorithm}) OPTIONAL } Which shows that the extension point is restricted and not completely open. Use the DER sequence requires that this be checked correctly. > > >> We make certificates by doing sha256 hashes of the subject-public-key- > info > >> and other names, and having the CA sign that. I think that it makes no > >> sense to truncate the hash going into a 256-bit sized signature, since > >. ECDSA signs 256-bit values. I am not sure how to evaluate the strengh > required here. > >> It's a CBOR value, so it has a length, and I suppose we could define a > way to > >> truncate the value in a standard direction, and then decide later. > > > The first sentence has me slightly worried. Is the CA computing the hash > or > > is the hash being provided to the CA? > > I think that in traditional CA processing, we provide the public key (in a > CSR) to the CA, and it computes the hash. My point here is that if we were > concerned (as I concern myself above) with pre-image attacks against sha256 > under signature, then we should be concerned about certificates, period :-) > > I think that we can also intelligently advise pledge to carefully check the DER > encoding is minimal, and using memcmp() works very well here. > Stupider implementation wins here :-) > > > >> I think that a non-truncated hash ought to be as strong as sending the > key > >> itself, and having two code paths is not a win here. > > > One attack is a birthday attack. This is O(2^(n/2)) in terms of inputs to > > be evaluated. That is if you compute 2^(n/2) hash values you have a > 50/50 > > chance of finding a collision. This means that it takes 2^128 attempts for > > a 256-bit hash value, but only 2^64 for a 128-bit hash value, even if you > > truncate as SHA-256 value to 128 bits rather than using a 128-bit hash > > function (such as AES-CBC). The idea that 64-bit authentication values > are > > fine is the current thinking in the CoRE and ACE groups as that is the size > > of authentication value that is being used for encryption of items. Part of > > this is based on the assumption that these values are only of interest for > > short term and not historically. TLS on the other hand is worried about > > long term (i.e. recorded for later use) and thus has gone with longer > > authentication values as a general rule. In COSE we are saying that a > > truncated hash is fine for identifying certificates, but that is operating > > as a filter rather than an identifier. > > I have not paid enough attention to the HMAC algorithms in COSE... just > reading rfc8152. Truncated to 64-bits. Hmm. We wouldn't have a keyed- > hash, just a hash, which makes it more vulnerable to off-line dictionary > attacks I think. > But, I think you are perhaps referring to the kid usage? Look at the hash draft not the RFC - https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > > In online uses of the voucher, it has a limited time when it is useful, and in > the online usage, there is also a freshness nonce. So it seems that we could > truncate the hash efficiently. It would be inappropriate to generate off-line > nonceless (constrained) vouchers with this method, but I think that is > something we can write down intelligently. I would want to read the result, but I think this would be correct. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > >