Re: Client-Cert Header draft

Brian Campbell <> Fri, 24 April 2020 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C00AE3A0E13 for <>; Fri, 24 Apr 2020 15:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Status: No, score=-3.569 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.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pqHcInY36kmn for <>; Fri, 24 Apr 2020 15:21:03 -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 6AF553A0E11 for <>; Fri, 24 Apr 2020 15:21:03 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jS6gb-0002Fl-5i for; Fri, 24 Apr 2020 22:20:41 +0000
Resent-Date: Fri, 24 Apr 2020 22:20:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jS6ga-0002F0-9d for; Fri, 24 Apr 2020 22:20:40 +0000
Received: from ([2a00:1450:4864:20::229]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jS6gX-0000UA-HF for; Fri, 24 Apr 2020 22:20:40 +0000
Received: by with SMTP id j3so11551897ljg.8 for <>; Fri, 24 Apr 2020 15:20:37 -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=gBgIEEcyNcU8B61+YkNQ6ZVxfwQ9Y9+ZgOZxPWc2Q+g=; b=AFyVEmrTr2fKR2Lqo/ANFlLKrHt0icaTgzhfBC5KzUrJzMs9WEe0ReaZ1P92ubtNLU KiFrf6PPjOJfNqmWY974EnZsHYrtfW11w2oxo0ffgwCc6yE/82ze6l0z+h1OaNJOCf4k zcpavkz9inda5yweDWZDkj6Q9mDEXSYWVHdoDgvxhJGsMQ3VqtywrBVI9nqzM3Oekbgd i5aZ4oHvg2wD3+yEw8PJDfn1NoEZyQJ1BrcRvM9QNeWdWmjFW9lO7avg3ufJx3i5Wz+d CrqJb3iUJyNA+X4NUrVPzFFog8rkKyw+ZRmqWzymQ3/0imORfTBkbe57O7Eh8BY2fUxB syeQ==
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=gBgIEEcyNcU8B61+YkNQ6ZVxfwQ9Y9+ZgOZxPWc2Q+g=; b=mUNCkgu/JZWLx/hEgF7K39mIDCMtgdLSI/XVtJ34sjhbe7hClfPeWDG7OM4d4cuf7r K2xhEj3C8h4lvl72JmSz4XqTobYP1T+5/q/lK/ZakemLjTEhWSHUA3cc0Fo0Y8jC8NMj RJeEQc3RAeO0/+3JJadvUf1dMs/xSdQedi8vV0lJ050SYnK40ZhFTtJ2XtH4ZcL3sMAM lE17KNR8b+j8uiQE5mn3xxWlT/+velZW+J1leQi5I7Srx11ubky1SqWVM+9EJn/Mz0ZL zTwIr/7K7CHHhp/pHUtLy0zQlWNy78W4+mXIDzu2kquHtfYKTz2RtwA5et08q9uAETEZ mcjg==
X-Gm-Message-State: AGi0PuZrLDa/66omKEh1nMO57C52OP7M2UGd4sLwJ/PZartbUoU7zCpD sN9C04WvGCG6cNL0RXLQTL3nqhhiJ4uE2J5mGpedvG0I6lSpVIVE1031VYusliWyiXGEmHMaGxQ kDuu1XZY2TEeujy23uABY
X-Google-Smtp-Source: APiQypK+0f5ZFSrswM/OCIaoRMq4vroqer0v9m8ZwdPtE8zs8Ll7Eso0wuOtLWoqS/uVTdlYz+PShhsudhNguKn8R2A=
X-Received: by 2002:a2e:9455:: with SMTP id o21mr7342354ljh.245.1587766825703; Fri, 24 Apr 2020 15:20:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 24 Apr 2020 16:19:59 -0600
Message-ID: <>
To: David Benjamin <>
Cc: Lucas Pardue <>, Mike Bishop <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000a1fae305a410c598"
Received-SPF: pass client-ip=2a00:1450:4864:20::229;;
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: 1jS6gX-0000UA-HF ca8136603194ff1d18f8de27df06cc1b
Subject: Re: Client-Cert Header draft
Archived-At: <>
X-Mailing-List: <> archive/latest/37551
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Rather than misconfiguration, I would characterize it as an impedance
mismatch in functionality and expectations that arises at the intersection
of making use of TLS-level authentication at the HTTP level. With that
being said, I suspect this is something we just see differently and that's
unlikely to change. But I do note the objection and it's something that can
be hashed out further by the WG, if the work on the document proceeds in
the WG.

On Tue, Apr 21, 2020 at 2:13 PM David Benjamin <>

> 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
> used.
> 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 <>
> wrote:
>> 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.*

_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._