Re: Client-Cert Header draft

[Brian Campbell <[e-mail]>]

Apologies for the slow reply.

On Tue, Apr 21, 2020 at 10:31 AM Roberto Polli <[e-mail]> 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
> <[e-mail]> ha scritto:
> >
> > Hello HTTP Working Group,
> >
> > I've somewhat inadvertently found myself working on this draft
> https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/,
> 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._