Re: [dmarc-ietf] ARC questions

>>> T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz >>> 2CWA== >>> X-Gm-Message-State: >>> AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD >>> chdQCnyR1XB3fAEw5oIqGysS4Q== >>> X-Google-

Re: [dmarc-ietf] ARC questions

Michael Thomas skrev den 2020-12-03 03:58: if you're trying to make a point about the bloat, you might actually get your facts straight. ARC adds an additional DKIM signature and a Seal. i have no idea what a X-Google-DKIM-Signature is and is not relevant. would you show an example on that open

Re: [dmarc-ietf] ARC questions

2.02.15.30.03     (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);     Wed, 02 Dec 2020 15:30:04 -0800 (PST) Subject: Re: [dmarc-ietf] ARC questions To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.afdc027ce...@ary.qy>          <1eed8278-4efa-4abc-1

Re: [dmarc-ietf] ARC questions

CM_SHA256 bits=128/128);     Wed, 02 Dec 2020 15:30:04 -0800 (PST) Subject: Re: [dmarc-ietf] ARC questions To: John R Levine , Brandon Long Cc: IETF DMARC WG References: <20201124020453.afdc027ce...@ary.qy>          <1eed8278-4efa-4abc-15e0-2efcf014e...@mtcc.com>    <446d491b-

Re: [dmarc-ietf] ARC questions

On 12/2/20 6:33 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: But why bother?  The IANA header field registry currently has 419 entries. Why is it a crisis if it increases to 422 rather than 420? It does a lot more than that: We've been through this all before and none

Re: [dmarc-ietf] ARC questions

20 15:30:04 -0800 (PST) Return-Path: Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33]) by smtp.gmail.com with ESMTPSA id x7sm158495pfn.85.2020.12.02.15.30.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:30:04 -

Re: [dmarc-ietf] ARC questions

On 12/2/20 2:53 PM, John R Levine wrote: Which could trivially be added as an extension to DKIM and Auth-Res negating the need for the Seal altogether since DKIM can directly sign the old (renamed) auth-res. I can understand for an experiment not wanting to touch dkim or auth-res, but for some

Re: [dmarc-ietf] ARC questions

Which could trivially be added as an extension to DKIM and Auth-Res negating the need for the Seal altogether since DKIM can directly sign the old (renamed) auth-res. I can understand for an experiment not wanting to touch dkim or auth-res, but for something standards track less is more. I sti

Re: [dmarc-ietf] ARC questions

On 12/2/20 12:35 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: different in that respect. In fact as far as I can tell they are identical modulo the i= difference. Please reread the ARC spec.  The ARC-Authentication-Results at level N tells you whether the ARC and DKIM s

Re: [dmarc-ietf] ARC questions

On Wed, 2 Dec 2020, Michael Thomas wrote: different in that respect. In fact as far as I can tell they are identical modulo the i= difference. Please reread the ARC spec.  The ARC-Authentication-Results at level N tells you whether the ARC and DKIM signatures were good at level N-1. That's

Re: [dmarc-ietf] ARC questions

On 12/2/20 12:31 PM, John R Levine wrote: On Wed, 2 Dec 2020, Michael Thomas wrote: Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message. Wait, what? a DKIM signatures surviv

Re: [dmarc-ietf] ARC questions

On Wed, 2 Dec 2020, Michael Thomas wrote: Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message. Wait, what? a DKIM signatures survives until it encounters an intermediary that

Re: [dmarc-ietf] ARC questions

On 11/30/20 9:43 PM, Brandon Long wrote: To summarize what I said already in this thread, DKIM is taken by many receivers as the responsible party for a message, in both spam and phishing classifiers, with the latter being perhaps more relevant. DMARC is the one example of that.  DKIM signing

Re: [dmarc-ietf] ARC questions

In article you write: >questions the wg deems needed since then. Leaving ARC in an experimental >state ad infinitum doesn't seem optimal. Basically: 1) was it needed at >all 2) did it help. 3) if it helped, how much did it help. I agree that at some point we need to declare the experiment over

Re: [dmarc-ietf] ARC questions

On 11/26/20 1:56 AM, Murray S. Kucherawy wrote: ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking.  We landed at what became ARC.  I suppose an appendix might've been nice enumerating ever

Re: [dmarc-ietf] ARC questions

On 26/11/2020 10:56, Murray S. Kucherawy wrote: On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: Yeah, quantifying the problems kinda seems like the first order of business if you ask me. Quantifications will differ depending on what you count. Total number of messages versus total

Re: [dmarc-ietf] ARC questions

On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: > But what about DKIM? And why do they need to be processed differently? > When I first saw this, I looked at the ARC-Signature which looks identical > to a DKIM signature (i didn't notice the i= at the time), and am like what > is this? The i

Re: [dmarc-ietf] ARC questions

On 11/25/20 4:14 PM, Murray S. Kucherawy wrote: On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas > wrote: That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit". I just looked at a random message o

Re: [dmarc-ietf] ARC questions

On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas wrote: > On 11/24/20 8:19 PM, Murray S. Kucherawy wrote: > > On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Michael, I think the purpose is stated well enough: Mailing lists want >> to keep addi

Re: [dmarc-ietf] ARC questions

On 11/24/20 7:27 PM, Douglas Foster wrote: In my opinion, ARC does leave a lot of unanswered questions about how you use the data that ARC provides.   Again, the big organizations have the brain power at their disposal to figure that out for themselves, later. They've had that data for

Re: [dmarc-ietf] ARC questions

On 11/24/20 8:19 PM, Murray S. Kucherawy wrote: On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster > wrote: Michael, I think the purpose is stated well enough:   Mailing lists want to keep adding their content to messages, without being block

Re: [dmarc-ietf] ARC questions

On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Michael, I think the purpose is stated well enough: Mailing lists want > to keep adding their content to messages, without being blocked by > recipients. This means that they have to provide recipien

Re: [dmarc-ietf] ARC questions

Michael, I think the purpose is stated well enough: Mailing lists want to keep adding their content to messages, without being blocked by recipients. This means that they have to provide recipients with enough information for them to accept the forwarded content. Google and Microsoft seem to

Re: [dmarc-ietf] ARC questions

On Tue, 24 Nov 2020, Michael Thomas wrote: Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexity arises. Others shared our experience as well. That's more than one modifying intermediary in *separate

Re: [dmarc-ietf] ARC questions

On 11/24/20 4:56 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas > wrote: Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexity arises. 

Re: [dmarc-ietf] ARC questions

On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas wrote: > > On 11/24/20 3:24 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas wrote: > >> >> >> Sorry, changing the auth-res to old-auth-res and dkim signing the >> message would be completely sufficient, and far easier to

Re: [dmarc-ietf] ARC questions

On 11/24/20 3:24 PM, Brandon Long wrote: On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas > wrote: Sorry, changing the auth-res to old-auth-res and dkim signing the message would be completely sufficient, and far easier to understand with a lot less bloat. Al

Re: [dmarc-ietf] ARC questions

As Chair- This thread is quickly becoming unproductive and veering to personal attacks, which will not be tolerated. Please engage productively and on the merits, take the conversation elsewhere, or disengage. Seth On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas wrote: > You'd be wrong. The on

Re: [dmarc-ietf] ARC questions

You'd be wrong. The only ad hominem was yours from yesterday and it was I think where *you* dismissed the very question I raised: "Two or more levels of forward are quite common, particularly in large mail systems.  Look at mail coming out of Google and Microsoft's hosted mail and you'll see a

Re: [dmarc-ietf] ARC questions

On 11/23/20 6:04 PM, John Levine wrote: In article you write: What I'm struggling to understand is what having authenticated auth-res >from a previous hop helps. this is what i found: See some of the previous messages. My usual example is a mailing list message that fails DMARC at the final

Re: [dmarc-ietf] ARC questions

In article you write: >What I'm struggling to understand is what having authenticated auth-res >from a previous hop helps. this is what i found: See some of the previous messages. My usual example is a mailing list message that fails DMARC at the final recipient but passed DMARC (as recorded in

Re: [dmarc-ietf] ARC questions

On 11/23/2020 4:13 PM, Brandon Long wrote: On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker > wrote: On 11/23/2020 12:15 PM, Brandon Long wrote: On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker mailto:dcroc...@gmail.com>> wrote: DKIM often ties a domain to re

Re: [dmarc-ietf] ARC questions

On 11/23/20 3:00 PM, Dave Crocker wrote: On 11/23/2020 2:58 PM, John R Levine wrote: And, again, when ARC work was pursued, I don't recall anyone claiming that mailing lists were (significant) sources of misbehavior. Well, OK.  Please feel free to provide footnoted documentation of what the ac

Re: [dmarc-ietf] ARC questions

On 11/23/2020 2:58 PM, John R Levine wrote: And, again, when ARC work was pursued, I don't recall anyone claiming that mailing lists were (significant) sources of misbehavior. Well, OK.  Please feel free to provide footnoted documentation of what the actual motivation for ARC was if you believe

Re: [dmarc-ietf] ARC questions

I believe that Brandon has specifically said that Gmail sees this problem and that is why whitelisting mail from mailing lists isn't adequate. And that constitute "meaningfully document[ing]"? Works for me. I doubt I was the only person wondering why it needed all that mechanism when whitel

Re: [dmarc-ietf] ARC questions

On 11/23/2020 2:42 PM, John R Levine wrote: Forgive me but I believe misbehavior by mailing lists has never been meaningfully documented for this work.  Quite the contrary. I believe that Brandon has specifically said that Gmail sees this problem and that is why whitelisting mail from mailing

Re: [dmarc-ietf] ARC questions

You know that a message came from a mailing list because you have your list of IPs or DKIM signatures of lists you trust. Except that was not stated or, really, even implied in the text of the message I was replying to.  Rather, something like that seemed to be taken as an assumption, but with

Re: [dmarc-ietf] ARC questions

On 11/23/2020 1:27 PM, John Levine wrote: In article , Dave Crocker wrote: I believe, though, that the intent of ARC is that it be scalable in ways that manual enumeration of known legit mailing lists and forwarders is not. "if you know which hosts are legit" buries an assumption that is prob

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:48 PM, Dave Crocker wrote: This recent article also goes into things that DKIM signatures imply: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Re: [dmarc-ietf] ARC questions

In article you write: >I suppose that an approach to building up an ARC reputation might be one >where over time a receiving site can compare indirect mail flow that is >purported to have X as an authenticated identifier with mail that comes >direct to the receiving site with X as an authenticate

Re: [dmarc-ietf] ARC questions

In article , Dave Crocker wrote: >> I believe, though, that the intent of ARC is that it be scalable in >> ways that manual enumeration of known legit mailing lists and >> forwarders is not. > >"if you know which hosts are legit" buries an assumption that is >problematic, namely that you know

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:15 PM, Brandon Long wrote: This recent article also goes into things that DKIM signatures imply: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Re: [dmarc-ietf] ARC questions

On 11/23/2020 12:15 PM, Brandon Long wrote: On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker > wrote: > Yes, of course, a handling agent can do it, but there are plenty of reasons > why they shouldn't. Please enumerate and explain.  If it's that dangerous

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:29 PM, John R Levine wrote: 1) A mailing list creates an auth-res on the incoming mail to the list 2) It modified the message 3) It resigns the message with DKIM 4) It is then delivered to the subscriber's mail server 5) The destination mail server can look at the incoming mes

Re: [dmarc-ietf] ARC questions

1) A mailing list creates an auth-res on the incoming mail to the list 2) It modified the message 3) It resigns the message with DKIM 4) It is then delivered to the subscriber's mail server 5) The destination mail server can look at the incoming message including the mailing list's auth-res a

Re: [dmarc-ietf] ARC questions

On 11/23/20 12:09 PM, John R Levine wrote: Since this is an experiment, do we have an idea of what the rest of the problem is after the typical mailing list-like signature breakers are excluded? Sorry, this question makes no sense. The point of ARC is to deal with the kind of breakage that

Re: [dmarc-ietf] ARC questions

On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker wrote: > On 11/23/2020 11:42 AM, Brandon Long wrote: > > > > > > On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > > wrote: > > > > On 11/23/2020 11:29 AM, Brandon Long wrote: > > > The DKIM-Signature is an "ownership

Re: [dmarc-ietf] ARC questions

If auth-res is sometimes deleted, why wouldn't we expect the arc auth-res to not be deleted too? Please see RFC 7001, section 5. Since this is an experiment, do we have an idea of what the rest of the problem is after the typical mailing list-like signature breakers are excluded? Sorry, thi

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:34 AM, Brandon Long wrote: From the other direction, one could say that ARC is a superset of A-R and DKIM with different purpose, and you might be able to subsume them into ARC, but you couldn't build ARC out of the originals. It's seems to me that the superset involves exp

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:49 AM, Brandon Long wrote: I imagine that the vast majority of intermediaries that break signatures number exactly one extra domain, so it's not very hard to reconstruct the chain of custody from origin to destination. Assuming the intermediary resigns with th

Re: [dmarc-ietf] ARC questions

On 11/23/2020 11:42 AM, Brandon Long wrote: On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > wrote: On 11/23/2020 11:29 AM, Brandon Long wrote: > The DKIM-Signature is an "ownership" thing, it's a message originator > that is saying > "associate

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:42 AM, Brandon Long wrote: Yes, responsibility is the proper word.  My point survives the word change. DKIM says the domain takes responsibility for the message, while ARC says the domain takes responsibility for evaluating the status of the message when they received and fo

Re: [dmarc-ietf] ARC questions

On 11/23/20 11:28 AM, John R Levine wrote: From what I can tell, the main thing that ARC is doing is binding an auth-res to a dkim signature-like thing. But as I recall -- it's been a long time -- there were ordering requirements ala received headers for where new dkim-signatures and auth-res

Re: [dmarc-ietf] ARC questions

On 11/23/2020 11:29 AM, Brandon Long wrote: The DKIM-Signature is an "ownership" thing, it's a message originator that is saying "associate this message to me". That is not DKIM's semantics: "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some respons

Re: [dmarc-ietf] ARC questions

From what I can tell, the main thing that ARC is doing is binding an auth-res to a dkim signature-like thing. But as I recall -- it's been a long time -- there were ordering requirements ala received headers for where new dkim-signatures and auth-res go in the header. Assuming my memory is corre

Re: [dmarc-ietf] ARC questions

On 11/22/20 11:56 AM, John R Levine wrote: On Sun, 22 Nov 2020, Michael Thomas wrote: The ARC signature has a sequence number so you can track the chain of custody.  You are right that it is similar to the DKIM signature but the extra ovehead doesn't seem excessive. Did the wg consider just

Re: [dmarc-ietf] ARC questions

On 11/23/2020 10:34 AM, Todd Herr wrote: Yes, but knowing it really was handled by who is saying it was handled by isn't the entirety of the problem. Of course.  But it helps (quite a lot) to be clear about what this specific mechanism does do. d/ -- Dave Crocker dcroc...@gmail.com 408.329

Re: [dmarc-ietf] ARC questions

On Mon, Nov 23, 2020 at 12:02 PM Dave Crocker wrote: > On 11/23/2020 7:38 AM, Todd Herr wrote: > > On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan > wrote: > On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > >> >> >>> This also means that ARC isn't useful if you don't have a reputation s

Re: [dmarc-ietf] ARC questions

On 11/23/2020 9:15 AM, Doug Foster wrote: ARC tells me that somebody changed some data, but it does not tell me which MTA performed the forwarding operation, added content, or performed address rewriting.  If we could get HELO names into the ARC data, then those names could be correlated with t

Re: [dmarc-ietf] ARC questions

header chain to make better filtering decisions. DF From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker Sent: Monday, November 23, 2020 12:02 PM To: Todd Herr; Joseph Brennan Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ARC questions On 11/23/2020 7:38 AM, Todd Herr

Re: [dmarc-ietf] ARC questions

On 11/23/2020 7:38 AM, Todd Herr wrote: On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan > wrote: On Sat, Nov 21, 2020 at 7:14 PM John Levine > wrote: This also means that ARC isn't useful if you don't have a reputation

Re: [dmarc-ietf] ARC questions

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan wrote: > >> On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: >> >>> >>> > >> This also means that ARC isn't useful if you don't have a reputation >>> system to tell you where the lists and other forwarders that might add >>> legit ARC signatures a

Re: [dmarc-ietf] ARC questions

> > > > > On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > >> >> > This also means that ARC isn't useful if you don't have a reputation >> system to tell you where the lists and other forwarders that might add >> legit ARC signatures are. >> > > And if you know which hosts are legit mailing l

Re: [dmarc-ietf] ARC questions

.@mtcc.com Subject: Re: [dmarc-ietf] ARC questions In article you write: >-=-=-=-=-=- > > >On 11/22/20 11:18 AM, Douglas E. Foster wrote: >> ARC has a very limited set of items included in the signature.? ?Body >> hash is purposefully excluded.? So it is the same signatu

Re: [dmarc-ietf] ARC questions

In article you write: >-=-=-=-=-=- > > >On 11/22/20 11:18 AM, Douglas E. Foster wrote: >> ARC has a very limited set of items included in the signature.� �Body >> hash is purposefully excluded.� So it is the same signature algorithm >> but with different parameters and a different purpose.� Ther

Re: [dmarc-ietf] ARC questions

On Sun, 22 Nov 2020, Michael Thomas wrote: The ARC signature has a sequence number so you can track the chain of custody.  You are right that it is similar to the DKIM signature but the extra ovehead doesn't seem excessive. Did the wg consider just grafting that onto the DKIM signature itself

Re: [dmarc-ietf] ARC questions

Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ARC questions > Is there a reason that there is a separate ARC-signature rather than just > using the DKIM signature that is normally created for the new message? Since > ARC is new, you'd not want the intermediary to stop DKIM signing the

Re: [dmarc-ietf] ARC questions

On 11/22/20 11:14 AM, John R Levine wrote: Is there a reason that there is a separate ARC-signature rather than just using the DKIM signature that is normally created for the new message? Since ARC is new, you'd not want the intermediary to stop DKIM signing the message so you end up with esse

Re: [dmarc-ietf] ARC questions

Original message From: John R Levine Date: 11/22/20 2:14 PM (GMT-05:00) To: Michael Thomas , "Kurt Andersen (b)" Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ARC questions > Is there a reason that there is a separate ARC-signature rather than just > using the DKI

Re: [dmarc-ietf] ARC questions

Is there a reason that there is a separate ARC-signature rather than just using the DKIM signature that is normally created for the new message? Since ARC is new, you'd not want the intermediary to stop DKIM signing the message so you end up with essentially two signatures doing essentially the

Re: [dmarc-ietf] ARC questions

On 11/22/20 10:41 AM, Kurt Andersen (b) wrote: As usual, John has pretty well nailed the response, but there was one other part of your question (Mike) that I thought deserved explanation: On Sat, Nov 21, 2020 at 7:14 PM John Levine > wrote: In article mailto:dcc2

Re: [dmarc-ietf] ARC questions

As usual, John has pretty well nailed the response, but there was one other part of your question (Mike) that I thought deserved explanation: On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > In article you write: > >If I'm a receiver who is going to be making some filtering decisions > >bas

Re: [dmarc-ietf] ARC questions

In article you write: >If I'm a receiver who is going to be making some filtering decisions >based on ARC, I see that it passed by some authenticator along the way >which is fine, but my question is why I should trust that intermediary >in general? The short answer is that you shouldn't, any m

[dmarc-ietf] ARC questions

Hi all, long time. I finally read through the ARC spec after seeing it accidentally in mail headers wondering what it was, especially since it was so DKIM like. My barely informed take is that it allows intermediaries to say "this is what it looked like to me at this point [and before i mess