Jim Gettys wrote:
> Radio clock receivers often don't work where these devices are deployed
> (like in my basement). Not enough view of the sky (and multiple layers of
> floors). Radios are "nice to have", but can't be guaranteed to work.
No, the problem of radio clock is not its availability bu
On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley wrote:
> This discussion highlights the importance of making sure that hardware
> vendors understand the need for working clocks that can be easily
> bootstrapped. In addition to NTP radio clock receivers are ubiquitous,
> tiny and ridiculously cheap.
On Sat, 14 Sep 2013, SM wrote:
See above. But also, you can use various open resolvers. The Fedora
Project even runs a few for dnssec-trigger that are accessable only via
TCP - I'm hoping more people will put up TCP-only open resolvers,
especially with:
RFC 5358 has a "SHOULD NOT" for open res
Hi Tony,
At 05:27 12-09-2013, Tony Finch wrote:
But if you care about security you can - with useful effect - choose a
registrar with better security processes, and you can use a registry lock
to prevent other registrars from undermining that security.
There is a well-known domain for a well-kn
Hi Paul,
At 08:17 12-09-2013, Paul Wouters wrote:
the NSA's Key "Recovery" Service. Secondly, if the web site has all
http://www.youtube.com/watch?v=-qrlDGhoI1Q
See above. But also, you can use various open resolvers. The Fedora
Project even runs a few for dnssec-trigger that are accessable
Dickson, Brian wrote:
> In order to subvert or redirect a delegation, the TLD operator (or
> registrar) would need to change the DNS server name/IP, and replace the DS
> record(s).
Only to a victim to be deceived.
> This would be immediately evident to the domain owner, when they query the
> TLD
This discussion highlights the importance of making sure that hardware vendors
understand the need for working clocks that can be easily bootstrapped. In
addition to NTP radio clock receivers are ubiquitous, tiny and ridiculously
cheap. It is unconscionable that any consumer electronics are so
Ted,
What I like about this message is that you have demonstrated the
*potential* severability of these issues. Things are set up as they are
for a matter of scaling. Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity. It's also pretty
clear that we sho
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:
>
> On Sep 10, 2013, at 8:17 PM, David Morris wrote:
>
> >
> >
> > On Wed, 11 Sep 2013, Brian E Carpenter wrote:
> >
> >> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
> >> ...
> >>> My colleagues and I worked on OpenWrt routers to get Unboun
Ted Lemon wrote:
> This isn't _quite_ true. DNSSEC supports trust anchors at
> any point in the hierarchy, and indeed I think the right
> model for DNSSEC is that you would install trust anchors
> for things you really care about, and manage them in the
> same way that you manage your root trus
robert bownes wrote:
> A 1pulse per second aligned to GPS is good to a few ns. Fairly
> straightforward to plug into even a OpenWrt type of router. Turn on
the pps
> in NTP on the router and you are good to go.
Faking GPS signal is trivially easy.
Iraq successfully captured US unmanned plain, app
On Sep 12, 2013, at 1:49 PM, "Dickson, Brian" wrote:
> In order to subvert or redirect a delegation, the TLD operator (or
> registrar) would need to change the DNS server name/IP, and replace the DS
> record(s).
Someone who possesses the root key could in principle create a fake DNS
hierarchy wi
On Sep 12, 2013, at 3:16 PM, "Dickson, Brian" wrote:
> Excluding the direct methods of acquisition, let us consider the level of
> effort involved in recreating the root key, by brute force.
I think we can assume that they would use some fairly subtle attack to get the
key, and would not brute f
On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon wrote:
> On Sep 12, 2013, at 1:49 PM, "Dickson, Brian"
> wrote:
> > In order to subvert or redirect a delegation, the TLD operator (or
> > registrar) would need to change the DNS server name/IP, and replace the
> DS
> > record(s).
>
> Someone who posses
On 9/12/13 2:07 PM, "Ted Lemon" wrote:
>On Sep 12, 2013, at 1:49 PM, "Dickson, Brian"
>wrote:
>> In order to subvert or redirect a delegation, the TLD operator (or
>> registrar) would need to change the DNS server name/IP, and replace the
>>DS
>> record(s).
>
>Someone who possesses the root key
On Sep 12, 2013, at 11:07 AM, Theodore Ts'o wrote:
> Finally, if you think the target can try to find random caching
> nameservers all across the networ to use, (a) there are certain
> environments where this is not allowed --- some ISP's or hotel/coffee
> shop/airline's networks require that you
On 9/12/13 7:24 AM, "Theodore Ts'o" wrote:
>On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote:
>> > I disagree. DNSSEC is not just DNS: its the only available,
>>deployed, and
>> > (mostly) accessible global PKI currently in existence which also
>>includes a
>> > constrained p
On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o wrote:
> On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote:
> >
> > The model for this sort of validation is really not on a per-client
> > basis, but rather depends on routine cross-validation by various
> > DNSSEC operators throughout the n
Chiming in a bit late here, however, the availability of stratum 1 clocks
and stratum 2 class time data on non IP and/or non interconnected networks
is now so large, I question why one would run NTP outside of the building
in many cases, certainly in an enterprise of any size.
A 1pulse per second
On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker wrote:
> It would work just fine if the attacker did not mind if the surveillance was
> detected or actually wanted people to know they were being watched to
> intimidate them.
Yup,neither PKI nor DNSSEC address that threat model. For that you
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o wrote:
> Still, I agree with the general precept that perfect should not enemy
> of the better, and DNSSEC certainly adds value. I just get worried
> about people who seem to think that DNSSEC is a panacea.
Me too. It most certainly is not.
_
On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote:
>
> The model for this sort of validation is really not on a per-client
> basis, but rather depends on routine cross-validation by various
> DNSSEC operators throughout the network. This will not necessarily
> catch a really focused attac
On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote:
> > I disagree. DNSSEC is not just DNS: its the only available, deployed, and
> > (mostly) accessible global PKI currently in existence which also includes a
> > constrained path of trust which follows already established busine
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o wrote:
> It is still a hierarchical model of trust. So at the top, if you
> don't trust Verisign for the .COM domain and PIR for the .ORG domain
> (and for people who are worried about the NSA, both of these are US
> corporations), the whole system fal
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
Any co-ercing that happens has to be globally visible, if the target
ensures he is using "random" nameservers to query for data.
Not necessarily. First of all, an active attacker located close to
the target can simply replace the DNS replies with bogu
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o wrote:
> It is still a hierarchical model of trust. So at the top, if you
> don't trust Verisign for the .COM domain and PIR for the .ORG domain
> (and for people who are worried about the NSA, both of these are US
> corporations), the whole system falls
On Thu, Sep 12, 2013 at 10:22:10AM -0400, Paul Wouters wrote:
>
> Any co-ercing that happens has to be globally visible, if the target
> ensures he is using "random" nameservers to query for data.
Not necessarily. First of all, an active attacker located close to
the target can simply replace th
On Thu, 12 Sep 2013, Theodore Ts'o wrote:
More importantly, what problem do people think DNSSEC is going to
solve?
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the NSA
Theodore Ts'o wrote:
>
> Their dynamic with their users and the market is the same as with CA's
> --- the market virtually guarantees a race to the bottom in terms of
> quality and prices. So beyond replacing names like "Comodo" with "Go
> Daddy", what benefit do you actually think would accrue?
Phillip Hallam-Baker wrote:
>
> 2. The current time is a matter of convention rather than a natural
> property. It is therefore impossible to determine the time without
> reference to at least one trusted party.
Preferably more than one so you can use quorum agreement and minimize the
amount of t
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:
I think you can avoid that issue by having the device not pass traffic
until the DNSSEC validation is enabled. Only the device needs the special
permissive handling for this to work.
You mean only allow NTP and DNS traffic in the beginning, until
OK lets consider the trust requirements here.
1. We only need to know the current time to an accuracy of 1 hour.
2. The current time is a matter of convention rather than a natural
property. It is therefore impossible to determine the time without
reference to at least one trusted party.
2a) A t
On 2013-09-11, at 11:43, Phillip Hallam-Baker wrote:
> OK lets consider the trust requirements here.
>
> 1. We only need to know the current time to an accuracy of 1 hour.
[RRSIG expiration times are specified with a granularity of a second, right?
I appreciate that most people are generous w
On Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker wrote:
>>
>> I disagree. DNSSEC is not just DNS: its the only available, deployed, and
>> (mostly) accessible global PKI currently in existence which also includes a
>> constrained path of trust which follows already established business
>>
On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver wrote:
>
> On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker
> wrote:
> >
> > The DNS is the naming infrastructure of the Internet. While it is in
> theory possible to use the DNS to advertise very rapid changes to Internet
> infrastructure, the
On Wed, 11 Sep 2013, Joe Abley wrote:
1. We only need to know the current time to an accuracy of 1 hour.
[RRSIG expiration times are specified with a granularity of a second, right?
I appreciate that most people are generous with signature inception and expiration times
in order to facilita
On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters wrote:
> On Wed, 11 Sep 2013, Joe Abley wrote:
>
>
>>> 1. We only need to know the current time to an accuracy of 1 hour.
>>>
>>
>> [RRSIG expiration times are specified with a granularity of a second,
>> right?
>>
>> I appreciate that most people ar
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker wrote:
>
> The DNS is the naming infrastructure of the Internet. While it is in theory
> possible to use the DNS to advertise very rapid changes to Internet
> infrastructure, the practice is that the Internet infrastructure will look
> almost
On Sep 10, 2013, at 6:45 PM, Evan Hunt wrote:
> On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
>> My colleagues and I worked on OpenWrt routers to get Unbound to work
>> there, what you need to do is to start DNS up in non-validating mode wait
>> for NTP to fix time, then ch
On Sep 10, 2013, at 8:17 PM, David Morris wrote:
>
>
> On Wed, 11 Sep 2013, Brian E Carpenter wrote:
>
>> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
>> ...
>>> My colleagues and I worked on OpenWrt routers to get Unbound to work there,
>>> what you need to do is to start DNS up in non-va
On Sep 10, 2013, at 7:17 PM, Brian E Carpenter
wrote:
> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
> ...
>> My colleagues and I worked on OpenWrt routers to get Unbound to work there,
>> what you need to do is to start DNS up in non-validating mode
>> wait for NTP to fix time, then check i
On Sep 11, 2013, at 7:19 AM, Olafur Gudmundsson wrote:
>> (Actually... the root nameservers could *almost* provide a workable time
>> tick for bootstrapping purposes right now: the SOA record for the root
>> zone encodes today's date in the serial number. So you do the SOA lookup,
>> set your sy
On Wed, 11 Sep 2013, Brian E Carpenter wrote:
> On 11/09/2013 09:59, Olafur Gudmundsson wrote:
> ...
> > My colleagues and I worked on OpenWrt routers to get Unbound to work there,
> > what you need to do is to start DNS up in non-validating mode
> > wait for NTP to fix time, then check if the
[cc'ed to a more approriate IETF wg]
On Sep 10, 2013, at 11:55 AM, Jim Gettys wrote:
> Ted T'so referred to a conversation we had last week. Let me give the
> background.
>
> Dave Taht has been doing an advanced version of OpenWrt for our bufferbloat
> work (called CeroWrt http://www.bufferbl
m: Olafur Gudmundsson mailto:o...@ogud.com>>
Date: Tuesday, September 10, 2013 5:59 PM
To: Jim Gettys mailto:j...@freedesktop.org>>
Cc: "dnsop@ietf.org<mailto:dnsop@ietf.org> WG"
mailto:dnsop@ietf.org>>, "i...@ietf.org<mailto:i...@ietf.org>
TF" mailto
Olafur Gudmundsson wrote:
>> So how do you get the time after you power on the device? The usual
>> answer is "use ntp". Except you can't do a DNS resolve when your
>> time is incorrect. You have a chicken and egg problem to
>> resolve/hack around :-(.
It is one reason why DNSSEC does not wort
On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
> My colleagues and I worked on OpenWrt routers to get Unbound to work
> there, what you need to do is to start DNS up in non-validating mode wait
> for NTP to fix time, then check if the link allows DNSSEC answers
> through, at wh
On 11/09/2013 09:59, Olafur Gudmundsson wrote:
...
> My colleagues and I worked on OpenWrt routers to get Unbound to work there,
> what you need to do is to start DNS up in non-validating mode
> wait for NTP to fix time, then check if the link allows DNSSEC answers
> through, at which point you c
On 2013-09-10, at 17:59, Olafur Gudmundsson wrote:
> [cc'ed to a more approriate IETF wg]
... and I'll gratuitously mention draft-jabley-dnsop-validator-bootstrap here
too, since it addresses exactly this topic.
Joe
___
DNSOP mailing list
DNSOP@i
49 matches
Mail list logo
