[ksk-change] Capabilities of validating systems we need to consider

Michael StJohns msj at nthpermutation.com
Sun Sep 21 17:24:56 UTC 2014


On 9/21/2014 11:37 AM, Joe Abley wrote:
> Hi Paul,
>
> Veering off at a slight tangent for the purpose of agenda-building:
>
> On 21 Sep 2014, at 11:27, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>
>> Greetings again. In thinking about the question of "what would happen if we changed the KSK", but without thinking about why and when, it would be good to think about what kinds of systems are out there. My initial list came to three categories of capabilities:
>>
>> 1) Able to automatically pull and correctly use a new KSK
> 1.3) Able to retrieve a new KSK public key in-band through the DNS and verify its authenticity using an existing trust anchor and DNSSEC (e.g. RFC 5011)
>
> 1.6) Able to retrieve a new KSK public key out-of-band through other methods and verify its authenticity before using it (e.g. using draft-jabley-dnsop-validator-bootstrap
>
> 1.6.5) is the approach in draft-jabley-dnsop-validator-bootstrap a reasonable one?
>
> 1.6.7) do we need to consider other approaches to trust anchor publication by IANA?

TANSTAAFL  - basically, you still need to know which root you trust 
(X.509) before you can select a DNSSEC trust anchor.  Which leads to the 
question of how do you recover if that X.509 root is compromised?  The 
approach is interesting, but just recurses the problem over to somewhere 
else without actually figuring out what the worst case compromise 
approach needs to be.   The main saving grace for the approach is that 
it moves data handling issues (e.g. size of the root DNSKEY RRSet) from 
DNS over to something else.

>
>> 2) Cannot automatically pull a new KSK, or cannot correctly use an automatically-pulled KSK; however, it can correctly get and use a new KSK with operator intervention
>>
>> 3) Even with operator intervention, cannot pull a new KSK or cannot correctly use an manually-pulled KSK
>>
>> Are there other categories that would look operationally different to either customers of the system or to operators of signed zones?
>>
>> We will certainly later debate how many systems are in these categories and if those systems are "important", but it would be good to start with the smallest complete set to talk about.
>
> Joe
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover



More information about the ksk-rollover mailing list