Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106

Michael Richardson <> Sun, 19 January 2020 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1985912003F for <>; Sun, 19 Jan 2020 08:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zte7D8gxDwTO for <>; Sun, 19 Jan 2020 08:52:17 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F102E12002E for <>; Sun, 19 Jan 2020 08:52:16 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 889853897A; Sun, 19 Jan 2020 11:51:45 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 7391FC9B; Sun, 19 Jan 2020 11:52:15 -0500 (EST)
From: Michael Richardson <>
To: Brian Campbell <>
cc: "secdispatch\" <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain
Date: Sun, 19 Jan 2020 11:52:15 -0500
Message-ID: <22451.1579452735@localhost>
Archived-At: <>
Subject: Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106
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: Sun, 19 Jan 2020 16:52:19 -0000

<#secure method=pgpmime mode=sign>

Brian Campbell <> wrote:
    > Apologies folks, I'm responsible for the rushed and awkward
    > presentation about reverse proxies and TLS client certificates at the
    > very end of the SECDISPATCH session in Singapore, which is mentioned
    > below with "no draft yet--> needs draft". It took me a little while to
    > get through the work but I'm happy to share that there is now an
    > actual draft available. Here it is in the fancy new HTML format:
    > as

Thanks for this document.
I think it is useful and important work.
{"something-something" sounds like something that Winnie the Pooh would ask to
eat for lunch}

draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Client
Certificates in the Registrar.
I have a document on operational considerations for Registrars,
and I've added your document as reference.

In section 1, you may wish to reference:

although I can't find a section in
that describes the Client Certificate variable.  I use "SSL_CLIENT_CERT"
and more recently, "rack.peer_cert" in my code.

** I would like to have access to the entire client certificate *chain* **
Not just the End-Entity certificate.

If any internal trust anchors were used to validate the chain, I also would
prefer to receive them as well.

Finally, I need to be able to configure the reverse proxy to do the TLS
operation on the assumption that the certificate validates, even if the
reverse proxy does not know how to validate the certificate chain itself.

I need, therefore, to know if the certificate chain was validated, or not.

You write:
  Forward proxies and other intermediaries MUST NOT add the Client-Cert header to requests.

but, the reverse proxy can not control what is sent to it, and you shouldn't
try to write normative language there.

You already handle this:
  2) Any occurrence of the Client-Cert header in the original incoming
     request MUST be removed or overwritten before forwarding the request.

and leave it like that, maybe emphasis this.
Maybe reverse proxies SHOULD reject requests that have a Client-Cert header
in them, period?

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-