On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz <bemasc=
40google....@dmarc.ietf.org> 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 <m...@lowentropy.net> 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, internet-dra...@ietf.org 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
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
