Subject: [TLS] I-D Action: draft-ietf-tls-snip-01.txt

From: [email-masked]
Date: Tue, 15 Feb 2022 21:30:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Secure Negotiation of Incompatible Protocols in TLS
        Author          : Martin Thomson
	Filename        : draft-ietf-tls-snip-01.txt
	Pages           : 12
	Date            : 2022-02-15

Abstract:
   An extension is defined for TLS that allows a client and server to
   detect an attempt to force the use of less-preferred application
   protocol even where protocol options are incompatible.  This
   supplements application-layer protocol negotiation (ALPN), which
   allows choices between compatible protocols to be authenticated.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-snip/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-snip-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-snip-01

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 16 Feb 2022 16:35:41 +1100

Hey everyone,

This is a keep-alive update for the most part.

I spent an hour or so trying to do improve the readability of the draft.  So it will look like a lot has changed as I rewrote large chunks, removed a fair bit, and moved whole sections.  All of that is with a goal of making the content more accessible.  Happy to hear how people feel that went and how it might be improved further.

Cheers,
Martin

On Wed, Feb 16, 2022, at 16:30, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 22 Feb 2022 15:58:31 -0500

I continue to support this draft.

I am puzzled by the requirement that "A server MUST omit any compatible
protocols from this extension".  Including them seems harmless, and
omitting them seems to impose an unstated requirement that (1) both parties
also include the ALPN extension and (2) the implementations of these
extensions must be intertwined.  I would change this to SHOULD.

Appendix C assumes that SVCB records are not authenticated.  That's allowed
by SVCB, but it's not required.  A client with authenticated SVCB records
(e.g. via DNSSEC) is not vulnerable to these attacks, and SNIP would
arguably be redundant in that case.  I don't think it's fair to claim that
DNSSEC is "impractical", as implied by this text.  ("often impractical"
might be fine.)

Also, the bullets underneath have some issues:

> it is not possible to ensure that all server instances in a deployment
have the same protocol configuration, as deployments for a single name
routinely include multiple providers that cannot coordinate closely;

This is not a problem.  The differently-configured servers would be
represented by different RRs in the RRSet.

> the ability to provide a subset of valid DNS records is integral to many
strategies for managing servers

Perhaps, but only the authoritative server is allowed to make these
judgments, and it must happen before DNSSEC signing (which signs the entire
RRSet as an indivisible unit).

> ensuring that cached DNS records are synchronized with server state is
challenging in a number of deployments.

SVCB contents are required to be accurate.  They might be conservative (not
offering all supported protocols), but they can't be optimistic (promising
protocols that aren't actually supported everywhere).  Perhaps there is
some SNIP use case where the client is excited to learn that this server
supports some as-yet-unannounced protocol, but it's not the main SNIP use
case.

On Wed, Feb 16, 2022 at 12:36 AM Martin Thomson <[email-masked]> wrote:

> I spent an hour or so trying to do improve the readability of the draft.
> So it will look like a lot has changed as I rewrote large chunks, removed a
> fair bit, and moved whole sections.  All of that is with a goal of making
> the content more accessible.  Happy to hear how people feel that went and
> how it might be improved further.
>
> Cheers,
> Martin
>
>

---

From: David Benjamin <[email-masked]>
Date: Tue, 22 Feb 2022 16:23:00 -0500

> extensions must be intertwined.  I would change this to SHOULD.

We shouldn't add variation to protocols just because they are (immediately)
harmless. Unless there's a strong reason for some implementations to
include them and others to omit them, we shouldn't use a SHOULD.

> Appendix C assumes that SVCB records are not authenticated.  That's
> allowed by SVCB, but it's not required.  A client with authenticated SVCB
> records (e.g. via DNSSEC) is not vulnerable to these attacks, and SNIP
> would arguably be redundant in that case.  I don't think it's fair to claim
> that DNSSEC is "impractical", as implied by this text.  ("often
> impractical" might be fine.)
>

SNIP would still not be redundant because of the deployment issues listed
below.

> represented by different RRs in the RRSet.

The bullet point is correct, though the "multiple providers" explanation
may not be the best one. When a change is rolled out or rolled back across
a server deployment, there will unavoidable a period when the server
deployment is non-uniform.

> SVCB contents are required to be accurate.  They might be conservative
> (not offering all supported protocols), but they can't be optimistic
> (promising protocols that aren't actually supported everywhere).  Perhaps
> there is some SNIP use case where the client is excited to learn that this
> server supports some as-yet-unannounced protocol, but it's not the main
> SNIP use case.
>

DNS is too far removed from the true server state for that to be plausible.
Indeed we went through quite a lot of trouble in ECH specifically to
tolerate inaccurate SVCB contents. I don't think the conservative vs.
optimistic classification works either. A service may need to rollback a
change due to an unanticipated issue somewhere in the system. In addition
to the period of non-uniformity above, the cached SVCB record will be
"optimistic" post-rollback.

But this is fine because we do *not* require SVCB ALPN lists to be
perfectly accurate. We fixed the broken Alt-Svc ALPN rules in SVCB to
effectively remove SVCB's influence on the authoritative protocol
selection. That must stay in TLS, for security and deployment reasons. If
SVCB says a server supports {h2, http/1.1} but it really only supports
{http/1.1}, it will continue working because "h2" and "http/1.1", at this
layer, effectively don't fix the exact protocol, just the set of compatible
protocols. That is, they are mostly just a funny way to say "TCP + TLS +
HTTP/??".

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 22 Feb 2022 17:31:53 -0500

On Tue, Feb 22, 2022 at 4:23 PM David Benjamin <[email-masked]>
wrote:

> We shouldn't add variation to protocols just because they are
> (immediately) harmless. Unless there's a strong reason for some
> implementations to include them and others to omit them, we shouldn't use a
> SHOULD.
>

In TLS, I think "MUST" means "recipients should validate this if possible
and fail the handshake if there is a mismatch".  Consider a client
implementation.  Upon receipt of a SNIP response, is it supposed to
cross-check the SNIP answer vs. the ALPN offer, and fail if there is
intersection?  This seems needlessly complicated.

> deployment is non-uniform.

Neither SNIP nor authenticated SVCB can defend against an incompatible
downgrade of transport X until all RRs in the SVCB response support
transport X.  (An attacker can force fallback between SVCB RRs.)  The
bullet point is accurate, but it's not something that SNIP addresses, so it
doesn't help to explain why authenticated SVCB is "impractical".

> DNS is too far removed from the true server state for that to be
> plausible. Indeed we went through quite a lot of trouble in ECH
> specifically to tolerate inaccurate SVCB contents. I don't think the
> conservative vs. optimistic classification works either. A service may need
> to rollback a change due to an unanticipated issue somewhere in the system.
> In addition to the period of non-uniformity above, the cached SVCB record
> will be "optimistic" post-rollback.
>

I should have said "SVCB ALPN contents".  A SVCB record that claims an ALPN
that is not actually supported by all the servers it points to is
non-compliant.  This means you can't start offering a new ALPN in SVCB
until you're sure it's fully rolled out and going to stay that way for at
least a few minutes-hours.  I really can't imagine a situation where that
is a problem.

> selection. That must stay in TLS, for security and deployment reasons.
>

Yes, SVCB's ALPN list does not affect the list of ALPNs offered by the
client once a transport is selected.

> If SVCB says a server supports {h2, http/1.1} but it really only supports
> protocols.

No, because HTTP/2 clients are not obligated to implement HTTP/1.1.  As a
server operator, suppose I offer two RRs:
1. An H1-only endpoint mislabeled as supporting H2 and H1.
2. An H2-only endpoint labeled as H2-only.

An H2-only client is permitted to try the first one, detect ALPN failure,
and abandon the whole connection attempt.  (It has at most a SHOULD-level
recommendation to fall back to another RR.)  Thus, in order to be
compatible with all compliant clients, each RR must contain only ALPN
values that are actually fully supported.

Optimistic claims about ALPN support are likely to be tolerated in
practice, but they are not spec-compliant.

> That is, they are mostly just a funny way to say "TCP + TLS + HTTP/??".
>

Yes, except that they're also an advertisement about which RRs are
compatible with you, and this advertisement is required to be accurate.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Feb 2022 11:45:22 +1100

On Wed, Feb 23, 2022, at 09:31, Ben Schwartz wrote:
> In TLS, I think "MUST" means "recipients should validate this if 
> possible and fail the handshake if there is a mismatch".  Consider a 
> client implementation.  Upon receipt of a SNIP response, is it supposed 
> to cross-check the SNIP answer vs. the ALPN offer, and fail if there is 

So this "MUST/SHOULD omit compatible protocols" is really only there to do as David suggests: reduce variation.  I don't think that we need it for correctness.  I'm inclined to loosen this to a SHOULD.

It's a little awkward in the sense that clients and servers might disagree about what protocols are compatible.  That is - for QUIC at least - we allow for compatibility to be defined separately from the protocol, which means that some implementations might believe that a protocol is compatible when it is not.  This leads to clients including things in ALPN that the server might also include in SNIP.

https://github.com/tlswg/snip/pull/9

Ben's point about ALPN is well-taken though.  This very much does assume that ALPN is in use.  Indeed, it makes very little sense without it.  So I'm going to suggest that we mandate it directly:

https://github.com/tlswg/snip/pull/8

As for the appendix, I wonder if it is better left out entirely.  I almost cut it last time, and this discussion makes me think that might be the easiest way out.  There are some philosophical differences here that we should probably continue to discuss, but we don't need to resolve them if we agree about the conclusion (which is to do this validation in TLS and not rely on DNSSEC).

https://github.com/tlswg/snip/pull/10