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

[Hector Santos]

On 8/19/2017 3:48 AM, Bron Gondwana wrote:


For what it's worth, the ONLY one of these which my "fake Brandon"
email would have failed to validate for is p=reject, arc=none.  A
chain of valid ARC seals is so easy to fraudulently create that it's
not funny.

Everything other than arc=all there is totally pointless - if you can
intercept and modify email, you can easily add ARC headers that
maintain a complete chain is seals.

Now arc=site2.com,site3.com,site4.com - that's valuable.


I agree. That is what the ATPS (Authorized Third Party Signature) and 
the ASL (Authorized Sender List) proposals was all about.


 https://tools.ietf.org/html/rfc6541

Check out this wizard that helps generate the appropriate ATPS records 
and/or ASL extended DMARC tags:


http://www.winserver.com/public/wcdmarc/default.wct

But many feel it doesn't scale.  We also called it a "registration" 
problem, i.e. how to get that authorized list, etc.   What has been 
going since then is to develop a method to inherently pass this 
information via the headers.  Thats been hard to understand since we 
are already making a DMARC DNS lookup that perpetuates all this.   We 
are just not getting enough information to properly work with it.



You could
say "only allow ARC through the following intermediate domains" - and
then you could add those to your allowed list for your domain as you
got reports of validation failures and user requests.  Over time a
domain would build a list of mail flows that its users used.   You
could even use a different selector for each sending user, and publish
a different policy for that selector, so each user got their own
allowed mail flows!

But anything that's based on count/position of seals in the chain,
that has no value.


I fully concur with the "level of "experimentations" that would give 
all parties, a payoff they can realize and the capability to design a 
logical integrated system and negotiate3ed protocol without kludges 
and also apply some  "Deep Learning" to help with the indeterminate 
conditions.


We have determinate conditions with the strong policies.  These MUST 
be honored or nothing works. This is the DKIM POLICY LAYER MODEL. The 
indeterminate conditions are the relaxed policies leaving it up to the 
receiver to explore algorithms. This is the DKIM TRUST/REPUTATION 
LAYER MODEL.  The DKIM standard purposely removed the Policy Layer 
with the hope the trust layer would prevail.  Many folks did not like 
this decision. It was extremely rough and we didn't have other 
developers, such as yourself around.


But as expected, it didn't happen and the problems we are seeing is 
due to that separation.  That said, I still expect it to happen 
because Policy gives us the first level automation (thanks to DMARC), 
and Trust/Reputation is the 2nd level to help with the fuzzy 
conditions. This is where it will be a vendor-based added value 
component to DKIM, as it was designed to be and should be. But as it 
was always stated, not everyone is going to use the same 
"Trust/Reputation" databases.  I called that the "Batteries Required" 
dilemma.


--
HLS


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

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

[Bron Gondwana]

On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote:
> On 8/16/2017 8:21 PM, Bron Gondwana wrote:
>> On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
>>> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:
>>> 
>>>   On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:
>>> 
>>> If we even have a DMARC ARC Policy concept, than that may be
>>> enough to begin pursuing the high cost of experimentation and
>>> development here.
>>> 
>>> 
>>>   Beyond the protocol and usage specs, what are you looking for?
>>> 
>>> 
>>> A practical purpose for supporting (implementing) this work.   It
>>> appears ARC wants the network to stamp mail "blindly" as the mail
>>> travels from point to point.  I am trying to grasp how it helps
>>> resolve the main issue with "unauthorized" indirect 3rd party
>>> signatures, in particular when dealing with strong, exclusive DKIM
>>> signature policy models such as DMARC p=reject.
>> 
>> We spent a while thinking about this (Neil and myself from FastMail)>> at 
>> IETF99 after learning how ARC works, and came to the conclusion
>> that ARC as specified can't help with DMARC p=reject.
>> 
>> 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.
> 
> The MLS (Mail List Server) cam also reject submissions from
> restrictive (p=reject) domains because that MAY be the intent of the
> originating author domain.   The MLS can so prohibit new subscriptions> by 
> verifying the user's domain is not restrictive.
> 
> We need more protocol information from what extracted from DMARC.  As> I see 
> it, these are some of the boundary conditions:
> 
> DMARC p=reject;  arc=none;   ignore ARC, same as no arc= tag
> DMARC p=reject;  arc=all;reject if any arc seals is
> invalid> DMARC p=reject;  arc=first;  don't reject if first arc 
> seal is> valid
> DMARC p=reject;  arc=last;   don't reject if last arc seal is> valid
> DMARC p=reject;  arc=first,last; don't reject if first and last
> arc seals are valid

For what it's worth, the ONLY one of these which my "fake Brandon" email
would have failed to validate for is p=reject, arc=none.  A chain of
valid ARC seals is so easy to fraudulently create that it's not funny.
Everything other than arc=all there is totally pointless - if you can
intercept and modify email, you can easily add ARC headers that maintain
a complete chain is seals.
Now arc=site2.com,site3.com,site4.com - that's valuable.  You could say
"only allow ARC through the following intermediate domains" - and then
you could add those to your allowed list for your domain as you got
reports of validation failures and user requests.  Over time a domain
would build a list of mail flows that its users used.   You could even
use a different selector for each sending user, and publish a different
policy for that selector, so each user got their own allowed mail flows!
But anything that's based on count/position of seals in the chain, that
has no value.
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Hector Santos]

On 8/16/2017 8:21 PM, Bron Gondwana wrote:

On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:

On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:

On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:

  If we even have a DMARC ARC Policy concept, than that may be
  enough to begin pursuing the high cost of experimentation and
  development here.


Beyond the protocol and usage specs, what are you looking for?


A practical purpose for supporting (implementing) this work.   It
appears ARC wants the network to stamp mail "blindly" as the mail
travels from point to point.  I am trying to grasp how it helps
resolve the main issue with "unauthorized" indirect 3rd party
signatures, in particular when dealing with strong, exclusive DKIM
signature policy models such as DMARC p=reject.


We spent a while thinking about this (Neil and myself from FastMail)
at IETF99 after learning how ARC works, and came to the conclusion
that ARC as specified can't help with DMARC p=reject.

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.


The MLS (Mail List Server) cam also reject submissions from 
restrictive (p=reject) domains because that MAY be the intent of the 
originating author domain.   The MLS can so prohibit new subscriptions 
by verifying the user's domain is not restrictive.


We need more protocol information from what extracted from DMARC.  As 
I see it, these are some of the boundary conditions:


   DMARC p=reject;  arc=none;   ignore ARC, same as no arc= tag
   DMARC p=reject;  arc=all;reject if any arc seals is invalid
   DMARC p=reject;  arc=first;  don't reject if first arc seal is 
valid
   DMARC p=reject;  arc=last;   don't reject if last arc seal is 
valid
   DMARC p=reject;  arc=first,last; don't reject if first and last 
arc seals are valid


arc=none (or no arc= tag) means the domain has no interest whatsoever 
in ARC. It is a highly exclusive restricted domain and it expects that 
complaint DMARC readers will honor the policy.  No interference.  This 
is the highest payout with the highest security value.


It gets more relax with the others; first or last or first and last, 
but with arc=all it is a tougher condition that requires all seals to 
be valid.  If any fails, reject.


I would also try to get more bang for the buck with a tag that could 
informs MLS to honor the DMARC p=reject policy by restricting users 
from a) subscribing and b) submitting list mail from restricted 
p=reject domains, although I think such a tag is needed to tell the 
MLS this. It should be a requirement, imo, cross all the teas, dot all 
the eyes.  If the MLS knows its going to be problematic, it should 
restrict the subscription and submission to relax policies only.


--
HLS


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

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

[Hector Santos]

On 8/18/2017 2:10 PM, Murray S. Kucherawy wrote:


Of course, the danger of proceeding along that line is that we do
establish a deployed base, however small, that will be difficult to
change later.


+1


I don't know the answer to that question immediately,
and admittedly I'm only going to be on the periphery of cleaning up
whatever mess results.


Well, we should know this by now.  Are we in a project research or 
product research phase here?  We are well beyond the proof of concepts 
here.  We all know what the problems are when a DKIM Policy Model 
offers a method to handle strong, exclusive, restrictive polices 
whether it was SSP/DomainKeys o=-, ADSP DISCARDable and now DMARC 
p=reject.


IMO, there is nothing new added to the table other than more overhead, 
a ARC chain, across the transport path. Highly sensitive to breakage, 
until the originating domain says something about it, I don't see how 
it resolves the original problem.


I suggest the simplest solution is to augment ARC with an extended 
DMARC tag that informs receivers that its "OK" to relax p=reject only 
under X% ARC seal conditions  It could be 100% or it be partial, 
fuzzy, "SoftFail" concept, whatever.  Let the Originating Author 
Domain decide.


This would offer a reason to support ARC, to explore the 
experimentation, and best of all, we won't have the design change 
pressures to deal with the borderline "illegal," "unethical" 5222.From 
rewriting methods/kludges.  Lets remember it remains to be the only 
hash binding header requirement by DKIM.


--
HLS


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

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

[Murray S. Kucherawy]

On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana 
wrote:

> On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
>
> On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long  wrote:
>
> 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.
>
>
> I wrote a draft a while ago that would allow a DKIM-Signature to include
> an annotation indicating that the signing ADMD did one or more of a
> specific set of small but well-defined message changes (e.g., add a footer,
> add a Subject tag).  Knowing what those are, a verifier could undo them and
> attempt validation of earlier signatures in the handling chain.  Presumably
> if no other modifications were made, the original content is thus
> discoverable, and you could then produce a chain of custody of the actual
> content before you that makes sense.
>
> If that's worthy of consideration now I could certainly revivify it.
>
>
> That seems really valuable to me.  Being able to track the provenance on
> individual parts of the message payload is a much stronger way to determine
> who is at fault when bad content is being injected than just knowing some
> bits of the message handling chain.
>

https://tools.ietf.org/html/draft-kucherawy-dkim-transform-00

The notion of tracking provenance is secondary to being able to recover and
evaluate the original content signed by the originating ADMD.  You could in
theory get that signature to pass again, which would satisfy DMARC.

The transformations it covers could easily be augmented to include Subject
tagging, or even non-MIME footer attachment using the "--" delimiter.

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

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

[Hector Santos]

On 8/16/2017 9:32 PM, Seth Blank wrote:

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

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.


So this is an excellent and crucial point that has been discussed
again and again on and off this list.

ARC only works if critical mass can be reached - both of
intermediaries who break DKIM and receivers who evaluate ARC.


Of course.  But in my opinion, the real problem, I thought, was 
finding a solution to the old DKIM Policy Model problem that began 
with SSP and ADSP, a proposed standard and now DMARC.  They all had 
the same issue. As a strong policy DKIM working group advocate, I was 
the one that illustrated the problem (the auto-unsubscribe issue).


DMARC did not resolve the reason ADSP was abandoned.  DMARC only 
obtained popularity first as a reporting mechanism which I thought was 
redundant.  It didn't prove anything beyond we already knew which was 
when a Strong Rejection was honored by receivers, it had a very high 
payoff value, so such, eventually, big domains supported it.  But it 
also eventually shows what we already knew what will happen -- it will 
cause mailing list "auto-unsubscribe" problems with accumulated failed 
Policy rejections.  This was well documented.


So if everyone supported some of the proposals which is far better 
than ARC to resolve this problem, then we would of ended this long 
time "project research" at least 4-6 years ago.


Right now, ARC is asking to stamp the mail with additional overhead. 
Its the first time I believe, that attempts to follow Dave Crocker's 
old ideas on Chain of (Mail Transport) Trust.


ARC can possibly help in that area but only if it resolves the 
unauthorized re-signer problem. That would basically mean that at 
least 1 ARC Seal only needs to be trusted, and that would be the first 
and/or last signer.  We always get back to this 100% versus less than 
100% problem and with ARC, it can be inherently or explicitly stated 
what is required.


   1) If all seals are valid, the chain is not broken, then is this an
  acceptable condition for a receiver to accept what would be 
otherwise

  a DMARC failed P=REJECT action?

   2) What if one fails?

We should let the Originating Authoring Domain have some say in all 
this.  Its how I would like to have my restricted domains treated and 
protected. I will do the same with other restricted domains.



Fundamentally, ARC will never reach critical mass if senders now also
need to enter into the equation with an additional flag on their DMARC
record. This is too high a bar and increases the interoperability
problems as opposed to reducing them.


I don't see that.  We are already creating DMARC records which is the 
big gain over ADSP. And it appears sufficiently enough to support the 
strong "DKIM Policy" p=reject concept.  But we had the same problem 
with SSP and ADSP, a IETF Proposed Standard.  The problem is that it 
didn't reach critical mass, and we also said that it didn't need to 
reach critical mass because it was well understood it would be a 
limited stream.


Yes, the protocol needs to start somewhere and if we don't offer an 
augmented policy concept for ARC, then I just don't see myself 
supporting it until there is some inherent or explicit declaration by 
the Author Domain that the payoff can be high by supporting it.  ARC 
does not have that.



For now, there is a clear unanswered question: what coverage of
receivers is needed for most mailing lists to achieve stable delivery
once ARC is in the mix?


This can leave a hole that is problematic if we continue on a critical 
mass reason to exist.  What will happen when all mail is ARC sealed 
but only 5% or 10% of the domains used p=reject.   You need to have a 
declaration somewhere about what 100% or less than 100% means as part 
of protocol because if ARC does not, then there will be a high 
overhead of legacy mail and domains didn't declare anything and ARC is 
suppose to be a way to ignore "p=reject" policies.


At some point, you will have to say

 "IF you want to use P=REJECT, then you MUST|SHOULD support ARC and
  only use send signed mail on streams that use ARC seal.  This will
  allow your users to use the restrictive domains in public 
environments

  which be against the domain wishes."

The problem?

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

[Bron Gondwana]

On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
> On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long
>  wrote:>> 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.> 
> I wrote a draft a while ago that would allow a DKIM-Signature to
> include an annotation indicating that the signing ADMD did one or more
> of a specific set of small but well-defined message changes (e.g., add
> a footer, add a Subject tag).  Knowing what those are, a verifier
> could undo them and attempt validation of earlier signatures in the
> handling chain.  Presumably if no other modifications were made, the
> original content is thus discoverable, and you could then produce a
> chain of custody of the actual content before you that makes sense.> 
> If that's worthy of consideration now I could certainly revivify it.

That seems really valuable to me.  Being able to track the provenance on
individual parts of the message payload is a much stronger way to
determine who is at fault when bad content is being injected than just
knowing some bits of the message handling chain.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Murray S. Kucherawy]

On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long  wrote:

> 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.
>

I wrote a draft a while ago that would allow a DKIM-Signature to include an
annotation indicating that the signing ADMD did one or more of a specific
set of small but well-defined message changes (e.g., add a footer, add a
Subject tag).  Knowing what those are, a verifier could undo them and
attempt validation of earlier signatures in the handling chain.  Presumably
if no other modifications were made, the original content is thus
discoverable, and you could then produce a chain of custody of the actual
content before you that makes sense.

If that's worthy of consideration now I could certainly revivify it.

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

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

[Bron Gondwana]

On Sat, 19 Aug 2017, at 04:51, Brandon Long wrote:
> 
> 
> 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 think I agree with you here - that keeping AS but breaking old ones by
removing AMS is the opposite of useful.
> 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).
Before I joined - maybe I should read back further!  This makes sense to
me, certainly two separate signatures (AS and AMS) is wasteful and
meaningless.  Which one the signature actually sits on doesn't matter at
all from a topological viewpoint, only what the signature covers
matters.  A signature on the AS which signed an AMS-like header that was
just a hash over the content would be fine.  Having the AMS-like header
calculated in such a way that if a site didn't modify the content of the
message, it also didn't modify the AMS hash would be super fine.
As a matter of fact, I really like this.  An AMS that doesn't have a
signature, but covers the content in a repeatably defined way, and
possibly even a way that can adapt to minor changes (changing from
address, stripping or adding MIME parts, etc) such that modifiers could
modify in a way that allowed provenance of the bulk of the message
payload to be tracked through them.  Being able to assert "I only
modified the message in these ways" in a way that could be verified
would be fantastic as an intermediate - and it would stop me doing what
I did in my last email and completely faking a valid ARC chain on a fake
message from Brandon.  I could only modify the message in limited ways
without tipping my hand.
> Another option would be to change our expectations, that is to say
> that signing by non-modifying hops is optional.
For sure.  Either changing ARC so that non-modifying hops sign but don't
change the AMS-like hash (so it's clear they didn't modify), or saying
that signing by non-modifying hops is at least a SHOULD NOT.
My goal with everything that I'm suggesting is to increase the ability
to determine provenance of the message payload.  The mail flow itself is
always going to be easily faked.[1]
DKIM doesn't assert anything about mail flow - you can receive a DKIM-
signed message and regardless of the route it's traveled, you know that
the payload was unmodified since it left the jurisdiction which had
access to the private key for its signing domain.
ARC as currently defined is weak on maintaining provenance on the
payload.  But provenance on the payload is what really matters, because
falsifying the payload is where attacks against email integrity get
their value.
Bron.

[1] footnote on this - I have alluded to crypto header rewriting such
that you can't rewind.  I'll write a separate email on that topic.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com

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

[Bron Gondwana]

On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote:
> On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker
>  wrote:>> On 8/18/2017 10:00 AM, Seth Blank wrote:
>>>
>>> Right now, we've got deployed code that we know works and improves
>>> the landscape. Everything else is - rightly or wrongly - conjecture.>> 
>> 
>> Personal Point of order:
>> 
>> Using an 'installed base' argument for a brand new specification
>> that is still in development and has minuscule deployment is not
>> appropriate, in spite of having a long and storied history of
>> being used to resist a proposal.>> 
>> What's supposed to happen with a proposal is an evaluation of its
>> technical and functional merits.>> 
>> 
>>  The entire point behind bringing a nascent specification to the IETF
>>  is to get review and suggestions from a wider audience.> 
> While I would normally agree firmly with that position, my view in
> this case is softer given what I believe was consensus (I'm not the
> chair, so that's not my call officially) that we're going to go for
> Experimental status.> 
> I submit that our primary mission here per our charter is to come up
> with a mechanism that mitigates DMARC's damage to mailing lists.  The
> claim that ARC as designed over-engineers a solution seems secondary
> to me; the question we need to answer is "Can this mitigate the
> damage?"  With or without Bron's reduced design, that's the question
> before us.
Yes, this is the crux of the question. 

> The "snake oil" claim may be true but it's orthogonal to that core
> question, and moreover points to the way we describe what exactly ARC
> provides ("chain of custody" is clearly not appropriate given that we
> are no longer sure what that actually covers), independent of whether
> it tells us enough to solve the question at hand.> 
> Accordingly, I would suggest we continue to deploy and experiment with
> the specification as-is, because there are implementations now, until
> we've determined that ARC as currently defined does or does not
> address DMARC's mailing list issues.  I also suggest that an appendix
> be added acknowledging that the super-crypto of ARC-Seal may be
> superfluous, and at the conclusion of the experiment we can make a
> decision about removing it and moving more toward what Bron's
> suggesting.> 
> Of course, the danger of proceeding along that line is that we do
> establish a deployed base, however small, that will be difficult to
> change later.  I don't know the answer to that question immediately,
> and admittedly I'm only going to be on the periphery of cleaning up
> whatever mess results.
Well, let's have a look at the question - can ARC mitigate the damage?
It depends what p=reject means.
Right now Brandon can't email this list with his bl...@google.com
address, because google.com publishes a p=reject record.  If the
list supported ARC, he could email this list and receivers which
supported ARC would accept the email from the list despite the
p=reject record.  Yay.
I could also take a message from the list, rewrite the subject and
content to be my own, sign it with my own key from my own domain, send
that to somebody as it if had come from Brandon, and assuming they
supported ARC, they would also accept that email, depite the p=reject
record.  Boo.
p=reject no longer stopped me sending a fraudulent email claiming to be
from Brandon with a "From:" of his official work address.
The receving site now needs to run heuristics including content analysis
and trust metrics on every hop in the ARC chain to determine whether to
accept the message.  That's fine, but we've basically mitigated DMARC
breakage of mailing lists by rolling back the meaning of DMARC p=reject.
Anyone can create an ARC seal on any email.  It doesn't even have to
have an original ARC seal on it.  Attached is an email which purports to
be from Brandon and has a valid ARC-Seal on it (assuming my code works
correctly - it adds the c= parameter now after Seth pointed out that
opendkim doesn't handle leaving it out).  Somebody from Google might be
able to tell which email I based this on (an email on Aug 9th to this
list and CCd to me which then got resent from a different address)
This will be accepted by an ARC-aware receiver unless I'm on a
blacklist, despite the p=reject.
Creating a new domain and putting a key in its DNS is pretty trivial -
so I guess the question is, what is ARC  doing other than rolling back
DMARC p=reject entirely?  We'd better think about that deeply, because
spammers/scammers sure will be.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


ARC-Seal: i=1; a=rsa-sha256; cv=pass; d=brong.net; s=fm1; bh=47DEQpj8HBS
a+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=y0Ij74LsWe7dYsdSS95iwW6T8Xn
w7bs/W8U2dvtKNtK3lJi+IBiS0eluFbRG+O6RRrNI9oOXiTN9sY1sIbLjjmv54hv
K9wbKePCMVxlHz0J/OxBmmwxgLkijKY9J9WxmW6I/N+BTeVZCCkJPYdJknReSwCA

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

[Dave Crocker]

On 8/18/2017 11:10 AM, Murray S. Kucherawy wrote:


While I would normally agree firmly with that position, my view in this 
case is softer given what I believe was consensus (I'm not the chair, so 
that's not my call officially) that we're going to go for Experimental 
status.


I submit that our primary mission here per our charter is to come up 
with a mechanism that mitigates DMARC's damage to mailing lists.  The 
claim that ARC as designed over-engineers a solution seems secondary to 
me; the question we need to answer is "Can this mitigate the damage?"  
With or without Bron's reduced design, that's the question before us.



Going for Experimental does not relieve the working group from trying to 
do careful engineering.


I'm sure you didn't mean to suggest otherwise, but fear that the result 
will be publishing a spec for something that is more complicated than it 
needs to be or less well understood than it needs to be.  Or both.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Bron Gondwana]

On Fri, 18 Aug 2017, at 16:46, 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.
The problem with the verifiable chain of custody trace is that isn't
actually verifiable, because anybody can break an old chain at any point
and mint a new link that looks as if the message was sent to them.
You can take an email that went

A => B => C => D => E with an intact ARC chain and chop the top off,
edit everything and create:
A => B => X => Y

If you're X, and there's no way to tell from the ARC headers that B
didn't originally send a message to X.
> 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?

 On this I agree with Seth.  removing AMS breaks AS, and I see even less
 value in keeping AS if it doesn't even keep verifying all the way back
 to the start.

Bron.--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


___
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

[Murray S. Kucherawy]

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker  wrote:

> On 8/18/2017 10:00 AM, Seth Blank wrote:
>
>>
>> Right now, we've got deployed code that we know works and improves the
>> landscape. Everything else is - rightly or wrongly - conjecture.
>>
>
>
> Personal Point of order:
>
>Using an 'installed base' argument for a brand new specification that
> is still in development and has minuscule deployment is not appropriate, in
> spite of having a long and storied history of being used to resist a
> proposal.
>
>What's supposed to happen with a proposal is an evaluation of its
> technical and functional merits.
>
>
> The entire point behind bringing a nascent specification to the IETF is to
> get review and suggestions from a wider audience.


While I would normally agree firmly with that position, my view in this
case is softer given what I believe was consensus (I'm not the chair, so
that's not my call officially) that we're going to go for Experimental
status.

I submit that our primary mission here per our charter is to come up with a
mechanism that mitigates DMARC's damage to mailing lists.  The claim that
ARC as designed over-engineers a solution seems secondary to me; the
question we need to answer is "Can this mitigate the damage?"  With or
without Bron's reduced design, that's the question before us.

The "snake oil" claim may be true but it's orthogonal to that core
question, and moreover points to the way we describe what exactly ARC
provides ("chain of custody" is clearly not appropriate given that we are
no longer sure what that actually covers), independent of whether it tells
us enough to solve the question at hand.

Accordingly, I would suggest we continue to deploy and experiment with the
specification as-is, because there are implementations now, until we've
determined that ARC as currently defined does or does not address DMARC's
mailing list issues.  I also suggest that an appendix be added
acknowledging that the super-crypto of ARC-Seal may be superfluous, and at
the conclusion of the experiment we can make a decision about removing it
and moving more toward what Bron's suggesting.

Of course, the danger of proceeding along that line is that we do establish
a deployed base, however small, that will be difficult to change later.  I
don't know the answer to that question immediately, and admittedly I'm only
going to be on the periphery of cleaning up whatever mess results.

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

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

[Seth Blank]

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker  wrote:

> On 8/18/2017 10:00 AM, Seth Blank wrote:
>
>>
>> Right now, we've got deployed code that we know works and improves the
>> landscape. Everything else is - rightly or wrongly - conjecture.
>>
>
>
> Personal Point of order:
>
>Using an 'installed base' argument for a brand new specification that
> is still in development and has minuscule deployment is not appropriate, in
> spite of having a long and storied history of being used to resist a
> proposal.
>
>What's supposed to happen with a proposal is an evaluation of its
> technical and functional merits.
>


So let me be very clear, because I wasn't rehashing earlier conversations
from this thread:

Right now, everything in ARC serves a purpose, and the AS, AMS, and AAR are
all defensible.

As we've clarified ARC and dug into putting appropriate data into the AAR,
the usefulness of the AS has gotten less apparent - but it still serves
several purposes and has been explicitly asked for by several members of
the working group.

Right now, there is one person - with a valid concern - asking if we really
need the AS. That conversation was dug into on list, and the consensus
(which that person agreed to) was that his concerns might be right, but the
point could be argued over forever with valid stances from both sides, or
determined on its merits quite quickly once the ARC experiment begins.

My point is, we can actually begin the experiment now. The open technical
concerns are around "will this piece matter?" and they're more
philosophical than technical (except for the AS concern, which might be
practical) - but the data to answer them is at our fingertips, so let's go
get the data.

Seth



>
>
> The entire point behind bringing a nascent specification to the IETF is to
> get review and suggestions from a wider audience.
>
>
> d/
>
>
> ps. Note that I haven't commented on the merits of this particular
> proposal.  I like the intent quite a bit, but haven't thought about the
> technical or operational aspects yet.
>
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 8/18/2017 10:00 AM, Seth Blank wrote:


Right now, we've got deployed code that we know works and improves the 
landscape. Everything else is - rightly or wrongly - conjecture.



Personal Point of order:

   Using an 'installed base' argument for a brand new specification 
that is still in development and has minuscule deployment is not 
appropriate, in spite of having a long and storied history of being used 
to resist a proposal.


   What's supposed to happen with a proposal is an evaluation of its 
technical and functional merits.



The entire point behind bringing a nascent specification to the IETF is 
to get review and suggestions from a wider audience.



d/


ps. Note that I haven't commented on the merits of this particular 
proposal.  I like the intent quite a bit, but haven't thought about the 
technical or operational aspects yet.



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Seth Blank]

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?

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

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

[Kurt Andersen]

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?

--Kurt
___
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 
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 
> 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.
>
>
> 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 how the message will be handled downstream - it depends on
> whether the recipient supports ARC, and you can't know that for sure.
>
> That's the big that makes me uncomfortable - ARC is defined in such a way
> that certain participants are unsure of whether they can safely keep
> sending legitimate email and have it accepted, because the interaction with

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

[Bron Gondwana]

On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote:
> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
>  wrote:>> I laugh as well, but it's more than 
> p=reject isn't enough in the ARC
>> world, because it doesn't distinguish between:>> a) I'm OK with email from 
>> my domain being sent via mailing lists; and>> b) no, this domain is only 
>> ever used for direct messages, it should
>>never appear in ARC chains that don't also pass DKIM.> 
> The DMARC WG charter directly addresses this:
> https://datatracker.ietf.org/wg/dmarc/charter/> 
> Our stated goal is to fix indirect mail flows so that they do not
> break under DMARC. To me, that's an explicit requirement of a), with
> b) being out of scope.
OK, so case (a) means that we are explicitly redefining the behaviour of
a DMARC receiver.  It should now accept messages that it used to reject,
because they have additional new headers.  Which means what - until it's
updated it now no longer compliant, or else it means (as I have just
responded to Brandon in what appears to be a split of this same thread)
that intermediate sites which modify messages are left in a limbo where
they have to guess what happens.
In one respect, that's no different than the situation now where
intermediate modifiers KNOW that they can't send on messages for
p=reject domains (or at least, they would know if they were DMARC-
aware).  But it does mean that workarounds for DMARC (like modifying the
from header) are needed for some time yet.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Bron Gondwana]

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
> 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.
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.
> 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 how the message will be handled
downstream - it depends on whether the recipient supports ARC, and you
can't know that for sure.
That's the big that makes me uncomfortable - ARC is defined in such a
way that certain participants are unsure of whether they can safely keep
sending legitimate email and have it accepted, because the interaction
with DMARC is defined in such a way that ARC *changes the behaviour of
DMARC* in a non-backwards-compatible way, and we will be running, for at
least a while, in a world in which some recipients treat DMARC the old
way (non-ARC-aware) and some treat it the new way.
So your only possible mitigation as the middleman, if you want full
deliverability, is to modify the message in such a way that DMARC no
longer applies to it.
Bron.

--
  Bron Gondwana, CEO, 

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

[Murray S. Kucherawy]

On Thu, Aug 17, 2017 at 11:48 AM, Seth Blank  wrote:

> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana 
> wrote:
>>
>> I laugh as well, but it's more than p=reject isn't enough in the ARC
>> world, because it doesn't distinguish between:
>> a) I'm OK with email from my domain being sent via mailing lists; and
>> b) no, this domain is only ever used for direct messages, it should never
>> appear in ARC chains that don't also pass DKIM.
>>
>
> The DMARC WG charter directly addresses this:
> https://datatracker.ietf.org/wg/dmarc/charter/
>
> Our stated goal is to fix indirect mail flows so that they do not break
> under DMARC. To me, that's an explicit requirement of a), with b) being out
> of scope.
>

+1.  My understanding is that altering DMARC is off the table right now.
We have to try to move forward.

I'm particularly opposed to adding a new "p=" value without a great deal of
thought put into it, lest the set of values there become hopelessly
polluted with things representing every conceivable combination of
authentication results and header field values, many of which will end up
being ephemeral.

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

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

[Murray S. Kucherawy]

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana 
wrote:

> On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
>
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana 
> wrote:
>
> 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.
>
>
> Goodness, it's a wonder that we've ever successfully deployed anything
> incremental around here.  ;-)
> -MSK
>
>
> I laugh as well, but it's more than p=reject isn't enough in the ARC
> world, because it doesn't distinguish between:
> a) I'm OK with email from my domain being sent via mailing lists; and
> b) no, this domain is only ever used for direct messages, it should never
> appear in ARC chains that don't also pass DKIM.
>
> The existing behaviour of p=reject is (b) for receivers that don't support
> ARC - so the question becomes:  are we defining ARC to changing the
> behaviour of p=reject to (a)?  If so, will we define a different (b) later,
> when we could instead have
> defined a different p= for (a).
>

My point is that the "SINGLE SITE" posture is absurd.  In all likelihood
there are still some MTAs out there that don't implement ESMTP and nothing
has melted.  We should fully expect things to roll out gradually, as they
always have.  Anyone planning for a flag day should speak up now so we can
disabuse them (and, of course, abuse them).

If the success of DMARC depends on 100% deployment of ARC, we may as well
pack up and go home now.  It'll never happen.

I support the idea of trying ARC even in the form you claim includes
superfluous operations.  (For the record, I find your technical argument
compelling.)  If after a period of experimentation and data collecting we
find that the seal is not itself useful, we can negotiate a reduced form
and try that.

If you really want to prove your point sooner, implement both, run them for
a while, and publish the results.  But given that there are interoperating
implementations now, I think there's enough to be learned from the
experiment to continue from here rather than reset.

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

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

[Seth Blank]

On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana 
wrote:
>
> I laugh as well, but it's more than p=reject isn't enough in the ARC
> world, because it doesn't distinguish between:
> a) I'm OK with email from my domain being sent via mailing lists; and
> b) no, this domain is only ever used for direct messages, it should never
> appear in ARC chains that don't also pass DKIM.
>

The DMARC WG charter directly addresses this:
https://datatracker.ietf.org/wg/dmarc/charter/

Our stated goal is to fix indirect mail flows so that they do not break
under DMARC. To me, that's an explicit requirement of a), with b) being out
of scope.

Seth
___
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] ARC-Seal is meaningless security theatre

[mham...@americangreetings.com]

On 8/17/2017 4:09 AM, Bron Gondwana wrote:

On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana 
> wrote:


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.


Goodness, it's a wonder that we've ever successfully deployed 
anything incremental around here.  ;-)

-MSK


I laugh as well, but it's more than p=reject isn't enough in the ARC 
world, because it doesn't distinguish between:

a) I'm OK with email from my domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should 
never appear in ARC chains that don't also pass DKIM.


You assume that mailing lists are the only corner case that ARC might 
address. It’s quite possible that this is not true. It's also not clear 
what you mean by "direct messages". When an agent does an MX lookup, it 
has no way of knowing whether the indicated MX host is the final 
destination or whether there are additional internal (to the 
administrative domain) or external hops beyond the initially indicated 
MX host. That's one of the things that makes the wonderful wacky world 
of email so interesting. While mailing lists are important to many, they 
are the tail and not the dog in the email world.


The existing behaviour of p=reject is (b) for receivers that don't 
support ARC - so the question becomes:  are we defining ARC to 
changing the behaviour of p=reject to (a)?  If so, will we define a 
different (b) later, when we could instead have

defined a different p= for (a).



This is absolutely an incorrect statement. Policy within DMARC, as 
expressed by p=, is a request by the sending domain and can always be 
ignored or overridden by local policy. Using ARC as an input is no 
different than any other input that a mailbox provider/validator 
considers in making delivery decisions.


The interesting question is what happens at non-updated sites in each 
case, because the answer is either "valid emails that should have been 
accepted are rejected by old policy engine" or "spoofed emails that 
should have been rejected are accepted by old policy engine"




In the DMARC world, emails are only valid in the sense that they pass 
either SPF or DKIM validation. A decision to accept or reject any given 
email involves many choices beyond simply passing DMARC validation for a 
given from domain. Spoofing may involve emails which pass DMARC 
validation but contain spoofing in the From display name, or any number 
of other ways.


Mike

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

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

[Bron Gondwana]

On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
>  wrote:>> 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.>> 
>> 
> Goodness, it's a wonder that we've ever successfully deployed anything
> incremental around here.  ;-)> -MSK

I laugh as well, but it's more than p=reject isn't enough in the ARC
world, because it doesn't distinguish between:a) I'm OK with email from my 
domain being sent via mailing lists; and
b) no, this domain is only ever used for direct messages, it should
   never appear in ARC chains that don't also pass DKIM.
The existing behaviour of p=reject is (b) for receivers that don't
support ARC - so the question becomes:  are we defining ARC to changing
the behaviour of p=reject to (a)?  If so, will we define a different (b)
later, when we could instead havedefined a different p= for (a).

The interesting question is what happens at non-updated sites in each
case, because the answer is either "valid emails that should have been
accepted are rejected by old policy engine" or "spoofed emails that
should have been rejected are accepted by old policy engine"
That's a worthwhile question.  Maybe it's already been asked and
answered and I just missed that.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Murray S. Kucherawy]

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

> 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.
>
>
Goodness, it's a wonder that we've ever successfully deployed anything
incremental around here.  ;-)

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

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

[Bron Gondwana]

On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
>  wrote:>> 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.> 
> So this is an excellent and crucial point that has been discussed
> again and again on and off this list.> 
> ARC only works if critical mass can be reached - both of
> intermediaries who break DKIM and receivers who evaluate ARC.> 
> Fundamentally, ARC will never reach critical mass if senders now also
> need to enter into the equation with an additional flag on their DMARC
> record. This is too high a bar and increases the interoperability
> problems as opposed to reducing them.> For now, there is a clear unanswered 
> question: what coverage of
> receivers is needed for most mailing lists to achieve stable delivery
> once ARC is in the mix? Knowing the landscape of receiving domains, I
> believe this to be a small number. From the above comments, I'm
> guessing you think this is a large number. We're not going to resolve
> this difference of opinion in an open forum. However, releasing ARC as
> an experiment into the wild for major lists like the IETF and M3AAWG
> will give us very clear data very quickly on what the actual landscape
> looks like, and what ARC does and does not solve.> 
> In its current form, ARC only helps mail flows, it does not harm them.
> How effective this improvement is remains to be seen, but preliminary
> information I've been hearing about (which could be totally wrong)
> makes it seem like the improvements are dramatic. So let's get ARC
> tied off as an Experiment (thank you, Dave Crocker), collect some
> data, and see where things stand. Maybe things are great and ARC can
> move to proposed standard. Maybe it fundamentally needs more receivers
> in the mix than currently expected, and some fix for that is needed.
> But we'll know that after the experiment has begun, not before.
Seems reasonable.  We will deploy it at FastMail for sure and
collect data.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Seth Blank]

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana 
wrote:
>
> 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.
>

So this is an excellent and crucial point that has been discussed again and
again on and off this list.

ARC only works if critical mass can be reached - both of intermediaries who
break DKIM and receivers who evaluate ARC.

Fundamentally, ARC will never reach critical mass if senders now also need
to enter into the equation with an additional flag on their DMARC record.
This is too high a bar and increases the interoperability problems as
opposed to reducing them.

For now, there is a clear unanswered question: what coverage of receivers
is needed for most mailing lists to achieve stable delivery once ARC is in
the mix? Knowing the landscape of receiving domains, I believe this to be a
small number. From the above comments, I'm guessing you think this is a
large number. We're not going to resolve this difference of opinion in an
open forum. However, releasing ARC as an experiment into the wild for major
lists like the IETF and M3AAWG will give us very clear data very quickly on
what the actual landscape looks like, and what ARC does and does not solve.

In its current form, ARC only helps mail flows, it does not harm them. How
effective this improvement is remains to be seen, but preliminary
information I've been hearing about (which could be totally wrong) makes it
seem like the improvements are dramatic. So let's get ARC tied off as an
Experiment (thank you, Dave Crocker), collect some data, and see where
things stand. Maybe things are great and ARC can move to proposed standard.
Maybe it fundamentally needs more receivers in the mix than currently
expected, and some fix for that is needed. But we'll know that after the
experiment has begun, not before.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Seth Blank]

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.

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."

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

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

[Hector Santos]

On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:

On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:

If we even have a DMARC ARC Policy concept, than that may be
enough to begin pursuing the high cost of experimentation and
development here.


Beyond the protocol and usage specs, what are you looking for?



A practical purpose for supporting (implementing) this work.   It 
appears ARC wants the network to stamp mail "blindly" as the mail 
travels from point to point.  I am trying to grasp how it helps 
resolve the main issue with "unauthorized" indirect 3rd party 
signatures, in particular when dealing with strong, exclusive DKIM 
signature policy models such as DMARC p=reject.


--
HLS


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

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

[Bron Gondwana]

On Tue, 15 Aug 2017, at 12:59, Seth Blank wrote:
> 
>> 
>> "might be useful to someone at some point" - that kind of wooliness
>> is a crock, sorry.  Once  crypto doesn't validate it has no meaning
>> if all the data is present elsewhere - and everything that an AMS
>> claims except for the crypto over the message is duplicated in the
>> next hop's AAR.>> 
>> If that's not the case, we should fix it so that it is.
>> 
>> "see what ends up being useful after this is in the wild for a bit"
>> makes sense for informational records.  It doesn't make sense for
>> cryptographic data.  Either the crypto is sound and it means
>> something, or it's actively misleading.  A no-longer-validating AMS
>> contains nothing that the next hop's AAR doesn't contain.> 
> So there have been two years of discussion about this on the list,
> and the consensus was that ARC will include trace information - like
> all non-originating AARs - because that information might be
> interesting or useful to some party at some point. Google has many
> instances where a non-originating AAR has the information that
> matters to them. But the tl;dr here is simply that the decision was
> made at its inception to include extra information that might be
> helpful later, and that the working group wasn't open to re-
> evaluating that decision because the body of ARC was built on it. If
> that's the design decision, then we need to be consistent in its
> application - which means not throwing out excess data, especially if
> someone says "that might be valuable to me.">  

Yes, trace information is good.  I absolutely agree that you need to
keep all the AARs.
The problem with AS is that it's not trace information in any meaningful
way over time.  The AS only validates while that key is still published,
so it's not "forever".
(mind you, nothing validates forever, the AMSes only validate while they
key is still in DNS too)
The fact that there was an AMS gets captured in the next AAR.

>>  
 I just had a really good chat with Seth on Skype half an hour ago
 about this.  He was unable to find a case where having a full
 AS,AMS,AAR adds any provable value over just checking the most-
 recent AMS and having AAR signed.  I do like your proposal of
 signing ALL the existing AARs, because they're the thing of value.
 Old AMS have no value, and old AS have no value either so long as
 you have a cv=pass on the current AS.>>> 
>>> That's not quite what I said ;-)
>> 
>> 
>> OK, did I misunderstand?
>> 
>> You  couldn't quote a case where AS,AMS,AAR adds provable value over
>> an AMS that signs the most recent AAR.  If you can find that case, I
>> will eat all my words, because I've spent a lot of time thinking
>> through the cases.>> 
>> I agree with what Brandon seemed to be saying above - that it should
>> be all the AAR being signed, not just the top one.  Otherwise an
>> intermediate could strip or modify earlier AAR without breaking the
>> authentication, and that would be bad.  Each AAR contains real,
>> valuable, meaningful data.> 
> I said the AS forces anyone who modified the chain to sign. In the
> obvious "all trusted" and "clearly untrusted" signers cases, the AS
> doesn't seem to add much value. But if a bad actor finds a way to send
> a chain through a good intermediary, then not having an AS would allow
> this message to be delivered. This is an edge case, and maybe doesn't
> matter - but the AS certainly protects against it.
Can you please expand on this point and show how the AS is protecting
against a bad actor sending a chain through a good intermediary.  I
really don't see it.  An example of AS protecting against a bad actor
here would totally blow my argument out of the water.
> 
> The spec already covers all AARs by the AS.
>  
>> 
>> 
>> As far as I see, we're quibbling over how much cryptographic
>> infrastructure is needed to maintain the integrity of the chain of
>> AAR headers.>> 
>> 
>>> If you throw old AMSs out, you cannot validate current ASs or walk
>>> the chain back.>> 
>> 
>> So what.  AS is bunk.
>> 
>> A current AMS over all AAR gives the same auditability, since AAR is
>> the only thing that has meaning.  AMS only has meaning while it still
>> validates, and AS only has meaning because it ties AMS and AAR
>> together.  Those meanings don't add value.  None of them mean jack
>> once you've been through an untrusted site, all previous headers are
>> suspect regardless of whether they have crypto that still validates,
>> unless that crypto covers facts about the message which we actually
>> care about.> 
> I thought our discussion ended with the AS adding an extra layer that
> was benign at worst, and protected against future unknown attacks at
> best. And your concern was the overhead of evaluating the AS on DNS,
> especially for long chains. I thought where we ended was your
> suggestion that the spec only requiring validation of the latest AS
> and AMS, and implementations MAY validate all 

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

[Seth Blank]

On Mon, Aug 14, 2017 at 6:31 PM, Bron Gondwana 
wrote:

> Do we, though? ARC has NOT ever been about localizing or understanding
> changes to a message, it has been about understanding *actors* who may have
> modified the message.
>
>
> Sure, but knowing which actors may have modified the message and which
> actors definitely didn't modify the message is super useful.
>

We get that with you suggestion above "first AMS failure"


>
> It means that if you trust the next hop, you don't need to trust the
> intermediates that couldn't modified the message without colluding with
> that next hop.
>

That's also how I see it.


> For instance, if we have two ARC-participating hops, and it was a
> non-participating hop between them who modified the message, we could
> localize the breakage to being at or between the two hops, but could not
> with certainty ascribe it to either hop, which is why ARC has avoided this.
>
>
> If you trust hop 2, you can confirm that it was modified since hop 1 (or
> that hop 1 can't form a valid signature).
>
> If you don't trust hop 2, then you don't know anything at all about the
> message before hop 2, regardless of any signatures.
>
> If that isn't clear, then I didn't explain myself very well on our call!
> Unless you trust hop 2, everything before that is meaningless, regardless
> of ARC headers.  An ARC chain through an untrusted hop 2 could be totally
> fiction.
>

Nope, we're in agreement.


> Yes, that makes sense - So long as each AAR includes the signing domain
> that it checked against for its arc=pass, then no information is lost.
>
>
> So much of ARC keeps trace information that might be useful to someone at
> some point, it feels very weird to throw some headers out and keep others.
> I argue we keep them all, and (to the discussion around Experimental
> status) see what ends up being useful after this is in the wild for a bit.
> This data can always be tossed later if it serves no real world purpose.
>
>
> "might be useful to someone at some point" - that kind of wooliness is a
> crock, sorry.  Once crypto doesn't validate it has no meaning if all the
> data is present elsewhere - and everything that an AMS claims except for
> the crypto over the message is duplicated in the next hop's AAR.
>
> If that's not the case, we should fix it so that it is.
>
> "see what ends up being useful after this is in the wild for a bit" makes
> sense for informational records.  It doesn't make sense for cryptographic
> data.  Either the crypto is sound and it means something, or it's actively
> misleading.  A no-longer-validating AMS contains nothing that the next
> hop's AAR doesn't contain.
>

So there have been two years of discussion about this on the list, and the
consensus was that ARC will include trace information - like all
non-originating AARs - because that information might be interesting or
useful to some party at some point. Google has many instances where a
non-originating AAR has the information that matters to them. But the tl;dr
here is simply that the decision was made at its inception to include extra
information that might be helpful later, and that the working group wasn't
open to re-evaluating that decision because the body of ARC was built on
it. If that's the design decision, then we need to be consistent in its
application - which means not throwing out excess data, especially if
someone says "that might be valuable to me."


>
>
>
> I just had a really good chat with Seth on Skype half an hour ago about
> this.  He was unable to find a case where having a full AS,AMS,AAR adds any
> provable value over just checking the most-recent AMS and having AAR
> signed.  I do like your proposal of signing ALL the existing AARs, because
> they're the thing of value.  Old AMS have no value, and old AS have no
> value either so long as you have a cv=pass on the current AS.
>
>
> That's not quite what I said ;-)
>
>
> OK, did I misunderstand?
>
> You couldn't quote a case where AS,AMS,AAR adds provable value over an AMS
> that signs the most recent AAR.  If you can find that case, I will eat all
> my words, because I've spent a lot of time thinking through the cases.
>
> I agree with what Brandon seemed to be saying above - that it should be
> all the AAR being signed, not just the top one.  Otherwise an intermediate
> could strip or modify earlier AAR without breaking the authentication, and
> that would be bad.  Each AAR contains real, valuable, meaningful data.
>

I said the AS forces anyone who modified the chain to sign. In the obvious
"all trusted" and "clearly untrusted" signers cases, the AS doesn't seem to
add much value. But if a bad actor finds a way to send a chain through a
good intermediary, then not having an AS would allow this message to be
delivered. This is an edge case, and maybe doesn't matter - but the AS
certainly protects against it.

The spec already covers all AARs by the AS.


>
> As far as I see, we're quibbling over how 

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

[Bron Gondwana]

On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>  wrote:>> 
>>> 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.>> 
>> 
>> That seems like it would be enough to fix that objection.  An
>> additional "first AMS failure" header at each hop would give you a
>> list of who actually modified the message.> 
> This makes sense, and should be a simple addition to 5.1.1 regarding
> what/how to stamp. I'll noodle over this and suggest language.
Excellent, thanks.

>  
>> 
>>> 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.>> 
>> 
>> Right.  That's the bit that we do absolutely need, regardless of
>> everything else.  Every link in the chain has to be trustworthy or
>> they can just repurpose an existing chain valid chain.  If you didn't
>> have that with XOAR I can see how an intermediate could have
>> falsified the chain of custody under XOAR without being implicated
>> for reputation purposes.  We definitely need to be able to know who
>> the injection point for bad content!> 
> Do we, though? ARC has NOT ever been about localizing or understanding
> changes to a message, it has been about understanding *actors* who may
> have modified the message.
Sure, but knowing which actors may have modified the message and which
actors definitely didn't modify the message is super useful.
It means that if you trust the next hop, you don't need to trust the
intermediates that couldn't  modified the message without colluding with
that next hop.
> 
> For instance, if we have two ARC-participating hops, and it was a non-
> participating hop between them who modified the message, we could
> localize the breakage to being at or between the two hops, but could
> not with certainty ascribe it to either hop, which is why ARC has
> avoided this.
If you trust hop 2, you can confirm that it was modified since hop 1 (or
that hop 1 can't form a valid signature).
 If you don't trust hop 2, then you don't know anything at all about the
 message before hop 2, regardless of any signatures.
If that isn't clear, then I didn't explain myself very well on our call!
Unless you trust hop 2, everything before that is meaningless,
regardless of ARC headers.  An ARC chain through an untrusted hop 2
could be totally fiction.
>> 
>>> 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.>> 
>> 
>> Yes, that makes sense - So long as each AAR includes the signing
>> domain that it checked against for its arc=pass, then no information
>> is lost.> 
> So much of ARC keeps trace information that might be useful to someone
> at some point, it feels very weird to throw some headers out and keep
> others. I argue we keep them all, and (to the discussion around
> Experimental status) see what ends up being useful after this is in
> the wild for a bit. This data can always be tossed later if it serves
> no real world purpose.
"might be useful to someone at some point" - that kind of wooliness is a
crock, sorry.  Once  crypto doesn't validate it has no meaning if all
the data is present elsewhere - and everything that an AMS claims except
for the crypto over the message is duplicated in the next hop's AAR.
If that's not the case, we should fix it so that it is.

"see what ends up being useful after this is in the wild for a bit"
makes sense for informational records.  It doesn't make sense for
cryptographic data.  Either the crypto is sound and it means something,
or it's actively misleading.  A no-longer-validating AMS contains
nothing that the next hop's AAR doesn't contain.
>  
>> I just had a really good chat with Seth on Skype half an hour ago
>> about this.  He was unable to find a case where having a full
>> AS,AMS,AAR adds any provable value over just checking the most-recent
>> AMS and having AAR signed.  I do like your proposal of signing ALL
>> the existing AARs, because they're the thing of value.  Old AMS have
>> no value, and old AS have no value either so long as you 

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

[Kurt Andersen (b)]

On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos  wrote:

>   If we even have a DMARC ARC Policy concept, than that may be enough to
> begin pursuing the high cost of experimentation and development here.
> 
>

Beyond the protocol and usage specs, what are you looking for?

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

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

[Bron Gondwana]

On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
>  wrote:>> __
>> . . . 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.> 
>  

I would like to address this point, but maybe we should have a separate
thread for it?  I would strongly argue that sites not changing the
message SHOULD NOT add ARC headers.  I spelled out the reasons in my
initial posting on this thread.
>> 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.> 
> In the current layout, "signing [the] AAR" is done via the AS. We
> wanted to keep the AAR as close to the A-R header as we could to
> maximize leverage of previous definitions rather than inventing an
> entirely new one. Initially, we had intended the AMS to sign over the
> AAR, but people objected to signing the AAR within both the AMS and
> AS scopes.
I can understand that.  I would fix it by not having AS scopes rather
than removing AAR from AMS.
>  
>> And this is the crux of our disagreement.  Seth thinks it's necessary
>> to do more than signing a statement that you believed the message was
>> authenticated when you got it, in a way that the next hop can verify
>> your signature over your own Authentication Results plus the content
>> of the message.  I disagree.> 
>  One could replace the AMS with an "egress DKIM" signature, but then
>  you would still have to decide what to do about alignment on this new
>  DKIM signature. That's why we built the AMS - to avoid the question
>  of alignment and have the ARCset as a self-contained "package".
Yes - calling it something different from DKIM-Signature is good, so
that nobody tries to check alignment with the "From:" domain.
But I don't see any reason to replace AMS - it does what's needed (apart
from not signing the AAR).  It's AS that bothers me.
> I see the point that you are driving at regarding the claim of
> "forgery", but I don't consider that any more or less of a forgery
> than what the IETF mailman will do to this message en route to the
> recipients. Mailman changes the headers (Subject) and body. Seems like
> that's about what you've done in the sample message...but at least you
> took responsibility for doing so with ARCset[7] (or someone with the
> private key for brong.net ;-) ).
It's true, anybody at FastMail could have done that.  At least anybody
with production access to our DKIM keys database :)
The point with forgery is that "a chain of unbroken ARC-Seals" is
meaningless, because they're not protecting anything.
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Bron Gondwana]

On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote:
> On 8/11/2017 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.
> 
> I don't have an opinion about whether this conclusion is correct, but> I'm 
> quite certain it a type of consideration that needs to be
> fundamental, to recommendations about usage.  Who should do what, and> why?  
> What are the upsides of their doing or not?  Downsides?
> 
> 
> 
>>>   Without the ARC Seal this determination is not possible and
>>>   there is>>>   no way to evaluate the ARC chain for delivery as a final 
>>> receiver.>> 
>> And this is the crux of our disagreement.  Seth thinks it's
>> necessary to>> do more than signing a statement that you believed the 
>> message was
>> authenticated when you got it, in a way that the next hop can verify>> your 
>> signature over your own Authentication Results plus the
>> content of>> the message.  I disagree.
>> 
>> I'm proposing exactly the same stragety DKIM uses, just with
>> series of>> signed "chain of custody" statements rather than the DKIM 
>> signature
>> having to align with the sender domain.
> 
> by 'strategy DKIM uses' what do you mean exactly?  I'm guessing
> you mean> having the signature cover more of the header and all of the body, 
> but> please confirm or clarify.

Sorry - yes, to clarify...

DKIM signs the entire body plus parts of the header.

In the strategy I am proposing, site "X" modifying a message in transit
(e.g. a mailing list) would add their own DKIM-like header (ARC-Message-
Signature is a perfectly fine name for it) which signed the new "body
and parts of the header", including a statement that site "X" had
verified the message authentication before modifying it (ARC-Authentication-
Results is a perfectly fine name for that statement).
That gives a complete chain of custody.

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Kurt Andersen (b)]

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

> . . . 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.
>



>
> 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.
>

In the current layout, "signing [the] AAR" is done via the AS. We wanted to
keep the AAR as close to the A-R header as we could to maximize leverage of
previous definitions rather than inventing an entirely new one. Initially,
we had intended the AMS to sign over the AAR, but people objected to
signing the AAR within both the AMS and AS scopes.



>
> And this is the crux of our disagreement.  Seth thinks it's necessary to
> do more than signing a statement that you believed the message was
> authenticated when you got it, in a way that the next hop can verify your
> signature over your own Authentication Results plus the content of the
> message.  I disagree.
>

 One could replace the AMS with an "egress DKIM" signature, but then you
would still have to decide what to do about alignment on this new DKIM
signature. That's why we built the AMS - to avoid the question of alignment
and have the ARCset as a self-contained "package".

I see the point that you are driving at regarding the claim of "forgery",
but I don't consider that any more or less of a forgery than what the IETF
mailman will do to this message en route to the recipients. Mailman changes
the headers (Subject) and body. Seems like that's about what you've done in
the sample message...but at least you took responsibility for doing so with
ARCset[7] (or someone with the private key for brong.net ;-) ).

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

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

[Dave Crocker]

On 8/11/2017 9:26 AM, Dave Crocker wrote:

Here's the task I see:

*  Talk about ARC in non-technical terms, describing not just its 
abstract goal but the nature of how it achieves those goals, in terms

of threats it is responding to, capabilities that it is responding
to, and limitations to those capabilities.

*  This needs to include reference to the concept of 'trust' as an 
operational attribute.


*  There also needs to be statements about the operational history 
upon which ARC builds -- that is, what is it doing that is

well-founded -- and what it is doing that is new.

*  For the parts that are 'new', there needs to be statements the 
provide explain why it is reasonable to be optimistic that deployment

 and use will be safe and useful.



Possibly-useful examples that already showed up in this thread:


On 8/7/2017 4:22 PM, Seth Blank wrote:

ARC is about maintaining a chain of custody so that a final receiver
can be certain of which domains modified a message in transit. Like
DMARC, DKIM, and SPF, we're trying to ascertain if the message was
handled by the domain it said it was handled by - we're not passing
judgement on the contents of the messages itself.




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.

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

In state #1, you're done - if you trust the signatories then you
trust they're not playing games with the AMS and AAR contents or
manipulating the message in malicious ways. Now you can make a
delivery decision as local policy dictates.

In state #2, you're also done - if you don't trust all the
signatories, then there are a multitude of routes for the message to
be garbage, including but not limited to everything you've outlined
above.

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).

Without the ARC Seal this determination is not possible and there is
no way to evaluate the ARC chain for delivery as a final receiver.




On 8/7/2017 7:41 PM, John Levine wrote:

Since it only makes sense to look at the ARC chain on mail that
comes from senders that are generally reliable, I've asked why you
don't just whitelist those senders and be done with it.

The answer, at least at very large mail systems, is that a mailing 
list sends nice clean mail, but then it starts forwarding lots of 
spam.  I've seen this on some of the ICANN lists where someone got
his address book stolen that had both the lists and individuals' 
addresses, so we're now getting mail through the lists with faked 
addresses of a frequent participant.  ARC passes along info from 
previous hops so the recipient can retroactively do filtering that

the mailing list didn't.




d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Dave Crocker]

On 8/11/2017 9:34 AM, Kurt Andersen (b) wrote:
I think that we have that sort of information scattered around in 
various non-spec presentations that have happened regarding ARC. Do you 
consider this to be something that should be tackled before or after the 
"intent"-related notes in your earlier review notes from the end of July?



I think it's compatible with some of the concerns I raise and so should 
be pursued at the same time.  I'm hoping that the exercise will produce 
much better clarity and coherence and widespread understanding of what 
ARC will and will not do.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Kurt Andersen (b)]

On Fri, Aug 11, 2017 at 9:27 AM, Dave Crocker  wrote:

>
> I wanted to try to generate some candidate text that would respond to the
> concerns that Bron has raised, but find that I'm not (yet) clear enough
> about underlying details of ARC.  I don't mean technical details, I mean
> conceptual basis.  (And this is in spite of my having been a participant in
> ARC development from the start!)
>
> So I'm now going to ask for a discussion that produces at least bits of
> text.  When there is convergence on those bits, I'm glad to offer to
> assemble them into some sort of "Concepts and Facilities" summary of ARC.


I think that we have that sort of information scattered around in various
non-spec presentations that have happened regarding ARC. Do you consider
this to be something that should be tackled before or after the
"intent"-related notes in your earlier review notes from the end of July?

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

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

[Dave Crocker]

On 8/9/2017 3:26 PM, Bron Gondwana wrote:
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've been mulling over this thread for some days.  A challenge in 
writing an IETF spec is to make sure the text is adequately 
understandable to folk who weren't part of the original specification 
effort, yet still can produce interoperable systems.  And will know why 
they should and what benefit will accrue if they do.  I think the 
current document does not provide enough information for this.


I wanted to try to generate some candidate text that would respond to 
the concerns that Bron has raised, but find that I'm not (yet) clear 
enough about underlying details of ARC.  I don't mean technical details, 
I mean conceptual basis.  (And this is in spite of my having been a 
participant in ARC development from the start!)


So I'm now going to ask for a discussion that produces at least bits of 
text.  When there is convergence on those bits, I'm glad to offer to 
assemble them into some sort of "Concepts and Facilities" summary of ARC.



Here's the task I see:

  *  Talk about ARC in non-technical terms, describing not just its 
abstract goal but the nature of how it achieves those goals, in terms of 
threats it is responding to, capabilities that it is responding to, and 
limitations to those capabilities.  This discussion needs to look for 
leaps of faith and other points of confusion or implicit assumption, and 
it needs to resolve them.


  *  This needs to include reference to the concept of 'trust' as an 
operational attribute.


  *  There also needs to be statements about the operational history 
upon which ARC builds -- that is, what is it doing that is well-founded 
-- and what it is doing that is new.


  *  For the parts that are 'new', there needs to be statements the 
provide explain why it is reasonable to be optimistic that deployment 
and use will be safe and useful.



Thoughts?

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Bron Gondwana]

On Thu, 10 Aug 2017, at 10:41, Brandon Long 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.
I would argue that if the AMS passes, the intermediate hop SHOULD NOT
add another ARC-Seal...
> 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.
Which is precisely my point above.  Consider this case

A => B => C => D

Where C is untrusted and you are D, but the AMS is

A(fail) => B(pass) => C(pass) => D

So you know that C didn't modify the message, and you can trust the
message because you trust B.
Now suppose  D modifies the message and sends it on.

A => B => C => D => E

With AMS status:

A(fail) => B(fail) => C(fail) => D(pass) => E

If you (E) trust A, B and D but don't trust C, the fact that C added an
ARC-Seal has confused a message that was perfectly trustworthy, because
you can no longer validate the fact that C didn't change the message.
That's why I say: don't ARC-Seal unless you're changing the message.

> 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.
That's fine if you have the resources of Google to know who's
intermediating a lot.
If you are B in that chain above and you can get C to forward your
messages, you could easily destroy C or D's reputation at E, even though
D knew that C wasn't modifying your messages.
> 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.
This comes down to how standard the AAR is.  If my AAR includes machine
parseable information to say that I could validate the previous AMS and
it passed, then you can walk back through the chain just as easily,
without even needing to validate the previous signatures, because I
already did that for the previous one, and they already did it for the
one before.
There are only two cases that the full ARC-Seal helps with.  You spelt
out one above: the earlier AMSes still validate, so you know the message
hasn't changed.  That's bogus to me in two ways:* the one I just spelled out 
(it muddies things after the next
  modification), so don't do it in the first place* if you can still validate 
the earlier AMS then you don't even need the
  follow the ARC-Seals - just validate each AMS from highest i= down
  until you find one that doesn't pass.  All the passing AMS must be
  trustworthy regardless of the later ARC-Seals, because they are signed
  by the domain and correctly describe the current message.
So ARC-Seal buys you nothing for the hops where AMS is passing (because
you're checking AMS anyway), and it buys you nothing for the earlier
hops, because you have to stop at the first hop you don't trust.
I will give you this - if you believe that it's likely that
implementations will exist that can successfully validate an AS chain,
and can successfully validate the previous AMS, but can NOT reliably
generate an AAR header, then ARC-Seal would have a point.  Otherwise
we're trusting sites to do all the crypto right, but not trusting them
to report the results of said validation correctly, which is really a
weird security stance IMHO.
> 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.
I believe the logic for "should I add an AMS" should be:
1) there is existing DKIM, but I'm about to break it by changing
   the message2) there is an existing AMS, but I'm about to break it by changing
   the message3) there is no DKIM  or AMS, but I trusted the message for some 
other
   reason which the next hop will be unable to verify (e.g. SPF passed)
In all other cases, adding a signature is bad.  Complex routing should
not break the signature, so only the process making the modifications
should be adding a new signature.
In the case of Google, that would mean adding an AMS on incoming MX only
for messages which have  no DKIM, then adding an AMS for messages which
are modified (e.g. by Groups)
> Also, you wouldn't expect to see arc signed messages from this list
> until it starts doing them itself, unless 

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"  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"  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

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

[MH Michael Hammer (5304)]

> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman
> Sent: Tuesday, August 08, 2017 10:28 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre
> 
> On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote:
> > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> > > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> > > <br...@fastmailteam.com> wrote:>> __
> > >
> > >> . . .  If you aren't willing to agree that the most recent liar can
> > >>
> > >>   repurpose an existing chain, I'm happy to avoid making the forgery,
> > >>   otherwise I'll make up a forgery and send it to the list.>>
> > >>
> > >> But since you either trust every hop to do good checks, or you
> > >> don't trust the entire message - then the ARC-Seal is literally
> > >> adding nothing.  It adds no meaning, just extra work.  Hence my
> > >> snakeoil claim.>>
> > >
> > > Is your concern that the last hop (or any other) can essentially do
> > > a wholesale replacement of the message contents and that there is no
> > > way to distinguish that from a semantically meaningless footer
> > > tweak?> I'm not sure that I understand your assertion that you can
> > > forge an AS any more than you could forge a DKIM signature.
> >
> > The whole point of verifying the chain of AS all the way back to i=1
> > is that you can tell that the message went through those servers, in
> > that order.
> > But it's bogus, because AS doesn't sign anything except itself and
> > some AMS and AAR.  Once AMS doesn't validate any more (any change at
> > all) then you can't really tell that the message passed through there,
> > just the _a_ message passed through there.
> > So I could take an existing message that had passed through Google and
> > create a brand new message and pass it off as if it had passed through
> > Google before passing through my server on its way to you.
> > In which case - the AS is meaningless.  It claims something which is
> > only true if everyone plays by the rules.  But if everyone plays by
> > the rules, then it's excessive.  You could just check the previous AAR
> > and know that the previous site had validated the hop before it, and so on.
> > It's crypto that doesn't add anything of value.
> > It's not actively damaging (other than the advice to do excessive DNS
> > lookups), but it's also not doing anything meaningful, and it's adding
> > something forgeable that looks like it means something.
> > Bron.
> 
> 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.
> 
> The fail case isn't very interesting.  If it doesn't validate it, ignore it.
> 
> I'm not sure yet what exactly the pass case buys, but I'm not convinced it's
> nothing.
> 
> Scott K
> 

I think the other thing that needs to be remembered is that DMARC, and 
subsequently ARC, is a request to the mailbox provider/validator. ARC is 
presumably used as an input for local policy in consideration of overriding 
DMARC failures. The fact that ARC validation is successful at the mailbox 
provider is ultimately a matter of local policy and presumably some sort of 
reputation schema. 

Mike

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

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

[Scott Kitterman]

On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote:
> On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> >  wrote:>> __
> > 
> >> . . .  If you aren't willing to agree that the most recent liar can
> >> 
> >>   repurpose an existing chain, I'm happy to avoid making the forgery,
> >>   otherwise I'll make up a forgery and send it to the list.>>
> >> 
> >> But since you either trust every hop to do good checks, or you
> >> don't trust the entire message - then the ARC-Seal is literally
> >> adding nothing.  It adds no meaning, just extra work.  Hence my
> >> snakeoil claim.>>
> > 
> > Is your concern that the last hop (or any other) can essentially do a
> > wholesale replacement of the message contents and that there is no way
> > to distinguish that from a semantically meaningless footer tweak?>
> > I'm not sure that I understand your assertion that you can forge an AS
> > any more than you could forge a DKIM signature.
> 
> The whole point of verifying the chain of AS all the way back to i=1
> is that you can tell that the message went through those servers, in
> that order.
> But it's bogus, because AS doesn't sign anything except itself and some
> AMS and AAR.  Once AMS doesn't validate any more (any change at all)
> then you can't really tell that the message passed through there, just
> the _a_ message passed through there.
> So I could take an existing message that had passed through Google and
> create a brand new message and pass it off as if it had passed through
> Google before passing through my server on its way to you.
> In which case - the AS is meaningless.  It claims something which is
> only true if everyone plays by the rules.  But if everyone plays by the
> rules, then it's excessive.  You could just check the previous AAR and
> know that the previous site had validated the hop before it, and so on.
> It's crypto that doesn't add anything of value.
> It's not actively damaging (other than the advice to do excessive DNS
> lookups), but it's also not doing anything meaningful, and it's adding
> something forgeable that looks like it means something.
> Bron.

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.

The fail case isn't very interesting.  If it doesn't validate it, ignore it.

I'm not sure yet what exactly the pass case buys, but I'm not convinced it's 
nothing.

Scott K

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

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

[Bron Gondwana]

On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
>  wrote:>> __
>> 
>> . . .  If you aren't willing to agree that the most recent liar can
>>   repurpose an existing chain, I'm happy to avoid making the forgery,
>>   otherwise I'll make up a forgery and send it to the list.>> 
>> 
>> But since you either trust every hop to do good checks, or you
>> don't trust the entire message - then the ARC-Seal is literally
>> adding nothing.  It adds no meaning, just extra work.  Hence my
>> snakeoil claim.>> 
>> 
>> 
> Is your concern that the last hop (or any other) can essentially do a
> wholesale replacement of the message contents and that there is no way
> to distinguish that from a semantically meaningless footer tweak?> 
> I'm not sure that I understand your assertion that you can forge an AS
> any more than you could forge a DKIM signature.
The whole point of verifying the chain of AS all the way back to i=1
is that you can tell that the message went through those servers, in
that order.
But it's bogus, because AS doesn't sign anything except itself and some
AMS and AAR.  Once AMS doesn't validate any more (any change at all)
then you can't really tell that the message passed through there, just
the _a_ message passed through there.
So I could take an existing message that had passed through Google and
create a brand new message and pass it off as if it had passed through
Google before passing through my server on its way to you.
In which case - the AS is meaningless.  It claims something which is
only true if everyone plays by the rules.  But if everyone plays by the
rules, then it's excessive.  You could just check the previous AAR and
know that the previous site had validated the hop before it, and so on.
It's crypto that doesn't add anything of value.
It's not actively damaging (other than the advice to do excessive DNS
lookups), but it's also not doing anything meaningful, and it's adding
something forgeable that looks like it means something.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Kurt Andersen (b)]

On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana 
wrote:

> . . .  If you aren't willing to agree that the most recent liar can
> repurpose an existing chain, I'm happy to avoid making the forgery,
> otherwise I'll make up a forgery and send it to the list.
>
> But since you either trust every hop to do good checks, or you don't trust
> the entire message - then the ARC-Seal is literally adding nothing.  It
> adds no meaning, just extra work.  Hence my snakeoil claim.
>

Is your concern that the last hop (or any other) can essentially do a
wholesale replacement of the message contents and that there is no way to
distinguish that from a semantically meaningless footer tweak?

I'm not sure that I understand your assertion that you can forge an AS any
more than you could forge a DKIM signature.

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

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

[Bron Gondwana]

On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>>  wrote:>> 
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but change the validation to
>> only require checking the most recent AS, since validating the rest
>> is meaningless.> 
> Bron, thanks for sharing your insight. I don't think it's too
> late/complex to incorporate direct real world experience into the
> specification.> 
> I tried to express my own attitude in the Prague meeting: the email
> space is special because it is huge. It doesn't make sense to pretend
> that it isn't. Instead, let's build tech to solve real problems, test
> it against the install base, and make the tech better based on what is
> learned.> 
> AFAICT, ARC is at the very beginning of the "test it against the
> install base" phase.
Thanks Tim,

We'll set ARC up at FastMail and experiment with it for sure.  The code
is pretty much ready to slot into place, and while nobody is filtering
on it, it's easy enough to play with.
It's not like ARC is worse than nothing (apart from maybe the increased
DNS load).  Regardless of our opinion of how good it is, we'll certainly
implement anything which helps our users' mail be delivered!  But it
would be nice to help make it even better if we get a chance to
influence the technology choices :)
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[John Levine]

In article <1502083287.2191248.1065195288.7cdc7...@webmail.messagingengine.com> 
you write:
>I thought long and hard about using a less inflammatory title, but I
>figure maybe going in hard is the right way here, because I'd rather
>fix this before it becomes a standard! (and thanks Dave for your
>thoughtful questions during the Prague DMARC session which prompted
>some of my thinking)

For the most part you're right, but there seem to be a few corner
cases that make it worthwhile.

Since it only makes sense to look at the ARC chain on mail that comes
from senders that are generally reliable, I've asked why you don't
just whitelist those senders and be done with it.  

The answer, at least at very large mail systems, is that a mailing
list sends nice clean mail, but then it starts forwarding lots of
spam.  I've seen this on some of the ICANN lists where someone got his
address book stolen that had both the lists and individuals'
addresses, so we're now getting mail through the lists with faked
addresses of a frequent participant.  ARC passes along info from
previous hops so the recipient can retroactively do filtering that the
mailing list didn't.

I personally don't expect to do that, but if Gmail says they will,
I presume they will.

R's,
John

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

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

[Bron Gondwana]

On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>>  wrote:>> 
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but change the validation to
>> only require checking the most recent AS, since validating the rest
>> is meaningless.> 
> Bron, thanks for sharing your insight. I don't think it's too
> late/complex to incorporate direct real world experience into the
> specification.> 
> I tried to express my own attitude in the Prague meeting: the email
> space is special because it is huge. It doesn't make sense to pretend
> that it isn't. Instead, let's build tech to solve real problems, test
> it against the install base, and make the tech better based on what is
> learned.> 
> AFAICT, ARC is at the very beginning of the "test it against the
> install base" phase.
Thanks Tim,

We'll set ARC up at FastMail and experiment with it for sure.  The code
is pretty much ready to slot into place, and while nobody is filtering
on it, it's easy enough to play with.
It's not like ARC is worse than nothing (apart from maybe the increased
DNS load).  Regardless of our opinion of how good it is, we'll certainly
implement anything which helps our users' mail be delivered!  But it
would be nice to help make it even better if we get a chance to
influence the technology choices :)
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  br...@fastmailteam.com


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

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

[Tim Draegen]

> On Aug 7, 2017, at 1:21 AM, Bron Gondwana  wrote:
> 
> A more cheap and nasty fix, assuming it's too late/complex to change the 
> protocol more, would be to keep AS, but change the validation to only require 
> checking the most recent AS, since validating the rest is meaningless.

Bron, thanks for sharing your insight. I don't think it's too late/complex to 
incorporate direct real world experience into the specification.

I tried to express my own attitude in the Prague meeting: the email space is 
special because it is huge. It doesn't make sense to pretend that it isn't. 
Instead, let's build tech to solve real problems, test it against the install 
base, and make the tech better based on what is learned.

AFAICT, ARC is at the very beginning of the "test it against the install base" 
phase.


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