Subject: [Dcrup] Fwd: Review of: draft-ietf-dcrup-dkim-crypto-07

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jan 2018 00:21:59 -0800

---------- Forwarded message ----------
From: Dave Crocker <[email-masked]>
Date: Sat, Jan 20, 2018 at 9:04 PM
Subject: Review of: draft-ietf-dcrup-dkim-crypto-07
To: "Murray S. Kucherawy" <[email-masked]>, John Levine <
[email-masked]>

(Please redistribute as needed. I'm not subscribed to dcrup. /d)

Review of:    A new cryptographic signature method for DKIM
I-D:          draft-ietf-dcrup-dkim-crypto-07

Reviewed by:  D. Crocker
Review date:  20 Jan 2018

Summary:

The document specifies an additional signing algorithm for DKIM.  The
document is well-organized and generally well-written.  It probably could
be used in its current form, although some minor tweaks have been
suggested, with the intent of adding clarity for a less-experienced reader.

Detail:

Abstract
>
>    DKIM was designed to allow new cryptographic algorithms to be added.
>    This document adds a new signing algorithm.
>

First sentence is superfluous.

I Suggest simply:

     This document adds a new signing algorithm to DKIM.

1.  Introduction
>
>    Discussion Venue:    Discussion about this draft is directed to the
>       [email-masked] [1] mailing list.
>
>    DKIM [RFC6376] signs e-mail messages, by creating hashes of the
>    message headers and body and signing the header hash with a digital
>    signature.  Message recipients fetch the signature verification key
>    from the DNS where it is stored in a TXT record.  The defining
>    documents specify a single signing algorithm, RSA [RFC3447], and
>    recommend key sizes of 1024 to 2048 bits.
>

Given that this is a cursory summary, the "where it is stored in a TXT
record" is an odd and somewhat distracting bit of detail.

   This document adds a new stronger signing algorithm, Edwards-Curve
>    Digital Signature Algorithm using the Curve25519 curve (ed25519),
>    which has much shorter keys than RSA for similar levels of security.
>

3.  Ed25519-SHA256 Signing Algorithm
>
>    The ed25519-sha256 signing algorithm computes a message hash as
>    defined in section 3 of [RFC6376], and signs it with the Hash variant
>    of Ed25519, as defined in in RFC 8032 section 5.1 [RFC8032].  The
>

   as defined in in RFC 8032 section 5.1 [RFC8032].
   ->
   as defined in section 5.1 of [RFC8032].

   signing algorithm is HashEdDSA.  (Even though the input to the

   (Even though the input to the

   ->

   <indented sub-paragraph>

      Even though the input to the...

This seems a significant enough point to warrant some visual highlighting.

   signing algorithm has already been hashed, the PureEdDSA which does
>    not do an additional hash is not widely implemented, and the extra
>    hash causes no problems other than an insignificant slowdown.)  The
>

   an insignificant slowdown.)
   ->
   negligible incremental computational overhead.)

   DNS record for the verification public key MUST have a "k=ed25519"

   The DNS record...
   ->
   <p>
   The DNS record

The sentence switches to a significantly different issue and includes a
normative point, where the previous text had had none. So, again, worth
some visual emphasis.

   tag to indicate that the key is an Ed25519 rather than RSA key.

Stylistically, I'm not fond of using normative terms for what is simply
straight definition.

That is, k= is simply definitional.  The provided k= value defined here
specifies use of the algorithm. (Yes, I know that MUST is popular for such
things. But consider a specification for arithmetic operators and having
the spec say that a "+" MUST be used for addition and a "*" MUST be used
for multiplication, and...  So I suggest simple declarative language rather
than invoking the god of MUST.)

   Note: since Ed25519 keys are 256 bits long, DNS key record data will

A quick scan of RFC 8302 doesn't make it obvious to me which ED25519 key is
meant (public vs. private) and where it says they are 256 bits.  So please
cite the specific section/subsection that is being referenced here.

   generally fit in a single 255 byte TXT string, and will work even
>    with DNS provisioning software that doesn't handle multi-string TXT
>    records.
>
> 4.  Signature and key syntax
>
>    The syntax of DKIM signatures and DKIM keys are updated as follows.
>
> 4.1.  Signature syntax
>
>    The syntax of DKIM algorithm tags in section 3.5 of [RFC6376] is
>    updated by adding this rule to the existing rule for sig-a-tag-k:
>
>        ABNF:
>
>        sig-a-tag-k =/ "ed25519"
>

Strictly speaking, I believe this is meant to modify an existing rule,
rather than add a new one.  So perhaps:

   by adding this rule to the existing rule for sig-a-tag-k:
   ->
   by modifying the rule sig-a-tag-k to add the indicated alternative:

4.2.  Key syntax
>
>    The syntax of DKIM key tags in section 3.6.1 of [RFC6376] is updated
>    by adding this rule to the existing rule for key-k-tag-type:
>
>        ABNF:
>
>        key-k-tag-type  =/ "ed25519"
>

similar comment as above.

5.  Key and algorithm choice and strength
>
>    Section 3.3 of [RFC6376] describes DKIM's hash and signature
>    algorithms.  It is updated as follows:
>

   It is updated as follows:
   ->
   It is updated by adding the following sentence to the first paragraph.

>    Signers SHOULD implement and versifiers MUST implement the
>    ed25519-sha256 algorithm.
>
>
>
>
>
> Levine                    Expires June 4, 2018                  [Page 3]
>
> Internet-Draft             DKIM Crypto Update              December 2017
>
>
> 6.  Transition Considerations
>
>    For backward compatibility, signers MAY add multiple signatures that
>

This appears to be claiming to invent the ability to do multiple
signatures, along with giving permission to use it.  Since that ability
already exists and is permitted anytime, the phrasing and use of MAY is
problematic here.

I believe what is intended is:

   For backward compatibility until support of the new algorithms is
sufficiently widespread, signers might choose to add multiple signatures,
using old and new signing algorithms.

   use old and new signing algorithms.  Since there can only be a single
>    key record in the DNS for each selector, the signatures will have to
>    use different selectors, although they can use the same d= and i=
>    identifiers.
>

Truly trivial nit:  i= is irrelevant to the receiver.

7.  Security Considerations
>
>    Ed25519 is a widely used cryptographic technique, so the security of
>    DKIM signatures using new signing algorithms should be at least as
>    good as those using old algorithms.
>

   using new  ->  using these new

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 21 Jan 2018 12:43:58 -0500

Thanks, this mostly seems reasonable.  Some of the minor copy edits I'd 
rather leave for the editors so they make it match the style book.

One gaping hole we have left to fill is the format for ed25519 keys in DNS 
records.  For RSA keys, everyone uses base64 encoded ASN.1 keys, but at 
this point different libraries use different forms for ed25519.  Since the 
keys are fixed length and fixed format, the extra cruft from ASN.1 is not 
helpful, and it'd require putting an ASN.1 decoder into the dkim library 
if the crypto library it calls doesn't use ASN.1.

Scott K and I have been scratching our heads about this for a while but 
haven't come up with any great inspiration.

R's,
John

On Sat, 20 Jan 2018, Dave Crocker wrote:

> document is well-organized and generally well-written.  It probably could be 
> used in its current form, although some minor tweaks have been suggested, 
> with the intent of adding clarity for a less-experienced reader.
>
>
> Detail:
>
>>  Abstract
>>
> normative point, where the previous text had had none. So, again, worth some 
> visual emphasis.
>
>
> things. But consider a specification for arithmetic operators and having the 
> spec say that a "+" MUST be used for addition and a "*" MUST be used for 
> multiplication, and...  So I suggest simple declarative language rather than 
> invoking the god of MUST.)
>
>
>
> Strictly speaking, I believe this is meant to modify an existing rule, rather 
> than add a new one.  So perhaps:
>
> This appears to be claiming to invent the ability to do multiple signatures, 
> along with giving permission to use it.  Since that ability already exists 
> and is permitted anytime, the phrasing and use of MAY is problematic here.
>

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 21 Jan 2018 18:56:25 +0000

Any reason not to use the base64 of 40 bytes of the key?

On 1/21/18, 12:44 PM, "John R Levine" <[email-masked]> wrote:

    
    
    R's,
    John

    
    Regards,
    
    _______________________________________________
    Dcrup mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dcrup

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Jan 2018 11:39:26 -0800

On 1/21/2018 9:43 AM, John R Levine wrote:

> One gaping hole we have left to fill is the format for ed25519 keys in 
> DNS records.  For RSA keys, everyone uses base64 encoded ASN.1 keys, but 
> at this point different libraries use different forms for ed25519.  
> Since the keys are fixed length and fixed format, the extra cruft from 
> ASN.1 is not helpful, and it'd require putting an ASN.1 decoder into the 
> dkim library if the crypto library it calls doesn't use ASN.1.

On the theory that this bit of convention ought to have applicability 
far beyond DKIM, I suggest formulating a proposal in a separate 
document, starting with text along the above lines, that explains what 
the convention should probably /not/ use, such as ASN.1.

The two goals for the convention would seem to be: 1) ensuring 
text-ness, and 2) compressing if possible.

Easiest would be a summary of the existing different forms you cite as 
already being done and then choosing one you folk think best.  Or 
proffer and alternative with clear, strong arguments for its superiority.

d/

---

From: "John R Levine" <[email-masked]>
Date: 21 Jan 2018 15:47:59 -0500

On Sun, 21 Jan 2018, Dave Crocker wrote:
> On the theory that this bit of convention ought to have applicability far 
> beyond DKIM, I suggest formulating a proposal in a separate document, 
> starting with text along the above lines, that explains what the convention 
> should probably /not/ use, such as ASN.1.

On the principle that we shouldn't solve problems that will likely never 
arise, I'd rather not.  RSA keys use ASN.1 because they do.  At some point 
we will figure out what is the least painful representation for ed25519 
keys, but that will depend on what sort of glue code is needed to adapt a 
key representation to the various libraries.  If we ever add another 
algorithm to DKIM, it'll be another decade from now, and I have no 
confidence that whatever issues seem important now will still be important 
then, or that issues in other applications would be the same as the ones 
we have here.

Over in LAMPS they're doing a crypto update with orders of magnitude more 
algorithms than we'll ever look at.  PKIX is, for historical reasons, all 
ASN.1 all of the time, but those are the people I'd look to if I were 
wondering about key representations.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 21 Jan 2018 16:16:16 -0500

On Sunday, January 21, 2018 03:47:59 PM John R Levine wrote:
> >>  DNS

As far as ASN.1 goes, let's not.  For this application, it's just pointless 
complexity as far as I can tell.

What I'd used so far for the public key representation is base64 of the public 
key that PyNaCl spits out (effectively what libsodium produces).  I think the 
binary output is defined by RFC 80322.  Running it through base64 gives a 
consistent, low-overhead ascii friendly representation.

I see that Section 7.1 of RFC 8032 gives some examples with public and private 
keys in ASCII friendly representations.  Section 7 explains how they did it.  
Let's just use that for public and private key representations.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Jan 2018 21:40:00 -0800

> On the principle that we shouldn't solve problems that will likely never 

The suggestion wasn't about solving future problems but enabling wider 
use by separating this bit of specification into an independent 
document.  That makes it easier to re-use by other applications and 
easier to modify if experience dictates making changes.

> arise, I'd rather not.  RSA keys use ASN.1 because they do.  At some 
> point we will figure out what is the least painful representation for 
> ed25519 keys, but that will depend on what sort of glue code is needed 
> to adapt a key representation to the various libraries. 

I'd think it would mostly depend on the encoding limitations for putting 
this information into the DNS, since that is the task at hand.

>    If we ever add 
> another algorithm to DKIM, it'll be another decade from now, and I have 
> no confidence that whatever issues seem important now will still be 
> important then, or that issues in other applications would be the same 
> as the ones we have here.

My suggestion has nothing to do with adding future algorithms, but 
defining a DNS encoding for this current type of information, for 
possible use by other applications.

> 
> Over in LAMPS they're doing a crypto update with orders of magnitude 
> more algorithms than we'll ever look at.  PKIX is, for historical 
> reasons, all ASN.1 all of the time, but those are the people I'd look to 
> if I were wondering about key representations.

Your sense of the utility of that dependency appears to be different 
from mine...

d/

---

From: "John R. Levine" <[email-masked]>
Date: 22 Jan 2018 11:51:59 -0500

> Let's just use that for public and private key representations.

The test vectors in section 7.1 are printed in hex, not base64.  Since the 
keys are only 32 bytes, the hex is 64 characters and base64 is 44 
characters so they're both pretty small.  We should pick one and move on.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 22 Jan 2018 11:54:15 -0500

On Sun, 21 Jan 2018, Dave Crocker wrote:
>>  key representation to the various libraries. 
>
> I'd think it would mostly depend on the encoding limitations for putting this 
> information into the DNS, since that is the task at hand.

This whole exercise started because RSA keys were getting too big to fit 
into a 255 character text string.  But EC keys are so short that any 
encoding, even one with lots of ASN.1 goop, will fit.  The size limit 
isn't an issue, and I don't know of any other crypto applications where 
squeezing a text version of the key into 255 chaaracters matters.

See the note from Scott about his key experience.  We should pick a hex or 
base64 version of the key, which is very short either way, and be done 
with it.

R's,
John

PS:

> Your sense of the utility of that dependency appears to be different from 
> mine...

No argument there.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Jan 2018 16:55:54 +0000

➢ The test vectors in section 7.1 are printed in hex, not base64.  Since the 
    keys are only 32 bytes, the hex is 64 characters and base64 is 44 
    characters so they're both pretty small.  We should pick one and move on.

Will the author of the draft please pick on and update the draft soon.  If anyone on the WG has good rationale for disagreeing with the author’s choice, think twice and post it.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Jan 2018 17:08:03 +0000

>characters so they're both pretty small.  We should pick one and move

I think either is fine.  I picked base64 originally because I was already using it, but that doesn't really mean anything.  Either has good support in libraries, which is the main thing.

"We picked the format used in the examples in RFC 8932 Section 7" seems like a nice rationale to me.

Let us know what you want to pick?

Scott K

---

From: James Cloos <[email-masked]>
Date: Mon, 22 Jan 2018 12:30:06 -0500

[Replying to a random mail in the thread.]

The optimal way to encode an eddsa public key in dns is raw binary with
either hex, base32 or base64 for the presentation format.

But for dkim, since it is stuck with TXT and already uses base64 for
k=rsa's p=, then base64 of the raw public key is the answer.

In base64 an ed25519 key will take 44 octets.

A records like this:

  v=DKIM1;k=ed25519;p=fjkXkmq6aJiRS2tycuHzHdCYRcA2WWgEs0oh+HoXz2g=

[not a real key] is then just 64 octets of content.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "John R. Levine" <[email-masked]>
Date: 22 Jan 2018 22:50:36 -0500

> Will the author of the draft please pick on and update the draft soon.  If anyone on the WG has good rationale for disagreeing with the author’s choice, think twice and post it.

The people have spoken and seem to have said base64.  Updated draft 
posted, also with style edits per Dave's suggestions.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Tue, 30 Jan 2018 08:14:55 -0500

On 1/22/2018 11:54 AM, John R Levine wrote:
>
> This whole exercise started because RSA keys were getting too big to
> fit into a 255 character text string.  But EC keys are so short that
> any encoding, even one with lots of ASN.1 goop, will fit.  The size
> limit isn't an issue, and I don't know of any other crypto
> applications where squeezing a text version of the key into 255
> chaaracters matters.
>
> ...... We should pick a
> hex or base64 version of the key, which is very short either way, and
> be done with it.

+1.

-- 
HLS