I'll not continue with the charter topic, because you're right that it's
offtopic on a privacy list. However the point was made because it was an
opportunity as a protocol change would be introduced when introducing
encryption.
On Tue, Jan 17, 2017 at 09:49:09PM -0500, Robert Edmonds wrote:
>
On Tue, Jan 17, 2017 at 07:54:45AM -0800, Paul Hoffman wrote:
> > On a side note, because any encryption will require a change to the DNS
> > protocol (i.e., putting things into a crypto box which isn't backwards
> > compatible) IMO it would be worthwhile to consider revisiting the DNS
> > message
On Wed, Jan 18, 2017 at 06:53:44AM +0530, Mukund Sivaraman wrote:
> On Tue, Jan 17, 2017 at 07:54:45AM -0800, Paul Hoffman wrote:
> > > On a side note, because any encryption will require a change to the DNS
> > > protocol (i.e., putting things into a crypto box
Hi Christian
On Tue, Sep 25, 2018 at 01:40:59PM -0700, Christian Huitema wrote:
> On 9/25/2018 12:15 PM, Tony Finch wrote:
>
> > For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I don't
> > know QUIC's handshake.
> >
> > The warm start time should soon be 0RTT.
>
> The basic
On Tue, Sep 25, 2018 at 10:43:44PM +0530, Mukund Sivaraman wrote:
> DNS is at the head of any user-initiated internet connection and the
> turnaround time of a DNS request is definitely influenced by the
> resolution time at the head of the sequence of steps.
That should say "t
On Thu, Jul 19, 2018 at 02:23:53PM -0400, Brian Haberman wrote:
> This thread is for discussion of the user perspective of DNS privacy
> between the recursive resolver and authoritative servers.
>
> - Focus on *what* is needed.
> - Avoid *how* to achieve it.
> - Consider both ends of
Hi Daniel
On Thu, Dec 13, 2018 at 02:32:41PM -0500, Daniel Kahn Gillmor wrote:
> The degenerate scenario i'd painted on the call was:
>
> * consider a DPRIVE-capable DNS resolver; for whatever reason, only a
>single request has been made to it since it booted.
>
> * a new cleartext
On Thu, Dec 13, 2018 at 04:21:39PM -0500, Daniel Kahn Gillmor wrote:
> Hi Mukund--
>
> thanks for your prompt followup!
>
> On Fri 2018-12-14 02:22:12 +0530, Mukund Sivaraman wrote:
> > The trailing '='s are part of the base32 encoding.
> >
Hi Daniel
First, thank you for replying. I wondered if I'd said something
completely wrong. :)
On Thu, Dec 13, 2018 at 01:50:39PM -0500, Daniel Kahn Gillmor wrote:
> On Tue 2018-12-11 11:08:06 +0530, Mukund Sivaraman wrote:
> > 1. The RDATA of an NS record has to be a hostname, so it wo
Hi Paul
On Thu, Dec 13, 2018 at 09:11:52PM +, Paul Hoffman wrote:
> There are many ways to get a key and then compare the hash of the key with
> the hash you get securely from the DNS.
>
> > If it can be
> > demonstrated to work for near-future algorithms (next 2-3 decades), then
> > it's
There was some discussion in last night's meeting about encoding keys in
the DNS name of a nameserver, similar to DNSCurve. There are at least
some issues with it:
1. The RDATA of an NS record has to be a hostname, so it would limit the
amount of data that can be encoded within the NSDNAME. As an
Hi all
Some ideas on how to practically test resolver->auth secure transport
was asked during yesterday's dprive meeting. Here are some examples to
test.
Simulate the case of queries for names in the DNS that are hosted
topologically farthest away from the tester. Assume the test is
conducted in
On Wed, Dec 05, 2018 at 10:22:49PM +0530, Mukund Sivaraman wrote:
> Nod, HTTPS has demonstrated that TLS can be scalable (even more so in
> recent years) and DNS is not different in this aspect. This is one
> aspect for protocol selection. I also worry about roundtrips in
> recursiv
13 matches
Mail list logo
