Subject: [TLS] Authenticating incompatible protocols

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Jul 2020 11:21:24 +1000

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.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Jul 2020 18:53:40 -0400

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 15 Jul 2020 16:25:08 +1000

On Wed, Jul 15, 2020, at 08:53, Ben Schwartz wrote:
> 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.  

I don't think that it is that bad.  It is more that server operators need to understand that the ways in which they advertise the availability of their service interacts with what is deployed.  That is, you need to configure discovery methods and your TLS stacks with the same information (though your TLS configuration can be more conservative in terms of advertising a subset of what can be discovered, so that deployments can be staged).

Right now, that means that if you use SVCB, you should configure your TLS stack to authenticate that.  This might eventually include QUIC versions as well - once that is sorted out - but that won't require the same sort of coordination.

The problem with more detailed indications is that it requires far more configuration.  The TLS stack doesn't just need to know that FOO is available, it needs to know where.  As that is usually the business of the DNS provisioning more than the TLS configuration, I'm concerned that you would get out of sync too easily.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Jul 2020 16:52:35 -0400

On Wed, Jul 15, 2020 at 2:25 AM Martin Thomson <[email-masked]> wrote:
...

> you need to configure discovery methods and your TLS stacks with the same
> information (though your TLS configuration can be more conservative in
> terms of advertising a subset of what can be discovered, so that
> deployments can be staged).

If there are multiple ways to reach your server (multiple applicable
scopes), you have to be even more conservative: you can only advertise the
_intersection_ of supported protocols from all possible scopes.  The
ClientHello doesn't tell the server which scope the client has.

Basically, I think this draft should probably either name the scope or be
specific to SVCB, to avoid cases where the scope is ambiguous.  Naming the
scope, and providing a scope identifier meaning "IP and port number", would
often be sufficient for secure QUIC upgrade without SVCB, at the cost of
some conceptual complexity.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Jul 2020 11:26:25 +1000

On Thu, Jul 16, 2020, at 06:52, Ben Schwartz wrote:
> Basically, I think this draft should probably either name the scope or 
> be specific to SVCB, to avoid cases where the scope is ambiguous.  
> Naming the scope, and providing a scope identifier meaning "IP and port 
> number", would often be sufficient for secure QUIC upgrade without 
> SVCB, at the cost of some conceptual complexity.

It took me a while to think this through.  tl;dr, I agree with your conclusion.

Written up in a longer form as an issue: https://github.com/martinthomson/snip/issues/1