Re: [dmarc-ietf] A-R results for DMARC

[Brandon Long]

On Wed, Dec 9, 2020 at 2:27 PM Michael Thomas  wrote:

>
> On 12/8/20 4:51 PM, Brandon Long wrote:
>
>
>
> On Mon, Dec 7, 2020 at 8:31 PM John R Levine  wrote:
>
>> On Mon, 7 Dec 2020, Murray S. Kucherawy wrote:
>> > The original intent back in RFC 5451 was to relay only those details
>> that
>> > an MUA might care about, such as the DKIM result (so you can display
>> > something representing a "pass" or "fail" on a message) and maybe the
>> > domain name found in a passing signature (an early shot at caring about
>> > alignment when rendering a message). ...
>>
>> I suppose but 5451 also says it might be useful to message filters.
>>
>
> Right, there are clearly MUAs that do some amount of spam filtering, so
> disposition
> of p=quarantine would seem to be useful for that.
>
> Is there any evidence for that though? I would assume that the folks on
> this list use a diverse set of MUA's and would be in a position to tell us
> if some of them do. I'm guessing by your statement that gmail doesn't do
> anything different.
>
Gmail does put messages with disposition quarantine into the spam label,
but we don't rely on the A-R header to pass that information from the smtp
transaction to the mailbox.

At least the Mac Apple Mail client did have a client-side spam filter,
looks like it probably still does:
https://support.apple.com/guide/mail/reduce-junk-mail-mlhlp1065/mac

Does it handle spf/dkim/dmarc in any way?  I don't know.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

[Brandon Long]

On Wed, Dec 9, 2020 at 10:53 AM John Levine  wrote:

> In article <609e1c9b-cc4d-d7d1-0fa8-79f515c1e...@tana.it> you write:
> > It has been asked for a new report type (perhaps a subset of failure
> > reports) that provides minimal data from the email (specifically, the
> > initial ask is for the to: and from: email addresses only) in order
> to aid
> > identification of the email's destination (and hence, the owner who
> can
> > help with getting it authenticated) without providing other PII.
>
> As always, I would want to see some evidence of an actual problem to
> be solved here. In the existing format, reporters can and do redact as
> much as they want.  Why isn't that sufficient?
>
> Looking at the actual forensic reports I get, the majority are from
> antispamcloud.com which gloms some report info and the failed
> message's headers into a text body, ignoring the spec that says it's
> supposed to be multipart/report. I presume if we changed the spec they
> still wouldn't follow it, so why bother.
>
> The rest of the reports are multipart/report, some with the whole
> message, some with just the headers.
>
> I think that if a reporter isn't willing to provide the headers it's
> unlikely to provide anything.  If we have a concrete reason to believe
> that there are people who would send these proposed super-redacted
> failure reports who do not send reports now, I might consider this.
> Otherwise, it's not a problem and close the ticket.
>

In today's much more privacy conscious world, should we have RUF reports in
DMARC
at all?

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

[Brandon Long]

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 understand
>> with a lot less bloat. All of this hand wringing about dozens of message
>> manglers in the path before it get to the destination and not be able to
>> figure out which auth-res was which seems wildly out of proportion for
>> what the normal case is: 1 message mangler in the path before it arrives
>> at the receiver's domain. Just like this message right here. That's why
>> I asked how common that was, which was dismissed, but not answered.
>>
>
> Note that this was exactly what we started with,
> X-Original-Authentication-Results
> and with Google's implementation signing that with X-Google-DKIM-Signature.
>
> Our version didn't just sign with DKIM-Signature because of the reasons
> already stated in this
> thread, that our understanding of how DKIM-Signature was being used made
> it a poor choice.
>
>
> Sorry, I didn't see that. Pointer?
>
>
> 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* administrative
> domains? Within your own administrative domain there shouldn't be an issue
> of trust since you can trust your own servers auth-res and that they are
> not maliciously trying to forge an auth-res for better treatment. and
> course it's best to stop a bad message as soon as possible in the mail
> pipeline if for no other reason than why waste the resources.
>
The administrative domain in practice tends to be per-vendor and
multi-tenant.  Ie, gsuite/gmail is on google.com, various third party
anti-spam gateways also different, on-premise being also separate.  Passing
that trust between domains is one of the things that ARC can handle.

O365 does a better job than Gmail at this, since there you can set up third
parties to be called from within a particular customer more specifically
(like an API), you can do this with GSuite or ad-hoc MTAs, but it tends to
be more manual by chaining MTAs and there isn't as much of an auth
mechanism to use.

As for stopping bad messages early, there tends to be strong majority in
favor of that for malware, less so for spam where people want access from
their mailboxes to false positives.  Some products do have separate
administrative quarantine areas that can be checked by admins, but that's
also an extra burden for IT... some of which want that burden, and some
definitely don't.  Some quarantines can be self-administered by users, but
that's obviously a separate thing they have to check, whether that's worse
than a spam folder, *shrug*.

> You say that your message had 1 mangler in the path, but really you don't
> know that.  It is
> likely that some people on this list are on enterprise accounts who are
> behind mangling inbound
> gateways (rewriting urls to go through safety checking hops is common, for
> example).  Or maybe
> they are on with University accounts using exchange but forward their mail
> to a personal or department
> gmail account.
>
>
> Well sure, I'm sure it can happen but is it common enough to worry about?
> And I'm still not convinced that figuring out who signed what and which
> auth-res it belonged to is in insurmountable problem. for one, there are
> received headers which better not be getting out of order to help correlate
> with the messages' path through intermediary verifiers too.
>
So, we do have some Received header walking code, and allow admins to set
up the list of IPs that are considered "internal" (beyond private
addresses)... but O365 uses public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible for
admins to maintain a list.  Obviously we can all add code to handle
Microsoft specially... and whichever other ones come up.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

[Brandon Long]

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  > <mailto:d...@dcrocker.net>> 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 this message to me".
> >
> > That is not DKIM's semantics:
> >
> >  "DomainKeys Identified Mail (DKIM) permits a person, role, or
> >  organization to claim some responsibility for a message by
> >  associating a domain name"
> >
> > This says nothing about whether the organization has anything to do
> > with
> > origination.
> >
> > There is nothing to prohibit or preclude handling agents other than
> the
> > originator from signing.
> >
> >
> > 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, we should
> document it, especially I don't recall that constraint being in any of
> the design or standardization discussions.
>

DKIM often ties a domain to reputation and other anti-spam features.  If you
forward spam to another host and sign it while forwarding, then the other
host
will think you send spam.

DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.  DKIM signing mail that you forward could mean
upgrading
a phishing message to passing DMARC.

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/

Perhaps this all means that DKIM has been used for more than it was
intended for.


> >  > Intermediaries don't want to take ownership of the message in that
> >  > sense, though there
> >  > are some mailing lists that do.
> >
> > Signing with DKIM does not take 'ownership'.
> >
> >
> > Yes, responsibility is the proper word.  My point survives the word
> change.
>
> I disagree.
>
>
> > 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 forwarded it.
>
> This implies that the word 'some' is irrelevant.  It isn't.  And it was
> included intentionally.
>

Automated systems can't really tell how much responsibility an intermediary
was
intending to take for the message.  OTOH, they typically are using it only
for a certain
purpose, so they assume that the intermediary took responsibility in the
sense that they
want... or rather, the people who wrote the code do.  Or the journalist
writing the story.

ARC was specified to have a more specific responsibility, and as different
from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM
for.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Trying to understand DMARC in light of Sender/indicators

[Brandon Long]

Although I'm not fully convinced by Dave's point on whether indicators are
useless (they certainly are not of large value, I'm less certain in the
margins).. I think I need to work through what DMARC is without that.

DMARC is composed of three things: alignment, policy and reporting.  I
think the argument is that the most important thing that DMARC brings is
message authentication.. but that's not actually what DMARC brings, but
perhaps we can view the point of DMARC as pushing forward the authenticated
message agenda.  In some ways, it's well defined to be such a forcing
function.  Policy and alignment make it easy for various bodies to point to
it as something they require entities to do, and reporting gives them the
path to do it and measure their success against it.

Alignment makes policy application easy, and it also makes reporting easy.
The Sender proposal hijacks the alignment, bringing in another
possible policy to enforce and a different potential reporting path.  The
draft makes it clear which policy is enforced (though of course that only
works if the receiver supports the Sender extension), but various folks on
the list have referred to the matrix problem of looking at the policies of
both, so at least it brings confusion.  It does provide confusion of
"ownership".  DMARC currently provides very clear ownership, even if that
is overly simplified for the pre-existing ecosystem.  Adding Sender muddies
that, even if it is a better match.

If both Sender & From fail evaluation, do we report to both? Should we
report Sender overrides to the From, should we report which From we're
overriding to the Sender?  How does the Sender overrider benefit from
reporting?  They'll have even less opportunity to "fix" things, since
presumably they have a more straightforward role, and without the existence
of the header, they have no role at all, so the best it could be is "places
we add the header but fail to sign" or all the other normal intermediary
cases where DMARC currently fails.

Does DMARC that allows third party overrides via Sender provide the same
incentive to originators?  In the sense that it makes it easier to get to
p=reject as there are fewer false rejects, probably.  In the sense that it
undermines the simple explanation for what DMARC does, I think it will harm
DMARC adoption.  ""Why did this phishing message get through" "Because
example.com added a Sender header that's aligned"  "What's the point of me
doing all this if it can be bypassed that easily?" "See, the receiving
system knows it wasn't yours and so it's on them that they didn't catch it"

In some ways, I fear that the Sender proposal is a solution for the mailing
list problem that throws out almost everything that DMARC added.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists

[Brandon Long]

On Tue, Sep 8, 2020 at 1:30 PM Murray S. Kucherawy 
wrote:

> On Tue, Sep 8, 2020 at 5:09 AM Doug Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> However, I disagree about negative reputation.Content filtering alone
>> is insufficient and even more error prone.   In the last year, I have had
>> spam campaigns about LED lighting, stand-up desks, touchless thermometers,
>> and knife sharpeners.  I cannot anticipate all the ways that spammers will
>> hide their dirty deeds.   But I know it is spam, not merely unwanted
>> advertising, because of receiving many similar messages from many different
>> domains using many different servers.   Third-party RBLs help but are
>> insufficient.   I am gradually building my own reputation database based on
>> the traffic that I am receiving.   By blocking the problem sources, I have
>> been able to get the spam problem under something approaching good control.
>>   Content filtering is a useful tool for day-zero detection of a new spam
>> source.   Once a source is detected, it needs to be blocked.
>>
>>
>>
>> Whether a message passes SPF and DMARC criteria is part of my search
>> critieria for unwanted traffic, but definitely not the only one.   As has
>> been observed, actual spoofing of the From address is not a huge part of my
>> problem at present.   This is largely because spammers have easy enough
>> tools in Friendly Name spoofing and corporate logo misuse.   But I also
>> attribute that low volume to the existence of SPF and DMARC.
>>
>
> Suppose I'm one of your touchless thermometer spammers.  Your system
> identifies me and the DKIM signing domain I'm using.  I notice, through
> well-established means, that my spam is no longer getting through to you.
> So I register a brand new junk domain name, perhaps sadehaiuhfiewn.com or
> whatever a few smashes of the keyboard yields, and start signing with that
> instead of whatever domain I was using before.  For a couple of bucks, I
> have now escaped my negative reputation in your system.  Maybe I bounce it
> through a botnet too, so that you can't catch me with an IP reputation
> either.
>
> Negative reputations are trivially shed.  It follows that it's not
> terribly useful to track them, at least not long-term.  You end up with
> records of spammy domains that you'll notice only sent mail for the
> shortest of time ranges, long enough to get in undetected or under the
> guise of "too new to block", and then abandoned when they stop working.
> Blocking domains you've never heard of before is often disruptive when,
> say, you join a loyalty program for some vendor you've never dealt with
> before and actually do want their mail, so you're between a rock and a hard
> place.
>
> Instead, positive reputations are the things on which you can reliably
> act, giving such messages preferential treatment.  It's generally a much
> higher bar, plus the namespace of domains that manage to earn positive
> reputations is small, and they tend to be well-behaved over longer periods
> of time.
>

I disagree, we track reputations both good and bad, and they are
incorporated in spam rules across the ladder.  A surprising number of
negative reputations are not shed, even at very-low... and sure, we do
sunset reputations that go unused.  At the very least, there is a time lag
before the spammer notices the effect and switches.

I mean, a blacklist is ultimately a determination that a reputation is so
low as to block completely, and that seems to be the main way that
anti-spam information is distributed and used by most medium to small
providers.

That set of botnet IPs definitely will get a low reputation themselves and
end up on blacklists.

And forcing the spammers to spend money on things like new domain names is
part of the benefit.

OTOH, we also don't believe in "too new to block", unknown reputation is a
great reason to apply throttling at the least.

Maybe some of this is large system stuff, where you can expect to see more
traffic and things don't tend to be unique... but of course we also get
complaints from very small volume folks as well.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[Brandon Long]

I think the DMARC RFC does a good job explaining why DMARC is better than
ADSP, even if the same mailing list issue is still there:
https://tools.ietf.org/html/rfc7489#appendix-A.5

And if you read the archives on the move to historic for adsp, there were
others then who objected to the reason put in the historic move as
likely as affecting the replacement .  Given the success of the
replacement, it stands to reason that the reasoning given in the move
to historic was not the full reason for the failure... and perhaps lends
credence to the thought that certain folks are more concerned about the
effects on mailing lists than the ecosystem as a whole is.

Brandon

On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton  wrote:

> On 8/15/20 3:53 PM, John Levine wrote:
>
> Not really. DKIM was deliberately designed not to be tied to any
> visible part of the message. ADSP was a poorly designed hack that was
> never implemented other than small experiments, and that I don't think
> many people understood. I got a lot of grief for making the most
> strict policy "discardable" even though that's obviously what it was.
>
>
> And even with the kinder-and-gentler term "discardable" for its most harsh
> policy option, ADSP was moved from Standards Track to Historic. From
> https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :
>
> There is, however, evidence of harm caused by incorrect configuration and by
> inappropriate use.  There have, for example, been real cases where a 
> high-value
> domain published an ADSP record of "discardable", but allowed users on their
> domain to subscribe to mailing lists.  When posts from those users were sent 
> to
> other domains that checked ADSP, those subscriber domains rejected the
> messages, resulting in forced unsubscribes from mailman (due to bounces) for
> the unsuspecting subscribers.
>
> Assurances that are provided by ADSP are generally obtained out of band in the
> real Internet, and not through ADSP.  Current deployment of ADSP is not
> recommended.
>
> Is that not exactly the same situation with DMARC, except that the policy
> in question now is "reject" rather than "discardable"? Yes, it's just a
> keyword, but it reflects the semantics of the expected action as well.
>
> -Jim
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Brandon Long]

On Fri, Aug 21, 2020 at 12:24 PM Jim Fenton  wrote:

> On 8/17/20 3:52 PM, Jesse Thompson wrote:
> > With a complex organization the only way to get people to change is to
> publish a restrictive DMARC policy and then see who comes out of the
> woodwork sheepishly admitting that they've been ignoring us for years.
> >
> > Normal people sending email (especially those who are working with an
> ESP, most of which happily send email without any DMARC alignment) do not
> comprehend the notion that they should be using a subdomain for their
> transactional messages; even when we directly communicate this fact to them
> repeatedly.  They just don't understand the nuances of email.
> >
> I thought the DMARC reporting mechanism was there to allow such
> organizations to detect those behaviors and get them corrected without
> actually causing the damage of a restrictive policy.
>

One thing we've found useful in this case is controlling the organization
from spamming.

Which is to say that the org has a policy on approvals and what is allowed
to be sent marketing wise, in some parts of the world to comply with laws
on such topics,
or to be sure the entire org follows the principles and someone new doesn't
just poison the pool for everyone else.

There are always people who route around restrictions or sometimes don't
even bother to look for anything, they'll just hire a third party ESP and
spam away.

DMARC helps in this case to reduce the success of that and force them back
to internal compliance, which relieves the legal burden as well as the
negative impacts
on delivery and public perception.

For folks who just register a new domain name and spam anyways... yeah,
well, there are other consequences down the line and other anti-phishing
restrictions that
kick in at least on our inbound systems..

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Brandon Long]

On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen  wrote:

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy 
> wrote:
>
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  wrote:
>
>> I am wondering whether companies like Dmarcian could implement third-pary
>> whitelisting.  As they receive and analyze DMARC aggregate reports on
>> behalf of many mail sites, they probably are able to distinguish various
>> level of authentication failures, from mailing lists to misaligned ESPs, to
>> actual abusers.  In that case, they could maintain a whitelist tailored for
>> any given client.  The client would set, say:
>>
>> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
>> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
>> [...]
>>
>
> Having spent a lot of time and energy building a DKIM-based reputation
> system that (IMHO) showed promise, I made it available for people to try
> for free.  There was no uptake, even after presenting its promising results
> in places like M3AAWG.  Times may have changed, but in retrospect I think
> there are too many "what-ifs" for add-ons of this nature to be seen as
> feasible.  The issues seem to be:
>
>
> Hi MSK, hi Ale,
>
> I can second that MSK's DKIM-based reputation system is amazing. From
> where I sit, it's like a flying saucer that humans just haven't figured out
> how to fuel quite yet. I believe that fuel comes from widespread adoption
> of domain-based email authentication aka DMARC. The challenge of getting
> the email universe to embrace something like DMARC feels at times
> impossible, but the fact is it just takes a lot of coordination,
> dedication, and consistent levels of exercise to stay sane.
>
> That said, Ale, I like the idea of a Domain Owner being able to share some
> sort of exception list for email flows that are recognized by the Domain
> Owner, but are still (for various reasons) beyond the ability of the Domain
> Owner to address. Something like, "I've got a vendor that will never send
> DMARC-compliant email on my behalf". It appeals to my fondness to be able
> to Just Fix Things without having to bother anyone. I don't think it would
> work, though, because it relies on email receivers having to widely
> implement new stuff, and it relies on Domain Owners accurately maintaining
> another thing. It's easier and more effective to get the vendor to do the
> right thing.
>
> Oh, on 2nd read (I've been consumed with the non-IETF world for a few
> months and only took this up because Ale emailed me at work).. I think
> keying off of "Sender:" is a really bad idea. Multiple policy keys into a
> single piece of email has never made sense.
> Third party authorization makes sense to me in theory as a tool for a very
> specific problem. In practice, people and organizations struggle to get
> first party authorization into place. Once they start to tackle their own
> first party authorization, the need for third party authorization tends to
> evaporate. What's left over? People that want to put together a list of
> authorized third parties but aren't quite ready to do their own first party
> auth?
>
> From a receiver's perspective, it then looks like the first party has no
> idea what it is doing (which is the default anti-spam stance for all
> Internet mail), so then the receiver is now looking at a bunch of factors
> unrelated to first-party auth.. including any third party authorization.
> EG, the receiver notes that the email is authorized by a third-party - a
> newsletter company. "First party" authorization is NOT established, so the
> receiver has to process the email based on the strength of the newsletter
> company's reputation (among other things). So then why bother at all with
> the construct of "third party authorization"?
>
> So I guess put me in the camp of not seeing utility in third party
> authorizations. Better to make the work that needs to be done as clear and
> as simple as possible.
>

I tend to agree with the negative stance on third party auth, but SPF
obviously has the include: statement which is third party auth at the most
basic level...
atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
because it wasn't all that useful, or if it was tied in folks minds to
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage
across thousands of "relays" etc, and I don't think they should be used for
that, but for a bunch of small to medium entities, it could be the thing
that makes higher p= possible.

Brandon

[1] I just looked atps again, but I might have missed something that makes
it less useful
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Mediation (was: Re: Header munging, not ARC, can solve the mailing list problem)

[Brandon Long]

On Fri, Jun 19, 2020 at 12:03 PM Pete Resnick  wrote:

> On 19 Jun 2020, at 13:38, Dave Crocker wrote:
>
> > The description of what a Mediator might do is not incompatible with
> > also viewing it as having characteristics of a publisher:
> >>
> >> ### [5.3](). Mailing
> >> Lists
> >>
> >>
> >>...
> >>In addition to sending the new message to a potentially large
> >> number
> >>of new Recipients, the Mailing List can modify content, for
> >> example,
> >>by deleting attachments, converting the format, and adding
> >> list-
> >>specific comments.
>
> Fair enough, but as you mention below, in the case of the common mailing
> list, the intent is simply to redistribute the message with minimal
> change (hence the retention of the Message-ID: and the From:). That
> said, I do disagree with the reasoning given with regard to why
> 5321.MailFrom has changed: It's not because of the authorship, but
> rather because it is responsible for the submission onto the network,
> just as the ReSender is in 5.2.
>
> > Note that in terms of email transport, it is posting a new message.
>
> Strictly in terms of transport, yes. But in terms of the layer above
> (the 5322 layer), it is usually the same message; see the second Note:
> in RFC 5322 section 3.6.4:
>
>Note: There are many instances when messages are "changed", but
>those changes do not constitute a new instantiation of that
>message, and therefore the message would not get a new message
>identifier.  For example, when messages are introduced into the
>transport system, they are often prepended with additional header
>fields such as trace fields (described in section 3.6.7) and
>resent fields (described in section 3.6.6).  The addition of such
>header fields does not change the identity of the message and
>therefore the original "Message-ID:" field is retained.  In all
>cases, it is the meaning that the sender of the message wishes to
>convey (i.e., whether this is the same message or a different
>message) that determines whether or not the "Message-ID:" field
>changes, not any particular syntactic difference that appears (or
>does not appear) in the message.
>
> > Mediators really have complete freedom to do whatever they want.  If
> > describing the full range of what a publisher might do, it would cover
> > the same range.
>
> Well, "complete freedom" in the sense that no Internet police prevent
> such actions. But for most mediators, large substantive (for interesting
> definitions of "substantive") changes are outside of the scope of their
> definitions, and would probably invite someone to say, "That's not being
> a mediator." Certainly that would happen in the case of an alias or a
> resender.
>

And if we knew how to encode and verify that the mediator sticks to that,
we could
enforce it with policy.

There were several attempts to come up with alternative signing schemes
that would
allow messages to pass through mailing lists and still be verified as
"untampered" with,
and we were unable to come up with such a thing.

Perhaps we could have constrained ourselves to a 80 or 90% solution, and
that would have been
sufficient and a better solution than From header rewriting.  Everyone has
their opinion on the must
haves for mailing list message modification, and it becomes quickly
intractable.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.

[Brandon Long]

So you think we should include
https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in
the actual spec?

Brandon

On Tue, Jun 16, 2020 at 10:26 AM Hector Santos  wrote:

> Hi Brandon, some quick points:
>
> 1) I was 100% concentrating on the technical protocol aspects to make
> DMARC protocol complete. DMARC is currently not protocol complete. It
> does not address the failure scenarios related to 3rd party
> re(signers). It left loopholes that need to be closed.  The
> application aspects for administration is, in my technical view, a
> secondary consideration.  The protocol's framework need to complete.
>
> 2) If you suggest there are existing solutions to fill in the holes,
> then they need to be documented in the DMARC proposed standard.It
> can't be intentional "ignorant" about it.  This ignorance did not work
> with ADSP and it did not work with DMARC.
>
> Based on your comments there would be a total of four methods to
> consider for implementors to offer:
>
> 1) Honor the DMARC policy. No Subscriptions, nor submissions from
> restrictive domains. Gandfather current members from restrictive
> domains as read-only members.
>
> 2) Give DKIM private Key to authorized (re)signer,
>
> 3) Use CNAME to share a key with authorized (re)signer, and
>
> 4) Use ATPS RFC6541
>
> Note, I intentionally left out the horrible rewriting kludge. I would
> not encourage it.  Provide good protocol-complete solutions and
> kludges won't be necessary.
>
>
> Thanks
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
> On 6/15/2020 1:15 PM, Brandon Long wrote:
> > I don't understand what adding authorized third party signatures will
> add.
> >
> > For a corporation, it may be possible to validate and approve a number of
> > third party signers... right now, that's done via DNS by either extending
> > SPF to include the third party, or giving the third party a DKIM key (or
> > better, mapping a key into your domain name space with CNAME)... or even
> > by smarthosting.
> >
> > Any email sending vendor has to support this at this point.  However,
> this
> > doesn't handle the external mailing list case, or at best it works with
> just
> > the largest providers or some limited number of lists, but I doubt our
> > security department would approve some random open source list to send
> mail
> > as the company.
> >
> > For a large mailbox provider, the set of potential third party vendors is
> > very large, and would require an extensive vetting process to make it
> work,
> > and even then, you've opened it up to security issues at the weakest
> link.
> > This is basically Google's OAUTH API Verification process with estimates
> > that the vendor security audit cost of $15-75k... and still wouldn't
> handle
> > small mailing list providers.
> >
> > The reason third party signatures don't work for mailing lists is because
> > they are a relay, not an origination service, and fundamentally third
> party
> > signatures only work with origination services.
> >
> > One could say that the third party auth problem is the same with ARC, but
> > there are two major differences.  For one, the question of whether to
> > accept an ARC hop as valid is on the receiver, not the sender, which
> allows
> > it to work with relays which are more known to the receiver than the
> sender.
> > For two, ARC is saying something very different.  Third party auth is
> > saying "this service can act as me" while ARC is saying "this service
> > relayed the message
> > without substantive changes".  It remains to be seen whether ARC is
> > successful at this, of course.
> >
> > So, at best, third party auth for DKIM wil be a "new" way of giving a
> > service access that no one will support for a long time, while there are
> > existing
> > mechanisms which work today for that.
> >
> > Brandon
> >
> > On Sun, Jun 14, 2020 at 10:23 AM Hector Santos  > 40isdg@dmarc.ietf.org> wrote:
> >
> >> When we look at DKIM and the DMARC protocol by exposing the boundary
> >> conditions of the protocol, it helps with laying the groundwork for a
> >> protocol-complete model.
> >>
> >> DKIM has three possible signature states:
> >>
> >> - NONE (no valid signature)
> >> - 1PS (1st party valid signature, Author.domain == Signer.domain)
> >> - 3PS (3rd party valid signature, Author.domain != Signer.domain)
> >>
> >> DMARC has thre

Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem

[Brandon Long]

On Mon, Jun 15, 2020 at 11:01 PM Murray S. Kucherawy 
wrote:

> On Sun, Jun 14, 2020 at 7:09 AM  wrote:
> > Thanks for you honesty. Then the relevant question is whether open and
> > interoperable standards still matter, or if they should be replaced by
> > proprietary web apps one feature at a time.
>
> Both have been around for a long time now and I've seen no evidence
> that the Internet public at large is keen to make such a wholesale
> migration.
>
> We apparently really, really like our mailing lists.
>

I for one am always amazed how much people use web forums, which are almost
all universally worse at providing a reading interface or keeping people
up-to-date on new messages... which might be why most of the one's I look
at are nearly dead, maybe there are better ones that are active.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Definition of "value" in RFC8601

[Brandon Long]

On Wed, Apr 1, 2020 at 5:32 PM John Levine  wrote:

> In article <6b4c7533-ebee-796b-e00e-a2bb40750...@arcsin.de> you write:
> >To decide for an authserv-id whether to pull sub-domain from 5321 or
> >6531, one needs to know if the message is internationalized. But to
> >obtain that information, one must have parsed all message header fields,
> >per 6531 sec 3.6, including A-R, that is still waiting to be parsed.
>
> In systems that keep ASCII and EAI mail separate, that info will be in
> the metadata, whether it arrived in an SMTP session with the SMTPUTF8
> option.
>

Does anyone implement it that way?

We just upgraded our parser to handle EAI mail, and the parser returns
requested data
in UTF8, decoding 5322 mail or going straight from 6532 mail as necessary,
with
specific accessors needing to know what the possible encodings could be.
We then check
when we go to send mail whether we should specify SMTPUTF8 on the output..
as for input...

We see plenty of mail transferred without SMTPUTF8 that contains UTF8 (or
other
8-bit characters, but the majority of that became UTF8 probably close to a
decade ago), and we
just handle it.

Unfortunately, everybody thinks they can just make their own emali messages
because its a text-like
format, and they're very often wrong.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Question regarding RFC 8617

[Brandon Long]

Yes, its for checking whether a custodian made changes, but the changes its
checking for are the core of the message (to use the DKIM wording), the
same as DKIM.

If the core of the message was unchanged, then ARC is unnecessary.  The
utility of ARC is to pinpoint where the core was changed, so the receiver
can make a
judgement as to how to handle the message.

Brandon

On Thu, Nov 7, 2019 at 8:45 AM Weist, Bill  wrote:

> Thank you both for replying.  There are two instances where I have
> identified ARC signatures consistently failing:
>
>
>
> Case 1:  An intermediary SMTP system receives an email on behalf of a
> recipient system whereby the “from” field is required to be changed for the
> email to reply as desired by the recipient system.  (example:
> william.we...@gmail.com rewritten to william.we...@iqvia.com)
>
>
>
> Case 2: An Intermediary SMTP system receives an email on behalf of the
> recipient system whereby the “subject” field is required to by changed for
> the email to be categorized as desired by the recipient system. (example:
> “RE: [dmarc-ietf] Question regarding RFC 8617” modified to:  “RFC
> Correspondence: [dmarc-ietf] Question regarding RFC 8617”)
>
>
>
> As Kurt pointed out below, the ARC signature is NOT intended to be
> validated by hops >1 step away.  However, I did not think this was the case
> and that ARC was specifically supposed to validate each custodian where
> DKIM would be broken by the cases listed above.
>
>
>
> As differentiated from DKIM, the RFC reads as if ARC is designed to
> validate the “custodian” and NOT the “sender” therefore, “From” and
> “Subject” would not be as desirable as say “X-Received”,
> “X-Google-Smtp-Source”, and “X-Gm-Message-State” in the case of Brandon’s
> email to which I am replying.
>
>
>
> It is my suggestion that for ARC to be a valuable addition to DKIM, it
> needs to focus on the “custodian” and not the “sender”.
>
>
>
> Thank you both for your time and attention.
>
> -Bill
>
>
>
> *From:* Brandon Long 
> *Sent:* Wednesday, November 6, 2019 12:43 PM
> *To:* Kurt Andersen (b) 
> *Cc:* Weist, Bill ; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] Question regarding RFC 8617
>
>
>
> This email originated from outside of the organization.
>
>
>
> What's more, the point of including Subject and other mutable headers is
> the same as it is for DKIM, those are the headers which are important to
> the receiver, so they should be validated.
>
> As Kurt points out, the point of ARC is to acknowledge these changes hop
> to hop, and the Arc Seal proves who did the change, the question becomes do
> you believe
>
> the person who changed it wasn't malicious.
>
>
>
> Brandon
>
>
>
> On Wed, Nov 6, 2019 at 7:37 AM Kurt Andersen (b)  wrote:
>
> The choice of which headers are included in the signed set is strictly up
> to the domain administrators who implement the signing practices. Also, the
> AMS is only relevant for the next receiver, it is not intended to be
> validated by hops >1 step away from the domain which adds that instance so
> I don't see how mutability would matter.
>
>
>
> --Kurt Andersen
>
>
>
> On Wed, Nov 6, 2019 at 7:30 AM Weist, Bill 
> wrote:
>
> DOI:  10.17487/RFC8617
>
>
>
> The inclusion of the address headers in the signature, and possibly the
> Subject, is an issue:
>
>
>
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
> microsoft.com
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com=02%7C01%7CWilliam.Weist%40iqvia.com%7C3c6685ae55144287801808d762e0daa5%7C5989ece0f90e40bf9c791a7beccdb861%7C1%7C0%7C637086590191460908=KyZ7aC4X35IcojTOEbgeDFXnOPPSHvlt8RaqH8VtXpA%3D=0>;
> s=arcselector9901; 
> h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
> bh=;
>
>
>
> If a downstream server needs to modify either of these two values, the
> signature check fails.
>
>
>
> It is my understanding that the Authenticated Received Check signature is
> to validate the chain of possession.  As such, in my opinion, the signature
> should only include immutable references.
>
>
>
> In my opinion, there is value in NOT requiring headers to be stripped by
> downstream servers, thus maintaining the custody chain from origination to
> destination.
>
>
>
> Thank you for your time and attention,
>
>
>
> *William M. Weist*
>
> *Enterprise Architect I – Global Messaging – Mobile and Presence*
>
> CIO Team – End User Computing
>
> *[image: IQVIA logo_96dpi_100pxheight]*
>
> Learn more
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2

Re: [dmarc-ietf] New proposed wording for p=quarantiine

[Brandon Long]

On Sat, Aug 10, 2019 at 1:44 AM Дилян Палаузов
 wrote:
>
> Hello,
>
> to the idea to amend the existing definition of p=:
>
>   quarantine:  The Domain Owner wishes to have email that fails the
>  DMARC mechanism check be treated by Mail Receivers as
>  suspicious.  Depending on the capabilities of the Mail
>  Receiver, this can mean "place into spam folder", "scrutinize
>  with additional intensity", and/or "flag as suspicious".
>
> the text “
>
> The Domain Owner wishes in addition, that the sender of messages failing 
> DMARC are notified about the suspicious
> handling with an appropriate rejection message.  Senders not willing to be 
> notified that their message is suspicious,
> shall use the NOTIFY=NEVER service extension.
>
> In the past, Domain Owner could express as wish either to reject or to 
> quarantine.  Considering that from the options:
> only reject; only qurantine; and quarantine, while notifying the sender about 
> the suspicious handling of the message;
> nobody will choose only to quarantine, the interpretation of what the Domain 
> Owner wishes by publishing quarantine was
> changed to include the rejection component.”
>
> so far two voices were against.  The reasoning against the amendment is that 
> writing what the domain owner wants is just
> its preference, not anything binding, and the current definition is 
> sufficient.
>
> My motivation in favour the amendment is, that currently nobody has the 
> practice to quarantine messages and inform the
> sender of the special delivery status at the same time.   Spelling more 
> precisely what the domain owner wants will
> suggest the implementations to implement precisely that preference.

It's not standard, but Google does add a string DMARC:QUARANTINE to
our 250 response to DATA for messages that policy
evaluated to quarantine.  I'm not sure anyone ever noticed, of course.
We've been doing it since 2012.

I'm not agreeing with the amendment, merely pointing this out.

Sender notifications would have to be one of:
1) Something like Google does, some 2xx response that contains extra
information the sending server would have to act on (which
becomes challenging in forwarding situations)
2) A 5xx response but also accept the message so a DSN is generated by
the sending (maybe intermediary) server. While I'm sure plenty of
servers
already do something like this at least for honeypots, this seems like
a twisting of the standards.
3) A 2xx response, accept the message, and the receiver generating a
DSN.  This has the obvious typical backscatter issue.

So, I can see why our implementor chose #1, but also the low utility of it.

Brandon

>
> With other words, the sole reason why a receiving host does not notify the 
> sender for quarintined message might be, that
> the receiving site has not come to this idea.  The additional text removes 
> the cause.
>
> If there was a common practice by now to deliver as junk and reject with 
> appropriate text at SMTP level, then the
> amendment would have been less necessary.
>
> Regards
>   Дилян
>
>
>
>
>
>
> On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote:
> > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman  
> > wrote:
> > > Policy is an indication of sender preference, not a directive the 
> > > receiver must follow.  I think the definition is fine.  If the sender 
> > > prefers failing messages be quarantined, then they should use that 
> > > policy.  They won't get what they want in all cases and that's fine.
> >
> > This matches my understanding.
> >
> > -MSK
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

[Brandon Long]

Currently, we don't do anything with failed chains short of keeping stats.
Everything we've used the chain for so far has been from passing chains.

That said, we still only trust our own chain elements, we haven't seen wide
enough adoption to spend much effort on interpreting chains which
involve multiple parties.

Brandon

On Fri, Aug 3, 2018 at 10:54 AM John R Levine  wrote:

> > I know I lost the argument on cv (I think cv is entirely superfluous and
> > there's no point adding/signing a cv=fail header), but it seems the
> > argument for that is more data.  That said, this "either or" signing set
> > thing on cv=fail seems pretty cumbersome.
>
> You guys have looked at as many ARC signatures as anyone.  Once the chain
> has a cv=fail do you learn anything useful from further seals?
>
> R's,
> John
>
> >> In 5.2, oldest pass is confusing, since it doesn't tell you whether
> >> the validation succeeds or not.  I would take out steps 5-7 and add
> >> something to the INFORMATIONAL at the end like "A validator can check
> >> the AMS headers to estimate when in a chain of forwards the message
> >> was modified."
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] WGLC ARC-16 concern on Section 5.1.2 - cv=fail should sign greedily

[Brandon Long]

I know I lost the argument on cv (I think cv is entirely superfluous and
there's no point adding/signing a cv=fail header), but it seems the
argument for that is more data.  That said, this "either or" signing set
thing on cv=fail seems pretty cumbersome.

Brandon

On Mon, Jul 30, 2018 at 5:42 PM John R Levine  wrote:

> > The working group considered cv=invalid last year, but there was strong
> > consensus was against it. The guidance for Sealing cv=invalid Chains
> > somehow made it into this draft applied to all cv=fail Chains. All Chains
> > should be Sealed in the same fashion (your AS covers the ARC Set you've
> > added and all previous ARC Sets), unless the Chain is invalid in which
> case
> > you only Seal your own ARC Set.
>
> Ah.  Perhaps reword 5.1.1 like this:
>
> The signature of an AS header field signs a specific canonicalized
> form of the ARC Set header values, when all of the previous ARC sets
> are valid. In that case, the ARC set header values are supplied to the
> hash function in increasing instance order, starting at 1, and include
> the ARC Set being added at the time of Sealing the message.  If any of
> the existing sets are invalid, the AS header field only signs its own
> ARC Set.
>
> Within an ARC Set, header fields are supplied to the hash function in the
> following order:
>
> 1. ARC-Authentication-Results
> 2. ARC-Message-Signature
> 3. ARC-Seal
>
> The ARC-Seal is generated in a manner similar to when DKIM-Signatures
> are added to messages ([RFC6376], section 3.7).
>
>
> In 5.1.2:
>
> In the case of a failed Authenticated Received Chain, the header
> fields included in the signature scope of the AS header field b= value
> MUST only include the ARC Set headers in the newly created set, as if
> this newest ARC Set was the only set present.
>
>
> In 5.2, oldest pass is confusing, since it doesn't tell you whether
> the validation succeeds or not.  I would take out steps 5-7 and add
> something to the INFORMATIONAL at the end like "A validator can check
> the AMS headers to estimate when in a chain of forwards the message
> was modified."
>
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Brandon Long]

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 says you have to delete
> stuff that's clearly a forgery.
>
>
> I didn't go back and check the wording used in 7601 obviously. I was
> inferring from the language in 4.1.2, "are likely to be deleted".
>

Right, basically an ADMD right now has to delete any existing A-R field
that claims to be the ADMD in order to prevent forgery.  If you added it to
the signature and added an instance variable, you don't need to do that
anymore, but you may still run afoul of other software that is deleting
them.

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 not there, but that's not what
we're seeing in practice).  Earlier instances of the AMS are expected to
fail if the message content is changed and for that to be fine.

We did spend a bunch of time, maybe before it even came to the IETF,
exploring whether we could do this without having a separate set of header
fields, and we decided no.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0

[Brandon Long]

On Mon, Apr 16, 2018 at 11:01 AM Alessandro Vesely <ves...@tana.it> wrote:

> On Wed 11/Apr/2018 04:35:54 +0200 Scott Kitterman wrote:
> > On Tuesday, April 10, 2018 11:48:48 PM Brandon Long wrote:
> >>
> >> Well, obviously there is some difference in handling of p=quarantine and
> >> p=none ;)
> >>
> >> I guess the question is, in terms of forwarders, should they handle
> those
> >> differently or not.  I'm not sure how many are p=none vs p=quarantine
> vs no
> >> dmarc (I could look at our mail flow for some numbers, but some others
> on
> >> the list may have better numbers), but if a lot are at p=none, things
> will
> >> be yucky if it changes.  Ie, right now,
> gmail.com/hotmail.com/outlook.com
> >> are all p=none, so changing Groups or mailman for p=none will affect a
> lot
> >> of folks.
> >
> > I'd have to rethink if p=none was really worth publishing if that
> happened.  I
> > guess we'd need p=none-really then.
>
> Given that From: rewriting is the de-facto standard, this WG should
> publish an
> RFC about that, including recommendations and caveats about how to do it.
>
> Its Security Considerations, for example, should mention cases like, say:
>
> From: The POTUS via phishing-attempt <obsc...@phisherman.example.com>
> X-Original-From: The POTUS <po...@whitehouse.gov>
>
>
> For a personal opinion, I don't know what is the purpose of having GG
> rewrite
> From:'s of a given domain.  Perhaps, it is to let users participate to
> groups
> without revealing their real addresses to spammers.  That sounds
> legitimate to
> me...
>

Do you mean, that user's don't understand why some are rewritten and some
aren't?

That's definitely true, and an interesting question as to whether Groups
should always rewrite.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

[Brandon Long]

Hmm, I guess this means the set of required/optional fields now stretches
between the DKIM and ARC specs, eh?

Is t the only one that's now optional?

For Seal, I have i, a, s, d, b, cv (removed t based on this thread)
For AMS, I have i, a, s, c, d, d, b, h, bh

Brandon

On Tue, Apr 3, 2018 at 4:05 PM Kurt Andersen (b)  wrote:

> Please implement -13, but there are almost no protocol changes between -6
> and -13. It's mostly editorial. We may have made some tags optional but if
> Google wants 'em, it's probably best to include them, but that doesn't mean
> you aren't implementing -13.
>
> --Kurt
>
> On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris  wrote:
>
>> On 21/03/18 15:18, Murray S. Kucherawy wrote:
>> > On Wed, Mar 21, 2018 at 3:00 PM,  wrote:
>> >
>> >> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt
>> >> has been successfully submitted by Kurt Andersen and posted to the
>> >> IETF repository.
>>
>> I see that Google are still listed as implementing Version 6 -
>> and indeed, if you don't supply a t= tag in the AS (which is not
>> required, as far as I can find in Version 13) then gmail.com says:
>>
>>   "arc=fail (missing mandatory fields);"
>>
>> in it's A-R.
>>
>> Which should I implement?
>> De-jure, or de-facto (and too-big-to-fail)?
>>
>> --
>> Cheers,
>>   Jeremy
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] "next steps?"

[Brandon Long]

On Wed, Mar 14, 2018 at 2:37 PM Brandon Long <bl...@google.com> wrote:

>
>
>
> On Tue, Mar 13, 2018 at 3:44 PM Hector Santos <hsan...@isdg.net> wrote:
>
>> >>
>> >>  One would be a spec revision to deal with ARC.  Does DMARC
>> >> still 'fail'?  Yet the whole point of ARC is to create the
>> >> possibility of still getting delivered, in spite of this.
>> >
>> > My position on this is that the decision by a validator/mailbox
>> > provider to use ARC and accept mail that would otherwise fail DMARC
>> > falls under the heading of "local policy". There does not need to be a
>> > spec revision to deal with ARC from this perspective. A sending domain
>> > publishing a DMARC policy is expressing it's wishes, not making
>> > demands (it cannot enforce). This is true with respect to any local
>> > policy a validator/mailbox provider implements.
>> >
>>
>> If a domain publishes a "p=reject/quarantine" (restrictive policy),
>> the published intent and expectation is to reject or quarantine
>> failures.   If the receiver wishes to further relax how it handles
>> failures, that would be a specific local policy, not "general policy."
>>   Overall, the protocol intent is to Reject/Quarantine.
>>
>> The ARC question is how does ARC change this existing
>> "psuedo-standard" protocol logic?
>>
>> I prefer an explicit DMARC extended tag (or a author domain ARC seal)
>> that publishes the domain intent to use ARC to relax "some"
>> p=reject/quarantine failure in some fashion which is not defined at
>> the moment.  The preference is to remove/reduce receiver ambiguity of
>> what is to be expected when DKIM/DMARC is augmented with the ARC.
>>
>
> I still object to this concept on the same basis as the last two times we
> had this discussion.
>
> Brandon
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-11.txt

[Brandon Long]

I sometimes override DMARC p=quarantine failures with filters, does DMARC
require a filters extended tag and compliance by mail clients to not allow
overriding of the filters if the domain requests it?

My point is, fundamentally in the mail eco-system, whether something is
delivered or rejected or labeled as spam is at the discretion of the
receiver.  Having increasing levels of "but I really mean it" for DMARC is
not useful.

Also, the sender doesn't implement ARC, so why should they care?

Also, I think some of this already happens today based on reports.  We get
complaints about where we override DMARC from domains all the time, and
that goes into our work on making our overrides more correct.  I don't see
how arc=n helps that at all.  If you wanted to help that, you'd want some
mechanism or automation with which a domain owner could tell a particular
mailbox provider that they're doing a bad job, and that's a lot more
complicated than arc=n.

Brandon


On Wed, Jan 24, 2018 at 7:53 AM Hector Santos <hsan...@isdg.net> wrote:

> Quick review note:
>
> The draft introduction talks about the "False Positive" problem with
> restrictive DMARC policies -- the reason why we are here.
>
> We need to keep in mind, DMARC also comes with "True Positives" DMARC
> failures as well.  DMARC Author Domains who will either be ignorant
> (unaware of ARC) and/or does not wish to implement it (yet) and expect
> all DMARC failed messages to be handled according (rejects/quarantine)
> by receivers.  This is expected to be especially true during the
> experimentation and migration to support period.  We are here because
> of the reject/quarantine problem. People are not going to just stop
> processing this filter until ARC proves itself.
>
> For easier plug and play logic, the compliant ARC Receivers will need
> a signal from the DMARC Author Domain that ARC can/should be applied
> when DMARC failures.   I suggest a new ARC section for an DMARC
> extended tag, "arc=" and/or using the first Author Domain created ARC
> header to signal ARC compliance.
>
> For the DMARC Extended Tag (throwing it out there):
>
> arc=0 ARC not expected to preempt failures (default)
>
> arc=1 The Original Domain signs with ARC, not required
>   if author domain is the first seal.
>
> arc=y The Original Domain MAY NOT sign with ARC but
>   others can to forward failed messages.
>
> Something like the above to convey the various possibilities the
> DMARC/ARC will mostly be encountering which will basically be:
>
>if DMARC fails
>{
>   //==
>   // NEW!  Added ARC Policy support
>   //==
>   if Mail.Headers["ARC-Seal"].domain == AuthorDomain
>  or DMARC.Tags["arc"] != "0"
>   {
>  Add ARC seals/headers
>  return SUCCESS;
>   }
>   //==
>   Fail the message
>   return FAILURE;
>}
>
> Thanks
>
>
> On 1/22/2018 5:47 PM, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
> >
> >  Title   : Authenticated Received Chain (ARC) Protocol
> >  Authors : Kurt Andersen
> >Brandon Long
> >Steven Jones
> >Seth Blank
> >Murray Kucherawy
> >   Filename: draft-ietf-dmarc-arc-protocol-11.txt
> >   Pages   : 54
> >   Date: 2018-01-22
> >
> > Abstract:
> > The Authenticated Received Chain (ARC) protocol creates a mechanism
> > whereby a series of handlers of an email message can conduct
> > authentication of the email message as it passes among them on the
> > way to its destination, and record the status of that authentication
> > at each step along the handling path, for use by the final recipient
> > in making choices about the disposition of the message.  Changes in
> > the message that might break DKIM or DMARC can be identified through
> > the ARC set of header fields.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-11
> > https://datatracker.ietf.org/doc/ht

Re: [dmarc-ietf] Algorithm rotation, New drafts of ARC protocol (10) & usage (03) posted

[Brandon Long]

On Thu, Dec 21, 2017 at 9:23 AM Seth Blank  wrote:

> On Thu, Dec 21, 2017 at 8:57 AM, John Levine  wrote:
>
>> 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.
>>
>
> Is there any appetite in the group to handle rotation in a separate
> document?
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Brandon Long]

On Wed, Dec 20, 2017 at 11:40 AM Murray S. Kucherawy 
wrote:

> On Tue, Dec 19, 2017 at 6:49 AM, Kurt Andersen (b) 
> wrote:
>
>> * 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;
>>
>
> I plan to start a 7601bis effort to support what ARC needs, possibly over
> the holidays, certainly in time for IETF 101.
>
> 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.
>>
>
> 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?
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC draft-08 updates to section 5.1 and WG questions

[Brandon Long]

And again from the right address, sigh.

Brandon


On Fri, Dec 1, 2017 at 2:10 PM Brandon Long <bl...@google.com> wrote:

>
>
>
> On Thu, Nov 30, 2017 at 11:38 PM Murray S. Kucherawy <superu...@gmail.com>
> wrote:
>
>> On Tue, Sep 5, 2017 at 2:52 PM, Seth Blank <s...@sethblank.com> wrote:
>>
>>> Replace 5.1.1 with:
>>>
>>> 5.1.1. ptypes and properties for arc-info
>>>
>>> Certain information pertinent to ascertaining message disposition can be
>>> lost in transit when messages are handled by intermediaries. For example,
>>> failing DKIM signatures are sometimes removed by MTAs, and most DKIM
>>> signature on messages modified by intermediaries will fail. Therefore, a
>>> passing DKIM-Signature from the first ARC signer is likely to have been
>>> removed by final receipt of the message.
>>>
>>> The AAR, and in particular the ptype-properties stamped in arc-info,
>>> provide a mechanism for this information to survive transit.
>>>
>>> The ptypes and properties defined in this section SHOULD be stamped in
>>> the AAR:
>>>
>>> * smtp.client_id - The connecting client IP address from which the
>>> message is received;
>>> * header.ds - The domain/selector pair for each dkim signature on the
>>> message (header.ds=example.com,selector)
>>> * arc.closest_fail - The hop number of the most recent AMS that fails to
>>> validate, or 0 if all hops pass.
>>>
>>
>> Why "client_id" instead of "client-ip"?  (it's an IP address, not some
>> opaque identifier)
>>
>
> agreed on ip instead of id.
>
> Why "header.ds" and not "header.d" and "header.s"?  (why combine them?)
>>
>
> agreed on not combining things like this, sure string.split is easy and
> all, but let's use the parsing/etc we already have.
>
> Brandon
>
> Why "arc.closest_fail" and not "arc.closest-fail"?  (use a hyphen, to be
>> consistent with other entries already in the registry)
>>
>> Unless someone wants to point me at the part of the spec that says
>> otherwise, the IP address is utterly orthogonal to anything ARC is doing.
>> I'd rather not shoe-horn it in here, even if DMARC operators might want
>> it.  Rather, we should do a separate document (outside this WG if needed)
>> that registers a header field for this, since there's been something like
>> X-Original-IP in public use for years anyway, and then just require that it
>> be signed or something.  Or if we really want it in A-R, register it
>> accordingly, independent of ARC.
>>
>> But if we want to do that last thing, I'd like to have some sort of
>> discussion on the record for changing the scope of A-R, which is really
>> what we're talking about here.  As I've said before, A-R's original purpose
>> was to collect data about authentication work done at the ingress MTA that
>> might be of interest to users or filters.  We've specifically kept things
>> like IP addresses unregistered on the basis that your average human won't
>> know whether to trust one string of octets over another, and there's a
>> treatise in the appendix of RFC7601 and all of its predecessors that lays
>> out why.  But that's the logic we applied eight years ago when RFC5451 was
>> written.  If in the intervening time we've decided we want to repurpose it
>> to carry arbitrary stuff that might be of benefit to filters and concede
>> that users aren't the likely primary consumers as we intended, then we
>> should probably do up an RFC7601bis that says so, and renovate the prose
>> and registries accordingly.  I'll put the editing work in, but there has to
>> be recorded consensus to back that move.
>>
>
+1 to 7601bis on Kurt's terms.


>
>> ===
>>>
>>> Open questions:
>>>
>>> 1) The optimal ABNF for AAR would inherit the A-R payload ABNF from
>>> 7601. Unfortunately, authres-header was defined in a way that makes this
>>> difficult. Is there a better way to say that the AAR inherits the A-R
>>> payload, and if anything modifies the definition of authres-header in 7601,
>>> the AAR also needs to inherit this change?
>>>
>>> To be super specific, this is the current authres-header ABNF from 7601:
>>>
>>>  authres-header = "Authentication-Results:" [CFWS] authserv-id
>>>   [ CFWS authres-version ]
>>>   ( no-result / 1*resinfo ) [CFWS] CRLF
>>>
>>> Optimally, there would be:
&

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

[Brandon Long]

On Tue, Sep 26, 2017 at 3:58 PM, John Levine  wrote:

> In article <59c8d406.7000...@openfortress.nl> you write:
> >I am looking forward to your responses.  Please keep me in Cc: if
> possible?
>
> I hate to be totally negative, but this draft revives a lot of things
> that we considered and rejected when we did DKIM.
>
> Marking content in an MUA is a WKBI*.  There is no reason to believe
> that users would understand content marking or would make reasonable
> decisions based on it.  As a general rule, anything that puts security
> policy in the hands of end users doesn't work.  Think of all the
> browser bad SSL cert warnings you've clicked through.
>

Knowing what changed is actually something that could go into a spam filter
decision, however.

It may be more complicated than arc.  And we did have an example proposal
that foundered on the deletion case.

https://www.ietf.org/mail-archive/web/dmarc/current/msg01444.html

One could also make a spam/phishing decision and show the original, forcing
the user to click to see the modified version.  In most mailing list cases,
the subject/footer is mostly barely useful (quick, does this mailing list
have a footer?).  Ie, one could spam score both the original and the
modified version, and make choices based on the difference.


> Also, there are more ways to change content that anyone can describe.
> Some of the harder to describe are recoding between 7 and 8 bit and
> base64, reducing the size and resolution of images (common on phones)
> and reordering MIME parts.
>

There is an obvious question of "handles everything" vs "handles the
99-percentile case better".

Ie, a mechanism that explicitly handled subject prefixes and footers might
do a better job than ARC, it might have better adoption and fewer
deployment headaches, even as it allows some set of modifications to fail.
It might also be harder to

Also, among what you're talking about, I think the 7/8/base64 stuff would
be covered by his MIME canonicalization.  Although I've seen web proxies or
clients which resize photos, I don't think I've ever seen an MTA do it...
which doesn't mean they couldn't, but I'm not sure it's a use case we have
to try and handle.

Ie, I would have been happy to have changed Google Groups to allow DKIM
signed mail to pass through, but we feel that current anti-spam laws mean
we have to include an unsub link.  We would have routed out any of the
other types of changes you're talking about because DKIM passing to get the
mail through is more important.

Finally, it is pretty clear from the ARC work that big mail systems
> are more interested in telling recipient systems the identities of the
> parties that handled a message than how it changed or whether any of
> those parties thought the changes were a good idea.
>

Google was the one with the previous diff based proposal, I would have been
happy to avoid the "who" question if we could have
done something more exact.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Lenient DKIM (new Internet Draft)

[Brandon Long]

This is an interesting sketch, but it doesn't  include the hard parts, so
it's hard to know if it can provide what is needed.  For example, will the
rolling hash allow for exact boundaries of changes to be determined?
Subjects are pretty short, how does a rolling hash handle that?  I'm not
familiar with rolling hashes, so perhaps my questions are naive.

The mime body canonicalization is odd, what percentage of mail isn't
multipart at this point?  It also requires that mime canonicalization
requires impl of this other spec, which seems more v2ish, though maybe not
in formatting.

I'd say the mime header canonicalization doesn't go far enough.  For
example, most mailing lists that are i18n aware are going to decode rfc2047
subjects before adding a subject prefix, and then reencode, which may not
be in the same charset, especially if the prefix and subject are in
different languages.  Another issue we see is in optional things, such as
quoting in address and parameter headers.  Defining a canonical form for
those headers might be necessary to accomplish what you want.  There's also
smtputf8 downgrades, which would imply taking a utf8 nonencoded subject and
encoding it.  It's also useful if your system uses a non rfc822 format
internally and only gateways to the internet.

I think a proper mime canonicalization would be useful on it's own, we've
talked about it before internally here at Google.

I believe that we discussed something similar to this early on this list,
but the challenge is in the details.

Brandon


On Sep 25, 2017 3:02 AM, "Rick van Rein"  wrote:

> Hello DKIM/DMARC list,
>
> I would like to propose a method for "fixing" the real-world problems
> that currently break DKIM.  I am aware of the work on ARC, but in
> comparison this appriach:
>
>  1. is much simpler, with a simple cryptographic foundation
>  2. works without explicit support from message-modifying intermediates
>  3. locates message parts that have changed [within practical bounds]
>  4. allows training on acceptable changes for given senders/intermediates
>  5. pins down rogue senders/intermediates more accurately
>
> The idea isn't completely worked out yet, but the approach should be
> crystal clear from the current text.  I believe that this leads to
> better email user experiences than possible with ARC.
>
> I am looking forward to your responses.  Please keep me in Cc: if possible?
>
>
> Best wishes,
>
> Rick van Rein
> ARPA2.net / InternetWide.org
> > *From:* internet-dra...@ietf.org
> > *Date:* 25 September 2017 at 11:49
> > *To:* "Rick van Rein" 
> > *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00.
> txt
> > A new version of I-D, draft-vanrein-dkim-lenient-00.txt
> > has been successfully submitted by Rick van Rein and posted to the
> > IETF repository.
> >
> > Name: draft-vanrein-dkim-lenient
> > Revision: 00
> > Title:Lenient DKIM
> > Document date:2017-09-25
> > Group:Individual Submission
> > Pages:7
> > URL:https://www.ietf.org/internet-drafts/draft-vanrein-dkim-
> lenient-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-vanrein-dkim-
> lenient/
> > Htmlized:   https://tools.ietf.org/html/
> draft-vanrein-dkim-lenient-00
> > Htmlized:   https://datatracker.ietf.org/
> doc/html/draft-vanrein-dkim-lenient-00
> >
> >
> > Abstract:
> >DKIM is a framework for signed messages, especially for email.  While
> >in transit, changes are sometimes made, and these break the DKIM-
> >Signature.  This specification makes DKIM more lenient, without
> >changes to its core.  It adds leniency towards MIME body rewrites,
> >removal of alternatives and annotation with bits of text.  The
> >intention is to allow these changes such that they can be clearly
> >shown to the user, while indicating that the remainder of the
> >signedmessage is still in tact.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Google and ARC status

[Brandon Long]

And again from my non-Google account, hoping I didn't get people kicked off
the list again

On Tue, Sep 19, 2017 at 2:56 PM, Brandon Long <bl...@google.com> wrote:

> Google is now using ARC results for local policy DMARC passes.  This
> should be visible in your DMARC rua reports as "arc=pass" in the local
> policy comment field.
>
> This should replace most instances in your reports of xoar=pass.  There
> are still some cases where xoar passes and arc does not, mostly because
> xoar is always the last hop and replaces any existing one, so it works in
> cases where the arc chain breaks.
>
> Ie, arc would need the ability to restart broken chains to be equivalent,
> though it's not clear that the extra covered cases would be that useful,
> definitely edge cases.
>
> If/when some other major sites like ietf.org enable arc signing, we can
> add them to the whitelist.
>
> Automated trust is going to require a larger rollout to be effective, and
> we haven't started working on that yet.
>
> Brandon
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Google and ARC status

[Brandon Long]

Google is now using ARC results for local policy DMARC passes.  This should
be visible in your DMARC rua reports as "arc=pass" in the local policy
comment field.

This should replace most instances in your reports of xoar=pass.  There are
still some cases where xoar passes and arc does not, mostly because xoar is
always the last hop and replaces any existing one, so it works in cases
where the arc chain breaks.

Ie, arc would need the ability to restart broken chains to be equivalent,
though it's not clear that the extra covered cases would be that useful,
definitely edge cases.

If/when some other major sites like ietf.org enable arc signing, we can add
them to the whitelist.

Automated trust is going to require a larger rollout to be effective, and
we haven't started working on that yet.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC draft-08 spec section 9.4

[Brandon Long]

On Tue, Sep 5, 2017 at 3:34 PM, Seth Blank  wrote:

> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-9.4
>
> There was an earlier thread about the proper way to handle this (
> https://mailarchive.ietf.org/arch/msg/dmarc/Mz3xIgdB_OuBUqt9OlaZ9_feUpI).
>
> I want to suggest a different direction:
>
> Section 9.4 should be removed in its entirety.
>
> Returning a 421 tempfail is a bad idea for several operational and
> security reasons:
> - it can create generate backscatter
>

more so than a dmarc failure would?


> - one could craft a legitimately ARC signed message and then pull DNS
> records resulting in a 421 ddos ping-ponging amongst intermediaries
>
> But more importantly, because of the nature of how ARC works and mail
> servers function, there is no way to handle temporary failures cleanly,
> especially because (as per the thread I linked to) sometimes delivering a
> message with arc=fail is better than tossing it back (for instance, when
> dmarc still passes on final receipt, and you'd otherwise by impeding a
> legitimate message).
>

I think arc=tempfail is a valid input to the DMARC decision, and I think
it's a good idea for DMARC to upgrade a REJECT to a temp failure based on
temp failure of any inputs.

As a datapoint, we've upgraded 1.3% of REJECTs in the past week to temp
failures, which "fixes" more DMARC false positives than we expect ARC to do
(mostly because of the incremental benefit of ARC over our current XOAR
scheme).

I'm unclear if there is any benefit for this being in the ARC spec,
however.  It would appear to be a useful addition to the DMARC spec or
useful in a BCP for either.


> If anything, section 9.4 should state that all temporary failures are
> permanent ARC failures. Messages in this situation MUST be capped with
> cv=fail and passed along upstream. Stamping the A-R prior to sealing with
> arc=tempfail could be quite valuable to upstream receivers, but doesn't
> change the fact that the chain is dead.
>

I pointed this out before, but this is potentially another case where
participating in the chain is worse than non-participation.

If the status of a hop's arc verification is tempfail, not participating
means if you are a non-modifying hop, the next hop may be able to verify
the chain.  Capping the chain as a failure prevents that.

Yes, yes, a DNS failure for one hop is likely to be a failure at the next
hop as well, since the hops are temporally similar, and although I say
there's always another hop, statistically, we're already talking about the
second hop here, and the number goes down quickly from there.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] About "non-rewindable crypto"

[Brandon Long]

On Sun, Aug 20, 2017 at 6:25 PM, Bron Gondwana 
wrote:
>
> Right - so how exactly does that help, given that you've modified the
> message since then?  You could easily change the message-id at the same
> time.  If the original DKIM-Signature still passes then sure, you can't
> modify anything.  But then you don't need ARC anyway.
>
> If the DKIM signature allowed you to tell that some of the protected
> headers were unchanged while allowing others to change, then it would mean
> something - but the whole point of ARC is for when DKIM doesn't validate
> any more, and if DKIM doesn't validate any more then the message-id can be
> spoofed too.
>
>
Do we think there's any utility to adding more message info to the AS, such
as message-id?

We originally tried to keep them very separate, but we could combine the AS
with the concepts of the "weak DKIM" signature we talked about a while back.

It equally doesn't prevent any individual attack, but perhaps there are
other benefits in aggregate.

I could also easily imagine some utility for having AMS include the z= DKIM
tag, though this may get into the weeds of what can be used
programmatically to determine spamminess/reuse vs expert user forensics
after the fact.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Readability and some technical remarks on draft-ietf-dmarc-arc-protocol-08

[Brandon Long]

On Tue, Aug 22, 2017 at 10:41 PM, Rick van Rein 
wrote:

> Hello,
>
> Thanks for the work on ARC!
>
> I would like to share a few remarks about
>
>
>   draft-ietf-dmarc-arc-protocol-08
>
> that could improve its readability, and then there is one technical
> remark.  I apologise if things are due to reading it not intensely
> enoughh, but that is only a sign that I find the draft difficult to read.
>

[snip]


>
> 11.
> It is not clear to me how the market forces would work in getting all
> those low-cost / low-effort email forwarding arrangements to implement
> this (somewhat complex) technology.  Just the fact that keys have to be
> hunt in domains, presumably by users at the level of understanding of
> forwarding, sounds like an irrational dream to me.  What is the
> intention of ARC in that respect?  Is the intention to push such
> situations out of the Internet [basically breaking email functionality]
> or to use SPF (without DMARC's additional envelope.From==header.From
> check) and/or to trace back Received headers on an incoming "real" mail
> deal?  What would then be the expectations of SPF on the forwarding mail
> domain?  These kinds of impact on the email landscape are incredibly
> important, especially because ARC intends to resolve them -- by being
> rather heavy-weight.
>

I really don't understand what you're saying here (hunt in domains?)

For one, most forwarders, especially the low-cost / low-effort ones, don't
modify mail when forwarding, so there is no DMARC issue.

If they do modify mail, they're already hurting today.

It's also true that the email ecosystem of today is more complicated, and
although you can just send mail from anywhere, it's not clear that anyone
will accept your mail without effort.

The keys put in domains are already a requirement for DKIM, which, if not a
requirement for sending, is a good step at getting your mail accepted
anywhere.

No one's trying to push anyone out of the Internet, but sometimes the bar
for participation is raised.  And no one's saying that ARC will be a
requirement for anything.

One could argue that ARC usage by the larger providers actually allows you
to send mail with only SPF auth and not DKIM, since the SPF auth will be
forwarded with ARC.  Probably be a long time before that can be relied on.

As for the rest of the paragraph about SPF and whatever... it sounds like
you're proposing an alternative or something.

As for the heavy-weight issue, managing a key is the same weight as it was
for DKIM, which isn't to say that most people get it right (someone should
make a lets encrypt style system for managing DKIM keys, it wouldn't be too
hard to do).  The rest is handled by the software, and frankly, although
the software may be a bit tricky to get right, I wouldn't expect the
low-cost / low-effort folks to be writing their own, they'll install
something already written and use it.  And that software is much less
complicated than say the TLS software they are also hopefully using.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] About "non-rewindable crypto"

[Brandon Long]

Can you do that and it's still possible to validate that site2 signed it?

Brandon

On Aug 18, 2017 5:53 PM, "Bron Gondwana"  wrote:

> So this is an interesting case that I'd like to spin into a separate
> thread.
>
> At the moment, ARC headers are purely additive.  You receive a message
> with some ARC headers on it, you add some more on top and send it on.
>
> AR: arc=pass, ...  // at receiver
> AS: i=3; cv=pass, d=site4.com
> AMS: i=3; d=site4.com
> AAR: i=3; arc=pass
> AS: i=2; cv=pass, d=site3.com
> AMS: i=2; d=site3.com
> AAR: i=2; arc=pass
> AS: i=1; cv=none, d=site2.com
> AMS: i=1; d=site2.com
> AAR: i=1; arc=none; dkim=pass
> DKIM-Signature: d=site1.com
>
> site1 => site2 => site3 => site4 => receiver
>
> Somebody who obtains a copy of that message could then trim the message
> back:
>
> AS: i=2; cv=pass, d=site3.com
> AMS: i=2; d=site3.com
> AAR: i=2; arc=pass
> AS: i=1; cv=none, d=site2.com
> AMS: i=1; d=site2.com
> AAR: i=1; arc=none; dkim=pass
> DKIM-Signature: d=site1.com
>
> And pretend that the message was sent from site3 down a different path:
>
> AR: arc=pass, ...  // at receiver
> AS: i=3; cv=pass, d=badsite.com
> AMS: i=3; d=badsite.com
> AAR: i=3; arc=pass
> AS: i=2; cv=pass, d=site3.com
> AMS: i=2; d=site3.com
> AAR: i=2; arc=pass
> AS: i=1; cv=none, d=site2.com
> AMS: i=1; d=site2.com
> AAR: i=1; arc=none; dkim=pass
> DKIM-Signature: d=site1.com
>
> And the message still arrives at receiver with a valid ARC chain, just via
> badsite.com instead of site3.com.
>
> It is possible to do things with crypto, mixing in hashes, such that you
> not only add new headers, but you rewrite past headers such that the
> original versions of them can't be reconstructed any more.  Which would
> mean that if you could intercept a copy at the receiver, you couldn't trim
> back to i=2 and restart the chain on that message.  It would mean header
> replacement rather than just header addition though.
>
> Is this something that would have enough interest to be worth pursuing?
> It's bound to be more complex than ARC-as-defined, but it also makes faking
> mail flows a lot harder, because you would have to intercept the message
> between site3 and site4 if you wanted to fake the mail flow from site3 -
> you couldn't just pick it up later.
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   br...@fastmailteam.com
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank  wrote:

> On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen  wrote:
>
>> So I was able to retrace our design steps which led to the 3-piece model
>> (AAR + AMS + AS) and the reasoning for the AS, signing just the ARC header
>> sequence was to provide the verifiable chain of custody trace (though, of
>> course, only from participating intermediaries). Some of the recent tweaks
>> to the spec to deal with malformed sets of ARC header fields have weakened
>> that original idea.
>>
>> In keeping with Bron's general idea to simplify, I'd suggest that having
>> an AAR + [optional AMS] + AS would be a close approach for handling steps
>> which do not break the ingress signature. Skipping the AMS would be a sign
>> to downstream intermediaries that the prior DKIM or AMS was still valid
>> upon egress. (certain details would have to be worked out)
>>
>> Does that help the conversation?
>>
>
> No, I think this is a huge step in the wrong direction.
>
> Right now, we've got deployed code that we know works and improves the
> landscape. Everything else is - rightly or wrongly - conjecture.
>
> Let's keep the tech stable and move to experimentation.
>
> If anything, this is an excellent question for receivers - when evaluating
> AMS/AS, were there any situations where you required both signatures to
> truly validate a chain and make a delivery decision, or with the added ARC
> payload is now just having one sufficient?
>

I'm leary that removing the AMS on certain hops is the right choice, here.
Without the AMS, the extra AAR/AS is not tied to this message directly, so
I'm unsure how to handle any assertions made in the AAR.  This also feels
like the opposite of what Bron is asking for.

I also proposed a month or so back some simplifying changes which were
largely met with radio silence, that would have partially mitigated some of
Bron's operational concerns, notably to either require the s/d be the same
on AS/AMS or to eliminate the signature and s/d on AMS completely,
switching the AMS to a hash that would then be covered by the AS.  That
doesn't reduce the number of crypto ops as much as his AMS only based
proposal (which presumably would halt at the first broken AMS).

Another option would be to change our expectations, that is to say that
signing by non-modifying hops is optional.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana <br...@fastmailteam.com>
wrote:

> On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote:
>
> dammit, posted from the wrong address again...
>
>
> You'll be dealing with this until the bulk of mailing lists AND receivers
> have become ARC aware, so you've got a while to get used to changing which
> address you post from :p
>

The bulk of mailing lists I deal with are rewriting From headers, IETF is a
special case.

> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <br...@fastmailteam.com>
> wrote:
>
>
>
> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <br...@fastmailteam.com>
> wrote:
>
> The only way you could even hope (as a mailing list) to avoid rewriting
> the sender is for every site that currently has DMARC p=reject to change
> that to a new policy which explicitly means "only reject if no ARC chain" -
> otherwise you can't stop rewriting sender until you know that every
> receiver on your list is ARC-aware.
>
>
> I don't understand your point.
>
>
>
> If you are a mailing list and you receive a message from a domain with
> DMARC p=reject, you can't send that message on to the members of your list
> without rewriting the sender.
>
>
> The only way DKIM works is if enough receivers validate it.
>
> The only way adding elliptic curve to DKIM works is if enough receivers
> validate it.
>
> The only way a DMARC policy works is if enough receivers validate it.
>
> ARC is the explicit solution to mailing list breakage with DMARC. But, as
> with all other IETF RFCs, only works if enough receivers validate it.
>
> Our job is to make sure ARC accomplishes its goals under the DMARC
> charter, and demonstrate value to receivers that it's worthwhile to
> implement.
>
> There will always be a ramp up and implementation phase, that is a
> feature, not a bug, and not a reason to say "it won't work."
>
>
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
> You still have to rewrite the sender until there is either full adoption
> or sufficient adoption that you just don't care about the stragglers.
>
> ARC doesn't solve that unless every receiver is either ARC-aware or
> DMARC-unaware.  Hence the suggestion that I think Hector is making - to
> define a new policy p=rejectnonarc or something, which means that sites
> which are ARC-unaware accept rather than reject.
>
>
> Theoretically, if rewriting the from header had been the "approved" way to
> work around DMARC issues for mailing ilsts, one could imagine that
> something like ARC could have explicitly allowed for that concept and
> making it so receivers could back-sub the original From or something. That
> way, ARC implementers would get immediate benefits over from rewriting.
>
>
> I've thought quite a lot about that as well.  I would love if most mailing
> lists included enough data to reconstruct the original DKIM-passing message
> again, so the receiver could actually know the diff from the original
> message and scan it separately.  That way you could very easily know
> whether the source of any objectionable content was the mailing list or the
> original sender.
>

We went down the path of including a diff of the message in the headers,
but you run up against more complicated changes that make that
challenging.  Ie, mailing lists which strip attachments.  If all we cared
about were subject munging and footers, there probably would have been a
practical solution there.

> OTOH, if you ignore from header rewriting as a solution (which many have),
> then ARC implementation theoretically adds immediate benefit (or the
> potential for immediate benefit, since it requires participation from both
> the mailing list and receivers)
>
>
> I kind of buy that.  I'll be interested to see how it pans out in practice.
>
> ARC definitely solves more than from header rewriting does, but from
> header rewriting is certainly a much simpler solution for mailing lists...
> even as it makes them slightly worse to use.
>
>
> As someone just about to launch a new mailing list product, we will be
> from-header rewriting for DMARC p=reject domains for at least a little
> while, and likely building something horrible which attempts not rewriting
> for individual recipients and keeping a whilelist to see if they don't
> reject.  Though if someone is just dropping messages, we would never know -
> it's a horrible uncertain situation as the site in the middle, because you
> don't know h

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

dammit, posted from the wrong address again...

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana 
wrote:

> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana 
> wrote:
>
> The only way you could even hope (as a mailing list) to avoid rewriting
> the sender is for every site that currently has DMARC p=reject to change
> that to a new policy which explicitly means "only reject if no ARC chain" -
> otherwise you can't stop rewriting sender until you know that every
> receiver on your list is ARC-aware.
>
>
> I don't understand your point.
>
>
> If you are a mailing list and you receive a message from a domain with
> DMARC p=reject, you can't send that message on to the members of your list
> without rewriting the sender.
>
> The only way DKIM works is if enough receivers validate it.
>
> The only way adding elliptic curve to DKIM works is if enough receivers
> validate it.
>
> The only way a DMARC policy works is if enough receivers validate it.
>
> ARC is the explicit solution to mailing list breakage with DMARC. But, as
> with all other IETF RFCs, only works if enough receivers validate it.
>
> Our job is to make sure ARC accomplishes its goals under the DMARC
> charter, and demonstrate value to receivers that it's worthwhile to
> implement.
>
> There will always be a ramp up and implementation phase, that is a
> feature, not a bug, and not a reason to say "it won't work."
>
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
> You still have to rewrite the sender until there is either full adoption
> or sufficient adoption that you just don't care about the stragglers.
>
> ARC doesn't solve that unless every receiver is either ARC-aware or
> DMARC-unaware.  Hence the suggestion that I think Hector is making - to
> define a new policy p=rejectnonarc or something, which means that sites
> which are ARC-unaware accept rather than reject.
>

Theoretically, if rewriting the from header had been the "approved" way to
work around DMARC issues for mailing ilsts, one could imagine that
something like ARC could have explicitly allowed for that concept and
making it so receivers could back-sub the original From or something. That
way, ARC implementers would get immediate benefits over from rewriting.

OTOH, if you ignore from header rewriting as a solution (which many have),
then ARC implementation theoretically adds immediate benefit (or the
potential for immediate benefit, since it requires participation from both
the mailing list and receivers)

ARC definitely solves more than from header rewriting does, but from header
rewriting is certainly a much simpler solution for mailing lists... even as
it makes them slightly worse to use.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana 
wrote:

> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana 
> wrote:
>
> The only way you could even hope (as a mailing list) to avoid rewriting
> the sender is for every site that currently has DMARC p=reject to change
> that to a new policy which explicitly means "only reject if no ARC chain" -
> otherwise you can't stop rewriting sender until you know that every
> receiver on your list is ARC-aware.
>
>
> I don't understand your point.
>
>
> If you are a mailing list and you receive a message from a domain with
> DMARC p=reject, you can't send that message on to the members of your list
> without rewriting the sender.
>
> The only way DKIM works is if enough receivers validate it.
>
> The only way adding elliptic curve to DKIM works is if enough receivers
> validate it.
>
> The only way a DMARC policy works is if enough receivers validate it.
>
> ARC is the explicit solution to mailing list breakage with DMARC. But, as
> with all other IETF RFCs, only works if enough receivers validate it.
>
> Our job is to make sure ARC accomplishes its goals under the DMARC
> charter, and demonstrate value to receivers that it's worthwhile to
> implement.
>
> There will always be a ramp up and implementation phase, that is a
> feature, not a bug, and not a reason to say "it won't work."
>
>
> While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
> You still have to rewrite the sender until there is either full adoption
> or sufficient adoption that you just don't care about the stragglers.
>
> ARC doesn't solve that unless every receiver is either ARC-aware or
> DMARC-unaware.  Hence the suggestion that I think Hector is making - to
> define a new policy p=rejectnonarc or something, which means that sites
> which are ARC-unaware accept rather than reject.
>

Theoretically, if rewriting the from header had been the "approved" way to
work around DMARC issues for mailing ilsts, one could imagine that
something like ARC could have explicitly allowed for that concept and
making it so receivers could back-sub the original From or something. That
way, ARC implementers would get immediate benefits over from rewriting.

OTOH, if you ignore from header rewriting as a solution (which many have),
then ARC implementation theoretically adds immediate benefit (or the
potential for immediate benefit, since it requires participation from both
the mailing list and receivers)

ARC definitely solves more than from header rewriting does, but from header
rewriting is certainly a much simpler solution for mailing lists... even as
it makes them slightly worse to use.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Prove me wrong!

[Brandon Long]

Since AMS i=1 doesn't pass, the information included in Set 2 only says
that site3 claims that site2 said that spf passed, whereas in Set 1, the AS
allows you to verify that site2 actually claimed that spf passed.

Now, since the i=1 AMS doesn't pass, it is true that the i=1 headers in
both cases could have been either made out of whole cloth (in Set 2) or
copied from an existing message (in Set 1).

Your formulation also means that who asserted anything in i=1 is now
missing.  You could include information in the i=1 aar on who made the
assertion (srv-id?) or not strip the broken AMS for i=1.

Looking at my whitelist based local policy override code, it doesn't care
about the seal, the seal is only used to verify the intact arc chain.

So, assuming some changes to what you're saying, your handling of a single
message is not different based on the two versions above.

That is not the only utility of the arc chain, however.

AS allows me to verify that what was asserted was asserted by the actual
service, but not that that assertion applies to this message.  The fact
that it applies to this message is based on trusting the services which
handled receipt, yes.  But your version allows a malicious actor to invent
the path the message went through.  With AS, they have to copy an existing
chain, without it they can just write whatever they want.

This distinction becomes more important when using the information as
training data for learning which paths to trust and which not to trust.
The AS certainly contains more information there, but perhaps that more
information is only useful for the largest actors, and then maybe only as
some small percentage of decreased false positives or the ability to allow
trust further down the long tail.  Without sufficient data and
implementation, it's hard to judge whether the utility of this extra
information is useful.

Brandon


On Mon, Aug 14, 2017 at 7:06 PM, Bron Gondwana 
wrote:

> Seth pointed out that my emails have been long and contained many points,
> so I'd like to keep this really simple.
>
> I will propose two sets of headers on the same message, and I ask if
> anybody can find a case where the set with AS headers provides some
> information which is not present in the set without.  Assume you are a
> receiver at site5.com who just received this message on your MX and are
> validating it.
>
> Set 1:
>
> AS: i=3; cv=pass; d=site4.com
> AMS: i=3; d=site4.com
> AAR: i=3; arc=pass (spf=fail spfdomain=site1.com dmarc=fail fromdomain=
> site1.com)
> AS; i=2; cv=pass; d=site3.com
> AMS: i=2; d=site3.com
> AAR i=2; arc=pass (spf=fail spfdomain=site1.com dmarc=pass fromdomain=
> site1.com)
> AS; i=1; cv=none; d=site2.com
> AMS: i=1; d=site2.com
> AAR i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=
> site1.com)
> DKIM-Signature: d=site1.com
> From: 
>
> Set 2:
>
> AMS: i=3; d=site4.com; h=aar:aar:aar:to:from:etc
> AAR: i=3; arc=pass (arcdomain=site3.com spf=fail spfdomain=site1.com
> dmarc=fail fromdomain=site1.com)
> AMS: i=2; d=site3.com; h=aar:aar:to:from:etc
> AAR: i=2; arc=pass (arcdomain=site2.com spf=fail spfdomain=site1.com
> dmarc=pass fromdomain=site1.com)
> AAR: i=1; arc=none (spf=pass spfdomain=site1.com dmarc=pass fromdomain=
> site1.com)
> DKIM-Signature: d=site1.com
> From: 
>
> In each case the AMS with i=2 and the AMS with i=3 are valid.
>
> I would love to see a case where Set 1 gives information that Set 2
> doesn't, because that would prove that my understanding was incorrect.
>
> Regards,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   br...@fastmailteam.com
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] How are ARC results processed, relative to DMARC?

[Brandon Long]

For our usage, we still consider dmarc=fail, and then include the actual
disposition (dis=) in the comments in the auth-res header.  In the xml rua
report, we would then specify in the PolicyEvaluatedType the actual
disposition and the PolicyOverrideType of local_policy with a comment
saying arc=pass.

This is all said explicitly in draft-ietf-dmarc-arc-protocol-08 9.6.2,
though it does this with the fragment of the dmarc report instead of in
text.

We could expand this to something like...

ARC is not used in DMARC evaluation, the DMARC result is independent of
ARC.  ARC can be used by a receiver to override the Domain Owner's policy
and apply a different disposition from what they asked for.  In that case,
it should be reported as a DMARC fail with a PolicyOverrideType of
local_policy.

Brandon

On Tue, Aug 15, 2017 at 11:42 AM, Dave Crocker  wrote:

> G'day.
>
> ARC is motivated by a desire to deal with a class of DMARC failures.  In
> that context, it can be seen as 'augmenting' DMARC, even though it is
> formally separate from DMARC.  That is, ARC doesn't and shouldn't specify
> how ARC is used in a DMARC context.  But there needs to be some
> understanding -- and I suspect a spec, somewhere, eventually -- that says
> how to integrate ARC into an engine that includes DMARC.
>
> BTW, the DMARC spec uses the terms 'pass' and 'fail' with respect to the
> underlying authentication mechanisms of DKIM and SPF.  It also uses it
> within the context of DMARC processing, itself, but it does not define what
> those terms mean, in that context.  Beyond reference to DMARC 'policy'
> records, text in the specs that talk about processing DMARC policy is
> similarly implicit, rather than explicit.  The only clear, explicit
> directive about DMARC outcomes seems to be Section 6.6.2 #6, Apply policy.
>
> An example of possible confusion in the case of ARC:  does DMARC still
> 'fail'?  Yet the whole point of ARC is to create the possibility of still
> getting delivered, in spite of this.
>
> So, were one to write something to augment the DMARC spec, in support of
> ARC, what are the kinds of text one ought to formulate and how should they
> be linked to the DMARC spec?
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana 
wrote:

> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:
>
> I'm just picking out the key quote here:
>
> On 8/7/2017 4:22 PM, Seth Blank wrote:
>
> When validating an ARC signed message, one verifies the latest AMS
> (which must validate), and *the entire chain* of ARC Seals, not only
> the latest. This guarantees you a list of all message signatories -
> the chain of custody we're talking about.
>
>
> Yes, I follow this bit, but then...
>
> When evaluating the chain for final receipt, there are two states to
> worry about as a matter of local policy: 1) you trust all the
> signatories on the chain 2) there is an untrusted signatory on the
> chain
>
>
> Which is why it's a bad idea to sign if you're not modifying, because then
> everybody has to trust you or their chain breaks, even though you didn't do
> anything which required signing.
>

This is an interesting point.

If there is a non-participating intermediary, either the message wasn't
modified (so the next hop passes arc) or it was (and the next hop fails the
whole chain).

If you are participating, the fact that you didn't modify the message is
lost when the message is modified down the chain.

This is a clearly worse scenario for participation, due to the lack of
information that is passed forward in the chain.

We would need to include more information in the chain in order to overcome
this, some information from hop N about which previous hop was the last
modifying hop.

[snip]

> The critical thing about the ARC Seal is that it guarantees this
>
> behavior in state #1 - if you trust all the d= values in the ARC
> Seals, they all validate, and you have cv=pass, then you know for
> certain everyone who has manipulated the message (and maybe some who
> handled but did not modify).
>
>
> In state #1, you don't need a chain of ARC Seal.  You just need each site
> to sign their own AAR and each AAR to include "arc=pass" for the previous
> AMS.  You trust the sites, so you trust them to verify the ARC status on
> ingress.
>
> So ARC Seal isn't adding anything other than complexity.  I'm not saying
> "ARC Seal doesn't work in case #1" - I'm saying "ARC Seal is security
> theater in state #1".  It's overly complex and adding no value.
>

If a message goes through two modifying hops, then there is no utility in
the AMS/AAR from the first hop, because it no longer verifies.

At that point, you only ever have the AMS/AAR from the last modifying hop,
which is exactly what we had with XOAR (or at least the Google
implementation).

The Google implementation was basically X-Google-DKIM-Signature as the AMS
and X-Original-Authentication-Results as the AAR.

Theoretically, the second modifying hop could include information from the
preceding AAR in it's AAR, and maybe that transitive trust (I trust hop 2,
which trusts hop 1, so I have to trust hop 1) is ok, because by trusting
hop 2, they could have completely replaced the message.  This wasn't done
with XOAR.

There would be no point in including multiple AMS/AAR headers, why bother
keeping the non-verifiable ones.  Or maybe, you just get rid of the AMS and
keep the AAR and have your AMS sign over all of the existing AAR records.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Brandon Long]

Sorry, posted from the wrong address, trying again.

On Aug 9, 2017 8:41 PM, "Brandon Long" <bl...@google.com> wrote:

> We discussed this exact situation extensively during several M3AAWG
> meetings, so I don't think we're missing something... but maybe.
>
> With AS I can trust the chain and use the older hops AAR.  And whether to
> use a given hops AAR is based on my trust level for that hop.
>
> As long as the AMS passes, you can ignore hops you don't trust and keep
> walking.
>
> Once you reach a hop where the AMS doesn't verify, you can only walk back
> to hops you trust, and untrusted hop ends your walk back.
>
> So, you can copy and entire chain on to whatever message you want, but
> that only works if I trust you.  If you do this a lot, we won't trust you
> any more.
>
> This doesn't mean that some messages can't abuse the trust relationship
> and make it through, and we specifically say that standard
> spam/phishing/abuse analysis should still be done.
>
> With your proposed AAR signed by the AMS, I can only trust your AAR, and
> whatever you choose to put in it, not anyone in front of you.
>
> With XOAR, we have experience with that type of single hop working system,
> and it's not complete enough, we see too many complicated routing policies
> which go through many hops, and the last hop data isn't always enough.  We
> work around it with from header rewrites and signing as the intermediary
> domain, but then we need to make decisions on when to do so since dkim
> means something different than ams does.
>
> Also, you wouldn't expect to see arc signed messages from this list until
> it starts doing them itself, unless people are posting to it though another
> intermediary or you receive it through a separate intermediary.
>
> Brandon
>
> On Aug 9, 2017 6:26 PM, "Bron Gondwana" <br...@fastmailteam.com> wrote:
>
>> On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
>>
>> I think the "Once AMS doesn't validate anymore ..." argument is an
>> suggestion that it's fragile, not that it's pointless.  I have concerns
>> myself about the robustness of this design, but I think that's best
>> addressed through deployment and experimentation.
>>
>>
>> It's not fragility, the older AMS is supposed to not validate any more,
>> because it's a signature over a bunch of headers and the body - any change
>> in those will break it.  That's fine so long as the chain of custody exists.
>>
>> My problem is that ARC-Seal only actually shows the chain of custody back
>> to the first bad actor.  That's also fine, because any bad actor means the
>> whole message is tainted and should be discarded.
>>
>> The thing is - ARC-Seal and verifying every Seal only gives more
>> integrity than checking the previous AMS and signing your own AAR unless
>> this is true:
>>
>> * There exists a site which correctly checks ARC-Seal and adds new
>> ARC-Seals, but does not generate an accurate AAR.
>>
>> I do feel like nobody understands what the hell I'm trying to say here
>> based on the responses I've seen so far, so maybe I do actually need to
>> find an existing ARC-Sealed email and forge a change to it.  Seth asked to
>> have a phone chat about this, and I'm happy to have a phone chat with
>> anybody if it will help explain my point.
>>
>> I'm not saying that the underlying concept of ARC are wrong - the idea of
>> chain of custody is sound.
>>
>> The problem is that ARC-Seal makes claims it just doesn't deliver on -
>> it's not adding value, and it is adding cost and fragility (the need to
>> successfully do DNS fetches for every seal in the chain at every point,
>> plus the cost of checking that crypto) - and yet any one site can still
>> falsify all the earlier items in the chain.
>>
>> Sadly I only have a few message in my entire mailbox that have ARC-Seals
>> on them.  They're from a Mozilla Thunderbird list of all things, and they
>> have some Google ARC headers on them.  I'd prefer to impersonate someone
>> from this list if I'm going to make a proof of concept to show what I mean,
>> but nobody appears to be sending messages with ARC headers on them here!
>>
>> Bron.
>>
>> --
>>   Bron Gondwana, CEO, FastMail Pty Ltd
>>   br...@fastmailteam.com
>>
>>
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] dns failures in the draft

[Brandon Long]

> 9.4.  Handling DNS Problems While Validating ARC
>DNS failures to resolve or return data which is needed for ARC
>validation SHOULD result in a 421 tempfail during the SMTP
>conversation with the sending system.  Temporary or intermittent DNS
>problems will generally not be sufficiently transitory to allow a
>mediator to obtain a different result during the ordinary transit
>duration so it is better to have the source system queue the
>problematic message(s) than to generate (potential) backscatter.
>
>Operators of systems which mediate mail should be aware that broken
>DNS records (or malfunctioning name servers) will result in
>undeliverable mail to any downstream ARC-verifying ADMDs.
>
>DNS-based failures to verify a chain are treated no differently than
>any other ARC violation.  They result in a "cv=fail" verdict.

I don't know if SHOULD is the right choice here.

For a large percentage of mail, ARC is unnecessary, even when
forwarded through an intermediary.  The mail will continue to DMARC
pass, or the mail will not be for a DMARC p=reject domain.

I think that issuing a temp fail instead of a perm fail on a DMARC
reject if the arc chain may have allowed a local policy override is
useful, but to temp fail all arc dns failures may be more harmful than
helpful.

I think I used the dns failure case as a place where cv=fail instead
of just not signing was actually more harmful, but that seemed more
complicated than others were willing to go.

Of course, passing the dns failure from a separate arc milter to a
dmarc milter to make that determination is complicated, though in
authres terms, we could use an arc=tempfail result to pass that info
on.

Brandon

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] questions about section 5.1.1 of the new ARC draft

[Brandon Long]

In that case, I dislike specifying the hop number in the ptype, given the
registry nature of the ptype and property, it seems like they should be
specific and not an enumerated value.

Brandon

On Mon, Jul 31, 2017 at 4:25 PM, Gene Shuman <geneshu...@gmail.com> wrote:

> I was just talking with Seth about this.  I think the language was poorly
> worded, and the intention is not to have a million ams.s, ams.ds in the
> aar, but just the ones from the most recent hop.  Is this correct?
>
> Also, I still dont like ARC implementations being asked to parse DKIM
> signatures to get header.s.  Nor do I really understand why we want that
> info.
>
> On Mon, Jul 31, 2017 at 4:20 PM, Brandon Long <bl...@fiction.net> wrote:
>
>> Catching up here...
>>
>> Perhaps the traditional separation of all of the mail authenticators is
>> what should change, ie if we combined the various handlers into one, then
>> it becomes much more obvious how the information flow would occur.
>>
>> For our impl, it's just various calls within the single process, hence
>> why it's easy to issue a single authres header as well.
>>
>> Looking at the 5.1.1 section, I do think we should specify that the
>> source.ip is either in the arc section or the spf section, and not leave
>> that to random choice.
>>
>> I also do not like the arc related data as specified.  If the arc chain
>> is intact, then the information is trivially extracted from the chain, if
>> it's not intact, then who cares.
>> Even if we want to include this data, I think the fact that we have a
>> chain of data could be used, and therefore we would only include the i-1
>> hop data in the single aar.
>>
>> Arc-Authentication-Results: i=3; mx.google.com; arc=pass ams.d=google.com
>> ams.s=arc as.d=google.com as.s=arc
>>
>> The spec currently says i can go up to 1024 but unlikely over 50, are we
>> going to generate:
>> Arc-Authentication-Results: i=50; mx.google.com;
>> arc=pass ams49.d=google.com ams49.s=arc-20160816 as49.d=google.com
>> ams49.s=arc-20160816
>> ams48.d=google.com ams48.s=arc-20160816 as48.d=google.com
>> ams48.s=arc-20160816
>> ams47.d=google.com ams47.s=arc-20160816 as47.d=google.com
>> ams47.s=arc-20160816
>> ams46.d=google.com ams46.s=arc-20160816 as46.d=google.com
>> ams46.s=arc-20160816
>> ams45.d=google.com ams45.s=arc-20160816 as45.d=google.com
>> ams45.s=arc-20160816
>> ams44.d=google.com ams44.s=arc-20160816 as44.d=google.com
>> ams44.s=arc-20160816
>> ams43.d=google.com ams43.s=arc-20160816 as43.d=google.com
>> ams43.s=arc-20160816
>> ams42.d=google.com ams42.s=arc-20160816 as42.d=google.com
>> ams42.s=arc-20160816
>> ams41.d=google.com ams41.s=arc-20160816 as41.d=google.com
>> ams41.s=arc-20160816
>> ams40.d=google.com ams40.s=arc-20160816 as40.d=google.com
>> ams40.s=arc-20160816
>> ams39.d=google.com ams39.s=arc-20160816 as39.d=google.com
>> ams39.s=arc-20160816
>> ams38.d=google.com ams38.s=arc-20160816 as38.d=google.com
>> ams38.s=arc-20160816
>> ams37.d=google.com ams37.s=arc-20160816 as37.d=google.com
>> ams37.s=arc-20160816
>> ams36.d=google.com ams36.s=arc-20160816 as36.d=google.com
>> ams36.s=arc-20160816
>> ams35.d=google.com ams35.s=arc-20160816 as35.d=google.com
>> ams35.s=arc-20160816
>> ams34.d=google.com ams34.s=arc-20160816 as34.d=google.com
>> ams34.s=arc-20160816
>> ams33.d=google.com ams33.s=arc-20160816 as33.d=google.com
>> ams33.s=arc-20160816
>> ams32.d=google.com ams32.s=arc-20160816 as32.d=google.com
>> ams32.s=arc-20160816
>> ams31.d=google.com ams31.s=arc-20160816 as31.d=google.com
>> ams31.s=arc-20160816
>> ams30.d=google.com ams30.s=arc-20160816 as30.d=google.com
>> ams30.s=arc-20160816
>> ams29.d=google.com ams29.s=arc-20160816 as29.d=google.com
>> ams29.s=arc-20160816
>> ams28.d=google.com ams28.s=arc-20160816 as28.d=google.com
>> ams28.s=arc-20160816
>> ams27.d=google.com ams27.s=arc-20160816 as27.d=google.com
>> ams27.s=arc-20160816
>> ams26.d=google.com ams26.s=arc-20160816 as26.d=google.com
>> ams26.s=arc-20160816
>> ams25.d=google.com ams25.s=arc-20160816 as25.d=google.com
>> ams25.s=arc-20160816
>> ams24.d=google.com ams24.s=arc-20160816 as24.d=google.com
>> ams24.s=arc-20160816
>> ams23.d=google.com ams23.s=arc-20160816 as23.d=google.com
>> ams23.s=arc-20160816
>> ams22.d=google.com ams22.s=arc-20160816 as22.d=google.com
>> ams22.s=arc-20160816
>> ams21.d=google.com a

[dmarc-ietf] News piece on using arc...

[Brandon Long]

https://www.propublica.org/nerds/item/authenticating-email-using-dkim-and-arc-how-we-analyzed-the-kasowitz-email
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] new arc usage

[Brandon Long]

I know I complained recently that no one else was sending us arc signed
mail, but that is no longer true.

We're now seeing a smattering of low volume domains sending us arc-signed
mail, about 190 of them in total (possibly from fewer servers).

Glad to see it.

Someone's using a keysize of 4098... that's odd.

There's also one slightly larger sender is who quoting the existing header
fields when we get the mail back from them, ie the arc-seal is coming back
with
d="google.com" a="rsa-sha256" s="arc-20160816".  That may just be some
weird mta.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Clarifying question: AAR coverage by AMS

[Brandon Long]

So, history, the concepts of ARC come from the XOAR as implemented by
Google.

There, there is the XOAR header and it's covered by the
X-Google-DKIM-Signature header.  This translated to the AAR covered by
AMS.  ARC obviously has the second layer with the AS, which seems likely to
provide the same level of protection.

I don't really see the implementation challenge with requiring this, but
I'm open to removal if there is no utility to it.

I'm trying to think through scenarios to see if there's anything stronger
that this gives us, but I haven't seen any yet.

AMS covering AAR means that you could "trust" the AAR even if the chain
itself is compromised, but we've typically said "a broken chain should be
ignored", and I think that
statement should still hold.

There is the oddness that the AS and AMR don't have any requirements to be
the same.  With AAR not covered by AMS, you could replace the AAR/AS for a
hop, and sign the AS with a different key.  That means the AAR's trust
vector is just the AS and not both (AS/AMS).

Brandon

On Tue, May 30, 2017 at 3:11 PM, Gene Shuman <g...@valimail.com> wrote:

> The two list approach to configuration actually seems sensible in general,
> I'll discuss this with msk.
>
> However, if the recommended AAR inclusion language accomplishes nothing,
> shouldn't we remove it, regardless?
>
> On Tue, May 30, 2017 at 3:00 PM, Brandon Long <bl...@google.com> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 1:35 PM, Gene Shuman <g...@valimail.com> wrote:
>>
>>> So I'm actively doing development on OpenARC right now, and this
>>> definitely something that is being a source of some non-trivial
>>> awkwardness.
>>>
>>> Can anybody recall why the aforementioned language of recommending
>>> including the AAR's in the AMS is in there?  Afaik, it seems to make no
>>> sense, and is causing some implementation specific awkwardness wrt both
>>> OpenARC & the test suite.
>>>
>>> So one would expect that for an ARC implementation, we would want a
>>> simple configuration option that tells us which headers to sign.  I believe
>>> OpenDKIM behaves in exactly this fashion.  And it needs to be able to
>>> include duplicates, as that's a require feature of the rfc.  But this
>>> recommendation to include AAR's in the list makes this awkward, as, as we
>>> can't configure this in a similar fashion, as we dont know how many AAR's
>>> are in messages a prior.
>>>
>>
>> I think this is broken.  Why would you ever configure "only sign two
>> copies of this header, but not three"?  I'd expect two lists, one of which
>> headers to sign, and one of which headers to add as empty to prevent extra
>> copies of the header to be added.  Ie, in dkimpy, that's the SHOULD and
>> FROZEN lists.
>>
>>
>>> So either an implementation will either need some AAR inclusion
>>> configuration option, independent of the other h= configuration list, or it
>>> needs to make some internal decision of whether to be signing these headers
>>> or not.  The first option is awkward & seems just kind of needlessly
>>> complex.  And I'm also not a fan of implementations making this kind of
>>> decision internally, as I think its important from a testing standpoint to
>>> have the output headers be predictable.
>>>
>>> So can anybody recall why this language is there?  It seems kind of
>>> pointless in the best case, and slightly harmful in the worst.  Unless
>>> somebody has a reason for it being there, I suggest we remove it.  Or why
>>> not just actively forbid the inclusion of all ARC-Set header fields in the
>>> AMS while we're at it?  That seems like a plausible idea.
>>>
>>
>> The AMS was arrived at incrementally, as was the AAR (originally there
>> was just one AAR, not a full chain).  I guess it's not required, though I'm
>> not sure about the harmful part.
>>
>> Brandon
>>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

[Brandon Long]

On Wed, May 24, 2017 at 4:42 PM, John R Levine  wrote:

> On Wed, 24 May 2017, Seth Blank wrote:
>
>> aft-ietf-dmarc-arc-protocol-03#section-5.1.3 :
>>
>> "The AAR should contain all Authentication-Results results from within its
>> ADMD, regardless of how many Authentication-Results headers are on the
>> message."
>>
>
> Seems reasonable, give or take a word or two to make it clear we're just
> talking about the ones for the current hop.


There should only be the ones from the current hop if the admd is stripping
previously existing ones prior to adding any new ones per the authres rfc.

We can make that fact explicit here as well, though.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] implementation update

[Brandon Long]

Why should the sender be involved in determining which forwarding is
allowed?

The arc chain specifies each of the hops, and the receiving domain is in
the best position to know about the intermediaries.

I can imagine a whitelist style rbl allowing folks to know which
intermediaries to trust, but I don't get having to have each sender know
all intermediaries ahead of time.

Brandon

On May 23, 2017 8:27 AM, "Hector Santos" <hsan...@isdg.net> wrote:

> On 5/11/2017 7:08 PM, Brandon Long wrote:
>
>>
>> We're still a couple weeks away from using this information in dmarc
>> evaluation.
>>
>
> If my understanding is correct of the ARC work done, and thanks to Murray
> for his draft rewrite ("better" flow, mail tech read),  ARC will allow an
> "indirect" message, i.e. list message, to survive the original author
> domain signature, provided the final receiver reads the ARC headers with a
> 3rd party ARC seal?
>
> If so, are we still missing a *deterministic* author domain 3rd party
> signature authorization procedure/protocol that links DMARC with ARC?
>
> When I last left this work, I called that a "Registration" scheme,
> process, I thought was inherently missing in all the DKIM "policy" proposed
> solutions.
>
> Before I begin to look at implementing ARC for our mail server,  I am
> still hopeful for a "registration" DKIM/POLICY protocol.   This is could be
> as simple as an extended DMARC "arc" tag, hopefully as an optional signal
> to augment something like ATPS (Authorized Third Party Signature). Maybe a
> ATPAS (Authorized Third Party Arc Seal)?
>
> Thanks
>
> --
> HLS
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Alternative draft text for draft-ietf-dmarc-arc-protocol

[Brandon Long]

On Tue, May 9, 2017 at 3:56 PM, Gene Shuman <g...@valimail.com> wrote:

> I've taken a look at the proposed draft and have a few notes as well.
>
> 4.  The currently specified limits on i= are not included MUST >10, SHOULD
> > 50, etc
>
> 5.1 - In the current draft, it's mandated that AMS must use relaxed header
> canonicalization, but that's missing from the proposed draft
>

I think that 5.1.2 in the current draft is wrong, it's overridden by 5.1.2.1.2.
We started out only allowing relaxed, but then added back support for c= in
a later draft.

Brandon

5.2 - I'm a bit confused by the comment noting the importance of i=2.  What
> is it that you're intending there?
>
> 5.3.1 - typo:  one of three possible values: -> one of *four* possible
> values
>
> 7.2 - It may be worth elaborating more on the possible ways in which
> cv=invalid can arise, if not here, maybe somewhere else
>
> 7.4 - In general I prefer this to the psuedo code in the current draft,
> but I think it could still use a bit of work.  In particular, sections C-H
> are exactly describing how to validate a DKIM signature and seems somewhat
> unnecessary. Is there any particular reason you decided to include this, as
> opposed to just relying on the DKIM spec for this?
>
> 7.5 - typo: no -> all
>
> In general though, I agree with Brandon, the proposed draft definitely
> makes some things clearer, which I think is a step in the right direction.
>
> =Gene
>
>
> On Tue, May 9, 2017 at 2:04 PM, Brandon Long <bl...@google.com> wrote:
>
>> In 5.1 defining the AMS, you say that it should cover DKIM-Signature and
>> AuthRes headers.  In particular, AuthRes headers are expected to be removed
>> by ADMDs, especially if the message transits the same ADMD multiple times.
>> Also, the information in the AuthRes header is superseded by the ArcAuthRes
>> header.  Including it means an arbitrary AMS breakage for something pretty
>> minor, so I would recommend to not include it.
>>
>> Our implementation explicitly blacklists that header.
>>
>> I know some mailing lists also strip the DKIM-Signature header, but since
>> they are likely to break the AMS anyways, that's less important.  I'm not
>> sure what the benefit is to including it, but it seems harmless.  In
>> particular, if the DKIM-Signature still passes, then the ARC isn't adding
>> that much, and removing the DKIM-Signature header doesn't mean all that
>> much either since it's validity was already assessed and that assessment
>> included in the AAR.  We don't blacklist the DKIM-Signature method in our
>> implementation, but I don't understand the advisement.
>>
>> You also talk about "responsibility".  I'm not sure that's how I would
>> describe it.  An ARC hop is documenting that a message passed through it,
>> and that it evaluated the authentication of the message.  The only
>> responsibility of a hop is to correctly validate the SPF/DKIM/ARC
>> information, there is no ownership implied over the message itself.
>>
>> With AMS, you can answer the question: which ADMD is the last ADMD to
>> have modified the message.  I guess in that sense, the last modifier is
>> "responsible" for the current state of the message... but that kind of
>> means that the AMS of previous hops allows them to disown responsibility
>> for the current state of the message...
>>
>> 5.2 - should we point out that there should be only one of these per
>> hop?  The openspf/dkim/dmarc implementations tend to add separate AuthRes
>> headers for each evaluation, but ARC requires those to be a single instance.
>>
>> 5.3.1 - none as defined as "arrives at an MTA from an MSA", perhaps my
>> understanding of those terms is slightly odd, but I would think that an MSA
>> usually uses an MTA to actually send the message, and it isn't that
>> "sending" MTA that's the first hop, it should be the first "receiving"
>> MTA.  I mean, that's usually the point at which the DKIM signature is
>> applied, and the SPF would be "from" there, not based on the location of
>> the MUA.
>>
>> There are some missing pieces here, corresponding to the current draft
>> sections 5.4 (alternate signing algorithms), 6.4.3 (arc email
>> authentication method for AuthRes), 6.4.5 for dmarc xml.  I see that the
>> arc is included in your IANA section, not sure if the call out outside of
>> the definition is necessary or not.
>>
>> Overall, I think your draft makes some things clearer, and some things in
>> the original are clearer.  It's worth looking into either combining or
>> choosi

[dmarc-ietf] reporting arc local_policy to dmarc rua

[Brandon Long]

6.4.5 in the current spec specifies the following as how to report the
local_policy override from arc:

   
 delivered
 fail
 fail
 
  local_policy
  arc=pass ams=d1.example d=d1.example,d2.example
 
   

The comment is obviously completely unspecified, though maybe some
inferences can be done... though I'm not sure what it's saying myself.

Are we attempting to dictate the comment?  Or is that just an example and
it could be anything?

If anything, then folks who ingest these may need to look at a bunch, or
folks may just say arc=pass.

Is the more extensive information useful?

I came up with random format for use in the comment field for the authres
header, ie something like:

arc=pass (i=2 spf=pass spfdomain=example.com dkim=pass dkdomain=example.com)
(only partially rolled out, most servers are just saying (i=2)) but I'm not
sure that's useful directly either.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] implementation update

[Brandon Long]

Gmail/Google has deployed our implementation of ARC to our mail system.

At this point, we aren't creating new ARC chains, yet, but any message with
an existing arc chain will be validated and signed.

Let us know if you see any issues.

We expect to start creating our own chains in the next couple weeks, baring
issues.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

[Brandon Long]

We also recently discussed having a new DKIM rfc revision to create a
registry of algorithms and allowed key lengths, so that we wouldn't need to
rev the rfc every time they changed, and also to incorporate into arc,
which will use similar signatures.

Discussed a bit here:
https://www.ietf.org/mail-archive/web/dmarc/current/msg03436.html

Brandon

On Thu, Apr 6, 2017 at 2:28 PM, Vladimir Dubrovin 
wrote:

>
> Hello Scott,
>
> it may be good to cover compatibility issues, because otherwise there are
> little chances to succeed the older but more compatible protocols in
> nearest future.  The possible (but probably not the best one) solution is:
>
> 1. produce 2 different DKIM-Signatures with 2 different selectors:
> slector1  with SHA-1 + RSA and selector2 one with  SHA-512 + ECDSA
> 2. add an additional field to either selector1 DKIM DNS record (need to
> consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's
> allowed but probably is not enough to protect against downgrade) to
> indicate the selector is legacy-only, e.g. o=sha512/eccp256 to indicate
> this selector should be ignored if verifier supports sha-512 and eccp256.
>
> Legacy verifier has valid DKIM-Signature with sha1+rsa
> Compatible verifier ignores sha1+rsa and choose sha-512+ECDSA
>
> I can imagine few more ways to resolve compatibility issues, but this one
> seems to be a simplest.
>
>
> 06.04.2017 20:32, Scott Rose пишет:
>
> This may be of interest to this group, as there isn't an active DKIM WG
> anymore.  This is my first attempt to produce a draft about defining new
> digital algorithms for DKIM.  I'm trying to keep this short i.e. only
> define a few IANA registry entries and that's it.
>
> I'm trying to head off a potential issue for organizations that are told
> to migrate to ECDSA or looking for algorithm agility that doesn't involve
> using SHA-1.
>
> Comments welcome and needed. Including being told this isn't needed
> (though I think it might be).
>
> Scott Rose
>
> NIST
>
>
>
>  Forwarded Message 
> Subject: New Version Notification for draft-srose-dkim-ecc-00.txt
> Date: Thu, 6 Apr 2017 10:26:43 -0700
> From: internet-dra...@ietf.org
> To: Scott Rose  
>
>
>
> A new version of I-D, draft-srose-dkim-ecc-00.txt
> has been successfully submitted by Scott Rose and posted to the
> IETF repository.
>
> Name:draft-srose-dkim-ecc
> Revision:00
> Title:Defining Elliptic Curve Cryptography Algorithms for use with
> DKIM
> Document date:2017-04-06
> Group:Individual Submission
> Pages:6
> URL:https://www.ietf.org/internet-drafts/draft-srose-dkim-ecc-
> 00.txt
> Status: https://datatracker.ietf.org/doc/draft-srose-dkim-ecc/
> Htmlized:   https://tools.ietf.org/html/draft-srose-dkim-ecc-00
> Htmlized:   https://datatracker.ietf.org/
> doc/html/draft-srose-dkim-ecc-00
>
>
> Abstract:
>DomainKeys Identified Mail (DKIM) uses digital signature to associate
>a message with a given sending domain.  Currently, there is only one
>cryptography algorithm defined for use with DKIM (RSA).  This
>document defines four new elliptic curve cryptography algorithms for
>use with DKIM.  This will allow for algorithm agility if a weakness
>is found in RSA, and allows for smaller key length to provide the
>same digital signature strength.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
>
> --
> Vladimir Dubrovin
> [image: @Mail.Ru]
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC-Authentication-Results

[Brandon Long]

On Mon, Apr 3, 2017 at 5:42 PM, Murray S. Kucherawy 
wrote:

> On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones  wrote:
>
>> My POV, there is a strong 1:1 correlation between a set of ARC headers
>> and a given ADMD. In this world view, the A-A-R would *not* collect all A-R
>> values from all preceding ADMDs.
>>
>
> It depends on what the goal is.  If you only want to record what the ADMD
> itself directly evaluated, your proposal is fine.  If you want to record
> what the ADMD thinks prior ADMDs claimed (e.g., GMail saying "Yahoo! claims
> this was fine when they got it"), then we must go deeper.  But I don't know
> if that's what's actually needed, or would even be useful, or how one would
> evaluate the meaning of such an indirect claim without a lot of reputation
> data.
>
>
Knowing what the previous ADMD thought is explicitly a goal of ARC.  The
theory is, the first hop said that it was from yahoo.com and DKIM signature
matched, and then the mailing list changed it so the DKIM signature is now
broken, but I believe that the first hop was accurate, so I will bypass
DMARC reject.

Does it need to be included at every hop?  Well, what if it goes through a
mailing list at @google.com which does rewrite it to @google.com and DKIM
signs it to pass, then another hop which rewrites all of the links to use
Proofpoint's "smart malware redirector", so it would fail DMARC for a
domain that wasn't the original domain or evaluation.

The proposal which led to this, X-Original-Authentication-Results, was
basically a way to pass a single AuthRes header forward (in our impl, it is
only believed if it is covered by our X-Google-DKIM-Signature, ARC extends
this to handling multiple hops.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] updating draft-akagiri-dmarc-virtual-verification

[Brandon Long]

It's unclear to me why this needs to be an RFC.  Is the point to register
specific Authentication-Results header values in IANA?

Otherwise, this seems like nothing more than some local special anti-spam
sauce.  Like Scott says, this sounds like SPF bestguess, perhaps he can
point out any discussion that was had about bestguess and why it was left
out of the SPF RFC.

Brandon

On Fri, Mar 31, 2017 at 1:16 PM, Murray S. Kucherawy 
wrote:

> Please be sure to read RFC7601 while deciding, as it sets out the rules
> for the registries related to Authentication-Results and what's appropriate
> to put in them.
>
> On Fri, Mar 31, 2017 at 12:08 PM, Kouji Okada  wrote:
>
>> Mark
>>
>> Thank you for your comment.
>>
>> The authors are now discussing which
>> authentication-method or authentication-code is suitable
>> to be marked in the authentication-results.
>>
>> > Trying to guess where to send (unasked for) reports is guaranteed to
>> end with poor outcomes.
>>
>> I totally agree.
>>
>> Best regards,
>> Kouji Okada
>>
>> > 2017/03/28 22:26、mham...@americangreetings.comのメール:
>> >
>> > On 3/25/2017 12:45 AM, Scott Kitterman wrote:
>> >> For SPF, we had "best guess" [1], which we chose not to standardize at
>> all
>> >> because we didn't think it appropriate to break the opt-in nature of
>> SPF.
>> >> This concerns me a bit here, but I'm mostly writing to support the
>> idea of
>> >> distinguishing between some kind of guess and an actual DMARC result.
>> >>
>> >> I think "dmarc=bestguesspass" is far superior to "dmarc=pass", since
>> this is
>> >> not a DMARC pass.  I think "dmarcguess=pass" would be better since
>> this isn't
>> >> properly a DMARC check at all.
>> >>
>> >> Scott k
>> >
>> > I absolutely agree with Scott on this. "bestguesspass" is NOT DMARC. It
>> is local policy applied in a DMARC like manner.
>> >
>> > This is also why there is no legitimate place to send reports. The
>> sender did not publish a DMARC record and did not ask for reports. Trying
>> to guess where to send (unasked for) reports is guaranteed to end with poor
>> outcomes.
>> >
>> > Mike
>> >
>> >
>> > ___
>> > dmarc mailing list
>> > dmarc@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dmarc
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC)

[Brandon Long]

On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker <dcroc...@gmail.com> wrote:

> On 11/2/2016 2:58 PM, Brandon Long wrote:
>
>> The difference is mostly cosmetic, though depending on your mail client,
>> there may be other downsides.  And it may violate RFC 5322.
>>
>
> Brandon,
>
> You know that I know that the attacks that generated the use of DMARC,
> which is causing the current situation, are serious.  I'm mentioning that
> here to make sure the context for what follows is clear...
>
> Email is communication between an author and one or more recipients.
>
> Everything in between them is 'overhead'.  The overhead functions need to
> be careful to avoid cavalierly reducing the utility of email, even as the
> changes are meant to aid in the use of email.
>
> Identification of the author and recipients is meaningful to them. That's
> not 'cosmetic'.
>
> And software tools employed by users take advantage of this
> identification, for searching and for organizing.
>

Including Gmail, which doesn't handle this workaround well, either.


> In a highly diverse world, one of the problems of being a very major
> player is that it becomes far too easy not to see all the diversity or to
> appreciate its import to others. After all, most of that diversity is seen
> as such a tiny percentage of the activity. This is the essence of
> ethnocentrism.
>
> Changing the contents of the rfc5322.From field is changing basic
> statements about authorship.
>
> Perhaps there's no practical choice right now, but please let's not be
> cavalier about its import.


I think technical fans of email perhaps attach more import to the
rfc5322.from field than does the average user.  Certainly, downsides
exist.  That said, facebook notifications today all come from the same
per-user address, with the actual commenter as just the display name.
Various forum software, email ticketing software, the email notifications
from various web based messaging systems, they all fail to apply authorship
in how you say.

Yes, mailing lists have existed in this form for some time, and they are a
good and vital system, and the downsides are real.

Note also that I imagine that mailing list software which supports EAI
messages might also need to munge the From header to downgrade the message
for delivery to non-EAI enabled receivers.

I'm not sure if my comment was heard in the recent ARC round table, where
folks were questioning the overall complexity of ARC, but I'm fairly
serious in saying that all of our discussions on work arounds and technical
methods for trying to make DMARC work with mailing lists, and from header
munging is by far the simplest.  No trust/reputation systems, no manual
whitelisting, no "magic sauce", no new software to be installed by
receivers.

ARC will add greatly to the size of mail headers, which some folks on
mailop still think should be tiny and talk about automatically marking
large headers as spam.

ARC will add greatly to the privacy concerns which were raised last week on
the DKIM IETF list, where now not only is a message have attestation of
origin, but that attestation will survive some amount of
forwarding/modification, and the path it took will also be attested to.

ARC will require new software to be installed by mailing list providers and
any receivers who implement DMARC.  Even after being installed, there is
still more work in order to allow the mailing list messages through.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC and weak signatures (again)

[Brandon Long]

On Sat, Aug 20, 2016 at 4:02 AM, Alessandro Vesely <ves...@tana.it> wrote:

> On Fri 19/Aug/2016 01:40:42 +0200 Brandon Long wrote:
> > On Wed, Aug 17, 2016 at 2:47 AM, Alessandro Vesely <ves...@tana.it>
> wrote:
> >> On Sat 13/Aug/2016 17:22:52 +0200 Dave Crocker wrote:
> >>>
> >>> [...]  With DKIM, trust assessment is of the entity doing the
> >>> signing, typically the originating service.  With ARC, that
> >>> assessment still must be made, but it must be coupled with an
> >>> assessment of the first ARC-signing entity.
> >>>
> >>> Maybe that's not a big deal.  But I think that combinatorial
> >>> trust assessments are new and therefore might be challenging.
> >>
> >> That challenge can only be accepted by mailbox providers who are
> >> large enough to maintain a statistically meaningful perspective of
> >> global Internet mailing.  Smallish MTAs will likely have to take
> >> recourse to dnswl.org, possibly after some more attempts at
> >> creating protocol-specific white lists.
> >>
> >> Formal criteria to establish when valid ARC fields can inhibit
> >> DMARC's policy would seem to be better suited for protocol
> >> specifications.  I proposed ARC-0, but there may be better methods
> >> than that.
> >> [...]
> >
> > With ARC, one's MTA could do the DKIM check, fix the message, and
> > then ARC sign the result.
>
> How can that ARC set be used by the next hop?  *Guidance for receivers*
> is based on /sufficient history/:
>
>Final message recipients may or may not
>choose to examine these results when messages fail other
>authentication checks.  They are more likely to override, say, a
>failing DMARC result in the presence of an intact ARC chain where the
>participating ARC message handlers have been observed to not convey
>"bad" content in the past, and the initial ARC participant indicates
>the message they received had passed authentication checks.
>
> Say A -> B -> C are the MTAs:  C sees a message where B is cited in the
> To: or Cc: header fields.  The message is ARC signed by B.  B says A's
> DKIM signature was good, but now it is broken.  A's DMARC policy says
> that C should reject in that case.  What should C do?
>
> If C is gmail, it likely has sufficient history to know how A and B
> behave.  But what about small MTAs whose email flow is statistically not
> enough to use combinatorial trust assessments?
>

If your MTA is too small to use combinatorial trust assessments, then you
are stuck
with the same two options you have today: manual whitelists or using a
service to
give you that information.

If you're small enough, I don't think manually whitelisting the mailing
list servers your users
are subscribed to would be that challenging, especially if you receive the
DMARC reports your
server generates.

If A had added a second DKIM signature, signing just the To: or Cc:
> field(s) which cited B, with l=0 for the body, then that signature
> likely survived B's fixing and hence C could infer that B is a true (not
> self-styled) forwarder.  IOW, A's second (weak) signature provides C
> with a formal criterion to instruct its local policy to accept email
> that fails the DMARC mechanism check even if A has published a "reject"
> policy.
>
> So, what I called ARC-0 in my former proposal, doesn't really have much
> to do with ARC.  The concept is weak signatures.  Of course, they won't
> work unless carefully standardized and implemented.  The question is if
> they will ever work at all, and if this WG is willing to consider them.
> If not, we need to address Dave's concern some other way, or resign
> ourselves to building a solution which will likely work 98.7% for some
> and 0.2% for others.
>

So, any message sent from A to B can then be used as a replay with any
content to any party as long
as the To/Cc are intact?  That seems pretty useless.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarc-escape draft available

[Brandon Long]

Gmail will display the Sender information with a on behalf of or similar in
certain circumstances when we think its necessary to give the user more
information.

99% of users won't use the more information for anything useful or even
really notice it or at best get confused, but eh.

More information: https://support.google.com/mail/answer/1311182?hl=en

So, the messages on this list have via ietf.org next to the author, for
example.

Brandon

On Wed, Apr 22, 2015 at 10:58 AM, Douglas Otis doug.mtv...@gmail.com
wrote:



 On 4/21/15 4:20 PM, Terry Zink wrote:
  Some quick comments:
 
  - Section 3 is really short. Some examples of how it would work would be
 nice.
  - Regarding this from section 3:
 
This makes an assumption users employ Mail User Agents that
 display the
identity contained in the Sender header field when used as a basis
for acceptance.
 
I've tested Hotmail and Gmail and both suppress the Sender: header in
 favor of the 5322.From address. Conversely, Outlook and Outlook Web Access
 (OWA) show it as sender on behalf of from.
 
  -- Terry
 

 On 4/21/15 4:20 PM, Terry Zink wrote:

  Some quick comments:
 
  - Section 3 is really short. Some examples of how it would work would be
 nice.
  - Regarding this from section 3:
 
This makes an assumption users employ Mail User Agents that
 display the
identity contained in the Sender header field when used as a basis
for acceptance.
 
I've tested Hotmail and Gmail and both suppress the Sender: header in
 favor of the 5322.From address. Conversely, Outlook and Outlook Web Access
 (OWA) show it as sender on behalf of from.
 
  -- Terry

 Dear Terry,

 You make a good point. I consider sender on behalf of
 from a reasonable approach. It takes seconds using OS X
 Mail (Mail, Preferences, Viewing, Show message headers:
 custom, type Sender) to display the Sender header.  It is
 not displayed when it is not there of course, nor is this
 setting the default.

 For Thunderbird, users will need to access Preferences,
 Advanced, General tab, click Config Editor, Enter
 mail.compose.other.header and double click
 mail.compose.other.header entry and type the desired headers
 in the string dialog.  For other MUAs beyond Outlook, Mail,
 and Thunderbird, this may require plugins or similar
 tinkering.  Nonetheless, Sender header protection is
 available and likely something better configured using a
 script offered by the provider.

 In the early days when working with Iconix, they were able
 to offer fairly comprehensive coverage for web access and
 MUA using javascript overlays with company icons.  This
 improved source trust based on verification methods then
 available.  It seems these MUAs offer proof it can be done
 and Iconix proved people could understand the results.  This
 seems rather important since it is the Sender being trusted
 in most cases; the result of mail's store and forwarding
 protocol. DKIM and SPF only offer assurances between hops.
 Use of IM-From better protects the role of author and
 enables improved availability for direct paths while also
 offering greater flexibility at adding easily noticable
 information.

 http://tools.ietf.org/html/draft-otis-dmarc-escape-00


 Regards,
 Douglas Otis

 ___
 dmarc mailing list
 dmarc@ietf.org
 https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] yet more From rewriting,

[Brandon Long]

On Thu, Oct 2, 2014 at 7:23 PM, John Levine jo...@taugh.com wrote:

  The typical reaction to the disruption they created was to translate
 their
  p=reject into p=quarantine.
 
 Would you provide some proof of this assertion?

 I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
 publishing p=reject.


We didn't change anything at that point.  We already had code for treating
some specific cases as p=quarantine where we expected the messages were
unable to pass SPF or DKIM.  Its not a blanket thing, and we expect it will
be tightened up over time ... especially if phishers figure out how to
spoof it.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage

[Brandon Long]

On Sun, Sep 14, 2014 at 12:34 PM, Scott Kitterman skl...@kitterman.com
wrote:


 I can (an plan to) write code that leverages their X-Original-To.  I'd
 rather have something standardized, but it's not essential for me to solve
 the problem I'm having. For the broader internet, I'm not so sure.


(assuming you meant X-Original-From):

Theoretically, this seems fine... as long as you don't display the results
directly in the UI, since that would defeat the whole purpose of DMARC and
re-writing the From in the first place.

As for why we did that, its kind of a our default to add an X-Original or
X-Google-Original prefix when rewriting headers.  We're still debating
whether or not we should do anything more with it, or adjust how we
generate reply-to headers in these cases... or even add the author to the
list footer, but there's been no burning need so far.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Draft DMARC working group charter

[Brandon Long]

In favor as written.

Brandon


On Tue, Jul 1, 2014 at 11:38 AM, Terry Zink tz...@exchange.microsoft.com
wrote:

  I am in favor of it, as written, as well.



 -- Terry



 *From:* dmarc [mailto:dmarc-boun...@ietf.org] *On Behalf Of *Mike Jones
 *Sent:* Tuesday, July 1, 2014 11:20 AM
 *To:* Douglas Otis; Dave Crocker
 *Cc:* Pete Resnick; dmarc@ietf.org; Barry Leiba
 *Subject:* Re: [dmarc-ietf] Draft DMARC working group charter



 I believe the WG charter is adequate as written.  The activities described
 in section one of the working group activities addresses third-party email
 and DMARC.  That section says that the working group will document the
 effects of DMARC on such mail flows and consider mechanisms for reducing
 or eliminating DMARC's effects on indirect mail flows.



 I am in favor the of the WG charter as written.



 Thanks,

 Mike







 On Tue, Jul 1, 2014 at 10:45 AM, Douglas Otis doug.mtv...@gmail.com
 wrote:



 On Jul 1, 2014, at 9:00 AM, Dave Crocker dcroc...@gmail.com wrote:



  On 6/20/2014 12:38 PM, Dave Crocker wrote:

  Here is some draft text to consider for a DMARC working group charter:



 G'day,

 I've looked over the small amount of mail posted about the draft charter
 and do not see any changes mandated.

 Apologies if I've missed something, and I assure you it wasn't
 intentional.  So please do re-state the suggestion.

 Otherwise, I think the major question now is whether there is general
 consensus on submitting this draft charter text to the IESG?



 Dear Dave,

 I do not think the charter is adequate.  It needs to address the topic
 related to authorizing third-party use.  Otherwise, it is not possible to
 address the resulting disruption when reject is ever desired in conjunction
 with a mixed use domain.   At this point, it seems wrong to expect this
 problem will somehow evaporate.

 Several have suggested things like DKIM-Delegate, CDKIM, and the like.
  Frankly, your DKIM-Delegate distributes less data than would using the
 TPA-Label.  However,  TPA-Label requires much smaller DNS resources
 assuming public key retraction is to remain an important control aspect.
  IMHO, reliance on expiry represents a poor option.

 Improvements in DMARC features (identifier alignment, reporting, policy

 preferences) will be considered, such as:



- Enumeration of data elements required in Failure reports

 (specifically to address privacy issues)

- Handling potential reporting abuse

- Aggregate reporting to support additional reporting scenarios

- Alternate reporting channels

- Utility of arbitrary identifier alignment

- Utility of a formalized policy exception mechanism


   +- Domain Federation or Authorization scheme.  See DKIM-Delegate or
 TPA-Label drafts as examples.
  Our company is willing to work with any large ISP to demonstrate use
 of TPA-Label.


 http://tools.ietf.org/html/draft-otis-tpa-label


 Such a conclusion is easily supported since only the DMARC domain receives
 feedback necessary to acknowledge and mitigate abuse of the From header
 field.  As such, ONLY the DMARC domain is able to indicate which other
 domains are permitted (authorized or federated).
 Phishing and spoofing is an extremely serious problem NOT addressed using
 anti-SPAM techniques. If there is some time available in any upcoming
 meeting, I would like to take a few minutes to review this matter and
 relate our company's experience.


 Regards,
 Douglas Otis








 ___
 dmarc mailing list
 dmarc@ietf.org
 https://www.ietf.org/mailman/listinfo/dmarc







 ___
 dmarc mailing list
 dmarc@ietf.org
 https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc