On 06/09/2022 17.06, Ben Schwartz wrote:
The choice of transport is independent of the DNS server's answering
behavior, which must not be modified by the transport.
Nit: there's a very specific counter-example of EDNS padding which is
meant to be added depending on transport encryption.
On 09/02/2022 18.02, Mike Kosek wrote:
Thanks for your comment - I agree. However, we are issuing single queries in
our study on newly established connections - hence, we have no issues with
HoLB, and thus do not see significant differences between the HTTP versions.
Yes, I knew. That might
On 09/02/2022 16.46, Mike Kosek wrote:
we do not observe significant differences between the HTTP versions
HTTP 1.1 would surely have performance issues in practical use due to
head of line blocking, especially if some answers take long to resolve.
Sure you can work around that by opening
On 15/12/2021 17.41, Ben Schwartz wrote:
We can simply agree that resolvers have no obligation to prefer
encrypted nameservers. That means mixed NS-sets will result in
fractional DoT rollout, which seems fine.
That would be a question for operators. I imagine some deployments
might want to
On 10/12/2021 23.13, Daniel Kahn Gillmor wrote:
- whether to hard-fail or not
I don't think it's much worth to bother with authentication if on-path
active attackers could easily cause automatic downgrade anyway.
One problem with discovery in non-downgradable schemes without parent
On 07/12/2021 17.52, Brian Haberman wrote:
Please let me know if you disagree with the above direction.
I do not disagree, but in case of 8467 I can also imagine making the
normative padding-policy requirements more vague, with a non-normative
reference to 8467 as an "example" of (selecting)
On 29/11/2021 17.19, Eric Rescorla wrote:
I don't particularly care whether 853 is assigned to DoQ or not, but
these reasons do not strike me as particularly strong.
+1
DNS over DTLS is not known to be used (or even "implemented", I think),
and that state seems unlikely to change, especially
On 01/11/2021 17.24, Daniel Kahn Gillmor wrote:
Is there an additional privacy leak if there were to be more than one EDNS
Padding option?
I don't think it's possible to leak more privacy by doing that. Assuming
an encrypted channel, only the overall length of the DNS message should
matter.
On 20/09/2021 18.12, Ben Schwartz wrote:
There seem to be many participants in the WG who believe that getting
new glue RR types into parent zones (and especially TLDs) is a very
distant prospect.
Right, I underestimated that aspect. Who knows, maybe this new-RR-type
problem would even
Hello.
If the parent zone also implements authenticated encryption, this
provides sufficient protection for the glue records, but many
important parent zones seem unlikely to implement authenticated
encryption in the near future.
I'm not very convinced about the motivation so far. Let me
On 09/09/2021 13.14, Sara Dickinson wrote:
However, if the working group does want the guidance moved there then we
probably need to look again at authors for that document so it can progress.
And if it were to be a normative reference for DoQ the two would need to move
forward together to
Hello.
On 16/08/2021 14.18, Brian Haberman wrote:
1. Stub to recursive resolver
2. Recursive resolver to authoritative servers
3. Zone transfers
Do you agree/disagree that the use cases should be considered for DoQ?
I'm certainly glad that 2 got included. I probably even
On 13/07/2021 17.56, Hollenbeck, Scott wrote:
Delegation-centric zones return name server IP addresses that are exposed in
subsequent recursive queries. The value proposition of encrypting those
addresses in a DNS response has to be weighed against [...]
I think that's a bit too simplified
I like it in principle, so I say adopt.
I already see a significant problem, though I expect we can fix it
somehow after adoption:
After sending out all requests for SVCB records [...]
My understanding of section 3 implies that an implementing resolver MUST
NOT ask any of the nameservers
On 31/03/2021 15.12, Jim Reid wrote:
As an example, widespread adoption of RFC8806 - no sniggering at the back! -
could obviate the need for encrypted queries to the root or possibly offload
the TLS goop to the local instances of the root. But the WG doesn’t seem to
want to consider that.
On 31/03/2021 02.53, Erik Kline wrote:
I think, "IN NS com." doesn't reveal much information. But perhaps
"IN NS sensitive-tld." could have privacy implications for some folks?
Yes, it could be e.g. accidentally leaked garbage. But even so, it's
not so difficult to completely avoid querying
On 11/20/20 9:14 PM, Brian Dickson wrote:
> So, using a new algorithm for whatever we do, should be 100% backward
> compatible.
Yes, it should be. A few different proposals have been relying on that
already, for DS or DNSKEY. It is possible that some validators still
have bugs around this, but
On 11/19/20 2:05 PM, Peter van Dijk wrote:
> 1. auth operators publish TLSA records for their NSes
> 2. the registry, while generating zone files, queries for those TLSA records
> 3. from the found TLSA records, the registry generates DOTPIN DSes
> 4. the DOTPIN DSes are published alongside the
On 8/12/20 9:50 PM, Paul Wouters wrote:
>> Delegation NS records are not signed, so do we stick -those- (or a hash
>> of the NSset perhaps?) into DS?
>
> I don't think so. The DS is signed, and following that path, it hardly
> matters where the NS records point to. Do you fear that you will
On 8/12/20 8:39 PM, John Levine wrote:
>> I am against adoption for two reasons. The draft as it currently is,
>> requires that domain name owners and nameserver hosting administrators
>> synchronise their nameserver TLS keys.
> Why wouldn't you publish multiple DS records for multiple nameserver
Hello.
On 5/21/20 10:50 PM, Brewst wrote:
> The proposed solution of having DNS encrypted via DoT from the
> resolver to authoritative is fantastic idea. It ensures the data's
> integrity while also giving system owners the ability to inspect
> traffic sent to their local resolver as well as the
On 1/9/20 6:37 PM, Ted Lemon wrote:
> On Jan 9, 2020, at 9:21 AM, Vladimír Čunát <mailto:vladimir.cunat+i...@nic.cz>> wrote:
>> Depends what you'd want from the stamps.
> If the stamps make assertions about what service is offered, I’d want
> that to be verifiable. [.
These stamps do contain interesting ideas, I believe.
On 1/9/20 5:13 PM, Ted Lemon wrote:
> In order for this to actually be useful, two things would be required.
>
> 1. The assertions about resolver behavior (e.g., logging, etc) would
> have to be signed
> [...]
Depends what you'd want from the
On 12/16/19 12:22 PM, Vittorio Bertola wrote:
> Incidentally, though it is much easier said than done, I think that being
> able to apply different trust models to different types of networks, so that
> the OS/application behaves differently when you connect to a random wi-fi in
> a cafe than
On 11/18/19 2:32 PM, Vladimír Čunát wrote:
> A colleague implemented the PSL approach for Knot Resolver recently
> where user picks the resolver set
I forgot the link:
https://knot-resolver.readthedocs.io/en/stable/modules.html#c.policy.slice
_
On 11/16/19 8:38 AM, Jari Arkko wrote:
> https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00
A colleague implemented the PSL approach for Knot Resolver recently
where user picks the resolver set, but I'm skeptical about
spreading-with-PSL significantly improving
On 11/1/19 4:34 PM, Eric Rescorla wrote:
>
> Let me re-emphasize this from the original statement: "FOR PRIVACY".
>
> DNSSEC security is orthogonal to privacy, and is not a requirement
> FOR PRIVACY.
>
>
> I don't believe that that's correct in this case. The issue here is
> that in
On 11/1/19 3:13 PM, Eric Rescorla wrote:
>
> Generally speaking, I believe it's fine to add assumptions about
> DNSSEC
> validation, if that makes the ADoT protocol "better" in some way.
> (and
> I expect it will) It seems that DNSSEC will be much easier than this
> new
On 11/1/19 11:38 AM, Stephane Bortzmeyer wrote:
> * DROP is not a perfect acronym since the draft does not talk only
> about privacy but also about integrity ("result filtering", aka lying
> resolvers).
It's even possible to keep the acronym and just tweak the name, e.g. DNS
Recursive Operator
On 11/1/19 1:37 AM, Eric Rescorla wrote:
> Hmm. I think that's only true if you are assuming that the NS
> record for the leaf is DNSSEC secured, but that doesn't seem like a
> safe assumption.
Generally speaking, I believe it's fine to add assumptions about DNSSEC
validation, if that makes
Hello.
> 4.5 End-User Policy Propagation
I think the client-subnet part here is fully covered by the current RFC
7871 already, but that seems an unimportant nitpick at this point.
--Vladimir
___
dns-privacy mailing list
dns-privacy@ietf.org
On 10/16/19 2:59 AM, Patrick McManus wrote:
> 1b] As this is a BCP, I question whether this is really advice driven
> by BCP. How often is this done, and when it is done how much traffic
> is driven through it so that we really understand the implications of
> it? This feels more like an idea than
> [...] Implementing out-of-order delivery via TLS is akin to
> (re-)implementing the stream multiplexing part of SCTP, QUIC or
> HTTP/2.0. We believe that this is one of the main reasons why
> DNS-over-TLS failed to gain significant traction.
The last sentence really surprises me. I'm actually
Hello,
I now read through the whole document, and I see one thing that might be
a little bit confusing - the beginning of page three reads like QNAME
minimization is not possible or at least never done, and contrary to
rfc7626 itself it isn't even mentioned in the whole document. I would
suggest
34 matches
Mail list logo
