Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-crypto-09

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2018 13:10:06 -0400

On 5/29/2018 12:16 PM, Alexey Melnikov wrote:
> On Tue, May 29, 2018, at 4:57 PM, John Levine wrote:
>> In article
>> <[email-masked]> you
>> write:
>>> This is a short document, so I've started IETF LC on it.
>>>
>>> I have some nits though:
>>>
>>> Abstract
>>>
>>>    This document adds a new signing algorithm to DKIM.
>>>
>>> This is a bit short, as it doesn't give a reader enough details to decide whether or not to read further. Please mention the added algorithm!
>>
>> How about this:
>>
>>     This document adds a new signing algorithm, ed25519-sha256, to DKIM.
>>     DKIM verifiers are required to implemenent this algorithm.
>>
>> Other nits are fine, will fix them once we agree on the abstract.
>
> Yes, I think this is perfect!

I believe I understand what the author is intending here, but DKIM 
verifiers are not required to implement this new algorithm which 
requires unnecessary code change, not to mention more overhead 
(migration double signing necessary/required).

Current compliant DKIM verifiers can choose to just to stick with 
SHA256 and still be compliant.   Not implementing this new method 
SHOULD NOT disqualify a perfectly valid DKIM verifier as a 
legitimately secured DKIM signer (and verifier) using just SHA256.

Instead, maybe the abstract should explain why it should be 
implemented.  Is there something wrong with SHA256?  etc.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jun 2018 17:14:39 +0000

Hector,

You have objected multiple times.  Nobody else in the WG shares your views.

Speaking as co-chair,
	/r$

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Jun 2018 14:18:30 -0400

How do you conclude no one else in this WG shares my views?  In this 
particular view regarding a last minute LC critical change?

Perhaps, within the IETF WGs, critical changes should be done with 
more time to consider it, not made in the last minute LC.

For the record, I'm objecting to a last minute LC draft abstract 
change that requires all DKIM verifiers to implement this hashing 
method when it is redundant in terms of security, i.e. nothing wrong 
with the current standard SHA256. It instantly makes all verifiers 
non-DKIM compliant with the updated STD which in fact, you don't know 
if all implementators are able to do it anytime soon, if ever.

Thanks

On 6/6/2018 1:14 PM, Salz, Rich wrote:
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>
>

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jun 2018 20:51:46 +0000

Please be explicit about which draft and which change you dislike.  The latest says Ed25516 with SHA256.  It adds a new signing mechanism.

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 6 Jun 2018 17:58:04 -0400

On Jun 6, 2018, at 4:51 PM, Salz, Rich <rsalz=[email-masked]> wrote:

>> How do you conclude no one else in this WG shares my views?  In this particular view regarding a last minute LC critical change?
> 

The same poster made the same objection in February, so what is cited isn't a late change, unless we're now going to embark on a debate of the vagaries of "required to implement" vs. "MUST implement":

https://www.ietf.org/mail-archive/web/dcrup/current/msg00764.html

Stan

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jun 2018 22:20:46 +0000

So Hector, is the message Stan referenced what you are objecting to?

Standards evolve.

I repeat my question:

  *   The same poster made the same objection in February, so what is cited isn't a late change, unless we're now going to embark on a debate of the vagaries of "required to implement" vs. "MUST implement":

  *   https://www.ietf.org/mail-archive/web/dcrup/current/msg00764.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mail-2Darchive_web_dcrup_current_msg00764.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=okCdV6SDQ6gukRFmty8bS-muc-kubR6lk3p_zgMOvAY&s=4ik17UWa14kVCD7sNUj3EVln0qY_Z2wWzvfDgMUihcY&e=>

If so, it was (a) not last-minute; and (b) really an editorial change.

I still maintain you’re in the rough here, and the WG has consensus around this draft.  Please provide more information, and details, to show that I am wrong.

                /r$

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 6 Jun 2018 23:32:18 +0100

On 06/06/2018 07:18 PM, Hector Santos wrote:
> For the record, I'm objecting to a last minute LC draft abstract change
> that requires all DKIM verifiers to implement this hashing method

I'd assume that DKIM verifiers not claiming to implement the RFC this
document becomes are not bound by it.

Perhaps the wording could be modified to not make the inference
possible?
-- 
Jeremy

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jun 2018 23:16:09 +0000

possible?

Why?  What other RFC's do this?

---

From: denis bider <[email-masked]>
Date: Wed, 6 Jun 2018 19:25:31 -0500

This seems to me a strong argument that the change is an editorial one, and
that the substance is not new.

Hector, my understanding is that a principal reason for Ed25519 is so that
signers can use a strong algorithm when they would otherwise need to use
short RSA keys (e.g. 1024-bit). These are signers that are restricted to
using DNS middleware which prevents them from publishing a 2048-bit RSA key
due to size restrictions. They can however publish an Ed25519 key.

If verifiers are not required to support Ed25519, this thwarts a principal
reason to have it in the first place.

On Wed, Jun 6, 2018 at 5:20 PM, Salz, Rich <
rsalz=[email-masked]> wrote:

> Please be explicit about which draft and which change you dislike.  The
> latest says Ed25516 with SHA256.  It adds a new signing mechanism.
>
>
>
>
>
>    - The same poster made the same objection in February, so what is
>    cited isn't a late change, unless we're now going to embark on a debate of
>    the vagaries of "required to implement" vs. "MUST implement":
>
>
>
>    - https://www.ietf.org/mail-archive/web/dcrup/current/msg00764.html
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mail-2Darchive_web_dcrup_current_msg00764.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=okCdV6SDQ6gukRFmty8bS-muc-kubR6lk3p_zgMOvAY&s=4ik17UWa14kVCD7sNUj3EVln0qY_Z2wWzvfDgMUihcY&e=>
>
>
>
>
> I still maintain you’re in the rough here, and the WG has consensus around
> this draft.  Please provide more information, and details, to show that I
> am wrong.
>
>
>
>                 /r$
>
>
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2018 09:39:22 +0200

I, for one, *do* support an editorial change here, primarily because I
don't like having a normative requirement appear only in the abstract.
I think no change to the abstract is necessary, but I would like to
see the following change in Section 3:

OLD
   This is an additional DKIM signature algorithm added to Section 3.3
   of [RFC6376] as envisioned in Section 3.3.4 of [RFC6376].

NEW
   This is an additional DKIM signature algorithm added to Section 3.3
   of [RFC6376] as envisioned in Section 3.3.4 of [RFC6376].  DKIM
   verifiers are REQUIRED to implement this algorithm so that they
   can interoperate with signers that use it.

END

Barry

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2018 11:26:02 +0200

>document becomes are not bound by it.

Standards track RFCs give advice on how to build systems that
interoperate.  We are not the Protocol Police, if you don't want to do
what they say, you don't have to.  Your system probably won't
interoperate as well, but that's your choice.

I agree that there is nothing new here.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2018 11:30:02 +0200

>don't like having a normative requirement appear only in the abstract.

It's in section 5:

5.  Key and algorithm choice and strength

   Section 3.3 of [RFC6376] describes DKIM's hash and signature
   algorithms.  It is updated as follows:

   Signers SHOULD implement and verifiers MUST implement the
   ed25519-sha256 algorithm.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2018 11:32:50 +0200

Ha, I missed that; thanks.

Barry

On Thu, Jun 7, 2018 at 11:30 AM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2018 12:38:58 -0400

Thanks for your input Barry.

I personally believe its more of a technical sales abstract that I was 
thinking will help. The normative language was already in the draft, 
not required for the abstract and I don't think it generally done that 
way, but maybe this is the trend.  It could scare potential 
implementators when they just read the published abstract with no 
details. "Oh, I have to do this?  I don't think I will worry about 
that for now."  Denis had some good input with some "tech sales" 
points.

That said, I remove my objection to the abstract change.

Thanks

--
HLS