On Mon, Nov 14, 2022 at 9:55 AM Alan DeKok <[email protected]> wrote:
> On Nov 14, 2022, at 12:43 PM, Eric Rescorla <[email protected]> wrote: > > I don't believe this is correct. > > I'd like to have a way to say "if you don't support session tickets, > just ignore them". > Again this text is not quite right because it is possible to have PSKs that are not session tickets, and you can't always tell whether a PSK is a ticket or not. Right now, the observed behaviour is "we don't support session tickets, > so we drop any TLS connection which uses them". > > This literally has world-wide implications for WiFi network access > today. It is actively preventing the use of TLS 1.3. > Can you explain how you got into this posture? The only reason a client should be sending session tickets is if it received one from the server. > I do think this document should make clear cases where you are supposed > to ignore specific unknown values. I think it does that for this, but if > you have other examples, please file an issue on RFC 8446-bis: > https://github.com/tlswg/tls13-spec/ > > I can file an issue there. But advice to "ignoring unknown values" is > substantially different from "tear down the TLS session when we see a known > extension which we don't plan to use". > In general, TLS has interpreted this kind of advice to include values which are known to the implementation but configured off, but if you have clearer text, I'm certainly open to it. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
