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

[Edward Lewis <[e-mail]>]

At 10:26 +0100 9/23/04, Jim Reid wrote:
>>>>>>  "Edward" == Edward Lewis <[e-mail]> 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                                            [phone]
ARIN Research Engineer

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

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