Re: Artart last call review of draft-ietf-mile-rolie-10

[Kathleen Moriarty <[e-mail]>]

The telechat prep delayed my response.  Inline.

On Mon, Oct 9, 2017 at 11:45 PM, Martin Thomson
<[e-mail]> wrote:
> On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty
> <[e-mail]> 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