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 <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
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
