Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

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:
>
> 
> 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).
>
> 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 might be
>> vulnerable to eavesdropping.
>
>
> This quote is about privacy. Your concerns so far have been about replay
> protection. TLS protects both.
>
>
> Regarding TLS, I've mentioned 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 as a serverless application and hosted by one of the cloud
> providers.
>
>
> Right, but (as I’ve said before) the same reasoning applies to a JWT too.
> The infrastructure could just as easily “terminate JWS” as it currently
> terminates TLS. As I keep saying, it’s much better to spend your time
> ensuring end-to-end TLS than end-to-end JWT.
>

That's not always possible. In some enterprises, they will have an
inspection middlebox that breaks the end-to-end TLS, e.g., ZScaler.

Regards,
 Rifaat

> We should try to avoid writing specs just to work around badly configured
> infrastructure.
>
> (The counterexample to this is IoT applications, where messages often have
> to traverse protocol-translating proxies. But that’s not the case here).
>
>
> As for,
>
> Right - so trying to solve this issue by replacing TLS with another
>> technology that is just as susceptible to the problem is not a real
>> solution.
>
>
> Following your logic, other RFCs such as 8555 (Automatic Certificate
> Management Environment) went the wrong way with their mandatory anti-replay
> built-in mechanism in quite similar circumstances.
>
> https://tools.ietf.org/html/rfc8555#section-6.5
>
>
> The only justification of the replay nonce given in RFC8555 is for
> protection of 0RTT early-data (which does not benefit from TLS’s normal
> replay protections). As to why a protocol that can typically tolerate
> latencies of several weeks (for cert renewal) needs 0RTT, you’ll have to
> ask the authors of that RFC. It makes little sense to me.
>
> — Neil
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>