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