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

Read this for the first time. Well-written and useful document.

- Abstract: “This document explains the risks of using early data for HTTP ...”
Very little explanations of risks in the document. I think more explanation and maybe some examples would be helpful for the readers of this document.

- Section 1: “one or two round trip delay”
Should this be “one or two round trip delays”?

- Section 2: “concatenated with other application”
Should this be “concatenated with other application data”?

- Section 1: “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains.”

I think the it would be very good to explain what replay means in this case, especially as the reader might be someone without detailed knowledge of TLS 1.3. While replay in some cases means more than duplication, replay in normal language means duplication and anti-replay are in most cases synonym with mechanisms mitigating duplication. I suggest something like:

 “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. The attacker might delay, reorder, and/or duplicate requests.”

- Section 3: “TLS [TLS13] mandates”
Doesn’t TLS 1.3 says “SHOULD implement either the single-use tickets or ClientHello recording techniques”?

- Section 3: “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.”

“unsafe methods” -> “not safe from side-effects” following the reason above.

Agree with Stephen Farrell that something is missing here. I would suggest something like:

“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 not safe from side-effects, using the techniques outlined
above. Absent explicit information and mitigations, origin servers
MUST NOT accept early data in requests not safe from side-effects.”

/John

On 2017-11-24, 11:12, "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 Saturday, 25 November 2017 06:44:55 UTC