Re: Client-Cert Header draft

David Benjamin <> Tue, 21 April 2020 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CB0F3A0943 for <>; Tue, 21 Apr 2020 13:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 5pqmjdl2f16A for <>; Tue, 21 Apr 2020 13:17:09 -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 522783A0942 for <>; Tue, 21 Apr 2020 13:17:09 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jQzHG-00035C-KS for; Tue, 21 Apr 2020 20:13:54 +0000
Resent-Date: Tue, 21 Apr 2020 20:13:54 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jQzHF-00034M-7T for; Tue, 21 Apr 2020 20:13:53 +0000
Received: from ([2607:f8b0:4864:20::102e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jQzHC-0000Ok-OG for; Tue, 21 Apr 2020 20:13:53 +0000
Received: by with SMTP id a5so1082914pjh.2 for <>; Tue, 21 Apr 2020 13:13:50 -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=9SObCLXHrGUBwhG2UoHnh1QEUmc6NlexJULWqbVzeZE=; b=YPxNdvLIXxifwq3CzYM3ZONlC+rJGwMedbC6EygZf18/zFeyCa/cjjzghQmFIXHRTq jPx3Mc8RKr3tomaxVLLL/8foLTMNct0/p8opNb6nFVpiut6q/wKhZdGHr4oBa/9O0gsi 6D6IPTzBrSXHOFgOD7j3inR315Lar8ZqfIshs=
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=9SObCLXHrGUBwhG2UoHnh1QEUmc6NlexJULWqbVzeZE=; b=OgWU4Z4FvNO9EMXliOr91PsJwHFssS8BzAnbBeU0z4IAkjb4JXjws6AjV9ylfe3rb1 wULhWLk+ihEZjTPI+0coX+fnStFjr2XiibgpazUbHM8kAcRtyWggieK9LrLiXH/S3BL7 N8fg5fddeAcYB104kKHNkhkmvLD9FRl42ExgBgPnLoLGjT9yRgN3IYoPGChQoad7KSU1 83i+eLtIaDZMgJH9e77NJxphOmJ/TCVP0oiFV8ff7wiHxeBvy2ZGOHxJ2lmPYHpqtHxr U+Z9UZJGK+KxIUhJGljzolZqAaUiERJ50BGng5YnJfK47kFjsNw5rEXma5oI8CI0CFC8 PW8A==
X-Gm-Message-State: AGi0Pub04KfCOoTpo0AWl/W1nWI9Bk7aZ8yuY1uzsOfOFRgYdZN9jb9H kEghvt6wrbsB7bqQVS7i3QN+wGru2zU7gNAVZoBK
X-Google-Smtp-Source: APiQypLMRDAAQDJeue7TWCbASQ+iwnsteXNvVoAxC6fsljwK1ZorPHB+ju3luN1zI2Y00OEx70Fpeaud4vIKczs8cHo=
X-Received: by 2002:a17:902:b187:: with SMTP id s7mr24480649plr.0.1587500019042; Tue, 21 Apr 2020 13:13:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 21 Apr 2020 16:13:22 -0400
Message-ID: <>
To: Brian Campbell <>
Cc: Lucas Pardue <>, Mike Bishop <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000b7c04405a3d2a608"
Received-SPF: pass client-ip=2607:f8b0:4864:20::102e;;
X-W3C-Hub-Spam-Status: No, score=-11.2
X-W3C-Scan-Sig: 1jQzHC-0000Ok-OG 0df8d361c2b7ae284abfa5d9b03bdd47
Subject: Re: Client-Cert Header draft
Archived-At: <>
X-Mailing-List: <> archive/latest/37534
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

HTTP 403 and especially application level controls do not work. While some
misconfigured servers do report the error outside TLS, they are
misconfiguration. As a client, we consider this scenario unsupported. The
poor caching behavior is on the server operator, as the defined mechanism
for reporting a TLS client certificate error, namely a TLS alert, was not

We should not standardize a misconfiguration. Wanting to separate TLS
termination from access control is plausible, but any attempt to solve this
problem must be done holistically. This includes defining error-handling
and making sure it actually works.

On Mon, Apr 20, 2020 at 6:14 PM Brian Campbell <>

> Very true that connection-level authentication doesn't always play well
> with HTTP. But the intended scope of this draft isn't trying to address
> that. It's only trying to bring some commonality to what's typically done
> in practice now. I would think an HTTP 403 or even application level
> controls on content is what's happening now regardless. The approach in
> this draft does mean that authorization errors aren't going to be conveyed
> back to the client at the connection level but, as you point out, doing so
> is differently odd. So much so that I don't think the draft needs to do
> anything to facilitate it.
> On Fri, Apr 17, 2020 at 3:12 PM David Benjamin <>
> wrote:
>> 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 <>
>> wrote:
>>> +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.*
> *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.*