chwartz ; Eric Rescorla ; Paul
> Wouters
> *Cc:* draft-ietf-tls-svcb-ech.auth...@ietf.org <
> draft-ietf-tls-svcb-ech.auth...@ietf.org>; ;
> dn...@ietf.org WG
> *Subject:* Re: [TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech
>
> We could add a recommendation like &q
] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech
We could add a recommendation like "Clients using ECH SHOULD select a DNS
resolver that they trust to preserve the confidentiality of their queries and
return authentic answers, and communicate using an authenticated and
confidential tran
> We could add a recommendation like "Clients using ECH SHOULD select a DNS
resolver that they trust to preserve the confidentiality of their queries
and return authentic answers, and communicate using an authenticated and
confidential transport", but this draft seems like an odd place for that
tex
> I do not, however, think that we should have a SHOULD for using DNSSEC
as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU
WON'T)".
I agree
On Mon, Sep 30, 2024 at 6:43 AM Eric Rescorla wrote:
>
>
>
> On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters 40aiven...@dmarc.ietf.org>
We could add a recommendation like "Clients using ECH SHOULD select a DNS
resolver that they trust to preserve the confidentiality of their queries and
return authentic answers, and communicate using an authenticated and
confidential transport", but this draft seems like an odd place for that te
I've written up adjusted references based on Paul's recommendations [1]. (I
haven't deleted the reference to RFC 1034, as I believe it remains the
authoritative RFC on what DNS is all about.)
Regarding Section 3.1 of SVCB (RFC 9460) [2], we imagine the client uses DoT to
issue and SVCB qu
On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters wrote:
> Hi,
>
> I have done my AD review of draft-ietf-tls-svcb-ech. Some history was well
> summarized by the Document
> Shepherd:
>
> Please note that the text in this I-D was initially developed in the DNSOP WG,
> went through IETF LC, and IESG rev
