Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jan 10, 2009, at 12:31 AM, SM wrote:

At 15:44 09-01-2009, Douglas Otis wrote:
[...]
This leaves the issue of authentication itself clearly in the rough.
Section 1.5.2 of the draft explains why Sender-ID and SFP is  
supported by this header field.  In a nutshell, it's about using a  
single header field instead of creating separate header fields for  
each mechanism.  According to the IESG Note in RFC 4406, Sender-ID  
participants should consider the advice given in Section 3.4 of that  
RFC to avoid the interoperability problem you mentioned.
Many considered the IESG note to offer poor advice and it was limited  
to whether a message is accepted.  RFC 4406 recommends ignoring the  
stated scope of RFC 4408 records, and to add records explicitly  
supporting RFC 4406 which may produce negative results.  This was  
intended to overcome RFC 4406's scope modifications.  As such, a  
conflict between RFC 4408 and RFC 4406 remains.
The IESG warning, whether heeded or not, does not correct the issue  
regarding annotations that depend upon the kucherawy-sender-auth- 
header draft.  This draft describes Sender-ID or SPF as Authentication- 
Results "authenticating" a domain, while omitting the IP address of  
the SMTP client.  This prevents compliance with section 4.1 reputation  
check of an authenticated message origination that is needed to  
mitigate highly disruptive and injurious situations.
It's nearly two years since these two specifications have been published. If you believe that these two experiments are a failure, then post your observations so that a decision can be taken. In my opinion, this would be through a Sender-ID and SPF discussion and not one about this header field.
A concern remains about the label applied in the message by the  
kucherawy-sender-auth-header draft,  and its omission of critical  
origination information.  In one place the draft admits Sender-ID is  
_not_ about authentication, but then describes Sender-ID and SPF as  
authenticating.  The draft assumes the domain represents the  
origination of the message, rather than the IP address of the SMTP  
client.  At least the IP address has been weakly authenticated by TCP  
interaction, which is not true for the domain.
In addition, there is also the matter of encouraging the use of dangerous local-part macros when one wishes to obtain email-address annotations. []
Section 2.4.3 of the draft covers SPF and Sender-ID Results.  I  
don't see any encouragement for the use of local-part macros in there.
Section 2.4.3.  SPF and Sender-ID Results
...
,---
If the retrieved sender policies used to evaluate [SPF] and [SENDERID] do not contain explicit provisions for authenticating the local-part (see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with results for these mechanisms SHOULD NOT include the local- part.
'---

Placement within the authentication header has been made dependent upon an undefined and unsupported notion as to whether a local-part had been used to obtain authorization. (Assuming this is what the draft meant when incorrectly using the word authenticating.) Current record parsing libraries do not support qualifications made by Section 2.4.3. Since local-part macros are almost never used, and can be dangerous when allowed, the draft should not institute this dubious feature, and should preclude inclusion of the local-part instead.
The remedy being sought is to replace the local-part of the "authorizing" email-address with a converted string representing the IP address of the SMTP client that is being authorized. This allows the authenticated origin of a message to be vetted, in addition to what _might_ be an authorizing domain. A fair compromise.
Are there any implementations of the technique you are suggesting?   
The feedback received from other implementors showed that they  
neither use the above technique nor do they support your point of  
view.
Are you recommending coercion to resolve conflicts?  Not all SMTP  
clients restrict the use the PRA, and yet some inbound provider can  
apply Sender-ID checks against a PRA that authorized the SMTP client  
with a version 1 SPF record.  When a fraudulent PRA headers appear to  
have been from a domain publishing RFC 4408 records, should all  
messages that then appear to be from this domain be blocked until they  
publish RFC 4406 records?  How else is this problem to be handled?
Not everyone believes they MUST, or even SHOULD, publish RFC 4406  
records when publishing RFC 4408 records.  It is not common for an MTA  
to restrict the use of a PRA, although the SMTP client must be trusted  
to protect the PRA.  By including the IP address of the SMTP client, a  
reputation check of the SMTP client allows its Sender-ID "pass"  
results to be ignored when it fails to protect the PRA. This could  
avoid the need to block an entire domain publishing just version 1 RFC  
4408 records.   Why preclude an important option, and a necessary  
check as stated in section 4.1?  There has never been any reasonable  
justification for omitting the IP address of the SMTP client.  This IP  
address must be passed to the SPF record evaluation process!
[...]
Getting back to draft-otis-auth-header-sec-issues-00, Section 1 of the document encourages blocking the SMTP client IP address instead of blocking all mail from a domain. This can lead to more than one domain being blocked when there are several domains hosted on the same IP address.
It might be that Sender-ID pass results needs to be ignored whenever  
it has been determined that the SMTP client fails to protect PRAs.  In  
addition, when access to the SMTP client has been compromised, often  
other servers continue to operate.  When the kucherawy-sender-auth- 
header draft enables confidence artist's an easy exploit with  
unrestricted PRAs, there will be a need to report support of Sender-ID  
by SMTP client.
In discussions on the mail-vet discuss mailing list, some of your comments could, maybe erroneously, be interpreted as saying that the proposed header field is a barrage of marketing efforts for Sender- ID and SPF even though the proposal for the header field was spurred during the Domainkeys and DKIM work. The proposed header field was discussed at IETF 70 during the DKIM Working Group session [1]. If there was any push to satisfy those that represent special interests, I am not aware of it.
This draft adopted the erroneous, overstated, and misleading  
terminology used by those marketing email path registration.   
Importantly, the recommended remedy allows annotating a message to  
remain complaint with section 4.1 which states the reputation of the  
_authenticated_ origin of the message be checked first.  Once again,  
only the IP address of the SMTP client will have been (weakly)  
authenticated by way of the TCP exchange.  If the IP address is in  
doubt, so is any authorization of that address.
Most domain checks occur when visiting a web page.  From there, use of  
folder placement utilities can eliminate much of the need for domain  
reputation checks to guard against look-alike exploits.  By including  
both the domain and the IP address of the SMTP client in the  
authentication-results, the annotation application can decide whether  
folder placement removes a need to check the domain reputation, but it  
should always check the reputation of the SMTP client.
As for your concerns about the IESG (I gather that you meant IESG and not IETF) stewardship role, I'll point to the fact that the IESG did not rubber stamp the specification for the proposed header during their evaluation. The record shows that they raised several questions about it.
Being an idealist hoping that both IESG and the IETF do not knowingly  
accept negligently misleading drafts that enable confidence artists  
exploits, DDoS attacks, or that have a potential to be highly  
disruptive, it would be both. :^)
-Doug





_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]