Subject: [Curdle] Call for Adoption

From: Daniel Migault <[email-masked]>
Date: Tue, 12 Jan 2016 19:58:46 +0000

Hi,

We wish you a happy new year 2016, and start the year with a call for adoption of the following drafts. Please indicate whether you support or not the adoption of these drafts by January 19.

If adoption of the curves and EdDSA seems quite complete, another part of the WG milestones concerns deprecation and recommendations for cryptographic algorithm. Feel free to share by January 19 which protocols you would like to see addressed (PKIX, DNS, ...) or submit a draft by January 26.

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02

https://tools.ietf.org/html/draft-josefsson-ssh-curves-00

https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03

https://tools.ietf.org/html/draft-sury-dnskey-ed448-00

https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

 Daniel and Rich

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 12 Jan 2016 15:26:59 -0500

Hi,

> https://tools.ietf.org/html/draft-sury-dnskey-ed448-00

I support adoption of these two documents by the working group, and can
commit to reviewing them.  (Well, at least the DNS protocol parts.)

By the way, as far as implementation status goes, I know of one
DNS implementation that has started working on Ed25519 support:

    http://blog.powerdns.com/2015/12/24/technical-preview-releases-of-authoritative-server-recursor-and-dnsdist/

    "Experimental ed25519 signing support based on
    draft-sury-dnskey-ed25519-03."

-- 
Robert Edmonds

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 12 Jan 2016 21:36:34 +0100 (CET)

+1 from me as the second co-author on my drafts.  We will probably submit updated drafts before January 26 anyway, the update is slowly finding its way to the top of my TODO list.

Cheers,
Ondrej

--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "Robert Edmonds" <[email-masked]>
> To: "Daniel Migault" <[email-masked]>
> Cc: "Ondřej Surý" <[email-masked]>, [email-masked], [email-masked]
> Sent: Tuesday, January 12, 2016 9:26:59 PM
> Subject: Re: [Curdle] Call for Adoption

> Daniel Migault wrote:
>> Hi,
>> 
>> We wish you a happy new year 2016, and start the year with a call for adoption
>> of the following drafts. Please indicate whether you support or not the
>> adoption of these drafts by January 19.
>> 
>> 
>> 
>> If adoption of the curves and EdDSA seems quite complete, another part of the WG
>> milestones concerns deprecation and recommendations for cryptographic
>> algorithm. Feel free to share by January 19 which protocols you would like to
>> see addressed (PKIX, DNS, ...) or submit a draft by January 26.
> 
> Hi,
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jan 2016 23:44:50 +0200

> https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02

Support.

(Some obsolete refs, maybe also merge Ed448 if it makes out
fast enough).

> https://tools.ietf.org/html/draft-josefsson-ssh-curves-00

Support.

(looks like one paragraph assumes keys are 32 octets, where those
might also be 56).

> https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03

Support.

> https://tools.ietf.org/html/draft-sury-dnskey-ed448-00

Why is this separate from Ed25519 draft? Due to CFRG draft stuff?

Expected to merge with Ed25519 draft later if CFRG-EDDSA makes
out?

Anyway: I think this should be done one way or another.

> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

I don't think mixing ECDH and signature keys is a good idea. However,
this approach would be good for ECDH keys, which I do have heard
requests for.

That is, drop PH and add SHOULD for using the ECDH algorithm.

> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

Support.

-Ilari

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 13 Jan 2016 10:17:00 +0100 (CET)

Hi Ilari,

> Why is this separate from Ed25519 draft?

The benefit of Ed448 for DNSSEC is doubtful, thus we wanted to separate the two drafts so we can drop Ed448 if the DNS folks come to consensus that it's not needed at all.

Also we thought that adding Ed25519 to DNSSEC won't raise any objections so it might be just faster to split it into separate document so we can fast forward this into the RFC.  As opposed to Ed448 where we might have a lengthy discussion.

> Due to CFRG draft stuff?

We expect to merge if there's a strong support for Ed448 in DNSSEC.

> Anyway: I think this should be done one way or another.

I am fine with merging if it won't stall Ed25519 progress.

Cheers,

---

From: Rob Stradling <[email-masked]>
Date: Wed, 13 Jan 2016 14:38:39 +0000

On 12/01/16 19:58, Daniel Migault wrote:
> Hi,
>
> We wish you a happy new year 2016, and start the year with a call for
> adoption of the following drafts. Please indicate whether you support or
> not the adoption of these drafts by January 19.
<snip>
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

I support adoption of these two drafts.

ISTM that it might make sense to combine them into one document; or, for 
simplicity's sake, it might make sense to only standardize one of the 
two approaches [1].  But let's adopt, then discuss.

[1] https://www.ietf.org/mail-archive/web/pkix/current/msg33401.html

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 13 Jan 2016 07:39:41 -0800

Hi,

Over on the [email-masked] list, Stephen Farrell suggested that I
see if I could add

  https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2 

under the curdle charter. 

The draft deprecates a Secure Shell (SSH) key exchange algorithm
(Diffie-Hellman group1 - a 768-bit MODP group) and recommends
replacement with stronger Diffie-Hellman MODP groups (groups 14, 15,
16).

The draft does have two interoperable implementations that have
implemented it.

Does it fit well enough into the curdle charter to be added here?

	Thank you,
	-- Mark

 ------- forwarded message -------
From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jan 2016 10:34:05 +0000
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

Hiya,

On 13/01/16 09:21, Mark D. Baushke wrote:
> Hi,
> 
> URL: https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2
> 
> I believe that OpenSSH and Dropbear SSH have both implemented interoperable
> versions using the current 01 version at this point in time.
> 
> I would be interested in hearing if any other implementations have
> adopted these new DH groups.
> 
> Are there any additional comments or changes needed for the draft before
> we can move to the next step in the process?
> 
> Hmmm... What is next? Getting 'AD is watching' or is it getting a
> document shepherd?

There's no active SSH WG, but there is the curdle WG. Its
charter [1] however is limited in terms of what it's
allowed to add to protocols. OTOH, this is not defining any
new groups, just updating codepoints, including deprecating
one (to NOT RECOMMENDED). So the draft could fit there on
that basis I guess. So I'd say send a mail to the curdle
list and suggest this be adopted there.

If that doesn't work I can look at AD sponsoring it, but
since one of the reasons to setup curdle was to avoid too
many of these being AD sponsored, please try there first.

Cheers,
S.

[1] https://tools.ietf.org/wg/curdle

> 	Thank you,
> 	-- Mark

---

From: Daniel Migault <[email-masked]>
Date: Wed, 13 Jan 2016 16:31:39 +0000

Hi,
 
 Thanks for the suggestion. I think it falls into the scope of the WG.
 
 The question I would have is whether it would make sense to extend the 
 document to the crypto suites others than DH - i.e. encryption mac.  
 This would result in a document providing cryptographic 
 recommendations for SSH and have this document regularly updated as 
 crypto evolves. Any opinion ?
 
 BR,
 Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 13, 2016 10:40 AM
To: Curdle Chairs
Cc: Curdle; [email-masked]
Subject: Re: [Curdle] Call for Adoption 

Hi,

Over on the [email-masked] list, Stephen Farrell suggested that I see if I could add

The draft deprecates a Secure Shell (SSH) key exchange algorithm (Diffie-Hellman group1 - a 768-bit MODP group) and recommends replacement with stronger Diffie-Hellman MODP groups (groups 14, 15, 16).

The draft does have two interoperable implementations that have implemented it.

	Thank you,
	-- Mark

 ------- forwarded message -------
From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Jan 2016 10:34:05 +0000
Subject: Re: draft-baushke-ssh-dh-group-sha2-01 (was Re: DH group exchange)

Hiya,

On 13/01/16 09:21, Mark D. Baushke wrote:
> I believe that OpenSSH and Dropbear SSH have both implemented 
> interoperable versions using the current 01 version at this point in time.
> 
> Are there any additional comments or changes needed for the draft 
> before we can move to the next step in the process?
> 

There's no active SSH WG, but there is the curdle WG. Its charter [1] however is limited in terms of what it's allowed to add to protocols. OTOH, this is not defining any new groups, just updating codepoints, including deprecating one (to NOT RECOMMENDED). So the draft could fit there on that basis I guess. So I'd say send a mail to the curdle list and suggest this be adopted there.

If that doesn't work I can look at AD sponsoring it, but since one of the reasons to setup curdle was to avoid too many of these being AD sponsored, please try there first.

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 13 Jan 2016 08:40:29 -0800

>  crypto evolves. Any opinion ?

I'd prefer to prioritize the already deployed Curve25519 and Ed25519
work over crypto recommendations which other groups can develop. We
also should consider [email-masked] to be added as this addresses
a corner case in the spec which makes AEAD complex.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 13 Jan 2016 08:50:01 -0800

>  Thanks for the suggestion. I think it falls into the scope of the WG.

Thank you.

>  document to the crypto suites others than DH - i.e. encryption mac.  

I am not sure if this is the best course.

There are other SSH drafts also in draft by other authors

  https://datatracker.ietf.org/doc/draft-ssh-ext-info
  https://datatracker.ietf.org/doc/draft-rsa-dsa-sha2-256
  https://datatracker.ietf.org/doc/draft-bjh21-ssh-ed25519

which are working in this area of SSH already.

>  crypto evolves. Any opinion ?

Coming up with RFC 4250bis, RFC 4242bis, RFC 4253bis, and RFC 4254bis
would be a lot of work and keeping them regularly updated would be
non-trivial.

I am open to suggestions for additions or changes to
https://datatracker.ietf.org/doc/draft-baushke-ssh-dh-group-sha2 
as long as the ietf-SSH group wants that to happen.

Does any one else have any opinions on this topic?

	-- Mark

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Jan 2016 16:26:50 +0100 (CET)

Dear chairs and wg members

>> https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03

as I didn't heard any objections to this, I have update the draft to use Ed25519ph variant and submitted the I-D as WG draft.

I have to yet hear what we should do with DNSKEY Ed448:

a) drop it as there's no real benefit (DNSSEC signatures are usually short-lived)
b) proceed with independent draft
c) merge it into draft-curdle-dnskey-ed25519

I am slightly inclined to do c) just for the sake of consistency between different protocols, and because people are going to constantly ask why we haven't done Ed448.  But I would like to hear other opinions.

Cheers,

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Jan 2016 17:23:27 +0100

I suggest dropping ed448 for dnssec. The reason for me is purely dnssec-based. For dnssec we've seen significant issues deploying new algorithms, e.g. cloudflare's use of ecdsa still triggers bugs.  There is probably only one ed448 implementation following the latest spec, and it will take time to get others to materialize so people are likely to not implement ed25519 and ed448 at the same time.  There is also the desire for short signatures.

We can always publish it later.

BTW, why ed25519ph? Why not ed25519? There are many implementations around for ed25519.

/Simon

"Ondřej Surý" <[email-masked]> skrev: (27 januari 2016 16:26:50 CET)
>as I didn't heard any objections to this, I have update the draft to
>use Ed25519ph variant and submitted the I-D as WG draft.
>
>I am slightly inclined to do c) just for the sake of consistency
>between different protocols, and because people are going to constantly
>ask why we haven't done Ed448.  But I would like to hear other
>opinions.
>
>Cheers,
>--

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Jan 2016 17:03:57 +0000

Hi,

Personally, I would favor c). I am not so much convinced that having two cipher suites in a document would slow their respective deployments. Implementations may still chose to implement only one of the two cipher suites. Of course I am happy to hear other opinions.

BR,
Daniel

From: Simon Josefsson [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 11:23 AM
To: Ondřej Surý; [email-masked]; curdle-chairs
Cc: Robert Edmonds
Subject: Re: [Curdle] Call for Adoption

/Simon
"Ondřej Surý" <[email-masked]<mailto:[email-masked]>> skrev: (27 januari 2016 16:26:50 CET)

 Support.

I am slightly inclined to do c) just for the sake of consistency between different protocols, and because people are goin!

 g to

constantly ask why we haven't done Ed448.  But I would like to hear other opinions.

Cheers,

________________________________

________________________________

________________________________

Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Jan 2016 17:06:34 +0000

And just to prove that we’re not monolithic ☺  I would prefer to drop them.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: Daniel Migault [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 12:04 PM
To: Simon Josefsson; Ondřej Surý; [email-masked]; curdle-chairs
Cc: Robert Edmonds
Subject: RE: [Curdle] Call for Adoption

Hi,

BR,
Daniel

From: Simon Josefsson [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 11:23 AM
To: Ondřej Surý; [email-masked]<mailto:[email-masked]>; curdle-chairs
Cc: Robert Edmonds
Subject: Re: [Curdle] Call for Adoption

/Simon

 https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsury-2Ddnskey-2Ded25519-2D03&d=CwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=wxTBjOgBiv-OJVjptSDB6DrlNaxDJOFqdfHATNLjyLA&s=uxyF1loIlMDsdkoyQLd_cQSNlkpA2YIxss1byvMOC5c&e=>

 Support.

 g to

Cheers,

 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz<https://urldefense.proofpoint.com/v2/url?u=https-3A__nic.cz&d=CwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=wxTBjOgBiv-OJVjptSDB6DrlNaxDJOFqdfHATNLjyLA&s=Fr4yI1pjztoCdnSBXk9fhiQSp3ljcd7s8Hw2a3BpnWk&e=>/

Curdle mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/curdle<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_curdle&d=CwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=wxTBjOgBiv-OJVjptSDB6DrlNaxDJOFqdfHATNLjyLA&s=mL-mm7wNUfEY-B-zj3qbL14F_mI4HVWENwNfX_7XvM8&e=>

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 27 Jan 2016 18:17:44 +0100

No strong reason for ph, apart from the fact we already had SHA-512 in the draft, so it seemed a logical choice. I am all ears for recommendations here... 

CZ.NIC 

On 27 Jan 2016 17:24, at 17:24, Simon Josefsson <[email-masked]> wrote:
>I suggest dropping ed448 for dnssec. The reason for me is purely
>dnssec-based. For dnssec we've seen significant issues deploying new
>algorithms, e.g. cloudflare's use of ecdsa still triggers bugs.  There
>is probably only one ed448 implementation following the latest spec,
>and it will take time to get others to materialize so people are likely
>to not implement ed25519 and ed448 at the same time.  There is also the
>desire for short signatures.
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 Jan 2016 18:37:23 +0100

Are there any implementations? You get worse security properties with the ph-variant. So unless there is a legacy reason (api) my recommendation is to go with the non-ph variant. It uses sha512 too if that makes you happier :)

/Simon

"Ondřej Surý" <[email-masked]> skrev: (27 januari 2016 18:17:44 CET)
>No strong reason for ph, apart from the fact we already had SHA-512 in
>the draft, so it seemed a logical choice. I am all ears for
>recommendations here... 
>
>--

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 27 Jan 2016 19:48:36 +0200

On Wed, Jan 27, 2016 at 06:17:44PM +0100, Ondřej Surý wrote:
> No strong reason for ph, apart from the fact we already had SHA-512
> in the draft, so it seemed a logical choice. I am all ears for
> recommendations here... 

My advice about Ed25519ph: Don't use, it is there only due to bad
legacy APIs.

Ed25519 can easily sign few kB of highly temporally local data as-is.

(Same for Ed448... one implementation I have even does scatter-
gather signing/verification).

(and if some application call for very high amounts of data to sign
or poor temporal localization, build the required mechanisms at
protocol level, since otherwise you will cause severe problems for
the verifier).

Also, the prehash with SHA-512 greatly weakens Ed25519ph. For similar
reasons as original RSA-PSS proposal with MD5 hash is still a mighty
challenge, while the standarized RSA-PSS with MD5 is easy pickings.

-Ilari

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 28 Jan 2016 09:37:57 +0100 (CET)

Simon, could you get this and possibly other's comments on Ed25519ph variant into Chapter 4 of irtr-cfrg-eddsa?

Note about Ed25519ph being weeker should deserve a sentence or two in Security Considerations as well.

And now I am going to rewrite my draft to use Pure variant.

Cheers,
Ondrej

----- Original Message -----
> Sent: Wednesday, January 27, 2016 6:37:23 PM

> Are there any implementations? You get worse security properties with the
> ph-variant. So unless there is a legacy reason (api) my recommendation is to go
> with the non-ph variant. It uses sha512 too if that makes you happier :)
> 
> /Simon
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 28 Jan 2016 10:06:31 +0100

Agreed -- given this discussion, I think a "guide to chosing EdDSA
variant" is warranted.  The disadvantage with lumping these variants
together is that people may chose the wrong variant, or be overwhelmed
by options and walk away.

In my mind, Ed25519 is what everyone should opt for first.  If the
protocol is built around hashing data before signing, such as OpenPGP,
then an Ed25519ph-like approach is natural, but otherwise it shouldn't
be used.  Ed448 is unproven, and the new domain-separation schema makes
it rather unattractive from a peer-review and implementers point of
view in the next 3-5 years, in my opinion, so I don't currently see why
anyone would want to use it.

/Simon

> Simon, could you get this and possibly other's comments on Ed25519ph
> variant into Chapter 4 of irtr-cfrg-eddsa?
> 
> > Are there any implementations? You get worse security properties
> > with the ph-variant. So unless there is a legacy reason (api) my
> > recommendation is to go with the non-ph variant. It uses sha512 too
> > if that makes you happier :)
> > 
> > /Simon
> > 
> >>>dnssec-based. For dnssec we've seen significant issues deploying
> >>>new algorithms, e.g. cloudflare's use of ecdsa still triggers
> >>>bugs.  There is probably only one ed448 implementation following
> >>>the latest spec, and it will take time to get others to
> >>>materialize so people are
> >>likely
> >>>>as I didn't heard any objections to this, I have update the draft
> >>>>to use Ed25519ph variant and submitted the I-D as WG draft.
> >>>>