Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 24 July 2016 10:39 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC112D854 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 24 Jul 2016 03:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level:
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 bS0v9FiifwfU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 24 Jul 2016 03:39:23 -0700 (PDT)
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 68F6812D848 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 24 Jul 2016 03:39:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bRGkf-00077b-1l for ietf-http-wg-dist@listhub.w3.org; Sun, 24 Jul 2016 10:35:17 +0000
Resent-Date: Sun, 24 Jul 2016 10:35:17 +0000
Resent-Message-Id: <E1bRGkf-00077b-1l@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ilariliusvaara@welho.com>) id 1bRGkZ-00076k-44 for ietf-http-wg@listhub.w3.org; Sun, 24 Jul 2016 10:35:11 +0000
Received: from welho-filter3.welho.com ([83.102.41.25]) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <ilariliusvaara@welho.com>) id 1bRGkW-0004DW-TM for ietf-http-wg@w3.org; Sun, 24 Jul 2016 10:35:10 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D2D3118B8; Sun, 24 Jul 2016 13:34:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id PBAuEJLKnJRb; Sun, 24 Jul 2016 13:34:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 534A921C; Sun, 24 Jul 2016 13:34:40 +0300 (EEST)
Date: Sun, 24 Jul 2016 13:34:35 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20160724103435.GA576@LK-Perkele-V2.elisa-laajakaista.fi>
References: <F9D2CFF3-57C2-41BD-ACB1-FA6C991458D7@mnot.net> <CABcZeBPTYgcfecKErhacR=jfXkoRPESgUQ=1pzPEWg092fqZvw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPTYgcfecKErhacR=jfXkoRPESgUQ=1pzPEWg092fqZvw@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Received-SPF: none client-ip=83.102.41.25; envelope-from=ilariliusvaara@welho.com; helo=welho-filter3.welho.com
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=-0.857, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bRGkW-0004DW-TM 94c07942471f4962abffaba2b1a58d12
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2
Archived-At: <http://www.w3.org/mid/20160724103435.GA576@LK-Perkele-V2.elisa-laajakaista.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32042
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Mon, Jul 04, 2016 at 03:48:24PM -0700, Eric Rescorla wrote:
> Document: draft-bishop-httpbis-http2-additional-certs-01
> 
> In each of these cases, it seems like there are two phases:
> 
> 1. The relying party indicates the identity it would like the
>    peer to authenticate for.
> 2. The authenticating party supplies a certificate and proves
>    possession of the private key corresponding to the certificate.
> 
> The second of these seems pretty similar for both use cases, but the
> first actually is rather different and seems rather shoe-horned in in
> an attempt to make it symmetrical. I would suggest instead that we
> provide different mechanisms for the "certificate request" phase that
> more closely track the TLS 1.3 mechanisms. Specifically:

Or if one wanted to really hack things, one could put the server
name in client request as certificate extension of SubjectAlternativeName
type.
 
> - When requesting that the server authenticate for a new origin,
>   the client should supply a new domain name.
> - When requesting that the client authenticate for a new certificate
>   the server should supply a CertificateRequest which indicates
>   detailed certificate properties (this is more or less what the
>   draft does).
> 
> I think that this would be clearer and provide a better match for the
> use case.

I think one needs to also sign and MAC over any implicit parameters
that are shared over multiple authentications. E.g. Supported end-
certificate signature algorithms.
 
> I'd also like to understand the relationship of this mechanism
> with TOKBIND, as it seems that it has extremely similar properties,
> albeit being restricted to H2.

Not really:

TOKBIND is intended to restrict usage of cookies and other similar
resources. It is not intended to convey any sort of authority, and
using it for that purpose is highly dangerous. Whereas this mechanism
is explicitly to convey authority.

> DETAILED COMMENTS
> S 1.1.
> I'm a bit skeptical of this encrypted SNI use case, though I suppose
> it might work in some settings. As DKG has suggested, there are applications
> of encrypted SNI where you want the gateway not to be able to see the
> plaintext.

My understanding is that "encrypted SNI" usecase is that here it is
intededed to be used when both the "real" resources and "decoy"
resources are hosted on the same server.

One could do "gateway" already (albeit at cost of double encryption
as is fundamental to riding on top of TLS) using CONNECT (at least
for low-level implementation).


> S 2.
> This AUTOMATIC_USE thing seems very dangerous, as indicated in S 5.  I
> would suggest instead that servers always have this semantic (you
> require this anyway in S 3.5) and that clients never have this
> semantic. In addition, I would forbid ambient authentication with
> any certificate (including one established at the TLS layer) once
> the client has authenticated with a certificate at the HTTP layer,
> and reserve some indicator for the certificates established in TLS.

Or better yet, subject any TLS certs to same control mechanism once
flag indicating support for this is flipped.
 
Such control mechanism is needed for client side anyway. I'm not sure
it is needed for server side, since server always designates its
authority.

 
> S 3.3.
> It's pretty odd that you allow servers to take a position on which
> extensions should be in certs but not on what signature algorithms
> should be used to sign them. Also, as noted above, all the fields here
> are useless in the server->client authentication case (it's not like
> you're going to provide the whole trust anchor list). You should
> use a different format here for server and client, because most of
> the signaling here in client->server is cruft.

If one wanted symmetry, having empty trust anchor list (which means
"implicit") wouldn't be that bad. Yeah, the whole browser list is far
too big to send.
 
> What is a peer supposed to do if it receies a request that it
> thinks it has already satisfied (e.g., a duplicate SAN?).

I think signaling no certificate would be reasonable.

However, if done that way, one has to be careful to explicitly
specify how certificate sets behave on resumption (e.g. clear all).

> S 3.5.
> Signing the same value with every CERTIFICATE_PROOF seems like it's
> really living on the edge. Minimally, it seems like you have a
> reflection attack where the client is able to replay the server's
> CERTIFICATE_PROOF back to it. I would recommend that:
> 
> - You sign over the certificate and the RequestID (I don't have a
>   concrete attack but it just seems like an abundance of caution).
>   You could just stuff it in the context parameter.
> - Have the client and server exporters be different to avoid reflection.
> - Also, nothing wrong with 64 bytes, but it seems a bit long, no?

I thought client and server already use different contexts to prevent
reflection (but maybe not, I think they should)?

RequestID/Context could be a counter?

> S 6.1.
> A two byte bitfield indicating which algorithms you support seems
> like premature optimization. It's easy to see how this gets to be
> half-full, just with algorithms that we know of today (4Q, digest
> signatures, some sort of lattice-based post-quantum thing). I would
> think at least 32-bit field would be wise.

Also note that if you have fields like this, I think you would need to
sign and MAC over their values, even if not actually part of every
request.
 

Also, I got an idea of sending the certificate on non-0 stream,
opened for the purpose. However, this might hit nasty implementability
problems (the original HTTP/2 spec is not careful with schemes, e.g.
doesn't require stream error on unknown scheme) and also could possibly
cause deadlocks. At least one could send clear stream errors, and not
mess with frame types.



-Ilari