Re: Working Group Last Call for Using Early Data in HTTP

I think this is a useful mitigation draft but am concerned that
there's a bit of arm-waving at it's core. Given that people are
(sadly IMO) super-keen about using 0rtt, and this draft is a
harm-reduction effort, I can accept that we may end up having to
live with some arm-waving but I'd like to ask about one bit of
that.

(BTW: Apologies if this was covered in previous list discussion,
if so, pointing me there is a fine answer and I'll try not to
cause any more regurgitation:-)

Section 3 says:

  "It is RECOMMENDED that origin servers allow resources to explicitly
   configure whether early data is appropriate in requests.  Absent such
   explicit information, they SHOULD mitigate against early data in
   requests that have unsafe methods, using the techniques outlined
   above."

I don't get why that SHOULD isn't a MUST. Can you explain why
it'd be ok for an origin server to allow unsafe methods in early
data for all resources that aren't explicitly indicated as being
actually-safe? (I don't see how an origin server could be selective
for the unsafe resources for which there's no config, hence asking
about all resources.)

I'm also not entirely clear what you mean by "mitigate" here. If
mitigate meant reject it'd be clear, but if "mitigate" means "do
whatever you want to handle that" then the entire paragraph starts
to look like weasel words. I assume that you mean one or more of
items 1-4 from earlier in the section. If so, I'm afraid that does
seem to amount to the latter "do whatever you want" kind of guidance.
Is it really not possible to be more specific here?

As a separate comment, the draft is a little vague about the TLS
role of the intermediary or gateway and whether or not those mean
the same thing always. I read it as saying that intermediary and
gateway are synonyms (from the TLS POV) and that the intermediary
or gateway is the TLS server in all cases. If that's a mis-reading
then it might be worth a bit more clarification. (And if I've got
that wrong, then I don't understand how that entity adds an HTTP
header field in section 5.1 for sure:-)

Cheers,
S.

On 24/11/17 02:43, Patrick McManus wrote:
> Hi All - When we met in Singapore we discussed a couple final details of
> the Early Data / Replay draft and indicated we would start WGLC after a
> final(?) update. The authors have made that update and we're ready for the
> LC now.
> 
> Please have a look at:
> https://tools.ietf.org/html/draft-ietf-httpbis-replay-02
> 
> Raise any issues either on the mailing list or in the issues list.
> Statements of support, implementation, or intent to implement to the list
> would also be helpful.
> 
> We'll run this for a touch over two weeks, ending the WGLC on December 10,
> 2017. We look forward to your comments :)
> 
> -Patrick
>