[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 13 October 2016 11:50 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B340A129464; Thu, 13 Oct 2016 04:50:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com>
Date: Thu, 13 Oct 2016 04:50:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Niua1Y53-fgQM21-r3zYuikAI80>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-safecurves@ietf.org, kivinen@iki.fi
Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Oct 2016 11:50:50 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-safecurves-05: Yes

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.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- Wouldn't it be good to encourage minimising re-use of
public values for multiple key exchanges? As-is, the text
sort-of encourages use for "many key exchanges" in
section 4.

- Sorry if I'm forgetting how we handle this in IPsec,
but is an implementation of this RFC expected to support
both curves? I think it'd be ok to say that 25519 is a
MUST for folks doing, this but that 448 is optional.  I'm
also fine if we mean that implementing this means you
have to support both btw but you don't say (here) that
that's the case.