-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:
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
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 a
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
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 , Roy Arends ,
> "Joe
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
___
> From: Olafur Gudmundsson
> 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 hours (
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, fujiw...@jprs.co.j
> From: Tony Finch
> 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 possibility
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 ensu
On Thu, Mar 06, 2014 at 05:31:32PM +,
Evan Hunt 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 deserves a
separate
> -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 Bortzm
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
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 S
On 03/06/2014 02:39 PM, Stephane Bortzmeyer wrote:
>> 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 well)). In which
>> case we'd need even better channel encryption,
On Wed, Mar 05, 2014 at 04:38:20PM +,
Tony Finch 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 (because they c
On Wed, Mar 05, 2014 at 03:11:59PM +,
Wessels, Duane 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, where the authoritat
On Wed, Mar 05, 2014 at 02:58:49PM +,
Jelte Jansen 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 well)). In which
> c
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 avoi
On Tue, Mar 04, 2014 at 02:38:14PM +,
Warren Kumari 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 accept to devote the
Suzanne,
On 3/6/14 10:51 AM, "Suzanne Woolf" 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 session.
I am g
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 tec
On Thu, Mar 06, 2014 at 05:51:32AM -0500,
Suzanne Woolf 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 know :-) And they are mu
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 effective
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 if
25 matches
Mail list logo
