Greetings.
This note offers comments on the appeal, draft-otis-auth-header-appeal-00, which
has been lodged against standardization of
draft-kucherawy-sender-auth-header-20.
This appeal lacks merit on basic points.
As a technical criticism, the appeal is confused and lacks substance. The
conclusions appear to be based on fundamentally mis-reading of basic technical
details of the specification. At best, the appeal makes the mistake of wanting
to kill the messenger, rather than the message's author. That is, the appeal's
authors appear to have concerns with certain types of report content, rather
than with the mechanism of doing reporting. Yet auth-res is merely the
mechanism, a common conduit for reporting a class of related information.
Indeed, the appeal is dominated by criticisms of SPF and Sender-ID. The appeal's
authors should express their concerns with those communities of interest, rather
than with a mechanism that merely carries information that is generated by other
mechanisms.
As a statement of preference, the appeal lacks support. Contrary to the appeal
authors' perspective, the bulk of the email reporting operations community find
this mechanism helpful, in its current form. Whatever possible downsides the
appeal's authors envision, it has not yet come to pass, over a long period of
use.
Detailed comments follow:
Authentication-Results Header Field Appeal
For such use, it is crucial to include within an "authenticated-results"
header, a truly authenticated identity.
Auth-res is specified as operating within a trust domain. It explicitly
asserts the need for trusting the source of the report and the path from the
report generator to the report consumer. As such, there is no obvious basis for
claiming that further authentication of the report is needed.
To the extent that one might construct that need, it can (and should) be a
separate mechanism from the report definition, much as SMTP Auth or Open PGP are
separate from the defintion of IMF (RFC5322).
The draft acknowledges that it confuses authorization with authentication in
section 1.5.2.
No it does not. There is no language in 1.5.2 that describes or acknowledges any
confusion. The only relevant text in that section is "this proposal groups them
both into a single header field".
Consequently it appears that the real confusion is with the authors of the
appeal, who confuse an explicit decision to allow two types of information to
cohabit, with inability to distinguish between the two types of information.
This confusion has lead the draft to incorrectly elevate the authorization of
an SMTP client into the authentication of an email-address domain.
This language implies (or states directly) that the subject specification is
performing authorization and/or authentications functions. The spec does
nothing of the sort. It conveys information, about functions performed by
supplying mechanisms. It's only active function, beyond that, is to map some
information into canonical form. If the appeal's authors are claiming that this
mapping function somehow turns authorization information into authentication
information, they need to supply the particulars.
More likely, the appeal's authors need to distinguish report conveyance from
report generation. They need to pursue their concerns about particular message
security analysis functions with the folks responsible for particular functions,
whether path registration based, message authentication crypto-based or whatever
particular services they are actually unhappy with.
More generally, they seemed believe that the specification's ability to carry
data on behalf of multiple types of security functions means that information
from the different functions gets mashed together and becomes indistinguishable.
This is the only way I can guess why they think that an SMTP Client
authorization function can be confused with an "email address domain" -- but,
then, I have to guess what they mean by email address domain. Perhaps they mean
the rfc5322.From field address, but perhaps they mean the rfc5321.mailfrom, or
some other address associated with a message. Again, they provide no specifics
about either of these functions.
Elevating the *authorization* of the SMTP client into the *authentication* of
an email-address domain incorrectly assumes current email practices
adequately restrict the use of an email-address domain based upon the
originating IP address of the SMTP client. In an era of carrier grade NATs,
virtual servers, aggregated services, and other techniques that overload the
IP address, this assumption is neither safe nor practical.
Although the draft explicitly declares Sender-ID and SPF as the authorization
of the transmitting SMTP client, it fails to offer the authenticated identity
being trusted.
The draft does not make that declaration. It states that Sender-ID and SPF make
that declaration. Again, confusing message with messenger.
A truly authenticated identity is essential for reputation
assessments which section 4.1 indicates should be made prior to results being
revealed.
I don't understand what significance this statement has.
Concerning this following portion of the appeal:
Table of Contents
1. Introduction 2. IPv6, SPF macros, and local-parts 3. Recommended
Modifications 4. References 4.1. References - Normative 4.2. References -
Informative Authors' Addresses
1. Introduction
In the requested review of [I-D.otis-auth-header-sec-issues], Barry Leiba
made the following remarks:
...
Since Sender-ID permits the use of either version of the SPF records to be
applied against the PRA, version 2 records must then be published whenever
authorization of a PRA is not intended. This retro- active mandate is to
prevent the misapplication of SPF [RFC4408] records against PRA header
fields. The conflict as to whether just the Mail From or the PRA has been
authorized by SPF version 1 records has left the intended scope of the SPF
record in doubt.
It has no discernible relevance to the auth-res specification. At best, it has
some relevance to mechanisms that produce output that is carried by auth-res.
The appeal's authors should therefore address their concerns with the relevant
specifications and authors. Auth-res isn't the venue for this.
The [I-D.kucherawy-sender-auth-header] fails to indicate which version of an
SPF record had been discovered, or whether any record had been discovered
allowing recipients a means to gauge risk.
Auth-res carries the information it is given. If SPF or Sender-ID should report
different information, the appeal's authors should discuss this with the SPF and
Sender-ID community.
[I-D.kucherawy-sender-auth-header] introduces a header field, which because
of its label, can mislead recipients into believing that it contains
"Authentication-Results".
The appeal's authors have nicely demonstrated that almost anything can be
confused. So an abstract fear of possible, future confusion is a pretty weak
argument for (or against) anything.b
In the case of Auth-res, there is already an established track record, with no
indication that the feared confusion due to the header field's name, has
occurred.
In addition, as a matter of simple vocabulary semantics, the chosen field name
accurately represents the role this carried information plays.
Without the presence of an authenticated identity within the
Authenticated-Results header, there can not be any practical or timely remedy
against compromised SMTP client access or BGP spoofing.
At best, the appeal's authors are confusing a possible need for independent
authentication, between report creator and report consumer, with the contents of
the report itself. Auth-res specifies the report contents. If the appeal's
authors are concerns about authenticating the contents, they should pursue a
separate specific and garner support for it.
The places within the [I-D.kucherawy-sender-auth-header] that purport either
Sender-ID or SPF as authenticating the originating domain overlook the
Auth-res "purports" nothing of the kind.
2. IPv6, SPF macros, and local-parts
Linking IPv6 with Auth-Res is creative, but spurious.
Unfortunately, the Authentication-Header draft may actually encourage use of
this dangerous local-part macro. Section 2.4.3 requires local- part
authentication before it is to be included within the Authentication-Results
header.
The relevant language in the spec prohibits including a field, in an
authentication report, if it has not been authenticated. All that that
encourages is authentication. Extrapolating that requirement into encouraging
use of that field is without basis or merit.
3. Recommended Modifications
Change Section 2.4.3 FROM:
...
TO:
To discourage exploitation risks, the entity that has been authenticated (the
IP address of the SMTP client) SHOULD BE included.
This fundamentally changes the meaning of that section of the specification and,
instead moves into active role in the internals of the reporting mechanism.
Auth-res is an entirely inappropriate venue for such semantics.
TO:
End users making direct use of this header field may inadvertently trust
information that has not been properly vetted. [SPF] results SHOULD BE
handled as specified by section 3.4.3.
This is the same confusion of venues as cited above.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html