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 th
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
ot
As one of those who yammered constantly about splitting the ECH portions
out of the SVCB document to move it forward, I feel some responsibility.
But I think Erik's text pulled from 9460 does a good job discussing this.
Is it enough text to reference the section in 9460?
tim
just a DNS guy
On Sat
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 d
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 few
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 we
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 r
