Subject: 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
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

> its signing policy, thus allowing recipients to distinguish these

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.

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

> it seems like one might be able to get around ADSP using this feature.

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.

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

> phishing, then forgery seems more useful to the attacker.

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

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

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

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.

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

---

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

At Fri, 2 Jan 2009 19:22:25 -0500 (EST),
> lot of other threats, arguably more important to address, but ADSP doesn't 

OK.

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

> rejection), but there's no agreement on which if any an ADSP client should 

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

-Ekr

---

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: [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
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bill McQuillan <[email-masked]>
Date: Sat, 3 Jan 2009 12:37:54 -0800

> designation of authorship, how are legitimate occurrences of multiple authors to

Perhaps someone knows what the "Founders" (of email) conceptual models were
for a "message" (memo?) For instance, although I obviously do not understand
the "original intent" behind the "group of mailboxes" construct, I have long
wondered why the following is not valid:

   From: ACME Chief Officers:
           Alice <[email-masked]>,
           Bob <[email-masked]>;

There must have been *some* concept of email that dictated that a message
could be sent *to* a group but not *from* one!

-- 
Bill McQuillan <[email-masked]>

---

From: SM <[email-masked]>
Date: Sat, 03 Jan 2009 13:49:54 -0800

At 12:02 03-01-2009, Dave CROCKER wrote:
>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 adjunct protocol shouldn't modify core semantics if it is built 
upon the primary protocol.

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

Yes.

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

There is a difference between features that remain unexercised and 
features that are obsolete.  If we want to depreciate a feature 
during a protocol update, we make a case for it.

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

If we are going to use that line of argument, we would depreciate a 
lot of features which seem unused because well-known mail clients do 
not implement them.  I don't see a strong case as there are some mail 
clients that implement the feature.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 04 Jan 2009 08:07:28 -0800

> wondered why the following is not valid:

Internet mail grew out of the standalone mail system that was running on BBN's 
Tenex system, which had a message appearance similar to what we see today.  I 
haven't talked with the folks who created the Tenex system, to ask about their 
particular choice.  However I suggested an interpretation of it's perspective in 
RFC 733, which formally codified the model:

>      A general "memo" framework is  used. 
...
>      Such a  framework  severely  constrains  document  tone  and
> appearance  and  is  primarily useful for most intra-organization
> communications  and  relatively   structured   inter-organization
> communication.   A more robust environment might allow for multi-
> font, multi-color, multi-dimension encoding  of  information.   A
> less  robust  environment,  as  is present in most single-machine
> message systems, would more severely constrain the ability to add
> fields  and the decision to include specific fields.  In contrast
> to paper-based communication, it is interesting to note that  the
> RECEIVER  of  a  message  can exercise an extraordinary amount of
> control over the message's  appearance.   

The incremental revisions to the model that were done in RFC 733, RFC 822, RFC 
2822 and RFC 5322 have tweaked things, such as with the group construct you cite 
and, of course, with multi-media attachments (MIME).  These enable a broader 
range of uses. So I'm not sure the 'founders' intent is all that informative or 
constraining, 35 years on. I think it is more helpful to note the disparity 
between what styles of communication email *can* support and what kinds it 
*does* support.

Specifically, the point of my message was to note that IMF (Internet Message 
Format) is used for only a subset of the functions it could be used for and that 
(probably) it could support with no change and that. In fact, it has features 
intended to support those additional functions but which remain almost 
completely unexercised after all this time.

What prompted my note was the observation that having stray bits of unexercised 
protocol features hanging around invites divergent implementations, as follow-on 
enhancements are made. The current situation with ADSP is merely a concrete example.

By "divergent" I mean "non-interoperable".  So as logically compelling as the 
potential for those unused bits of capability are, the fact that they remain 
unused is demonstrably problematic, which leads to the questions of possibly 
deprecating them, and how to do it.

> could be sent *to* a group but not *from* one!

I don't remember whether this idea came up during discussions for RFC 733. I 
don't think so, although it certainly seems to me to be as reasonable to be able 
to apply the construct to the author field as to a recipient field. But since 
the construct so infrequently used, I'm not sure it's all that helpful to 
explore this "enhancement"...

d/
-- 

   Dave Crocker

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 4 Jan 2009 08:57:07 -0800

> explore this "enhancement"...

Well, this prompted me to go searching the RFCs, and I found out that the
"From: group: ... ;" construct WAS allowed in RFCs 724 and 733 but was
removed in 822. There are examples showing exactly this construct in the
earlier RFCs (724: II.D.i and 733: V.C.9), but the corresponding example
has been changed in 822 (A.2.7) and a note added specifically saying:

                                                    Note that the name
        of the committee cannot be specified, since <group> names  are
        not permitted in the From field.

I'd love to see the discussion that brought about that change.  :-)

Anyway, this tangent has probably run it's course, so I'll drop it on this
list.