Re: draft-thomson-httpbis-cant
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 22 October 2014 16:10 UTC
Return-Path: <ietf-http-wg-request@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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BF71ACD6B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 22 Oct 2014 09:10:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level:
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, 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 0v5pSEWOeTKm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 22 Oct 2014 09:10:46 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D60F1AC417 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 22 Oct 2014 09:10:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XgySQ-0007ji-Mz for ietf-http-wg-dist@listhub.w3.org; Wed, 22 Oct 2014 16:08:18 +0000
Resent-Date: Wed, 22 Oct 2014 16:08:18 +0000
Resent-Message-Id: <E1XgySQ-0007ji-Mz@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1XgySJ-0007j2-LQ for ietf-http-wg@listhub.w3.org; Wed, 22 Oct 2014 16:08:11 +0000
Received: from [134.226.56.6] (helo=mercury.scss.tcd.ie) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1XgySF-0006HX-CX for ietf-http-wg@w3.org; Wed, 22 Oct 2014 16:08:11 +0000
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D5FCBBDFD; Wed, 22 Oct 2014 17:07:34 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsGNWhi0uteU; Wed, 22 Oct 2014 17:07:33 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.41.59.37]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EE319BDFC; Wed, 22 Oct 2014 17:07:32 +0100 (IST)
Message-ID: <5447D644.3050709@cs.tcd.ie>
Date: Wed, 22 Oct 2014 17:07:32 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
CC: Martin Thomson <martin.thomson@gmail.com>, ietf-http-wg@w3.org
References: <5447BAE5.2040104@cs.tcd.ie> <20141022145239.GA21530@LK-Perkele-VII>
In-Reply-To: <20141022145239.GA21530@LK-Perkele-VII>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=134.226.56.6; envelope-from=stephen.farrell@cs.tcd.ie; helo=mercury.scss.tcd.ie
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: AWL=-3.832, RDNS_NONE=1.274
X-W3C-Scan-Sig: lisa.w3.org 1XgySF-0006HX-CX a1cb465386dd0ba3f784887a79af2769
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-thomson-httpbis-cant
Archived-At: <http://www.w3.org/mid/5447D644.3050709@cs.tcd.ie>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/27687
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 22/10/14 15:52, Ilari Liusvaara wrote: > On Wed, Oct 22, 2014 at 03:10:45PM +0100, Stephen Farrell wrote: >> >> First off, I like the idea - the more ways in which we >> can try push passwords a bit further off stage the better. >> So I hope this is taken up somewhere and progressed and >> gets deployed. >> >> That said: >> >> - section 2: I don't like the auth scheme name - this >> should work without X.509. I'd suggest "TLSClientAuth" >> would be a better thing to use. > > Looks like the name is "ClientCertificate" (the first > paragraph) Yup. I'm suggesting a change. Which as Martin noted might amount to a different scope. > >> - 3.1: I assume this is solely for backwards compat? >> If not they who do we expect to use this? If so, >> please say so and encourage use of (hashes of) keys >> or certs instead. > > It is not for backwards compatiblity. TLS 1.0-1.2 > have the equivalent field. TLS 1.3 probably not. > > And besides, having it available at HTTP level saves > a handshake attempt to obtain the list of acceptable > CAs. But turns out that (the acceptable CA list) doesn't work well except in enterprise cases, in which case it's probably a no-brainer anwyay. > >> - 3.1: You should probably profile X.500 names for >> use here - requiring the full complexity of X.500 >> (e.g. it allows for X.400 ORAddress as an option) >> would seem like a bad idea. Not sure where you could >> find that already done by someone else but it ought >> be somewhere (maybe some ldap thing?). > > The matching looks the simplest possible: Raw opaque > binary blob (to be compared using memcmp()) Base64url > encoded. Matching isn't the problem here, but rather en/de-coding and presentation. Its worth being less flexible than is allowed by X.500 names. > >> - 3.2: Someone needs to do a compare/contrast against >> websec's key pinning but also DANE and JOSE for this >> bit. Not sure its quite right now. > > - This uses existing registry of hashes, whereas > HPKP defines just SHA-256, DANE has its own set > in registry and I think JOSE just defines SHA-1 > and SHA-256. > - Websec and JOSE pinning pins just keys inside > certificates, whereas this pins whole certificates. > DANE can pin either keys or whole certificate. Right. There're a few things to check is the point and a few nearly-trivially different choices to make. > >> - 3.2: You need to add support for hash(public-key) >> which could be done like DANE or even via RFC6920 >> URIs if that made sense (no idea, so don't take this >> as me pushing an RFC I co-authored:-). That's needed >> for bare-keys TLS anyway, and is just a good plan (tm). > > I read the section that if the certificate is RPK, > then the hash matches the RPK. > > (Of course, this runs into trouble with identification). Maybe just more clarity is all that's needed then. And its easily fixed regardless. > >> - somewhere: why not have a KeyIDType somewhere here >> where the client/server can signal what kind(s) of >> key identifiers (or containers) are being, or to be, >> used. Probably something that maps to an existing >> TLS construct. Who knows maybe someday someone will >> come up with a privacy-friendly way to identify >> public keys that'd even help with this in TLS1.2 and >> earlier? So having that here would be a good plan >> I think. > > Identifying the public key itself runs into trouble > with identification. > > If one does not use X509, one would presumably need > some sort of tag to identify public key (and actually > with X509, the CA can be such tag, since there is > no requirement for the client to trust the CA). I'm suggesting to use whatever TLS uses to identify the public key id/container. Again, not a huge deal. > >> - Its not clear to me how or if this ought be bound >> to the TLS session. I think that'd be a good thing >> to ponder, but I've not:-) OTOH, it'd be a pain to >> define this but also have it work via e.g. a TLS >> MITM as that would utterly make it meaningless as a >> strong client authentication scheme. Not sure what's >> doable there but maybe the UA could send an Authorization >> header field based on the challenge and a TLS extractor >> (RFC5704) value and its public key as at least an >> option that'd detect MITMs or maybe some other forms >> of attack. > > It will be a new TLS session. Sure. Still worth figuring out though. >> - I'm sure you'll need changes to keep the http >> auth scheme police happy:-) [1] seems to have now >> achieved that status so copying from there may help. >> >> S. >> >> [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba > > > Another thing that isn't clear: The spec says that the > scheme can't be used with http://. What about HTTP/2 > oppsec http://? If not via proxy, there is presumably > direct connection, suitable for using TLS client certificates. Good point. I agree that needs to be figured out and that there're a few possible sensible answers that could be offered. S. > > > -Ilari >
- draft-thomson-httpbis-cant Stephen Farrell
- Re: draft-thomson-httpbis-cant Ilari Liusvaara
- Re: draft-thomson-httpbis-cant Martin Thomson
- Re: draft-thomson-httpbis-cant Stephen Farrell
- Re: draft-thomson-httpbis-cant Stephen Farrell
- Re: draft-thomson-httpbis-cant Martin Thomson