Re: Keys at apex problem

[ted@tednet.nl (Ted Lindgreen)]

[Quoting Dan Massey, on Apr 18, 14:05, in "Keys at apex problem ..."]

> Do I tell the administrator to:
> 
> 1) Ignore the SHOULD and put the ssh key at the apex anyway.
>        The isi.edu zone will have to store the ssh key
>        and east.isi.edu must involve the parent in any ssh key change.
>        The ssh client should accept the ssh key for east.isi.edu based on 
>          the SIG from the isi.edu zone key?? (stored at isi.edu)
>          the SIG from the east.isi.edu key?? (stored at easti.isi.edu)
>          either SIG??
>          both SIGs??

First the questions:
-The ssh client, like any client, should look at the zoneKEY for
 any SIG other than the SIG over the zoneKEY itself. So it looks
 at "the SIG from the east.isi.edu key (stored at easti.isi.edu)"
- To Jakob Schlyter question: if a SIG fails, something is broken
  or hacked.
  But I think that a well designed client would only check the
  relevant SIGs: ssh-KEY-SIG against the zoneKEY and the zoneKEY-SIG
  against the parent-zoneKEY, etc. and would ignore other SIGs.
  So, if a relevant SIG fails, the zone is broken or hacked, if a
  non-relevant SIG fails nobody would know.

Now about 1)
 I think you (zone-admin of isi.edu) bests points at the SHOULD
 towards the administrator of east.isi.edu and then do either:
 1. Tell that your local policy is not to accept non-zoneKEYs in
    the zone-KEY RRset of your children.
 2. Tell that your local policy is to charge $1000000 for signing
    each additional non-zoneKEY in the zone-KEY RRset.

> 2) The A record is no longer allowed at the apex 
>        Forrest (the administrator) will point to zones like slashdot, cnn,
>        etc and say they do similar things.  He is not doing anything
>        particularly unique and nothing in the specs say he is wrong... 

Although I like it, I'm affraid it is not acceptable to change
this after allowing it for such a long time.

> 3) The SSH keys shouldn't be present in the zone file. 
>        Replace SSH with IPSEC, SSL, etc, etc and you have the same problem.  
>        If the KEY record is only for zone keys, let's make the spec say that.

This looks like a fundamental approach, but I'm not sure what changing
the definition of a KEY RR in such a way would mean for further delays 
in implementing DNSSEC.

> Currently I'm using option 4 which is to avoid the east.isi.edu zone
> administrator. :)

Yes! This one a fully understand :-)

Regards,
-- Ted.