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

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

Received on Monday, 14 May 2018 06:35:48 UTC