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

From: Bron Gondwana <[email-masked]>
Date: Mon, 07 Aug 2017 15:21:27 +1000

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)
Unfortunately I didn't get a full chance to think about ARC and how it
all functions before Prague, and then I hadn't fully internalised it by
the DMARC session - I was still refactoring the code I wrote on the
weekend and testing it some more, as well as getting the signing side
done.  It took a few days to fully understand how all those signatures
work together.  I had let others focus on ARC within our company rather
than looking at it myself until now.
So my apologies for coming along late with this manifesto!  I've been
trying to think of a more polite and diplomatic way to say it, but so
far I haven't see anything to convince me that ARC-Seal is anything
other than snake oil.  It's excessive crypto for no benefit, and with
the way I've had it described to me and the way it's being used right
now at least at Google (sealing every message on the way in), it adds
confusion rather than clarity to message provenance.
Let me explain.  Starting with purpose.

ARC conflates two purposes:

a) providing a new signature when you change a message in ways that
   break its existing signature.
b) providing a signature where there is none, but SPF passed and you
   would have trusted the source email anyway.
Apparently "just DKIM sign everything" isn't viable due to key
management problems and "sending on behalf of".  I'm willing to
stipulate that, because we have to work with the reality of deployed
systems with any new standard if it wants traction.
There is a third purpose that needs signatures:

c) new email received from trusted/internal host with no signature yet

This is generally handled by DKIM-signing the message before sending it
outside an organisation's trusted infrastructure.  FastMail for example
DKIM signs our outbound email during the final scan before adding to the
outbound queues.  Internally it travels around with an internal-only
header that identifies the sending user to allow us to choose which DKIM
signatures to apply, then we sign on final injection into the outbound
queue.  I suspect other organisations do the same, and this is what DKIM
was designed for.  My understanding of ARC is that is not supposed to
replace DKIM for this case.
Anyway, we are conflating:

1) I need to sign this email which I didn't modify because the next hop
   wouldn't be able to verify that it was sent from an authorised source
   any more; with
2) I'm modifying this message and I am asserting that I believed it was
   from an authorised source and correctly signed before I modified it
Right now AAR and AMS are exactly the same for those two cases.

The problem is - advice on "when should I ARC-Seal" is really woolly,
leading to a third case being conflated in here:
3) I'm not modifying this message or breaking its signature, I'm just
   adding my own signature as it passes through
Case three is the real problem.  By adding an AAR, AMS and AS in that
case, you're adding crypto which is misleading.  I will make my case
below :)  I use the following parties:
d=gmail.com - a sender and eventual receiver.  I could sub fastmail.com
here just as easily, but "everyone" knows gmail, and they currently ARC-
Seal all incoming email.
d=mailinglist.com - a mailing list which modifies all email, and hence
needs to apply ARC to every message for case (2) above.
d=forwarder.com - a site that just forwards email without changing the
message at all - something like pobox.com, our alias service.
d=sketchy.com - another forwarder who isn't well known or trusted.

Trust isn't transitive, gmail trusts mailinglist.com to validate
signatures and to only apply clean transformations (change sender, add a
footer) to any email it receives, but it doesn't trust sketchy.com at
all.  mailinglist.com on the other hand isn't sure about sketchy.com,
but has no reason to consider it less trustworthy than other forwarders
because it doesn't have a giant machine learning database to handle site
reputation.
Now let's consider the following message history.  The mail is going to
follow this path:
gmail.com => sketchy.com => mailinglist.com => forwarder.com =>
gmail.com
This seems somewhat contrived, but maybe sketchy.com is some university
system where a club has set up an alias that goes to their mailing list,
and one of the members is an alumnus using a separate university alumni
system which forwards to their gmail account.  That's not a totally
unreasonable mail flow.
Here's a message where sketchy.com just forwards the message, with no
changes made:
original message:

DKIM-Signature: d=gmail.com (VALID)
From: <[email-masked]>
To: <[email-masked]>

first hop:

AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (VALID)
AAR: i=1, dkim=pass, spf=pass, arc=none
DKIM-Signature: d=gmail.com (VALID)
From: <[email-masked]>
To: <[email-masked]>
ENV-To: <[email-masked]>

second hop:

AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[email-masked]>
To: <[email-masked]>

We see that both DKIM and i=1 AMS are now invalid, only the AS chain
continues to validate.  The DKIM still passed on arrival to
mailinglist.com, because sketchy.com didn't actually modify the message,
but won't pass again after this.
third hop:

AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[email-masked]>
To: <[email-masked]>
ENV-To: <[email-masked]>

and finally gmail seal it on the way in:

AS: i=4, d=gmail.com, cv=pass (VALID)
AMS: i=4, d=gmail.com (VALID)
AAR: i=4, dkim=fail, spf=fail, arc=pass
AS: i=3, d=forwarder.com, cv=pass (VALID)
AMS: i=3, d=forwarder.com (VALID)
AAR: i=3, dkim=fail, spf=fail, arc=pass
AS: i=2, d=mailinglist.com, cv=pass (VALID)
AMS: i=2, d=mailinglist.com (VALID)
AAR: i=2, dkim=pass, spf=fail, arc=pass
AS: i=1, d=sketchy.com, cv=none (VALID)
AMS: i=1, d=sketchy.com (INVALID)
AAR: i=1, dkim=pass, spf=pass
DKIM-Signature: d=gmail.com (INVALID)
From: <[email-masked]>
To: <[email-masked]>
ENV-To: <[email-masked]>

In here we have two things that are interesting:

1) the oldest AMS that still validates.  Nothing was changed since then.2) the AAR with the same i= value (i=2) which shows that DKIM still
   passed then.
So we can tell from these headers that the only place which modified the
message was mailinglist.com.  So far so good.  Absent ANY value at all
are the ARC headers with i=1, i=3 or i=4.  They add no value.  Likewise
the ARC-Seal at i=2 only adds value because it signs the AAR at i=2.
This is literally the only proof we have at this point that sketchy.com
didn't completely rewrite the message.  This same value could be
obtained by having sketchy.com and forwarder.com and gmail's inbound do
no ARC processing at all other than validating the AMS of
mailinglist.com rather than the DKIM signature at forwarder.com and
gmail.com inbound.
The only way to know that sketchy.com didn't modify the message is
because mailinglist.com's AAR said that dkim still passed at that time.
But mailinglist.com could easily lie about that if it wanted to, the
chain would still be unbroken.
Further, ARC-Seal doesn't capture the really interesting bits -
which are "what was the envelope at this point" or even "what was
the date at this point" - meaning you can re-purpose old ARC-Seals
for as long as you like if the selectors still exist, and they will
continue to validate.
OK, this has become pretty long and rambly, but here's the thing:

*AS adds nothing over just having AMS signing its own AAR, and then you
only have to verify ONE signature, the most recent.*
 Any site which lies about AAR and also modifies the message can just as
 easily file the serial numbers off an existing ARC chain, pretend it
 received the message from a point in that chain, and then mint a
 convincing AAR, a valid AMS and a valid AS which chains with the
 existing set of seals.  The seals don't include any previous facts
 about the message other than the hashes in the lower i= AMS headers,
 and a single modification to message content will render them invalid.
 Short of a global registry of all known email mesages (in which case
 ARC is pointless), you can't tell if those ARC headers were lifted off
 another message and reused.
You either trust the most recent signer and trust that THEY validated
the previous signer/SPF (and so on) or the chain is broken anyway, so
why add a parallel, easily falsified, chain of signatures?
So since ARC-Seal doesn't add any value, and adds complexity and cost
(in extra DNS lookups and crypto) and failure points (in potential DNS
tempfails which break the chain even though the underlying crypto is
sound and could be verified later) - it's a waste and, as I stated in
the subject,  snakeoil with no benefit.
What is valuable is AMS and AAR, and along with that - advice to not add
your own AMS unless you really have to.  If you aren't breaking the
existing signature, don't add your own, because it confuses provenance
on the message.  ARC would be a better standard if it removed AS
entirely, and had AMS sign its own AAR (e.g. by adding another tag to
the AMS header which is the hash of the  associated AAR)
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.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Tim Draegen <[email-masked]>
Date: Mon, 7 Aug 2017 10:50:52 -0400

> On Aug 7, 2017, at 1:21 AM, Bron Gondwana <[email-masked]> 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.

---

From: Seth Blank <[email-masked]>
Date: Mon, 7 Aug 2017 16:22:15 -0700

On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana <[email-masked]>
wrote:
> <snip>
> You either trust the most recent signer and trust that THEY validated the
> previous signer/SPF (and so on) or the chain is broken anyway, so why add a
> parallel, easily falsified, chain of signatures?
>

There's a critical reason the ARC Seal exists that you're missing:

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.

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.

Seth

---

From: "John Levine" <[email-masked]>
Date: 8 Aug 2017 02:41:12 -0000

>thoughtful questions during the Prague DMARC session which prompted

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

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 08 Aug 2017 14:02:00 +1000

On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>> <[email-masked]> 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.> 
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.

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 08 Aug 2017 14:10:54 +1000

On Tue, 8 Aug 2017, at 09:22, Seth Blank wrote:
> On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana
> <[email-masked]> wrote:>> *AS adds nothing over just having AMS signing its own AAR, and then
>> you only have to verify ONE signature, the most recent.*>> 
>> <snip>
>> 
>> why add a parallel, easily falsified, chain of signatures?> 

I'm not missing it, I'm saying it doesn't work.

> 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.
Yeah, I believed that was true until I thought about the crypto.  Except
we don't know that the message was handled by a domain it says it was
handled by.  We only know that _A_ message was handled by the domain it
says it was handled by.  That could be any message.
> 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.
Except it doesn't, because all the AS before the first liar could have
been grabbed from a different message and you can't tell.
> 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
> 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.
Sure there is.  In case #1, you can check who signed each AMS and check
that each of them had an associated AAR in which they validated the
previous AMS.  No chain required.  In fact, you can just check the most
recent AMS, because you know they checked the previous one.  You trust
them to have done the checks they claim to have done.
AS just adds theatre.

I'm not sure if there's a point to me proving this by forging a message
with an AS of a site that it never went through.  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.
Bron.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 8 Aug 2017 06:36:02 -0700

On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana <[email-masked]>
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

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 08 Aug 2017 23:59:19 +1000

On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> <[email-masked]> wrote:>> __
>> 
>>   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.>> 
>> 
>> 
> 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.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Aug 2017 10:28:12 -0400

> something forgeable that looks like it means something.

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 8 Aug 2017 14:57:55 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, August 08, 2017 10:28 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre
> 
> > > 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.
> >
> > 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.
> > 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.
> 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

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 08 Aug 2017 20:16:30 -0400

On 8/8/2017 9:59 AM, Bron Gondwana wrote:
>> 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.
>
> 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.
>

I think we are falling back a Policy Model where we need to know what 
the all important originating Author domain desires. What is the 
expected here for mail processing by the domain?

I thought the main reason, purpose, the "PayOff" for ARC,  was to help 
deal with indirect mail breakage when a DMARC p=reject policy is set 
and more importantly, SMTP receivers with embedded DMARC support have 
begun honoring with hard 55x rejects or ACCEPT/DISCARD/SPAM local 
policy logic.

It is the same problem ADSP had, but it wasn't fully realized, only a 
proof of concept (demo) was shown (here in the list, by me). Receivers 
had yet to implement or turn on the ADSP DISCARD switch but we 
envisioned the indirect mail issue would begin when they did.  So it 
was foreseeable Mailing List members would begin to get unsubscribed 
due to perpetual erroneous receiver rejections.  DMARC proved it when 
the idea was implemented and honored and the screaming began.

ARC is trying to automate something without the help of the 
originating domain.  If ARC is suppose to help save the "message" and 
the author domain from using a p=reject on a mailing list or indirect 
mail travel,  then it leverage the DNS lookup it is already doing.

I think we have made this all too complex by resisting a policy 
concept that helps with all this main processing.  ADSP and DMARC had 
to same issue, so when was ADSP abandoned and  replaced with the 
"Super ADSP" version called DMARC,  the only difference was the 
reporting stuff, which is really not helping.

Anyway, food for thought, a DMARC Tag Extension called ArcSeal.  I'm 
just winging it, so the ARC cogs can consider, or not:

        ArcSeal=All       ; All ARC seals must be valid start to finish.

        ArcSeal=Last      ; Only the last sender/ARC signer is 
necessary (because
                            of the chain of trust).

I suppose there is a "Hops" count concept in there, but the ArcSeal 
tag does not exist, the the message is in an indeterminate state. If 
it exist, thats added value to the Domain declaring to the world what 
it expects and allows, including desirable hard rejection.

The main thing is the automation.  It help with an incentive to 
encourage implementors sitting on the fence. It can help by relaxing 
the rejection of the DMARC p=reject policy using ARC. Isn't that a big 
help?

Personally, I really don't want to waste any more years working on 
this ARC complex proposal and really, this DKIM project since the 
early 2000s.  Folks, we are approaching 15 years on this stuff!!!!  It 
has been a battle of the Trust Model vs Policy Model.  We almost had 
it VBR for TRUST and for Policy with ADSP (proposed standard) plus 
ATPS (experimental) as a possible solution to the indirect mail 
problem.  But abandoned and replaced with DMARC (Informational) which 
has the same problem ADSP was abandoned far.

Sorry for repeating the same thing, but DMARC is the same problem and 
whey we are here, no?

So if DMARC is it, can we please fix it and have it work with ARC to 
help resolve the indirect mail problem?

If not, than other than marketing bullshit, is there any "mail" 
benefit and convincing reason why ARC should be implemented?

Thanks.

-- 
HLS

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 10 Aug 2017 08:26:04 +1000

On Wed, 9 Aug 2017, at 00:28, Scott Kitterman wrote:
> 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.

---

From: Brandon Long <[email-masked]>
Date: Wed, 9 Aug 2017 17:41:29 -0700

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" <[email-masked]> wrote:

> 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.
>
>
> 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.
>
> 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
> I'm not saying that the underlying concept of ARC are wrong - the idea of
> chain of custody is sound.
>
> 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.
>
> --
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Brandon Long <[email-masked]>
Date: Wed, 9 Aug 2017 17:42:07 -0700

Sorry, posted from the wrong address, trying again.

On Aug 9, 2017 8:41 PM, "Brandon Long" <[email-masked]> wrote:

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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 10 Aug 2017 15:54:40 +1000

On Thu, 10 Aug 2017, at 10:41, Brandon Long wrote:
> 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.

> 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 people are posting to it
> though another intermediary or you receive it through a separate
> intermediary.
It wasn't so much this list, it was everything else in my entire mail
repository!  Not much with ARC on it yet.
Bron.

> Brandon
> 
> On Aug 9, 2017 6:26 PM, "Bron Gondwana"
>>> 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.>> 
>> means the whole message is tainted and should be discarded.>> 
>> integrity than checking the previous AMS and signing your own AAR
>> unless this is true:>> 
>>   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.
>> 
>> --
> _________________________________________________
> dmarc mailing list
> [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 09:27:01 -0700

> 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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Aug 2017 09:34:22 -0700

On Fri, Aug 11, 2017 at 9:27 AM, Dave Crocker <[email-masked]> 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!)
>

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 10:19:28 -0700

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 

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/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 10:22:58 -0700

On 8/11/2017 9:26 AM, Dave Crocker wrote:
> 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.
> 
> upon which ARC builds -- that is, what is it doing that is
> well-founded -- and what it is doing that is new.
> 

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

On 8/7/2017 4:22 PM, Seth Blank wrote:
> 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
> delivery decision as local policy dictates.
> 
> signatories, then there are a multitude of routes for the message to
> be garbage, including but not limited to everything you've outlined
> above.
> 
> handled but did not modify).
> 

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.
> 
> 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' 
> previous hops so the recipient can retroactively do filtering that
> the mailing list didn't.

d/

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 12 Aug 2017 09:54:06 +1000

On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:

I'm just picking out the key quote here:

>> (which must validate), and *the entire chain* of ARC Seals, not only>> the latest. This guarantees you a list of all message signatories -

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

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.
>> delivery decision as local policy dictates.

Agree.

>> signatories, then there are a multitude of routes for the message to>> be garbage, including but not limited to everything you've outlined
>> above.

Agree.

>> 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.
>> 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.
What has no value is a chain of ARC-Seal that has to stretch right back
to the start, because all that is doing is signing its own crypto and
some headers that can be trivially transplanted from another message.
If this list allows messages with attachments, you'll see a copy of
"signedforgery.txt" which has me pretending to be Kurt with the complex
test message he gave me in Prague.  I've forged the Subject and Body,
and then Sealed it as brong.net.
brong@zula:~/src/mail-dkim$ perl arc.pl < signedforgery.txt
pass

The fact that there is an intact chain of ARC-Seal is pointless here.
And as I have (hopefully successfully) argued above, if all the sites
are trusted and they each successfully cryptographically authenticate
the previous sender (or SPF at the first hop), you need is the AMS.  ARC-
Seal does nothing.
Bron.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Aug 2017 17:04:45 -0700

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

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

d/

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 11 Aug 2017 17:16:24 -0700

On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <[email-masked]>
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.
>

<elided>

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

<elided>

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 12 Aug 2017 10:19:38 +1000

On Sat, 12 Aug 2017, at 10:04, Dave Crocker 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
>> 
>> 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
> 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.

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 12 Aug 2017 10:27:21 +1000

On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
>>   everybody has to trust you or their chain breaks, even though you
>>   didn't do anything which required signing.> 
> <elided> 

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Aug 2017 19:22:09 -0400

On 8/11/2017 1:19 PM, Dave Crocker wrote:
>> 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.
>

This is important if there is going to be an wider implementation here 
especially among the community of non-open source developers.  This is 
where the expense will be and there is an  expectation of having a 
document can developers can produce code from.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Aug 2017 19:51:32 -0400

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

Its a great idea.... but it still suffers from the long time 3rd party 
signature registration problem.   This is why we are here.  All the 
DKIM policy models, including DMARC with a p=reject policy) suffered 
this issue.  ARC is suppose to save 3rd party signed indirect messages.

The "Arc-Authentication-Results" header can claim this but it still be 
phishing, forged mail -- no trust at the downlink receiver level 
and/or MUA client when DMARC p=reject rejection results are seen.

What is needed is the Originating Domain making this claim that 
authorizes X as a legitimate modifier.  We can either lookup that 
information (ATPS, https://tools.ietf.org/html/rfc6541) or we pass it 
as a new DKIM-signature. Levine had a DKIM Conditional proposal that 
does this. It wasn't a lookup concept, which I prefer, but Levine's 
idea was the next best option that touches base with a "3rd Party 
Authorization" concept:

    https://tools.ietf.org/html/draft-levine-dkim-conditional-02
    Abstract

    This experimental specification proposes a modification to DomainKeys
    Identified Mail (DKIM) allowing advertisement of third-party
    signature authorizations that are to be interpreted as equivalent to
    a signature added by the administrative domain of the message's
    author.

I'm not against ARC other than it seems like complex, overhead that 
doesn't address the main issue of authorized 3rd party routes.   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.

-- 
HLS

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Sun, 13 Aug 2017 07:28:01 -0700

On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos <[email-masked]> 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.
> <https://www.ietf.org/mailman/listinfo/dmarc>
>

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

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Mon, 14 Aug 2017 12:42:32 -0700

On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana <[email-masked]>
wrote:

> Which is why it's a bad idea to sign if you're not modifying, because then

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]

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 15 Aug 2017 10:12:01 +1000

On Tue, 15 Aug 2017, at 05:42, Brandon Long 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.
>> 
>> 
>>>> 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
>> 
>> 
>> then everybody has to trust you or their chain breaks, even though
>> you didn't do anything which required signing.> 
> 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.> 
> 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.
> 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!
> 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.
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.
So if we had this:

AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc=pass, dkim=fail, spf=fail
AAR: i=3, arc=pass, dkim=fail, spf=fail
AAR: i=2, arc=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

That would give you everything.  The one downside is that every ARC
layer added another item to the h= header in the AMS.  One nice thing
about AS is that you don't need the h=, because it's implied.
But overall I'd say removing the other AMS headers and all the AS
headers still leads to a smaller payload than adding one h=arc-authentication-
results for each hop.
Unless I'm missing something, this design is just as robust as the
existing AS,AMS,AAR for tracking chain of custody back to the first
untrusted site, and neither design is any good for knowing things for
certain about the changes made before the first untrusted site.
Of course - this design doesn't tell you which of the steps modified the
message any more (my first point above).  I do like the idea of tagging
the message with data about which hops modified it... which is an
argument for not stripping AMS while is still validates.  You would wind
up with something like:
AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]AAR: i=3, arc2=pass, dkim=fail, spf=fail
AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-results:[...]AAR: i=2, arc1=pass, dkim=pass, spf=fail
AAR: i=1, dkim=pass, spf=pass

Which tells you that i=3 and i=4 didn't modify the message, because arc2
passed when i=4 validated it (proving that i=3 didn't modify it), and
the AMS for i=2, i=3 and i=4 all pass now.
If the next hop was to modify the message it would add:

AAR: i=5, arc4=pass, arc3=pass, arc2=pass, dkim=fail, spf=fail

then strip all the existing AMS and add its own:

AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:arc-authentication-results:[...]
Which signed that it verified hops 3 and 4 as non-modifiers.

Regards,

Bron.

---

From: Seth Blank <[email-masked]>
Date: Mon, 14 Aug 2017 17:46:46 -0700

On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[email-masked]>
wrote:
> overcome this, some information from hop N about which previous hop was the
> last modifying hop.
>
>

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.

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

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.

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

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

If you throw old AMSs out, you cannot validate current ASs or walk the
chain back.

> So if we had this:
>
> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-
> results:arc-authentication-results:arc-authentication-results:[...]
> AAR: i=4, arc=pass, dkim=fail, spf=fail
> That would give you everything.  The one downside is that every ARC layer
> added another item to the h= header in the AMS.  One nice thing about AS is
> that you don't need the h=, because it's implied.
>

All these items already get added to the h=.

>
> But overall I'd say removing the other AMS headers and all the AS headers
> still leads to a smaller payload than adding one
> h=arc-authentication-results for each hop.
>

We can't remove old AMS and AS headers for the reasons listed above
(mainly, a) we're saving trace information to see what's beneficial
downstream, and b) you can't validate the latest AS or walk the chain back
if you throw out old headers).

> message any more (my first point above).  I do like the idea of tagging the
> message with data about which hops modified it... which is an argument for
> not stripping AMS while is still validates.  You would wind up with
> something like:
>
> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-
> results:arc-authentication-results:arc-authentication-results:[...]
> AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
> AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-
> results:arc-authentication-results:[...]
> AAR: i=3, arc2=pass, dkim=fail, spf=fail
> AMS: i=2 h=[...]:arc-authentication-results:arc-authentication-
> results:[...]
> AAR: i=2, arc1=pass, dkim=pass, spf=fail
> passed when i=4 validated it (proving that i=3 didn't modify it), and the
> AMS for i=2, i=3 and i=4 all pass now.
>
> AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-
> results:arc-authentication-results:arc-authentication-
> results:arc-authentication-results:[...]
>

I'll suggest language for stamping "first AMS failure", but we shouldn't
strip old AMS/AS headers.

Seth

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 15 Aug 2017 11:31:37 +1000

On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>>> 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.>>> 
>>> 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.> 
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,
>>> message.  This wasn't done with XOAR.>> 
>> 
>> 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!> 
> 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.
>>> 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 have a
>> cv=pass on the current AS.> 

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.
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
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.
>> So if we had this:
>> 
>> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-
>> authentication-results:arc-authentication-results:[...]>> AAR: i=4, arc=pass, dkim=fail, spf=fail
>> about AS is that you don't need the h=, because it's implied.> 

Of AS in the current draft, yes.  If we added AAR to AMS and kept AMS as
a DKIM signature structure, then we would want the h= key to contain the
full list of headers.
>> results for each hop.> 
> downstream, and b) you can't validate the latest AS or walk the chain
> back if you throw out old headers).
 Forget AS when reading my examples here, because I was assuming no AS.
>> certain about the changes made before the first untrusted site.>> 
>> Of course - this design doesn't tell you which of the steps modified
>> the message any more (my first point above).  I do like the idea of
>> tagging the message with data about which hops modified it... which
>> is an argument for not stripping AMS while is still validates.  You
>> would wind up with something like:>> 
>> AMS: i=4, h=[...]:arc-authentication-results:arc-authentication-results:arc-
>> authentication-results:arc-authentication-results:[...]>> AAR: i=4, arc3=pass, arc2=pass, dkim=fail, spf=fail
>> AMS: i=3 h=[...]:arc-authentication-results:arc-authentication-results:arc-
>> authentication-results:[...]>> AAR: i=3, arc2=pass, dkim=fail, spf=fail
>> results:[...]>> AAR: i=2, arc1=pass, dkim=pass, spf=fail
>> Which tells you that i=3 and i=4 didn't modify the message, because
>> arc2 passed when i=4 validated it (proving that i=3 didn't modify
>> it), and the AMS for i=2, i=3 and i=4 all pass now.>> 
>> AMS: i=5, h=[...]:arc-authentication-results:arc-authentication-results:arc-
>> authentication-results:arc-authentication-results:arc-authentication-
>> results:[...]>> 
> I'll suggest language for stamping "first AMS failure", but we
> shouldn't strip old AMS/AS headers.
This is where we disagree.  We shouldn't create AS headers in the
first place.
We should have AMS sign all the AAR and that's it.  No AS, no need to
retain broken AMS.
It gets you all the same machine readable chain of custody as AS+AMS+AAR
in the unbroken case, and it breaks at the same place with the same
detectability in the fraudulent-actor case.
There are no other cases.  There's no middle here.

Please do prove me wrong if you can think of another case, I
really can't.
Bron.

---

From: Seth Blank <[email-masked]>
Date: Mon, 14 Aug 2017 19:59:17 -0700

> actors definitely didn't modify the message is super useful.

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

> intermediates that couldn't modified the message without colluding with

That's also how I see it.

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

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

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

> infrastructure is needed to maintain the integrity of the chain of AAR
> headers.
>
> 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 AS's if they wish.

If this is the case, then we can't throw out any AMS because none of the
ASs would validate any longer.

> This is where we disagree.  We shouldn't create AS headers in the first
> place.
>

This is 180 degrees from where we left off on the call.

> detectability in the fraudulent-actor case.

I'll let someone who's more familiar with where ARC started from - my
understanding was that ARC stemmed from something similar to AMS+AAR being
insufficient, but I don't have enough context here to provide meaningful
insight.

Seth

>
> Please do prove me wrong if you can think of another case, I really can't.
>
> Bron.
>
> --

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 15 Aug 2017 13:26:40 +1000

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

>>>> 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.>>> 
>> 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
>> 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.
>> 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 AS's if they wish.> 
> If this is the case, then we can't throw out any AMS because none of
> the ASs would validate any longer.>  
>> 
>>> 
>>> shouldn't strip old AMS/AS headers.>> 
>> 
>> first place.> 

That is true.   We discussed an alternative world in which we keep the
AS but reduce the validation requirement.  That's my fallback position
if I can't convince people that AS is pointless.  It's not my preferred
position, which is where I went in response to Brandon's post.
>> retain broken AMS.>> 
>> It gets you all the same machine readable chain of custody as
>> AS+AMS+AAR  in the unbroken case, and it breaks at the same place
>> with the same detectability in the fraudulent-actor case.> 
> understanding was that ARC stemmed from something similar to AMS+AAR
> being insufficient, but I don't have enough context here to provide
> meaningful insight.
I would love to see that.

If you can show me a case where AS protects against a bad actor, and
where having the latest AMS signing all AAR doesn't provide equivalent
protection, I will eat a whole lot of crow and crawl back in my corner,
because I don't see it.
Bron.

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Aug 2017 13:46:35 -0400

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

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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 17 Aug 2017 10:21:43 +1000

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

---

From: Seth Blank <[email-masked]>
Date: Wed, 16 Aug 2017 17:34:11 -0700

On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <[email-masked]>
wrote:
> 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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 17 Aug 2017 10:47:38 +1000

On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
> <[email-masked]> 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.> 

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

---

From: Seth Blank <[email-masked]>
Date: Wed, 16 Aug 2017 18:32:50 -0700

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[email-masked]>
wrote:
> aware, you can't use ARC on a DMARC p=reject domain without rewriting the
> sender.  Otherwise that site will bounce the email.
>
> 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.

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 17 Aug 2017 11:47:58 +1000

On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> <[email-masked]> 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.>> 
>> 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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Aug 2017 22:28:10 -0700

> sender.  Otherwise that site will bounce the email.
Goodness, it's a wonder that we've ever successfully deployed anything
incremental around here.  ;-)

-MSK

---

From: Brandon Long <[email-masked]>
Date: Thu, 17 Aug 2017 11:44:47 -0700

On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[email-masked]>
wrote:

> DMARC p=reject, you can't send that message on to the members of your list
> without rewriting the sender.
>
> implement.

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

---

From: Brandon Long <[email-masked]>
Date: Thu, 17 Aug 2017 12:11:07 -0700

dammit, posted from the wrong address again...

Brandon

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 18 Aug 2017 07:46:37 +1000

> 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
>>> <[email-masked]> wrote:>>>> The only way you could even hope (as a mailing list) to avoid
>>>> 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.>>> 
>> 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.>> 
>> 
>>> receivers validate it.>>> 
>>> The only way a DMARC policy works is if enough receivers
>>> validate it.>>> 
>>> validate it.>>> 
>>> implement.>>> 
>>> 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
> 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.

---

From: Brandon Long <[email-masked]>
Date: Thu, 17 Aug 2017 17:22:48 -0700

On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana <[email-masked]>
wrote:

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

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

> I kind of buy that.  I'll be interested to see how it pans out in practice.
>
> header rewriting is certainly a much simpler solution for mailing lists...
> even as it makes them slightly worse to use.
>
>
> 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.
>
> deliverability, is to modify the message in such a way that DMARC no longer
> applies to it.
>

Yes.

Brandon

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 17 Aug 2017 23:46:46 -0700

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

---

From: Seth Blank <[email-masked]>
Date: Fri, 18 Aug 2017 10:00:27 -0700

On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen <[email-masked]> wrote:

> 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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Aug 2017 10:08:26 -0700

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

---

From: Seth Blank <[email-masked]>
Date: Fri, 18 Aug 2017 10:17:42 -0700

On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker <[email-masked]> wrote:

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Aug 2017 11:10:19 -0700

> 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

---

From: Brandon Long <[email-masked]>
Date: Fri, 18 Aug 2017 11:51:39 -0700

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 09:00:11 +1000

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

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Aug 2017 16:20:37 -0700

On 8/18/2017 11:10 AM, Murray S. Kucherawy wrote:
> 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/

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 10:26:35 +1000

On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote:
> On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker
> <[email-masked]> 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:
>> 
>>     appropriate, in spite of having a long and storied history of
>>     being used to resist a proposal.>> 
>>     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.> 
> 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. 

> 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 [email-masked]
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.

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 10:40:41 +1000

On Sat, 19 Aug 2017, at 04:51, Brandon Long wrote:
> 
> 
> On Fri, Aug 18, 2017 at 10:00 AM, Seth Blank
> <[email-masked]> wrote:>> On Thu, Aug 17, 2017 at 11:46 PM, Kurt Andersen
>> <[email-masked]> 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.>>> 
>>> 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)>>> 
>> 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.
> 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
  [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Aug 2017 18:43:55 -0700

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 11:47:24 +1000

On Sat, 19 Aug 2017, at 11:43, Murray S. Kucherawy wrote:
> On Thu, Aug 17, 2017 at 5:22 PM, Brandon Long
> <[email-masked]> 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.> 

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.

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Aug 2017 00:51:26 -0400

On 8/16/2017 9:32 PM, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>     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.
>
>
> again and again on and off this list.
>
> 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.

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

There will be domains that really, really do not want any 3rd party 
streams to interfere with their direct mail streams.  It helps protect 
their domain and reputation.  I suppose this concept and offering to 
operators.  I am asking what are the rules of the protocol game for 
DMARC and ARC.

> Knowing the landscape of receiving domains, I
> looks like, and what ARC does and does not solve.

I believe this was pretty obvious by now.  The same issues applied 
with SSP and ADSP which would technically resolve the Mailing List 
problem by augmented it with ATPS. I am one of the few packages that 
know it works in practice.  How is ARC any better to add now that 
DMARC has replaced ADSP?

What will be achieved when there is 10% of the stream versus 90% using 
ARC?  You can't treat them differently because it will leave Security 
Holes and an awful lot of waste if there is a low payoff.

> In its current form, ARC only helps mail flows, it does not harm them.

More headers adds processing, more complexity.  Lets keep in mind that 
not everyone uses open source libraries.  ARC will also add cost.

> makes it seem like the improvements are dramatic.

Only if there is an declaration by the authoring domain that says 
something about its mail.

> So let's get ARC

This sounds like repeated project research work.  We don't need a 
trillion messages to show what A) the problem is  and B) what the 
solution can be.  We can do that in theory and in practice with just 1 
message.  It was always about DKIM Trust/Reputation Model vs  DKIM 
Policy Authorization model. At some point that Policy declaration 
needs to be made. Somewhere, somehow, otherwise the problem doesn't go 
away.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Aug 2017 22:17:11 -0700

On Fri, Aug 18, 2017 at 6:47 PM, Bron Gondwana <[email-masked]>
wrote:

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Aug 2017 01:23:58 -0400

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

> change later.

+1

> I don't know the answer to that question immediately,

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

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Aug 2017 02:33:10 -0400

On 8/16/2017 8:21 PM, Bron Gondwana wrote:
> 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
> 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

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 19 Aug 2017 17:48:53 +1000

On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote:
>> We spent a while thinking about this (Neil and myself from FastMail)>> at IETF99 after learning how ARC works, and came to the conclusion
>> 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
> 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=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

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.

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Aug 2017 11:22:22 -0400

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