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

[Brian Campbell <[e-mail]>]

On Mon, Jan 20, 2020 at 10:18 AM Michael Richardson <[e-mail]>
wrote:

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

I'll take it. Thank you :)


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

Got it and point taken.


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


It could be that we should have two headers.
> 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
>     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.
>

Gotcha


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

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

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