Reviewer: Chris Lonvick
Review result: Ready
Hi,
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.
I’ve seen a lot of discussion about this draft, so I’ll enter my reasons of why
I think that the document is (again) ready.
First, looking at this from an operational, “on the wire” perspective, the
Expires header field will pose no additional security concerns over those
defined in RFC 5322. I usually like to recommend to the authors that they have
a statement in the Security Considerations section referencing the Security
Considerations sections of at least a preceding RFC, but RFC 5322 contains a
very minimal Security Considerations section. I don’t think anyone implementing
the Expires header field would benefit from reading that.
While I don’t keep up with discussions regarding email in the IETF, I surmised
two things from the minimal Security Considerations section of RFC 5322: -
If the email community had consensus about the operational security of header
fields, they would have gotten together and written an RFC about it by now. -
The email community has been operating email systems for a long time and
have figured out how to deal with any “on the wire” operational concerns of
header fields. From that, I don’t think that the authors of this draft need to
add anything more to the Security Considerations section than what they have.
Making them do so would require them to take on the work, and obtain consensus,
of what should have been done in creating RFC 5322.
I did see an email go across the list that said something about the folding
white space in this header field. I don’t think that the authors of this draft
need to specifically address that. The reference to the ABNF of RFC 5322 was
sufficient and processing folding white space has been done for a long time.
There’s nothing in this field that would change that long-standing practice.
Second, I feel certain that the administrative policies of individuals and
companies for email systems will not be changed by receiving emails that
contain an Expires header field. I believe that all systems receiving an email
from outside their domains have, and will continue to have, a healthy distrust
of all received header fields. As others have said in the thread of this
discussion, at best the received header fields have been considered to be
“advisory”. The Expires header field doesn’t bring in anything new. Other
headers set by the originators, like orig-date, are usually not trusted if they
come from outside the domain, and I expect that they are not fully trusted even
if the email originates and stays within a domain.
Along those lines, I saw that there is an implementation where the Expires
header field is being used solely to provide some additional notification to
recipients. That seems appropriate. I’ve also seen enterprises enforce
retention policies to the extent that received emails are deleted at a certain
time after receipt, whether they’ve been read or not. I don’t see that the
Expires header is going to change those policies.
>From that, I feel that what the authors have written in the draft is sufficient.
Happy Holidays and Best Regards,
Chris
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
