A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Message Header for Indicating Sender Authentication
Status
Author(s) : M. Kucherawy
Filename : draft-kucherawy-sender-auth-header-02.txt
Pages : 15
Date : 2005-5-5
This memo defines a new message header for use with [MAIL] messages
to indicate the results of sender authentication efforts to mail user
agents (MUAs) in order to equip them to relay that information in a
convenient way to users.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-02.txt
Review of draft-kucherawy-sender-auth-header-02 by B. Lilly
Internet-Drafts and RFCs are required to meet certain criteria: [R1.ID],
[R2.Instruct]. These can be checked by using the "idnits" tool:
[R3.idnits]. That tool noted the following regarding the document:
idnits 1.71 (02 May 2005)
draft-kucherawy-sender-auth-header-02.txt:
Checking nits according to http://www.ietf.org/ID-Checklist.html :
* The document seems to lack separate sections for Informative/Normative
References.
Checking conformance with RFC 3978/3979 boilerplate...
* The document claims conformance with section 10 of RFC 2026, but uses
some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC
2026, you should not claim conformance with it if you have changed to using
RFC 3978/3979 boilerplate.
* The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching beginning.
Boilerplate error?
* The document seems to lack an RFC 3978 Section 5.4 Copyright Line --
however, there's a paragraph with a matching beginning. Boilerplate error?
* The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78.
* The document seems to lack an RFC 3978 Section 5.5 Disclaimer --
however, there's a paragraph with a matching beginning. Boilerplate error?
* The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure
Acknowledgement.
* The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
Acknowledgement.
* The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure
Invitation.
(The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of
drafts without verbatim RFC 3978 boilerplate is not accepted.)
Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :
* The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching beginning.
Boilerplate error?
- It seems as if not all pages are separated by form feeds - found 0 form
feeds but 15 pages
Miscellaneous warnings:
- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation
clause.
Run idnits with the --verbose option for more detailed information.
The document contains:
[ ] MIB
[X] ABNF [R4.RFC2234]
[ ] Internet message (or fragment)
Verification tools are available at [R5.verify] and/or [R6.mparse].
Verification tools yielded the following results:
Bill's ABNF Parser
Errors during parsing:
Errors are noted by line number and column,
e.g. line:column: Something bad.
20:0: error: Empty rule
22:0: error: Empty rule
Clearly, the "ABNF" is badly broken.
The formatting of the document is atrocious. See [R7.formatting] and
[R8.formatting]
The (intended) status of the document is:
[X] Not indicated
[ ] Experimental
[ ] Informational
[ ] Proposed Standard
[ ] Draft Standard
[ ] Internet Standard
[ ] Best Current Practice
However, the status as defined in BCP 9 should be:
[ ] Experimental (typically denotes a specification that is part of
some research or development effort, subject only to editorial
considerations and to verification that there has been adequate
coordination with the standards process)
[ ] Informational (published for the general information of the
Internet community, does not represent an Internet community
consensus or recommendation, subject only to editorial
considerations and to verification that there has been adequate
coordination with the standards process)
[ ] Proposed Standard (generally stable, has resolved known design
choices, is believed to be well-understood, has received
significant community review, appears to enjoy enough community
interest to be considered valuable, has no known technical
omissions)
[ ] Draft Standard (at least two independent and fully interoperable
implementations from different code bases have been developed,
sufficient successful operational experience has been obtained,
unused options and features have been removed, well-understood,
known to be quite stable both in its semantics and as a basis for
developing an implementation, must have been Proposed Standard
for at least six months)
[ ] Internet Standard (significant implementation and successful
operational experience has been obtained, characterized by a high
degree of technical maturity and by a generally held belief that
the specified protocol or service provides significant benefit to
the Internet community, must have been Draft Standard for at
least four months)
[ ] Historic (A specification that has been superseded by a more
recent specification or is for any other reason considered to be
obsolete, must have been Standards Track)
[ ] Best Current Practice (a way to standardize practices and the
results of community deliberations, subject to the same basic set
of procedures as standards track documents, the community's best
current thinking on a statement of principle or on what is
believed to be the best way to perform some operations or IETF
process function, common guidelines for policies and operations
which are generally different in scope and style from protocol
standards, not well suited to the phased roll-in nature of the
three stage standards track and instead generally only make sense
for full and immediate instantiation)
[X] None of the above.
The document suffers from the following serious defects:
[X] missing or inadequate IANA considerations
[X] missing or inadequate security considerations
[ ] missing or inadequate internationalization considerations
[X] incompatible with the Internet Architecture
[X] incompatible with one or more Internet Standards
[X] uses non-standard terminology which may lead to confusion,
misinterpretation, and loss of interoperability
[ ] not backwards compatible with widely deployed,
standards-conforming infrastructure
[ ] BCP 14 is referenced, but keywords are not used, or are used
inappropriately
In addition, the proposal is based on a lack of understanding or
misunderstanding of the following issues:
o While message delivery may be sequential, trust is not transitive.
Ignoring forgery for the moment, if A indicates authenticity to B,
and B trusts A, then it does not follow that C, who trusts B,
should also trust A. Trust needs to be end-to-end.
o Unencrypted, unsigned content is trivially forged.
o SMTP involves message transfer without prior arrangement, and may
traverse many transfer agents, as directed by MX DNS RRs.
Consequently, there might very well be no basis for authentication
for some part of a transfer (which is why trust must be
end-to-end):
o Due to DHCP and NAT, there might be no correspondence between a
domain name (SMTP HELO or ESMTP EHLO) and an IP address.
Indeed, there exist domain names which have no corresponding IP
addresses.
o The semantics of the [E]SMTP MAIL FROM command argument are of a
path for notification messages, which may legitimately be
unrelated, in whole or in part (e.g. domain), to the message
sender or message author.
o The message header address fields (From, To, Reply-To, Sender,
etc.) are unrelated to message transport, and are end-to-end,
user-to-user communication.
About the only portions of transfer that have some basis for
authentication are between parties which do have a prior
relationship, as between an originator's MUA and his ISP's MSA (if
the ISP operates a separate MSA on a port which is not blocked
between the MUA and MSA). Beyond such a hypothetical ISP's
borders (e.g. when a message is subsequently transferred to the MX
host corresponding to a recipient mailbox), such "authentication"
is of precisely zero value; there is (in general) no prior
arrangement between the hypothetical ISP's sending MTA and the MX
host receiving MTA, and any random sending MTA could connect to
the receiving MTA and present unsigned, unencrypted content
purporting to assert MUA-MSA auhentication.
o SMTP transfer does not alter content except for addition of
time-stamp fields (a.k.a. Received fields), and (at "final"
delivery) a Return-Path field. The proposal advocates slicing,
dicing, and modification of message header content in transit.
Please carefully review the references and resources indicated:
[X] [R1.ID]; Note in particular "The Internet-Draft should neither
state nor imply that it has any standards status", whereas the
draft uses "this standard" many times.
[X] [R2.Instruct]
[X] [R3.idnits]
[ ] [R4.RFC2234]
[ ] [R5.verify]
[ ] [R6.mparse]
[ ] [R7.formatting]
[ ] [R8.formatting]
[ ] [R9.FYI17]
[X] [R10.FYI18]; pay particular attention to the standard definition
of "header".
[ ] [R11.FYI36]
[X] [R12.STD10], [R13.STD10], [R14.STD10]
[X] [R15.STD11]; pay particular attention to the standard terms
"header" and "header field". Also note that comments cannot
appear between a field name and the colon which separates it from
the field body, as printable characters including parentheses may
be part of a field name. See also section 4.1 regarding (lack
of) significance of message header field order.
[ ] [R16.STD13], [R17.STD13]
[ ] [R18.STD17]
[ ] [R19.BCP9]
[ ] [R20.BCP14]
[ ] [R21.BCP18]
[X] [R22.BCP22]
[X] [R23.BCP26]
[ ] [R24.BCP32]
[ ] [R25.BCP41]
[ ] [R26.BCP44]
[ ] [R27.BCP56]
[X] [R28.BCP61]
[ ] [R29.BCP72]
[X] [R30.BCP82]
[X] [R31.BCP90]
[X] [R32.BCP95]
[ ] [R33.BCP97]
[ ] [R34.RFC1796]
[X] [R35.RFC1847]
[X] [R36.RFC1925] (5), (6), (8), (11)
[X] [R37.RFC1958]; particularly section 2.3.
[ ] [R38.RFC1982]
[X] [R39.RFC2015]
[X] [R40.RFC2223] paying particular attention to section 3a "Do not
do hyphenation of words at the right margin"
[X] [R41.RFC2231]
[X] [R42.RFC2821]
[X] [R43.RFC2822]; pay particular attention to the standard terms
"header" and "header field". Also note that comments cannot
appear between a field name and the colon which separates it from
the field body, as printable characters including parentheses may
be part of a field name. See also section 3.6 and Appendix B
regarding (lack of) significance of message header field order.
[ ] [R44.RFC3092]
[ ] [R45.RFC3117]
[X] [R46.RFC3156]
[ ] [R47.RFC3254]
[ ] [R48.RFC3426]
[ ] [R49.RFC3439]
[ ] [R50.RFC3444]
[X] [R51.RFC3467]
[ ] [R52.RFC3523]
[ ] [R53.RFC3536]
[ ] [R54.RFC3724]
[ ] [R55.RFC3929]
[ ] [R56.RFC3930]
[X] [R57.Errata]
[X] [R58.Fields]
The following applies to the document being reviewed:
[ ] The document seems promising, but needs work.
[X] The document needs substantial rework before serious review can
take place.
[ ] The document is a disaster. It should be withdrawn.
References:
[R1.ID] "Guidelines to Authors of Internet-Drafts", March
2005, ftp://ftp.ietf.org/ietf/1id-guidelines.txt
[R2.Instruct] Reynolds, J., and R. Braden, "Instructions to Request
for Comments (RFC) Authors", Work in progress (August
2004).
[R3.idnits] http://ietf.levkowetz.com/tools/idnits/
[R4.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[R5.verify] TOOLS, "Available Verification Tools",
http://tools.ietf.org/verif-tools
[R6.mparse] Internet Message Format validating parser,
http://users.erols.com/blilly/mparse/index.html
[R7.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",
http://www.rfc-editor.org/formatting.html
[R8.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
Comments using troff and nroff",
http://users.erols.com/blilly/formatting/draft-lilly-using-troff-04.html
[R9.FYI17] Harris, S., "The Tao of IETF - A Novice's Guide to
the Internet Engineering Task Force", RFC 3160,
August 2001.
[R10.FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983,
August 1996.
[R11.FYI36] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[R12.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[R13.STD10] Klensin, J., Freed, N., Rose, M., Stefferud, E., and
D. Crocker, "SMTP Service Extensions", STD 10,
RFC 1869, November 1995.
[R14.STD10] Partridge, C., "Mail routing and the domain system",
STD 10, RFC 974, January 1986.
[R15.STD11] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982.
[R16.STD13] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[R17.STD13] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[R18.STD17] McCloghrie, K. and M. Rose, "Management Information
Base for Network Management of TCP/IP-based
internets:MIB-II", STD 17, RFC 1213, March 1991.
[R19.BCP9] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[R20.BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[R21.BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[R22.BCP22] Scott, G., "Guide for Internet Standards Writers",
BCP 22, RFC 2360, June 1998.
[R23.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 2434, October 1998.
[R24.BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level
DNS Names", BCP 32, RFC 2606, June 1999.
[R25.BCP41] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[R26.BCP44] Moore, K. and N. Freed, "Use of HTTP State
Management", BCP 44, RFC 2964, October 2000.
[R27.BCP56] Moore, K., "On the use of HTTP as a Substrate",
BCP 56, RFC 3205, February 2002.
[R28.BCP61] Schiller, J., "Strong Security Requirements for
Internet Engineering Task Force Standard Protocols",
BCP 61, RFC 3365, August 2002.
[R29.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing
RFC Text on Security Considerations", BCP 72,
RFC 3552, July 2003.
[R30.BCP82] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692, January
2004.
[R31.BCP90] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header Fields",
BCP 90, RFC 3864, September 2004.
[R32.BCP95] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[R33.BCP97] Bush, R. and T. Narten, "Clarifying when Standards
Track Documents may Refer Normatively to Documents at
a Lower Level", BCP 97, RFC 3967, December 2004.
[R34.RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All
RFCs are Standards", RFC 1796, April 1995.
[R35.RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[R36.RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1996.
[R37.RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[R38.RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic",
RFC 1982, August 1996.
[R39.RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[R40.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.
[R41.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages,
and Continuations", RFC 2231, November 1997.
[R42.RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[R43.RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[R44.RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond,
"Etymology of "Foo"", RFC 3092, April 2001.
[R45.RFC3117] Rose, M., "On the Design of Application Protocols",
RFC 3117, November 2001.
[R46.RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[R47.RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002.
[R48.RFC3426] Floyd, S., "General Architectural and Policy
Considerations", RFC 3426, November 2002.
[R49.RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002.
[R50.RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference
between Information Models and Data Models",
RFC 3444, January 2003.
[R51.RFC3467] Klensin, J., "Role of the Domain Name System (DNS)",
RFC 3467, February 2003.
[R52.RFC3523] Polk, J., "Internet Emergency Preparedness (IEPREP)
Telephony Topology Terminology", RFC 3523, April
2003.
[R53.RFC3536] Hoffman, P., "Terminology Used in
Internationalization in the IETF", RFC 3536, May
2003.
[R54.RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the
Middle and the Future of End-to-End: Reflections on
the Evolution of the Internet Architecture",
RFC 3724, March 2004.
[R55.RFC3929] Hardie, T., "Alternative Decision Making Processes
for Consensus-Blocked Decisions in the IETF",
RFC 3929, October 2004.
[R56.RFC3930] Eastlake 3rd, D., "The Protocol versus Document
Points of View in Computer Protocols", RFC 3930,
October 2004.
[R57.Errata] RFC-Editor errata page,
http://www.rfc-editor.org/errata.html
[R58.Fields] Lilly, B., "Implementer-friendly Specification of
Message and MIME-Part Header Fields and Field
Components", work in progress, May 2005.