Re: Client-Cert Header draft

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78B903A0BE8 for <>; Fri, 24 Apr 2020 14:25:39 -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 XDpeLCDkEUqM for <>; Fri, 24 Apr 2020 14:25:37 -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 17B5A3A0BE9 for <>; Fri, 24 Apr 2020 14:25:36 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jS5lp-0007PD-OC for; Fri, 24 Apr 2020 21:22:01 +0000
Resent-Date: Fri, 24 Apr 2020 21:22:01 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jS5lo-0007Ky-Gs for; Fri, 24 Apr 2020 21:22:00 +0000
Received: from ([2a00:1450:4864:20::22f]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jS5lm-0001DK-HE for; Fri, 24 Apr 2020 21:22:00 +0000
Received: by with SMTP id u15so11472551ljd.3 for <>; Fri, 24 Apr 2020 14:21:58 -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=DC4Ol35W9F7vsEW7s6nxXTrED5eLNwEpXFsH4tPsX/E=; b=GSn7Y4ZBK499E5hHKioDSQxJq1dilVuYxXCzVT1KP72ahMs8WwbuP9gZjmk399+g7l Pnpyj2zm0HjHOY+trSYTkszi7Cs4Hi2TKSTwDM+xEd3Md/8b9HQ38XUYYK/sVmFq/kMX e6kxmlCxEzthPz39Om38QnfBFPLKuPX5tCT/zEb4VEHRZU+gz1meF2MHaCdZwqtyCJxV FPhG4w95tuoKhrwv7EfuC+CUXPnwa+/YX6kRYyLfEy1XNIRnwgXCODTSKzdbukHZWG6y akx8A/rs1HBj/qZumusPrzwTyozOthjYnKmf30xVeZTpC+M1StHFE7mUxCXtT41+rn4Z pSMw==
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=DC4Ol35W9F7vsEW7s6nxXTrED5eLNwEpXFsH4tPsX/E=; b=ucfp5IkJRMSX17GQ7bMpX6Jd0HXNbu/L3lwhOJEeEXgZiZQuq2wMh2q2tMrQnYbHxv dsDAb2Z958kVkSVN46RfZZOrFqPXOCv5AfBMaUFo6R2YzN2S5ZEJqsds1yLBXhaxIW19 bWuuyIkNS4LPD2E7p993rGOPE0gYV7NDknzgiuTIwxfmLtQ17/5aguKamEJhJ6n7vScL LwHZtqCCR8fOxncQj+Hi8D2MWRbJKxs3Bjy69hz0MqbVMrEDY2B/JKP+rQSBOeHFJ4Bj 7zcMyfFfKCF6E4/NDMCNprd3uFNV1ldr7xkUQQOyE8bFisA4ZZvmXGpY+4Fi0aDTc0sg 9hsQ==
X-Gm-Message-State: AGi0PuYUpHGjcZE0c4HlPQlrWEkmkvdT8NTlOZOysjYzDdJkAAIm4vpp mNNozlOGzb5VxHZqYjXdhE1xGJV8kRLBCKM4iaefKK3Q/vty/todcGqgphuCQXR61qaekitPsrU jlOXvacdkrOOgX4LB7No42Z80Mw==
X-Google-Smtp-Source: APiQypKaQ6xh8ZBuDC1D23N8sndi5ou8qAVEe8RuGc30gVDkvYz/NXMqUsOzImwR3IOpbIy+TV2IKOJ9XXxiNDGT/oY=
X-Received: by 2002:a2e:9842:: with SMTP id e2mr7119572ljj.273.1587763306753; Fri, 24 Apr 2020 14:21:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 24 Apr 2020 15:21:20 -0600
Message-ID: <>
To: Roberto Polli <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000e309b705a40ff3cd"
Received-SPF: pass client-ip=2a00:1450:4864:20::22f;;
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: 1jS5lm-0001DK-HE d7e0f26ecf600ce541b74dd55a1c33b1
Subject: Re: Client-Cert Header draft
Archived-At: <>
X-Mailing-List: <> archive/latest/37548
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Apologies for the slow reply.

On Tue, Apr 21, 2020 at 10:31 AM Roberto Polli <> wrote:

> Hi Brian,
> I think the work is interesting and useful, though it has complexities.

Thank you and yes.

> TL;DR: I'd only standardize the header semantic and file a detailed
> Security Considerations
> section with different sections addressing the different issues.

I sorta think that's how the draft currently lays out, more or less, so I'm
not sure what to take away from the comment.

> More follows:
> 1- standardizing the header name is good;
> 2- it is correct to investigate the impacts of this header when the
> network topology is not trivial
>     ( I see use cases for TTRP + re-encryption). I suggest providing
> subsections
>     in the Security Considerations;

I've endeavored to stay agnostic to the topology to the extent possible.
Other than to say it's applicable to an HTTPS reverse proxy and whatever
encompass the backend needs to be secured. The prospect of TTRP +
re-encryption is mentioned in the draft. But not mandated. This seems like
the appropriate scope to me.

> 3- the only reason for trusting that header is an actual agreement
> between the owners
>     of the services: I am not sure we should detail things like `Use
> of the technique is to be a configuration or deployment`
>     but please provide your thoughts;

The "configuration or deployment" phrasing was intended to convey the need
for some such agreement (including that the owners could be the same
entity) as a prerequisite to doing this whole thing so it's an opt-in bit
of functionality on both servers. I think we are saying the same thing. But
I'm certainly open to additional or alternative text to say as much.

> 4- I am not sure that adding processing rules in the spec can provide more
>     guarantees to the backend server,  as it's completely "delegating
> the authentication"
>     to the upstream server and cannot verify the received information.

If I understand, I believe that is inline with my intent in the current
draft (noting that there've been some comments/requests for it to be
different), which was that the backend server doesn't itself verify the
received information but takes it at the word of the upstream server.

> My2c,
> R.
> Il giorno gio 16 apr 2020 alle ore 10:05 Brian Campbell
> <> ha scritto:
> >
> > 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._