h2 header field names

This comment is in reference to section 10.3 of

http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt

> 10.3.  Intermediary Encapsulation Attacks
> 
>    HTTP/2 header field names and values are encoded as sequences of
>    octets with a length prefix.  This enables HTTP/2 to carry any string
>    of octets as the name or value of a header field.  An intermediary
>    that translates HTTP/2 requests or responses into HTTP/1.1 directly
>    could permit the creation of corrupted HTTP/1.1 messages.  An
>    attacker might exploit this behavior to cause the intermediary to
>    create HTTP/1.1 messages with illegal header fields, extra header
>    fields, or even new messages that are entirely falsified.
> 
>    Header field names or values that contain characters not permitted by
>    HTTP/1.1, including carriage return (ASCII 0xd) or line feed (ASCII
>    0xa) MUST NOT be translated verbatim by an intermediary, as
>    stipulated in [RFC7230], Section 3.2.4.
> 
>    Translation from HTTP/1.x to HTTP/2 does not produce the same
>    opportunity to an attacker.  Intermediaries that perform translation
>    to HTTP/2 MUST remove any instances of the "obs-fold" production from
>    header field values.

This section is incorrectly stated.  While it is worthwhile to warn
implementors of the difference between header field name syntax,
the actual sending of an HTTP/1.1 message is governed by HTTP/1.1
(not this spec). The second paragraph is already forbidden by RFC7230,
as is the third.

What this should say:

HTTP/2 allows header field names that are not valid header fields in
the Internet Message Syntax used by HTTP/1.1 and cannot be registered
as such with IANA.  An intermediary that is attempting to translate an
HTTP/2 request or response containing such an invalid field name into
an HTTP/1.1 message ought to ...

   {discard the field because only someone who wanted it to be discarded
    would be stupid enough to use an invalid field-name} |
   {do some magic undefined thing that has never been defined because
    it is a stupid idea for any Internet protocol to suggest a change
    to field name syntax} |
   {send a STREAM_ERROR because they deserve it}.

Alternatively, restrict the HTTP/2 header name syntax (not including
pseudo-headers) to the same syntax as HTTP/1.1, because that is the
sane thing to do.

HTTP/2 allows header field values that are not valid header field values
in the Internet Message Syntax used by HTTP/1.1.  An intermediary that
is attempting to translate an HTTP/2 request or response containing such
an invalid field name into an HTTP/1.1 message MUST perform the following
encoding of the octets that are not allowed in field-content: {pick one}.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Monday, 1 September 2014 02:37:45 UTC