Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)

[Brian Smith <[e-mail]>]

On Mon, Dec 9, 2013 at 9:16 AM, Martin Thomson <[e-mail]> wrote:
> On 9 December 2013 05:56, Brian Smith <[e-mail]> wrote:
>> Please see http://tools.ietf.org/html/draft-nottingham-http2-encryption-01#section-2.1
>> (read the whole document, but section 2.1 is especially interesting).
>> That document defines a mechanism wherein, through protocol
>> negotiation, a web browser and server can agree on a "relaxed" form of
>> TLS for HTTP where the client does not authenticate the server's
>> certificate. The goal is to enable a form of opportunistic encryption
>> to HTTP.
>
> My feedback to Mark on this point was that this negotiation was
> completely unnecessary.
>
> A server already has a way to signal that it doesn't care about
> certain security properties of a resource.  It does that by omitting
> the 's' in the resource URL.
>
> A client is then left to decide whether it cares about those
> properties.  What requirements are then placed on the subsequent
> interactions are up to the client.

Hi Martin,

If the server really doesn't care about the security or privacy
properties of a resource, then it wouldn't implement opportunistic
encryption in the first place, unless it was doing so purely as a
compatibility hack.

I think the point that you are making is that adding the
http2-tls-relaxed negotiation to the TLS handshake is pointless,
because you cannot securely negotiate anything on an insecure
connection. If so, then we'd say that the client MUST NOT advertise
the http2-tls-relaxed ALPN token, in order to avoid tipping off any
MitM that the connection will be unauthenticated. Is that right?

I think this means that, if the client supports opportunistic
encryption, then there would never be any way for the server to
securely know whether the client authenticated the connection or not,
so there's no secure way for a single server on a single port to
support both unauthenticated and authenticated TLS. Is this your
conclusion too?

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)