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

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."

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.

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
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/

Received on Monday, 14 May 2018 06:21:36 UTC