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
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
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
>An attacker who can prevent SVCB resolution can deny clients any
>associated security benefits. A hostile recursive resolver can
>always deny service to SVCB queries, but network intermediaries can
>often prevent resolution as well, even when the client and
>recursive resolver
The TLS WG has requested a two hour session slot at IETF 121 [0]; we are not
yet sure of the timing. For planning purposes, the chairs would like to solicit
input from the WG for agenda topics. Please send your agenda topics request and
an estimate for how much time you will need to tls-cha...@i
I don't see any reason why an enterprise, family, or personal filter would
filter SVCB responses based on the "ech" SvcParam described in this draft. The
SNI data concealed by ECH is just the SVCB and QNAME. Any DNS-modifying
entity that could implement RDATA-based response policies could
OK, done: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16
From: Salz, Rich
Sent: Monday, September 30, 2024 1:29 PM
To: Ben Schwartz ; Eric Rescorla ; Paul Wouters
Cc: draft-ietf-tls-svcb-ech.auth...@ietf.org
; ;
dn...@ietf.org WG
Subject: Re: [TLS]
> 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>
The TLS WG has placed draft-ietf-tls-hybrid-design in state
Waiting for WG Chair Go-Ahead (entered by Deirdre Connolly)
The document was previously in state In WG Last Call
The document is available at
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
_
10 matches
Mail list logo
