[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Michael Richardson]

Ondrej Filip <ondrej.filip at nic.cz> wrote:
    >> So, my original "gut feel" was approximately every year, and I still
    >> feel that that is roughly the right frequency -- but, I think that we
    >> first need to figure out what the cause of the increase in DNSKEY
    >> lookups is - it concerns me that we predicted no impact from the
    >> revocation, and we got... this. I think that, assuming we figure out
    >> the causes of the increase (and understand them well enough that we
    >> are fairly sure that they won't jump again!), my gut still says ~1year
    >> -- but, more research needed...

    > As a producer of a DNS validating CPE device/router, I must say, I am
    > not very excited about frequent roll-overs. If your device stays at a
    > retailer store for some time, you might be in a trouble. So I would
    > prefer some longer periods. But it is more important how much in
    > advance is the new key known/published.

I am also concerned about such devices.

Are you doing RFC5011?  if not, would you be willing to do that?

I know that Turris does automatic updates/patches... how much time would you
need to see the new key in order to be sure that you had incorporated new
anchors via software updates?

When you said "store" above, I was thinking that the CPE device was deployed
*at* a store.  (One of my ISP customers has about a thousand brick-and-mortal
retails with similar devices, and they are lucky to get any physical
maintenance).  I realize now that you meant that the device is a box at
a store (like amazon...) and it takes awhile to get plugged in.

I am particularly concerned about such devices, as they do not get updates while turned off.
I think that we need to find a way to extend RFC5011 to provide a way to
chain to current state of the art, and I think that turning DNSSEC off
to do software patches is the wrong idea.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190314/f90b13b0/signature.asc>