Subject: [DNSOP] WGLC on draft-ietf-curdle-dnskey-eddsa-01

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Nov 2016 23:55:10 -0400

Hi,

This message starts a Working Group Last Call (WGLC) for
draft-ietf-curdle-dnskey-eddsa-01.

The version to be reviewed is
https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01

Please send your comments, questions, and edit proposals to the WG mail
list until November 16th, 2016.  If you believe that the document is ready
to be submitted to the IESG for consideration as a Standards Track RFC
please send a short message stating this.

Yours,

Rich and Daniel

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Nov 2016 15:10:04 +1100

> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01

Does this use Ed25519 or Ed25519ctx?  It describes a context string,
which Ed25519 throws away.

---

From: Dan York <[email-masked]>
Date: Thu, 3 Nov 2016 09:36:42 +0000

Daniel,

On Nov 2, 2016, at 11:55 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.
>From a DNS perspective I support the draft as it seems very much in line with other similar drafts and RFCs specifying DNSSEC algorithms. I believe this adds useful capabilities to DNSSEC and should proceed.

That said, I will need to defer to others to confirm the details of the EdDSA usage as I do not have experience with those crypto algorithms.

One minor editorial nit. In section 4 there are multiple references to the "Chapter" of another draft. Example:
----

The Ed25519 signature algorithm is described in Chapter
   5.1.6 in [I-D.irtf-cfrg-eddsa<https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01#ref-I-D.irtf-cfrg-eddsa>].

----

In US English a "chapter" is typically reserved for a "book". I think the better term here might be "Section", but I don't know if there is specific guidance anywhere on what to call areas of another I-D.

Thank you to the authors for moving this forward.

Dan

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 3 Nov 2016 16:45:54 +0100 (CET)

Dear all,

I have incorporated the comments from Simon changing
Security Considerations and removing the Section about
Implementations.

I have also clarified usage of context.  The context label
is used only for Ed448.

I have also updated the example for Ed25519, but I would
really appreciate if somebody could review the script
used to generate the examples: 

https://gitlab.labs.nic.cz/labs/ietf/blob/master/dnskey.py

The updated drafts can't be uploaded, but I uploaded the
last version to our gitlab:

XML: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnskey-eddsa.xml
TXT: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnskey-eddsa.txt
HTML: https://gitlab.labs.nic.cz/labs/ietf/raw/master/draft-ietf-curdle-dnskey-eddsa.html

O.
--
 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: "Daniel Migault" <[email-masked]>
> To: "curdle" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Thursday, 3 November, 2016 04:55:10
> Subject: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

> Hi,
> 
> This message starts a Working Group Last Call ( WGLC ) for
> The version to be reviewed is [
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 |
> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01 ]
> 
> Please send your comments, questions, and edit proposals to the WG mail list
> until November 16th, 2016. If you believe that the document is ready to be
> submitted to the IESG for consideration as a Standards Track RFC please send a
> short message stating this.
> 
> Yours,
> 
> Rich and Daniel
> 
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 Nov 2016 22:01:38 +0100

> https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-01

Hello again.  Since my last review of -01, I have re-read the document
again, and noticed the text regarding signature contexts.  I believe the
use of contexts is in general ill-advised, and its presence in the
document highlights a need for a security consideration to address the
problem that context attempts to mitigate but does not succeed with:
don't re-use private keys for other purposes.  If this best practice
advice is followed, contexts is unwanted complexity instead of something
good.  If a private key is used for other purposes, contexts won't save
you -- DJB explained this on the CFRG list some time ago in a way that
convinced me.

Thus, allow me to suggest that

1) The draft is modified to not use signature contexts.

2) The security consideration has a new paragraph that reads:

   A private key used for a DNSSEC zone MUST NOT be used for any other
   purpose than for that zone.  Otherwise cross-protocol or
   cross-application attacks are possible.

Perhaps this text is better suited in the Introduction section, but it
bears repeating in the security consideration anyway.

/Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Nov 2016 22:11:06 +0000

I think the issue about signature  contexts first, and mainly, came up with TLS which generates a variety of private key material based on shared secret info, and the concern that those different keys could be used for  cross-protocol attacks.

But I could be wrong. :)

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Nov 2016 19:31:02 -0400

This is also my understanding. but I might be wrong as well.

Yours,
Daniel

On Thu, Nov 3, 2016 at 6:11 PM, Salz, Rich <[email-masked]> wrote:

> I think the issue about signature  contexts first, and mainly, came up
> with TLS which generates a variety of private key material based on shared
> secret info, and the concern that those different keys could be used for
> cross-protocol attacks.
>
> But I could be wrong. :)
>
> --
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Nov 2016 12:03:17 +1100

> I think the issue about signature  contexts first, and mainly, came up with TLS which generates a variety of private key material based on shared secret info, and the concern that those different k…

There are a lot of ways that keys (particularly those in certificates)
might be used.  Context strings reduce the chances that those keys are
misused such that data from one context can be transplanted into
another.

Simon's proposal works better in this context.  If only all keys were
so single-minded.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 4 Nov 2016 11:45:14 +0100 (CET)

Simon,

thanks for all the comments, I have now culled all the context usage from the
draft and the git version should be up to date and ready for -2 upload.

Cheers,
Ondrej

----- Original Message -----
> From: "Simon Josefsson" <[email-masked]>
> To: "Daniel Migault" <[email-masked]>
> Cc: "curdle" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Thursday, 3 November, 2016 22:01:38
> Subject: Re: [Curdle] WGLC on draft-ietf-curdle-dnskey-eddsa-01

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 4 Nov 2016 12:59:22 +0100 (CET)

And now the examples section contains Ed448 examples as well
generated using eddsa2.py from [CFRG-EDDSA] draft.

I think now the draft is as good as it gets.  Thanks all for
providing guidance.

O.

----- Original Message -----
> From: "Ondřej Surý" <[email-masked]>
> To: "Simon Josefsson" <[email-masked]>
> Cc: "Daniel Migault" <[email-masked]>, "curdle" <[email-masked]>, "dnsop" <[email-masked]>
> Sent: Friday, 4 November, 2016 11:45:14

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Nov 2016 21:00:29 -0400

Thanks for the update.

I think that woudl be helpful to have some text that provides some rational
for using Ed25519 versus Ed25519ph and Ed25519ctx as well as Ed448 versus
Ed448ph. I belive that is collision resilience as well as offline signing
in which case double path does not really matter.

Yours,
Daniel

On Fri, Nov 4, 2016 at 7:59 AM, Ondřej Surý <[email-masked]> wrote:

> > Cc: "Daniel Migault" <[email-masked]>, "curdle" <
> [email-masked]>, "dnsop" <[email-masked]>