Re: [TLS] Authenticating incompatible protocols

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>