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

[Ben Schwartz <[e-mail]>]

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

> On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz <bemasc=
> [e-mail]> wrote:
>
>> 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.
>>
>
> 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.

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.
>
>
>> 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 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.
>

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".

> 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.
>>
>
> 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.

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.
>

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
> {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.
>

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.