Resent-Date: Fri, 06 Feb 2015 21:35:50 +0000
Resent-Message-Id: <E1YJqZ4-0003Tl-EW@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <20150206081033.GA23827@LK-Perkele-VII>
References: <CAKC-DJhOm-4AqfvsdvTL1NBn1kauTBcsah8MBhushsS=5Ods=A@mail.gmail.com>
 <20150205162845.GA13872@LK-Perkele-VII>
 <CAKC-DJjArVEBCEeY47mKYceP5Lt+RThbKWwp7_WZCOmsoXWbag@mail.gmail.com>
 <20150206081033.GA23827@LK-Perkele-VII>
Date: Sat, 7 Feb 2015 08:35:17 +1100
Message-ID: <CABkgnnXYcPs4bP6N4hO4kTHpskLkaOcV5xXZD=Je62FsyDs-gg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Erik Nygren <erik@nygren.org>
Content-Type: multipart/alternative; boundary=e89a8fb1f3385f5d58050e7232bf
Received-SPF: pass client-ip=209.85.218.41;
 envelope-from=martin.thomson@gmail.com; helo=mail-oi0-f41.google.com
Subject: Re: http2 opportunistic security negotiation
Archived-At: <http://www.w3.org/mid/CABkgnnXYcPs4bP6N4hO4kTHpskLkaOcV5xXZD=Je62FsyDs-gg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--e89a8fb1f3385f5d58050e7232bf
Content-Type: text/plain; charset=UTF-8

I wouldn't assume to know with 100% confidence what any given client will
accept.
On Feb 6, 2015 7:16 PM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>
wrote:

> On Thu, Feb 05, 2015 at 05:21:26PM -0500, 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?
>
> Ah yeah, Server's ALPN. Client's ALPN would be always constant per client.
>
>
> Also, it occurs to me that if one can tell from certificate if it is
> supposed to be valid or not, the ALPN leak does not add much:
>
> - On TLS 1.2, one can inspect certificate of connection before deciding
>   to MITM or not (since nothing before it has any commitments).
> - In TLS 1.3, where that isn't possible (there are commitments from
>   both sides before), one can still connect to the server and probe
>   the certificate.
>
>
> Then there are some servers where getting good certificate is
> much less of a problem than dealing with the https:// scheme
> (due to legacy internal baggage).
>
>
> -Ilari
>
>

--e89a8fb1f3385f5d58050e7232bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I wouldn&#39;t assume to know with 100% confidence what any =
given client will accept.</p>
<div class=3D"gmail_quote">On Feb 6, 2015 7:16 PM, &quot;Ilari Liusvaara&qu=
ot; &lt;<a href=3D"mailto:ilari.liusvaara@elisanet.fi">ilari.liusvaara@elis=
anet.fi</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">On Thu, Feb 05, 2015 at 05:21:26PM -0500, Erik Nygren wrote:<br>
&gt; On Thu, Feb 5, 2015 at 11:28 AM, Ilari Liusvaara &lt;<br>
&gt; <a href=3D"mailto:ilari.liusvaara@elisanet.fi">ilari.liusvaara@elisane=
t.fi</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Even TLS 1.3 won&#39;t encrypt the ALPN (at least as TLS 1.3 curr=
ently is).<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Why can&#39;t the server&#39;s ALPN response be in EncryptedExtensions=
 for a TLS<br>
&gt; 1.3 ServerHello<br>
&gt; even if the client&#39;s ALPN (a superset so less interesting) is in-t=
he-clear<br>
&gt; in the ClientHello?<br>
<br>
Ah yeah, Server&#39;s ALPN. Client&#39;s ALPN would be always constant per =
client.<br>
<br>
<br>
Also, it occurs to me that if one can tell from certificate if it is<br>
supposed to be valid or not, the ALPN leak does not add much:<br>
<br>
- On TLS 1.2, one can inspect certificate of connection before deciding<br>
=C2=A0 to MITM or not (since nothing before it has any commitments).<br>
- In TLS 1.3, where that isn&#39;t possible (there are commitments from<br>
=C2=A0 both sides before), one can still connect to the server and probe<br=
>
=C2=A0 the certificate.<br>
<br>
<br>
Then there are some servers where getting good certificate is<br>
much less of a problem than dealing with the https:// scheme<br>
(due to legacy internal baggage).<br>
<br>
<br>
-Ilari<br>
<br>
</blockquote></div>

--e89a8fb1f3385f5d58050e7232bf--