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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 13 Oct 2016 04:50:49 -0700

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.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 13 Oct 2016 15:04:18 +0300

> draft-ietf-ipsecme-safecurves-05: Yes

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/
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Oct 2016 13:07:28 +0100

Thanks Tero and sorry for forgetting:-)

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Oct 2016 15:27:39 +0300

Hi, Stephen

> sort-of encourages use for "many key exchanges" in

I don’t think so. Re-use reduces the computation cost of an IKE Responder (or TLS server) without sacrificing security.  There was some discussion of this in CFRG, but I see that it didn’t make it into RFC 7748, so all I can find is some StackExchange question ([1]).

It does make the static keypair valuable. It is definitely not a good idea to store the private key on-disk and keep it forever, but generating a new key once in a while and discarding the old key is usually a good compromise there.

Anyway key-pair reuse is established practice. Using constant-time implementations is essential to making this practice safe, and the Security Considerations sections says just that.

Yoav

[1] http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-key

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Oct 2016 13:36:35 +0100

On 13/10/16 13:27, Yoav Nir wrote:
> Hi, Stephen
> 
>> 
>> - 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.
> 
> I don’t think so. 

Fair enough, though when I said "minimise" I didn't mean
"never re-use." But all you say below is correct, so not
that big a deal, but I do think it'd be better to explicitly
encourage implementers to roll their private values as
often as makes sense in their situation.

S.

> Re-use reduces the computation cost of an IKE
> Responder (or TLS server) without sacrificing security.  There was
> some discussion of this in CFRG, but I see that it didn’t make it
> into RFC 7748, so all I can find is some StackExchange question
> ([1]).
> 
> It does make the static keypair valuable. It is definitely not a good
> idea to store the private key on-disk and keep it forever, but
> generating a new key once in a while and discarding the old key is
> usually a good compromise there.
> 
> Anyway key-pair reuse is established practice. Using constant-time
> implementations is essential to making this practice safe, and the
> Security Considerations sections says just that.
> 
> Yoav
> 
> [1]
> http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-key
>