|
Re: [mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header
2009-01-12 21:54:02
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|