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

On Tue, Jul 17, 2018 at 8:01 AM, Jim Fenton wrote: > It wasn't meant as a restriction. I was trying to decide on the right > normative word to use here, and the IETF usage of SHOULD is probably too > strong. I'd be happy with a MAY there; I don't think it hurts to point out > that it's a good thi

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

On 7/16/18 1:00 PM, Kurt Andersen (b) wrote: On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton > wrote: On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton mailto:fen...@bluepopcorn.net>> wrote: I suggest that

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

In article you write: >> 9.2 describes the problem, but it's expressed in terms of a DoS attack on >> (primarily) validators. The DNS folk will be more concerned with the >> overall load on the infrastructure caused by ARC, not specifically on >> attack scenarios. So in consulting the DNS directo

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

On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton wrote: > 9.2 describes the problem, but it's expressed in terms of a DoS attack on > (primarily) validators. The DNS folk will be more concerned with the > overall load on the infrastructure caused by ARC, not specifically on > attack scenarios. So in c

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

On Mon, Jul 16, 2018 at 7:06 AM, Jim Fenton wrote: > On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: > > On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton > wrote: > >> >> I suggest that as part of WG Last Call that the DNS Directorate be >> consulted, largely to socialize this with them so they aren't

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

On 7/16/18 9:17 AM, Murray S. Kucherawy wrote: On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton > wrote: I suggest that as part of WG Last Call that the DNS Directorate be consulted, largely to socialize this with them so they aren't surprised by the reques

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

On Sun, Jul 15, 2018 at 6:27 PM, Jim Fenton wrote: > > I suggest that as part of WG Last Call that the DNS Directorate be > consulted, largely to socialize this with them so they aren't surprised by > the request load requirements. > Should the draft say more than what Section 9.2 already says?

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

On 7/11/18 9:39 PM, John Levine wrote: The header bloat war was over years ago, and bloat won. See the headers below from a Hotmail message I just sent to myself. And remember that most messages have two copies of the contents, one as text and one as overformatted HTML. I'm not particularly

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

In article you write: >Given that we've settled on Experimental status, I propose this gets tabled >until that's published. The experiment will establish what benefit ARC can >provide, which I think is the most important output of this work. The >change being suggested here appears to be one of

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

On Wed, Jul 11, 2018 at 8:33 PM, Jim Fenton wrote: > On 7/11/18 6:23 PM, Kurt Andersen (b) wrote: > > On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton > wrote: > >> >> So essentially we're creating a bunch of header bloat (creating duplicate >> header fields with different names where that could be a

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

On 7/11/18 6:23 PM, Kurt Andersen (b) wrote: On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton > wrote: So essentially we're creating a bunch of header bloat (creating duplicate header fields with different names where that could be avoided) because there ar

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

In article you write: >-=-=-=-=-=- > >On 7/11/18 5:15 PM, Brandon Long wrote: >So essentially we're creating a bunch of header bloat (creating >duplicate header fields with different names where that could be >avoided) because there are some MTAs that did not follow the >specifications before.

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

On Wed, Jul 11, 2018 at 5:38 PM, Jim Fenton wrote: > > So essentially we're creating a bunch of header bloat (creating duplicate > header fields with different names where that could be avoided) because > there are some MTAs that did not follow the specifications before. That > makes me unhappy,

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

On 7/11/18 5:15 PM, Brandon Long wrote: DKIM-Signatures are also sometimes removed from messages (mailing lists often do this), and there are also MTAs which incorrectly make assumptions about how DKIM-Signature failure means (the RFC says a failed DKIM-Signature should be treated as if it's no

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

On Tue, Jul 10, 2018 at 1:24 PM Jim Fenton wrote: > On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > > RFC7601 doesn't require or encourage deletion of A-R fields in general. > (The strongest word is "could".) If it's valid and possibly useful > downstream, you can certainly keep it. It only s

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

On 7/11/18 10:28 AM, Seth Blank wrote: But to circle back to Jim's original question about the value of the ARC Seal, this has also been discussed at length in this working group, and has probably been one of the largest technical points of contention: i.e. how much value does it really add,

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

On Wed, Jul 11, 2018 at 4:41 AM, Kurt Andersen (b) wrote: > I think that there is a bit of a difference here and terminology is not > being used precisely. The "seal" (AS) is not invalidated when someone > changes the content. The "signature" (AMS) is. The "seal" (aka AS) remains > valid as long

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

On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy wrote: > On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < > martijn=40dmarcanalyzer@dmarc.ietf.org > > wrote: > >> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text >> states to include the ARC Set currently being ad

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

On Wed, Jul 11, 2018 at 8:29 AM, Murray S. Kucherawy wrote: > On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < > martijn=40dmarcanalyzer@dmarc.ietf.org > > wrote: > >> In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text >> states to include the ARC Set currently being ad

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

On Wed, Jul 11, 2018 at 8:19 AM, Martijn van der Lee < martijn=40dmarcanalyzer@dmarc.ietf.org> wrote: > In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states > to include the ARC Set currently being added. > However, the signature cannot include the current ARC-Seal header

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

Hi all, In 5.1.1. (Header Fields To Include In ARC-Seal Signatures) he text states to include the ARC Set currently being added. However, the signature cannot include the current ARC-Seal header, as it's full contents are not yet known at the time (for obvious reasons). Should the current ARC-Seal

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

On Tue, Jul 10, 2018 at 10:48 PM, Murray S. Kucherawy wrote: > On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton > wrote: > >> On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: >> >> >> AMS is basically the same as DKIM-Signature, and so it covers body >> modifications. When you verify the seal, you mu

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

On Tue, Jul 10, 2018 at 1:24 PM, Jim Fenton wrote: > On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: > > > AMS is basically the same as DKIM-Signature, and so it covers body > modifications. When you verify the seal, you must also verify the latest > AMS, which in turn means the seal is invalida

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

On 7/10/18 12:43 PM, Murray S. Kucherawy wrote: RFC7601 doesn't require or encourage deletion of A-R fields in general.  (The strongest word is "could".)  If it's valid and possibly useful downstream, you can certainly keep it.  It only says you have to delete stuff that's clearly a forgery.

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

On Tue, Jul 10, 2018 at 12:13 PM, Jim Fenton wrote: > On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: > > On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton > wrote: > >> Substantive issues: >> >> General: I see lots of references to "authentication state", beginning >> with two references in the abstract,

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

On 7/9/18 7:28 PM, Kurt Andersen (b) wrote: On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton > wrote: Substantive issues: General: I see lots of references to "authentication state", beginning with two references in the abstract, but I don't see the ter

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

On Mon, Jul 9, 2018 at 3:01 PM, Jim Fenton wrote: > On 6/24/18 9:27 PM, Kurt Andersen wrote: > >> 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

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

On 6/24/18 9:27 PM, Kurt Andersen wrote: 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. I'm very late in revi

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

> On Jun 29, 2018, at 11:16 PM, John R Levine 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 ___

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

On Sun, Jun 24, 2018 at 9:27 PM, Kurt Andersen wrote: > 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. > I

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

On Wed, Jun 27, 2018 at 1:20 PM, Jeremy Harris wrote: > On 06/27/2018 09:15 PM, Kurt Andersen (b) wrote: > > 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 i

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

On Mon, Jun 25, 2018 at 9:03 AM, Jeremy Harris wrote: > "any tag not specified here, in any of the three ARC headers, > MUST be ignored". 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 wh

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

On Fri, 29 Jun 2018, Dave Crocker wrote: 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

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

On 6/29/2018 8:13 AM, John Levine wrote: In article you write: Anything that comes close to 'do whatever you want with this 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

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

On 6/29/2018 11:13 AM, John Levine wrote: In article you write: Anything that comes close to 'do whatever you want with this 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 ho

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

In article you write: >> Anything that comes close to 'do whatever you want with this >> 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 f

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

On 06/27/2018 09:15 PM, Kurt Andersen (b) wrote: > 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 h

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

On Wed, Jun 27, 2018 at 12:52 PM, Jeremy Harris wrote: > On 06/25/2018 05:09 PM, Dave Crocker wrote: > > On 6/25/2018 6:03 AM, Jeremy Harris wrote: > >> On 06/25/2018 04:44 PM, Dave Crocker wrote: > >>> If the creator of the information does not have a reliable way of > >>> knowing what the recei

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

On 06/25/2018 05:09 PM, Dave Crocker wrote: > On 6/25/2018 6:03 AM, Jeremy Harris wrote: >> On 06/25/2018 04:44 PM, Dave Crocker wrote: >>> 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 infor

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

On 6/25/2018 6:03 AM, Jeremy Harris wrote: On 06/25/2018 04:44 PM, Dave Crocker wrote: 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 is

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

On 06/25/2018 04:44 PM, Dave Crocker wrote: > 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 > inf

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

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

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

On Mon, Jun 25, 2018 at 8:30 AM, Jeremy Harris wrote: > On 06/25/2018 04:18 PM, Kurt Andersen (b) wrote: > > 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? Jus

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

On 06/25/2018 04:18 PM, Kurt Andersen (b) wrote: > 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 A

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

On Mon, Jun 25, 2018 at 8:16 AM, Jeremy Harris wrote: > On 06/25/2018 04:10 PM, Kurt Andersen (b) wrote: > >>+ 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 > >>

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

On Mon, Jun 25, 2018 at 7:07 AM, Stan Kalisch wrote: > > On Jun 25, 2018, at 12:27 AM, Kurt Andersen wrote: > > I've now posted draft 15 of the ARC protocol. > > > 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

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

On 06/25/2018 04:10 PM, Kurt Andersen (b) wrote: >>+ 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? >> > > The 'h' tag was never define

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

On Mon, Jun 25, 2018 at 4:31 AM, Jeremy Harris wrote: > 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

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

> On Jun 25, 2018, at 12:27 AM, Kurt Andersen wrote: > > I've now posted draft 15 of the ARC protocol. 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 Implement

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

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.

[dmarc-ietf] ARC protocol-15 posted

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 be