I am supportive of this draft. I don't think it's needed now, but eventually I would like to live in a world where we don't have to tolerate these kinds of downgrades, and I don't think it's too early to be drawing up the mechanism to prevent them.
For ease of deployment, I wonder whether the concept of a "scope" needs to be pinned down a bit more precisely. In 00 here, the scope is entirely implicit; servers are required to know how users might have found them, and what other servers they also might have found at the same time. That seems like it could be a management headache, especially if clients reach your server in more than one way. Could the scope be made more explicit instead? For example, it might be helpful if the server could say "this IP (and port number?) can also do FOO and BAR, and the whole SVCB pool can do FOO (but I don't know if they can all do BAR)". On Mon, Jul 13, 2020 at 9:22 PM Martin Thomson <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
