[Freeipa-devel] DNSSEC key metadata handling

[Petr Spacek]

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.

> It looks to me the only relevant states are Activated and (perhaps)
> Deactivated.
>
> But then again if replication is broken *many* other things are, so
> should we *really* care to handle broken replication by adding all this
> information ?
We need to keep track of timestamps anyway (to follow RFC 6781) so we need 
some other way how to *make sure* that timestamps never go backwards, even if 
replication was broken and later restarted.

What do you propose?

>> Effectively, state machine will be controlled by max(attribute) over all
>> replicas (for given key).
>>
>> Replication traffic estimation
>> ------------------------------
>> Number of writes to LDAP = (State transitions per key) * (Keys per zone) *
>> (Number of zones) * (Number of replicas)
>>
>> The obvious problem is that amount of traffic grows linearly with all variables.
>>
>> State transitions per key: 5
>> Keys per zone: 10
>> Zones: 100
>> Replicas: 30
>> Key life time: 1 month
>>
>> 5*10*100*30 / 1 month
>> i.e.
>> 150 000 writes / 1 month
>> i.e.
>> ~ 1 write / 17 seconds
>>
>> It seems like that this generates a lot of replication traffic. (Please note
>> that number of replicas/zones/keys per zone is also quite high but it will be
>> hard to improve scalability later if we decide to use LDAP in this way.)
>
> Right, and for an edge case that is already a broken state. I would
> rather spend time on a monitoring process that warns the amdin
> replication is broken rather than adding all this unnecessary traffic.
>
>> And ... our favorite question :-)
>> What should I use for cn=<some-replica-id> ? I would propose use either FQDN
>> of replica or value returned by LDAP whoami.
>
> Add to this dealing with dead/removed replicas ? I question the sanity
> of this approach :)
>
>> Proposal 2
>> ==========
>> Another possibility is to make timestamp attributes non-replicated and
>> (somehow) use DNS queries to determine if the desired key is available on all
>> other replicas before any state transition is allowed.
>>
>> That would require:
>> - Full-mesh replica-to-replica connectivity
>> - Similar amount of DNS query/response round trips (multiply <small int>)
>> - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS
>> answers and break key rotation mechanism during bootstrap (when no keys are
>> available) and maybe even later.
>>
>> It is easy to detect that key is:
>> - published
>> - unpublished
>> - used for signing
>>
>> The problem is that there is no reliable way to detect that is a key was
>> created/is available on replica but is not published yet and similarly that
>> the key is published but not used for signing anymore (it would require to
>> check all names published in the zone).
>>
>> I will think about it a bit more but I would like to know if full-mesh
>> replica-to-replica connectivity is acceptable requirement or not.
>
> Not really, and again I question the need to do this.
>
>> Almost-joke-proposal
>> ====================
>> The other alternative is to invent other mechanism for synchronous
>> replica-to-replica communication...
>
> Also called zone transfer ? :-P
Which is extremely expensive as mere existence check... :-)

I have to leave for today, let me know if you are interested in some details.

Have a nice day!

-- 
Petr^2 Spacek