Subject: Re: [ietf-822] one can re-sign without a permission to re-sign header

From: "John Levine" <[email-masked]>
Date: 1 May 2014 19:54:49 -0000

>author's site. That shouldn't require the mailing list to communicate 
>with the author's site, but it might require the author's site to get 
>something from the mailing list's site.

That seems overcomplicated.  Just make the expiration time fairly
short, since it's a rare mailing list that takes more than a day to do
its thing.

>> Perhaps it's time for a more concrete proposal to be written down.

It occurred to me that there's a very simple way to do this:

http://datatracker.ietf.org/doc/draft-levine-may-forward/

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 May 2014 00:42:44 -0700

> http://datatracker.ietf.org/doc/draft-levine-may-forward/

Dear John,

Thank you for taking time to create this draft.  It seems to meet Pete's expectations.  As suggested, it also provides a repository of replay-able cryptographic tokens aimed at defeating both DMARC and DKIM protection when used in a timely fashion.  Should all mailing-lists hold DMARC protected messages until DKIM signatures expire?  Perhaps even add warnings in the friendly name that such messages are only intended for third-party services.

Author Domains still need to signal their understanding of the message's destination. Not really any different from TPA, but TPA does not impact how mailing-lists or other third-party services work, or potentially defeat protections of other messages, or change the signatures being applied. At least, this draft suggests the Author Domain cares about the harm their DMARC policy might cause.  Setting p=quarantine seems much easier.

Regards,
Douglas Otis

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 02 May 2014 14:48:14 +0200

> http://datatracker.ietf.org/doc/draft-levine-may-forward/

Nice one, John!  However, the Security Considerations call for a major
addition, IMHO.  In what cases would a signer add an mf=, weak signature?

*Always* introduces a real security risk, unless all assessors are
modified so as to check the sender is a valid mailing list.  I think
many sites accept DKIM signatures as authentication, so putting a
negligible mf=y on a blank signature creates an attack vector for
phishing.  Of course, domains like PayPal.com will never produce such
signatures.  If Yahoo! do them, however, they'll loose whatever they
gained by letting p=reject.

*ML only* puts the burden of determining whether an entity is a
mailing list on the signer, rather than leaving it to the assessor.
Sites who trust their users have an advantage here; Yahoo! remains in
a questionable position.

Wouldn't it be more direct, albeit more demanding, to propose a
standard for mailing lists?  Such document would also tell how to
discover them, and how to subscribe, and...

Ale

---

From: Paul Smith <[email-masked]>
Date: Fri, 02 May 2014 13:58:41 +0100

> http://datatracker.ietf.org/doc/draft-levine-may-forward/
Isn't this a bit dangerous?

I don't mean the draft - I mean what the draft suggests.

Unless I'm misunderstanding something badly, essentially all you are 
doing is signing the 'From' header field. So, if I get hold of one of 
those messages, I can just reproduce it and send zillions more messages 
pretending to be from you all with your From header, and all 'signed 
correctly'.

Maybe that's the point - the draft essentially makes clear that you 
can't use DKIM from the sender to authenticate the message, as the From 
header is pretty much all you can rely on staying the same (if that) by 
the time the list recipient gets the message from the mailing list. 
Hence trying to do this is a bad idea.

IMHO, you'd be better off just not using DKIM at all in these 
situations, rather than giving out a way for people to forge mail from 
you and 'sign' it.

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

---

From: Pete Resnick <[email-masked]>
Date: Fri, 2 May 2014 09:33:10 -0500

> http://datatracker.ietf.org/doc/draft-levine-may-forward/

I don't see any replay protection in here at all. Nothing that says to 
keep the signature expiration relatively short, and nothing which a 
mailing list recipient could not subsequently use to send spam. The 
first issue just needs a mention. It's the second issue that needs to be 
addressed IMO:

As an originating site, I do not want to give permission to forward to 
just anyone. I want to indicate that I was sending to someone in 
particular, e.g., [email-masked], and [email-masked]* has permission to 
forward. (An originating site should be  fine with their being a 
subsequent re-forwarding, say [email-masked] sending to [email-masked] which 
forwards, but I think they'd expect [email-masked] to have given 
permission to [email-masked] to re-forward, and the eventual recipient will 
be able to see that chain.)

That's why I suggest that the originating site is going to want to talk 
to the mailing list site: "This message was sent from user@mydomain to 
[email-masked]. You had better see my signature *and* received it from 
a.example." Your proposal doesn't do that.

Maybe people who are now setting p=reject don't care. Maybe all they 
care about is a short-lived signature and permission to re-forward. But 
I don't think that's likely to be true. I think they care about the 
replay problem. Otherwise, it's inviting spammers to subscribe to 
(especially well-used) mailing lists so that they can get and endless 
supply of replayable signatures.

I wouldn't bother with what you've proposed.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "John R Levine" <[email-masked]>
Date: 2 May 2014 10:42:32 -0400

> I don't see any replay protection in here at all. Nothing that says to keep 
> the signature expiration relatively short, and nothing which a mailing list 
> recipient could not subsequently use to send spam. The first issue just needs 
> a mention. It's the second issue that needs to be addressed IMO:

Yeah, that occurred to me about five minutes after I posted it.  Here's a 
tweaked version where the mf tag is now mf=list.domain, with handwaving 
about how a may-forward signature doesn't count unless there's also a 
signature from the list domain.  Given lengthy discussions about how 
little abuse comes from real mailing lists, that'd probably be adequate.

> I wouldn't bother with what you've proposed.

Neither would I.  Whitelisting solves this problem far better.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Hector Santos <[email-masked]>
Date: Fri, 02 May 2014 12:44:07 -0400

> Neither would I.  Whitelisting solves this problem far better.

Assuming you mean a signer domain and/or list domain whitelist, no it 
doesn't John. It doesn't do diddly squat about dealing with protocol 
faults which is what this is all about and always have been for 9 
years John. That can only come from the message anchoring domain -- 
the originating source/author domain.

What if the Signature is missing or invalid?  What if the mf=y tag 
doesn't exist and it was intentionally left out which will be the 
default considerations such this would be an "DKIM Add-on" concept? 
Are you going to continue to forward?

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 May 2014 10:09:03 -0700

On May 2, 2014, at 9:44 AM, Hector Santos <[email-masked]> wrote:

> Assuming you mean a signer domain and/or list domain whitelist, no it doesn't John. It doesn't do diddly squat about dealing with protocol faults which is what this is all about and always have been for 9 years John. That can only come from the message anchoring domain -- the originating source/author domain.
> 
> What if the Signature is missing or invalid?  What if the mf=y tag doesn't exist and it was intentionally left out which will be the default considerations such this would be an "DKIM Add-on" concept? Are you going to continue to forward?

Dear Hector,

I hope you are willing to review a TPA draft.  It is not really just a white-list since it combines validation of third-party services together with specific exceptions granted by trusted domains conveyed in a message (Author Domain in most cases.)  It does not suffer from the complex overhead of creating special signatures for specific senders and recipients.  This seems to be an issue overlooked in John's rendition of Pete's request.  If Pete is serious, perhaps added tuples of author-domain and third-party/intended recipients could define a DKIM replacement/enhancement.  The TPA approach should still be easier to manage and adapt to technical changes without any increase in average message size.  In either case, the sender MUST convey additional information to mitigate disruption of legitimate messages caused by requested restrictive policies.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Sat, 03 May 2014 12:42:57 -0400

On 5/2/2014 1:09 PM, Douglas Otis wrote:

> Dear Hector,
>
> I hope you are willing to review a TPA draft.

Doug, I did go over your drafts in 2009 when it was rev3.  I see I 
even explored compiling your C code under Windows to create labels:

  Directory of M:\rfc\dkim

10/12/2009  10:45 PM            39,185 draft-otis-dkim-tpa-label-03.txt
10/17/2009  08:44 AM             7,175 tpa3.cpp
10/17/2009  08:44 AM            16,384 tpa3.exe

I don't know how much rev6 changed, but as I recalled mentioning to 
you in 2009, there was too much details to follow but it was 
definitely a much wider scope and coverage.  But we all had the same 
basic idea and fundamental problem of an authorized 3rd party 
(re)signer need, whether it was with:

    SSP  Sender Signer Practices
    ADSP Author Domain Signer Practices (RFC5617)
    ASL  ADSP extension for 3rd party (smaller scale)
    ATPS ADSP extension for 3rd party (RFC6541) (larger scale)
    TPA  ADSP extension for 3rd party (wider scope, large scale)

The technical problem was how to best do this via DNS, the scaling and 
optimization with a plug and play DKIM security policy layer as it was 
originally envisioned.  The practical problem was to how convince 
publishers and verifiers, especially resigners, to support and also 
enforce the stronger, restrictive policies as a deterministic mail filter.

It was made a harder problem with the interest of the 3rd party 
resigner became more important than the interest of the originating 
author domain.  This was burned in RFC5016 Section 5.3 Item 10 
functional requirements.  IMO, that needs to be corrected and not 
carried over to any future signing practice requirements or 
specifications doc.  That is not to suggest local policy does not 
prevail in any situation, but it would be the first security protocol 
principle to support the highest domain protection payoff value a 
security protocol has to offer over all any other modes of operations. 
You can't just intentionally ignore it knowing full well what the 
purpose of the security policy protocol was designed to do.

So I think we need to revisit the functional requirements for a DKIM 
Sender/Author Signing Practice protocol.  I believe this will help 
update DMARC or any other "improved DMARC" that comes down the road. 
We need to revisit the basic process model DKIM framework for both 
POLICY and TRUST where a:

    - Message comes in,
    - Verifier Check Author Domain Policy,
    - Verifier Check Signer Trust Policy.

Just like the RFC5585 DKIM Service Overview illustrates and outlines 
in Figure 1:

                              |
                              |- RFC5322 Message
                              V
+--------+    +--------------------------------+
| Private|    |  ORIGINATING OR RELAYING ADMD  |
| Key    +...>|  Sign Message with SDID        |
| Store  |    +---------------+----------------+
+--------+                    |
  (paired)                 [Internet]
+--------+                    |                     +-----------+
| Public |    +--------------------------------+    | Remote    |
| Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
| Store  |    |  Message Signed?               |    | Practices |
+----+---+    +-----+--------------------+-----+    +-----+-----+
      .              |yes                 |no              .
      .              V                    |                .
      .        +-------------+            |                .
      +.......>|  Verify     +--------+   |                .
               |  Signature  |        |   |                .
               +------+------+        |   |                .
                  pass|           fail|   |                .
                      V               |   |                .
               +-------------+        |   |                .
               |             |        |   |                .
      +.......>| Assessments |        |   |                .
      .        |             |        V   V                .
      .        +-----+--+----+      +-------+              .
      .              |  |          / Check   \<............+
      .              |  +-------->/  Signing  \
      .              |           /   Practices \<..........+
      .              |          +-------+-------+          .
      .              |                  |                  .
      .              |                  V                  .
+----+--------+     |            +-----------+     +------+-----+
|Reputation/  |     |            | Message   |     | Local Info |
|Accreditation|     +----------->| Filtering |     | on Sender  |
|Info         |                  | Engine    |     | Practices  |
+-------------+                  +-----------+     +------------+

                 Figure 1: DKIM Service Architecture

So the framework was laid out. We just need to get folks to support 
the Check Signing Practice (CSP) module and also honor the policy. 
The "Local Info On Sender Practices" module is what John Levine wants 
people to do, including a whitelist.  Thats fine, but it wouldn't be a 
consistent and persistent result across SMTP receiver sites unless 
they had the same local information. Even if this WhiteList was 
centralized,  it should still check and honor how restrictive the 
domain policy is.

-- 
HLS

---

From: Paul Smith <[email-masked]>
Date: Mon, 05 May 2014 09:50:47 +0100

On 02/05/2014 15:42, John R Levine wrote:
>> I don't see any replay protection in here at all. Nothing that says 
>> to keep the signature expiration relatively short, and nothing which 
>> a mailing list recipient could not subsequently use to send spam. The 
>> first issue just needs a mention. It's the second issue that needs to 
>> be addressed IMO:
>
> Yeah, that occurred to me about five minutes after I posted it. Here's 
> a tweaked version where the mf tag is now mf=list.domain, with 
> handwaving about how a may-forward signature doesn't count unless 
> there's also a signature from the list domain.  Given lengthy 
> discussions about how little abuse comes from real mailing lists, 
> that'd probably be adequate.
>
Could this be 'extended' to include message-ids in the MF signature?

That would provide some replay protection, especially if the forwarder 
checks for duplicate message-ids (the recipient could also check for 
dupes). Without it, I could see one of your messages on a list, then 
send messages to everyone on the list, pretending to be you.

-

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 11:19:00 -0700

On Fri, May 2, 2014 at 7:42 AM, John R Levine <[email-masked]> wrote:

>> keep the signature expiration relatively short, and nothing which a mailing
>> list recipient could not subsequently use to send spam. The first issue
>> just needs a mention. It's the second issue that needs to be addressed IMO:
>>
>
> signature from the list domain.  Given lengthy discussions about how little
> abuse comes from real mailing lists, that'd probably be adequate.
>

If we want to pursue a may-forward approach, this looks like a good
starting point to me.

If we're discarding may-forward, then it seems to me we might be better off
talking about a whitelist publish/query mechanism that deserves
standardization here.  Does VBR or a slight modification to it suffice, or
do we want something else?

-MSK

---

From: Brandon Long <[email-masked]>
Date: Mon, 5 May 2014 11:32:32 -0700

On Mon, May 5, 2014 at 1:50 AM, Paul Smith <[email-masked]> wrote:

> dupes). Without it, I could see one of your messages on a list, then send
> messages to everyone on the list, pretending to be you.

I was wondering if we wanted a new canonicalization which would allow for
the Subject to be included but stripped of "standard" MLM subject prefixes,
ie something similar to the reply_regexp in mutt (
http://www.mutt.org/doc/devel/manual.html#reply-regexp)

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2014 16:45:58 -0400

> do we want something else?

Anything that whitelists by domain name is going to end up similar to VBR, 
so if that's what we want to do, we might as well use VBR.  I am assuming 
that this would not be a straight to the inbox whitelist, just one to skip 
DMARC policy processing.

VBR can use a DKIM signature or validated SPF bounce address as a lookup 
handle (or Domain Keys or Sender ID, but I hope we agree they're dead.)

Regards,

---

From: "John Levine" <[email-masked]>
Date: 6 May 2014 02:01:59 -0000

>send messages to everyone on the list, pretending to be you.

You could, but now we're back to whether we believe that list managers
act to keep crud out of their lists.  In general, I observe that they
do, so I don't see any point to adding features that assume that
managers will just sit there and allow subscribers to abuse their
lists.

Anecdote: I am on one non-technical list where there is an extremely
obnoxious person who chronically poisons the dialog, yet the list
managers are unwilling to eject.  (My guess is that he is a large
donor to the organization.)  I have dealt with him by bozo filtering
his mail in procmail, but other people keep writing to me and asking
isn't there list software that will let subscribers decide which other
subscribers' mail to get, i.e. do the bozo filtering in the list
software.  As far as I can tell, no, because this is not a problem
that many lists have.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 May 2014 19:34:27 -0700

> managers will just sit there and allow subscribers to abuse their

This sounds a lot like what ATPS turned out to be, except that it didn't
give much thought to replay protection.  Maybe we can build on that instead?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 5 May 2014 22:41:49 -0400

> give much thought to replay protection.  Maybe we can build on that instead?

I'd rather stick with the whitelists, since they can solve more problems 
than the various signtature-transit hacks can.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Mon, 05 May 2014 23:29:05 -0400

IDEA:  do both

On 5/5/2014 10:41 PM, John R Levine wrote:
> I'd rather stick with the whitelists, since they can solve more
> problems than the various signtature-transit hacks can.

-- 
HLS