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

Hi Martin,

(Sorry for the slow response, was on a few days off)

On 26/11/17 22:52, Martin Thomson wrote:
> 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

Both of those look better to me, thanks,

S.


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