Subject: Re: another's view on zone enum & on-line signing

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Sep 2004 11:38:09 +0100

At 10:26 +0100 9/23/04, Jim Reid wrote:
>>>>>>  "Edward" == Edward Lewis <[email-masked]> writes:
>
>     >> At 16:28 +0000 9/22/04, Paul Vixie wrote:
>     >> word on the street is, online signing isn't allowed in the
>     >> dnssec-bis spec.
>
>     Edward> What about a signed zone that is dynamically updated -
>     Edward> doesn't that physically require on-line signing?
>
>I suppose a throwaway zone signing key could be on-line for on the fly
>signing of the updates and a strong key signing key kept off-line.

Back in the day...there was a discussion like this...

Let's assume that you have a zone with a mix of critical data and 
(for lack of a better word) vanity data.  Critical would be the 
address record of your mail server.  Vanity would be a CNAME to the 
entry you are using at a conference.

E.g. --->
      smtp           AAAA        <ip addr>
      marco.polo     CNAME       host-ripe49-139.example.net.

Since the smtp(-owned) record is critical, I'll sign it with key A, 
which is off-line and is 2048 bits long.  The latter record is 
dynamically added when I pop up the laptop, the key signing it is 
on-line and 512 bits long.

So - the smtp is signed "more" securely than marco.polo.  Or so I think.

There are a couple of problems.

One is - what if the attacker can make an update request to change 
smtp.  This would take just "breaking" through whatever ACL's are 
involved (IP, tsig key, TKEY, other policy, etc.).  The result is 
that smtp new's address is signed with the on-line key.

Another possibility is that the attacker gains the access to the 
private key (it is exposed).  In that case, the attacker can generate 
a new smtp record and slip that into the zone.  (Assuming that the 
attacker also has broken the host's security.)

To defend against the breaking of dynamic update policy we (Olafur, 
Brian, and I) toyed with the idea of using RFC 2065 KEY RR strength 
bits (signatory bits).  The idea was that no on-line SIG could usurp 
an off-line SIG.  I think that in trying to come up with a "strength 
scale" we encountered problems, I admit that my memory is foggy about 
this.  Probably because we saw the possibility of illicitly learning 
the on-line key as an insurmountable problem.

(If Olafur and/or Brian want to add to this, please do.  We had a lot 
of discussions back then that never made it out of the office and 
into recorded messages. ;)  The benefits of public mail list 
discussions and archives - discussions survive employment changes.)

Ultimately we determined (!= "and that's the way it is") that without 
a way to express to resolver/verifiers a policy that includes "these 
records can only be signed with this kind of key" and "those with the 
weaker key" it is useless for the server to use more than one key 
(per algorithm at a time).  (Yes, key replacement/rollover, etc. are 
times for multiple keys, but I'm not worried about that now.)

If we were to try now to differentiate between the keys a server uses 
- we'd have to 1) hardcode into the verifier algorithm a policy, or 
2) once again raise the the SEC RR:
    http://www.potaroo.net/ietf/all-ids//draft-ietf-dnsind-sec-rr-00.txt
(Note the last paragraph before section 2.)

BTW, we'd also have to specify that the SEC RR (set) would have to be 
signed off-line - otherwise the first record I'd replace is the SEC 
RR. ;)

In summary - unless some basic assumptions have changed (e.g., the 
trust model), I am quite pessimistic that differentiating between 
on-line and off-line keys is beneficial.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Robert Elz <[email-masked]>
Date: Thu, 23 Sep 2004 18:35:49 +0700

Date:        Thu, 23 Sep 2004 11:38:09 +0100
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a0602041dbd784f701cf4@[193.0.8.231]>

  | In summary - unless some basic assumptions have changed (e.g., the 
  | trust model), I am quite pessimistic that differentiating between 
  | on-line and off-line keys is beneficial.

Beneficial?   How is it even possible?    That is, how can anyone
(other than me) possibly tell whether or not the key used to sign
a zone is on-line or off-line - or really even whether a record was
dynamically signed on demand, or signed a year ago and stored (given
that if I am signing the data, I can set any date or time fields that
are included to anything I like before I sign it)?

This whole mention of banning on-line signing mistifies me.   I cannot
even imagine how it would be enforced, how anyone could determine
whether or not it had been done correctly (that is, if required to be
off line, how do you ensure that it was done off line, and for that matter,
what's the actual technical definition of "off line"), or anything else in
this area.

I certainly have no problems requiring the protocols to be able to be
implemented with no on-line keys - I believe that's always been a
goal, and should remain one.

But that doesn't mean that someone who cares a lot less about
security, or trusts their hosts security quite a lot, cannot use
on-line keys if they prefer it.   Exactly how is it proposed to
stop that?

kre

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Sep 2004 13:02:00 +0100

>are included to anything I like before I sign it)?

That was kind of my point. ;)

As far as "is it possible?" Well, yes, everything is possible - at a 
cost.  In this case, we'd have to code into resolver algorithm a 
rigid policy.

It would have to be in the algorithm and not the messages.  If you 
the assumption is that you can't trust the messages, you can't rely 
on the messages to tell you how to verify something. ;)

>what's the actual technical definition of "off line"), or anything else in

That's a good point - if there were a ban a resolver couldn't detect 
the violation.  (Same thought - if you assume the messages are not 
trustworthy...)