stracts (suggested 1 page text + 1 page references) from people who
are interested presenting at the workshop. Abstracts are due soon
after the start of the new year (2023-01-18), but as a reminder they
need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker
(both at USC/ISI), with Goeff H
01-18), but as a reminder they
need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker
(both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN
Labs) on the Technical Program Committee.
For details about DINR2023, see https://ant.isi.edu/events/dinr2023/
. (For informa
comes more quickly than a response over DOT/etc...
Another full read may squash some of the above, and clearly the authors
should feel free to disregard any of my statements and questions if they
think I'm wrong.
[1]: https://b.root-servers.org/news/2023/02/28/tls.html
[2]: https://ant.isi.edu/events/dinr2023/S/s43.pdf
--
Wes Hardaker
USC/ISI
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
maximum
contributions are preferred. Co-chairs are John Heidemann and Wes
Hardaker (both at USC/ISI), with Allison Mankin (Salesforce) and Moritz
Müller (SIDN Labs) on the Technical Program Committee. If you wish to
attend but not present, please submit a paragraph stating you wish to
attend only and provide
response) contains
Anyone that knows both is a potential point of compromise.
http://datatracker.ietf.org/doc/draft-hardaker-dnse-split-key-dns/
Warning: the security in here is not.
--
Wes Hardaker
Parsons
___
dns-privacy mailing list
dns-privacy
Phil Regnauld writes:
> Man, reading that sentence, I had the feeling that sentence that I had
> read it twice.
I wrote it twice, so it worked.
Somewhere in the abstract I should have put "what follows is random,
unproofread, typing that may or may not make sense".
--
Wes
cking in both places: K1..example.org).
--
Wes Hardaker
Parsons
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
e issues; You always
have to append a suffix which means you're always reducing the maximum
label count by the suffix length. Which in the above is 2).
--
Wes Hardaker
Parsons
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
iple
directions and require them all to be completely processed, it means
that you're final round trip time is subject to the worst-latency. So
you're definitely trading speed for privacy in this case.
--
Wes Hardaker
Parsons
___
dns-pri
the best result
based on where you want to compromise and where you don't. If we
optimize only for a single one first, we're likely to rule out the other
one from being solvable.
--
Wes Hardaker
Parsons
___
dns-privacy mailing list
dns-privacy@iet
x27;t think secure dhcp has
gotten that far, but I'm admittedly out of touch.
We simply keep moving this chicken/egg problem of secure bootstrapping
from one protocol to the next. It's like one egg that keeps changing
chickens.
--
Wes Hardaker
Parsons
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ses you need
> to have a trust anchor for the private part of the reverse tree or
> use leap of faith.
Yes, that's what I was saying... I was just following it by "there are
a huge number of private-address resolvers in the real world
Paul Hoffman writes:
> On Aug 27, 2014, at 12:46 PM, Wes Hardaker wrote:
>
>> But what's the solution? How do we authenticate that resolver? PKIX
>> won't help us, as there is no name.
>
> Say what? That draft clearly says that the resolver can have a PKIX
&g
IETF, which I'll also be at, I've
decided to hold a less formal bar BOF on the subject. If you're
interested in the topic of internet naming, where research is needed and
would like to participate in a conversation about it, please let me know.
--
Wes Hardaker
27;s a critically important protocol for
protecting the privacy and usability of DNS is certain situations. That
doesn't mean I want to use it everywhere, even though that's what we're
trending toward.
[that was a bit rambly; sorry]
--
Wes Hardaker
ther or not the
caches should be separate. If anything, it may argue for a shared cache
so that normal traffic from non-privacy protected lookups will mean
someone snooping caches for private-protected lookups won't know it came
from a TLS-based user.
[And, no, we shouldn't go dow
.dnssec-tools.org/ is due to a large number of zones
suddenly enabling DANE/SMTP on one.com. That shows the scale of
some of the larger zone holders.
--
Wes Hardaker
My Pictures: http://capturedonearth.com/
My Thoughts:
alyzing-root-privacy.pdf
Youtube 1: https://youtu.be/bSKBRMNQ7s0
Youtube 2: https://youtu.be/9YYH8JFH_bY?t=21m0s
--
Wes Hardaker
My Pictures: http://capturedonearth.com/
My Thoughts: http://blog.capturedonearth.com/
___
y situation:
7: "Hey Wes, how's things? Yeah, I know we supported everything for you
in the past because you're smart, we're smart and we're small enough to
pretty much help everyone. But to get you the speed you wanted, we had
to outsource your connection and addr
al does get adopted, I'd argue for experimental
being a much better track. I strongly doubt, without evidence, that
this will be the final solution to this newly targeted problem.
--
(as proof that I'm not opposed to the technology proposed in general:
https://datatracker.ietf.org/d
us venues by various people). I need
to collect better stats for "recently active" too (I have them, but I
don't trust them at the moment).
--
Wes Hardaker
My Pictures: http://capturedonearth.com/
___
ls that help both.
We're planning for a very interactive day of discussion and short talks. We are
soliciting short (1 page text + 1 page references) abstracts from people who
are interested presenting. Abstracts are due soon (October 26), but they're
short. Co-chairs are John Heidemann
be a huge
effort to submit something.
Start of forwarded message --------
From: Wes Hardaker
To: dpr...@ietf.org
Cc: John Heidemann
Subject: CFP for DINR 2021 workshop-Nov. 16 for early DNS research
Date: Mon, 04 Oct 2021 14:08:38 -0700
Greetings, dprive. Last ye
23 matches
Mail list logo
