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

Brian Campbell <> Mon, 20 January 2020 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 647A612013B for <>; Mon, 20 Jan 2020 05:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 huoXz3qgLunZ for <>; Mon, 20 Jan 2020 05:53:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB250120129 for <>; Mon, 20 Jan 2020 05:53:30 -0800 (PST)
Received: by with SMTP id z26so3470812lfg.13 for <>; Mon, 20 Jan 2020 05:53:30 -0800 (PST)
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=0ngEeBN964nK6cRekveLIXJwb6SoK21+cYUDJdPOpHI=; b=BoqmpVbbM4pi5vaX/zji4U5cUqucoQh8Dl/cdg1uqNB5Kk1j1Y4iB5GDMC3zjgTTto sF6BKC2ewttQY02N53PQoVN5BoM2KSiIDqm55fl/8ZS+yhdg1aFh8kIjhe0Ij7hy/eyI FZzOeWf5WmNarmRPHjtLJ+8RAVqjS0HQ90CGOOR5Y71T86WccbRLeDQIbFtpLNYtqvEM xBv88Br56d+JwDTRAnKuvg2vFW2Fc4AbAPygPG46M7AqB2i3k8i6Lt2W5L3AWYryiN8H qDSemqgBqvBITIPjQFx0T3HYOluhC84Tvk5yqt/BeJjnKpCGlljcx95FEfq2Oz1Q9FoE PP+g==
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=0ngEeBN964nK6cRekveLIXJwb6SoK21+cYUDJdPOpHI=; b=nWjXoWV2hFOKXOdwzDnY3HTGDF0rz2WxfzexUyr3eltRgyfq4Vcnv4+rE8JWdIw+HD Gn0GnZPPIiccJfIIVaGK49f+asRD41lfT8AL84bY95BWBWdga3PnfSngbWip8ctUIGIH tEnZrWYU0pZHMsQDdDx+SiMKVMz0hUNky5hfcifY4gKaozVLRI4RYtizzqfg1w7zHsSY dJYOhjX9SmI0JBVeo+rR5lSu5EbbRulf+N4EbTjXunodZb0DQzkPz4a7YceVbccJ9PgM R3z6291qsm8jCzTTVZO3vN+i2vFxdRlinvGaours80Zkhe0NcvQFAP7u7V4h3GzGWjZK B4rg==
X-Gm-Message-State: APjAAAVoBCCvjb0BfIUHtQ0t53zVWidI2Qv49UUNEcN974TWdL1L98xz bDi6L1UmjR3KE6Jct0DgYiG8k5sukw09mt1/7VhwzLFrTp2C3BgoXx8UW1gNosevVh1PmuY9OZ6 rQSlbWmluog4NmQHBkgFuiA==
X-Google-Smtp-Source: APXvYqzSKkbIkLtc+s559GGHZLptPbbvSZrI2uSr8wTF7yYKpSgg22Weim4+iNrPRJ6SPsfT35EIm29gUdNxwnxdP/c=
X-Received: by 2002:ac2:523c:: with SMTP id i28mr1594804lfl.104.1579528409126; Mon, 20 Jan 2020 05:53:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <22451.1579452735@localhost>
In-Reply-To: <22451.1579452735@localhost>
From: Brian Campbell <>
Date: Mon, 20 Jan 2020 06:53:02 -0700
Message-ID: <>
To: Michael Richardson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000bd3174059c929d75"
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: Mon, 20 Jan 2020 13:53:37 -0000

Thanks Michael for the read of the document and feedback. Some responses
are inline.

On Sun, Jan 19, 2020 at 9:52 AM Michael Richardson <>

> 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}

Via email exchange it's not entirely clear whether that's a compliment or a
criticism or just an observation.

It was meant as a nod to the header name chosen in the example on slide 4
which was there as a semi-humorous placeholder of a name to indicate that
the name is both important and unimportant at the same time.

> 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,
>   draft-richardson-anima-registrar-considerations
> 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.

AFAIK, those are de facto names originating out of defaults or
documentation from reverse proxy implementations that allow for similar
behaviour with respect to the client cert. Apache mod_ssl and Ruby thin
respectively I think.

For better or worse, I tried to choose a name that's meaningful and
shortish. And one that doesn't look like it came from the default
documentation of some popular web server.

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

In writing up this initial draft, I waffled about whether or not to include
intermediate signers and/or the whole chain. Although I landed on only
passing the leaf certificate, this is certainly something that's up for
discussion should this document find a home where it can be worked on and

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

True, the reverse proxy can not control what is sent to it. But it's meant
to be normative language towards other forward proxies and other
intermediaries to say that they can't/shouldn't be adding this thing. Which
seems legit (and something I'm told is supposed to be covered for registry
requests on header fields). Perhaps that text can be moved or adjusted in a
way that makes the distinction more clear.

> 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?

That's certainly an option. I suppose there are tradeoffs between rejecting
vs. cleaning such requests. Maybe a MAY would be appropriate for something
like that so as to give the proxy the option. Again, that's something that
could be fleshed out in discussions if this thing finds a home.

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

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