Paul,
I don't understand your threat model here.
1. As already noted upthread, ECH inherently leaks the name you are
resolving to the resolver. This leak doesn't depend on the resolver
tampering with the response, so DNSSEC verification on the client
doesn't help here [0].
2. If the client accep
On Mon, 7 Oct 2024, Benno Overeinder wrote:
* draft-ietf-dnsop-delegation-only
- In 2021, there was a poll on the DNSOP WG mailing list to drop the draft.
Rough consensus to drop the document was established on 24 August 2021.
- We marked the draft as Dead in the datatracker.
Still sad abou
Dear WG,
The chairs have been reviewing the expired drafts that were adopted by
DNSOP at some point. Here is a brief summary of their status and next
steps.
* draft-ietf-dnsop-dnssec-automation
- The draft is stable and WG feedback has been received and
incorporated. Two directorate revie
Distribution trimmed down to just dnsop, where the question is most
pertinent.
Paul Wouters writes:
> Of course even better is using RFC 7901 Chain Query and run the few
> signature validations yourself.
Related, is there any notable software out there that does 7901? I
started implementing it i
On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote:
>
>
> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
>>
>> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>>
>>> This is explicitly prohibited rfc9460 as it would provide linkability.
> See rfc9460 section 12: "Clients MUST ens
Regarding multiple AliasMode RRs, see
https://www.rfc-editor.org/rfc/rfc9460.html#section-2.4.2-1:
"If multiple AliasMode RRs are present, clients or recursive resolvers SHOULD
pick one at random."
--Ben
From: Joe Abley
Sent: Sunday, October 6, 2024 6:24 AM
To:
Sorry, I don't understand why this configuration would create a problem.
Each SVCB record is a valid configuration. Clients should try one, and if it
fails, they should try the other. [1]
A server should disambiguate which ECHConfig is in use by the config_id, or
otherwise use trial decryption
On Fri, Oct 4, 2024 at 10:21 AM Vladimír Čunát wrote:
> On 04/10/2024 05.20, John Levine wrote:
>
> Editorially, I would move the stuff about approaches not taken to an appendix
> to
> avoid confusing people. That includes the second and last paragraphs of
> section 2.
>
> Yes, please.
>
Yes,
On Thu, Oct 3, 2024 at 8:00 PM Dave Lawrence wrote:
> I have read the most recent version of the document and am strongly in
> favor of its publication as a proposed standard. I want my NXDOMAINs
> back.
>
Thanks! You're not the only one :)
> I have little substantive feedback on the text, mo
On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote:
>
> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
>
>> This is explicitly prohibited rfc9460 as it would provide linkability.
See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
partitioned for each local networ
On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>>> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is
>>> partitioned for each local network, or flushed on network changes, to
>>> prevent a local adve
11 matches
Mail list logo
