Skip to main content

Last Call Review of draft-kucherawy-authres-spf-erratum-
review-kucherawy-authres-spf-erratum-secdir-lc-meadows-2012-01-23-00

Request Review of draft-kucherawy-authres-spf-erratum
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-02-06
Requested 2012-01-12
Authors Murray Kucherawy
I-D last updated 2012-01-23
Completed reviews Secdir Last Call review of -?? by Catherine Meadows
Assignment Reviewer Catherine Meadows
State Completed
Request Last Call review on draft-kucherawy-authres-spf-erratum by Security Area Directorate Assigned
Completed 2012-01-23
review-kucherawy-authres-spf-erratum-secdir-lc-meadows-2012-01-23-00
I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the 

IESG.  These comments were written primarily for the benefit of the 

security area directors.  Document editors and WG chairs should treat 

these comments just like any other last call comments.

The purpose of this ID is summed up in the introduction as follows:

 [RFC 5451] defined a new header field for electronic mail messages

   that presents the results of a message authentication effort in a

   machine-readable format.  That Request For Comments created a

   registry of results for a few message authentication mechanisms, one

   of which was the Sender Policy Framework [SPF].  The registry

   contains one entry that is inconsistent with the latter

   specification, which was noted in an erratum filed with the RFC

   Editor.  This memo updates the IANA registries accordingly.

The inconsistent header entry identifies the case in which an evaluation

according to RFC 4408 fails.  The result of failing such an evaluation is that

the client is explicitly not authorized to inject or relay mail using the sender's DNS

domain.  RFC 5451 gave "hardfail" as the result to be listed here, while RFC 4408 used "fail"

to mean the same thing.  The purpose of this ID is to recommend that IANA mark

"hardfail" as deprecated and amend the "fail" entry appropriately.

This ID is definitely security relevant, as use of the wrong header could

cause a failure to recognize a failed authorization.  Thus in the Security Considerations

section the authors say that "cautious implementers may wish to support both

result strings for some period of time."

One quibble: I believe that the above is good advice, but it seems a little hesitant.  Why the use

of the words "cautious" and "may"?  Why not say that "we recommend that"?  Even if failure

to recognize a failed authorization doesn't lead to any immediate security problem,

it could prevent recognition of a potential attack, or more benignly, of a possible

misconfiguration.  




Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil