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

From: Edward Lewis <[email-masked]>
Date: Wed, 22 Sep 2004 11:25:10 +0100

I spoke with a person who used to be a DNS administrator at a 
well-known content provider (non-ISP, non-registry, etc.).  He told 
be that when he was at that job, he would not have been able to 
justify the deployment of DNSSEC because of zone enumeration.  The 
rationale for this is "the usual" - nothing other than not wanting to 
put certain information "so easily" available on the Internet.

As far as on-line signing as an option, he replied that that was not 
a big deal for him.  "What's the difference between managing extra 
zone keys and managing TSIG keys for XFR's?"

(Just a data point...)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Alex Bligh <[email-masked]>
Date: Wed, 22 Sep 2004 16:01:29 +0100

> (Just a data point...)

another data point (and I only bring this up because it's something I
could say earlier):
 http://tinyurl.com/6datz

One of the reasons why I and others (Nominet) have been a little
circumspect about the copyright etc. issues associated with enumeration is
that the matter was sub-judice in Australia, so this is in part by away of
apology for being a little reticent as to the legal basis. We've now had a
first ruling in court showing registries do hold copyright in their own
zone files (at least in Australian law) - i.e. those registries operating
in the "interests of the local community" etc. can, at a legal level
control the use of zonefile contents; i.e. it is worth fighting about the
technical element.

Alex

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Sep 2004 23:11:46 +0700

Date:        Wed, 22 Sep 2004 16:01:29 +0100
    From:        Alex Bligh <[email-masked]>
    Message-ID:  <16B3CD5DBBBFFC13C2F51E0B@[192.168.0.16]>

  | - i.e. those registries operating
  | in the "interests of the local community" etc. can, at a legal level
  | control the use of zonefile contents; i.e. it is worth fighting about the
  | technical element.

This is exactly backwards.    If one were to assume that the registry
wanted to control distribution (and should be assisted in doing so, which
I don't agree with in this case, but ignore that for now), but had no legal
protection available (there was no copyright) then relying on keeping
things secret might be the only method available - and so seeking technical
means to do that would be worthwhile.

But the whole point of copyright protection, is so that information can
be made easily available to everyone, without the author of the information
losing their rights to it.

We don't expect newspapers (or books) to get printed on magic ink that
doesn't work with photocopiers - the publisher (or writer, or someone)
has copyright - that restricts the making of copies, inventing silly
and expensive technical means to do the same thing isn't justified
(especially since every time that's been attempted - consider DVDs -
it turns into a farce).

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Sep 2004 16:28:52 +0000

> ...
> As far as on-line signing as an option, he replied that that was not a big
> deal for him.  "What's the difference between managing extra zone keys and
> managing TSIG keys for XFR's?"

word on the street is, online signing isn't allowed in the dnssec-bis spec.
given that i'd been presenting it as a workaround, i now apologize to all
for misunderstanding the protocol.  getting online signing of negative
responses would apparently require the same transition pain as NSECxx, so
we can stop talking about it separately, and fold it into the NSECxx thread,
which is blocked on a requirements definition, to which ed's words apply:

> I spoke with a person who used to be a DNS administrator at a well-known
> content provider (non-ISP, non-registry, etc.).  He told be that when he
> was at that job, he would not have been able to justify the deployment of
> DNSSEC because of zone enumeration.  The rationale for this is "the usual"
> - nothing other than not wanting to put certain information "so easily"
> available on the Internet.

---

From: Derek Atkins <[email-masked]>
Date: Wed, 22 Sep 2004 13:21:47 -0400

> which is blocked on a requirements definition, to which ed's words apply:

Yes, this is exactly why a few of us were trying to hold up the
online signing conversation before the bis drafts were finalized,
because we realized you COULDN'T do online signing in bis.  :(

It sucks royally.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Sep 2004 17:46:47 +0000

> because we realized you COULDN'T do online signing in bis.  :(

i think that sucking royally is the reason a number of people were trying
to hold up finalizing the -bis drafts until they had been relaxed in some
way that would permit online signing without the full transition cost.

"good? bad? i'm the one with the gun."

onward.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 23 Sep 2004 02:41:53 +0200

> We've now had a first ruling in court showing registries do hold
> copyright in their own zone files (at least in Australian law)

WHOIS data or zone file data?  The press release only mentions WHOIS
data.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Sep 2004 11:38:26 +1000

> WHOIS data or zone file data?  The press release only mentions WHOIS

	http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Sep 2004 10:03:27 +0100

>word on the street is, online signing isn't allowed in the dnssec-bis spec.

I was shocked when I heard this in the hallway.  (So I had to remove 
my Paul Vixie kill-file entry ;) ...)

What about a signed zone that is dynamically updated - doesn't that 
physically require on-line signing?

Historically, on-line signing was distasteful because of the thought 
that the private key would be vulnerable to a host attack.  I think 
of that as a security engineer's issue - I don't think it was ever a 
DNS protocol issue.  In addition, in RFC 2065 we had strength bits - 
we tried for a time to use it to separate on-line keys from off-line 
keys.

I don't recall any discussion to "kill off" on-line signing.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Jim Reid <[email-masked]>
Date: Thu, 23 Sep 2004 10:26:01 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    >> word on the street is, online signing isn't allowed in the

    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.

---

From: Robert Elz <[email-masked]>
Date: Thu, 23 Sep 2004 17:30:11 +0700

Date:        Thu, 23 Sep 2004 11:38:26 +1000
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	http://www.austlii.edu.au/au/cases/cth/federal_ct/2004/1244.html

Thanks for the reference.    It is clear from that that zone files weren't
an issue at all (nothing in the events leading up to the case was in the
slightest bit interested in zone file contents) - just the whois database,
and Nominet's registry database.

It is also clear from this that as an authority on whether or not
copyright actually exists in (even those) databases (leaving aside the
zone file) this case is totally useless, as that question was conceded
by all parties - that is, no-one contested the issue of whether or not
copyright actually existed.   The judgement just repeats the statutary
requirements, and asserts (by agreement) that they're all satisfied.

I think that we're going to need another case sometime, where the issue
is actually debated, or quite a lot of cases where it is assumed (so that
it becomes obvious) before there's any finalisation of the issue.

kre

---

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

>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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 23 Sep 2004 12:12:14 +0100

Can we stop the discussing court cases. We are not lawyers.

--Olaf
  DNSEXT co-chair

---

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Sep 2004 22:56:28 +0000

> physically require on-line signing?

i meant online signing of negative responses, without precomputed NSECs.

---

From: David Blacka <[email-masked]>
Date: Fri, 24 Sep 2004 11:26:55 +0100

> i meant online signing of negative responses, without precomputed 

So the problem you were referring to wasn't online signing, it was NSEC 
synthesis at (otherwise) non-existent names, right?

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Fri, 24 Sep 2004 18:08:00 +0000

> synthesis at (otherwise) non-existent names, right?

yes.