On 12.8.2013 14:30, Loris Santamaria wrote:
El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió:
On 9.8.2013 15:12, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
The most important question at the moment is "What can we postpone?
fragile it can be for shipping it as part of Fedora 20?" Could we
DNSSEC support as "technology preview"/"don't use it for anything
Until we figur out proper management in LDAP we will be a bit stuck, esp
if we want to consider usin the 'somthing' that stores keys instead of
toring them stright in LDAP.
So maybe we can start with allowing just one server to do DNSSEC and
source keys from files for now ?
The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
All DNS servers have to support DNSSEC otherwise the validation on client
can fail randomly.
Note that *parent* zone indicates that the particular child zone is secured
with DNSSEC by sending DS (delegation signer) record to the client.
will fail if client receives DS record from the parent but no signatures are
present in data from 'child' zone itself.
This prevents downgrade (DNSSEC => plain DNS) attacks.
As a result, we have only two options: One DNS server with DNSSEC enabled or
arbitrary number DNS servers without DNSSEC, which is very unfortunate.
as soon as we have that workign we should also have clearer plans about
how we manage keys in LDAP (or elsewhere).
Dmitri, Martin and me discussed this proposal in person and the new plan is:
- Elect one super-master which will handle key generation (as we do with
special CA certificates)
I guess we can start this way, but how do you determine which one is
How do we select the 'super-master' for CA certificates? I would re-use the
same logic (for now).
I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.
AFAIU keys don't expire, rather there is a rollover process. The problem would
be if the server that controlled the rollover went away the keys would never
roll, leaving you potentially exposed.
In DNSSEC it could be a problem. Each signature contains validity interval and
validation will fail when it expires. It practically means that DNS will stop
working if the keys are not rotated in time. (More keys can co-exists, so the
roll-over process can be started e.g. a month before the current key really
I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.
I definitely agree. IMHO the basic problem is the same or very similar for
DNSSEC key generation & CA certificates, so we should solve both problems at
once - one day.
I mean - we need to coordinate key & cert maintenance between multiple masters
somehow - and this will be the common problem for CA & DNSSEC.
You could implement a "protocol" where each master has a day or the week
or the month where it checks if there are any pending keys or CA
certificates to renew and tries to do the job. Next day it is another
master's turn to do the same job and so on.
Every master is identified by an unique nsDS5ReplicaId, which could be
used as a vector to generate an ordered list of masters. If you have
masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with
nsDS5ReplicaId 5 is master number one, the next is master number two and
On first day of the month it is master number one's turn to check of any
pending key and CA certificate renewal issues and to do the renewal. On
second day of the month it is master number two's turn to do the same.
So if a master was down the job will be done next day by the next
The cicle will repeat every "number of master" days, in the example
every four days.
It is interesting idea... but I think that it is could be fragile and create
some serious problems.
Please see and reply to e-mail in this thread:
Thank you for your time & contribution!
Freeipa-devel mailing list