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

[Benjamin Kaduk <[e-mail]>]

Sorry for the slow response to this thread; I wanted to have a closer
read of the ROLIE document itself (and not just the cherry-picked
TLS-specific bits).

On Mon, Oct 16, 2017 at 11:45:59AM +1100, Martin Thomson wrote:
> On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty
> <[e-mail]> wrote:
> > 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.
> 
> My point isn't to reject this sort of analysis, which is possibly
> correct, but to point out that this analysis is one that a deployment
> makes based on the circumstances
> 
> Everyone thinks that their thing is a special snowflake, and that's
> OK, but you are asking for a levy on all implementations that would
> prevent use of 0-RTT in all deployments.  I think that is
> inappropriate.  I don't want to see every draft that the IETF ever
> published making its own assessment and a policy statement regarding
> this particular feature.  (We don't mandate a particular
> authentication mechanism here either.)

Every draft doesn't have to; in the absense of an explicit statement
it is assumed that 0-RTT should not be used.

But, for protocols built on top of HTTP, perhaps things are not
as clear cut.

> Note that TLS 1.3 permits resumption without forward secrecy.  It's
> not widely implemented that way, but it is possible.  If you care
> about forward secrecy (I'm not sure that it's especially critical in
> this context given the time-sensitive nature of the information you
> are talking about), then you have to make statements about that as
> well.  But again, I would not on the same grounds: the purpose of this
> work is to define what interoperability looks like, not to legislate
> deployment configuration.  Explain the trade-off and let the
> operational teams do their work.

My main consideration is that the ROLIE document we're talking about
is a framework, and does not define any information types itself.  So,
you are asking the operational teams to know and anlayze not just what
events they are currently handling but also all types that might be
handled in the future, which seems like an intractable analysis for
them to perform.  But yes, you are right that a statement about forward
secrecy as a requirement would be appropriate.

I'm also quite reluctant to provide a general recommendation to send
client-authenticated requests in 0-RTT, as it still seems too risky to me.

I also don't see how preventing the use of 0-RTT is supposed to be
a "levy on all implementations".  It seems to only require *not* adding
additional code/logic to handle 0-RTT.  I could perhaps see calling it
a "levy on deployments" that are unable to take advantage of the
performance benefits, but given the large number of unknowns in what
will be conveyed via ROLIE, it seems to me an unwarranted risk to try
to take advantage of those benefits in general.

-Ben