Re: Client-Cert Header draft

Brian Campbell <bcampbell@pingidentity.com> Wed, 20 May 2020 20:08 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 8D6F33A0B04 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 13:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
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 RtlelpAGoRIL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 20 May 2020 13:07:54 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090FB3A0AF8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 20 May 2020 13:07:53 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jbUxb-0005M3-8E for ietf-http-wg-dist@listhub.w3.org; Wed, 20 May 2020 20:05:03 +0000
Resent-Date: Wed, 20 May 2020 20:05:03 +0000
Resent-Message-Id: <E1jbUxb-0005M3-8E@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bcampbell@pingidentity.com>) id 1jbUxZ-0005L9-3Y for ietf-http-wg@listhub.w3.org; Wed, 20 May 2020 20:05:01 +0000
Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <bcampbell@pingidentity.com>) id 1jbUxW-0000u3-UW for ietf-http-wg@w3.org; Wed, 20 May 2020 20:05:00 +0000
Received: by mail-lj1-x234.google.com with SMTP id l15so4988710lje.9 for <ietf-http-wg@w3.org>; Wed, 20 May 2020 13:04:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VjnhD86QVVc2OtY2Ovbi4Mebe7Si8KVOPzngGSdLMTc=; b=HNnZ5VPjMrjxSVvP4LFj0FtUD8drbyqAgnzTRignSWksVgfsmckCQimNl3wzgRqtbP 3S1FCYIeNXLE9QtjThiWl5ZThcgkjouLDk2ToKnzfTSRGJya3H6r/4JRiDbwd78Cwpl/ jOTR3PU7DLOJuHKvv/nOmYNJLCwQtsoSaU1BsYdR9riEbQ9ZmGXGFVWEgy8XLGyuMdvR TkfQYuZoyPhvAx/gLecZQzItpNDEIif9M2r1mpm5al97WC6u92Fwx8JpY6FsE+b3Btdr AZ03oPFpOb87wY5Y1yvBEuFwQbh8BFjF9jxiS89u0GpSMVscN+Bs3xEUjngHG7FWxGyL AysQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VjnhD86QVVc2OtY2Ovbi4Mebe7Si8KVOPzngGSdLMTc=; b=WPyjPBXJ+1QusD1N3ZHu9VOhKX69uzGjai+1+SF5tVxfEKE31yPdEVgw4RrfuA4p0j lUuzl03NvhjSfvgLPiZulH2fWj46g3ob5ZVU2pgSFvUZH8JTwvR2wrYF+azxrFVYOZfM sr56q8+/S+gtaWF3bzBkxe3dmKag/0ZOrdBmvX5jV39kTfgFzYpuwN0klTGm/csL2O57 28dYxTTDkX5st6tMQkfRLYxvF+RLMt6HcntCdfi9ljUH76pWcqsUFeJCbWAlDHOLOwTD EX8V3VGon3DVddWDRtWAyXSaZwPsXntxmHFUV0oGYKaObAr9mr25tO033EGsLC4T8Lvi /SZg==
X-Gm-Message-State: AOAM532eRQ1SsC1kUqmsvNkzHNM3iNTOCbytobIuIfN4Ocs2rpYDCHxI 8yyBBoNoGInaIJbbVAcam4fBVHfdCAYHkK2SK7NxYd1Q/0+yVGXWxLH/QLr0RQtNmz50ruRDWtT /q93iSidnWfIKTXXN0Y8u
X-Google-Smtp-Source: ABdhPJzONF826pcjkqhKlZOm9yBBYHWwXz4G1V+nlta2ahuLkxyIusdfGuF1sKOe1A+nX54ZY3mJNHeRaQf+BbfjJkk=
X-Received: by 2002:a2e:854c:: with SMTP id u12mr1315382ljj.422.1590005086949; Wed, 20 May 2020 13:04:46 -0700 (PDT)
MIME-Version: 1.0
References: <CA+k3eCRQhuS9TyEVdF6ZAfLSyPngjDLvctUTc++2Ok+RJmw0qA@mail.gmail.com> <CH2PR22MB208612E57276557568F843E2DAD90@CH2PR22MB2086.namprd22.prod.outlook.com> <CANatvzzSXfNX0VYrq56YK5vUCQqS3DYN3CvHLPRy-wTXp9QC4Q@mail.gmail.com>
In-Reply-To: <CANatvzzSXfNX0VYrq56YK5vUCQqS3DYN3CvHLPRy-wTXp9QC4Q@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 20 May 2020 14:04:20 -0600
Message-ID: <CA+k3eCQ1kkkUoV01kFARs9O=yH0QjMjTTygjpKpnRW=6DHXxfA@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000006667fd05a619e848"
Received-SPF: pass client-ip=2a00:1450:4864:20::234; envelope-from=bcampbell@pingidentity.com; helo=mail-lj1-x234.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jbUxW-0000u3-UW 4ccf3da4bc8ea919d8e5b572ce66e04e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Client-Cert Header draft
Archived-At: <https://www.w3.org/mid/CA+k3eCQ1kkkUoV01kFARs9O=yH0QjMjTTygjpKpnRW=6DHXxfA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37684
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

It's only anecdotal but in my experience HTTPS is overwhelmingly the lingua
franca used between reverse proxies/edge nodes/TLS terminators/whatever and
the origin servers. So HTTP is the scope of the proposal.

On Tue, May 19, 2020 at 8:11 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

> +1 to what Mike said.
>
> As a side note, per my understanding, the PROXY Protocol [1] supported by
> some TLS terminators has the capability of forwarding client certificates.
> I think using that would be generally preferable to using HTTP header
> fields, because that entire protocol (and therefore existing deployment
> requirements of that protocol) is based on the assumption that it would be
> used only between a trusted TLS terminator and backend servers.
>
> [1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
>
> 2020年4月18日(土) 4:23 Mike Bishop <mbishop@evequefou.be>be>:
>
>> Despite the distaste for client certificates from some quarters, they are
>> still both used and useful.  I’m certainly interested in seeing this
>> progress.
>>
>>
>>
>> In today’s situation, the intermediary checks that the cert matches the
>> rules it has been given to authenticate clients, and only forwards the
>> requests from valid clients.  Arguably, the origin is offloading less trust
>> in this draft’s model – the intermediary is responsible for validating that
>> the client possesses the claimed certificate, but might leave the origin to
>> decide what scope of access the certificate actually grants.  That allows
>> finer-grained access control, but also allows greater ability to send
>> requests back to the origin.  It also opens the door for intermediaries
>> which don’t support this header to accidentally forward requests containing
>> it.  Requiring intermediaries to drop it doesn’t get you much, since only
>> those intermediaries aware of the spec will comply by dropping the header.
>> To help address these, I’d like to see this mix in something that the
>> intermediary holds and the client doesn’t, such as an exporter from its TLS
>> connection to the server.
>>
>>
>>
>> But all that is refinement – the core concept here is beneficial, and I’d
>> like to see more engagement here.
>>
>>
>>
>> *From:* Brian Campbell <bcampbell@pingidentity.com>
>> *Sent:* Wednesday, April 15, 2020 5:01 PM
>> *To:* HTTP Working Group <ietf-http-wg@w3.org>
>> *Subject:* Client-Cert Header draft
>>
>>
>>
>> Hello HTTP Working Group,
>>
>>
>>
>> I've somewhat inadvertently found myself working on this draft
>> https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/,
>> which aspires to define a "Client-Cert" HTTP header field that allows a TLS
>> terminating reverse proxy to convey information about the client
>> certificate of a mutually-authenticated TLS connection to an origin server
>> in a common and predictable manner.
>>
>>
>>
>> I presented the concept
>> <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00>
>> at the recent virtual IETF 107 secdispatch meeting
>> <https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00>
>> and the outcome from that was basically that there seems to be some
>> interest in pursuing the work and the suggestion that the conversation be
>> taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the
>> work progresses). And that's what brings me here. I also hope to get a
>> little bit of time at one of the upcoming virtual interims to
>> present/discuss the draft.
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited..
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>
>
> --
> Kazuho Oku
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._