Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header

Mohit Sethi M <> Fri, 27 March 2020 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BC453A0964; Fri, 27 Mar 2020 15:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 32lnjK_VpfPp; Fri, 27 Mar 2020 15:17:16 -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 4A7683A05A0; Fri, 27 Mar 2020 15:17:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=EXHgv6zO5KRw7q3HnKcccoYN7HP5Qjm4Rjg5MbO/v7Jji5rBLSKNTDKjSQ4FNHeMZ+zIdDOYHlyIcQQIKOG/L/D5tX9AcHfxB/xvYQTLa5SQHeufUBzM3YqewnaYCUw7CeNQWEqVbtl5FitsoJTjOArtHxrAF1rOUhCWbIkQfSrKbatfi9sZn/hXzja06XIY8B6ni7ILhz/mdWadLaQsGqlwn07t4vXqbpQaqutPdLmPk+Xga4EGSTHhyXaq6UXv1+YF4q42ZyQXDGGiR1BIXvuJdNf1YJWwnOLvDkOx79g9vFjZkiLAzQKyfMLcl3XI2OTeU1V0G03jPq4hruFBYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dAmYY4OS6jfM5kH2fiNHyZemOqdQdoTcWmLgfBtxKE=; b=S4V0eaSuGJv7vL8PMUQx/ORDqh6GvSyqLd9IHaVEGb4Xh/432O1S+ch11GMcnzuGSFgTVH4hJ+jyL7VBpKs41GE32aIbrNKHQewoRyBsci8q6VLa9qAF8x0XqF+jFAiQnqwB748wYb6bMKzFeVVjbYVZHOZWdaOMgzFqnfL7Y4hCjmAhrNIvOe3k3ttAnLDtRgg6423Ce7XyOWwC4a0e514F5q6C73SSLk/KDz3yij5rXT5NTI9VGMnOC4d9Ns4HHcNXXX1ySs98lXHGTZnlQGkB4FIb7S54qlWZ+omXcoHHIiRvC7kXZ7VQ7Peht7jGfgbD58Rat5JKJcj3ugTR/g==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dAmYY4OS6jfM5kH2fiNHyZemOqdQdoTcWmLgfBtxKE=; b=IKFSIdP4ZA6jO9x9cE/TQXVZYiI5fzGj1VoTPflysTtuW5t9yLppRDE9qD0SpIdipkSGmn7dc41UCHivQvudVZUMYNfo2Bsak4YX+7Kd3g/C3jDXwavs/hSxKiFdANhNyB3yaJTHmJDWVWpfDqwpWqBaxOjgK2uvzShvEdZQkcE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.15; Fri, 27 Mar 2020 22:17:12 +0000
Received: from ([fe80::46a:30:fc8d:a724]) by ([fe80::46a:30:fc8d:a724%7]) with mapi id 15.20.2856.018; Fri, 27 Mar 2020 22:17:12 +0000
From: Mohit Sethi M <>
To: Eric Rescorla <>, Brian Campbell <>
CC: IETF SecDispatch <>, "" <>
Thread-Topic: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header
Thread-Index: AQHWBIV2hjLsIQ1RGEme1grzVmPFEQ==
Date: Fri, 27 Mar 2020 22:17:12 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:14bb:190:326c:5f0c:2481:d832:5f65]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7c98e574-8707-440f-cd3b-08d7d29c9975
x-ms-traffictypediagnostic: HE1PR0701MB2665:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0355F3A3AE
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(396003)(136003)(366004)(39860400002)(4326008)(316002)(2906002)(31686004)(76116006)(66446008)(110136005)(186003)(478600001)(66946007)(54906003)(6506007)(6486002)(86362001)(5660300002)(71200400001)(66476007)(6512007)(64756008)(53546011)(31696002)(2616005)(36756003)(66556008)(8676002)(966005)(8936002)(81156014)(81166006); DIR:OUT; SFP:1101;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6/ThY+iRYGaxfpD/luLYPLyrpJxvaTrLLBArPUmYB8oDhEZ/9QzKwpeYcqx+boethnov9nzg9R1F7iXsWMRqghSaGTXAldGWnt8RphoN9m0EHoV1w03crO2prnL4eRQpcvGg6A8Wtb/cMSsOJi2itL6x05IucxjVewCUJjiG3YhnYDzt3jOS6zdO87CvLzVLfUI9hQy7Hsu2aRPLAeLePqQ13vFvpEhswOcFKVONCfTt2q8dF3xGwM2rYc80ms6bReZU3uUervsN1Bgq710nUFkTEreKcGsKHC7qATDqqUNnlp4yf+IjkzW4qHg2WQW2zycbTXacqx7P59JgPcbsBse18a6OJ8RTk/rFOy6TDkI9A0NTFQq7yUUOMnL1k5zasGwnU522I0QtJI/mZBX1QHdCQiQXxloX9j9ONCPmpXn0qV6vk+w/5c41Ar8Wp/Tb+U00Tsy6tykBK4c+6HuobVBBMp6JEf+KZoRolD1S6nf9VpmGf4HxtPXVBsZrfHg32QLD1/MP4xVnlEwI1uQ2Wg==
x-ms-exchange-antispam-messagedata: VWHda65cR2zbar3yficCM4n5GiAW9yhU2qrNAnu/BtNRFBqCeK2b+g5DlaYHnJMVrmn1qy1mLlWhbocbzztOjqlShm2yWrLjnOZ05ujrf0bq0skMZP31Jx0lcQ0BYDIEDuP3q4Y1cP9xkVViGB9DyHbjmY7rOgcd9fX4JOamsPHz4KzEJD5mxJPsodIt1fTnjziGQ4WjP6eslvOZe4/HDA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_a93a634a22db682a77bbd6e8199c8372ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c98e574-8707-440f-cd3b-08d7d29c9975
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2020 22:17:12.5480 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Iu5FAsq2eS8G4S+Js8TGhG9joPLAjDaiZekgRw+npOaQyRR6zKZylQ1HhWLCL0JcJ8m/Coh8hhcQmhBypiP1AUmzzKD/QXv+7xBFq7Njayk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2665
Archived-At: <>
Subject: Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Mar 2020 22:17:19 -0000

Hi Brian,

On further thought, I actually agree that passing the entire chain makes more sense. This would be useful if the TLS proxy doesn't have the trust anchor (but the backend server has it).


On 3/27/20 7:21 PM, Eric Rescorla wrote:

Overall, I agree that something like this is needed. However,
I have two concerns about the mechanism described here.

First, as you note in S B.1., if the header is not properly
sanitized, there is a trivial attack and there are stronger
mechanism that do not require sanitization:

   "Client-Cert" header that would appear to the backend to have come
   from the reverse proxy.  Although numerous other methods of
   detecting/preventing header injection are possible; such as the use
   of a unique secret value as part of the header name or value or the
   application of a signature, HMAC, or AEAD, there is no common general
   standardized mechanism.  The potential problem of client header
   injection is not at all unique to the functionality of this draft and
   it would therefor be inappropriate for this draft to define a one-off
   solution.  In the absence of a generic standardized solution existing
   currently, stripping/sanitizing the headers is the de facto means of
   protecting against header injection in practice today.  Sanitizing

This seems like an odd argument to make: if a strong mechanism is
in order, we should design one and make it generic, not just throw
and continue to use weaker mechanisms.

Second, I think it's quite unwise to only pass the EE cert. This
means that the server will be unable to independently evaluate
the cert chain, which (1) is unduly restrictive on the architecture
because it forces the proxy to do it and (2) means that there
is no backstop in the case where the proxy makes errors or
has a not-very-good validator. You should pass the whole chain.
This also implies that you should have a way to pass extensions
such as SCTs and stapled OCSP responses.

Finally, two points about TLS integration.

1. You should define how this works in the case of resumption
of a connection that had client auth. Should the proxy attach the
chain from the original connection?

2. How do you handle post-handshake client authentication? Specifically:
(a) How do you handle the situation in which part of the HTTP
request is covered by the client cert?

(b) Post-handshake client authentication allows for the client
to authenticate with multiple certificates one after the other.
How is this propagated to the server?

On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <<>> wrote:
Hello SecDispatchers and Chairs thereof,

I'd like to request some time on the agenda in Vancouver to present on in an effort to gauge interest and potentially find an appropriate venue for the work to proceed (or just put it and its ridiculously long title out of its misery).

Client-Cert HTTP Header: Conveying Client Certificate Information from
     TLS Terminating Reverse Proxies to Origin Server Applications


   This document defines the HTTP header field "Client-Cert" 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.

Discussion around the value of having something like this defined happened in the OAuth WG a bit before the Singapore meeting (no doubt that's not the only time but it's the one in which I was involved recently) and an AD nudged me to secdispatch - falls somewhere in the middle of that long and sometimes contentious thread. I was unable to get a draft published prior to the I-D submission cut-off for Singapore and got a short "if time allows" presentation slot at the meeting. The judgment coming out of that meeting was "needs draft".

I did get an actual draft published a bit after Singapore (the one with the ridiculously long title previously mentioned) and there's been some, if not exactly an overwhelming amount of, discussion and support of it on this very list:

Brian Campbell

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._______________________________________________
Secdispatch mailing list<>

Secdispatch mailing list<>