Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

[Dave Crocker <[e-mail]>]

The paper concerns valid authentication and effective use of 
authenticated information.  That's an excellent goal.  The paper offers 
extensive technical analyses and empirical demonstrations of operational 
failures. Exercises like these are valuable and too infrequent.  Besides 
prompting specific repairs, work like this should motivate careful 
industry review of systems-level issues and standards-based documentation.

The paper does not adequately distinguish between claims of protocol 
design/specification errors, versus implementation errors, yet that 
distinction is essential.

The paper has a simplistic model of email anti-abuse processing and this 
distorts some of its analysis.  At the least, the paper needs to 
distinguish between theory and practice.

The paper has a flawed model of the role of recipient users in 
anti-abuse work and therefore the paper makes a basic error in its 
assessment of the importance of From: field validation.

The paper identifies a number of significant implementation deficiencies 
in various system.


Detailed comments:

> to authenticate the sender’s purported identity, as the basis for 
> displaying in email clients assurances of validity to userswhen they 
> read messages

That's a rather basic misunderstanding of how these mechanisms are 
actually used.


> In practice, attackers usually exploit SMTPby running their own email 
> servers or clients.

This is largely a non-sequitur.  It has built-in assumptions that aren't 
explained and are wrong with respect to any of the domain name-based 
protection mechanisms.  (And it isn't SMTP that is being exploited, per 
se. That's like saying that if I send a postal letter purporting to be 
the president of the United States, I've exploited the postal system. )


> SMTP’s design includes multiple “identities” when handling messages. 
Since this has been documented, they should cite it, for background.


> Both theMAIL FROMandFromheadersidentify the email sender, but they 
> have different meaningsin an SMTP conversation. The first represents 
> the user whotransmittedthe message, and is usually not displayed to 
> therecipient. 
It would be clearer and more helpful to say 'operator' or 'service 
provider' rather than 'user'.  A separate issue is whether their 
characterization of the differences between the two identifiers is valid 
in practice... The paper uses sender in a way that encourages confusion 
in the reader.  Especially since this is a technical paper, it should 
use language that carefully distinguishes roles, especially since 
terminology for making these distinctions is readily available.


> In addition, SMTP introduces multiple other sender identi-ties, such 
> as theHELOcommand,SenderandResent-Fromheaders.

I suspect that the failure to cite DKIM's d= field , until later, is a 
significant oversight.


> http://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt

heh.  the URL isn't valid.  Should be:

https://www.ietf.org/archive/id/draft-blank-ietf-bimi-00.txt<https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/>


> DKIM.DomainKeys Identified Mail (DKIM) uses cryp-tography to 
> authenticate senders...

I'm being too picky, right?  Formal DKIM semantics don't produce exactly 
that result.


> The general idea behind DKIM is to let senders sign parts ofmessages 
> so that receivers can validate them.
This is poorly written, wrong, or both.  'them' is ambiguous.  And the 
signing is to affix the d= value, not to validate any of the data that 
is part of the signature.


> it only need to have the same registered domain

Will typical readers understand what this means, in the context of this 
paper, since all of the domain name's components are 'registered'? It's 
not obvious what language would make the meaning clearer.


> If the email passes theDMARC verification, it enters the user’s inbox.

This is simply wrong.  It needs to place this phase of processing inside 
a complex filtering engine, which is the primary venue for using any of 
the mechanisms discussed in the paper.

> usually the MUA only displays theFromheader as the message sender.

These days, this isn't true either.  Most users only see the 
un-validated Display-Name.


> Thus, theFromheaderprovides the key identity relevant for gaining the 
> user’s trust

On its face, this seems a reasonable view.  In practice, it isn't.  Mail 
with obviously bogus email addresses in the rfc5322.From field are still 
effective for phishing, because what real users actually pay attention 
to is the body of the message and the identification information in it.  
That's why assertions about the display of validated source/author 
information to the end user are demonstrably wrong.


> Malicious usersof legitimate email providers exploit thefailure of 
> some email providers to perform sufficient valida-tion of emails 
> received from local MUAs. These attackers cansend emails with 
> spoofedFromheaders. The exploited emailproviders may automatically 
> attach DKIM signatures to theiroutgoing emails, enabling the attackers 
> to impersonate otherusers of the email provider

The writing of the paragraph's conclusion seems to be fundamentally 
misleading or wrong.  It seems to be saying that the DKIM signature will 
be for the domain in the From: field, which it won't.


> Security requirement.To achieve this goal,

I'm not sure exactly what goal they are referring to.


> (1) TheFromheader of the email thatSsends matches theauthenticated 
> username (other users ofScannot spoof Alice’saddress);


This requirement applies only in the presence of DMARC.


> (3) SPF/DKIM and DMARCcomponents inRconsistently authenticate the same 
> identifier


Except that SPF and DKIM are permitted to validate other identifiers, 
not just the one in the rfc5322.From field.


> This require-ment, although intuitive, implies a set of semantic 
> bindingrelations that every component in the email processing 
> chainmust respect.


This is imposing a requirement for deep, internal systems knowledge 
about features that are not, in fact, deeply embedded in email history 
or processing.  Arguably, the demand for having every component enforce 
this model is a basic mistake.

Rather the requirement is to prevent assumptions inside the system that 
serve to violate the policies needed at evaluation points.


 > robust principle

robustness

https://en.wikipedia.org/wiki/Robustness_principle


> be permissive in how they process malformed inputs


No, Postel did not direct accepting 'malformed' inputs.

And RFC 1122, Section 1.2.2 elaborated on this issue very helpfully:

> Software should be written to deal with every conceivable
> error, no matter how unlikely;


> 4.1 HELO/MAIL FROM confusion
This seems to imply that tightening is needed in DMARC, so that it uses 
an SPF domain that SPF has actually been validated? I think the issue is 
that SPF validation needs to inform DMARC what domain it has validated, 
rather than have DMARC decide which domain to fetch.


> SPF implementations treat “([e-mail]” as anempty MAIL FROM 
> address, and thus forward the resultsof checking HELO to the DMARC 
> component, because thestring in the parentheses can be parsed as a 
> comment ac-cording to RFC 5322 [10]. Some DMARC 
> implementations,however, may take it as a normal non-empty address,


1. This issues goes away if SPF supplies DMARC the domain name, rather 
than DMARC having to fetch it

2. I doubt this otherwise needs changes to language in the DMARC spec, 
but it's worth making sure.


> 4.3 Authentication results injection


Another focus on what results are communicated and how.

The paper asserts that AR is used as DMARC input.  I suspect that is 
rarely, if ever, true.  Yes? No?


> Generally, we can divideFromheader-relatedprocessing into two phases: 
> 1) parsing a MIME message to extract the Fromheader; 


The rfc5322.From: field is independent of MIME. MIME pertains only to 
the body.


> Microsoft:disregarded our report (which included our pa-per and a 
> video5demoing theA10attack) because the threatsrely on social 
> engineering, which they view as outside thescope of security 
> vulnerabilities.


That's oddly impressive.


> Improving MUA display
...

> We note however that experiences with suchapproaches for promoting 
> HTTPS (via browsers displayingtrusted icons for websites with valid 
> TLS certificates) havedemonstrated the challenges of ensuring that 
> users correctlyinterpret the icons and do not get fooled by imposters


"Challenges" is incorrect.  "Failure to be useful" is more appropriate 
language.















-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net