Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT
On Tue, Feb 22, 2022 at 8:39 PM Benjamin Kaduk wrote: > On Tue, Feb 22, 2022 at 08:27:02PM -0500, Shumon Huque wrote: > > On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > I noticed that the "dnssec_chain" extension in the IANA registry lists > > > only "CH" in the "TLS 1.3" column. However, the extension sends its > > > response in the certificate message (section 2.2), so I think that > > > column should read "CH, CT". > > > > > > > You are right, Ilari. > > > > What's the process to get the IANA registry corrected? > > It is probably "best" (for some definition of "best") to publish an RFC > that Updates: 9102 and has the revised directive to IANA. > Ouch! > Probably an errata report should be filed against RFC 9102 regardless. > IANA might be able to use the errata report without the updating RFC, > but you'd have to ask. > Let's see if this path works first. Shumon. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT
On Tue, Feb 22, 2022 at 08:27:02PM -0500, Shumon Huque wrote: > On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara > wrote: > > > I noticed that the "dnssec_chain" extension in the IANA registry lists > > only "CH" in the "TLS 1.3" column. However, the extension sends its > > response in the certificate message (section 2.2), so I think that > > column should read "CH, CT". > > > > You are right, Ilari. > > What's the process to get the IANA registry corrected? It is probably "best" (for some definition of "best") to publish an RFC that Updates: 9102 and has the revised directive to IANA. Probably an errata report should be filed against RFC 9102 regardless. IANA might be able to use the errata report without the updating RFC, but you'd have to ask. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT
On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara wrote: > I noticed that the "dnssec_chain" extension in the IANA registry lists > only "CH" in the "TLS 1.3" column. However, the extension sends its > response in the certificate message (section 2.2), so I think that > column should read "CH, CT". > You are right, Ilari. What's the process to get the IANA registry corrected? Shumon. ___ 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 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
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
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] tlsflags and "responses"
I think it would probably be better to require it to be sent even if empty. Then you could measure how often it was implemented. On Mon, Feb 21, 2022 at 9:36 PM Yoav Nir wrote: > I have just submitted PR #20 to allow unacknowledged flags. It is a > rewrite of section 3 (rules) > > https://github.com/tlswg/tls-flags/pull/20 > > It still requires that the flag extension not be sent when empty. Let me > know if that’s a problem as well. > > Yoav > > On 21 Feb 2022, at 2:21, Martin Thomson wrote: > > I missed this text in draft-ietf-tls-tlsflags: > > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. > > While sloppy on my part [1], I want to make it clear that this is a > show-stopper for me. Requiring an echo prevents a flag extension from > attaching semantics to a "response". > > I agree with Ilari's earlier point that these should work just like > extensions. If the server has no need to echo a flag, it should not be > required to do that. That allows the flag value in a "response" to carry > semantics. > > Cheers, > Martin > > [1] I missed this in the second WGLC, though in my defense, I don't think > the resolution and changes resulting from the first WGLC were very clearly > communicated. > > ___ > 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
