Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

Tero Kivinen <kivinen@iki.fi> Thu, 07 April 2016 14:09 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24812D0E3 for <ipsec@ietfa.amsl.com>; Thu, 7 Apr 2016 07:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjBsrAnzXc-T for <ipsec@ietfa.amsl.com>; Thu, 7 Apr 2016 07:09:11 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7213612D0B9 for <ipsec@ietf.org>; Thu, 7 Apr 2016 07:09:10 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u37E95oM003251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Apr 2016 17:09:05 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u37E95HT002363; Thu, 7 Apr 2016 17:09:05 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22278.27137.445934.901390@fireball.acr.fi>
Date: Thu, 07 Apr 2016 17:09:05 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <F40AD8BE6DDA484FB95ED61653259871@notebook>
References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> <22277.20520.264319.773683@fireball.acr.fi> <27E13094E90E4AC8BAE9DFF017324AE0@notebook> <22277.35607.896237.279372@fireball.acr.fi> <F40AD8BE6DDA484FB95ED61653259871@notebook>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 7 min
X-Total-Time: 7 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/0EVrOwqATxBGd_KDVPi4HWmxA3c>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2016 14:09:18 -0000

Valery Smyslov writes:
> After re-reading the draft I think that I'm also a bit unhappy with
> the way the last table (Section 4.2) is introduced. The draft says
> that this table is:
> 
>    Recommendation of Authentication Method described in [RFC7427]
>    notation.
> 
> However, the values from this table are just examples in RFC7427.
> Why exactly these algorithms were selected for recommendation?

Note, that most of them are MAY, so we should really remove them from
this draft. And they are the algorithms we expect people to use.

> What about others (EdDSA, GOST etc)?

EdDSA is just about getting oid, so we cannot really list it here. For
GOST I have no idea what the oid would be. Both of them would be in
the same level as sha256WithRSAEncryption, sha384WithRSAEncryption,
sha512WithRSAEncryption, sha512WithRSAEncryption, dsa-with-sha256,
ecdsa-with-sha384, and ecdsa-with-sha512.

> I understand that the algorithms listed were probably most popular
> (at least some of them) at the time RFC 7427 ws written. But why
> continue to maintain this list, when it is just a list of examples
> in RFC7427?

One of the reason RF7427 lists that many oids, is that there is no
centralized registry for them. I.e. you cannot go somewhere and get
list of OIDs you can use for signatures, so RF7427 tried to collect
all signature algortihms people might use.

Anyways I think we need to remove all that is not SHOULD or SHOULD NOT
from the list, i.e., everything we have MAY recommendation in the
list. 

> Well, I understand that some recommendations should be given.
> But probably only those signing algorithms that have non-MAY
> status should be listed and a note should be added that
> all others are MAY (that will refer to any unlisted signature
> algorithm)?

I agree on removing all MAY algorithms, we do not need note, as that
is already said in the section 1.2.
-- 
kivinen@iki.fi