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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 13 October 2016 12:07 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 07142128874; Thu, 13 Oct 2016 05:07:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.297
X-Spam-Level:
X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 TcNNnNJnj75P; Thu, 13 Oct 2016 05:07:31 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02BD129426; Thu, 13 Oct 2016 05:07:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2AEBBE4D; Thu, 13 Oct 2016 13:07:28 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBYoa1xLP8rb; Thu, 13 Oct 2016 13:07:28 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2C6A4BE32; Thu, 13 Oct 2016 13:07:28 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476360448; bh=xvV8JhDdHzhHQ2BCYSbSZIUAFiVZUFAEEj5dqhGDUAk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eoFpjWAyvR140bnUDLm7v6uu4pMVNFHJitcG2w9lliwhgYLKoSNQh2Tyiw6+lq45B +27iHnCLDvZm31rzHJZcjqnBtaNGNaw++k+bqgPLXseYG2G4otRnCz1mcc23YfGy9k fRzdv/F7sg13CMyVhk0U4djAFU8XIyxmwYQ03y6A=
To: Tero Kivinen <kivinen@iki.fi>
References: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> <22527.30786.897423.123891@fireball.acr.fi>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <04fc9ee1-283a-3232-9fb7-dd3c4100bf58@cs.tcd.ie>
Date: Thu, 13 Oct 2016 13:07:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <22527.30786.897423.123891@fireball.acr.fi>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000303040404090403030202"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/pPH_q9QOnqON-bQJWYuzy85BeWY>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-ipsecme-safecurves@ietf.org
Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)
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, 13 Oct 2016 12:07:34 -0000

Thanks Tero and sorry for forgetting:-)

Cheers,
S.

On 13/10/16 13:04, Tero Kivinen wrote:
> Stephen Farrell writes:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-ipsecme-safecurves-05: Yes
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> - 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.
> 
> In IPsec we do not specify any requirement levels in the actual
> algorithm documents. The algorithm documents just allocate the IANA
> numbers and specify how they algorithms are used.
> 
> Then we have separate documents (new versions soon to be in front of
> IESG) specifying the actual mandatory to implement algorithms.
> 
> Whether some implementation supports this new RFC is something that
> does not have well define answer, as people could say they implement
> this RFC if they support one or other, or both curves. Usually people
> are just saying they support algorithm RFC if they support one
> algorithm from there. I.e., vendors usually say they support RFC2451,
> even if they only support 3DES from there, and might not support
> CAST-128, RC5, IDEA and Blowfish.
> 
> Anyways the mandatory to implement ciphers are specified in the
> rfc4307bis [1] and rfc7321bis [2].
> 
> These curves are not mentioned there, so they are still going to be
> MAY. When we are going to update 4307bis again then we are most likely
> going to make them SHOULD+ or even MUST (if there is enough
> implementations actually implementing them at that point).
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/
> [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/
>