Subject: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Jul 2017 16:53:43 +0200

Having talked to a few others here at IETF 99 I'm abandoning my push
against using MUST NOT with respect to discouraging use of "rsa-sha1".
Scott, you're free to restore that language at your discretion, and I
believe consensus on that other thread supports that decision.  Thanks for
everyone's patience while we worked through that one.

We're going to appoint Seth Blank as the document shepherd for this one.
I'll help him through the process.  Unless there's anything controversial
in here or in the two things on the agenda regarding this document, I
intend to start Working Group Last Call on it after the session on Thursday.

I've reviewed the document (as a participant) and I have the following
additional feedback, in my role as a reviewing participant.

Abstract:
- Remove the last sentence.  It's already there in the header of the
document.

Section 1:
- The discussion venue thing should be marked "[RFC EDITOR: Please remove
before publication.]"  In fact, it's probably a good idea to make that its
own subsection.
- This section should also mention that SHA1 is being deprecated (and give
references explaining why).

Section 3:
- "One algorithms" should be "One algorithm" at least; we could also say
"Two algorithms are defined, but only one is currently supported", and have
a subsection acknowledging that "rsa-sha1" did exist but it is obsolete and
no longer supported.  I would prefer the latter.

Section 3.2:
- There's an errant comma after "DKIM" near the end of the section.
- Should we say verifiers SHOULD NOT verify signatures with keys smaller
than 1024?

Section 4:
- The ABNF should allow "rsa-sha256", not "sha256".

Section 6:
- Errand double period at the end.

Appendix A:
- I would remove the specific draft reference, unless you want this draft
to wait for that one to be published.  Acknowledging John for a lot of
source material separately is at your discretion.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 18 Jul 2017 19:34:49 -0000

It seems likely that we can hash out the few remaining issues on Thursday,
so are we doing one document or two?

R's,
John

In article <CAL0qLwZMJaErTa=[email-masked]> you write:
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 18 Jul 2017 21:47:18 +0000

I think that depends on Thursday.  Unless we manage to stop going in circles over hashed key records I think it should be two.  Let's see where you all get to at the meeting.

Scott K

On July 18, 2017 3:34:49 PM EDT, John Levine <[email-masked]> wrote:
>In article
><CAL0qLwZMJaErTa=[email-masked]>
>you write:
>_______________________________________________
>Dcrup mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dcrup

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 18 Jul 2017 21:55:26 +0000

I would like to see
1. One document that says don't use SHA1 and do use larger RSA key sizes; this exists
2. One document that talks about how to put key identifiers/key digests into DNS records and how to put them in DKIM data
3. One document that says how to use Ed25519 signatures (per the EdDSA RFC) for DKIM data

#1 exists
#2 and #3 also exists as a single document, but I would like to see them split.

Does this make sense?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Jul 2017 06:01:25 +0200

On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich <[email-masked]> wrote:

> 2. One document that talks about how to put key identifiers/key digests
> into DNS records and how to put them in DKIM data

Exactly the vision I have.

-MSK

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 19 Jul 2017 06:40:20 +0200

> Exactly the vision I have.

After hallway discussions earlier in the week, I agree as well with the
trilogy approach.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2017 08:48:49 +0200

I suppose, but three one-page RFCs seem odd. How to use ed25519 is literally two sentences.

Autocorrectly,
John

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 19 Jul 2017 09:47:35 +0200

> I suppose, but three one-page RFCs seem odd. How to use ed25519 is

A significant part of it is to facilitate change tracking for the IANA
registries. That's an insight that I discovered in the hallway
conversations earlier this week.

--Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 19 Jul 2017 07:58:04 +0000

Kurt Andersen:
> A significant part of it is to facilitate change tracking for the IANA registries. That's an insight that I discovered in the hallway conversations earlier this week.

I agree.

I'm not worried about "pushing the edges" of the RFC format.

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2017 10:11:11 +0200

> conversations earlier this week.

Oh, we certainly have to say the two sentences.  The question is whether 
they should be bulked up into a separate document.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Jul 2017 10:31:43 +0200

As for why make this three documents:

>>> 1. One document that says don't use SHA1 and do use larger RSA key
That's ready to go, because there's no change to operation at all in terms
of new code.

>>> 3. One document that says how to use Ed25519 signatures (per the EdDSA
Both of these involve new code that we haven't tried yet at any scale that
I know of.  I would really (repeat several times) like not to drive those
to publication until the "haven't tried yet" goes away.

I don't think we need to hold up the first one while we get at least
trivially comfortable with the other two.

-MSK, participatin'

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2017 10:39:32 +0200

> trivially comfortable with the other two.

Part of my thinks that since we've been deprecating SHA-1 for a decade, 
another month or two until we drive in the final stake isn't going to 
matter, but whatever.

When I get home I'll see about putting the the new stuff into the perl 
library I use.  I gather Scott's already doing stuff to the python one.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Jul 2017 11:21:28 +0200

> library I use.  I gather Scott's already doing stuff to the python one.

I should be able to hack the fingerprinting into OpenDKIM in short order.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 19 Jul 2017 10:41:41 +0000

>library I use.  I gather Scott's already doing stuff to the python one.

I started, but then got overwhelmed with paid work before I produced anything useful.  I will get back to it, but it's not imminent.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 31 Jul 2017 18:27:53 -0400

If I did things right, -03 should be posted.  Except for the 'should be rsa-
sha256' in the ABNF comment, I took a stab at incorporating all of the below 
items.  I didn't address that one because "sha1" / "sha256" / ... is straight 
out of RFC 6376, so I was reluctant to change it without further discussion in 
the group.

Scott K