[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Michael Richardson]

    > On Mar 15, 2019, at 4:30 PM, Michael Richardson <mcr+ietf at sandelman.ca>
    > wrote:

    > It seems that these issues exist if there are *any* keys generated before
    > use, independently of the number of keys.

Fred Baker <fred at isc.org> wrote:
    > To my mind, the argument has the issue backwards. The issue is that the
    > resolver needs to be able to resolve keys currently signed by the IANA, which
    > means that it needs to know "a" current public key to validate the DNSKEY
    > response. Rather than publish 2^12 keys that might or might not be used in
    > the future, it seems to me that it has to be able to identify *a* public key
    > that has been used in the past and use that to get the current public
    > key.

I agree with you.
(I think that there is a substantive difference between 2^12 keys, and 12
keys, and I think 2^12 was hyperbole... moving on)

    > It might be simplest to let resolver software bake whatever "current key"it
    > likes,

I agree that having a path from the current key at time X to the current key
at time Y is a good thing.  I don't think it needs to be contained in .

    > perhaps among a set of candidates, into the software, and use
    > that
    > public key to sign the NS request to the root. If the decrypted request is
    > recognized by the root, it replies to the DNSKEY request with the current
    > key.

While the math says you can encrypt/decrypt with either "public" or "private"
keys, and the practice says otherwise.  In particular,
  a) none of root name servers have the private keys online

  b) the root name servers are run by 13 different entities, and each has 50+
     anycast nodes operating as root name servers.

  c) thanks to DNSSEC there is significant thinking to having recursive
     resolvers take a copy of the root zone by <someprotocol>, and not
     bothering the root name servers as often.

    > The attack on that would be to flood the root with requests using whatever
    > key might be randomly generated (or no real key), consuming the root's
    > resource to validate signatures. I'm not sure I have a response to that, but
    > it probably comes down to a cheap way to identify candidates for validation
    > and ignore the rest.

The attackers know the real public key (it's public), so they don't have to
fake it.  They could put random garbage in, which I think is your point.

--
]               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    [


--
Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- 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/20190316/1cea242a/signature.asc>