Subject: Re: [Dcrup] ed25519 in DNS

From: Hector Santos <[email-masked]>
Date: Sun, 01 Apr 2018 21:08:11 -0400

On 3/30/2018 8:05 AM, Salz, Rich wrote:
>   * The toolkit in question is OpenSSL, and this push is an example of
>     the open source community assuming it is the end-all and be-all of
>     all things.
>
> I wasn’t trying to push anything, sorry if it came across that way.
>
> We will have to have a consensus decision on this.  Let’s let the
> discussion run for a few more days.  If you have anything new to
> mention, please speak up.  Otherwise it seems to me that the choice
> will be
>
>                  ASN1/DER wrap the Ed25519 key
>
>                  Just the key without wrapping.
>

My input, overall, DKIM did not have ASN1/DER API implementation 
requirements.  So for a new hash, it could add a higher barrier for 
(immediate) support, even put it on the back burner since in reality 
SHA246 is "good enough."  It wouldn't be "plug and play" anymore, per 
se.

On the other hand, today higher overhead is lesser concern with a 
multi-discipline developer. Using ASN1/DER could probably be useful 
for documentation, support, perhaps DNS folks. Coders probably would 
not care.  It would be more work.

For me, if using a non-ASN1/DER DNS storage is good enough for DKIM, 
then I think it should be kept that way since it would be a simpler 
API plugin with lesser QA concerns.   But if you are forcing more 
coding requirements for ASN1/DER support, it would take more time to 
consider ed25519 support.  That may or may not be a problem.

-- 
HLS

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 8 Apr 2018 18:59:00 +0100

Could we move towards a decision on this point?

My current reading of the preferences expressed is
(apologies if I've misread anyone; please correct me):

Bare key:

 [email-masked]
 [email-masked]
 [email-masked]
 Viktor Dukhovni <[email-masked]>
 [email-masked]   (?)
 [email-masked]
 [email-masked]
 [email-masked]
 [email-masked]

SubjectPublicKeyInfo wrapped key:

 Murray S. Kucherawy <[email-masked]>

Neutral:
 [email-masked]

Unclear:

 [email-masked]
 [email-masked]
 [email-masked]

-- 
Thanks,
  Jeremy

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Apr 2018 12:24:07 -0400

Hi Jeremy, I must admit this is a IETF first for me, to see a WG issue 
position outline per individual.  I suppose it helps.

In any case, I am for the "least DKIM change" position -- a plug and 
play new hash option, with minimum code change.  If that is what "bare 
key" means, then I support it.

My expectation is that when the time comes, I will just take what is 
already being done in our package for DKIM SHA1/SHA256 signing, 
verification and setup, copy and paste the logic code and make the 
OpenSSL crypto functional changes for Ed25519 support.   At the 
frontend, this is where it gets more difficult because the sysops 
options will need to be added, i.e. double signing support (Ed25519 
and SHA256).

side note: if there are customers who believe a previous version of 
OpenSSL is better than the latest (that we will compile and 
distribute),  we will need to add support for a disabled ED25519 
OpenSSL DLL/API, i.e, possible dynamic Linking support required here 
or some stub/wrapper wcEd25519() function.

Thanks

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Apr 2018 17:37:43 +0000

*   We will have to have a consensus decision on this.  Let’s let the discussion run for a few more days.  If you have anything new to mention, please speak up.  Otherwise it seems to me that the choice will be
                ASN1/DER wrap the Ed25519 key
                Just the key without wrapping.

Discussion seems to have died down, and it seems the “raw key” without any wrapping (such as OID/octet-string) is the consensus.  Does anyone *DISAGREE* with that?

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 16 Apr 2018 15:26:40 -0400

> On Apr 16, 2018, at 1:37 PM, Salz, Rich <[email-masked]> wrote:
> 
> We will have to have a consensus decision on this.  Let’s let the discussion run for a few more days.  If you have anything new to mention, please speak up.  Otherwise it seems to me that the choice will be

FWIW, I was relatively neutral at the beginning of this, but I've found the arguments in favor of raw to be more compelling, and more detailed in general, than those in favor of ASN1, etc.

Thanks,
Stan

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Apr 2018 16:27:03 -0700

On Sun, Apr 8, 2018 at 10:59 AM, Jeremy Harris <[email-masked]> wrote:

> [...]

This isn't really how we figure out whether all raised issues have been
addressed.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2018 19:48:10 -0400

>>                 Just the key without wrapping.

As soon as someone can send me a sample signed message to splice into
the draft, I think it'll really be done.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Apr 2018 01:07:24 +0000

On Mon, Apr 16, 2018 at 10:37 AM, Salz, Rich <[email-masked]> wrote:

>
>    - We will have to have a consensus decision on this.  Let’s let the
>    discussion run for a few more days.  If you have anything new to mention,
>    please speak up.  Otherwise it seems to me that the choice will be
>
> Discussion seems to have died down, and it seems the “raw key” without any
> wrapping (such as OID/octet-string) is the consensus.  Does anyone *
> *DISAGREE** with that?
>

I don't have any objection to declaring the consensus that way at this
point.  Thanks to everyone who participated in the discussion -- which I'm
glad we have on the record in case the IESG or a Last Call reviewer asks
about this point -- and, for the most part, keeping it civil.

Barry (who has volunteered to shepherd), please begin your write-up work at
your convenience.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Apr 2018 01:19:06 +0000

On April 19, 2018 11:48:10 PM UTC, John Levine <[email-masked]> wrote:
>In article
><[email-masked]> you
>write:

IIRC, at [1], 	rfc6376.signed.msg	 and	rfc8032_7_1.key have what you need.

Scott K

[1] https://git.launchpad.net/dkimpy/tree/dkim/tests/data

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Apr 2018 01:24:17 +0000

>IIRC, at [1], 	rfc6376.signed.msg	 and	rfc8032_7_1.key have what you

I forgot to mention that the private key is base64 encoded binary key from RFC 8032 7.1, the first example.