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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 24 July 2016 11:23 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 ADFE212B043 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 24 Jul 2016 04:23:30 -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 1bN9nDbdCe8t for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 24 Jul 2016 04:23:29 -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 3C32E12D739 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 24 Jul 2016 04:23:29 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bRHR7-0006qr-Bo for ietf-http-wg-dist@listhub.w3.org; Sun, 24 Jul 2016 11:19:09 +0000
Resent-Date: Sun, 24 Jul 2016 11:19:09 +0000
Resent-Message-Id: <E1bRHR7-0006qr-Bo@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ilariliusvaara@welho.com>) id 1bRHR2-0006pn-Pg for ietf-http-wg@listhub.w3.org; Sun, 24 Jul 2016 11:19:04 +0000
Received: from welho-filter2.welho.com ([83.102.41.24]) by lisa.w3.org with esmtp (Exim 4.80) (envelope-from <ilariliusvaara@welho.com>) id 1bRHR1-0007Xh-9r for ietf-http-wg@w3.org; Sun, 24 Jul 2016 11:19:04 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E1B1723DE; Sun, 24 Jul 2016 14:18:35 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id S_ozJykVatk5; Sun, 24 Jul 2016 14:18:35 +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 6BEFD285; Sun, 24 Jul 2016 14:18:35 +0300 (EEST)
Date: Sun, 24 Jul 2016 14:18:30 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20160724111830.GB576@LK-Perkele-V2.elisa-laajakaista.fi>
References: <F9D2CFF3-57C2-41BD-ACB1-FA6C991458D7@mnot.net> <CABcZeBPTYgcfecKErhacR=jfXkoRPESgUQ=1pzPEWg092fqZvw@mail.gmail.com> <20160724103435.GA576@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnX_0YC5-=EbZfU0XGtXeGvE7GH+5K75PW+FMsRsEOj23Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnX_0YC5-=EbZfU0XGtXeGvE7GH+5K75PW+FMsRsEOj23Q@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Received-SPF: none client-ip=83.102.41.24; envelope-from=ilariliusvaara@welho.com; helo=welho-filter2.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: lisa.w3.org 1bRHR1-0007Xh-9r 291217f8953fefb01a7fdd0ab5119372
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/20160724111830.GB576@LK-Perkele-V2.elisa-laajakaista.fi>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32044
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 Sun, Jul 24, 2016 at 12:56:31PM +0200, Martin Thomson wrote:
> On 24 July 2016 at 12:34, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > 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.
> 
> My understanding of SIGMA is that the MAC needs to cover the identity
> and other properties, but the signature only has to cover the key
> shares (or shared key).  Thankfully we don't need to worry about that
> distinction because of the way that TLS 1.3 and EMS cause everything
> to depend on everything else: keys depend on identity and negotiation
> parameters as much as the MAC does.

I thought the easiest way is to multi-tap hashes (in the same style
TLS 1.3 does), which impiles that the both cover the same things
(modulo MAC also covering the signature)...

And if MAC needs to cover the "implicit" properties, it means you
need to be able to include those into computations.

> Either way, I am increasingly of the opinion that we should ask for
> this facility from the TLS working group.  There are subtleties to
> this that are easy to get wrong and good analysis is crucial.

I think before that, one should plan the interface to HTTP/2 and
some rough ideas for what information is passed.

E.g.
- Are the requests transferred as header blocks or binary blobs
  (I presume responses are binary blobs)?
- At least which parameters are present for each request?
- What of above parameters are shared over multiple requests?
- How many flights are allowable (I presume 1 request + 1 response,
  but this should be explicit)?
- If typed auxillary data (e.g. OCSP staple or SCT staple) can be
  passed back or not?

This is to know what to request, so one avoids nasty surprises
of having hard time figuring out how to pluck the result into
HTTP/2.


And I think certificate use control should be separate mechanism,
operating over proven certificates in client->server direction.


-Ilari