Subject: [IPsec] EdDSA Signatures in IKE

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Apr 2016 16:43:22 -0300

Hi

At the meeting today, I presented the SafeCurves draft status and asked the room whether we wanted to wait for CFRG and Curdle to settle their respective RFCs. The room was unanimously in favor of not having anything in the current draft, instead using RFC 7427 digital signatures. To be certain if we *did* wait, we’d just list the two OIDs from Curdle that we like (the non-prehashed ones).

Quoting from the Curdle draft, they have this:

       id-Curve25519   OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.1 }
       id-Curve448     OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.2 }
       id-Curve25519ph OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.3 }
       id-Curve448ph   OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.4 }

In other news, it turns out that we still have some discussion to go with 4307bis. So I suggest that we add these to table 9 of section 4.2 there as follows:

       +------------------------------------+------------+---------+
       | Description                        | Status     | Comment |
       +------------------------------------+------------+---------+
       | RSASSA-PSS with SHA-256            | SHOULD     |         |
       | ecdsa-with-sha256                  | SHOULD     |         |
       | sha1WithRSAEncryption              | SHOULD NOT |         |
       | dsa-with-sha1                      | SHOULD NOT |         |
       | ecdsa-with-sha1                    | SHOULD NOT |         |
       | RSASSA-PSS with Empty Parameters   | SHOULD NOT |         |
       | RSASSA-PSS with Default Parameters | SHOULD NOT |         |
       | sha256WithRSAEncryption            | MAY        |         |
       | sha384WithRSAEncryption            | MAY        |         |
       | sha512WithRSAEncryption            | MAY        |         |
       | sha512WithRSAEncryption            | MAY        |         |
       | dsa-with-sha256                    | MAY        |         |
       | ecdsa-with-sha384                  | MAY        |         |
       | ecdsa-with-sha512                  | MAY        | ?SHOULD |
       | id-Curve25519                      | MAY        |         |
       | id-Curve448                        | MAY        |         |
       | id-Curve25519ph                    | MUST NOT   |         |
       | id-Curve448ph                      | MUST NOT   |         |
       +------------------------------------+------------+---------+

What do others think?

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Apr 2016 11:09:51 -0300

Replying to myself...

I’ve been told off-list that it didn’t make sense to introduce the hot, new algorithm as a MAY. The only reason I’m suggesting this is that there are currently no implementations to interop with, and no EdDSA certificates where the public keys might come from. My main motivation is to MUST NOT the pre-hashed versions because we don’t need them and again there’s no install base to interop with.

Thinking it over, the new EdDSA signature algorithm defined in the CFRG draft[1] can sign arbitrary-sized messages. We traditionally fed the signature functions hashes of the message because these signature functions only accepted a limited-size input. That is why the “digital signature” document (RFC 7427) has a negotiation and field for hash algorithm. Since we don’t need that with this particular algorithm, I suggest we don’t. IOW I’m suggesting that we allocate a new entry in the “IKEv2 Hash Algorithms” registry called “identity” that will be used only with EdDSA signatures (or any future signature with the same property).

Yoav

[1] See for example https://tools.ietf.org/id/draft-irtf-cfrg-eddsa-05.html#rfc.section.5.1.6

> On 4 Apr 2016, at 4:43 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Apr 2016 11:34:45 -0300

No responses yet...

Tero: What would it take to register an “identity” hash function for use with the EdDSA?

Yoav

> On 5 Apr 2016, at 11:09 AM, Yoav Nir <[email-masked]> wrote:
> 
> Replying to myself...
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Apr 2016 00:12:28 +0300

> Tero: What would it take to register an “identity” hash function for

I assume you mean new value for the RFC7427 Hash Algorithm registry?
That registry is by expert review, but as "identity" is not
necessarely clear enough for the implementors, I would suggest writing
internet-draft doing the allocation, and also explaining how the
"identity" hash function would be used and where it can be used.

That same draft could also point references to the suitable cfrg
document, and recommend not using the ph versions.

I.e., if we could use existing hash and signature algorithms then
there would not be need for document, but if we want to define new
"hash" algorithm, then I think we do need document that specifies
where it can be used and how it is "calculated". And that same
document can then also explain the signature algorithms where it is to
be used, and provide references.
 
> > I’ve been told off-list that it didn’t make sense to introduce the
> > hot, new algorithm as a MAY. The only reason I’m suggesting this
> > is that there are currently no implementations to interop with,
> > and no EdDSA certificates where the public keys might come from.
> > My main motivation is to MUST NOT the pre-hashed versions because
> > we don’t need them and again there’s no install base to interop
> > with.
> > 
> > Thinking it over, the new EdDSA signature algorithm defined in the
> > CFRG draft[1] can sign arbitrary-sized messages. We traditionally
> > fed the signature functions hashes of the message because these
> > signature functions only accepted a limited-size input. That is
> > why the “digital signature” document (RFC 7427) has a negotiation
> > and field for hash algorithm. Since we don’t need that with this
> > particular algorithm, I suggest we don’t. IOW I’m suggesting that
> > we allocate a new entry in the “IKEv2 Hash Algorithms” registry
> > called “identity” that will be used only with EdDSA signatures (or
> > any future signature with the same property).
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 01:29:15 -0300

> On 7 Apr 2016, at 6:12 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:

Like this?
https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 8 Apr 2016 09:30:00 -0300

"Identity" is the formally correct term, but I think "null" is much 
clearer than "identity". Especially in the context of certificates, 
where "identity" can be mistaken for something else.

Thanks,
	Yaron

On 04/08/2016 01:29 AM, Yoav Nir wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 8 Apr 2016 09:57:25 -0300

I also think that "null" is less ambiguous here.

Regards,
Valery.

-----Original Message----- 
From: Yaron Sheffer
Sent: Friday, April 8, 2016 9:30 AM
To: Yoav Nir ; Tero Kivinen
Cc: IPsecME WG
Subject: Re: [IPsec] EdDSA Signatures in IKE

Thanks,
Yaron

---

From: Yoav Nir <[email-masked]>
Date: Fri, 8 Apr 2016 10:11:25 -0300

I can change that. However, “Identity” is the term used in the CFRG draft.

> On 8 Apr 2016, at 9:57 AM, Valery Smyslov <[email-masked]> wrote:
> 
> -----Original Message----- From: Yaron Sheffer

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Apr 2016 17:30:50 +0300

> https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00

Yep.

One nit:

OLD

   To signal within IKE that no hashing needs to be done. A new value
   has to be signalled in the SIGNATURE_HASH_ALGORITHMS notification,
   one that indicates that no hashing is performed.

NEW

   To signal within IKE that no hashing needs to be done, we need a
   new value in the SIGNATURE_HASH_ALGORITHMS notification to signal
   that.

Why only SHOULD NOT for pre-hashed version? Would it not be better to
just say MUST NOT?
-- 
[email-masked]