Subject: [Dcrup] Next steps for draft-ietf-dcrup-dkim-crypto

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Nov 2017 11:50:48 +0800

Colleagues,

Consensus in the room at IETF 100 is to have this document settle on doing
"hash EDDSA" only, i.e., dropping support for "rsafp".

If there are any objections to going this way, please speak up on the
list.  If there are none, we'll advise John to proceed with updating the
document based on that call.  We'll proceed to Working Group Last Call when
that happens.

Barry Leiba has volunteered to act as document shepherd.

-MSK, co-chairin'

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Nov 2017 15:19:53 -0500

Hi,

(I don't know what rsafp means, looked at doc for definition, I 
presume it is about SHA1 signing).

Just so I understand, this document will update DKIM STD to where, 
from a product development standpoint:

   - RSA SHA1 is not longer required to be supported at DKIM receivers, so
     do not use or enabled RSA SHA1 for signing.

   - EDDSA support should be added, but you are not REQUIRED to add 
support.
     There will be an unknown migration period.

What is expected to happen when the DKIM receiver does not support EDDSA?

-- 
HLS

On 11/14/2017 10:50 PM, Murray S. Kucherawy wrote:
> Colleagues,
>
> Consensus in the room at IETF 100 is to have this document settle on
> doing "hash EDDSA" only, i.e., dropping support for "rsafp".
>
> list.  If there are none, we'll advise John to proceed with updating
> the document based on that call.  We'll proceed to Working Group Last
> Call when that happens.
>

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 16 Nov 2017 10:35:12 -1000

On Thu, Nov 16, 2017 at 10:19 AM, Hector Santos <[email-masked]> wrote:

> Hi,
>
> (I don't know what rsafp means, looked at doc for definition, I presume it
> is about SHA1 signing).

rsafp is the idea of publishing just the key fingerprint (fp) in DNS with
the full key in the header but validated against the DNS.

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Thu, 16 Nov 2017 21:59:55 +0000

> What is expected to happen when the DKIM receiver does not support EDDSA?

The message won't be considered authenticated by the receiver.

Brandon

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Nov 2017 23:13:54 +0000

>The message won't be considered authenticated by the receiver.

Which is why the smart move operationally would be to double sign rsa-sha256 and EDDSA for some time to come.  This used to be common with rsa-sha1 and rsa-sha256 (in the early days of DKIM).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 18 Nov 2017 11:32:39 -0500

> Which is why the smart move operationally would be to double sign rsa-sha256 and EDDSA for some time to come.  This used to be common with rsa-sha1 and rsa-sha256 (in the early days of DKIM).

I recall seeing them but not as common as you saw it because SHA1 and 
SHA256 were both required hashing methods to select.  The DKIM 
receiver had to support one or the other.  My signing package never 
had a "Hash with Both" option.

Until the tools are available to support EDDSA, i.e. OpenSSL in our 
case, SHA256 would be sufficient to cover all receiver nodes.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 19 Nov 2017 16:58:32 +0000

➢     Until the tools are available to support EDDSA, i.e. OpenSSL in our case,

The current plan is that the next release of OpenSSL will have the necessary API in-place.  This is also the release that will have TLS 1.3, and it’s binary compatible with 1.1.0, so hopefully the uptake will be rapid.

---

From: Hector Santos <[email-masked]>
Date: Tue, 21 Nov 2017 21:48:28 -0500

> The current plan is that the next release of OpenSSL will have the necessary API in-place.  This is also the release that will have TLS 1.3, and it’s binary compatible with 1.1.0, so hopefully the…

1.1.0 is a significant API/layout/build/DLL naming change, hence, we 
could have a longer migration, wait period.

I'll start planning for it.

-- 
HLS