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

Jim Manico <> Wed, 30 October 2019 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26E3E120106 for <>; Wed, 30 Oct 2019 13:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 jp9gxtN9KKRR for <>; Wed, 30 Oct 2019 13:04:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DFE2120018 for <>; Wed, 30 Oct 2019 13:04:47 -0700 (PDT)
Received: by with SMTP id 205so2843413qkk.1 for <>; Wed, 30 Oct 2019 13:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WLTqSL5AFTDCIYyNLOr89qM++DwgmbKAF2nLGtPPtwI=; b=OcvHlFDD0fCjzJoLwgOk/9Tvssl4tTou7G02WBOk0uJu2MoHIZI4YWDvgnSO8ut7gB e6LRQrkF3+pEw9hRaGXlzcf3yHfqsp5L2HDaKa6GsVJ9NZa0pz+LVxE4vQubfQE1+iyu kWmQWIfbAuFfAmBDDR6Yiph+zsbIbBbOleP1jIyXroOi83TXptaeaByzCSykhQGT0D+L 2Oy0kXv2aLRT2kh8uv4j28A3waPwF3eryspcOT3xgES9pSZzhEpZ89kFyJU0yEC5Plvd 4wlC/P5F3/prr5bQQo/g0iz9OvLbIgE442TtYRx6CyNyYC5rzZgrxBIZMjni954mmHCX JGXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=WLTqSL5AFTDCIYyNLOr89qM++DwgmbKAF2nLGtPPtwI=; b=lDU+T+BHbtPPnQ+vCX9Sk4KWDVHoaFdymu0DvSGEtJNf8EITb7BmfQJNBzGkqbYgCv 8NVHrkzCtcGl178qw40mZAgExTu2KJTak9c3XDq07y0b7vFKBfD0ZwxecR0iLYh0JZUz 6MqRQRa/CNTEhJTB29wOZbcE7isattHaEJfSuTZmckSVk3xQjZmtPkemWX/HR8ZBgZtH BgUpgd1OmQuos40BNdaKWwkwqdJZQPEN/HkgEo3BVRwVkRloZiesJkSv9v8Ce7YI7eiW 92gjfo2AvSADwl/jff6lUvNsFAXjecN4tjqQTA6i9CbDwPNfQZ+FW00sV7aNRuyK5//x bAsw==
X-Gm-Message-State: APjAAAXoAUva1EG+/sTemWqZRhfh0yuSOK+lt04Tzuie18EeByWkfGJN MADdC2R0Lv31ElZRFFK/h0+dOg==
X-Google-Smtp-Source: APXvYqwNODeUYQ2XSekrrYA8gp3bIiodsRQcGT+P2D3omfFaqtFENUidfduJRx/u6BbKdnCX6EMQUg==
X-Received: by 2002:a37:7705:: with SMTP id s5mr1790660qkc.145.1572465886359; Wed, 30 Oct 2019 13:04:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f35sm699080qtd.35.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Oct 2019 13:04:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-451963F3-A7E3-442D-84D8-513DCB5D0E97"
Content-Transfer-Encoding: 7bit
From: Jim Manico <>
Mime-Version: 1.0 (1.0)
Date: Wed, 30 Oct 2019 16:04:44 -0400
Message-Id: <>
References: <>
Cc: "Salz, Rich" <>, Brian Campbell <>, oauth <>
In-Reply-To: <>
To: Neil Madden <>
X-Mailer: iPhone Mail (17B84)
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 20:04:50 -0000

I love you Neil.

Jim Manico

> On Oct 30, 2019, at 3:18 PM, Neil Madden <> wrote:
> If you can point out where I recommended disabling TLS or not bothering to strip headers from incoming requests, or anything else along those lines then please let me know. Otherwise, yes we’re done here. 
>>> On 30 Oct 2019, at 17:19, Salz, Rich <> wrote:
>> To quote your previous claim: "There is no such thing as an unguessable name."
>> Right.  That doesn’t mean *I* have to guess it.
>> 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*!
>> Yes you are worse off.  Because that now-exposed header value can be used for spoofing.  As opposed to protection by TLS, and then sending the plaintext message around.
>> I don't know how many different ways I can say that this is a defense in depth
>> Because it is not.  It is taking an application-level piece of configuration data and requiring it to be treated as if it were crypto material. Which it cannot be, because multiple parties need to know it (as I said, the proxy, the backend, the app developers, the support team, etc).  It’s defense by “collapsing layers” rather than “in depth.”
>> As with all defense in depth, the aim is to be more than 1 configuration mistake away from total compromise.
>> But that is exactly what you are proposing. Exposing the header *is* a total compromise and multiple entities will need to know that header value.
>> At any rate,  I think we’re done here.
> _______________________________________________
> OAuth mailing list