Re: Getting our definitions of encryption straight for the HTTP/2 security discussion

On Wed, Nov 20, 2013 at 4:54 PM, Mark Nottingham <> wrote:

> Thanks Paul - that's helpful. I've moved it over to <
>> (since
> all of the other HTTP/2 material is there) and linked from the most
> relevant issue, <>.


> Would you agree that the distinction between better-than-nothing
> encryption and best-effort encryption is only important if someone chooses
> to do something with the information that server auth is or is not in place?

No. Better-than-nothing is an end-state: definitely unauthenticated.
Best-effort is a process: try for server-encrypted but fall back to
better-than-nothing if that isn't possible. If there is a good way to
indicate that the first two definitions are end states, but the latter two
are processes, that would be great.

> Keeping in mind that the "someone" is either going to be the UA (e.g., by
> changing its security indications to the user), or the origin server (and I
> *think* the only meaningful thing here would be to allow them to opt out of
> unauthenticated connections).

I agree with the first part (what to show the end user for the end states)
is a good idea. I'm still very hesitant on the second part where the client
tells the server "I'm not authenticating you" and the server then stops the
connection. I would want to hear more use cases for that choice. It seems
to me that the server might want to do something different with the
connection, but "I'm just stopping" seems like a big change in our current

> Mind you, I think it's OK if we specify best-effort and people use it just
> to get better-than-nothing encryption, provided it doesn't increase
> complexity too much; just making sure I understand the difference.
That's exactly my concern with the server stopping: that's a new state the
client needs to deal with. I don't want clients lying to the server about
authenticating just to keep the connection going.

--Paul Hoffman

Received on Thursday, 21 November 2013 01:12:56 UTC