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

Brian Campbell <> Tue, 21 January 2020 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C19712001A for <>; Tue, 21 Jan 2020 14:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 wPgsi13TKdQs for <>; Tue, 21 Jan 2020 14:21:05 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13AF012007A for <>; Tue, 21 Jan 2020 14:21:05 -0800 (PST)
Received: by with SMTP id r19so4555456ljg.3 for <>; Tue, 21 Jan 2020 14:21:04 -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=H401HRV0g1iZF3sKUemUgVrX03r9UTHCgvu4d5cxG/8=; b=e7Dts01w3lRVBKSwTAA2izFio8488XU3gBMTuX03BHWVSBZ7DPEc83vxNnVGsd8Xyl XVf5bs1wPdsbeYDXJlUysWBN3GtniO9gs9VQtsMDXUPS1rPb4nYi3FcZHfdcgRNwEDc8 Xkuy4S8t46apRsQ4uyENMw0E2+vT91C8OuUKA0DknNBiXxR3qLp7jqwJYY1FDN6Uxzur ep19iBzZSqsid8i7abNTdfGSobSjtkkT3PbC5garqxCf9qsj16Z4PJkwZwPksVz1r6vx RQOtRAtxMLJRTv8UQtoWtUcS2HnXQp3LXEtX4IQMloRlfZbHgrPxRptJr0DN8Tuatkzz JqAg==
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=H401HRV0g1iZF3sKUemUgVrX03r9UTHCgvu4d5cxG/8=; b=PjD/Y9bPQvVlhnoViNYE+CumtpJemhofdjQ3zi2XYeEEkk0uqg2RPMmavK6iigIpO0 97bYngBBkYJRE9+aahJoYXE7tNvcGtv1MZkBGK/TpTfp4bEN42s6JOggdBlTzJUbvDEH Bn4QMSXH4E8234aYQIJf1Np5hf9V6k0w/M8NBQhozQsCYXtVqzmpwSX2K24fyWYv3MOs 7WksPpSgCK3EPx5BH1Z0/3B3QhJRkOK9j/zJxteUwp8a0qo0v4dhItVDmoPBLTc0VMdh 5/2KiZInU29zjRBXvmR6BgXcBH72tGoEcQ7/Tv+3/ddflcb2XucGi7yvoT7KhamKSEYO iHgQ==
X-Gm-Message-State: APjAAAUCRg/jsfpZpMzJM9c4nLtQbFC1QWjnSRKmgY01/gI25ksJqJZc a7YtyJ5uA5NR12GPHIJ9d4n6Bhj9UIJGvRjaOAKg7ivYooEmojrNTSHSsUcL8Pnqsv+s4pCByeP ZkAF3gnvC8qh+cOmCpf/mwg==
X-Google-Smtp-Source: APXvYqzhaXyULI6m2LEVbr7iCIuDwBGWOotzXCoJj39iqFpL3jkYM39WANssb/si/XezlZ93lbpEFfw0h8VklI8oEQY=
X-Received: by 2002:a2e:9cd2:: with SMTP id g18mr15314042ljj.272.1579645263288; Tue, 21 Jan 2020 14:21:03 -0800 (PST)
MIME-Version: 1.0
References: <> <> <22451.1579452735@localhost> <> <4920.1579540711@localhost>
In-Reply-To: <4920.1579540711@localhost>
From: Brian Campbell <>
Date: Tue, 21 Jan 2020 15:20:36 -0700
Message-ID: <>
To: Michael Richardson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000ca3549059cadd296"
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: Tue, 21 Jan 2020 22:21:11 -0000

On Mon, Jan 20, 2020 at 10:18 AM Michael Richardson <>

>     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

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.


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