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

[David Benjamin <[e-mail]>]

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.


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


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

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


> On Wed, Feb 16, 2022 at 12:36 AM Martin Thomson <[e-mail]> wrote:
>
>> 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, [e-mail] wrote:
>> > 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
>> >
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>