Re: Client-Cert Header draft

David Benjamin <> Fri, 17 April 2020 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4A3F3A0743 for <>; Fri, 17 Apr 2020 14:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gXtNo8cp82VV for <>; Fri, 17 Apr 2020 14:14:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C50693A0776 for <>; Fri, 17 Apr 2020 14:14:09 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jPYHe-0004yB-Ql for; Fri, 17 Apr 2020 21:12:22 +0000
Resent-Date: Fri, 17 Apr 2020 21:12:22 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jPYHc-0004xM-4y for; Fri, 17 Apr 2020 21:12:20 +0000
Received: from ([2607:f8b0:4864:20::62e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jPYHX-0006yb-Ff for; Fri, 17 Apr 2020 21:12:19 +0000
Received: by with SMTP id z6so1394847plk.10 for <>; Fri, 17 Apr 2020 14:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NpooTyy360reSIIMC6yhAN7AKX/uHGrnU5h9zd4+5Ak=; b=dQe2tkknOa0Cf0mlmHc3nGzxKai7FI8VKqRTgy4gH6KobaDLymYtRhOTwIhsLqdhEL RpHMC9zBarXK6lazTyzBrrarzTyDNb5hhaD1/28yCWmWFuia+keIe6DB1m3pRsfPe56e cE8GCIDREdI7DtHnogNsx2T8kLQ83+M7Nlyk0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NpooTyy360reSIIMC6yhAN7AKX/uHGrnU5h9zd4+5Ak=; b=rb1tFwjv4O4fe+MwNTj7B3RQB46zKvcn3Bw1k34g5ap4kaNaR0H4bNt9hhIARlIQsK HM728xPmWPxJkr1LyArVFlvPYewmA9dxJQIApuOR0GpoJscaUZF+JkRL7YmXgh5v9L3z sTFfyRPpsxLmFgnNr63VDHK7kb2V4fNP/pGnbnz+g2AtF0e62b/m7yN6tBKhHyYYWXE3 0wxVZ660+TtnCgkVunZDMmhC0QUW9e3GIiwARrC3dK9t0qyCzCC1rqn137okWxZxkIX3 KGYPJ29zNoijO1n/Fux39e9Iqk3bkshFkz86asz5vbP+vQ2RGiK3RB1qLGQO2bFfNUqq ebeg==
X-Gm-Message-State: AGi0PuaWaZRrCa1wzP8/lSyO2x6r2+7794V3x/JUVm7YTv+hjmXPLDzY 5JulbJim5SMNGUpIpmhrL1P+ZviblN0B34Rg8jRT
X-Google-Smtp-Source: APiQypIabloTbFhm168WkoPY7c9/724sKWGsOtve6n28l82a1w/OSqBj8c71GoAW7gOvTFXW9qXIrTr+YP0jZ8Us8Wc=
X-Received: by 2002:a17:90a:7d16:: with SMTP id g22mr6718657pjl.179.1587157923230; Fri, 17 Apr 2020 14:12:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 17 Apr 2020 17:11:46 -0400
Message-ID: <>
To: Lucas Pardue <>
Cc: Mike Bishop <>, Brian Campbell <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000037f53105a3830046"
Received-SPF: pass client-ip=2607:f8b0:4864:20::62e;;
X-W3C-Hub-Spam-Status: No, score=-11.2
X-W3C-Scan-Sig: 1jPYHX-0006yb-Ff b8142c1afbce425ca11d4dcd87ab2020
Subject: Re: Client-Cert Header draft
Archived-At: <>
X-Mailing-List: <> archive/latest/37516
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

This draft isn't sufficient to properly move the access checks out of the
TLS terminator. More care is needed here. There is a "distaste for client
certificates from some quarters" for a reason.

In general, connection-level authentication does not play well with HTTP.
Server identities are generally public, so there is no complex policy
around when to release them. Client identities are generally user
identities and thus sensitive, with local policies, usually involving user
prompts and selections. That interacts badly with client certificates. It
just barely works today, but moving individual components without thought
as to the overall picture will break it.

In particular, client HTTP stacks necessarily cache client certificate
decisions. Without caching, the user is potentially prompted on every HTTP
request, but a user session involves many HTTP requests. Additionally, the
decision is inherently cached by way of connection reuse and session
resumption optimizations. Short of forcing a full TLS handshake on every
HTTP request, clients could not prompt on every HTTP request if they wanted
to. That means the HTTP stacks need an explicit signal, or no amount of
reloads will allow the user to select a different identity.

Currently, the only signal for a bad client certificate is a fatal TLS
alert. If the access checks are moved, bad client certificate signals will
come out of the origin server, which cannot generate those. This draft may
need to define a suitable HTTP 4xx code to correspond with TLS client
certificate authentication. Of course, existing clients won't know to
process that, but perhaps the origin server should translate to a TLS
alert? But then the response is never delivered, which may be differently
odd. Then one must consider the interaction with HTTP/2, which multiplexes
streams and potentially multiple origins together.

There may be further problems here that I haven't thought through. The
suggestion of this enabling finer-grained access control worries me.

On Fri, Apr 17, 2020 at 3:29 PM Lucas Pardue <>

> +1 to everything Mike said
> On Fri, 17 Apr 2020, 20:24 Mike Bishop, <> wrote:
>> 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 <>
>> *Sent:* Wednesday, April 15, 2020 5:01 PM
>> *To:* HTTP Working Group <>
>> *Subject:* Client-Cert Header draft
>> Hello HTTP Working Group,
>> I've somewhat inadvertently found myself working on this draft
>> 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
>> <>
>> at the recent virtual IETF 107 secdispatch meeting
>> <>
>> 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.*