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

SH doesn't allow empty header fields, FWIW.

We also don't have boolean values, but it seems trivial to use an integer.


> On 14 May 2018, at 4:35 pm, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
> Maybe I am missing some context, but the question here (for SH) seems
> to me that how we should carry a boolean flag.
> 
> I think that there could be two ways:
> 1. use the existence of the header as the flag, as Early-Data draft does
> 2. always require the header to carry a boolean value
> 
> I do not mind whichever we choose, but I would prefer having one way
> of doing that defined in SH.
> 
> 
> 
> 2018-05-14 15:29 GMT+09:00 Mark Nottingham <mnot@mnot.net>:
>> 
>>> 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/
>> 
> 
> 
> 
> -- 
> Kazuho Oku

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

Received on Tuesday, 15 May 2018 05:42:40 UTC