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

Does this help?

It is RECOMMENDED that origin servers allow resources to explicitly configure
whether early data is appropriate in requests. Absent such explicit information,
origin servers MUST either reject early data or implement the techniques
described in this document for ensuring that requests are not processed prior to
TLS handshake completion.

-- https://github.com/httpwg/http-extensions/pull/428/files

And I agree that the role thing could be clearer:
https://github.com/httpwg/http-extensions/pull/429

On Fri, Nov 24, 2017 at 9:03 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> 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
>>
>

Received on Sunday, 26 November 2017 22:52:27 UTC