Ted & ErikN,
So it looks like ErikN submitted the following PR and ekr approved:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1
If we have resolved your comments, can I ask on of the authors to spin a new
version and we can look to move this I-D.
Also, could I kindly ask you to revise
On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon wrote:
> Encrypted dns transport works if you can trust the provider you are
> talking to. DNSSEC works even if you can’t. And if your provider is
> trustworthy, DNSSEC validation of results acquired through this tunnel
> should work. So it’s silly in
Encrypted dns transport works if you can trust the provider you are talking
to. DNSSEC works even if you can’t. And if your provider is trustworthy,
DNSSEC validation of results acquired through this tunnel should work. So
it’s silly in this case to trust the tunnel—there’s no upside to doing so
On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren wrote:
>
> An attacker who can prevent SVCB resolution can deny clients any
> associated security benefits.
>
>
Yes.
> A hostile recursive resolver can always deny service to SVCB queries, but
> network intermediaries can often prevent resolution as
I pulled some text directly over from the 9460 security considerations with
some minor tweaks:
https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1/files
An attacker who can prevent SVCB resolution can deny clients any associated
security benefits. A hostile recursive resolver can always
Yeah, that sounds fine. I think 9460 is pretty good in that it covers both
DNSSEC and encrypted transports for DNS.
thanks,
Rob
On Sat, Mar 30, 2024 at 10:27 AM Ted Lemon wrote:
> I think that would make sense, yes.
>
> On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren wrote:
>
>> Do we want a
I think that would make sense, yes.
On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren wrote:
> Do we want a few sentences in Security Considerations that references
> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out?
>
> This seems like something that became less clear when
Do we want a few sentences in Security Considerations that references
https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out?
This seems like something that became less clear when we split these two
docs apart.
Most of draft-ietf-tls-svcb-ech used to be a section of what is now
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,
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
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
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
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
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
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:
>
>>
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
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
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
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
19 matches
Mail list logo
