On Mar 5, 2014, at 11:01 AM, Mark Andrews <ma...@isc.org> wrote:
>
> In message <20140305102536.gd9...@mx1.yitter.info>, Andrew Sullivan writes:
>> Mark,
>>
>> On Wed, Mar 05, 2014 at 08:58:23PM +1100, Mark Andrews wrote:
>>> a bit of flip flop but most of the time one is just "On WiFi" at home or
>>
>> The point is that we're designing a protocol, and "most of the time"
>> won't be good enough to avoid support calls to the ISP help desk. ISP
>> margins are thin enough that it would be a bad thing to build a
>> specification that encourages that even rarely.
>
> This is a problem that is INDEPENDENT of DNSSEC when you are siging both
> zones. This is about there being two versions of the zone.
>
>>> I really don't see this as being a issue in practice. Just sign
>>> the zone (all verisons) in the house with the same keys. Stop with
>>> this nonsence idea that you shouldn't sign the internal version
>>> when you are signing the external version.
>>
>> Mark, you're at least jumping ahead to implementation and at worst
>> begging the question. We started with a proposal that did signing in
>> the ISP's server. I was pointing out the consequences of that for
>> DNSSEC. One of the possible solutions is that the "internal version"
>> is unsigned. It would be careless not to list that as one of the
>> possibilities, even if I think that's a foolish outcome. We have to
>> list the possibilities we don't like, too, or else we won't have a
>> clear picture of what we're talking about.
>
> Signed and unsigned versions of the same zones are a REALLY REALLY
> REALLY REALLY bad idea. This is a "Doctor it hurts if I do this.
> Then don't do this." example. It could be made to work with negative
> trust anchors which are installed when the WiFi SSID matches the
> home's SSID but we really don't want to go there. There be dragons.
>
I think the fundamental question is
"Do we expect that INTERNAL zones on a home-net are signed ?
If the answer is yes then we have to assume that some device are DNS servers
have the
ability to sign the zones. If they can sign the internal zones they can sign the
external zones.
The key management when devices are "rolled" is an issue but that can be
addressed
by smart use of storage devices.
Rolled here means both Re-flashed and replaced by new one
> It is dead simple for nameserver in the CPE to do the signing. Why
> people thing it is beyond the capabilities of the a device like
> this is beyond me. The CPE generated the keys. It signs the
> records. It updates the parent zone to add DS records for the keys
> it has generated.
>
The device can sign if it has accurate time,
it can generate keys if it has good source of randomness.
It can be relied upon if the zone survives reboots.
> The owner of the CPE has to do nothing to make this happen.
There is no harm in signing when there is no DS
it is real bad to sign with a new key when there is a DS in place,
the same goes for not signing when there is a DS but the errors will be
different,
If the ISP/third party is signing the zones then they can handle the DS
management and it is easier to
roll the devices.
> Either sign all version or don't sign any.
>
> I will appeal any version that even hints that mixed signing is the
> way to go. It is just bad design, bad engineer and will cause pain
> for everyone.
>
The question is what is the "least bad design the can be deployed" along with
the question
"is there one fits all solution?"
Olafur
>> Best regards,
>>
>> A
>>
>> --
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
