This may seem a little strange, contrarian even, given how implacably
opposed to new things in this space pending some sanity, but I am
actually, broadly speaking, in favour of defining the world as it is,
regarding localhost.
If somebody seeks to invent something new, that is a discussion of its
Hi,
I wasn’t aware of this draft and will have to take a look at it, but note that
the DNSOP charter includes:
6. Publish documents that attempt to better define the overlapping
area among the public DNS root, DNS-like names as used in local
or restricted naming scopes, and the 'special names' r
Ondřej,
At 2016-11-17 01:02:10 +0100
Ondřej Surý wrote:
> > Given the low margin, my suspicion is that most CPE manufacturers would NOT
> > want
> > to add in any additional components to solve what for them would be an edge
> > case in terms of volume.
>
> This is the main problem. Most CP
Sure. We could also ask the IAB--there's a ton of expertise on the IAB. :)
However, in fact it's an accident of slow deployment of DNSSEC
validators that this has worked for thirty years, which would suggest
that that experience isn't going to help that much.
That said, I really was just bein
On Thu, Nov 17, 2016 at 01:19:28PM +0900, Ted Lemon wrote:
> The reason I ask is that the document proposes /not/ to use DNS to resolve
> it, which I think is correct. So it really doesn't sound like a dnsop
> issue. It's sounds like an intarea issue, or else keep it in sunset4.
Perhaps changing a
RFC 6303 doesn't help, because locally-served zones are all under
.arpa, and hence can have secure delegations. It is analogous to
.ONION, yes.
On Thu, Nov 17, 2016 at 2:06 PM, Shane Kerr wrote:
> Ted,
>
> Isn't this more-or-less the same as .ONION then? We're searching for a
> label-based swit
Ted,
Isn't this more-or-less the same as .ONION then? We're searching for a
label-based switch to disable DNS?
An alternate interpretation would be that this is something that could
be added to RFC 6303, "Locally Served DNS Zones". While that RFC is
only about reverse DNS now, one could step back
The reason I ask is that the document proposes /not/ to use DNS to resolve
it, which I think is correct. So it really doesn't sound like a dnsop
issue. It's sounds like an intarea issue, or else keep it in sunset4.
Additionally, the root zone will respond to queries for localhost with a
secure den
Ted,
> On Nov 17, 2016, at 12:46 PM, Ted Lemon wrote:
>
> Just to play the devil's advocate here, what does this have to do with DNS?
>From the abstract:
This document updates RFC6761 by requiring that the domain
"localhost." and any names falling within ".localhost." resolve to
loopb
Just to play the devil's advocate here, what does this have to do with DNS?
On Thu, Nov 17, 2016 at 12:07 PM, Matthew Pounsett wrote:
>
>
> On 17 November 2016 at 12:00, Dan York wrote:
>>
>> DNSOP,
>>
>> In SUNSET4 right now, Emily Stark from Google presented a draft from Mike
>> West (also Goo
+1 for adoption, and I will try to actively review more drafts from now again.
Not only this one.
O.
--
Ondřej Surý -- Technical Fellow
CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.s...@n
On Thu, Nov 17, 2016 at 11:48 AM, Ondřej Surý wrote:
> Section 7 (nit): s/implimentations/implementations/
>
> Applied
> Otherwise I have reviewed the document and I believe it's ready to be put
> in the oven.
>
> ~~~
>
> There's a small procedural thing - the last name of the draft
> appears o
Dear all,
I reviewed draft-wallstrom-dnsop-dns-delegation and I think
it useful as an overview of the current RFC on the subject
are. At the same time I think that in some parts it doesn't
match the current (or possibly) future operational best practice.
One such example is the "@ MX 0 ." that's
On 17 November 2016 at 12:00, Dan York wrote:
> DNSOP,
>
> In SUNSET4 right now, Emily Stark from Google presented a draft from Mike
> West (also Google) asking to update the language in RFC 6761 around the
> resolution of localhost:
>
> Draft: https://tools.ietf.org/html/draft-west-let-localhost
DNSOP,
In SUNSET4 right now, Emily Stark from Google presented a draft from Mike West
(also Google) asking to update the language in RFC 6761 around the resolution
of localhost:
Draft: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-02
Slides:
https://www.ietf.org/archive/id
On Thu, 17 Nov 2016, Ondřej Surý wrote:
Mikael,
the operation of the root zone and signing of the root
zone is in the ICANN/IANA bailiwick. Therefore most of
the relevant document to the RZ DNSSEC operations can
be found at https://www.iana.org/dnssec/ and the document
you are most interested
Dear all,
I reviewed draft-wallstrom-dnsop-dns-delegation and I think
--
Ondřej Surý -- Technical Fellow
CZ.NIC, z.s.p.o.-- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.s...@nic.czhttps://nic.cz/
--
Section 7 (nit): s/implimentations/implementations/
Otherwise I have reviewed the document and I believe it's ready to be put in
the oven.
~~~
There's a small procedural thing - the last name of the draft
appears on both datatracker.i.o and tools.i.o. I believe it
would be better to reupload t
Mikael,
the operation of the root zone and signing of the root
zone is in the ICANN/IANA bailiwick. Therefore most of
the relevant document to the RZ DNSSEC operations can
be found at https://www.iana.org/dnssec/ and the document
you are most interested in is here:
http://data.iana.org/root-ancho
On Thu, 17 Nov 2016, Ondřej Surý wrote:
Again, you are using unfair arguments. The devices have to cope with
that and it doesn't have to be a protocol design.
Agreed. It can also be method design. There have been some suggestions in
this thread for ways to handle the problem. I have not seen
- Original Message -
> From: "Mikael Abrahamsson"
> To: "Ted Lemon"
> Cc: "dnsop"
> Sent: Thursday, 17 November, 2016 01:44:59
> Subject: Re: [DNSOP] DNSSEC operational issues long term
> On Thu, 17 Nov 2016, Ted Lemon wrote:
>
>> Embedded systems of this sort need to have a managemen
btw this is not in any sense a novel problem. Anyone who owns a Dell,
and uses iDrac will be familiar with the "your certificate chain to
this console java app is expired" problem. It can be fixed, but it
requires effort.
And alongside the crypto age-out problem, the dependency on java is
increasi
Sent from my iPhone
> On Nov 16, 2016, at 22:41, Bob Harold wrote:
>
>> This is not well thought out, but what jumps to mind is to keep a chain of
>> signatures in the root DNS that links from the original KSK up through the
>> current KSK (or at least the last 10 years). Perhaps a differen
On Nov 16, 2016, at 22:38, Philip Homburg wrote:
>> Did you see my original response? Proposals for automatic DNSSEC trust
>> anchor updating *do* exist.
>
> Is there any document that deals with the situation where a device has
> been in a box for 10 years and then has to bootstrap automatical
On Thu, 17 Nov 2016, Ted Lemon wrote:
Embedded systems of this sort need to have a management process so that
that can be updated. This is needed for more reasons than DNSSEC. Putting a
ten year old device on a network without upgrading the firmware is
irresponsible.
We have been discussing ze
On 11/17/16, 08:49, "Matthew Pounsett" wrote:
>On 17 November 2016 at 06:57, "joel jaeggli" wrote:
>
>>A decade is well within the service range of all sorts embedded systems.
>
>Service range, sure. But back-room storage range?
The day before I flew here I took time to unbox a printer my wife bo
In message , Dan York writes:
> Mark,
>
> I agree that a physical solution could be a workable option (and a nice
> one), BUT
>
> On Nov 17, 2016, at 6:46 AM, Mark Andrews
> mailto:ma...@isc.org>> wrote:
>
> Is it that hard to add a sim or sd card reader? This is the solution
> the cable indu
- Original Message -
> From: "Dan York"
> To: "Mark Andrews"
> Cc: "Evan Hunt" , "Bob Harold" , "dnsop"
> , "Mikael Abrahamsson"
>
> Sent: Wednesday, 16 November, 2016 23:28:18
> Subject: Re: [DNSOP] DNSSEC operational issues long term
>
> On Nov 17, 2016, at 6:46 AM, Mark Andrews < [
On 17 November 2016 at 06:57, joel jaeggli wrote:
>
> A decade is well within the service range of all sorts embedded systems.
>
Service range, sure. But back-room storage range? I agree it's an
unreasonably long time to have something to sit on a shelf, never-used, and
then expect it to work
> On Nov 16, 2016, at 1:56 AM, Mikael Abrahamsson wrote:
>
> So if it's manufactured the day before a new key is publically released, when
> is the key material it has built in no longer viable to have successful
> DNSSEC validation?
Since we haven't done a root KSK roll yet, a general answer
- Original Message -
> From: "Emily Shepherd"
> To: "Mikael Abrahamsson"
> Cc: "dnsop"
> Sent: Wednesday, 16 November, 2016 14:26:53
> Subject: Re: [DNSOP] DNSSEC operational issues long term
> On Wed, Nov 16, 2016 at 02:18:17PM +0100, Mikael Abrahamsson wrote:
>>Ok, so what I see right
Mark,
I agree that a physical solution could be a workable option (and a nice one),
BUT
On Nov 17, 2016, at 6:46 AM, Mark Andrews mailto:ma...@isc.org>>
wrote:
Is it that hard to add a sim or sd card reader? This is the solution
the cable industry uses for its crypto issues but with bigge
Embedded systems of this sort need to have a management process so that
that can be updated. This is needed for more reasons than DNSSEC. Putting a
ten year old device on a network without upgrading the firmware is
irresponsible.
On Nov 17, 2016 06:57, "joel jaeggli" wrote:
> On 11/16/16 10:44 P
On 11/16/16 10:44 PM, Wessels, Duane wrote:
>
>> On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson wrote:
>>
>> As a whole, nobody seems to be interested in actually coming up with a
>> viable solution that actually fixes peoples problems. Everybody's just
>> punting the problem elsewhere or wav
There is also the physical solution. Have removable storage for
the key and update the key using this externally when reqired. Nano
sims or micro sd card would be a good form factor for this. Pick
a standard file name and you just have them sitting on the shelves
in stores with the key date pri
On Wed, Nov 16, 2016 at 08:41:03AM -0500, Bob Harold wrote:
> > Do you have a suggestion for a solution?
> >
> This is not well thought out, but what jumps to mind is to keep a chain of
> signatures in the root DNS that links from the original KSK up through the
> current KSK (or at least the last
Steve Crocker wrote:
> I recall a discussion several years about having a site that
> would have
> all of the keys accumulated over time. A query to it would return the
> current key. It's roughly analogous to using a root hints file
> to find a
> current root server and from that the full set
I recall a discussion several years about having a site that would have all of
the keys accumulated over time. A query to it would return the current key.
It's roughly analogous to using a root hints file to find a current root server
and from that the full set of current servers.
This wouldn
Johan Ihren and I and Olaf had a competing ID that delt with shelf life and
embedded devices w/o an easy way to update key info. RFC 5011 won out
since shelf life and embedded devices were considered edge cases.
/Wm
On Wednesday, 16 November 2016, Tony Finch wrote:
> Wessels, Duane > wrote:
>
Wessels, Duane wrote:
>
> I don't think its possible to have a solution that works for devices on
> the shelf for an arbitrarily long time. You posed the problem as 10
> years, which I think is an unrealistically long time.
>
> You could probably have a useful discussion about what is an appropri
Looks like someone else thought of it already:
https://tools.ietf.org/html/draft-wijngaards-dnsext-trust-history-03
Thanks to Jaap for that info.
Someone will probably point out that using keys for a long time increases
the chances that someone can break them, But in this case I think it is
On Wed, 16 Nov 2016, Bob Harold wrote:
This is not well thought out, but what jumps to mind is to keep a chain
of signatures in the root DNS that links from the original KSK up
through the current KSK (or at least the last 10 years). Perhaps a
different record type, so it is only sent if aske
Philip Homburg writes:
> >Did you see my original response? Proposals for automatic DNSSEC trust
> >anchor updating *do* exist.
>
> Is there any document that deals with the situation where a device has
> been in a box for 10 years and then has to bootstrap automatically?
>
> I'm not awa
> On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson wrote:
>
> As a whole, nobody seems to be interested in actually coming up with a viable
> solution that actually fixes peoples problems. Everybody's just punting the
> problem elsewhere or waving their hands and says "not our problem".
I don
On Wed, Nov 16, 2016 at 8:30 AM, Dan York wrote:
>
> On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson wrote:
>
> As a whole, nobody seems to be interested in actually coming up with a
> viable solution that actually fixes peoples problems. Everybody's just
> punting the problem elsewhere or wavi
>Did you see my original response? Proposals for automatic DNSSEC trust
>anchor updating *do* exist.
Is there any document that deals with the situation where a device has
been in a box for 10 years and then has to bootstrap automatically?
I'm not aware of any. But maybe there is.
Note that by a
On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson
mailto:swm...@swm.pp.se>> wrote:
As a whole, nobody seems to be interested in actually coming up with a viable
solution that actually fixes peoples problems. Everybody's just punting the
problem elsewhere or waving their hands and says "not our
On Wed, Nov 16, 2016 at 02:18:17PM +0100, Mikael Abrahamsson wrote:
Ok, so what I see right now is DNSSEC punting the problem somewhere
else. NTP is punting it somewhere else. TLS is punting it somehere
else.
I don't think this is what people are saying. The issue of trust anchor
updates is o
On Wed, 16 Nov 2016, Philip Homburg wrote:
Recently, there was some discussion in homenet related to this topic, in
particular how does a device without battery backed RTC obtain the
current time.
I think that ideally this should be discussed in a security related
working group. Because a lo
>Now after 10 years after plugging the first one in, I take the second one
>off the shelf and plug it in. It will now not work because there has been
>a root zone key rollover. I am told this is by design. This makes me a sad
>panda.
>
>We have a bootstrapping problem. My device has no way to kn
Ted Lemon wrote:
> Why would you put a device on the shelf for ten years?
The failure occurs if a device is on the shelf for the wrong 6 months
(second half of 2017) and this is a completely reasonable length of time
to hold stock.
> This is certainly a known issue that has been talked about at
On Wed, Nov 16, 2016 at 10:56:35AM +0100, Mikael Abrahamsson wrote:
So if it's manufactured the day before a new key is publically
released, when is the key material it has built in no longer viable to
have successful DNSSEC validation?
The new KSK was generated at the end of October this year
> On 16 Nov 2016, at 10:24, Jerry Lundström wrote:
>
> How does this affect if I want to build an implementation?
What are the chances that the patent holder will be litigous? Do you (or your
employer) feel lucky? :-)
Personally, I wouldn't risk implementing something that has a patent or IPR
Hi all,
How does this affect if I want to build an implementation?
Cheers,
Jerry
On 11/15/16 01:48, IETF Secretariat wrote:
> Dear Jim Hague, John Dickinson, Sara Dickinson, Terry Manderson, John Bond:
>
>
> An IPR disclosure that pertains to your Internet-Draft entitled "C-DNS: A
> DNS Packet
> On 16 Nov 2016, at 10:12, Jaap Akkerhuis wrote:
>
> Mikael Abrahamsson writes:
>
>> So if it's manufactured the day before a new key is publically released,
>> when is the key material it has built in no longer viable to have
>> successful DNSSEC validation?
>
> A properly designed device
Mikael Abrahamsson writes:
> So if it's manufactured the day before a new key is publically released,
> when is the key material it has built in no longer viable to have
> successful DNSSEC validation?
A properly designed device will discover that its preconfgured trust
anchor differs from
> On Nov 16, 2016, at 18:56, Mikael Abrahamsson wrote:
>
> So if it's manufactured the day before a new key is publically released, when
> is the key material it has built in no longer viable to have successful
> DNSSEC validation?
Do the first (only) bootstrap without validation if validatio
On the current timeline, October 11 -> January 11 so three months.
Vendors of sealed units who ship equipment from before October 11 with
delivery held up for three months at the docks by a strike, or people
who put the sealed unit into a long-delay orbit to Mars to be turned
on by Matt Damon on
On Wed, 16 Nov 2016, George Michaelson wrote:
I feel this is a corner case. My experience with 'mom' whitegoods is
that they age out much faster than the 10+ year case. Shops do not hold
electronic goods for sale that long, if its old but unboxed, you have
taken yourself into a dark alley deli
I feel this is a corner case. My experience with 'mom' whitegoods is
that they age out much faster than the 10+ year case. Shops do not
hold electronic goods for sale that long, if its old but unboxed, you
have taken yourself into a dark alley deliberately. If you genuinely
were supporting your mum
Or your device needs an RTC...
On Wed, Nov 16, 2016 at 6:30 PM, Mikael Abrahamsson wrote:
> On Wed, 16 Nov 2016, Ted Lemon wrote:
>
>> Why would you put a device on the shelf for ten years? Is this a real
>> scenario? This is certainly a known issue that has been talked about at
>> length--the
On Wed, 16 Nov 2016, Ted Lemon wrote:
Why would you put a device on the shelf for ten years? Is this a real
scenario? This is certainly a known issue that has been talked about at
length--the conclusion when it was discussed is that there is nothing we
can do about it, and it's relatively un
I echo what Ted said. If its 'not well known' its a property of the
RFC ecology in general, that things we did know, and did document,
wind up buried in the RFC free text search.
>From memory, the specific issue was discussed across at least two
rounds of IETF, as a thing. I seem to recall Mike St
> On Nov 16, 2016, at 15:09, Ondřej Surý wrote:
>
> Hi,
>
> I read the document and I believe that the document goes to far
> to recommend the vendors how to implement the knobs in their
> software here:
>
> It is recommended that resolvers that implement Aggressive Negative
> Caching prov
Why would you put a device on the shelf for ten years? Is this a
real scenario? This is certainly a known issue that has been talked
about at length--the conclusion when it was discussed is that there is
nothing we can do about it, and it's relatively unlikely, and manually
fixable.
On Wed, No
Hi Ondřej,
On 16-11-16 07:09, Ondřej Surý wrote:
Hi,
I read the document and I believe that the document goes to far
to recommend the vendors how to implement the knobs in their
software here:
It is recommended that resolvers that implement Aggressive Negative
Caching provide a configura
Hi,
today I have discovered something after talking to some people that know
more than I do.
Example:
I go to the store and buy two DNSSEC enabled devices that rely on DNSSEC
working for them to work.
I put one device on the network immediately and the other one on the
shelf. The one I p
67 matches
Mail list logo
