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

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

Received on Monday, 14 May 2018 05:37:15 UTC