Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

Yes, later in the thread we all agreed that "don't do this" is far better
than any protocol solution.

On Mon, Nov 28, 2016, 11:30 Jim Fenton  wrote:

> Waking up to this thread a little late...
>
>
> On 11/14/16 7:38 AM, Michael Thomas wrote:
>
> On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
>
> On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany 
> wrote:
>
> Hi Murray.
>
>
> Mark!
>
> > RFC6376 and even RFC4871, but now it's apparently happening
>
> I'd be interested to hear about the actual scenarios. Are the targeted
> users somehow given an indication that the email verifies and it's
> from a credible domain and yet it contains a malevolent payload?
>
>
> As I understand the attack:
>
> Spammer tries to send spam to a victim.  The MSA blocks this because it's
> spam.  However, the spam filter is not applied to mail sent by the spammer
> to itself, because why would that be a problem?  So the spammer sends
> itself a piece of spam, which the MSA dutifully signs.  Then the spammer
> downloads that message and remails it using whatever envelope it likes.
> The signature will continue to validate, carrying the reputation of the
> signing domain through any whitelist or other system that says this signer
> tends to send good mail.
>
>
>
> This sounds like a misconfiguration problem.It's a problem because it's
> $spam/$malware/$bad regardless of who the recipient is.
>
> The rule is: if you think it's bad, don't sign it. If you sign it, you own
> it.
>
> So to put Mike's comment a different way: Why is the MSA signing something
> that isn't subject to scrutiny? If the message is just going back to the
> sender, it doesn't need a signature.  It sounds like this problem could be
> addressed by putting signing after the outgoing spam check, with no change
> to the protocol.
>
>
> -Jim
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Jim Fenton]

Waking up to this thread a little late...

On 11/14/16 7:38 AM, Michael Thomas wrote:
> On 11/13/2016 09:38 PM, Murray S. Kucherawy wrote:
>> On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany > > wrote:
>>
>> Hi Murray.
>>
>>
>> Mark!
>>
>> > RFC6376 and even RFC4871, but now it's apparently happening
>>
>> I'd be interested to hear about the actual scenarios. Are the
>> targeted
>> users somehow given an indication that the email verifies and it's
>> from a credible domain and yet it contains a malevolent payload?
>>
>>
>> As I understand the attack:
>>
>> Spammer tries to send spam to a victim.  The MSA blocks this because
>> it's spam.  However, the spam filter is not applied to mail sent by
>> the spammer to itself, because why would that be a problem?  So the
>> spammer sends itself a piece of spam, which the MSA dutifully signs. 
>> Then the spammer downloads that message and remails it using whatever
>> envelope it likes.  The signature will continue to validate, carrying
>> the reputation of the signing domain through any whitelist or other
>> system that says this signer tends to send good mail.
>>  
>
> This sounds like a misconfiguration problem.It's a problem because
> it's $spam/$malware/$bad regardless of who the recipient is.
>
> The rule is: if you think it's bad, don't sign it. If you sign it, you
> own it.
So to put Mike's comment a different way: Why is the MSA signing
something that isn't subject to scrutiny? If the message is just going
back to the sender, it doesn't need a signature.  It sounds like this
problem could be addressed by putting signing after the outgoing spam
check, with no change to the protocol.

-Jim
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Martijn Grooten]

On Mon, Nov 14, 2016 at 02:48:01PM +0900, Murray S. Kucherawy wrote:
> On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten 
> wrote:
> 
> It isn't very clear to me how this proposal deals with receipients at
> different domains, including but not limited to blind carbon copies. I
> may be showing my ignorance of how DKIM signing engines work under the
> hood, but unless the email is not signed until a copy has been created
> for each receiving domain, my understanding of the draft is that this
> would result in every receiving domain receiving an invalid copy of the
> email.
> 
> 
> Yes, if you have three recipients going to distinct MXes, and you want this to
> work, you need to sign each copy individually.  You need to anticipate how the
> message is likely to arrive, basically

This sounds like something that could easily go wrong, unless signing
agents take a very cautious approach and create individual copies for
each recipient domain. And even then, as the draft already mentions in
section 5, it could go wrong if the verifier doesn't get the complete
list of recipients.

> Finally, is there a reason the proposal doesn't sign the canonicalized
> list of recipients separately and add this signature as a separate DKIM
> tag? This could allow for a more smooth transition period.
> 
> Now that's an interesting idea.

Other than that it makes the proposal backwards-compatible, it also
gives some insight in possible replay attacks against DKIM. And it
allows a spam filter that uses DKIM to make more granular decisions,
e.g. "this looks like a replay attack, but the sender is a known list
server, so it's probably okay".

> One could even sign each recipient individually and add a list of
> signatures to a separate DKIM header. This would allow the verifier to
> check each recipient individually, which should be doable if their
> number isn't too big and does not require knowledge of which signature
> links to which recipient.
> 
> I think that adds additional complexity beyond your previous suggestion and 
> I'm
> not sure what the incremental gain is.

It would allow for more flexibility. The current proposal checks whether
the set of recipients seen by the verifier is the same set as that seen
by the signing agent, while to prevent replay attacks, it only matters
that the former is a subset of the latter.

Mind you, it may still add too much additional complexity. And maybe
there is an easier way to solve this cryptographically. I'll look
around.

Martijn.

___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

On Sun, Nov 13, 2016 at 9:39 PM, Mark Delany 
wrote:

> Hi Murray.
>

Mark!

> RFC6376 and even RFC4871, but now it's apparently happening
>
> I'd be interested to hear about the actual scenarios. Are the targeted
> users somehow given an indication that the email verifies and it's
> from a credible domain and yet it contains a malevolent payload?
>

As I understand the attack:

Spammer tries to send spam to a victim.  The MSA blocks this because it's
spam.  However, the spam filter is not applied to mail sent by the spammer
to itself, because why would that be a problem?  So the spammer sends
itself a piece of spam, which the MSA dutifully signs.  Then the spammer
downloads that message and remails it using whatever envelope it likes.
The signature will continue to validate, carrying the reputation of the
signing domain through any whitelist or other system that says this signer
tends to send good mail.


> This sounds like some sort of quarantine system which only looks at
> verification status.
>

Sort of, yeah.  It's any receiver that gives preferential treatment to
messages signed by particular domains.


> It's too bad formal communication to the MUA was eliminated in
> DKIM. The original hope was that after a decade or so, MUAs would have
> evolved to participate and make some rendering indication in such
> situations. After all, an unknown-to-the-MUA to:/cc: recipient or
> domain in a verified email is highly actionable.
>

Which channel was eliminated?  I think RFC7601 could help if that's what
you're referring to.


> Anyway, based on your draft I presume the desire is still to retain
> the binary verification status as a strong dispositional attribute
> that is handled by anything *but* the MUA?
>

Right, that seems to be the attack that needs addressing.


> In the section that discusses the impact on forwarded and list email
> you might want to highlight that the proposal could further reduce
> email to a point-to-point protocol. In which case an alternative
> long-term strategy might be simply to insist on strong SPF checks
> rather than signatures. Or do SPF checks not help the scenario you're
> addressing here?
>

SPF might indeed help for cases where there are no intermediate hops.

Both good suggestions.  Thanks!

-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Martijn Grooten]

On Sun, Nov 13, 2016 at 03:50:05PM +0900, Murray S. Kucherawy wrote:
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/
> 
> Comments welcome.

Thanks for this.

It isn't very clear to me how this proposal deals with receipients at
different domains, including but not limited to blind carbon copies. I
may be showing my ignorance of how DKIM signing engines work under the
hood, but unless the email is not signed until a copy has been created
for each receiving domain, my understanding of the draft is that this
would result in every receiving domain receiving an invalid copy of the
email.

I also think it wouldn't hurt to make point 2 of section 4.1 a bit more
explicit: should the addresses be converted to lowercase? To ASCII?

Finally, is there a reason the proposal doesn't sign the canonicalized
list of recipients separately and add this signature as a separate DKIM
tag? This could allow for a more smooth transition period.

One could even sign each recipient individually and add a list of
signatures to a separate DKIM header. This would allow the verifier to
check each recipient individually, which should be doable if their
number isn't too big and does not require knowledge of which signature
links to which recipient.

Martijn.



signature.asc
Description: Digital signature
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

[Mark Delany]

Hi Murray.


> RFC6376 and even RFC4871, but now it's apparently happening

I'd be interested to hear about the actual scenarios. Are the targeted
users somehow given an indication that the email verifies and it's
from a credible domain and yet it contains a malevolent payload?

This sounds like some sort of quarantine system which only looks at
verification status.


It's too bad formal communication to the MUA was eliminated in
DKIM. The original hope was that after a decade or so, MUAs would have
evolved to participate and make some rendering indication in such
situations. After all, an unknown-to-the-MUA to:/cc: recipient or
domain in a verified email is highly actionable.

Anyway, based on your draft I presume the desire is still to retain
the binary verification status as a strong dispositional attribute
that is handled by anything *but* the MUA?

In the section that discusses the impact on forwarded and list email
you might want to highlight that the proposal could further reduce
email to a point-to-point protocol. In which case an alternative
long-term strategy might be simply to insist on strong SPF checks
rather than signatures. Or do SPF checks not help the scenario you're
addressing here?


Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] draft-kucherawy-dmarc-rcpts

[Murray S. Kucherawy]

I've posted a draft that attempts to address an attack that's begun to
appear with DKIM.  Interestingly, we called it out as a possible attack in
RFC6376 and even RFC4871, but now it's apparently happening and being
annoying enough that people (I believe from the MAAWG community) are asking
if there's a protocol solution that's possible.

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Comments welcome.

-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html