Re: How is DNSSEC

2008-03-27 Thread Steven M. Bellovin
On Fri, 21 Mar 2008 08:52:07 +1000
James A. Donald [EMAIL PROTECTED] wrote:

  From time to time I hear that DNSSEC is working fine, and on
 examining the matter I find it is working fine except that 
 
 Seems to me that if DNSSEC is actually working fine, I should be able
 to provide an authoritative public key for any domain name I control,
 and should be able to obtain such keys for other domain names, and
 use such keys for any purpose, not just those purposes envisaged in
 the DNSSEC specification.  Can I?  It is not apparent to me that I
 can.
 
You might want to look at RFC 3445 and draft-iab-dns-choices-05.txt.

As for DNSSEC keys -- DNSSEC is for securing the DNS.  Once you've done
that, you can put other records in the DNS, but there are some subtle
points in DNS RR design that should be heeded.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-27 Thread Ben Laurie

Dave Howe wrote:

James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on 
examining the matter I find it is working fine except that 


DNSSEC is working fine as a technology. However, it is worth 
remembering that it works based on digitally signing an entire zone - 
the state of the world being what it is, most people prohibit xfer so 
any other technology that would allow a zonewalk is not going to be 
deployed.


as far as I can tell, this is a basic design flaw, so isn't going to be 
rectified anytime soon.


RFC 5155 rectifies this design flaw.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread Florian Weimer
* James A. Donald:

 From time to time I hear that DNSSEC is working fine, and on examining
 the matter I find it is working fine except that 

 Seems to me that if DNSSEC is actually working fine, I should be able
 to provide an authoritative public key for any domain name I control,
 and should be able to obtain such keys for other domain names, and use
 such keys for any purpose, not just those purposes envisaged in the
 DNSSEC specification.  Can I?  It is not apparent to me that I can.

DNS is hierarchical.  Nobody wants the DoD (who are traditionally quite
good at keeping secret data) or any other institution to keep keys at
important positions in the hierarchy.  And nobody wants to be the keep
irreplaceable keys, either, which makes introduction at levels below the
DNS root difficult.

This is not a problem with the browser PKI because it's possible to
replace root certificates with a software update (which can be automated
in many cases).

And as Bill pointed out, it's not possible to use the DNS keys directly.
However, you can bootstrap another key based on data from DNS.  This
even works without DNSSEC.  DKIM does that, for instance.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread Ben Laurie

James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
the matter I find it is working fine except that 


Seems to me that if DNSSEC is actually working fine, I should be able to 
provide an authoritative public key for any domain name I control, and 
should be able to obtain such keys for other domain names, and use such 
keys for any purpose, not just those purposes envisaged in the DNSSEC 
specification.  Can I?  It is not apparent to me that I can.


There are two major issues with DNSSEC right now. Neither of them is 
that it isn't working.


Firstly, the root is not signed. This means there's no easy way for the 
relying party to establish the correctness of the key on your domain.


Secondly, although we have DNS servers and resolvers, software that uses 
DNS is largely unaware of DNSSEC and so has absolutely no idea what to 
do when one of the many possible cryptographic/proof failures occurs. 
Very little thought has gone into what should be done, even in software 
that is aware.


That said, if you want to distribute keys with DNSSEC, then RFC 4398 
standardises ways to do a number of them, and can be extended to cover 
more. RFC 4255 gives you SSH host keys, too.


If you want to do something ad hoc, then there are always TXT records, 
though I guarantee this will make the DNS people hate you forever.


Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread Ben Laurie

[EMAIL PROTECTED] wrote:

On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote:
From time to time I hear that DNSSEC is working fine, and on examining 
the matter I find it is working fine except that 


Seems to me that if DNSSEC is actually working fine, I should be able to 
provide an authoritative public key for any domain name I control, and 
should be able to obtain such keys for other domain names, and use such 
keys for any purpose, not just those purposes envisaged in the DNSSEC 
specification.  Can I?  It is not apparent to me that I can.



	actually, the DNSSEC specification -used- to support 
	keys for any purpose, and in theory you could use

DNSSEC keys in that manner.  However a bit of careful
thought suggests that there is potential  disconnect btwn
	the zone owner/admin who creates/distributes the keys as 
	a token of the integrity and authenticity of the data in

the DNS, and the owner/admin of the node to which the DNS
data points.


So far, so good. This disconnect doesn't seem to have done the CA 
industry any harm, though.



  Remember that while you may control your forward
name (and not many people actually run their own DNS servers)
it is less likely that you run your address maps - and for
	the paranoid, you would want to ensure the forward and 
	reverse zones are signed and at the intersection, there is

a common data element which you can use.


Non sequiteur, plus I can't see why paranoia would prompt me to want to 
do this? What does it prove?


Also, PTR records are only supposed to point to primary domain names. 
Since it is common for hosts to have many names resolving to the same IP 
address, by definition most of these will not correspond to the reverse 
lookup.



To do what you want, want, you might consider using the
CERT-rr, using the DNS to distribute host-specific keys/certs.
And to ensure that the data in the DNS was not tampered with,
using DNSSEC signed zones with CERT-rr's would not be a bad
thing.   In fact, thats what we are testing .


Who is we and what exactly are you testing?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread bmanning
On Sat, Mar 22, 2008 at 10:59:18AM +, Ben Laurie wrote:
 [EMAIL PROTECTED] wrote:
 On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
 the matter I find it is working fine except that 
 
 Seems to me that if DNSSEC is actually working fine, I should be able to 
 provide an authoritative public key for any domain name I control, and 
 should be able to obtain such keys for other domain names, and use such 
 keys for any purpose, not just those purposes envisaged in the DNSSEC 
 specification.  Can I?  It is not apparent to me that I can.
 
 
  actually, the DNSSEC specification -used- to support 
  keys for any purpose, and in theory you could use
  DNSSEC keys in that manner.  However a bit of careful
  thought suggests that there is potential  disconnect btwn
  the zone owner/admin who creates/distributes the keys as 
  a token of the integrity and authenticity of the data in
  the DNS, and the owner/admin of the node to which the DNS
  data points.
 
 So far, so good. This disconnect doesn't seem to have done the CA 
 industry any harm, though.

The CA business -is- to serve as a notary They attest to
the binding o fthe key to holder.  To date, thats NOT what
a zone admin does, he is attesting that its HIS key, that it
is HIS record in HIS database.  Just because he has sold the
right to use to someone else, is still his database and his data.

Unless of course Nominet (for example) is now going to allow 
client driven dynamic updates - where the clients are in complete 
control of their data.  (thats closer to James, assertion that he 
owns/controls his domain name)

 
   Remember that while you may control your forward
  name (and not many people actually run their own DNS servers)
  it is less likely that you run your address maps - and for
  the paranoid, you would want to ensure the forward and 
  reverse zones are signed and at the intersection, there is
  a common data element which you can use.
 
 Non sequiteur, plus I can't see why paranoia would prompt me to want to 
 do this? What does it prove?

The argument is, again, to James asserton that he owns his domain 
name.  In point of fact, every node has at least two names
in the DNS, the forward (which gets most of the attention) and the
reverse - which is nearly always controled by your ISP.

DNSSEC validation along one path in the DNS graph is reassuring
(or so it is claimed).  I posit that validation over two, generally
non-overlapping administrative spheres of influence, in the DNS
graph would give a higher level of assurance. Couple this with
finding the identical x509 cert at the origin of the validation
chain for both paths - and I think I have a much higher confidence
that I am actually going to be sending packets to the right
node.


 Also, PTR records are only supposed to point to primary domain names. 
 Since it is common for hosts to have many names resolving to the same IP 
 address, by definition most of these will not correspond to the reverse 
 lookup.

Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names.  Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a single
name - is and has been spread widely.

  To do what you want, want, you might consider using the
  CERT-rr, using the DNS to distribute host-specific keys/certs.
  And to ensure that the data in the DNS was not tampered with,
  using DNSSEC signed zones with CERT-rr's would not be a bad
  thing.   In fact, thats what we are testing .
 
 Who is we and what exactly are you testing?

We is USMIR, the registry for .UM  -  www.nic.um

--bill

 
 Cheers,
 
 Ben.
 
 -- 
 http://www.apache-ssl.org/ben.html   http://www.links.org/
 
 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [mm] How is DNSSEC

2008-03-26 Thread Ben Laurie

[EMAIL PROTECTED] wrote:

Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names.  Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a single
name - is and has been spread widely.


You can disbelieve my assertion if you wish, but I am only quoting the 
RFC. RFC 1035, to be precise:


Address nodes are used to hold pointers to primary host names
in the normal domain space.

(section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [mm] How is DNSSEC

2008-03-26 Thread bmanning
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:
 [EMAIL PROTECTED] wrote:
  Er... Allow me the option o fdisbeleiving your assertion.
  PTR records can and do point to mutiple names.  Some narrow
  implementations have assumed that there will only be a single
  data element and this myth - that PTRs only point to a single
  name - is and has been spread widely.
 
 You can disbelieve my assertion if you wish, but I am only quoting the 
 RFC. RFC 1035, to be precise:
 
 Address nodes are used to hold pointers to primary host names
 in the normal domain space.
 
 (section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture.


ah... open to interpretation.  what is a primary host name?

--bill

 
 -- 
 http://www.apache-ssl.org/ben.html   http://www.links.org/
 
 There is no limit to what a man can do or how far he can go if he
 doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [mm] How is DNSSEC

2008-03-26 Thread Ben Laurie

[EMAIL PROTECTED] wrote:

On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:

Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names.  Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a single
name - is and has been spread widely.
You can disbelieve my assertion if you wish, but I am only quoting the 
RFC. RFC 1035, to be precise:


Address nodes are used to hold pointers to primary host names
in the normal domain space.

(section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture.



ah... open to interpretation.  what is a primary host name?


RFC 1035 does not say, in the case of hosts, but the intent is quite 
clear from the text on gateways:


Gateways will often have two names in separate domains, only one of 
which can be primary.


--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: [mm] How is DNSSEC

2008-03-26 Thread Ben Laurie

[EMAIL PROTECTED] wrote:

On Sat, Mar 22, 2008 at 03:52:49PM +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:

On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote:

[EMAIL PROTECTED] wrote:

Er... Allow me the option o fdisbeleiving your assertion.
PTR records can and do point to mutiple names.  Some narrow
implementations have assumed that there will only be a single
data element and this myth - that PTRs only point to a single
name - is and has been spread widely.
You can disbelieve my assertion if you wish, but I am only quoting the 
RFC. RFC 1035, to be precise:


Address nodes are used to hold pointers to primary host names
in the normal domain space.

(section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture.


ah... open to interpretation.  what is a primary host name?
RFC 1035 does not say, in the case of hosts, but the intent is quite 
clear from the text on gateways:


Gateways will often have two names in separate domains, only one of 
which can be primary.



the intent for gateways...  hosts w/ multiple IP's (VMware etc)
are not gateways.  comparing oranges w/ dragonfruits.


If you insist on language lawyering, I can play.

I'd say it is clear from:

a) The lack of a repeated PTR record for a host IP in the example,

b) The use of the word 'primary',

c) The fact that the authors felt it necessary to explain what they saw 
as an exceptional case, i.e. that a gateway could have two names


that in the case of hosts, the authors expected there to only be a 
single PTR record for reverse lookup.


Of course, we have the power to change RFCs. But there's a process for that.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-26 Thread Dave Howe

James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
the matter I find it is working fine except that 


DNSSEC is working fine as a technology. However, it is worth 
remembering that it works based on digitally signing an entire zone - 
the state of the world being what it is, most people prohibit xfer so 
any other technology that would allow a zonewalk is not going to be 
deployed.


as far as I can tell, this is a basic design flaw, so isn't going to be 
rectified anytime soon.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


How is DNSSEC

2008-03-21 Thread James A. Donald
From time to time I hear that DNSSEC is working fine, and on examining 
the matter I find it is working fine except that 


Seems to me that if DNSSEC is actually working fine, I should be able to 
provide an authoritative public key for any domain name I control, and 
should be able to obtain such keys for other domain names, and use such 
keys for any purpose, not just those purposes envisaged in the DNSSEC 
specification.  Can I?  It is not apparent to me that I can.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: How is DNSSEC

2008-03-21 Thread bmanning
On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote:
 From time to time I hear that DNSSEC is working fine, and on examining 
 the matter I find it is working fine except that 
 
 Seems to me that if DNSSEC is actually working fine, I should be able to 
 provide an authoritative public key for any domain name I control, and 
 should be able to obtain such keys for other domain names, and use such 
 keys for any purpose, not just those purposes envisaged in the DNSSEC 
 specification.  Can I?  It is not apparent to me that I can.


actually, the DNSSEC specification -used- to support 
keys for any purpose, and in theory you could use
DNSSEC keys in that manner.  However a bit of careful
thought suggests that there is potential  disconnect btwn
the zone owner/admin who creates/distributes the keys as 
a token of the integrity and authenticity of the data in
the DNS, and the owner/admin of the node to which the DNS
data points.  Remember that while you may control your forward
name (and not many people actually run their own DNS servers)
it is less likely that you run your address maps - and for
the paranoid, you would want to ensure the forward and 
reverse zones are signed and at the intersection, there is
a common data element which you can use.

To do what you want, want, you might consider using the
CERT-rr, using the DNS to distribute host-specific keys/certs.
And to ensure that the data in the DNS was not tampered with,
using DNSSEC signed zones with CERT-rr's would not be a bad
thing.   In fact, thats what we are testing .

 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]