ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Fenton-DKIM-Threat-02 3.1. Use of Arbitrary Identities (and SSP)

2006-01-09 16:28:00
Frank Ellermann wrote:

Jim Fenton wrote:
 

the email-address domain owner (to use your term) or
originating-address domain owner (to use mine)
   


Doug's vaguer term might be better until I know precisely what
you're talking about, "originator", "author", "sender", "PRA",
or what else.  It's not the Return-Path and no "opaque-ID", so
far I'm still on your track.

If you transform it into draft-dkim-threats-00 I hope you'll
add more to appendix A:  "Typically the 2822-From" is a trivial
case, if you really want that say "author" instead of "origin",
this would also exclude Resent-From.
 

I'm sure I don't mean "author".  Repeating a bit of what I said
elsewhere, what I'm trying to convey is "who it's from", as defined by
what a typical email user would say when they look at a message.  It's
that address that really matters to them.  The reason I say "Typically
the 2822-From" is that it's my belief that most users will point to it
and say "It's from [whomever]".  I looked at your message and said to
myself "it's from  Frank Ellermann", not "it's from ietf-dkim-bounces".

What's ADMD ?  Some kind of MTA either DKIM-signing messages,
or checking the signature, that point is clear.  Your diagram
apparently suggests that the "signer policy" is only checked
for a "verified domain".  Is that intentional, and how is it
supposed to work for unsigned mails ?
 

Dave Crocker contributed the diagram, which I appreciate because I'm not
good at creating diagrams.  I assume it means "administrative domain". 
Dave?

| Placeholder for some discussion of 2821 vs. 2822 solutions

Say that DKIM is by design independent of the transport, and
that has obvious advantages and disadvantages.  Nothing in the
existing 2821 solutions is incompatible with DKIM.  No need to
go into details, anybody who cares knows where to find tons of
Caveats for PRA, it's also simple to test it.
 

That's a good thing to say.

| These tools may or may not falsify the origin address

s/may or may not/typically allow to/  It's draft about threats,
not CAN SPAM compliant spam novices.

| and possibly networks of compromised computers ("zombies")

s/possibly//  No doubt about that.

| Access to significant computing resources, perhaps through
| the conscription of worm-infected "zombie" computers.

s/perhaps/normally/ or similar, there's no doubt about this...
 

I like the more straightforward wordings.

| Ability to "wiretap" some existing traffic

...OTOH that's rather special, isn't it ?  No problem with
listing it as possibility, of course, if it later turns out
to be related to DKIM in some way.
 

I don't see it as being much more special, or difficult, than
manipulating IP routing.

| Certain attacks are possible primarily within the
| administrative unit of the claimed originator

This AU stuff invariably turns into a mouthful, why not use
Keith's term MON (mail originating network).  It's perfectly
clear that a "zombie" can pick any route also available to
its former owner including any MSAs signing mail with DKIM.
 

I'm happy to use any term that fits but I want to be consistent.  Is
there a definition of MON somewhere that I can read and refer to?

| and/or recipient domain

"AU of the recipient domain" is also tricky, but Keith's MRN
is clear, who cares how they adminster or outsource their MXs
and AV, and in what adminstrative relationship they are with
the domain part of the original or replaced RCPT TO.
 

There's one vote for Keith's terminology.  Any other opinions, anyone?

| DKIM focuses primarily on bad actors located outside of the
| administrative units of the claimed originator and the
| recipient.

That would be the "MON of the purported author(s)" if you're
talking about the 2822-From, and the MRN on the side of the
final RCPT TO.  I skip further "AU" issues.  Essentially it's
a matter of taste which terms you use, but with "AU" it tends
to get pretty verbose.  In your short form "AU of the claimed
originator" it makes IMHO no sense.

[Internal bad actors on the MON side]
| DKIM is not directly effective against these bad actors.

Of course not.  It might make it worse if the bad actors get a
DKIM PASS, isn't that the main threat ?

| DKIM is effective in mitigating against the use of addresses
| not controlled by bad actors

That's unclear, which addresses, author(s) / sender / PRA ?
 

If you consider SSP, probably "originating address".

Nit or my DEnglish, shouldn't that be "against the abuse of" ?
 

If it's a bad actor, it's almost certainly "abuse".

| In other words, the presence of a valid DKIM signature does
| not guarantee that the signer is not a bad actor.

ACK, same as SPF PASS.  Even if it's no stranger, it could be
somebody we know turned into a zombie.

| It also does not guarantee the accountability of the signer,

What do they sign it for if they're not accountable ?  That's
different from SPF PASS.  For the latter you can at least send
bounces and auto replies without hitting innocent bystanders -
incl. any SPF PASS of bad actors.  JFTR, nothing you need to
mention in your draft.
 

This is that paragraph I need to rewrite, because I was thinking about
the individual that is the administrator of the domain, but of course
DKIM doesn't trace accountability to individuals who are domain owners,
only to the domains.

| accreditation and reputation systems can be used to enhance
| the accountability of DKIM-verified addresses and/or the
| likelihood that signed messages are desirable.

Better add "white or black listing" as example / explanation,
 

Good point.

3.2 is about "eBoy", how about s/specific/look-alike/ or a
similar term ?  IMHO DKIM will be not completely ineffective:
 

We aren't really getting into the specifics of the attacks at this point
in the document.  The attacker has a specific target in mind that they
want to attack.  The use of look-alike domains is a means to that end.

If I'm used to see a PASS for paypal.com, and get a NEUTRAL
for mail.paypal.com.au, then it's "suspicious".  Creating a
funny thread on the spamcop list for that fresh and real case.
 

I tend to think of that as a (mental) reputation: it's not something we
can depend on.

| Compromised system within originator's | Medium | Medium |
| network                                |        |        |

That could be "high + low" for a phish.  Or for a mail worm
installing a keylogger it could be "high + medium".  It's the
case I most worry about:  White listed address with DKIM PASS
turned into a zombie.
 

Whether it's high or medium impact (based on my definitions) depends on
how strictly the originating domain restricts access to message
signing.  But since that's outside the scope of DKIM, I'm inclined to
raise the impact to High.

It's no "DKIM bug" or something, but it's a real danger, where
any scheme offering some kind of PASS could make it worse, if
receivers aren't educated to stay vigilant.

| It may also help locate the compromised system that is the
| source of the messages more quickly.

Yes, that "may" help.  No much progress with that, blocking
port 25 is a cheap snake oil.

| Look-alike domain names                |  High  |  High  |

Oops, yes, you're right, I forgot that they will get a PASS for
their look-alike domain.  IMHO you can delete I18N as special
"high : medium" case, soon nothing will be special with IDNA.

[multiple authors]
| This is an area in need of further study.

Yes, but "pick the first" sounds like a good idea.  Even very
stupid MUAs should somehow manage to display at least the first
author (in all scenarios with bad actors).
 

That was our inclination.

All in all no serious problem, if we can agree on talking about
author(s) for the 2822-From.  Not "origiator", PRA, or "sender"
unless you seriously want it after you have precisely defined
it, RFC, section, paragraph, sentence.  That's burnt territory.

Maybe a stupid metaphor, AU is like NFKD, MON + MRN like NFKC,
both are fine, but you need the latter for your threats draft.
 

You lost me on the metaphor.  I assume you mean the Unicode acronyms
NFKD and NFKC?

Thanks for your comments!

-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org