Last Call Review of draft-ietf-appsawg-xdash-
review-ietf-appsawg-xdash-secdir-lc-kelly-2012-03-16-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.

This document deprecates the use of the "X-" prefix in application protocols
(e.g. HTTP). The security considerations section says that issues with
security-critical parameters can result in unnecessary vulnerabilities, and
points the reader to an appendix for further discussion. The appendix says

  "Furthermore, often standardization of a non-standard parameter or
   protocol element leads to subtly different behavior (e.g., the
   standard version might have different security properties as a result
   of security review provided during the standardization process).  If
   implementers treat the old, non-standard parameter and the new,
   standard parameter as equivalent, interoperability and security
   problems can ensue."

I agree with the part about interoperability issues, but I think the security
discussion is a bit more nuanced. In general, unauthenticated header fields are
not reliable, and for this reason, it should not matter whether there is an X-
prefix or not: you should not be basing security decisions on this.

I can see where some parameters might *relate* to security somehow, but it
seems that the associated data would be self-contained in terms of its security
properties, in the same way that, e.g., an encapsulated CMS payload is
self-contained.

In such cases, it is true that there would be interop issues if the receiver
mis-interpreted the payload, but in no event should the receiver be trusting
something just because it has (or does not have) the X- prefix.

I think this is very subtle, and after trying to compose a simple email I can
see that it gets complex very quickly, so I don't want to rush into a rathole
here. Still, I wonder if the security considerations should make the point that
presence or lack of an X- prefix must not be relied upon for security decisions.

--Scott