On Mon, 23 May 2005, Ted Hardie wrote:
William,
The best route for you to send comments is directly
to the IESG; the reviewers act as a sounding board for us as
APPs ADs, but they have no independent role.
As suggested by Ted Hardie I'm sending you my comments regarding possible
incompatibilities and other problems in the MARID-related documents.
------------------------------------------------------------------------
I. Draft says that SID authorizes the message
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| 4. Decision Model
|
| Sender ID enables receiving e-mail systems to answer the question:
| Given an e-mail message, and given an IP address from which it has
| been (or will be) received, is the SMTP client at that IP address
| authorized to send that e-mail message?
The above statement is way too wide and is not valid in security terms.
SPF and SID do not tell if the client is authorized to send any kind of
email message. What they do is answer the question on if the client is
authorized to use given address in specific identity of the mail message,
i.e. pass result of SPF lookup on example.com would answer the question
on if SMTP client is authorized to use address within domain example.com
as MAIL FROM / bounce address in the email it is about to send.
For SID the question would be if client is authorized to use address as
part of PRA identity. There is however a wider problem because PRA
consists of multiple headers and so this identity is very ambiguous.
[Submitter address being one field identity does not have this problem]
None of those statements are the same as saying that somebody is authorized
to send email [any email] message on behalf of somebody else, that would
be a lot stronger and lot more general assertion.
II. Experimental Draft makes recommendations for entire Internet Email System
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| 7. Implementation Guidance
|
| This section describes the actions that certain members of the
| Internet e-mail ecosystem must take to be compliant with this
| specification.
This draft is going for experimental status. It is not appropriate for
it to make recommendations to internet community as a whole, only those
who wish to participate in experiment should be targeted. The entire
section (in fact SID authorization system in general) would require
those who are not participant of the experiment to comply and change
their behavior in order for those who participate to get positive results.
III. Draft makes recommendations to forwarders incompatible with RFC2822
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| 7.2 E-Mail Forwarders
|
| In order to pass the PRA variant of the test, a program that forwards
| received mail to other addresses MUST add an appropriate header that
| contains an e-mail address that it is authorized to use. Such
| programs SHOULD use the Resent-From header for this purpose.
The above is is incompatible with the section 3.6.6 of RFC2822:
Ref: http://www.ietf.org/rfc/rfc2822.txt
| Note: Reintroducing a message into the transport system and using
| resent fields is a different operation from "forwarding".
| "Forwarding" has two meanings: One sense of forwarding is that a mail
| reading program can be told by a user to forward a copy of a message
| to another person, making the forwarded message the body of the new
| message. A forwarded message in this sense does not appear to have
| come from the original sender, but is an entirely new message from
| the forwarder of the message. On the other hand, forwarding is also
| used to mean when a mail transport program gets a message and
| forwards it on to a different destination for final delivery. Resent
| header fields are not intended for use with either type of
| forwarding.
This objection was discussed at MARID and was found to be valid based on
the answer by Pete Resnick and in subsequent discussion in jabber conference.
Note: Same objection applies to section 7.3 of senderid-core document
IV. Draft uses Resent-* headers for automatic action which is incompatible
with RFC2822
Ref: http://www.ietf.org/rfc/rfc2822.txt (section 3.6.6):
| Resent fields are
| strictly informational. They MUST NOT be used in the normal
| processing of replies or other such automatic actions on messages.
I take "automatic action" to include rejection and bouncing of messages
and http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
recommends when PRA address derived from Resent- header is not authorized
base on corresponding SPF record check, then message is to be rejected
by mail system in automated manner.
V. PRA algorithm fails when message is RFC822 compliant but not RFC2822
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
| Where messages conform to RFC822 rather than RFC2822, it is possible
| for the algorithm to give unexpected results. An RFC822 message
| should not normally contain more than one set of resent headers;
| however the placement of those headers is not specified, nor are they
| required to be contiguous. It is hence possible that the Resent-From
| header will be selected even though a Resent-Sender header is present.
| Such cases are expected to be rare or non-existent in practice
The problem is acknowledged in the draft, however I'm uncertain that it
should be ignored quite so easily. Consider this also as one more reason
why use of Resent- headers as specified in this draft is bad idea in general.
VI. Zonecuts
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| If the PRA version of the test is being performed and no records
| remain, the requirement in [SPF] to find the Zone Cut and repeat the
| above steps is OPTIONAL.
Zonecut use has been removed fron spf draft because the use maybe dangerous
and lead to incorrectly targeted dns queries. It is still, however, present
in senderid-core-01 draft.
VII. Use of v=spf1 for SenderID PRA identity checking is not appropriate
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
| Sender ID implementations
| SHOULD interpret the version prefix "v=spf1" as equivalent to
| "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
The existing v=spf1 records have been published exclusively by those who
have participated in SPF experiment for checking of SMTP2821 MAIL FROM
identity (MFROM scope). The senderid-core-01 draft would make them
automatically participating in another experiment (that they may not
have agreed with) and subject to PRA test which may not lead to the
same results and may cause email rejection where otherwise there would
not have been.
VIII. SUBMITTER is required to be equal to PRA
Ref: http://www.ietf.org/internet-drafts/draft-katz-submitter-01.txt
| SMTP clients MUST set the SUBMITTER parameter value to the purported
| responsible address of the message as defined in [PRA]. This also
| applies to messages containing a null reverse-path.
While this is not a technical standard non-compliance objection, I do not
believe it is in the best interest of email community to require SUBMITTER
to have to be equal to PRA. Submitter has a value in itself as way to
identify during SMTP session address of the person responsible for email
transmission on the SMTP client network but I'm not certain the address
(which is hop-specific) must necessarily be included and indicated in
message headers. This is like EHLO name - we do not after-all have
message header field that corresponds to EHLO name and if somebody
proposed it, that would be considered pretty stupid idea (since its
so hop-specific) but we do have Received trace headers and those
headers record per-hop specific EHLO name. I believe something like
that is better for SUBMITTER because it shares similarities with
EHLO (the difference is that EHLO is server-name specific data where
as SUBMITTER is network-specific and does not have to correspond to
that specific server and maybe name or address of person associated
with that network responsible for transmission at that specific hop).
IX. SPF uses TXT too much
Ref: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
SPF system is relying too much on TXT records which are general records
not purposed for it (plus use of TXT records directly in the root of
domain tree is also likely to lead to collisions). While draft calls for
assignment of new SPF dns record type, I believe that not enough effort is
made in the draft text to explain to new users that once it becomes
EXPERIMENTAL RFC it would be its goal to move to using this new record
type as soon as possible. Some of what could be done is specific note
about this and that use of SPF record type is always preferable to use of
TXT as well as changing examples to use "SPF" instead of "TXT".
X. PRA and SID change semantics of Sender identity
I've done some research on this issue and came to the conclusion that
neither path authentication (like SPF) nor cryptographic mail signatures
(like DK) can work on their own to protect email system because of the
way current email architecture is setup [SPF fails with forwarding and
crypto fails with mail lists]. Either we need to change email architecture
(which cant be done quickly) or we'll need to use more then one authorization
system to compensate in case of failure of another and further research
showed that the only way more then one authorization system can work
without being exploited is if different authorization systems work
with same identity.
The most important identity to protect is From/Sender header (From
used if Sender is not present) as that is what is abused with phishing
and that is in fact claimed to be focus of SID as well, but instead of
protecting Sender, SID invents new identity which sometimes corresponds
to email sender and sometimes to recipient (remember that forwarders act
on behalf of recipient not on behalf of the email sender). This changing
and unpredictable nature of PRA makes it impossible to be used in
conjunction with other methods and wider use of PRA may in fact
undermine those efforts by changing nature of Sender identity.
Note, that I'm not against checking RFC2822 From/Sender header fields
with path authentication such as SPF - I think its great way to help
whitelist known good email, but it'll never on its own be good enough
to actually reject bad messages and the same is true about PRA except
that unlike doing strict Sender authorization, its results are less
predictable and in process the actual system violates RFC2822.
I'll publish web paper on this issue within next 15-30 days on ASRG for
those of you who follow that list, you might be interest that research.
XI. Some drafts use trademarked SenderID name
Ref: http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
http://www.ietf.org/internet-drafts/draft-katz-submitter-01.txt
Despite a clear not recommended warning about it from MARID WG chair at:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05042.html
the drafts by Microsoft still use "SenderID" name including as name of the
draft itself and I have yet heard nothing to indicate that permission has
been granted to IETF from trademark owner to use SenderID name in its
documents. So this may put IETF and ISOC if it approves these documents in
the dangerous situation and make them liable for damages as well as those
who may want to use the specification in some parts of the world.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net