Re: [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-autonomic-control-plane-29: (with COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 October 2020 20:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 BC3503A1084 for <anima@ietfa.amsl.com>; Tue, 6 Oct 2020 13:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.113
X-Spam-Level:
X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 On5uj4-2nUkM for <anima@ietfa.amsl.com>; Tue, 6 Oct 2020 13:43:34 -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 2153F3A106D for <anima@ietf.org>; Tue, 6 Oct 2020 13:43:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2184C389C6; Tue, 6 Oct 2020 16:48:53 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pLl8gCZYGvev; Tue, 6 Oct 2020 16:48:52 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ED1AD389C5; Tue, 6 Oct 2020 16:48:51 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 942C870D; Tue, 6 Oct 2020 16:43:31 -0400 (EDT)
To: anima@ietf.org, kaduk@mit.edu, Toerless Eckert <tte@cs.fau.de>
References: <160159178470.16845.16995175102690434365@ietfa.amsl.com>
From: Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <dcc69101-73be-cf9d-2e6f-8356ca38cb56@sandelman.ca>
Date: Tue, 6 Oct 2020 16:43:31 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <160159178470.16845.16995175102690434365@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/JITK3GEtp6a2FxpV8GX4_UurDUM>
Subject: Re: [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-autonomic-control-plane-29: (with COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2020 20:43:36 -0000

On 2020-10-01 6:36 p.m., Benjamin Kaduk via Datatracker wrote:
> A couple of the new bits in the -29 might benefit from targeted review (noted
> inline), e.g., for CDDL, TSV, or INT-specific aspects.

Carsten has already done that for CDDL.
I'm unclear what TSV and INT specific things you have in mind.


>     ACP nodes MUST NOT support certificates with RSA public keys whose
>     modulus is less than 2048 bits, or certificates whose ECC public keys
>     are in groups whose order is less than 256 bits.  RSA signing
>     certificates with 2048-bit public keys MUST be supported, and such
> 
> I think I mentioned this previously (and sorry for the repetition if I
> did), but just in case I didn't: this 256-bit group order requirement
> excludes Ed25519 and friends.  If you're fine with that, that's okay; I
> just want to make sure it's an informed choice.

Right, Ed25519 is considered to be a curve of 128-bits of equivalent 
strength.  My understanding is that secp256*, while having 256-bit 
curves, is also 128-bits of strength.
And RSA keys of 2048 bits is also of that relative strength.

I think that this is what Toerless is trying to say, but he didn't get 
the wording right.  Can you advise what the correct way to ask for this 
is?  Can we just point elsewhere?

> I think I may have failed to think about and comment on this previously,
> but doing direct ECDH with the (static) key in the certificate is pretty
> uncommon -- as I understand it you don't need this bit set in order to
> use the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite, for
> example.  To be clear, I'm not saying it's inherently wrong to make this
> requirement, just that I don't think it's needed for the use-cases
> presented in this document.  (It may also make it harder to get such
> certificates issued in the future, though it's hard to predict what
> path CA policies will take in the future.)

Agreed, and it's why I prefer to say less.