At 10:57 20-02-2009, Murray S. Kucherawy wrote:
All of the issues Mr. Otis raises have been given substantially more than a
normal amount of consideration, yet they have failed to attract any detectable
consensus. Disagreement with both his concerns and his proposed remedies is
ample and well-documented.
As a participant to the discussions that lead to
draft-kucherawy-sender-auth-header-20, I can confirm that the issues
raised by Mr Otis were discussed on the mailing list - see
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000390.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000398.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000409.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000504.html
http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000507.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000549.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000550.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000552.html
http://mipassoc.org/pipermail/mail-vet-discuss/2009q1/000558.html
During the IESG evaluation, a secdir review of
draft-otis-auth-sender-sec-issues-00, which raises alleged security
issues was requested.
The appeal mentions that:
'In the case of Sender-ID or SPF, the deceptive nature of this header
could have been remedied by including the "authenticated" IP address
of the SMTP client, in addition to the authorizing domain.'
That is at odds with the second paragraph of the appeal where the
authors of the appeal point to the downside in the era of carrier
grade NATs, virtual servers, aggregated services, and other
techniques that overload the IP address.
The appeal states that the its goal is to ensure adequate information
is available when annotating email. The last paragraph mentions that
an MTA adding this header field SHOULD NOT include any data which has
not been authenticated by the method(s) being applied. It then
proposes an exception for an Authorizing domain only when it
accompanies the authenticated IP address of the SMTP client.
Assigning a negative rating to an affected SMTP client IP addresses
mitigates the security breach problem while completely blocking all
messages from the domain and other domains hosted in a virtual server
environment. Furthermore, basing MUA annotations on the rating of an
IP address is questionable as messages are not always retrieved
immediately after delivery.
The appeal gets into a discussion about IPv6, SPF macros, and
local-parts. draft-kucherawy-sender-auth-header-20 defines a header
to capture email verification results. It is not about the internals of SPF.
There is a recommended modification that the "pvalue" reported along
with results for these mechanisms SHOULD NOT include the local-part.
Quoting the draft under appeal, the value:
For Sender ID: value of header field used by PRA after removing comments
and parts not authenticated
For SPF: envelope sender after removing parts not authenticated
That cannot be interpreted as the local-part should be included.
As for the confusion about authorization with authentication in
section 1.5.2 of draft-kucherawy-sender-auth-header-20, there is a
reference to BCP 72 and it quotes Section 4.4 which describes
authorization and authentication. Authentication simply identifies a
party, authorization defines whether they can perform a certain
action. Authorization necessarily relies on authentication, but
authentication alone does not imply authorization.
draft-kucherawy-sender-auth-header-20 describes SPF and Sender ID as
authorization mechanisms in that they express a result that shows
whether or not the ADMD that apparently sent the message has
explicitly authorized the connecting SMTP client to relay messages on
its behalf but do not actually validate any property of the message
itself. The author of the draft mentions that rather than create a
separate header field for each class of solution, this proposal
groups them both into a single header field.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf