Subject: [dmarc-ietf] "Missed it by *that* much". . .

From: Kurt Andersen <[email-masked]>
Date: Wed, 15 Mar 2017 16:18:11 -0700

I discovered today as I attempted to submit the ARC protocol update that
I've been working on, that the submission system closed about 40 hours
earlier - sigh.

Since I'm headed to Ecuador for a three week vacation with unknown and/or
unlikely Internet access, I have created a git repo and posted the source
(kramdown) and rendered xml, txt, html versions for both the protocol and
usage documents at https://github.com/kurta/arc-docs

Once the submissions system opens and I have internet access, I will get
the official submission completed; but until then, you can see the updates
at:

http://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dmarc-arc-protocol-01.txt&url2=https://raw.githubusercontent.com/kurta/arc-docs/master/dmarc-arc-protocol-02.txt

(obviously the date will have to change further)

Here are the key changes I added (based on input from the list and
discussion during the interop in February):

1) Removed the attempts to repair any problems in the ARC chain beyond
simple ordering problems, added cv=invalid
2) Added section 5.4 to discuss phases for transitioning signature
algorithms
3) Updated length of chain? (section 5.1.1.1.1) at least 10, may be up to
50; may mark invalid above that

Also as discussed in the interop, I did not add any additional requirements
in ARC regarding key lengths. I will be submitting an update to the DKIM
spec itself to fork both the key length and signing algorithms into a
registry which can then be managed without requiring further spec updates.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Mar 2017 00:43:25 -0700

> usage documents at https://github.com/kurta/arc-docs

Thanks, I'll take a run at it soon, especially during Chicago.

> Also as discussed in the interop, I did not add any additional
> requirements in ARC regarding key lengths. I will be submitting an update
> to the DKIM spec itself to fork both the key length and signing algorithms
> into a registry which can then be managed without requiring further spec
> updates.

There's already registries for DKIM key types and hash algorithms, so no
need to create any:
https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml

I'm not sure how you could go about registering key lengths.  What do you
have in mind?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 17 Mar 2017 00:23:15 -0000

>I'm not sure how you could go about registering key lengths.  What do you

Come to DISPATCH and learn all about it.

The general point is that DKIM's key advice is kind of stale -- 512 bit keys are
too short, 1024 keys are OK now, but within the likely lifetime of this spec
we'll need longer keys.  The obvious suggestion is 2048 except they don't
fit in a single TXT record string, and way too much DNS web crudware(tm)
doesn't handle multiple strings.

Oh, and elliptic curve.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 Mar 2017 15:22:26 -0700

> Come to DISPATCH and learn all about it.

Oh, don't you worry.  :-)

The general point is that DKIM's key advice is kind of stale -- 512 bit
> keys are

Sure; the existing registries are for hash algorithms and key types.
Obviously more of those could be added, or we could deprecate some
entries.  And I could see an "Updates" document changing what DKIM says
about supported or recommended key sizes, or amendments to these
registries.  But Kurt said something about creating an IANA registry of
supported key sizes, and I don't know what that would look like.

I'll find out in Chicago, I guess.

-MSK