Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

Neil Madden <> Wed, 30 October 2019 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E543D120074 for <>; Wed, 30 Oct 2019 10:03:57 -0700 (PDT)
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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ie-cjcfJ6cN7 for <>; Wed, 30 Oct 2019 10:03:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA730120111 for <>; Wed, 30 Oct 2019 10:03:55 -0700 (PDT)
Received: by with SMTP id g24so2899148wmh.5 for <>; Wed, 30 Oct 2019 10:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3GHy9BenAp6ShBHu3TdXdrvRdUpJCJgNX3RP1w2iFSo=; b=F+exeNAfYUi0kF3wllYrslTqRlQMc1G8D5xjszePGuIW6n9ZvazRFjnM32NxuUtomq 7IzKY+J1suTLbZSIJ9XQ8kHupZ6HQQtLmlNcaKOyZ7v4iQ1j+how5icp/b2hKhe0AvUK T2Dw0myFO4P1uQGdiWrGzVbzVPQbwEtL5ZFfc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3GHy9BenAp6ShBHu3TdXdrvRdUpJCJgNX3RP1w2iFSo=; b=I8wTMeoJKtOQNs6s4SRVhjLMCQzdPDQDiWAQowVSBLRbtWwY/0q5BVwNABsnGYWUkG BsowjU2befwW3jlfaue19OUtfHfbYXuRYVE/bYc/KqTaD+vxO8m41Mv/7G29y04Gn9Ym VimNQzU5GBgWoUe6UUSLBcMUNzQRH0OjKqq/pefB7pL22wn+AcQo3++s8TaA6IIH6e2l R6aTuMNdUuQPEdx/Jo1W8tqc5CRBMwlnYGOcfRqWZYdFl0TsduidwER23/0xCbphU2bK ucoF9yHarbGjX6qXtVvXDrYEnpKEebrdz8aGmFKCT087RMkH5FB44Q4Fiv6IGn1DIzOg WmBA==
X-Gm-Message-State: APjAAAUy7IMG7yUqEvgtBwkZQROVOP3r2JEus7Vgl1xOaY4AEDis2sUX UcIjFX48iT82F45RGd4HhxwfdA==
X-Google-Smtp-Source: APXvYqywCoizyq+L7xZSuwTCesD3xNSraUpR6j8i/0yFB4hYb5dJToZT1kWMe5ixReDTx5yZfpHb4Q==
X-Received: by 2002:a1c:7406:: with SMTP id p6mr496878wmc.64.1572455034381; Wed, 30 Oct 2019 10:03:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 76sm684807wma.0.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 10:03:53 -0700 (PDT)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_80020BA6-6DD1-4F38-A77F-5BD4E31899F6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 30 Oct 2019 17:03:49 +0000
In-Reply-To: <>
Cc: Justin Richer <>, Brian Campbell <>, oauth <>
To: "Salz, Rich" <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 17:03:58 -0000

On 30 Oct 2019, at 16:41, Salz, Rich <> wrote:
> I'm thinking of a uniformly random 16 byte name right now. Have at it.
> Cute but missing the point.  I don’t have to guess it. 

To quote your previous claim: "There is no such thing as an unguessable name."

> YOU have to securely deploy it across your proxy (however many staff), your backend (however many staff), your application developers (however many), and perhaps your diagnosing or debug teams if they are different.  And then you must make sure that if ANYONE ever takes a packet trace, or makes a slide out of a sample message, that they don’t disclose the header, such as by showing “here’s how we do OAUTH” at a user group meeting.

Even if your deployment team had such staggeringly bad operational security practices as to allow people to take packet captures from an internal network and show them on public slides without any kind of questions being asked, if this actually happens *YOU ARE NO WORSE OFF THAN IN THE SITUATION WHERE YOU USED A WELL-KNOWN HEADER NAME*!

I don't know how many different ways I can say that this is a defense in depth *in addition to* everything else you would normally do to secure traffic between your RP and backend servers. As with all defense in depth, the aim is to be more than 1 configuration mistake away from total compromise.

-- Neil