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

Brian Smith <> Tue, 10 December 2013 02:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D78C31AE0D8 for <>; Mon, 9 Dec 2013 18:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wue34DI5vWF1 for <>; Mon, 9 Dec 2013 18:15:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DB3CF1AE0F8 for <>; Mon, 9 Dec 2013 18:15:46 -0800 (PST)
Received: by with SMTP id gc15so3583860qeb.7 for <>; Mon, 09 Dec 2013 18:15:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X2HLXeF8/Tl1APr4PUSHgz8S4YeyXzcxhRzw075QA2E=; b=O4LZt+vrrc6zVyhSaQqCIzKAFLG38chbPfvIk8XygnDbLtAUIYGlMCiR6lPrFpv/rn Zl8xTCFTVz5yfgyb4dUbGOIJYvgnh3DKgtpmBybPBn2yHWulvSMOXk+NvKdMplmUJCpw rBDujmLbpGUOjYv1OGcqUbrgpN6jDoKrWqbTktTDFxFtps0p21x4uq3RCZNiCS9nUCeL NlAnOA0gJlonN1b0279RieOpfC1J3XjYDPOCpFuVF8ARBLR4/XEU+EkeOiRq7eqsAKOy qs/j5xBPmrGSmZGDjVmr6E9mQgMF2BpTfbFg/40jVXqYBJ5zgvep8TU0RgZcRK+VpJ66 oXow==
X-Gm-Message-State: ALoCoQk/YAQ7AQBd4Q0zwoyCoh+2ZUHcXlLlIJBxk5hSRxKjCX1Xd4SaoQDXE/3CmEuEGDIEsrVm
MIME-Version: 1.0
X-Received: by with SMTP id i2mr39251056qeo.26.1386641741733; Mon, 09 Dec 2013 18:15:41 -0800 (PST)
Received: by with HTTP; Mon, 9 Dec 2013 18:15:41 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Mon, 9 Dec 2013 18:15:41 -0800
Message-ID: <>
From: Brian Smith <>
To: Martin Thomson <>
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann <>, "<>" <>
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2013 02:15:49 -0000

On Mon, Dec 9, 2013 at 9:16 AM, Martin Thomson <> wrote:
> On 9 December 2013 05:56, Brian Smith <> wrote:
>> Please see
>> (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?

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)