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

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 9 Mar 2012 04:42:40 -0800 (PST)

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 10:38:23 -0600

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
> 
> 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 10:46:22 -0600

> 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Mar 2012 10:57:57 -0600

> 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/