W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: draft-ietf-httpbis-replay-03, "5.1. The Early-Data Header Field"

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 14 May 2018 16:29:02 +1000
Cc: Willy Tarreau <w@1wt.eu>, "Julian F. Reschke" <julian.reschke@gmx.de>, Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DC5ED7A8-9424-4405-BF03-C8BB2252D455@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>

> On 14 May 2018, at 4:21 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> Mark, are you advocating for removing the text around duplicate values and
> falling back to something like:
> 
> "If the header field is repeated or contains a value other than "1" it is
> invalid.  An invalid header field SHOULD be disregarded."

As I said at the start, I'm not asking for any changes to the early-data header field; just trying to validate that in theory, SH would be usable for it (if the timing worked out).

Of course, we *can* make changes if we wish.

> There's an interesting question here about how the requirement to discard
> malformed header fields generates appropriate feedback signals, but I think
> that you have a fair point.  If we stop assuming that we have to deal with
> actors that fail to implement correctly, then we exert pressure on those
> actors to comply.  And everyone benefits because our code is simpler and
> more consistent overall.

*If* it's consistent. We're putting mechanisms in place for SH to help that (generic implementations and a test suite); not sure that applies here.


> I was initially attracted to the idea that maybe *just this one time* the
> use case was "special".  But that's dangerous thinking.

:)

> One comment for SH.  You permit additional constraints on syntax (like
> ranges on integers).  You separately note that if parsing fails the header
> field is dropped.  You should connect the two explicitly. If a header field
> is valid according to SH, but invalid according to constraints on the
> specific header field what happens?
>   * it needs to be dropped because malformed header fields are dropped
> according to SH
>   * the definition of the specific header field needs to define what
> happens in this case
> 
> I think that your assumed position here is the former, but that needs to be
> really crisp.
> 
> https://github.com/httpwg/http-extensions/issues/623

Section 2 of the editors' draft already says:

"However, header field authors are encouraged to clearly state additional constraints upon the syntax, as well as the consequences when those constraints are violated."

https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#specify

Happy to take PRs to expand upon that; if not, I'll try to tease it out.

Cheers,




> On Mon, May 14, 2018 at 3:56 PM Mark Nottingham <mnot@mnot.net> wrote:
> 
>> The general discussion around SH error handling has been that if we're
> able to establish good interop early on with clear algorithms and a test
> suite, it's not necessary to have messy post-hoc special casing like we do
> with many existing HTTP headers.
> 
>> See also <https://tools.ietf.org/html/draft-iab-protocol-maintenance-00>.
> 
>> Cheers,
> 
> 
>>> On 14 May 2018, at 3:36 pm, Willy Tarreau <w@1wt.eu> wrote:
>>> 
>>> On Mon, May 14, 2018 at 07:00:19AM +0200, Julian Reschke wrote:
>>>> On 2018-05-14 00:45, Mark Nottingham wrote:
>>>>> ...
>>>>>>> And I'm OK with that in this case.  Were we to cite structured
> headers, we
>>>>>>> would probably want to call out that direct contravention.
>>>>> 
>>>>> My assumption was that if this spec were using SH, you wouldn't need
> to say anything beyond 'this is the structure we expect:...".
>>>>> ...
>>>> 
>>>> Agreed. If we need a special case for something simple like that, one
> of the
>>>> two specs needs to change.
>>> 
>>> I was trying to figure what other very sensitive header field we have
>>> which falls in this situation where we don't want to simply ignore nor
>>> discard it. Transfer-Encoding is one such header field. What we do
>>> there for non-100% valid requests is to return 400 (cf 7230#3.3.3).
>>> 
>>> Given the sensitifivity of the Early-Data header field, I'm now more
>>> convinced that the risk of being too tolerant with it could lead to
>>> some agents setting it lazily and causing interoperability issues or
>>> opening replay attacks. Thus I would suggest the following instead :
>>> 
>>> If a server receives a request message containing more than one
>>> Early-Data header field or one such header field with a value that
>>> is not exactly "1", the server MUST respond with a 400 (Bad Request)
>>> status code and thne close the connection.
>>> 
>>> Optionally we could try to deduplicate identical values like we already
>>> do for Content-Length, but I'm inclined to think that it's up to the
>>> intermediaries which decide to add this field to first verify if another
>>> one was already present.
>>> 
>>> I think we should always keep SH in mind when adding new fields, and try
>>> hard not to open new cans of worms all the time. That doesn't mean it
>>> will always work but at least we have to try.
>>> 
>>> Cheers,
>>> Willy
> 
>> --
>> Mark Nottingham   https://www.mnot.net/

--
Mark Nottingham   https://www.mnot.net/
Received on Monday, 14 May 2018 06:29:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC