Dear colleagues,
DNSOP now has two meetings to manage, both with packed agendas. This means your
chairs will really appreciate early volunteers for note-takers and jabber
scribes.
Please drop us a note if you can do either job for either session.
Pitch: you might get more out of the session
Talked with Jim Roskind who did the QUIC talk back in Vancouver. I
include his comments:
I actually discussed this in a hallway discussion at the Canada IETF
meeting.
I think it would fit well, as it has the potential to offer zero-RTT
connect (similar to what DNS over UDP
On Thu, Mar 06, 2014 at 05:51:32AM -0500,
Suzanne Woolf suzworldw...@gmail.com wrote
a message of 16 lines which said:
you might get more out of the session if you're forced to ignore
your email,
Email? You mean the thing we used in the 1990s? Today, people use
Twitter and Facebook, you
Here are new identifiers that are not domain names and do not even
look like domain names:
https://www.frogans.org/
If you are in a hurry, and just interested in the identifiers, they
are at:
https://www.frogans.org/en/resources/ifap/access.html
And you may read only the first one IFAP 1.0
Suzanne,
On 3/6/14 10:51 AM, Suzanne Woolf suzworldw...@gmail.com wrote:
DNSOP now has two meetings to manage, both with packed agendas. This
means your chairs will really appreciate early volunteers for note-takers
and jabber scribes.
Please drop us a note if you can do either job for either
On Tue, Mar 04, 2014 at 02:38:14PM +,
Warren Kumari war...@kumari.net wrote
a message of 39 lines which said:
Which is why I think that some of this involves us[0] talking to
ICANN and explaining the reason / purpose for ALT, and playing nice.
OK, so we just have to find people who
This is an update of my previous messages.
The generic DNS confidentiality problem can be divided into 3 cases:
1- stubs - local resolver
2- stubs - remote open resolver
3- resolver - auth. servers
In the first case the local resolver is in the same security area
(I use area to avoid to
On Wed, Mar 05, 2014 at 02:58:49PM +,
Jelte Jansen jelte.jan...@sidn.nl wrote
a message of 20 lines which said:
all the more reasons for ISPs to try and force you to use theirs
(perhaps even after some friendly coercion from the nearest
three-letter agency (four in the netherlands as
On Wed, Mar 05, 2014 at 03:11:59PM +,
Wessels, Duane dwess...@verisign.com wrote
a message of 35 lines which said:
The goal of the DNSE BoF was privacy, not authentication. For
Do you mean data authentication, or who-I-am-talking to authentication?
Data authentication. In the DNS,
On Wed, Mar 05, 2014 at 04:38:20PM +,
Tony Finch d...@dotat.at wrote
a message of 13 lines which said:
For authentication, we have DNSSEC :-)
DNSSEC authenticates data not servers.
See my reply to Duane. Athenticating an autoritative name server or a
forwarder has little value
In your previous mail you wrote:
If we follow this line of reasoning, why do we deploy more security,
then?
= because we want (and as you noticed they don't want).
With this argument, we would never have deployed HTTPS
either.
= have we? I am afraid most HTTPS are MITM'ed where SSH
On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote:
The only place where server authentication could be useful is between
a stub and the first resolver.
I think that's exactly the point that was under discussion, though:
How can people who don't want their DNS traffic snooped
-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Evan Hunt
Sent: Thursday, March 06, 2014 6:32 PM
To: Stephane Bortzmeyer
Cc: Tony Finch; dnsop@ietf.org
Subject: Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer
On Thu, Mar 06, 2014 at 05:31:32PM +,
Evan Hunt e...@isc.org wrote
a message of 12 lines which said:
I think that's exactly the point that was under discussion,
It's a very valid and interesting point but it has not a lot of
relationship with the privacy issues. I suggest that it
On Thu, Mar 06, 2014 at 06:39:07PM +0100, Stephane Bortzmeyer wrote:
It's a very valid and interesting point but it has not a lot of
relationship with the privacy issues.
I don't entirely agree: if a MITM can spoof a trusted remote resolver,
then QNAME minimization won't help you. DNSSEC
From: Tony Finch d...@dotat.at
It is an interesting draft and I can see why the problem concerns you. The
dummy DS is a clever work-around, but it is a pity about the validation bug
in Google public DNS.
Thanks. I'm not sure that the validation error is a bug or not.
I wonder about the
Hi,
I believe there may of been some take away from Vancouver on direction.
I have a hand written note on this, but it was lost in the discussion on
Key Exchanges.
I will followup with you after tonight's meeting, and apologies for
dropping this.
tim
On 3/6/14, 5:57 PM,
From: Olafur Gudmundsson o...@ogud.com
Your calculations on the amplification are good illustration, but assume that
the resolvers use
the parental provided NS set, not the child side provided NS set.
In the case of google.co.jp.
JP side NS has TTL of 1 day but google.co.jp side has is 96
On Fri, Mar 07, 2014 at 03:03:40AM +0900, fujiw...@jprs.co.jp wrote:
...
I would like to know whether the increase of DS queries are observed
commonly or not. (with small NCACHE TTL value)
We are observing around the same % of qps but still need to confirm
the other characteristics.
Fred
Hi all,
We had an idea in the bar. We wrote it up. Comments welcome.
Joe
Begin forwarded message:
From: internet-dra...@ietf.org
Subject: New Version Notification for draft-jabley-dnsop-dns-onion-00.txt
Date: 6 March 2014 at 19:24:34 GMT
To: Joao Luis Silva Damas jda...@dyn.com, Roy
DNSOP members,
Given our session today talking about protecting DNS privacy, I found an
interesting bit of synchronicity upon going back to my room and seeing this
article in my feeds about a compromise of at least 300,000 small office / home
office (SOHO) home routers by a variety of attacks
Dan,
I guess you have to separate the problem of compromising device with the
case where we are looking for only confidentiality or privacy. IMHO, this is
somewhat out of scope.
However, we cannot ignore it. In this special case, just the admin of that
recursive resolver needs to react to that
On Thu, Mar 06, 2014 at 11:09:33PM +, Dan York wrote:
this case of the attacker controlling the recursive resolver, I
don't know that any of the various solutions thrown around today
would do anything to help with this.
But this was exactly the question I (among others) was trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello list,
the authors of *Special-Use Domain Names of Peer-to-Peer Systems* I-D
are inviting you to review the latest version (02) of our draft. It
includes changes prompted by community feedback, many coming from the
DNSOP list. Among them:
24 matches
Mail list logo
