Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

Yes, that fully addresses my concern. Thanks!

Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla 

>
> Hi Ted,
>
> Doesn't this section of RFC 9460 address this case and say what you are
> recommending:
>
> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1
>
> -Ekr
>
>
>
> On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:
>
>> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
>> that you may or may not be doing DNSSEC validation. And you may or may not
>> be /able/ to do DNSSEC validation if the infrastructure breaks it
>> accidentally or deliberately.
>>
>> The document says: "The SVCB-optional client behavior specified in
>> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
>> if all SVCB options fail. This behavior is not suitable for ECH, because
>> fallback would negate the privacy benefits of ECH."
>>
>> So it's saying that the default handling of SVCB is incorrect and would
>> fail open, and overriding that behavior. Given that this is the case, that
>> implies that it matters whether the data has been validated, but nowhere in
>> the document, certainly not in Security Considerations, is any mention made
>> of this issue. So that's what I'm pointing out.
>>
>> It is absolutely not the case in practice that all stub resolvers do
>> validation. You are making a security decision about trust based on data
>> the trustworthiness of which you've not discussed, in a situation where the
>> implementor has meaningful choices to make with respect to validating that
>> trustworthiness. So it's worth mentioning that if the policy is not to
>> validate, this vulnerability exists.
>>
>> I'm a DNS guy, not a TLS guy, so I don't know the history of this
>> work—I'm just making this observation about the document I was asked to
>> review. The fact that (apparently) no DNSDIR review ever raised this issue
>> about the other documents you mentioned is of no interest to me—I'm not
>> reviewing those documents.Whether you take this advice is between you and
>> the IESG. I'm not even claiming to be right—just pointing out the issue I
>> see.
>>
>> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>>
>>> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
>>> or you can fail during ECH (unless you want to use non-ECH, which is not
>>> ECH, and not part of this draft).
>>>
>>> It makes sense to me: one can reject a request unless the requirements
>>> embedded in the SVCB are met (the server chooses those, which can include
>>> many aspects of the request). I don't understand why one would insert
>>> DNSSEC here. That seems to be the whole point--it works without it.
>>>
>>> thanks,
>>> Rob
>>>
>>>
>>> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>>>
 I'm not telling you that you have to require DNSSEC. I'm saying the
 document is incomplete if you don't talk about how it relates to DNSSEC. I
 think EKR got the point, so maybe go with his approach?

 On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:

> It's a policy choice, though, right? I think ekr hinted at this issue
> as well.
>
> It's that one might also view requests that reveal the SNI as
> insecure. If that's the case, DNSSEC doesn't help. There will certainly be
> a transition period where that will be impractical for many servers. I
> think these are separate problems, though.
>
> thanks,
> Rob
>
>
> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>
>> It looks like if you can't get the SCVB you're going to fail
>> insecure, so being able to use DNSSEC to prevent that for signed domains
>> seems worthwhile.
>>
>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>
>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>> nore...@ietf.org> wrote:
>>>

 I don't think it's reasonable to specify the privacy properties of
 SVCB and
 /not/ talk about DNSSEC validation.

>>>
>>> Could you explain more about this part? I think DNSSEC doesn't add
>>> much here, unless you want to accept non-ECH traffic. For example, many 
>>> of
>>> the test servers will bounce you to some other site if you don't send 
>>> ECH
>>> or screw it up in some way (speaking as someone who has screwed it up 
>>> many
>>> times...).
>>>
>>> I think there might be a DoS attack here, where someone messes with
>>> the response, but they can also turn off the DNSSEC bit unless it's
>>> DoT/DoH/DoQ etc. So, if using those, it's just the trustworthiness of 
>>> the
>>> DNS server itself, right? Sorry if I'm missing something.
>>>
>>> thanks,
>>> Rob
>>>
>>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Eric Rescorla]

Hi Ted,

Doesn't this section of RFC 9460 address this case and say what you are
recommending:

https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1

-Ekr



On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon  wrote:

> Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
> that you may or may not be doing DNSSEC validation. And you may or may not
> be /able/ to do DNSSEC validation if the infrastructure breaks it
> accidentally or deliberately.
>
> The document says: "The SVCB-optional client behavior specified in
> (Section 3 of [SVCB]) permits clients to fall back to a direct connection
> if all SVCB options fail. This behavior is not suitable for ECH, because
> fallback would negate the privacy benefits of ECH."
>
> So it's saying that the default handling of SVCB is incorrect and would
> fail open, and overriding that behavior. Given that this is the case, that
> implies that it matters whether the data has been validated, but nowhere in
> the document, certainly not in Security Considerations, is any mention made
> of this issue. So that's what I'm pointing out.
>
> It is absolutely not the case in practice that all stub resolvers do
> validation. You are making a security decision about trust based on data
> the trustworthiness of which you've not discussed, in a situation where the
> implementor has meaningful choices to make with respect to validating that
> trustworthiness. So it's worth mentioning that if the policy is not to
> validate, this vulnerability exists.
>
> I'm a DNS guy, not a TLS guy, so I don't know the history of this work—I'm
> just making this observation about the document I was asked to review. The
> fact that (apparently) no DNSDIR review ever raised this issue about the
> other documents you mentioned is of no interest to me—I'm not reviewing
> those documents.Whether you take this advice is between you and the IESG.
> I'm not even claiming to be right—just pointing out the issue I see.
>
> On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:
>
>> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
>> or you can fail during ECH (unless you want to use non-ECH, which is not
>> ECH, and not part of this draft).
>>
>> It makes sense to me: one can reject a request unless the requirements
>> embedded in the SVCB are met (the server chooses those, which can include
>> many aspects of the request). I don't understand why one would insert
>> DNSSEC here. That seems to be the whole point--it works without it.
>>
>> thanks,
>> Rob
>>
>>
>> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>>
>>> I'm not telling you that you have to require DNSSEC. I'm saying the
>>> document is incomplete if you don't talk about how it relates to DNSSEC. I
>>> think EKR got the point, so maybe go with his approach?
>>>
>>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>>
 It's a policy choice, though, right? I think ekr hinted at this issue
 as well.

 It's that one might also view requests that reveal the SNI as insecure.
 If that's the case, DNSSEC doesn't help. There will certainly be a
 transition period where that will be impractical for many servers. I think
 these are separate problems, though.

 thanks,
 Rob


 On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:

> It looks like if you can't get the SCVB you're going to fail insecure,
> so being able to use DNSSEC to prevent that for signed domains seems
> worthwhile.
>
> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>
>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>>
>>> I don't think it's reasonable to specify the privacy properties of
>>> SVCB and
>>> /not/ talk about DNSSEC validation.
>>>
>>
>> Could you explain more about this part? I think DNSSEC doesn't add
>> much here, unless you want to accept non-ECH traffic. For example, many 
>> of
>> the test servers will bounce you to some other site if you don't send ECH
>> or screw it up in some way (speaking as someone who has screwed it up 
>> many
>> times...).
>>
>> I think there might be a DoS attack here, where someone messes with
>> the response, but they can also turn off the DNSSEC bit unless it's
>> DoT/DoH/DoQ etc. So, if using those, it's just the trustworthiness of the
>> DNS server itself, right? Sorry if I'm missing something.
>>
>> thanks,
>> Rob
>>
>> ___
> 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

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

Okay, I think I see the disconnect, maybe. The issue I'm pointing to is
that you may or may not be doing DNSSEC validation. And you may or may not
be /able/ to do DNSSEC validation if the infrastructure breaks it
accidentally or deliberately.

The document says: "The SVCB-optional client behavior specified in (Section
3 of [SVCB]) permits clients to fall back to a direct connection if all
SVCB options fail. This behavior is not suitable for ECH, because fallback
would negate the privacy benefits of ECH."

So it's saying that the default handling of SVCB is incorrect and would
fail open, and overriding that behavior. Given that this is the case, that
implies that it matters whether the data has been validated, but nowhere in
the document, certainly not in Security Considerations, is any mention made
of this issue. So that's what I'm pointing out.

It is absolutely not the case in practice that all stub resolvers do
validation. You are making a security decision about trust based on data
the trustworthiness of which you've not discussed, in a situation where the
implementor has meaningful choices to make with respect to validating that
trustworthiness. So it's worth mentioning that if the policy is not to
validate, this vulnerability exists.

I'm a DNS guy, not a TLS guy, so I don't know the history of this work—I'm
just making this observation about the document I was asked to review. The
fact that (apparently) no DNSDIR review ever raised this issue about the
other documents you mentioned is of no interest to me—I'm not reviewing
those documents.Whether you take this advice is between you and the IESG.
I'm not even claiming to be right—just pointing out the issue I see.

On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre  wrote:

> I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure)
> or you can fail during ECH (unless you want to use non-ECH, which is not
> ECH, and not part of this draft).
>
> It makes sense to me: one can reject a request unless the requirements
> embedded in the SVCB are met (the server chooses those, which can include
> many aspects of the request). I don't understand why one would insert
> DNSSEC here. That seems to be the whole point--it works without it.
>
> thanks,
> Rob
>
>
> On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:
>
>> I'm not telling you that you have to require DNSSEC. I'm saying the
>> document is incomplete if you don't talk about how it relates to DNSSEC. I
>> think EKR got the point, so maybe go with his approach?
>>
>> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>>
>>> It's a policy choice, though, right? I think ekr hinted at this issue as
>>> well.
>>>
>>> It's that one might also view requests that reveal the SNI as insecure.
>>> If that's the case, DNSSEC doesn't help. There will certainly be a
>>> transition period where that will be impractical for many servers. I think
>>> these are separate problems, though.
>>>
>>> thanks,
>>> Rob
>>>
>>>
>>> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>>>
 It looks like if you can't get the SCVB you're going to fail insecure,
 so being able to use DNSSEC to prevent that for signed domains seems
 worthwhile.

 On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:

> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>>
>> I don't think it's reasonable to specify the privacy properties of
>> SVCB and
>> /not/ talk about DNSSEC validation.
>>
>
> Could you explain more about this part? I think DNSSEC doesn't add
> much here, unless you want to accept non-ECH traffic. For example, many of
> the test servers will bounce you to some other site if you don't send ECH
> or screw it up in some way (speaking as someone who has screwed it up many
> times...).
>
> I think there might be a DoS attack here, where someone messes with
> the response, but they can also turn off the DNSSEC bit unless it's
> DoT/DoH/DoQ etc. So, if using those, it's just the trustworthiness of the
> DNS server itself, right? Sorry if I'm missing something.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Rob Sayre]

I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure) or
you can fail during ECH (unless you want to use non-ECH, which is not ECH,
and not part of this draft).

It makes sense to me: one can reject a request unless the requirements
embedded in the SVCB are met (the server chooses those, which can include
many aspects of the request). I don't understand why one would insert
DNSSEC here. That seems to be the whole point--it works without it.

thanks,
Rob


On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon  wrote:

> I'm not telling you that you have to require DNSSEC. I'm saying the
> document is incomplete if you don't talk about how it relates to DNSSEC. I
> think EKR got the point, so maybe go with his approach?
>
> On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:
>
>> It's a policy choice, though, right? I think ekr hinted at this issue as
>> well.
>>
>> It's that one might also view requests that reveal the SNI as insecure.
>> If that's the case, DNSSEC doesn't help. There will certainly be a
>> transition period where that will be impractical for many servers. I think
>> these are separate problems, though.
>>
>> thanks,
>> Rob
>>
>>
>> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>>
>>> It looks like if you can't get the SCVB you're going to fail insecure,
>>> so being able to use DNSSEC to prevent that for signed domains seems
>>> worthwhile.
>>>
>>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>>
 On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
 nore...@ietf.org> wrote:

>
> I don't think it's reasonable to specify the privacy properties of
> SVCB and
> /not/ talk about DNSSEC validation.
>

 Could you explain more about this part? I think DNSSEC doesn't add much
 here, unless you want to accept non-ECH traffic. For example, many of the
 test servers will bounce you to some other site if you don't send ECH or
 screw it up in some way (speaking as someone who has screwed it up many
 times...).

 I think there might be a DoS attack here, where someone messes with the
 response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
 etc. So, if using those, it's just the trustworthiness of the DNS server
 itself, right? Sorry if I'm missing something.

 thanks,
 Rob


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

I'm not telling you that you have to require DNSSEC. I'm saying the
document is incomplete if you don't talk about how it relates to DNSSEC. I
think EKR got the point, so maybe go with his approach?

On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre  wrote:

> It's a policy choice, though, right? I think ekr hinted at this issue as
> well.
>
> It's that one might also view requests that reveal the SNI as insecure. If
> that's the case, DNSSEC doesn't help. There will certainly be a transition
> period where that will be impractical for many servers. I think these are
> separate problems, though.
>
> thanks,
> Rob
>
>
> On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:
>
>> It looks like if you can't get the SCVB you're going to fail insecure, so
>> being able to use DNSSEC to prevent that for signed domains seems
>> worthwhile.
>>
>> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>>
>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>> nore...@ietf.org> wrote:
>>>

 I don't think it's reasonable to specify the privacy properties of SVCB
 and
 /not/ talk about DNSSEC validation.

>>>
>>> Could you explain more about this part? I think DNSSEC doesn't add much
>>> here, unless you want to accept non-ECH traffic. For example, many of the
>>> test servers will bounce you to some other site if you don't send ECH or
>>> screw it up in some way (speaking as someone who has screwed it up many
>>> times...).
>>>
>>> I think there might be a DoS attack here, where someone messes with the
>>> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
>>> etc. So, if using those, it's just the trustworthiness of the DNS server
>>> itself, right? Sorry if I'm missing something.
>>>
>>> thanks,
>>> Rob
>>>
>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Rob Sayre]

It's a policy choice, though, right? I think ekr hinted at this issue as
well.

It's that one might also view requests that reveal the SNI as insecure. If
that's the case, DNSSEC doesn't help. There will certainly be a transition
period where that will be impractical for many servers. I think these are
separate problems, though.

thanks,
Rob


On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon  wrote:

> It looks like if you can't get the SCVB you're going to fail insecure, so
> being able to use DNSSEC to prevent that for signed domains seems
> worthwhile.
>
> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:
>
>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>>
>>> I don't think it's reasonable to specify the privacy properties of SVCB
>>> and
>>> /not/ talk about DNSSEC validation.
>>>
>>
>> Could you explain more about this part? I think DNSSEC doesn't add much
>> here, unless you want to accept non-ECH traffic. For example, many of the
>> test servers will bounce you to some other site if you don't send ECH or
>> screw it up in some way (speaking as someone who has screwed it up many
>> times...).
>>
>> I think there might be a DoS attack here, where someone messes with the
>> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
>> etc. So, if using those, it's just the trustworthiness of the DNS server
>> itself, right? Sorry if I'm missing something.
>>
>> thanks,
>> Rob
>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

It looks like if you can't get the SCVB you're going to fail insecure, so
being able to use DNSSEC to prevent that for signed domains seems
worthwhile.

On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre  wrote:

> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>>
>> I don't think it's reasonable to specify the privacy properties of SVCB
>> and
>> /not/ talk about DNSSEC validation.
>>
>
> Could you explain more about this part? I think DNSSEC doesn't add much
> here, unless you want to accept non-ECH traffic. For example, many of the
> test servers will bounce you to some other site if you don't send ECH or
> screw it up in some way (speaking as someone who has screwed it up many
> times...).
>
> I think there might be a DoS attack here, where someone messes with the
> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
> etc. So, if using those, it's just the trustworthiness of the DNS server
> itself, right? Sorry if I'm missing something.
>
> thanks,
> Rob
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon]

That seems okay. Would be good to document in the security considerations.

On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla  wrote:

>
>
> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Ted Lemon
>> Review result: Almost Ready
>>
>> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>>
>> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
>> which
>> is surprising given that the draft proposes privacy properties for SVCB
>> responses containing ECH data. I would think that it would make sense to
>> say
>> that the SVCB querier should attempt to validate the response, and then
>> talk
>> about what to do for bogus, insecure and valid positive and negative
>> responses.
>>
>> For example, I would think that a /bogus/ response should be taken to
>> mean that
>> the SVCB record must be assumed to exist and should be treated the same
>> as if
>> the list of destinations were not reachable. An /insecure/ NXDOMAIN or
>> NODATA
>> response would not provide this assurance, and so what is currently
>> described
>> in the document makes sense for this case. A /valid/ NXDOMAIN would
>> assure that
>> no SVCB record existed, and hence ECH is not available.
>>
>> I don't think it's reasonable to specify the privacy properties of SVCB
>> and
>> /not/ talk about DNSSEC validation.
>>
>
> I could see that there might be an objection that if DNSSEC isn't working
>> at a
>> particular site because of a broken DNS resolver, this would prevent
>> connecting
>> to perfectly acceptable destinations simply because of general DNSSEC
>> breakage,
>> not a specific attack on this specific domain. The problem is that
>> there's no
>> way to distinguish this from an attack. So if this exception is allowed,
>> the
>> security considerations section should talk about what the risks are of
>> allowing it. E.g. if we succeed in validing the root and com, but can't
>> validate the zone containing the SVCB (or determine that it's not
>> signed), that
>> would be a clear indication of an attack, but if we can't validate the
>> root, it
>> could just be brokenness, and an attacker would do well to just prevent
>> all
>> validation so that we can't distinguish.
>
>
> Thanks for your comments.
>
> While I agree that SVCB being bogus deserves some consideration. I don't
> think this
> resolutions is *quite* correct. In general, TLS and HTTP don't take a
> position
> on what if any DNSSEC validation is to be done or what to do in response to
> failures.
>
> The new angle here is that there are two queries, and so it is possible
> for the
> A/ queries to produce a valid response but the SVCB to produce a bogus
> one, which might be used by an attacker to disable ECH. What I would say
> here
> is that a bogus SVCB should be handled in the same way as if A/ were
> bogus.
> So if you would normally fail the resolution, you should do that, but if
> you would
> normally log and move on, then you should do that.
>
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Reviving draft-zauner-tls-aes-ocb?

[Tony Arcieri]

For those who are unfamiliar, the "pitch" of OCB mode is that it's fast
everywhere: on servers, desktops, smartphones, and low-power IoT devices
with some sort of hardware-accelerated block cipher, whereas currently GCM
is popular on higher-power devices like servers/desktops/smartphones
whereas the IoT/embedded space frequently uses CCM to be able to offload
encryption onto hardware accelerators instead of an MCU (where OCB would
double performance by cutting the number of block cipher invocations in
half).

This draft to add OCB ciphersuites to TLS expired in 2016:

https://datatracker.ietf.org/doc/html/draft-zauner-tls-aes-ocb

However, in the intervening time, the IPR story around OCB (its former
biggest drawback, IMO) has become significantly clearer.

OCB's creator Phil Rogaway has disavowed or intentionally allowed all of
his patents to lapse. "OCB is Free" declares his licensing page, which
notes all of his IP is now in the public domain:
https://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

This Jutla/IBM patent expired in 2022:
https://patents.google.com/patent/US6963976B1/en

Given that, I'm curious if this resolves IPR concerns around OCB, and if it
does, if there are other concerns beyond those.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Eric Rescorla]

On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly 
wrote:

> > KEMs are not "key agreement" algorithms as suggested by this draft
> name.  In a key agreement algorithm, both parties contribute to the shared
> secret.  With a KEM, only one party generates the the shared secreat value.
>
> This is not generally accurate with the KEM schemes under consideration
> for adoption by any standards bodies: in the -hybrid-design and
> -mlkem-key-agreement documents, the `Client` generates an ephemeral
> keypair, and the `Server` encapsulates to that keypair, but especially in
> ML-KEM which is under consideration in both documents, the KEM randomly
> sampled message `m` is sampled by the `Server` but the final
> `shared_secret` resulting from `Encaps` and `Decaps` is based on computing
> over the message `m`, the public key `PK` generated by the `Client`, as
> well as the randomized ciphertext `CT` generated by the `Server`. The
> encapsulated message `m` is not actually the `shared_secret` that is the
> input to the TLS 1.3  key schedule, even independent of the entire
> handshake transcript being included into the full key schedule as well.
>
> The naming of the document excluded 'key exchange' and 'key
> establishment', and went with 'key agreement', but that is a weakly held
> name,
>

I would probably rank order these as establishment > agreement > exchange,
but I'm not going to argue about these.

-Ekr


> On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  wrote:
>
>> Sean:
>>
>> I observe that ML-KEM is not a Elliptic curve group or a Finite Field
>> Diffie-Hellman group.  I really think we want to include sepport for KEMs.
>> but a separate range is needed.  I assume it will be carved out of the
>> Elliptic curve group range.
>>
>> KEMs are not "key agreement" algorithms as suggested by this draft name.
>> In a key agreement algorithm, both parties contribute to the shared
>> secret.  With a KEM, only one party generates the the shared secreat value.
>>
>> Russ
>>
>> > On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
>> >
>> > 
>> >
>> > **WARNING: Potential bikeshed**
>> >
>> > -connolly-tls-mlkem-key-agreement has suggested that code points for
>> the NIST PQ be registered in the TLS Supported Groups IANA registry [1].
>> Currently [2], the registry is carved up into three blocks as follows:
>> >
>> > Range: 0-255, 512-65535
>> > Registration Procedures: Specification Required
>> > Note: Elliptic curve groups
>> >
>> > Range 256-511
>> > Registration Procedures: Specification Required
>> > Note: Finite Field Diffie-Hellman groups
>> >
>> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
>> path for PQ KEM algorithms (and maybe regardless of whether this is the
>> path), we should really replace the “Elliptic curve groups” note in the
>> 0-255, 512-65535 range row with something else.  I am open to suggestions,
>> but would like to propose “unallocated”. I have submitted the following
>> issue:
>> > https://github.com/tlswg/rfc8447bis/issues/54
>> > and this PR:
>> > https://github.com/tlswg/rfc8447bis/pull/55
>> > to address this.
>> >
>> > spt
>> >
>> > [1]
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
>> >
>> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named
>> Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved
>> out the FFDH space.
>>
>> ___
>> 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

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Deirdre Connolly]

> KEMs are not "key agreement" algorithms as suggested by this draft name.
In a key agreement algorithm, both parties contribute to the shared
secret.  With a KEM, only one party generates the the shared secreat value.

This is not generally accurate with the KEM schemes under consideration for
adoption by any standards bodies: in the -hybrid-design and
-mlkem-key-agreement documents, the `Client` generates an ephemeral
keypair, and the `Server` encapsulates to that keypair, but especially in
ML-KEM which is under consideration in both documents, the KEM randomly
sampled message `m` is sampled by the `Server` but the final
`shared_secret` resulting from `Encaps` and `Decaps` is based on computing
over the message `m`, the public key `PK` generated by the `Client`, as
well as the randomized ciphertext `CT` generated by the `Server`. The
encapsulated message `m` is not actually the `shared_secret` that is the
input to the TLS 1.3  key schedule, even independent of the entire
handshake transcript being included into the full key schedule as well.

The naming of the document excluded 'key exchange' and 'key establishment',
and went with 'key agreement', but that is a weakly held name,

On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  wrote:

> Sean:
>
> I observe that ML-KEM is not a Elliptic curve group or a Finite Field
> Diffie-Hellman group.  I really think we want to include sepport for KEMs.
> but a separate range is needed.  I assume it will be carved out of the
> Elliptic curve group range.
>
> KEMs are not "key agreement" algorithms as suggested by this draft name.
> In a key agreement algorithm, both parties contribute to the shared
> secret.  With a KEM, only one party generates the the shared secreat value.
>
> Russ
>
> > On Mar 28, 2024, at 10:52 AM, Sean Turner  wrote:
> >
> > 
> >
> > **WARNING: Potential bikeshed**
> >
> > -connolly-tls-mlkem-key-agreement has suggested that code points for the
> NIST PQ be registered in the TLS Supported Groups IANA registry [1].
> Currently [2], the registry is carved up into three blocks as follows:
> >
> > Range: 0-255, 512-65535
> > Registration Procedures: Specification Required
> > Note: Elliptic curve groups
> >
> > Range 256-511
> > Registration Procedures: Specification Required
> > Note: Finite Field Diffie-Hellman groups
> >
> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the
> path for PQ KEM algorithms (and maybe regardless of whether this is the
> path), we should really replace the “Elliptic curve groups” note in the
> 0-255, 512-65535 range row with something else.  I am open to suggestions,
> but would like to propose “unallocated”. I have submitted the following
> issue:
> > https://github.com/tlswg/rfc8447bis/issues/54
> > and this PR:
> > https://github.com/tlswg/rfc8447bis/pull/55
> > to address this.
> >
> > spt
> >
> > [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> >
> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named
> Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved
> out the FFDH space.
>
> ___
> 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

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Rob Sayre]

On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker 
wrote:

>
> I don't think it's reasonable to specify the privacy properties of SVCB and
> /not/ talk about DNSSEC validation.
>

Could you explain more about this part? I think DNSSEC doesn't add much
here, unless you want to accept non-ECH traffic. For example, many of the
test servers will bounce you to some other site if you don't send ECH or
screw it up in some way (speaking as someone who has screwed it up many
times...).

I think there might be a DoS attack here, where someone messes with the
response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ
etc. So, if using those, it's just the trustworthiness of the DNS server
itself, right? Sorry if I'm missing something.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Eric Rescorla]

On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker 
wrote:

> Reviewer: Ted Lemon
> Review result: Almost Ready
>
> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>
> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
> which
> is surprising given that the draft proposes privacy properties for SVCB
> responses containing ECH data. I would think that it would make sense to
> say
> that the SVCB querier should attempt to validate the response, and then
> talk
> about what to do for bogus, insecure and valid positive and negative
> responses.
>
> For example, I would think that a /bogus/ response should be taken to mean
> that
> the SVCB record must be assumed to exist and should be treated the same as
> if
> the list of destinations were not reachable. An /insecure/ NXDOMAIN or
> NODATA
> response would not provide this assurance, and so what is currently
> described
> in the document makes sense for this case. A /valid/ NXDOMAIN would assure
> that
> no SVCB record existed, and hence ECH is not available.
>
> I don't think it's reasonable to specify the privacy properties of SVCB and
> /not/ talk about DNSSEC validation.
>

I could see that there might be an objection that if DNSSEC isn't working
> at a
> particular site because of a broken DNS resolver, this would prevent
> connecting
> to perfectly acceptable destinations simply because of general DNSSEC
> breakage,
> not a specific attack on this specific domain. The problem is that there's
> no
> way to distinguish this from an attack. So if this exception is allowed,
> the
> security considerations section should talk about what the risks are of
> allowing it. E.g. if we succeed in validing the root and com, but can't
> validate the zone containing the SVCB (or determine that it's not signed),
> that
> would be a clear indication of an attack, but if we can't validate the
> root, it
> could just be brokenness, and an attacker would do well to just prevent all
> validation so that we can't distinguish.


Thanks for your comments.

While I agree that SVCB being bogus deserves some consideration. I don't
think this
resolutions is *quite* correct. In general, TLS and HTTP don't take a
position
on what if any DNSSEC validation is to be done or what to do in response to
failures.

The new angle here is that there are two queries, and so it is possible for
the
A/ queries to produce a valid response but the SVCB to produce a bogus
one, which might be used by an attacker to disable ECH. What I would say
here
is that a bogus SVCB should be handled in the same way as if A/ were
bogus.
So if you would normally fail the resolution, you should do that, but if
you would
normally log and move on, then you should do that.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Ted Lemon via Datatracker]

Reviewer: Ted Lemon
Review result: Almost Ready

This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.

Section 4.1 advises disabling fallback, but does not talk about DNSSEC, which
is surprising given that the draft proposes privacy properties for SVCB
responses containing ECH data. I would think that it would make sense to say
that the SVCB querier should attempt to validate the response, and then talk
about what to do for bogus, insecure and valid positive and negative responses.

For example, I would think that a /bogus/ response should be taken to mean that
the SVCB record must be assumed to exist and should be treated the same as if
the list of destinations were not reachable. An /insecure/ NXDOMAIN or NODATA
response would not provide this assurance, and so what is currently described
in the document makes sense for this case. A /valid/ NXDOMAIN would assure that
no SVCB record existed, and hence ECH is not available.

I don't think it's reasonable to specify the privacy properties of SVCB and
/not/ talk about DNSSEC validation.

I could see that there might be an objection that if DNSSEC isn't working at a
particular site because of a broken DNS resolver, this would prevent connecting
to perfectly acceptable destinations simply because of general DNSSEC breakage,
not a specific attack on this specific domain. The problem is that there's no
way to distinguish this from an attack. So if this exception is allowed, the
security considerations section should talk about what the risks are of
allowing it. E.g. if we succeed in validing the root and com, but can't
validate the zone containing the SVCB (or determine that it's not signed), that
would be a clear indication of an attack, but if we can't validate the root, it
could just be brokenness, and an attacker would do well to just prevent all
validation so that we can't distinguish.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-svcb-ech-01.txt

[Sean Turner]

Hi! I am going to kick off some early reviews from the DNS and HTTP 
directorates to see if we get anything back.

spt

> On Mar 27, 2024, at 16:37, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-svcb-ech-01.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
>   Authors: Ben Schwartz
>Mike Bishop
>Erik Nygren
>   Name:draft-ietf-tls-svcb-ech-01.txt
>   Pages:   6
>   Dates:   2024-03-27
> 
> Abstract:
> 
>   To use TLS Encrypted ClientHello (ECH) the client needs to learn the
>   ECH configuration for a server before it attempts a connection to the
>   server.  This specification provides a mechanism for conveying the
>   ECH configuration information via DNS, using a SVCB or HTTPS record.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Russ Housley]

I am fine with putting a more inclusive name on the existing range.

Russ

> On Mar 28, 2024, at 6:04 PM, David Benjamin  wrote:
> 
> I don't believe we need a separate range, just to unmark the elliptic curve 
> range. TLS does not usually ascribe meaning to ranges of codepoints because 
> TLS implementations do not need to categorize codepoints they don't 
> understand.
> 
> The only reason supported groups was partitioned was because of a goofy thing 
> RFC 7919 did for FFDH. That goofy thing also was what made RFC 7919 
> undeployable anyway, so it didn't work out. :-)
> 
> On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  > wrote:
>> Sean:
>> 
>> I observe that ML-KEM is not a Elliptic curve group or a Finite Field 
>> Diffie-Hellman group.  I really think we want to include sepport for KEMs. 
>> but a separate range is needed.  I assume it will be carved out of the 
>> Elliptic curve group range.
>> 
>> KEMs are not "key agreement" algorithms as suggested by this draft name.  In 
>> a key agreement algorithm, both parties contribute to the shared secret.  
>> With a KEM, only one party generates the the shared secreat value.
>> 
>> Russ
>> 
>> > On Mar 28, 2024, at 10:52 AM, Sean Turner > > > wrote:
>> > 
>> > 
>> > 
>> > **WARNING: Potential bikeshed**
>> > 
>> > -connolly-tls-mlkem-key-agreement has suggested that code points for the 
>> > NIST PQ be registered in the TLS Supported Groups IANA registry [1].  
>> > Currently [2], the registry is carved up into three blocks as follows:
>> > 
>> > Range: 0-255, 512-65535
>> > Registration Procedures: Specification Required
>> > Note: Elliptic curve groups
>> > 
>> > Range 256-511
>> > Registration Procedures: Specification Required
>> > Note: Finite Field Diffie-Hellman groups
>> > 
>> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the 
>> > path for PQ KEM algorithms (and maybe regardless of whether this is the 
>> > path), we should really replace the “Elliptic curve groups” note in the 
>> > 0-255, 512-65535 range row with something else.  I am open to suggestions, 
>> > but would like to propose “unallocated”. I have submitted the following 
>> > issue:
>> > https://github.com/tlswg/rfc8447bis/issues/54
>> > and this PR:
>> > https://github.com/tlswg/rfc8447bis/pull/55
>> > to address this.
>> > 
>> > spt
>> > 
>> > [1] 
>> > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
>> > 
>> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named 
>> > Curve Registry” and then RFC 7919 re-named it “Supported Groups” and 
>> > carved out the FFDH space.
>> 
>> ___
>> 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