From nobody Thu Mar 18 05:07:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FE03A2977 for ; Thu, 18 Mar 2021 05:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pbql6VUJgPep for ; Thu, 18 Mar 2021 05:07:16 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2EA3A2976 for ; Thu, 18 Mar 2021 05:07:15 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id k10so3537184ejg.0 for ; Thu, 18 Mar 2021 05:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IBUVwf8Br4zmGHwlPQGLLtRxlnB1qZECLZzUwCfjsNg=; b=JwjmqUObZSjPw2uV38Gnd3ZL3HmJvGf0aA5nX65Lm1UlrIYxc2IbD5UTGH9J7r3zJc 9S59j6yK61iJPa+oD3xAywbNA902YMzkYO625zCDLjmHlqA5FgLOGXh7qjihu+++1JQZ QgrnJOKhUKvDTRsbllino0xGPJOy9EIX1q/4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IBUVwf8Br4zmGHwlPQGLLtRxlnB1qZECLZzUwCfjsNg=; b=R6p3Fas2Jh8hI7Q/Wx8EHP44tO2ZC+LwI92Adb9ll8NeAqcdKvb/IZYWLkl36w0Z4Y fRF5JOy3R09WarnSuH4Ln6LCybB5GizAL2uposqmnYkwd93IpymoK+pkYVGaYF8+DPjq FDCzuazw57rwxvfdboQPkaiUjO4KD3jWBBo37+eqH77TsDkq2F8HagNLc/SeOcbraj04 Pn5u2rkE1x2g/7ltUTVySvN0UxODKIK1EQuzalaactPhpU5sztvbG/l3QjMLcjBxpc2I x4CSg5DpdXh9vdisIzzZC86UPxX4AySV7TWmwZ77vI4D7OlSKKR3iHOkUbcgRP2FH3bC 2KTw== X-Gm-Message-State: AOAM530Vnbrlecv/XfyQ5aKlZpYV3FHUn4yB/7XYXp9Cu52s/k1uO7Ar +oXqxL7CTIHfPz8F5u5nfh/vzKdz6a8FVXLLLSVEdV1xcjiwMtRumVwstXpsfd/gs/sNJZzcgg= = X-Google-Smtp-Source: ABdhPJy5tV2VHY+QlkJqr3ZoqycPVUEGB/tZKpjZAXsN6TdofKWaw5SZSPQ8a8Sg5Ks0+BWXmkt0yg== X-Received: by 2002:a17:906:33da:: with SMTP id w26mr40551849eja.302.1616069233212; Thu, 18 Mar 2021 05:07:13 -0700 (PDT) Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id q12sm1702227ejy.91.2021.03.18.05.07.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Mar 2021 05:07:12 -0700 (PDT) From: Neil Madden Message-Id: <0860DA51-9C0C-49CF-8CE4-F90415CC6D0D@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Mar 2021 12:07:11 +0000 In-Reply-To: Cc: Andrii Deinega , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: multipart/alternative; boundary="Apple-Mail=_758B76AB-7E9E-4227-8782-C1DE8FFFC5A6" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org 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: Thu, 18 Mar 2021 12:07:19 -0000 --Apple-Mail=_758B76AB-7E9E-4227-8782-C1DE8FFFC5A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef wr= ote: >=20 > On Thu, Mar 18, 2021 at 3:45 AM Neil Madden > wrote: >=20 >=20 >> On 18 Mar 2021, at 05:33, Andrii Deinega > wrote: >>=20 >> =EF=BB=BF >> The Cache-Control header, even with its strongest directive "no-store", = is pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext = Transfer Protocol: Caching). >>=20 >> This directive is NOT a reliable or sufficient mechanism for ensuring pr= ivacy. In particular, malicious or compromised caches might not recognize = or obey this directive, and communications networks might be vulnerable to = eavesdropping. >=20 > This quote is about privacy. Your concerns so far have been about replay = protection. TLS protects both.=20 >=20 >>=20 >> Regarding TLS, I've mentioned that we don't always have the luxury to se= e what is going on with the infrastructure. A bright example would be an AS= implemented as a serverless application and hosted by one of the cloud pro= viders. >=20 > Right, but (as I=E2=80=99ve said before) the same reasoning applies to a = JWT too. The infrastructure could just as easily =E2=80=9Cterminate JWS=E2= =80=9D as it currently terminates TLS. As I keep saying, it=E2=80=99s much = better to spend your time ensuring end-to-end TLS than end-to-end JWT.=20 >=20 > That's not always possible. In some enterprises, they will have an inspec= tion middlebox that breaks the end-to-end TLS, e.g., ZScaler. And if you use encrypted JWTs to work around that you=E2=80=99ll soon have = inspection middleboxes that break end-to-end JWT. This isn=E2=80=99t a game= we can win by adding more layers of the same solution. =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail=_758B76AB-7E9E-4227-8782-C1DE8FFFC5A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On= 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:

On = Thu, Mar 18, 2021 at 3:45 AM Neil Madden <neil.madden@forgerock.com> wrote:

On 18 Mar 2021, at 05:33, = Andrii Deinega <andrii.deinega@gmail.com> wrote:

=EF=BB=BF
The Cache-Control = header, even with its strongest directive "no-store", is pretty naive prote= ction... Below is an excerpt from RFC 7234 (Hypertext Transfer Protoco= l: Caching).

This directive is NOT a reliable or sufficient mechanism= for ensuring privacy.  In particular, malicious or compromised caches= might not recognize or obey this directive, and communications networks mi= ght be vulnerable to eavesdropping.

This quote is abou= t privacy. Your concerns so far have been about replay protection. TLS prot= ects both. 

<= div dir=3D"ltr" class=3D"">

Regarding TLS, I've mentio= ned that we don't always have the luxury to see what is going on with = the infrastructure. A bright example would be an AS implemented a= s a serverless application and hosted by one of the cloud providers.
<= /div>

Right, but (as I=E2=80=99ve said before) the same reasoning applies= to a JWT too. The infrastructure could just as easily =E2=80=9Cterminate J= WS=E2=80=9D as it currently terminates TLS. As I keep saying, it=E2=80=99s = much better to spend your time ensuring end-to-end TLS than end-to-end JWT.=  

That's not always pos= sible. In some enterprises, they will have an inspection middlebox that bre= aks the end-to-end TLS, e.g., ZScaler.

And if you use encrypted JWTs to work around that you= =E2=80=99ll soon have inspection middleboxes that break end-to-end JWT. Thi= s isn=E2=80=99t a game we can win by adding more layers of the same solutio= n.

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail=_758B76AB-7E9E-4227-8782-C1DE8FFFC5A6--