Re: Client Certificates - re-opening discussion

Mike Belshe <mike@belshe.com> Mon, 21 September 2015 15:26 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF251B3305 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Sep 2015 08:26:40 -0700 (PDT)
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 f3Vxf1AFbR_Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Sep 2015 08:26:36 -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 E26611B3304 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 21 Sep 2015 08:26:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ze2w9-0001lL-HL for ietf-http-wg-dist@listhub.w3.org; Mon, 21 Sep 2015 15:23:25 +0000
Resent-Date: Mon, 21 Sep 2015 15:23:25 +0000
Resent-Message-Id: <E1Ze2w9-0001lL-HL@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 <mike@belshe.com>) id 1Ze2w2-0001kV-SI for ietf-http-wg@listhub.w3.org; Mon, 21 Sep 2015 15:23:18 +0000
Received: from mail-vk0-f48.google.com ([209.85.213.48]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <mike@belshe.com>) id 1Ze2w0-0008CF-1y for ietf-http-wg@w3.org; Mon, 21 Sep 2015 15:23:18 +0000
Received: by vkgd64 with SMTP id d64so67039143vkg.0 for <ietf-http-wg@w3.org>; Mon, 21 Sep 2015 08:22:50 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=pL1ldI4Br6fF4VLWAIRAaHjiU4bYfsfdb+ofXqidbBw=; b=MuQhJLkeVP5VLul54jHVGbScKdClYJYj5vuE8B3uP/uozEFmh7mdOMSdSPn3M3PAmR ZjT8I2p5bz/O3IJn1NLzyfEcX++BX3+x/Q8aVN3voPu9SuTtj+nNOzeHEkvseSHyRXbV hgTOH1IJgr/1pxXgyob03JH19TCZU/2b6+9dftUjmj9lQT8uNwqZPNSfG8jOCFGCuri2 zTSQv6oqLkzv5aIDH95keOd+Cl+p3duGM/qGQoQFinW/mUCddevXKawTn58SScL+PeeJ x2ffs4wD6a6V0ksqIaB1KK2nVfnn7mhplqkrsA3/ts8POE0+yhjLgoGcUxyAWP2iGmU8 OFDg==
X-Gm-Message-State: ALoCoQmPx2zKtkvQnZt7DIvUo4VG3vb6TBUcl3E5T2h9XJ2YRC+ybnFAB+nTJ/pnTy8kEYSvl6RK
MIME-Version: 1.0
X-Received: by 10.31.188.208 with SMTP id m199mr13917828vkf.36.1442848969973; Mon, 21 Sep 2015 08:22:49 -0700 (PDT)
Received: by 10.103.5.132 with HTTP; Mon, 21 Sep 2015 08:22:49 -0700 (PDT)
In-Reply-To: <BN3PR0301MB12490306AD3248F868D8B2B287590@BN3PR0301MB1249.namprd03.prod.outlook.com>
References: <63DECDF0-AB59-4AFD-8E48-8C2526FD6047@mnot.net> <42DDF1C6-F516-4F71-BAE0-C801AD13AA01@co-operating.systems> <2F3BD1CB-042D-48AB-8046-BB8506B8E035@mnot.net> <CABaLYCtZ_EAGKaW0ydcYoKSJjyv6=YXdLrry2LQyVTzcC_qt_w@mail.gmail.com> <BN3PR0301MB12490306AD3248F868D8B2B287590@BN3PR0301MB1249.namprd03.prod.outlook.com>
Date: Mon, 21 Sep 2015 08:22:49 -0700
Message-ID: <CABaLYCs7qM92GNMrfHUG+e4eWv8H-Hhk6oYv3cBFnsDSP=DFRQ@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>, Henry Story <henry.story@co-operating.systems>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a1142f7ec51fabc05204374e7"
Received-SPF: none client-ip=209.85.213.48; envelope-from=mike@belshe.com; helo=mail-vk0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: AWL=-1.137, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1Ze2w0-0008CF-1y af7390f3a9ad2fcdbf51e30d01b3c107
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <http://www.w3.org/mid/CABaLYCs7qM92GNMrfHUG+e4eWv8H-Hhk6oYv3cBFnsDSP=DFRQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30248
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 Fri, Sep 18, 2015 at 11:31 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> We have historically had cases where customers were either legally
> mandated to use client certificate authentication specifically, or more
> generally had an IT requirement to use two-factor authentication to access
> enterprise resources.  I’ll research the details of some of these, and see
> whether I can share some details to frame this conversation in Yokohama.
> Internally, we use it regularly – the certificate lives on a smartcard, the
> TPM, or was simply issued to the machine when it enrolled for device
> management.
>
>
>
> For us, at least, the “pain” is that we can’t support a legal requirement
> without falling back to HTTP/1.1 and generating even more round-trips.  Our
> HTTP/2 investments don’t apply as soon as we’re talking to the auth server.
>

Thanks, this sounds about right.  The usability of browser-based
client-auth was so awful, that unless "mandated" by some law, no real user
or website would use it :-)  If anyone on this thread hasn't tried client
auth, you should, and then imagine turning that on for any real website.

I hope the legal requirement doesn't require that client auth be done in
the HTTP protocol layer, just that the certificate based auth be done.  My
own opinion is that HTTP/1.1/TLS's client auth was a mistake, and my
evidence is the usability of both client-auth and basic-auth authentication
schemes at the protocol layer.  Neither is used in significant amounts.
The latter was definitely moved by millions of websites into the
application layer, and I see no reason why browsers shouldn't offer support
for client-auth like primitives which will help customers move
certificate-based client auth up a level too.

Given the flexibility of HTTP2s framing layer, it will be tricky to avoid
major security bugs in HTTP2 if we try to enable client-auth at the session
below the framing.

Mike





>
>
> *From:* Mike Belshe [mailto:mike@belshe.com]
> *Sent:* Friday, September 18, 2015 11:20 AM
> *To:* Mark Nottingham <mnot@mnot.net>
> *Cc:* Henry Story <henry.story@co-operating.systems>; HTTP Working Group <
> ietf-http-wg@w3.org>
> *Subject:* Re: Client Certificates - re-opening discussion
>
>
>
> In a strange twist of fate I find myself doing a lot of PKI work these
> days, and I've considered a fair bit about how client-certs might help with
> some of my application-level needs.
>
>
>
> However, just like HTTP's basic-auth, I wonder HTTP or TLS level
> client-certs will just never be used?  My concern, of course, is that we
> build something that has a user experience similar to HTTP's basic-auth.
> It's so bad that nobody can use it and authentication gets pulled into web
> pages (where ironically, it is less secure!).
>
>
>
> Mark - you said there is "pain".  Is there a set of use cases to be solved
> here?  Let me know if I missed them - I may be able to contribute.
>
>
>
> My suspicion is that we really need crypto features moved up a level from
> the protocol, as it will be very difficult to make satisfactory user
> interfaces from the protocol level alone.  Perhaps for machine-to-machine
> auth it would be okay.
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Sep 18, 2015 at 10:05 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
> Hi Henry,
>
> Thanks, but this is a much more narrowly-scoped discussion -- how to make
> client certs as they currently operate work in HTTP/2. At most, I think
> we'd be talking about incrementally improving client certs (e.g.,
> clarifying / optimising the scope of their applicability -- and that really
> just is an example, not a statement of intent).
>
> Cheers,
>
>
> > On 18 Sep 2015, at 11:53 am, Henry Story <
> henry.story@co-operating.systems> wrote:
> >
> >
> >> On 17 Sep 2015, at 23:10, Mark Nottingham <mnot@mnot.net> wrote:
> >>
>
> >> Hi,
> >>
> >> We've talked about client certificates in HTTP/2 (and elsewhere) for a
> while, but the discussion has stalled.
> >>
> >> I've heard from numerous places that this is causing Pain. So, I'd like
> to devote a chunk of our time in Yokohama to discussing this.
> >>
> >> If you have a proposal or thoughts that might become a proposal in this
> area, please brush it off and be prepared. Of course, we can discuss
> on-list in the meantime.
> >>
> >> Cheers,
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >
> >
>
> > Apart from the proposals as the proposal by Martin Thomson
> > and the follow up work  referenced earlier in this thread
> > by Mike Bishop [1], I'd like to mention more HTTP centric
> > prototypes which would rely perhaps not so much on certificates,
> > but on linked public keys, that build on existing HTTP
> > mechanisms such as WWW-Authenticate, which if they pass security
> > scrutiny would fit nicely it seems to me with HTTP/2.0 .
> >
> > • Andrei Sambra's first sketch authentication protocol
> >   https://github.com/solid/solid-spec#webid-rsa
> >
> > • Manu Sporny's more fully fleshed out HTTP Message signature
> >   https://tools.ietf.org/html/draft-cavage-http-signatures-04
> >
> > These and the more TLS centric protocols require the user
> > agent to be able to use public/private keys generated by
> > the agent, and signed  or published by that origin, to
> > authenticate or sign documents across origins.
> >
> > This is where one often runs into the Same Origin Policy (SOP)
> > stone wall. There was an important discussion on
> > public-webappsec@w3.org [1] and public-web-security@w3.org
> > entitled
> >
> >   "A Somewhat Critical View of SOP (Same Origin Policy)" [2]
> >
> > that I think has helped clarify the distinction between Same Origin
> > Policy, Linkability, Privacy and User Control, and which I hope
> > has helped show that this policy cannot be applied without
> > care nor can it apply everywhere.
> >
> > The arguments developed there should be helpful in opening discussion
> > here and elswhere too I think. In a couple of e-mails  in that
> > thread, I went into great detail showing how SOP, linkability and User
> > Control and privacy apply in very different ways to 4 technologies:
> > Cookies, FIDO, JS Crypto API and client certificates [3]. This shows
> > that the concepts don't overlap, two being technical and the two
> > legal/philosophical, each technology enabling some aspect of the
> > other, and not always the way one would expect.
> >
> > Having made those conceptual distinctions I think the path to
> > acceptance of solutions proposed by this group will be much eased.
> >
> > Looking forward to following and testing work developed here,
> >
> > All the best,
> >
> >       Henry
> >
> >
> > [1] • starting:
> https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html
> >    • most recent by Mike Bishop
> >
> https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0310.html
> > [2] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/
> > [3]
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html
> >  which is in part summarised with respect to FIDO in a much shorter
> >  email
> >
> https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0119.html
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>