Return-Path: X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9821A7011 for ; Thu, 5 Feb 2015 16:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjaENLCF7ftf for ; Thu, 5 Feb 2015 16:07:46 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BF51A0029 for ; Thu, 5 Feb 2015 16:07:46 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from ) id 1YJWPT-0002JW-E6 for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Feb 2015 00:04:35 +0000 Resent-Date: Fri, 06 Feb 2015 00:04:35 +0000 Resent-Message-Id: Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from ) id 1YJWPM-0002Il-9A for ietf-http-wg@listhub.w3.org; Fri, 06 Feb 2015 00:04:28 +0000 Received: from mail-wi0-f173.google.com ([209.85.212.173]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1YJWPL-0007Yd-1Y for ietf-http-wg@w3.org; Fri, 06 Feb 2015 00:04:28 +0000 Received: by mail-wi0-f173.google.com with SMTP id r20so1382938wiv.0 for ; Thu, 05 Feb 2015 16:03:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2neTQ6Yd978ewrvscDEkXBsZrhURL6zXvMHxsL82x4s=; b=Z2oJFRQlqjrANFkTJOQVGE7i79Pv5EjsLOmGYKj0LxOME0JRr3TlfMgwUuwnIIR236 pGqZkv+OtyvUPx88cBPiv+/V3ONDCQ7mAcnlmR0LSGZJjilY+7efcVt+V0pAowi5kI5W DWu5Dl7LAA4MU6ix2OPiqiCFiukD547zhzDEiyn5+LBdrRfdYII1nlGRR3pwD/xcNo9d Cu2MEZSG6tC2gmhtxZb6vvShPvQ88lGqfkLJpNJIzezncXxW2DI64kzN6FYtAeI2UVCC m6pC1AwVUdKaKL4V/F+JQV9R4ccLsckn/O8Co4YwOYQfYE2b5rZwnxTjQ9RD9PNviCX7 Rz/Q== X-Gm-Message-State: ALoCoQmSiJIe9Ht4CfIUFKtDsUmvujdoSqyVp7mxgE6UZ2pSpDoebI7KN7FBRg5PbnSRoHPtugKE X-Received: by 10.180.74.8 with SMTP id p8mr1487274wiv.61.1423181039734; Thu, 05 Feb 2015 16:03:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.219.205 with HTTP; Thu, 5 Feb 2015 16:03:19 -0800 (PST) In-Reply-To: References: <20150205162845.GA13872@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 6 Feb 2015 11:03:19 +1100 Message-ID: To: Erik Nygren Cc: Ilari Liusvaara , "ietf-http-wg@w3.org Group" Content-Type: multipart/alternative; boundary=f46d043c7b9e53261a050e602861 Received-SPF: none client-ip=209.85.212.173; envelope-from=ekr@rtfm.com; helo=mail-wi0-f173.google.com X-W3C-Hub-Spam-Status: No, score=-3.8 X-W3C-Hub-Spam-Report: AWL=-3.101, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001 X-W3C-Scan-Sig: maggie.w3.org 1YJWPL-0007Yd-1Y b49ee9a86644ae6fd365181efaa7f1b7 X-Original-To: ietf-http-wg@w3.org Subject: Re: http2 opportunistic security negotiation Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/28766 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --f46d043c7b9e53261a050e602861 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 6, 2015 at 9:21 AM, Erik Nygren wrote: > On Thu, Feb 5, 2015 at 11:28 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > >> >> Even TLS 1.3 won't encrypt the ALPN (at least as TLS 1.3 currently is). > > > > Why can't the server's ALPN response be in EncryptedExtensions for a TLS > 1.3 ServerHello > even if the client's ALPN (a superset so less interesting) is in-the-clear > in the ClientHello? > That is my expectation, since it falls into the category of extensions "which are not needed to establish the cryptographic context" -Ekr > Erik > > --f46d043c7b9e53261a050e602861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 6, 2015 at 9:21 AM, Erik Nygren <erik@nygren.org> wrote:
=
On Thu, Feb 5, 2015 at 11:28 AM= , Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wr= ote:

Even TLS 1.3 won't encrypt the ALPN (at least as TLS 1.3 current= ly is).


Why can't the server's ALPN= response be in EncryptedExtensions for a TLS 1.3 ServerHello
even if th= e client's ALPN (a superset so less interesting) is in-the-clear in the= ClientHello?

That = is my expectation, since it falls into the category of extensions
"which are not needed to establish = the cryptographic context"

-Ekr
<= div>=C2=A0
= =C2=A0=C2=A0=C2=A0=C2=A0 Erik


--f46d043c7b9e53261a050e602861--