[Freeipa-devel] DNSSEC support design considerations: key material handling

Loris Santamaria loris at lgs.com.ve
Mon Aug 12 12:30:04 UTC 2013


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
> >>>>> first.
> >>>>>
> >>>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
> >>>>>>
> >>>>>> The most important question at the moment is "What can we postpone?
> >>>>>> How
> >>>>>> fragile it can be for shipping it as part of Fedora 20?" Could we
> >>>>>> declare
> >>>>>> DNSSEC support as "technology preview"/"don't use it for anything
> >>>>>> serious"?
> >>>>>
> >>>>> 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
> >>>> side
> >>>> 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.
> >>>> Validation
> >>>> 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
> >> master ?
> 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 
> expires.)
> 
> >> 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
so on.

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
master.

The cicle will repeat every "number of master" days, in the example
every four days. 


-- 
Loris Santamaria   linux user #70506   xmpp:loris at lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:103 at lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6173 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130812/db01cb91/attachment.bin>


More information about the Freeipa-devel mailing list