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

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

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

I would suggest, therefore, adding the following paragraph to the
Security Considerations:

   As a corollary to the recommendation provided under Section 2,
   implementations MUST NOT assume that "standard" parameters are
   "secure" whereas "non-standard" parameters are "insecure", based
   solely on the names of such parameters.

Strictly speaking that shouldn't be necessary because the security of a
parameter is just one instance of the parameter's (assumed) properties,
but it might be a helpful clarification.

Peter

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