Subject: Re: TAG requests addition to section 3.2.1 of Part 3 [#155]

From: [email-masked] (Henry S. Thompson)
Date: Wed, 09 Jun 2010 13:47:52 +0100

Further to the TAG's suggestion in [1] regarding 'sniffing', and
replies from Yves Lafon [2] and Mark Nottingham [3], the TAG has asked
me to convey our thanks for your willingness to reopen this issue.
With some minor adjustments, we are happy that the text proposed at [2]
addresses most of our concerns.

We suggest the following two minor changes:

  does not correctly identify the content sent

 -->

  does not reflect the intended interpretation of the content sent

 and

  Such recipients SHOULD NOT

 -->

  Recipients SHOULD NOT

We would however prefer that something about this issue also remain in
section 3.1.2.  Perhaps keep

  If the Content-Type header field is present, a recipient which
  interprets the underlying data in a way inconsistent with the
  specified media type risks drawing incorrect conclusions.

in 3.1.2, adding something along the lines of "See [7.3] for a related
security issue.", but we are happy to leave this to your editorial
discretion.

We are less happy with the proposed addition suggested by Mark in [3],
on the grounds that it a) implies that documents have media types in
some intrinsic way, which we think is at best misleading, and that b)
the straw men it sets up will in fact be counterproductive.

ht, on behalf of the TAG

[1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0493.html
[2] http://lists.w3.org/Archives/Public/public-html/2010Mar/0659.html
[3] http://lists.w3.org/Archives/Public/public-html/2010May/0330.html
[This message pertains to TAG ACTION-370]
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Jun 2010 09:52:57 +1000

Henry,

My only concern with [2] is this set of requirements

>    Such recipients SHOULD NOT override the specified type it there are
>    known security risks and they SHOULD provide for users to disable such
>    heuristic Content-Type detection.

as discussed before. 

HTTPbis can introduce new requirements that break existing implementations only where there are overriding security and/or interoperability concerns. 

While it could be argued that this holds true here, the first requirement is quite vague, and the second will AFAIK make every existing implementation non-conformant (with the possibility that they will remain so indefinitely).

Would the TAG be amenable to either dropping this sentence from the proposal, or modifying the text at [3] to address your concerns?

Regards,

On 09/06/2010, at 10:47 PM, Henry S. Thompson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFMD414kjnJixAXWBoRAr4EAJ9W4zFN1SywFjfMG8QQtXAiPPmaIwCfbAw2
> rZ/VkbMn24RAI2S6OoMUDWU=
> =dhkn
> -----END PGP SIGNATURE-----

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jun 2010 11:46:52 +1000

The HTTPbis editors discussed this yesterday, and came up with the following proposal:

---8<---
3.2.1 Type

When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered  encoding model:

  entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body, unless that information is unknown. 

If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients MAY either assume that it is "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the content to determine its type.

In practice, currently-deployed servers sometime provide a Content-Type header which does not correctly convey the intended interpretation of the content sent, with the result that some clients will examine the response body's content and override the specified type.

Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation"). Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.

Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource.  There is no default encoding.
--->8---

New text is the two paragraphs starting with "In practice..."

Thoughts, both from the HTTPbis WG, the HTML WG and the TAG?

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jun 2010 13:20:04 +0200

On 15.06.2010 03:46, Mark Nottingham wrote:
> ...

I think this is good, because...:

- it accurately reflects the situation

- it doesn't make new normative requirements we know won't be adhered to

- it points out the risks, without going into too much detail (which 
would require lots of additional work that really needs to go somewhere 
else)

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/155/i155.diff>

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 17 Jun 2010 18:56:14 +0100

> The HTTPbis editors discussed this yesterday, and came up with the

. . .

Thank you for your helpful response.  At their telcon today, the TAG
agreed that your proposal addresses our concerns, and we will close
our ACTION-370.

On behalf of the TAG,

ht
- --

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Jun 2010 12:03:02 +1000

Just to the HTTPbis WG: any objections to this revised text for #155?

On 18/06/2010, at 3:56 AM, Henry S. Thompson wrote:

> iD8DBQFMGmG+kjnJixAXWBoRAq8GAJ99YdgCF9XTpRGem+aH+2y3izibgwCdHrgo
> DBr1AjbBs2YsyI0oN0JGVpo=
> =DWrt

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 21 Jun 2010 10:21:54 +0200

> Just to the HTTPbis WG: any objections to this revised text for #155?

Would have helped if the text had been quoted together with the
question. I guess from the thread that it's this:

http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0325.html

        In practice, currently-deployed servers sometime provide a
        Content-Type header which does not correctly convey the intended
        interpretation of the content sent, with the result that some
        clients will examine the response body's content and override
        the specified type.
        
        Client that do so risk drawing incorrect conclusions, which may
        expose additional security risks (e.g., "privilege escalation").
        Implementers are encouraged to provide a means of disabling such
        "content sniffing" when it is used.
        
If this is the text you refer to then +1 From me. I think this
represents the general view of the group, and works well together with
the rest of the document text on Content Type.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Jun 2010 19:19:29 +0200

> Just to the HTTPbis WG: any objections to this revised text for #155?

There weren't any, so I have applied the change with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/831>.

Best regards, Julian