Subject: [ietf-dkim] ADSP and From header authentication?

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Oct 2008 17:52:56 -0700

http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-16.txt

The sender-auth draft provides a mechanism for use when ADSP records  
are discovered, the From header field can be captured within an  
Authentication-Results header.  The purpose of the Authentication- 
Results header is to convey to MUAs the results of various message  
"authentication" checks.  Because the Author-Signature definition  
limits what is allowed within a compliant DKIM signature, neither  
ADSP, Sender-ID, or SPF can properly be described as providing an  
authentication of the From header field, PRA, or the MAILFROM email- 
address respectively.  The Author-Signature definition prevents a  
complaint signature  "on-behalf-of" value from indicating a From  
header field has not been authenticated.

In addition, the path registration process of Sender-ID and SPF only  
authorize an SMTP client.  An authorized SMTP client will not safely  
convey an assurance that the corresponding email-address was  
authenticated to represent the author or even being a valid use of the  
email-address.  Often thousands of email-domains share a common  
outbound server that might have only 8 IP addresses.  Clearly, an IP  
address is not assured to relate to any specific email-address.

S/MIME and OpenPGP provide a means to authenticate an email-address.   
At this time, due to the Author-Signature definition, DKIM-ADSP does  
not.  DKIM without ADSP could offer an assurance that an email-address  
was authenticated, since the signature is free to indicate what the  
signing domain actually authenticates.  What the signing domain  
authenticates often differs from that of an email-address contained  
within the From or Sender header field.  The authentication-header  
draft overstates to a dangerous degree what these mechanisms  
accomplish by using the term authentication.  Fixing the ADSP Author- 
Signature definition would help eliminate the assumption of  
"authenticated" with respect to DKIM-ADSP.

-Doug

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 23 Oct 2008 09:59:08 +0100

> "authenticated" with respect to DKIM-ADSP.

Indeed so. However, it is perfectly possible to construct a DKIM signature
that does _not_ include the From header. It would violate a MUST in the
definition of DKIM, but you cannot stop signers from doing it or verifiers
  from accepting it if they are so constructed. I suspect that intermediate
signers are just going to do this, RFC or no RFC.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Oct 2008 12:17:57 -0700

> header field has not been authenticated.

I'm afraid I'm missing how the definition of Author-Signature, which is 
a property of the ADSP specification, alters what SPF or Sender-ID can 
claim.

> email-address.

A consumer of the data presented in this header field would be expected 
to understand what an SPF "pass" or Sender-ID "pass" actually implies 
before acting on it.  There's text covering that in the draft already as 
well, in the "Header Position and Interpretation" section.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Oct 2008 16:44:33 -0700

On Oct 23, 2008, at 12:17 PM, Murray S. Kucherawy wrote:

> Douglas Otis wrote:
>> The sender-auth draft provides a mechanism for use when ADSP  
>> records  are discovered, the From header field can be captured  
>> within an  Authentication-Results header.  The purpose of the  
>> Authentication- Results header is to convey to MUAs the results of  
>> various message  "authentication" checks.  Because the Author- 
>> Signature definition  limits what is allowed within a compliant  
>> DKIM signature, neither  ADSP, Sender-ID, or SPF can properly be  
>> described as providing an  authentication of the From header field,  
>> PRA, or the MAILFROM email- address respectively.  The Author- 
>> Signature definition prevents a  complaint signature  "on-behalf- 
>> of" value from indicating a From  header field has not been  
>> authenticated.
>
> I'm afraid I'm missing how the definition of Author-Signature, which  
> is a property of the ADSP specification, alters what SPF or Sender- 
> ID can claim.

This draft incorrectly describes methods as offering  
"authentication".  Unfortunately, this mischaracterization also  
includes DKIM-ADSP because of the broken Author-Signature definition.

>> In addition, the path registration process of Sender-ID and SPF  
>> only  authorize an SMTP client.  An authorized SMTP client will not  
>> safely  convey an assurance that the corresponding email-address  
>> was  authenticated to represent the author or even being a valid  
>> use of the  email-address.
>
> A consumer of the data presented in this header field would be  
> expected to understand what an SPF "pass" or Sender-ID "pass"  
> actually implies before acting on it.  There's text covering that in  
> the draft already as well, in the "Header Position and  
> Interpretation" section.

A security mechanism should not recklessly abuse the term  
Authentication.  The term Authentication is _dangerously_ misleading  
for most methods logged by this header.  The term "Authentication"  
should be replaced by a neutral term "method" within draft where  
possible.  It would not be too misleading to use the terms  
"Authentication or Authorization" instead of just "Authentication"  
within a few sentences.   A header label "Source-Results"  would be  
less deceptive in respect to the nature of the results obtained.  The  
term Authentication is being misused more than 60 times through out  
this draft (ignoring the title and header labels).  Admittedly the  
word "authorized" is buried in the definition of some results,  but  
this term will _never_ be evident to the user.  Do you see the danger  
using the header label "Authentication-Results:"?  The draft's  
introductory statement does not help much either:

"At the time of publication of this draft, [AUTH], [DKIM],  
[DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail  
authentication methods in common use."

Authentication methods?  Really?

It is _dangerous_ and _misleading_ to suggest that an SMTP client  
_authorization_ method results in the "authentication" of the PRA,  
MAILFROM, the valid origination of the message as stated in this  
draft.  An _unauthorized_ SMTP client MAY be an indication of the  
invalid use of a MAILFROM or PRA,  however an authorized SMTP client  
must not be assumed to indicate the valid use of an email-address, as  
suggested by the overused term "Authentication" through out this  
draft.  Describing an authorization method as being an authentication  
method results in a dangerous misrepresentation of the results  
produced for most of the methods currently defined methods, even for  
DKIM-ADSP at this time.

Get rid of the sales hype describing everything as "authentication".   
Security is no time for muddled or misused terminology.  There is no  
reason to mislead recipient any more than they already are.

-Doug