[secdir] secdir review of draft-ietf-appsawg-xdash-03

["Scott G. Kelly" <[e-mail]>]

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