[APPS-REVIEW] secdir review of draft-kucherawy-sender-auth-header-20

[Barry Leiba <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These comments 
were written primarily for the benefit of the security area directors.  Document 
editors and WG chairs should treat these comments just like any other last call 
comments.

Specifically, I've been asked to review draft-kucherawy-sender-auth-header-20, 
after having reviewed the -18 revision, and to consider 
draft-otis-auth-header-sec-issues-00 in the review.  I'm also copying this review 
to the apps-review list, since it's relevant there.

I've looked at the diffs between the -18 and -20 versions, to make sure I didn't 
miss any changes, and I've reviewed the -20 version as a whole.  I've also looked 
at the comments and questions that have come up during IESG evaluation.

My evaluation of the document stands from the -18 version -- the -19 and -20 
revisions have made clarifications over -18, in response to other comments, and 
that's good.  But the document was basically sound then, and reflected rough 
consensus of the participants from the email-developer community, and still does.

Considering draft-otis-auth-header-sec-issues-00: Doug's main point appears to 
involve a disagreement with Murray's decision not to include the IP address, for 
SPF and Sender-ID cases (for simplicity, I'll just say "SPF" to refer to both in 
this review).  Murray instead includes only the domain that has been verified (or 
not) *using* the IP address.  His complaint is that the header field "fails to 
offer the authenticated entity being trusted in the exchange, the IP address of 
the SMTP client."  In other words, Doug considers that it's the IP address, not 
the ADMD, that has been "authenticated".

I disagree, but this is a tricky area, because we're not wading in a typical sort 
of authentication pool here -- SPF is actually blending identity, authentication, 
and authorization.  As I see it, the SPF model is that the *identity* to be 
authenticated is taken from the SMTP MAIL FROM command (for Sender-ID it's 
derived through the PRA algorithm), the IP address supplies the authentication 
*credentials*, and the DNS lookup both verifies the credentials (completing the 
authentication) and returns the authorization information in one, combined 
response ("the entity with these credentials is authorized to send mail on behalf 
of the identity 'example.com'.").

Of course, it's entirely reasonable to want the credentials to be preserved, 
since they're not secret.  I see nothing wrong with including the IP address, and 
I wonder why Murray has chosen not to.  That said, I agree with the approach that 
this field is meant to convey the *results* of application of an "authentication" 
algorithm, and not to give the MUA what it needs to re-run the authentication. 
I'll note that the same is true with the application of this to DKIM: the header 
field described here does not contain all the information provided to the DKIM 
validator.

So, while I see no harm in including the IP address, I have no problem with the 
decision not to.  I also note that it can be added as an extension, if there's 
demand for that from the MUA vendors.  There doesn't seem to be, at this point.

There's the issue of needing the IP address to properly assess reputation.  DNS 
black/white lists (see draft-irtf-asrg-dnsbl) use the IP address as a reputation 
key because it's what they have.  The whole *point* of SPF is to translate the IP 
address into a confirmed domain name, to have a more useful reputation key, and 
this header field supports that.  That said, there are result values that do not 
allow the use of the ADMD as a key to a reputation check: "none" and "neutral", 
for example, explicitly refuse to tie the IP address to the domain name.  In such 
cases it might be useful to have the IP address available for fall-back 
reputation checks.

On the other hand, it's likely that the mail system will have done other checks 
at the domain boundary besides just SPF.  Putting the responsibility for 
IP-address-based checks in the MUA is probably unwise anyway.

Doug also worries about the use of the "local part" in SPF cases.  I know that 
Doug is bothered by the local-part stuff in general, and I agree with some of his 
concerns.  I think, though, that those concerns aren't relevant to this document 
-- the document, again, is reflecting the *results* of the SPF check, which may 
or may not involve the local part.  This document is not *adding* anything in 
that regard.

Finally, Doug appears to dislike the use of the word "authentication" here, and I 
agree with him.  As I said above, SPF (for example) isn't *really* an 
authentication system, and it's unfortunate that we've fallen into using that 
term for it.  But the fact is that we *have* fallen into it, and I think there'd 
be more damage done by trying to use a different term than there is by using the 
term that's come to be accepted, and to acknowledge that it's not strictly 
correct.

So, here's the bottom line:
1. I think draft-kucherawy-sender-auth-header-20 is ready to go as it is.
2. I'd like it if we weren't calling all this "authentication", but I don't see 
any way around it and I recommend that it NOT be changed.
3. I wouldn't object to the inclusion of the IP address in the header field for 
SPF and Sender-ID cases, but I don't think it's necessary and support the 
decision not to include it.

Barry

--
Barry Leiba, Senior Technical Staff  ([e-mail])
Internet Messaging Technology, IBM Research
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam


_______________________________________________
APPS-REVIEW mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-review