FYI, in particular for those who are following the SVCB work. The lack of authentication for the results of SVCB discovery were a concern for me. I am not entirely comfortable with the idea that we are shipping a protocol without any real protection against downgrade attack. So I wrote up a rough draft.
My initial thinking was that this was general enough that TLS is the right venue, but I can also see reasons for having some discussion here. ----- Original message ----- From: Martin Thomson <m...@lowentropy.net> To: t...@ietf.org Subject: [TLS] Authenticating incompatible protocols Date: Tuesday, July 14, 2020 11:21 The work in DNSOP on the SVCB record raised a few awkward questions about the potential for downgrade attacks. Where protocols aren't compatible -- that is, A is not compatible with B if you can't attempt A and negotiate B -- you don't get downgrade protection. ALPN only really protects against downgrades with compatible protocols. With QUIC, and increasing diversity of protocol usage across TLS and DTLS, there are more opportunities for incompatible protocols to be used. I've done a quick writeup of something that might work: https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ https://martinthomson.github.io/snip/draft-thomson-tls-snip.html Thoughts would be appreciated. As a footnote: this makes some assumptions about the way that ALPN is used. That is, this relies on the same ALPN not being used in incompatible protocols. The ALPN registry already lists one counterexample in stun.turn [RFC7443] which can be used over both DTLS and TLS. I personally think that was a mistake, but I know that others disagree. _______________________________________________ TLS mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
