Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt

[Bruce Lilly <[e-mail]>]

> 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.