Subject: [dmarc-ietf] ARC protocol-15 posted

From: Kurt Andersen <[email-masked]>
Date: Sun, 24 Jun 2018 21:27:49 -0700

I've now posted draft 15 of the ARC protocol. It should be ready for last
call - please review with that in mind. Note that the XML was a little
wacky in the Implementation Status section. I'll fix that formatting in the
next rev.

A new version of I-D, draft-ietf-dmarc-arc-protocol-15.txt
> has been successfully submitted by Kurt Andersen and posted to the
> IETF repository.
> Name: draft-ietf-dmarc-arc-protocol
> Revision: 15
> Title: Authenticated Received Chain (ARC) Protocol
> Document date: 2018-06-24
> Group: dmarc
> Pages: 34
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-15.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-15

--Kurt

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 25 Jun 2018 12:31:43 +0100

On 06/25/2018 05:27 AM, Kurt Andersen wrote:
> I've now posted draft 15 of the ARC protocol.

Section 4.1.3 ARC-Seal (AS)

Second bullet point:
   "Section Section 5.1.1"
   - reads oddly in the text version.  It's more clear in the
     html version, where the second "Section" is part of a link.
     This applies in multiple places

Fifth bullet point:
   "Note especially that the DKIM "h" header is NOT"...

s/header/tag ?

   + this (new?) requirement to check on h-tags for
     AS mean that a common parse routine for the three
     header types cannot be used.  Did I miss the discussion
     introducing the requirement?

   + 5.1.1 has no further information... perhaps a whole
bunch of info was dropped?

-- 
Cheers,
  Jeremy

---

From: Stan Kalisch <[email-masked]>
Date: Mon, 25 Jun 2018 10:07:46 -0400

> On Jun 25, 2018, at 12:27 AM, Kurt Andersen <[email-masked]> wrote:
> 

Nit:  Tim's last name seems to be morphing into a dragon.

Stan

> It should be ready for last call - please review with that in mind. Note that the XML was a little wacky in the Implementation Status section. I'll fix that formatting in the next rev.
> 
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-protocol-15.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-15
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol
>> Diff:           https://www..ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-15
> 
> --Kurt
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 25 Jun 2018 08:10:36 -0700

>      This applies in multiple places

Looks like this was accidentally introduced in the editing process along
the way. Will be cleaned up. Thanks for catching it.

>    "Note especially that the DKIM "h" header is NOT"...

Yes

>      introducing the requirement?

The 'h' tag was never defined for the AS header.

> bunch of info was dropped?

I see text in both html and txt versions in section 5.1.1 in my locally
processed version. Will check the IETF tools version.

--Kurt

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 25 Jun 2018 16:16:32 +0100

> The 'h' tag was never defined for the AS header.

Indeed, but there was no requirement to check for one either.

-- 
Cheers,
  Jeremy

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 25 Jun 2018 08:17:07 -0700

> Nit:  Tim's last name seems to be morphing into a dragon.

Fixed. You'd think I would get that right given the spelling of my own last
name :-/ Apologies to Tim.

--Kurt

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 25 Jun 2018 08:18:42 -0700

> Indeed, but there was no requirement to check for one either.

Correct - this was a clarification that has been added. If people find it
objectionable we can take it back out. What would your parser do if it
found an "h" tag in the header? Just ignore it or override the implicit "h"
that is defined for AS?

--Kurt

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 25 Jun 2018 16:30:43 +0100

> found an "h" tag in the header? Just ignore it or override the implicit "h"

Just ignore it.
-J

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 25 Jun 2018 08:38:53 -0700

On Mon, Jun 25, 2018 at 8:30 AM, Jeremy Harris <[email-masked]> wrote:

> Just ignore it

That's the right approach, but the ambiguity of what a validator might do
is why we thought it best to be explicit. I guess that we could drop the
illegality of an "h" tag and just specify that it MUST be ignored instead.
Opinions from any other implementations?

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Mon, 25 Jun 2018 05:44:58 -1000

On 6/25/2018 5:38 AM, Kurt Andersen (b) wrote:
> That's the right approach, but the ambiguity of what a validator might 
> do is why we thought it best to be explicit.

Yup.

Anything that comes close to 'do whatever you want with this 
information' demonstrates NON-standardization.

If the creator of the information does not have a reliable way of 
knowing what the receiver of it will do with it -- I mean interpretation 
of the information, not follow-on policy decision-making -- then it 
isn't a standard.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 25 Jun 2018 17:03:16 +0100

> of the information, not follow-on policy decision-making -- then it

On that view, the spec should be either

  "any tag not specified here, in any of the three ARC headers,
  invalidates the ARC set"

or

  "any tag not specified here, in any of the three ARC headers,
  MUST be ignored".

-- 
Cheers,
  Jeremy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 25 Jun 2018 06:09:11 -1000

>    "any tag not specified here, in any of the three ARC headers,

While there are some operational environments where one of these two 
choices really is appropriate -- the need for extremely rigorous control 
over the entire range of operational choice is... extreme -- this isn't 
one of them.

There's a difference between 'all information must be defined' and 'all 
information must be defined here'.  Your choices match the latter.  The 
former is adequate here.

Just because information isn't defined in /this/ document and just 
because the receiver doesn't understand the information, does not mean 
its presence is unacceptable.  The most common example of this truth is 
enhancements defined later, while continued operation by older 
implementations is still desired.

d/

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 27 Jun 2018 20:52:07 +0100

> over the entire range of operational choice is... extreme -- this isn't

Then I'm unclear what you were asking for with

> Anything that comes close to 'do whatever you want with this information' demonstrates NON-standardization. 

Perhaps you could suggest some text for the spec?
-- 
Jeremy

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 27 Jun 2018 13:15:12 -0700

On Wed, Jun 27, 2018 at 12:52 PM, Jeremy Harris <[email-masked]> wrote:

> <https://www.ietf.org/mailman/listinfo/dmarc>
>

We already tried to walk that line in the spec. In general, any tag that
does not have a defined interpretation (firstly in the ARC spec, then
falling back to the DKIM spec) gets ignored with certain exceptions, such
as the "h" tag in an AS header.

--Kurt

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 27 Jun 2018 21:20:18 +0100

> as the "h" tag in an AS header.

That does not say why that specific case is worthy of special attention.
I think you need to justify it.

-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2018 10:13:50 -0500

>> information' demonstrates NON-standardization.

Not at all.  The point of a standard is to say here is what you do if
you want to interoperate.  Trying to figure out how to recover when
someone else doesn't follow the spec is a fool's errand, since there
are more ways to misimplement a spec than any of us can imagine.

I suppose we could put in a sentence or two reminding people that
unlike DKIM, the list of tags in the spec are the only ones allowed in
an ARC header, so don't try to invent new ones.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 29 Jun 2018 22:13:49 -0400

> an ARC header, so don't try to invent new ones.

That's pretty tight.  No room for exploration and experimentation, and 
imeo, this protocol will need more than a few explorations to see how 
useful it might be.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jun 2018 19:41:23 -0700

> are more ways to misimplement a spec than any of us can imagine.

Your first sentences asserts disagreement, but I don't see how the rest 
of the paragraph provides it, since it both looks reasonable and doesn't 
seem to contradict what I said.

In any event, my language was carelessly broad and probably misdirected, 
so it might be worth some clarification and better precision:

1. A protocol specification defines a space to work within.  If you work 
outside of that space, your activity has nothing to do with that spec.

2. If you are purportedly working within that space but take actions the 
deviate from prescribed actions (or include proscribed ones) then you 
really are violating the spec.  So one of my points is that a 
specification has an obligation to specify actions that are clear and 
precise and reasonable.  For all actors.

3. Not all protocol details are about actions.  The ones about formats 
do not necessarily couple with directives about actions; that is, a spec 
might define syntax and semantics without saying what is to be done with 
the data.  But specifications of formats, too, have an obligation to be 
c-p-r. Although there are situations that justify common packaging for 
'private' information -- that is, non-standardized data inside a 
standardized container -- the usual case imposes standards on the data 
semantics too.  That goes to the other point I meant to make:  A 
specification that basically says that data may be interpreted in 
whatever way the receiver wants is not specifying a standard, because 
the encoder has no way to predict how the decoder will interpret it. 
(This was at the core of the DKIM d=/s= debate.)

> an ARC header, so don't try to invent new ones.

That's a major decision to make. It impedes innovation, so it should be 
justified pretty carefully.  In the text.

d/

---

From: John R Levine <[email-masked]>
Date: Fri, 29 Jun 2018 23:16:27 -0400 (EDT)

On Fri, 29 Jun 2018, Dave Crocker wrote:
> Your first sentences asserts disagreement, but I don't see how the rest of 
> the paragraph provides it, since it both looks reasonable and doesn't seem to 
> contradict what I said.

I think I'm agreeing with you and disagreeing with the person who said 
otherwise.  If you want to interoperate, implement what the spec says and 
don't worry about people who implement it wrong.

> justified pretty carefully.  In the text.

The alternative is to say to ignore mystery tags, but then we're in the 
same swamp we got to with DKIM v=2, tags that modify the intepretation of 
the signature.  Perhaps we should try and figure out the least bad way of 
allowing new signature algorithms, since that's the most likely change to 
happen soon.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Jun 2018 06:33:20 -0700

>   "any tag not specified here, in any of the three ARC headers,

In my view this is the right approach, but keep in mind that what's valid
in an AMS header field value is largely defined by what's valid in DKIM,
and what's valid in DKIM is defined in RFC6376 plus any later updates to it
or anything that registers a new tag.  And what's valid in AAR is anything
defined as valid in RFC7601, plus any registered additions, plus "i=".

AS is the only one with a tightly constrained set.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Jun 2018 06:40:40 -0700

> I think you need to justify it.

I think saying:

Notably absent from this list is the "h" tag.  It is not required for the
ARC-Seal because the list and order of header fields included in the seal
are prescribed in this specification.

...should suffice.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Jun 2018 07:00:07 -0700

> wacky in the Implementation Status section. I'll fix that formatting in the

I haven't read the entire thing yet (I will before Montreal) but I've
noticed that the organization of Section 5 has gone a little sideways:

* In Section 5.1, bullet 3 seems weird because it doesn't describe a step
* Section 5.1 is titled Sealer Actions, but Sections 5.1.4 and onward don't
actually enumerate actions for the sealer; they contain advice and general
discussion

A couple of other quick points until I can do a full pass:

* Section 9.2, bullet 1: For this attack to work, you don't have to forge
signatures; the signature could be the letter "x", and you'll still hit the
DNS to get the public key to try to verify it
* The IANA registration templates in Section10.1 are improperly formatted
* All of the formal references to old versions of the draft seem
unnecessary; simply using prose for those should suffice rather than
bulking up the Reference sections

-MSK

---

From: Stan Kalisch <[email-masked]>
Date: Sat, 30 Jun 2018 20:26:24 -0400

> On Jun 29, 2018, at 11:16 PM, John R Levine <[email-masked]> wrote:
> 
> Perhaps we should try and figure out the least bad way of allowing new signature algorithms, since that's the most likely change to happen soon.

Yes.  Especially because this spec is intended to be experimental.

Thanks,
Stan