Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 5 Nov 2015 18:09:45 -0800

Removing the editorial fixes which I've incorporated into the recently
posted -09, I'm responding inline below to the discussion questions.

On Sat, Oct 31, 2015 at 4:56 AM, Murray S. Kucherawy <[email-masked]>
wrote:

>
> Section 4.1.3.3:
>
> - Is that fist bullet talking about things like "On behalf of"?  Also,
> what sort of collision is the concern here?
>

Not the "on behalf of" as much as the practice of taking the address part
and putting it into the display name while possibly tweaking the address
part to be "invalid".

Section 4.2:
>
> I'm generally unsure about this section.  It will eventually (sooner than
> later) refer to a number of expired documents.  It might be more helpful to
> the reader to just summarize the idea behind each approach in a paragraph
> rather than forcing the reader to chase down specific expired I-Ds.
>

I don't see a good way to avoid referring to (eventually) expired I-Ds.
That's the best way to catalog the ideas, but I did take your suggestions
on rephrasing the intent of some of them into some new wording.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Nov 2015 12:58:59 +0900

> on rephrasing the intent of some of them into some new wording.

I don't think you actually need to cite I-Ds just to enumerate the general
approaches that have been proposed.  Perhaps use this for the bullet list:

o Third party authorization schemes provide ways to extend identifier
alignment under control of the domain owner.

o A way to canonicalize messages that transit mailing lists so that their
alterations can be isolated from the original signed content.

o A way to record message transformations applied at each hop so they can
be reversed and the original signed content recovered.

o "Conditional" DKIM signatures, whereby the author domain indicates its
signature is only good if accompanied by a signature from an expected
downstream relay.

o Mechanisms to extend Authentication-Results [RFC7601] to multiple hops,
creating a provable chain of custody as well as a view to message
authentication results at each handling step.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Fri, 6 Nov 2015 15:37:51 -0600 (CST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Kurt Andersen (b)" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, November 5, 2015 7:58:59 PM
> Subject: Re: [dmarc-ietf] Responses to comments on
> draft-ietf-dmarc-interoperability-08.txt

> On Fri, Nov 6, 2015 at 11:09 AM, Kurt Andersen (b) < [email-masked] >
> wrote:

> > on
> > rephrasing the intent of some of them into some new wording.
> 

> o A way to record message transformations applied at each hop so they can be
> reversed and the original signed content recovered.

> authentication results at each handling step.

While the I-D will likely expires they will not be removed from the website, so references will still work, so I don't see as that bad that they are properly referenced in this document. I however agree we should provide a quick summary for people that do not need the details.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Nov 2015 16:36:23 -0800

On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin <[email-masked]>
wrote:

> While the I-D will likely expires they will not be removed from the
> website, so references will still work, so I don't see as that bad that
> they are properly referenced in this document. I however agree we should
> provide a quick summary for people that do not need the details.
>

On the flipside, I don't see what value they add; the ones that gain
consensus will be published in their own right, and the details of the ones
that don't probably aren't interesting to later readers anyway.

-MSK

---

From: [email-masked]
Date: Mon, 09 Nov 2015 14:16:42 -0800 (PST)

> that don't probably aren't interesting to later readers anyway.

Generally speaking IETF Consensus/Publication != Adoption and Use. There are a
number of drafts that never made it to RFC that contain information on stuff
that did in fact deploy. (Although the best example of this by far  is actually
in X.400, where one of the most widely used text bodypart types was only ever
described in a preliminary draft.)

That said, I'm dubious of the value of this section in a more general sense,
since in-progress work is likely to shift and change in unexpected ways,
which could easily make any description we provide more confusing than not.

I personally would prefer to limit this sort of thing to descrptions of
things we know are currently deployed to some degree. It's then up to
future work to describe it's own interoperability issues, which is going
to be a requirement for anything that makes it to RFC status anyhow.

And yes, this does leave the door open for something that doesn't make it to
RFC but does achieve some degree of deployment. But I think we have enough
current issues to cover without trying to detail the nature of future ones.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Nov 2015 13:01:58 +0100

On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote: 
>> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote: 
> 

Somewhat agree, unless we're able to say more on the reasons why a specific
approach failed to get broad consensus/ adoption.  I'm thinking of RFC6541, for
which the text in -10 (of the transient nature of I-Ds) doesn't hold.

OTOH, conditional signatures have been discussed for more than five years (my
dkim-joint-sigs I-D was in 2010), an implementation exists, albeit alpha
(Murray's OpenDKIM 2.11.0), and we seem to have a candidate WG document (John's
dkim-conditional-02) which would match the charter's "form of DKIM signature
that is better able to survive transit through intermediaries".  Can the WG
coordinate publication of these two I-Ds?

> I personally would prefer to limit this sort of thing to descriptions of

I'm neutral on mentioning ARC, dkim-transform, and dkim-canon-list.

Ale

---

From: [email-masked]
Date: Tue, 10 Nov 2015 06:30:14 -0800 (PST)

> coordinate publication of these two I-Ds?

THat's a good point. However, I have to say that while it would be nice in
theory to include information about whatever conditional scheme ends up getting
standardized in this document and/or what's in deployed code, deferring this
document in order to make that possible isn't really feasible from a process
standpoint.

				Ned

---

From: Terry Zink <[email-masked]>
Date: Tue, 10 Nov 2015 17:40:27 +0000

> coordinate publication of these two I-Ds?

-1.

Not because I don't think conditional DKIM can't work, but that we need to focus on one solution. When someone asks "How do I get email to survive DMARC if forwarded" we tell them "Go do this one thing" and not "Go do either this *or* this." It's also easier for receivers to implement, debug, and maintain one solution rather than two.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Alessandro Vesely
Sent: Tuesday, November 10, 2015 4:02 AM
To: [email-masked]; Murray S. Kucherawy
Cc: [email-masked]; Franck Martin
Subject: Re: [dmarc-ietf] Responses to comments on draft-ietf-dmarc-interoperability-08.txt

Ale

---

From: "M. Hammer" <[email-masked]>
Date: Tue, 10 Nov 2015 13:22:12 -0500

> Not because I don't think conditional DKIM can't work, but that we need to focus on one solution. When someone asks "How do I get email to survive DMARC if forwarded" we tell them "Go do this one t…

I agree with Terry on this, mainly because of the implementation issue 
for receivers.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Nov 2015 22:36:10 -0800

On Tue, Nov 10, 2015 at 9:40 AM, Terry Zink <[email-masked]>
wrote:

> Not because I don't think conditional DKIM can't work, but that we need to
> focus on one solution. When someone asks "How do I get email to survive
> DMARC if forwarded" we tell them "Go do this one thing" and not "Go do
> either this *or* this." It's also easier for receivers to implement, debug,
> and maintain one solution rather than two.
>

That makes it sound like we've already picked the one thing.  I don't
believe that's the case.

But really I think we're getting a bit ahead of ourselves here.  The
current focus should be on finishing the interoperability document, not
which protocol project(s) ought to progress toward standardization.

-MSK