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 but
On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley glen.wi...@gmail.com 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
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
robert bownes wrote:
A 1pulse per second aligned to GPS is good to a few ns.
GPS time may be accurate, if it were assured to be secure.
Masataka Ohta
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
Martin Rex wrote:
There is no problem with the assumption that trusted third party
_could_ exist.
It couldn't.
What organization in US can be trusted against attacks by USG?
Note that Snowden demonstrated that even USG failed to keep its
top secret.
The reason where PKI breaks badly is
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
On 9/12/13 2:07 PM, Ted Lemon ted.le...@nominum.com wrote:
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com
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
On 9/12/13 7:24 AM, Theodore Ts'o ty...@mit.edu 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
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu 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
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
Masataka Ohta 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 apart.
Right. PKI is
Phillip Hallam-Baker wrote:
3) A relying party thus requires a demonstration that is secure against a
replay attack from one or more trusted parties to be assured that the time
assertion presented is current but this need not necessarily be the same as
the source of the signed time assertion
Phillip Hallam-Baker hal...@gmail.com 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
On 9/12/13 3:02 AM, Masataka Ohta wrote:
Phillip Hallam-Baker wrote:
3) A relying party thus requires a demonstration that is secure against a
replay attack from one or more trusted parties to be assured that the time
assertion presented is current but this need not necessarily be the same
Arturo Servin wrote:
3) A relying party thus requires a demonstration that is secure against a
replay attack from one or more trusted parties to be assured that the time
assertion presented is current but this need not necessarily be the same as
the source of the signed time assertion itself.
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 business
Theodore Ts'o wrote:
More importantly, what problem do people think DNSSEC is going to
solve?
Insufficient revenue of registries.
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
Theodore Ts'o ty...@mit.edu 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
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
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com 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
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 the
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu 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
On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o ty...@mit.edu 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
On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon ted.le...@nominum.com wrote:
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com
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
On Sep 12, 2013, at 2:35 PM, Phillip Hallam-Baker hal...@gmail.com 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.
On Sep 12, 2013, at 11:07 AM, Theodore Ts'o ty...@mit.edu 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
On Sep 12, 2013, at 3:16 PM, Dickson, Brian bdick...@verisign.com 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
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 trust
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,
On Sep 12, 2013, at 1:21 PM, Theodore Ts'o ty...@mit.edu 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 Sep 11, 2013, at 12:38 PM, Phillip Hallam-Baker hal...@gmail.com 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
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 attack,
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
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 bogus
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com 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
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote:
On Sep 10, 2013, at 8:17 PM, David Morris d...@xpasc.com 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
On Sep 10, 2013, at 6:45 PM, Evan Hunt e...@isc.org 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,
On Sep 10, 2013, at 7:17 PM, Brian E Carpenter brian.e.carpen...@gmail.com
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
On Sep 10, 2013, at 8:17 PM, David Morris d...@xpasc.com 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
On Sep 11, 2013, at 7:19 AM, Olafur Gudmundsson o...@ogud.com 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
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 which
Hi -
From: Olafur Gudmundsson o...@ogud.com
Sent: Sep 11, 2013 7:19 AM
To: Evan Hunt e...@isc.org
Cc: dn...@ietf.org WG dn...@ietf.org, ietf@ietf.org TF ietf@ietf.org
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.
...
RRSIG on the SOA or NS or DNSKEY also is fine timestamp
On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver nwea...@icsi.berkeley.edu
wrote:
On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com
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
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
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
On 2013-09-11, at 11:43, Phillip Hallam-Baker hal...@gmail.com 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
On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters p...@nohats.ca 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 are
Hi Jim,
On 2013-09-10, at 11:55, Jim Gettys j...@freedesktop.org wrote:
We uncovered two practical problems, both of which need to be solved to
enable full DNSSEC deployment into the home:
1) DNSSEC needs to have the time within one hour. But these devices do not
have TOY clocks (and
On Tue, 10 Sep 2013, Jim Gettys wrote:
We uncovered two practical problems, both of which need to be solved to enable
full DNSSEC deployment into the home:
1) DNSSEC needs to have the time within one hour. But these devices do not
have TOY clocks (and arguably, never will, nor even probably
Paul Wouters p...@cypherpunks.ca wrote:
/dev/random references into /dev/urandom. You are most likely better of
giving the device a webgui and using the clients javascript to generate
randomness. (yes I know, I just said to use javascript for private
keys)
I agree ---
Paul Wouters p...@cypherpunks.ca wrote:
One solution is tlsdate which uses the installed bundled CA (or comes
with its own) and runs TLS against a bunch of well known large sites
(using insecure DNS) and sets the time based on the TLS handshakes.
I believe tlsdate currently only gets the time
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 can
Hi Jim,
At 08:55 10-09-2013, Jim Gettys wrote:
We uncovered two practical problems, both of which need to be solved
to enable full DNSSEC deployment into the home:
1) DNSSEC needs to have the time within one hour. But these devices
do not have TOY clocks (and arguably, never will, nor even
I faced this problem in Omnibroker.
One answer is that DNS is an infrastructure for resolving Internet labels
to Internet resources including IP addresses. It is thus the only Internet
infrastructure where infrastructure providers may reasonably be expected to
maintain long term IP addresses by
On 2013-09-10, at 12:58, Michael Richardson mcr+i...@sandelman.ca wrote:
But I'm still thinking of a scheme involving insecure ntp lookups for
pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow
down the current time. Of course, all of that is vulnerable to replay
attacks.
Jim:
1) DNSSEC needs to have the time within one hour. But these devices do not
have TOY clocks (and arguably, never will, nor even probably should ever have
them).
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
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.bufferbloat.net/projects/cerowrt/wiki/Wiki).
Of course, we both want things other than just bufferbloat,
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 link
On 2013-09-10, at 16:52, Russ Housley hous...@vigilsec.com wrote:
NTP can be used to get time from an IP address. I understand all of the
reasons why a DNS name is preferred, but this a bootstrapping problem.
Retrieval of root zone KSK trust anchors requires a DNS name, however (and you
[cc'ed to a more approriate IETF wg]
On Sep 10, 2013, at 11:55 AM, Jim Gettys j...@freedesktop.org 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
61 matches
Mail list logo
