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

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Jan 2020 13:42:55 -0700

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:
https://www.ietf.org/id/draft-bdc-something-something-certificate-01.html
as well as the good ol status page:
https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/

On Tue, Nov 19, 2019 at 9:34 PM Francesca Palombini <francesca.palombini=
[email-masked]> wrote:

> The SECDISPATCH WG met on Tuesday November 19.  The agenda items were
> dispatched as follows:
>
>
>
> (1) Problem statement for post-quantum multi-algorithm PKI (Max Pala)
>
> drafts:  https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
>
>
> https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
>
> --> dispatch to LAMPS WG (confirm on mailing list)
>
>
>
> (2) OCSPv2 - Improving OCSP Responses (Max Pala)
>
> LAMPS & PKIX discussions:
>
> Draft:  https://tools.ietf.org/html/draft-pala-ocspv2-00
>
> --> create a BoF for small focused WG
>
>
>
> (3) Privacy Pass Protocol (Nick Sullivan)
>
> drafts: https://datatracker.ietf.org/doc/draft-privacy-pass/
>
> --> work on charter text then BoF for small focused WG
>
>
>
> (4) HTTP Request signing (Justin Richer)
>
> draft: https://tools.ietf.org/html/draft-cavage-http-signatures
>
> --> dispatched to HTTPBIS WG
>
>
>
> (5) Communication Network Perspective on Malware Lifecycle (Joachim Fabini)
>
> draft:
> https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/
>
> --> check the IAB project (talk to Ted)
>
>
>
> (6) Securing protocols between proxies and backend (HTTP?) servers (Brian
> Campbell)
>
> draft: Looking for support/contributors, no draft yet
>
> --> needs draft
>
>
>
> Detailed minutes will be coming in the next couple of weeks.
>
>
>
> Thanks,
> Francesca
>

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Jan 2020 11:52:15 -0500

<#secure method=pgpmime mode=sign>

Brian Campbell <bcampbell=[email-masked]> 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,
  draft-richardson-anima-registrar-considerations
and I've added your document as reference.

In section 1, you may wish to reference:
   https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface

although I can't find a section in https://www.python.org/dev/peps/pep-3333/
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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Jan 2020 06:53:02 -0700

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

> {"something-something" sounds like something that Winnie the Pooh would

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
of
https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-securing-protocols-between-proxies-and-backend-http-servers-00
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.

> although I can't find a section in
> https://www.python.org/dev/peps/pep-3333/

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

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

> Maybe reverse proxies SHOULD reject requests that have a Client-Cert header

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jan 2020 12:18:31 -0500

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

compliment.

    bc> It was meant as a nod to the header name chosen in the example on slide 4
    bc> of

Ah!

    >> and more recently, "rack.peer_cert" in my code.

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

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

My point is to
  a) point to de-facto names which are currently being used to demonstrate
     the need for a standard.
  b) indicate if the contents are the same or different.

    mcr> ** I would like to have access to the entire client certificate *chain* **
    >> I need, therefore, to know if the certificate chain was validated, or not.

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

good, we agree.
Isn't httpbis the obvious WG here?

It could be that we should have two headers.
One for the EE, and one (or many?) for the chain.

    >> try to write normative language there.

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

Sure. I'm saying no normative language about another entity.
The normative language should say that reverse proxies MUST remove the header
when coming in.

    >> Maybe reverse proxies SHOULD reject requests that have a Client-Cert header

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

It seems like a request that arrives with Client-Cert in it is at best
misconfiguration, and at worse an attack.  It can't be legitimate.
I think that being tolerant here does not benefit anyone.

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 21 Jan 2020 18:18:23 +0000

I support this effort!

The lack of such a header has been a pain point for migrating applications with client-cert driven auth mechanisms into the cloud.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Secdispatch <[email-masked]> On Behalf Of Brian Campbell
Sent: January 17, 2020 2:43 PM
To: Francesca Palombini <francesca.palombini=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL]Re: [Secdispatch] SECDISPATCH WG Summary from IETF 106

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
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: https://www.ietf.org/id/draft-bdc-something-something-certificate-01.html as well as the good ol status page: https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/

On Tue, Nov 19, 2019 at 9:34 PM Francesca Palombini <francesca.palombini=[email-masked]<mailto:[email-masked]>> wrote:
The SECDISPATCH WG met on Tuesday November 19.  The agenda items were dispatched as follows:

(5) Communication Network Perspective on Malware Lifecycle (Joachim Fabini)
draft: https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/
--> check the IAB project (talk to Ted)

(6) Securing protocols between proxies and backend (HTTP?) servers (Brian Campbell)
draft: Looking for support/contributors, no draft yet
--> needs draft

Thanks,
Francesca

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.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 21 Jan 2020 15:20:36 -0700

>     bc> criticism or just an observation.

I'll take it. Thank you :)

>   b) indicate if the contents are the same or different.

Got it and point taken.

    bc> In writing up this initial draft, I waffled about whether or not to
> include

It seems a likely candidate, yeah.

The issue that the draft aspires to address certainly isn't new. But it
reared its head again on the OAUTH WG list not too long ago before the last
meeting. When the prospect of trying to standardize something came up, one
of the SEC ADs encouraged me to bring a presentation and/or draft to
SECDISPATCH. That was right before the I-D cutoff pre Singapore so I just
started with a presentation there, which was rushed due to time constraints
and basically the suggestion coming out of the meeting was to write a
draft. I just recently got this little draft written, which brings us to
where we are now. And I guess that basically amounts to looking for some
direction from SECDISPATCH and/or gauging interest or appetite for the
work.

> One for the EE, and one (or many?) for the chain.

 That's certainly a possibility. And I think not inconsistent with what
some existing proxies will do now.

    bc> True, the reverse proxy can not control what is sent to it. But
> it's meant

Gotcha

> I think that being tolerant here does not benefit anyone.

When phrased like that, the case for intolerance does sound pretty strong.