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

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

On 3/12/12 10:38 AM, Peter Saint-Andre wrote:
> 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.

OK, I thought about it quickly. :)

I think your point relates to our recommendation against making
programmatic distinctions between "standard" and "non-standard" (and
therefore perhaps "secure" and "insecure") parameters based solely on
the names. In version -04 (to be posted before the deadline tonight, I
hope), the content of Section 2 ("Recommendations for Implementers of
Application Protocols") will read as follows:

   Implementations of application protocols MUST NOT programatically
   discriminate between "standard" and "non-standard" parameters based
   solely on the names of such parameters (i.e., based solely on
   whether the name begins with 'x-' or a similar string of characters).

Now, the leap from "standard" to "secure" and "non-standard" to
"insecure" is unwarranted, I think -- sometimes it might be true, but
not in the general case -- so we might want to recommend against making
such an assumption based solely on the names of parameters. But that is
a slightly different point than the one you're making, it seems.

Peter

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