Subject: [secdir] Review of draft-ietf-dkim-ssp-08

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Jan 2009 12:06:48 -0800

$Id: draft-ietf-dkim-ssp-08-rev.txt,v 1.1 2009/01/02 19:05:45 ekr Exp $

This document describes a way for domains to publish their policy
vis-a-vis signing emails with DKIM. The idea here is that when
you receive an email that is not signed you would like to be able
to distinguish (at least) two cases:

- The domain doesn't sign.
- This is a forgery.

This document (hereafter called ADSP) allows the domain to advertise
its signing policy, thus allowing recipients to distinguish these
(and some other) cases.

Generally, this approach and the protocol it describes seem sound.
However, I have some concerns as detailed below.

One general question: I see you're using TXT here. I know this
is a hot button for the DNS people. If you haven't cleared this
with them, that might be good. If you have, then ignore this
comment.

TECHNICAL
S 3.

   Hosts can look up the ADSP information of the domain(s) specified by
   the Author Address(es) as described in Section 4.3.  If a message has
   multiple Author Addresses the ADSP lookups SHOULD be performed
   independently on each address.  This document does not address the
   process a host might use to combine the lookup results.

I'd like to see some security analysis of why this is OK. Naively,
it seems like one might be able to get around ADSP using this feature.
I.e., I want to forge a message apparently from example.com, which
has "dkim-all". I generate a message with "From: [email-masked], [email-masked]"
where I control example.org. I then serve a record for example.org 
indicating that I don't sign. If this is accepted, that seems 
potentially problematic.

S 4.3.
   Check Domain Scope:   An ADSP checker implementation MUST determine
      whether a given Author Domain is within scope for ADSP.  Given the
      background in Section 3.1 the checker MUST decide which degree of
      approximation is acceptable.  The checker MUST return an
      appropriate error result for Author Domains that are outside the
      scope of ADSP.

I don't really undersand how the second (and maybe third) MUSTs are
operationalizable. How would I not "decide"? I mean, I could
just ignore the issue and do exact match. Would that constitute
"deciding"? What would not "deciding"?

S 6.2.
   An attacker might attack the DNS infrastructure in an attempt to
   impersonate ADSP records to influence a receiver's decision on how it
   will handle mail.  However, such an attacker is more likely to attack
   at a higher level, e.g., redirecting A or MX record lookups in order
   to capture traffic that was legitimately intended for the target
   domain.  These DNS security issues are addressed by DNSSEC [RFC4033].

I don't understand why an attacker is more likely to redirect A or MX.
These are different attacks with different objectives. If I'm doing
phishing, then forgery seems more useful to the attacker.

In addition, to the extent to which the point of security
considerations is to give the reader an accurate picture of the
security of the system, I don't think this works that well, as due to
the very low deployment of DNSSEC, in practice these records are
easily forged.

EDITORIAL
S 2.7.

   For example, if a message has a Valid Signature, with the DKIM-
   Signature field containing "i=[email-masked]", then domain.example
   is asserting that it takes responsibility for the message.  If the
   message's From: field contains the address "[email-masked]" and an
   ADSP query produces a "dkim=all" or "dkim=discardable" result, that
   would mean that the message does not have a valid Author Signature.
   Even though the message is signed by the same domain, it fails to
   satisfy ADSP.

I think this example might benefit from a bit more explanation.
As I understand it, this signature is invalid per DKIM and so it needs
to be treated as unsigned, and that's where ADSP kicks in. But I
may have misunderstood, so some clarity here might help.

S 3.1.
   Note:   The results from DNS queries that are intended to validate a
      domain name unavoidably approximate the set of Author Domains that
      can appear in legitimate email.  For example, a DNS A record could
      belong to a device that does not even have an email
      implementation.  It is up to the checker to decide what degree of
      approximation is acceptable.

I don't really understand this graf. Can you rephrase?

-Ekr
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Jan 2009 13:49:55 -0800

At Fri, 02 Jan 2009 12:06:48 -0800,
> indicating that I don't sign. If this is accepted, that seems 

In retrospect, this isn't very clear.

In the case where there is one author and no signature, it seems to me
that ADSP allows you to differentiate two cases:

(1) The domain does not do DKIM signing [or more precisely hasn't
    bothered to publish a policy.]
(2) The domain DKIM signs and this is a forgery [or an error or something.]

Obviously a message that falls into case (2) should be treated with
extreme skepticism (and presumably discarded if discardability is
set). By contrast, a message that falls into category (1) probably
would be treated with less skepticism.
 
Now, let's try to extend that question to a message with multiple
signers. Consider the following policy for combining the results: "If
any author lacks an ADSP record, act is af no ADSP record is
available." ISTM that this allows an attacker to generate a message
with a nominal author list that includes a domain that DKIM signs but
get it treated as if it were in case (1). To the extent to which such
messages get less skepticism, that seems undesirable. By contrast,
a policy which said "treat the most strict policy as applying to all
signers" would have a very different set of security properties.

Obviously, these questions interact a lot with what treatment messages
get which fall into various categories, something I appreciate that
DKIM has tried to be agnostic about in general. Unfortunately, I think 
this is somewhere where you need to consider some plausible treatments
and the effect of various policies in the face of the natural attacker
behaviors.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Jan 2009 17:08:26 -0800

At Fri, 2 Jan 2009 19:22:25 -0500 (EST),
John R Levine wrote:
> ADSP is a very, very narow design, that attempts to deal with only a 
> single threat: exact forgery of an address on the From: line.  There's a 
> lot of other threats, arguably more important to address, but ADSP doesn't 
> deal with them.

OK.

> Since we don't have any real experience with signed mail with multi 
> address From: lines, any analysis would just be a guess, and not a very 
> well informed one at that, so we figured it was better not to.  Consider 
> these From: lines:
> 
> From: [email-masked], [email-masked] ; ADSP fail, pass
> 
> From: [email-masked], [email-masked] ; ADSP unknown, pass
> 
> From: [email-masked], [email-masked]; ADSP pass, unknown
> 
> The first and second cases are probably bad guys, but the third could be 
> someone you know and trust and his friend who you don't happen to know 
> yet.
> 
> We don't see any way to tell these apart without consulting external 
> reputation databases, which are way outside the scope of ADSP and DKIM.

OK, but I don't see how it helps to put the job of making this 
judgement on the implementor, who probably has less expertise
and time to think about this than the DKIM WG has, especially
as there is at least one policy that more or less obviates
ADSP (treat all addresses as having the weakest policy 
advertised by any of them). 

> Why phish if you can hijack the real traffic to the target?

Because the legitimate URL the user is dereferencing uses TLS?

> > As I understand it, this signature is invalid per DKIM
> 
> It's valid DKIM, but ADSP has additional semantics that are incompatible 
> with common auditing usage of the DKIM i= field.  The -09 draft will have 
> a note pointing this out with a workaround.  For an example of usage of 
> i=, see the DKIM signature on this message.
>
> Many people have pointed out that in practice you can trivially circumvent 
> ADSP by using lookalike domains, e.g. paypalsecurity.com or 
> www.paypal.com.  One way to address this would be to check to see if the 
> domain is in use at all for e-mail, since the number of domains in use for 
> mail is a tiny fraction of all of the names in the DNS.  Unfortunately, 
> due to the ancient SMTP rule that use an A record, and now also AAAA, for 
> fallback if a domain has no MX record, any name with an A or AAAA record 
> can potentially be used for mail.  There's a range of more or less 
> aggressive heuristics to see if a name with an A/AAAA record really is 
> used for mail (e.g., try to connect to port 25 and see if you get a hard 
> rejection), but there's no agreement on which if any an ADSP client should 
> use.

I would suggest that some explanation like this should go in the document.

-Ekr

---

From: John R Levine <[email-masked]>
Date: Fri, 2 Jan 2009 19:22:25 -0500 (EST)

> is a hot button for the DNS people.

ADSP records are in the same _domainkey subtree as DKIM TXT records, so 
they should be as OK.

> operationalizable. How would I not "decide"?

You're right, the second isn't really anything you can do.  The third says 
that if, e.g., the domain doesn't exist at all, it has to return an error.

Regards,
John Levine, [email-masked], Taughannock Networks, Cambridge UK
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: John L <[email-masked]>
Date: Fri, 2 Jan 2009 20:25:20 -0500 (EST)

> and time to think about this than the DKIM WG has

Honest, we thought about it and have no advice to give.  Different
mail users will have different tradeoffs between losing real mail and
accepting bogus mail, and we really have no experience at all with
signed mail with multi-address From: other than contrived examples.

> especially as there is at least one policy that more or less
> obviates ADSP (treat all addresses as having the weakest policy

That's certainly one policy you might use if your tradeoff avoids
losing real mail.

> Because the legitimate URL the user is dereferencing uses TLS?

True, although we were thinking of mail.  Again, lacking any experience
at all here we're just guessing.

> I would suggest that some explanation like this should go in the document.

My recollection is that there was less consensus than one might hope on
that particular explanation.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Fri, 02 Jan 2009 17:43:56 -0800 (PST)

> signed mail with multi-address From: other than contrived examples.

As a practical matter the issue of how multiple From: fields are handled has
become largely moot, in my experience at least. The mail client I use is one
that supports generation of this construct, but the last half-dozen times I've
tried it something has gone wrong every time - the receiving client mishandled
it, the message was blocked by overly aggressive filters, etc. etc.

After the last times, when a message to an IETF list was silently dropped and 
i was forced to ask one of the other recipients to resend it (having neglected
to keep a copy myself), I've given up on this construct, even though I find
it's semantics to be valuable.

As always, the plural of anecdote is not data, so there may be places I'm
unaware of where this construct is in use and doesn't cause any problems. But
given the mainstream nature of the various agents I've seen fail to handle
multivalued From: fields sensibly, my suspicion is there aren't very many such
places.

Now, I suppose an argument could be made that this points to the need for ADSP
to specify semantics for handling multivalued From: fields in order not to
break multivalued From: even more. But that argument only makes sense if we
believe that there's a single semantic we can assign that is broadly
applicable, and I don't think anyone believes that. And given a choice between
ADSP and not causing some additional breakage to a mostly broken minor
capability, I think the right choice is pretty clear.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 03 Jan 2009 12:02:40 -0800

[email-masked] wrote:
> unaware of where this construct is in use and doesn't cause any problems.
...
> Now, I suppose an argument could be made that this points to the need for
> ADSP to specify semantics for handling multivalued From: fields in order not
> to break multivalued From: even more. But that argument only makes sense if
> we believe that there's a single semantic we can assign that is broadly 
> applicable, and I don't think anyone believes that. 

This thread's taking place on the main IETF list, so it's probably worth noting 
some deeper issues that your observations raise:

1.  Should an adjunct protocol modify core semantics of the primary protocol, 
rather than add semantics to it?  If yes, when yes and when no?

     The issue, in this particular case, is a challenge between waiting to 
deprecate a feature in one protocol, versus potentially introducing 
interoperability instabilities by failing to support that feature -- that is, 
effectively deprecating it -- within a follow-on, adjunct protocol.

     Cavalierly modifying core semantics creates incompatible variants, and 
distributes their definition into unlikely places.

     Since the likely answer to these sort of experience-generated questions is 
usually "yes, but only sometimes", the real questions are when and how?

2.  If a protocol has a features that remain unexercised for a long time, when 
is it appropriate to deprecate it?  To make the exercise a bit more challenging, 
take note of situations in which the protocol is modeling well-established 
behavior from elsewhere in the world, but which nonetheless is not a behavior 
that has (yet) shown up in use of the protocol.

     RFC5322 models the world of memos.  Paper messages and other human 
communications can be, and sometimes are, "from" multiple authors.  That's not 
just theory; it's real-world practice.  If the Internet's email format drops 
that construct from the only place in the message that provides a structured 
designation of authorship, how are legitimate occurrences of multiple authors to 
be indicated?

     What we have here is a case of a protocol's supplying functional variety 
that models the real-world, but which has remained virtually unused for 30 
years.  One can easily argue that the deeper "problem" is that Internet Mail 
remains a limited functionality that will yet expand to fill the roles we know 
-- from the paper world -- are yet needed.  But even if we restrict the 
historical review to the start of the mass market Internet (1994) we are still 
looking at 15 years of not expanding into that available functionality.  Failure 
to use a feature for that long makes a strong case for deprecating it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir