On Thu, Mar 18, 2021 at 3:45 AM Neil Madden <neil.mad...@forgerock.com> wrote:
> > > On 18 Mar 2021, at 05:33, Andrii Deinega <andrii.dein...@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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
