Subject: Intent of 14.38 Server

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Wed, 20 Dec 2006 16:47:21 -0800

Section 14.38 states:

"If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it MUST include a Via field (as described in Section 14.45)."

Taken literally, this requirement overrides the ability for a proxy to replace whitespace, and totally prevents a proxy from sanitizing the field-value. Is this the intent? The mention of Via seems to indicate otherwise -- that the intent is to prevent proxies from inserting their own server string into the Server header.

Another problem is that the term "modify" is not defined precisely. Does removal of a header count as modification?

Any thoughts?

-- Travis

---

From: Paul Leach <[email-masked]>
Date: Wed, 20 Dec 2006 17:24:27 -0800

Authentication protocols that provide integrity protection can rely on
the original wording to mean that they can include fields that proxies
aren't allowed to modify in the integrity check.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Travis Snoozy (Volt)
Sent: Wednesday, December 20, 2006 4:47 PM
To: [email-masked]
Subject: Intent of 14.38 Server

Section 14.38 states:

"If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it MUST
include a Via field (as described in Section 14.45)."

Taken literally, this requirement overrides the ability for a proxy to
replace whitespace, and totally prevents a proxy from sanitizing the
field-value. Is this the intent? The mention of Via seems to indicate
otherwise -- that the intent is to prevent proxies from inserting their
own server string into the Server header.

Another problem is that the term "modify" is not defined precisely. Does
removal of a header count as modification?

Any thoughts?

-- Travis

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 21 Dec 2006 16:03:06 +0100

> aren't allowed to modify in the integrity check.

Are you sure?

I very much doubt thats the reason to the specific wording about the
Server header..  Have always read that part as that the proxy have no
business mucking around with the Server header to advertise itself, it
MUST use the Via header for this purpose.

The Server header is supposed to advertise the software version of the
products making up the server, not as a communication channel or
capability indication.

Is it really true that proxies is not allowed to clean up LWS in Server
headers? I have always considered folding/unfolding, LWS cleanup and and
list merging to be safe operations on all headers.

Regards
Henrik

---

From: "Travis Snoozy (Volt)" <[email-masked]>
Date: Thu, 21 Dec 2006 10:16:44 -0800

Henrik Nordstrom said:
<snip>

> list merging to be safe operations on all headers.

Well, I'd say the answer hinges on what "modify" means.

1. "A recipient MAY replace any linear white space with a single SP before
   interpreting the field value or forwarding the message downstream."
   (Section 2.2, page 16)

2. "If the response is being forwarded by a proxy, the proxy application
   MUST NOT modify the Server response-header." (Section 14.38, page 141)

3. "MAY   This word, or the adjective 'OPTIONAL', mean that an item is
   truly optional.  [...] An implementation which does not include a
   particular option MUST be prepared to interoperate with another
   implementation which does include the option, though perhaps with reduced
   functionality. In the same vein an implementation which does include a
   particular option MUST be prepared to interoperate with another
   implementation which does not include the option (except, of course, for
   the feature the option provides.)" (BCP0014)

--

Supposing (1) IS considered modification, if (1) is applied to a Server
header, then the implementation is in violation of the spec, as per (2).
However, if any application depends on (2), they would be in violation
of (3) (UNLESS (3) is determined to be null and void in cases where a MUST
conflicts with it). Thus, it's technically possible to correctly implement this interpretation, but it uselessly locks the Server header.

Supposing (1) IS NOT considered modification, we can perform (1) without
violating (2). (3) applies as it does for all "modifiable" headers. IMHO,
this makes the most sense, but it requires that we define what "modify"
means (which gives us the opportunity to take care of the "is deletion
modification?" question).

I propose adding the following (or something like it) to section 1.3:

modify
   When applied to headers, "modify" means any change made to the field-
   value that alters the semantic meaning of that field. Combining multiple
   header fields (see section 4.2) and replacing LWS with a single SP (see
   section 2.2) are not considered modifications, nor are any changes that
   have been specified as having no semantic meaning. The removal of a
   header and altering the order of headers that have the same field-name
   are both considered to be modifications.

-- Travis

---

From: David Morris <[email-masked]>
Date: Thu, 21 Dec 2006 10:46:00 -0800 (PST)

I recall the authentication dicussion Paul referenced, but not the
details. Given the conflicts noted below, and good engineering practice,
would be to normalize any values before using them in computing an hash
used as part of authentiction. That would allow LWS cleanup of any header
with no negative impact. Don't know what the digest auth rfc requires
however.

Dave Morris

---

From: Paul Leach <[email-masked]>
Date: Thu, 21 Dec 2006 11:29:55 -0800

Sorry, I didn't mean to imply that that was the motivation, just that
because it is that way, for whatever reason, authentication protocols
could previously depend on it.

I could imagine that wanting integrity protection for the header might
be interesting. I forget specific details, but it was kind of annoying
when designing Digest how few headers could be integrity protected that
it seemed it might be useful to protect. (The natural inclination of
security geeks is to be conservative and protect as much as possible,
instead of guessing what might be important.)

-----Original Message-----
From: Henrik Nordstrom [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 7:03 AM
To: Paul Leach
Cc: Travis Snoozy (Volt); [email-masked]
Subject: RE: Intent of 14.38 Server

Are you sure?

Regards
Henrik

---

From: Paul Leach <[email-masked]>
Date: Thu, 21 Dec 2006 12:13:26 -0800

I'd be happy to do that, if someone else works out the canonicalization
rules (or restricts the set of modifications that can be made to, e.g.,
LWS tweaks).

As I recall, the number of different ways of saying the same thing is
really large -- e.g., not just LWS, but escapes, different list orders,
etc.

And, as a practical matter, no clients canonicalize. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Morris
Sent: Thursday, December 21, 2006 10:46 AM
To: Travis Snoozy (Volt)
Cc: [email-masked]
Subject: RE: Intent of 14.38 Server

I recall the authentication dicussion Paul referenced, but not the
details. Given the conflicts noted below, and good engineering practice,
would be to normalize any values before using them in computing an hash
used as part of authentiction. That would allow LWS cleanup of any
header with no negative impact. Don't know what the digest auth rfc
requires however.

Dave Morris

On Thu, 21 Dec 2006, Travis Snoozy (Volt) wrote:

>
>
> Henrik Nordstrom said:
> <snip>
>
> > Is it really true that proxies is not allowed to clean up LWS in 
> > Server headers? I have always considered folding/unfolding, LWS 
> > cleanup and and list merging to be safe operations on all headers.
>
> Supposing (1) IS considered modification, if (1) is applied to a 
> Server header, then the implementation is in violation of the spec, as
per (2).

> of (3) (UNLESS (3) is determined to be null and void in cases where a 
> MUST conflicts with it). Thus, it's technically possible to correctly
implement this interpretation, but it uselessly locks the Server header.
>
> Supposing (1) IS NOT considered modification, we can perform (1) 
> without violating (2). (3) applies as it does for all "modifiable" 
> headers. IMHO, this makes the most sense, but it requires that we
define what "modify"