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

[Peter Saint-Andre <[e-mail]>]

On 3/9/12 5:42 AM, Scott G. Kelly wrote:
> 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.

Hi Scott,

I see your point, but it's not clear to me that this document is the
place to make a general statement about secure handling of application
parameters. Further, not all parameters are header fields, so this is
not a matter of headers vs. payloads. However, I do think there's an
issue here, so I will think about it more today and perhaps reply again.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/