Re: Comments requested on recent appeal to the IESG

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

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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