Subject: [dmarc-ietf] New drafts of ARC protocol (10) & usage (03) posted

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 19 Dec 2017 14:49:10 +0000

I've just posted new drafts of both the protocol and usage documents:

Name: draft-ietf-dmarc-arc-protocol
Revision: 10
Title: Authenticated Received Chain (ARC) Protocol
Document date: 2017-12-19
Group: dmarc
Pages: 49
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-10.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-10
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-10

and

Name: draft-ietf-dmarc-arc-usage
Revision: 03
Title: Recommended Usage of the Authenticated Received Chain (ARC)
Document date: 2017-12-19
Group: dmarc
Pages: 18
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-usage-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dmarc-arc-usage-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-03
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-usage-03

The pertinent changes are as follows:

Protocol:
* Update section 4 using Seth's suggested "protocol elements" section with
some editorial adjustments and incorporating the few feedback suggestions
which had come in on the list;
* Move the "instance" definition into section 5
* Update the AAR definition section (formerly 5.1) using Seth's suggested
7601bis wording (also adjusting for feedback that came in on the list) and
annotating the section to be adjusted if we can kick off the 7601bis work
in a timely fashion;
* Various other tweaks and adjustments to clean up the prose here and there

Usage:
* Incorporate Seth's "experiment" write-up as an "open questions" section
with various adjustments to the wording to reflect the "open questions we
would like to understand" adjustment.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Dec 2017 11:40:33 -0800

> annotating the section to be adjusted if we can kick off the 7601bis work

I plan to start a 7601bis effort to support what ARC needs, possibly over
the holidays, certainly in time for IETF 101.

> would like to understand" adjustment.

Whoa, no.  This belongs in the main protocol document, because it is the
experiment.  And that document is still showing "Standards Track".  Didn't
we reach consensus on the experimental route for the protocol document?

Some other stuff after a quick glance at the diff:

I like the addition of a "Protocol Elements" section.  However, I'm
becoming increasingly uneasy with the term "Chain of Custody".  To me,
perhaps from watching too many legal shows, that term is in effect a blob
of metadata applied to some object as a way of showing who transported it
from A to B (i.e., a handling chain), but in no way is that material
modified in transit.  If we have such an immutable payload here, I'm not
clear on what that is.  To me, ARC is more of an audit trail that
incorporates a record of changes to the object as well as who handled it.

I thought discussion had led to registration of "header.s" instead of
"header.ds" and ARC would just use that plus "header.d" to provide the
required information.  This version still contains "header.ds".

Finally, not specific to this version, but: Do we need the section on
algorithm rotation?  DKIM didn't have that in RFC7601, and DCRUP which is
adding ECC to DKIM has far less to say on the matter (
https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-07#section-6).  I
suspect, therefore, that we could get away with a more minimalist
approach.  Alternatively, do we have experience in any other protocol of
doing this kind of algorithm rotation pattern to success?

-MSK

---

From: Brandon Long <[email-masked]>
Date: Thu, 21 Dec 2017 00:39:46 +0000

On Wed, Dec 20, 2017 at 11:40 AM Murray S. Kucherawy <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-07#section-6).
> I suspect, therefore, that we could get away with a more minimalist

I think algorithm rotation is more challenging for ARC than it is for DKIM,
since with DKIM you can just sign with both... but for ARC, there's a chain
of signers and the you have to handle links not being able to verify
intermediate states in the other algorithm.

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Dec 2017 22:12:38 -0800

On Wed, Dec 20, 2017 at 4:39 PM, Brandon Long <[email-masked]> wrote:

> I think algorithm rotation is more challenging for ARC than it is for
> DKIM, since with DKIM you can just sign with both... but for ARC, there's a
> chain of signers and the you have to handle links not being able to verify

If the group concurs, then it would seem this section needs quite a bit
more development.  Who's up for proposing text?

-MSK

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 21 Dec 2017 22:58:09 +1100

On Thu, 21 Dec 2017, at 17:12, Murray S. Kucherawy wrote:
> On Wed, Dec 20, 2017 at 4:39 PM, Brandon Long
> <[email-masked]> wrote:>> 
>> DKIM, since with DKIM you can just sign with both... but for ARC,
>> there's a chain of signers and the you have to handle links not being
>> able to verify intermediate states in the other algorithm.>> 
> 
> If the group concurs, then it would seem this section needs quite a
> bit more development.  Who's up for proposing text?
I certainly concur with Brandon here - changing ARC algorithm looks like
a very messy proposition, I expect you'd pretty much have to do a window
where both the old and new algorithm were supported - with a dealine
where the old algorithm gets treated like a broken link.  It's probably
a strong reason to MUST that every implementation support signing and
verifying at least two currently presumed strong algorithms at the
start, so if one is found wanting we can immediately deprecate it and
everyone can just turn on the other algorithm in their software
configuration.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2017 11:57:44 -0500

In article <[email-masked]> you write:
>where the old algorithm gets treated like a broken link. ...

Complex technical approach:

Invent a new ps= tag for peer selector.  If using two signing
algorithms, add two AS and AMS headers with the same d= but different
s=, one for each algorithm, each with a ps= pointing to the other
header, and each signature covering both headers, and you have to
check when signing and validating that the ps= in this header matches
the s= in the other.  The chain is valid if either AS is valid.

Simple administrative approach:

Stall ARC for a few more months until we can get ed25519 into the
libraries, then adjust the document to make it MUST verify both.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Thu, 21 Dec 2017 09:23:02 -0800

> libraries, then adjust the document to make it MUST verify both.

Is there any appetite in the group to handle rotation in a separate
document?

-- 

Bringing Trust to Email

Seth Blank | Director of Industry Initiatives
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: Brandon Long <[email-masked]>
Date: Thu, 21 Dec 2017 17:29:54 +0000

> Is there any appetite in the group to handle rotation in a separate

I would have preferred not to defer it when arc was on standards track, but
now that it's experimental,
I could see deferring it.  I'm also fine with John's approach to wait for
dcrup, though I don't know many folks
are waiting for arc to be released as an rfc before working on it, I would
think openarc going 1.0 is probably the
main thing folks were waiting for.

Brandon

---

From: Seth Blank <[email-masked]>
Date: Thu, 21 Dec 2017 17:43:05 +0000

Now from my personal email.

On Thu, Dec 21, 2017 at 09:30 Brandon Long <[email-masked]> wrote:

> I would have preferred not to defer it when arc was on standards track,
> but now that it's experimental,

I agree OpenARC 1.0 will help, but many are looking for the technical
components of the draft to be “stable” and this could reopen that
hesitation to implement.

Bringing Trust to Email

Seth Blank | Director of Industry Initiatives
[email-masked]
+1-415-894-2724 <javascript:void(0);>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 21 Dec 2017 21:56:49 +0000

On Thu, Dec 21, 2017 at 5:29 PM, Brandon Long <[email-masked]> wrote:
>
>
> . . .when arc was on standards track, but now that it's experimental . . .
>

It's not experimental - that was a proposal in Prague when we were
considering pushing for WGLC before Singapore. Since we are continuing to
iterate and clean up the language in the standards track protocol, I've
left it on standards track.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 21 Dec 2017 17:25:09 -0500

On Thursday, December 21, 2017 11:57:44 AM John Levine wrote:
> In article 
<[email-masked]> you 
> libraries, then adjust the document to make it MUST verify both.

I doubt you'll see it in OpenARC until after OpenSSL has a release that 
supports ed25519.  That may be a large value of few.  Does anyone know?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Dec 2017 15:10:32 -0800

> but now that it's experimental,

I recall an extended discussion that produced agreement on experiment.

I don't recall seeing a discussion to reverse that, nor a change in 
circumstances that makes obvious the need for the change.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Thu, 21 Dec 2017 23:18:06 +0000

That is also what I remember, and why I proposed the Experimental
Considerstions as part of the primary draft and not the usage guide.

Kurt had some strong opinions on why they belonged in the usage guide,
which I suggest we revisit in another thread.

On Thu, Dec 21, 2017 at 15:11 Dave Crocker <[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 21 Dec 2017 21:50:33 -0500

>supports ed25519.  That may be a large value of few.  Does anyone know?

Rich Salz says it's supposed to be in the next release.  The ed25519
code has been in the github source for several months.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Dec 2017 00:32:36 -0800

>> circumstances that makes obvious the need for the change.
This was also my understanding.

"Experimental" is perfectly fine.  As I understand it, EAI did that first
and went to the standards track after it had some field use.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 22 Dec 2017 12:37:39 -0500

>and went to the standards track after it had some field use.

That is true, but it's also true that the standards track version of
EAI is fairly different from the experimental version, mostly by
leaving out a feature that didn't work in the field (downgrading.)

ARC is complex enough that I think it's likely that once we have
experience with ARC 1.0, we'll find that the stanards track ARC 2.0 is
somewhat different.  Perhaps we should think about how to prepare
for that, e.g., the dread version number field.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Dec 2017 09:56:56 -0800

On 12/22/2017 9:37 AM, John Levine wrote:
> Perhaps we should think about how to prepare

To repeat my non-traditionalist view of version numbers: I've seen 
claims of effective uses for them, not mere promises of future 
usefulness, but I haven't retained the examples.

Rather, my view is:

1. Added features:  A revision often adds a feature or extends values, 
or the like.  My claim is that the presence of that additional 
information also signals use of the later version of the specification. 
Hence the version field is, at best, redundant.

2. Deprecated features:  Consider the above and then reverse it.  The 
presence of a deprecated feature tells the receiver that the sender is 
using the older version of the spec.  Again, the version field is redundant.

3. Incompatible features:  This is the interesting case, where the 
previous and later versions have conflicting behaviors. My view is that 
this is not merely a new 'version' but, rather, is a new protocol. 
However the protocol itself -- not version -- has been identified by the 
lower layer, a new label should be used.

d/

---

From: "John R Levine" <[email-masked]>
Date: 22 Dec 2017 13:03:26 -0500

On Fri, 22 Dec 2017, Dave Crocker wrote:
> 3. Incompatible features:  This is the interesting case, where the previous 
> and later versions have conflicting behaviors. My view is that this is not 
> merely a new 'version' but, rather, is a new protocol. However the protocol 
> itself -- not version -- has been identified by the lower layer, a new label 
> should be used.

As you note, in a tag=value system you don't need versioning to add or 
ignore tags.  We'll have to agree to disagree about whether it's a good 
idea to invent a new name for every version tweak that's not fully 
backward compatible, particularly ones that don't change the parsing, just 
the interpretation.

R's,
John

PS: But if you're saying that IPv6 should have had a different name, I 
totally agree.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Dec 2017 10:06:58 -0800

On 12/22/2017 10:03 AM, John R Levine wrote:
> We'll have to agree to disagree about whether it's a good idea to
> invent a new name for every version tweak that's not fully backward
> compatible, particularly ones that don't change the parsing, just the
> interpretation.

1.  I believe such incompatibilities are relatively rare.

2. It should be viewed as a Very Big Deal.

Compatibility is essential for operational stability, so something that
breaks that is inherently traumatic.  Using a new, lower-level
identifier is the least of the issues.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Dec 2017 22:01:42 -0800

> leaving out a feature that didn't work in the field (downgrading.)

Does that mean going with "experimental" first was a good choice or bad
choice for them?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 23 Dec 2017 11:21:02 -0500

> Does that mean going with "experimental" first was a good choice or bad

For EAI it was the right choice.  They invented a brand new two-part 
address (Unicode and ASCII) and didn't know whether it would work in 
practice.  The experiment showed that it didn't so we took it out of the 
standards track EAI.

For ARC I see two unknowns, a minor one about how to do algorithm 
rotation, and a major one whether its audit trail will be adequate to do 
un-DMARC-ing.  For that last question I expect there could be one answer 
for mail systems large enough to have their own models of where all the 
mail comes from and a different answer for smaller systems.

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 23 Dec 2017 09:56:14 -0800

> or ARC I see two unknowns, a minor one about how to do algorithm 

Can't remember whether there was an explicit list of 
unknowns-of-interest for ARC, developed previously.  The above look like 
very good items for the list.

What else should be evaluated, during experimental implementation and 
deployment?

d/