Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt
On Wed, Feb 23, 2022, at 09:31, Ben Schwartz wrote: > 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. So this "MUST/SHOULD omit compatible protocols" is really only there to do as David suggests: reduce variation. I don't think that we need it for correctness. I'm inclined to loosen this to a SHOULD. It's a little awkward in the sense that clients and servers might disagree about what protocols are compatible. That is - for QUIC at least - we allow for compatibility to be defined separately from the protocol, which means that some implementations might believe that a protocol is compatible when it is not. This leads to clients including things in ALPN that the server might also include in SNIP. https://github.com/tlswg/snip/pull/9 Ben's point about ALPN is well-taken though. This very much does assume that ALPN is in use. Indeed, it makes very little sense without it. So I'm going to suggest that we mandate it directly: https://github.com/tlswg/snip/pull/8 As for the appendix, I wonder if it is better left out entirely. I almost cut it last time, and this discussion makes me think that might be the easiest way out. There are some philosophical differences here that we should probably continue to discuss, but we don't need to resolve them if we agree about the conclusion (which is to do this validation in TLS and not rely on DNSSEC). https://github.com/tlswg/snip/pull/10 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt
On Tue, Feb 22, 2022 at 4:23 PM David Benjamin
wrote:
> On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz 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.
>
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 operato
Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt
On Tue, Feb 22, 2022 at 3:58 PM Ben Schwartz 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 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 prot
Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt
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 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
Re: [TLS] I-D Action: draft-ietf-tls-snip-01.txt
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] I-D Action: draft-ietf-tls-snip-01.txt
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
