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

[Kathleen Moriarty <[e-mail]>]

Sent from my iPhone

> On Oct 9, 2017, at 9:55 PM, Martin Thomson <[e-mail]> wrote:
> 
> On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty
> <[e-mail]> wrote:
>>> This is quite explicitly using HTTP, which has a profile (work in
>>> progress).  If that profile is somehow inadequate, then a case should
>>> be made in the draft explaining why (hence the choice of the word).  A
>>> reference to TLS 1.3 also has the unfortunate effect of delaying
>>> publication of this draft.
>> 
>> Can you provide a pointer?  The profile is likely inadequate for this
>> and many other uses of HTTP/TLS if early data is permitted.  0RTT has
>> a large impact across many protocols including those that use
>> HTTP/TLS.
> 
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/
> Editor's copy (with a number of changes):
> http://httpwg.org/http-extensions/replay.html
> 
>> If there is no normative language, then it can continue on to be
>> published with the draft for TLS 1.3 being used.  This is an
>> application where security is very important, so decisions like this
>> that can be made now should be prior to implementers testing TLS 1.3.
> 
> Currently there is normative language, and it wouldn't make sense to
> make any sort of statement with respect to 0-RTT without making that
> statement normative.  However, I think that it would be wiser to rely
> on HTTP doing the right thing here.  I would of course encourage you
> and the document authors to review the draft above to see if we're
> making completely unsuitable recommendations.
> 

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.

> I realize that security is very important here, but I don't think that
> it is so significantly special that a whole new application profile of
> HTTP is needed.  HTTP can be very secure with the right configuration.

Configuration mistakes happen and lead to big problems.

> Strong recommendations about good practices for both configuration and
> operation are appropriate.  RFC 7525 is what I would use for that.
> RFC 7525 covers all that the draft does and more.

Yes, I had pointed that out in my review.

Best,
Kathleen