The telechat prep delayed my response. Inline. On Mon, Oct 9, 2017 at 11:45 PM, Martin Thomson <martin.thomson@xxxxxxxxx> wrote: > On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty > <kathleen.moriarty.ietf@xxxxxxxxx> wrote: >> I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. > > That is true, but it's not clear to me that this is a protocol that is > intolerant of replay. AtomPub follows a pattern that limits exposure > fairly well. The primary thing to safeguard in ROLIE is the > confidentiality of the content, and replay won't generally compromise > that. The sorts of things you might see is duplicate resource > creation (we recommend against POST in early data for that reason; we > also recommend against PUT), and the sort of traffic analysis and > timing side channel information that reveals if resources exist or > have been updated (which shouldn't be an issue here). I see what you are saying and that makes sense, but you also lose forward secrecy with 0RTT and that is a problem. I think we need to accept that there will be uses of HTTP that will not allow for 0RTT. In the draft you mentioned in the HTTP working group, section 3 even starts out with, "When a server enables early data", meaning it won't always be appropriate. I do think that draft should be more clear on the risks, with a pointer back to Section 2.3 of TLS 1.3. I think there will also be cases where HTTP is used and the profile isn't a fit. Since some implementations of TLS 1.3 keep the streams separate (0RTT and full negotiation), just using the full negotiation stream will reduce configuration problems for implementers. Lots of security problems are the result of configuration mistakes and if we can avoid them in places where it matters, we should. The systems running ROLIE will be ones that enterprises will regard as high value assets. Replay attack and lack of forward secrecy aren't acceptable. The same will be true of many other HTTP enabled services. A performance gain isn't worth the trade off. Even with the profile you've created, the server has the option to not enable early data, although that's not as clear as I think it should be in the draft and is something that would be good to improve, If developers implementing the HTTP profile only look at this draft, they have to have enough context to understand the implications that they must in turn ensure implementors of their code/applications using code have the information to make appropriate decisions for their environment. I hope that's helpful enough for an update of your profile draft. My opinion is that for ROLIE, there is no need for 0RTT. I'm not sure a slight delay in publication would matter much since TLS 1.3 is getting closer to publication. If it is, we could also play with the language so it's an informational reference if there is a rush. Thanks for your thoughtful review. -- Best regards, Kathleen