[Freeipa-devel] DNSSEC key metadata handling

[Petr Spacek]

On 18.6.2014 19:19, Petr Spacek wrote:
> On 13.6.2014 18:43, Petr Spacek wrote:
>> On 12.6.2014 17:49, Petr Spacek wrote:
>>> On 12.6.2014 17:19, Simo Sorce wrote:
>>>> On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote:
>>>>> Hello list,
>>>>>
>>>>> I have realized that we need to store certain DNSSEC metadata for every
>>>>> (zone,key,replica) triplet. It is necessary to handle splits in replication
>>>>> topology.
>>>>>
>>>>> DNSSEC key can be in one of following states:
>>>>> - key created
>>>>> - published but not used for signing
>>>>> - published and used for signing
>>>>> - published and not used for signing but old signatures exist
>>>>> - unpublished
>>>>>
>>>>> Every state transition has to be postponed until relevant TTL expires,
>>>>> and of
>>>>> course, we need to consider TTL on all replicas.
>>>>>
>>>>>
>>>>> Example of a problem
>>>>> ====================
>>>>> DNS TTL=10 units
>>>>> Key life time=100 units
>>>>>
>>>>> Replica=1 Key=1 Time=0   Published
>>>>> Replica=2 Key=1 Time=0   Published
>>>>> Replica=1 Key=1 Time=10  Published, signing
>>>>> Replica=2 Key=1 Time=10  Published, signing
>>>>> Replica=1 Key=2 Time=90  Generated, published, not signing yet
>>>>> Replica=2 Key=2 Time=90  <replication is broken: key=2 is not on replica=2>
>>>>> Replica=1 Key=1 Time=100
>>>>> ^^^ From time=100, all new signatures should be created with key=2 but that
>>>>> can break DNSSEC validation because key=2 is not available on replica=2.
>>>>
>>>> Can you explain how this break validation ?
>>>> Aren't signatures regenerated on each replica ?
>>> They are.
>>>
>>>> And so isn't each replica self-consistent ?
>>> Ah, sorry, I didn't mention one important detail. Keys published in the zone
>>> 'example.com.' have to match keys published in parent zone. There has to be a
>>> mechanism for synchronizing this.
>>>
>>> Validation will break if (keys published by parent) are not subset of (keys on
>>> replicas).
>>>
>>> Next logical step in the example above is to remove key1 from replica 1 so you
>>> will end replica1 having key2 and replica2 having only key1.
>>>
>>> How can we guarantee that synchronization mechanism will not wipe key1 from
>>> parent? Or the other way around? How can we guarantee that key2 was uploaded?
>>>
>>> Also, things will break is number of keys in parent exceeds reasonable number
>>> (because DNS replies will be to big etc.).
>>>
>>>>> Proposal 1
>>>>> ==========
>>>>> - Store state and timestamps for (zone,key,replica) triplet
>>>>> - Do state transition only if all triplets (zone,key,?) indicate that all
>>>>> replicas reached desired state so the transition is safe.
>>>>> - This implicitly means that no transition will happen if one or more
>>>>> replicas
>>>>> is down. This is necessary otherwise DNSSEC validation can break
>>>>> mysteriously
>>>>> when keys got out of sync.
>>>>>
>>>>> dn: cn=<some-replica-id>,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec,
>>>>> cn=dns, dc=example
>>>>> idnssecKeyCreated: <timestamp>
>>>>> idnssecKeyPublished: <timestamp>
>>>>> idnssecKeyActivated: <timestamp>
>>>>> idnssecKeyInactivated: <timestamp>
>>>>> idnssecKeyDeleted: <timestamp>
>>>>
>>>> Why do you care for all 5 states ?
>>> In short, to follow RFC 6781 and all it's requirements.
>>
>> Simo and I have discussed this off-line. The final decision is to rely on
>> replication. The assumption is that if replication is broken, everything will
>> break soon anyway, so the original proposal is overkill.
>>
>> We have to store one set of timestamps somewhere to be able to follow RFC
>> 6781, so we decided to store it in the key-metadata object.
>>
>> I added other attributes to object class definition so it contains all
>> necessary metadata. The new object class idnsSecKey is now complete.
>>
>> Please note that DN in the previous example was incorrect. It is necessary to
>> store the metadata separately for pairs (zone, key) to cover the case where
>> key is shared between zones. This also nicely splits metadata from actual key
>> material.
>>
>> All attributes are single-valued.
>> MUST attributes are:
>>   idnsSecKeyRef
>>   idnsSecKeyCreated
>>   idnsSecAlgorithm
>>
>> dn: cn=<z/ksk+keytag>, cn=keys, idnsname=example.com, cn=dns, dc=example
>> objectClass: idnsSecKey
>> idnsSecKeyRef: <DN of the PKCS#11 key object under cn=keys, cn=sec, dn=dns>
>> idnsSecKeyCreated: <timestamp>
>> idnsSecKeyPublish: <timestamp>
>> idnsSecKeyActivate: <timestamp>
>> idnsSecKeyInactive: <timestamp>
>> idnsSecKeyDelete: <timestamp>
>> idnsSecKeyZone: <boolean> equivalent to bit 7 (ZONE) in [1]
>> idnsSecKeyRevoke: <boolean> equivalent to bit 8 (REVOKE) in [1]
>> idnsSecKeySep: <boolean> equivalent to bit 15 (SEP) in [1]
>> idnsSecAlgorithm: <string> used as mnemonic in [2]
>
> I haven't heard any complains so I allocated OIDs and I'm going to implement it.

Relevant LDAP schema is:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#DNSSECmetadata

Me and Honza have discussed off-line that reference from metadata to key 
material should be in form of PKCS#11 URI so it will work even with real HSM. 
The new definition is:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#idnsSecKeyRef

-- 
Petr^2 Spacek