CurveCP/djb-mailについて、ここに記述してください。
Date: 18 May 2011 23:58:36 -0000 Message-ID: <20110518235836.19776.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" <djb@cr.yp.to> To: curvecp@list.cr.yp.to Subject: Re: curveprotect References: <201105120932.20594.jan@mojzis.com>
Jan Mojžíš writes:
> How to install and setup it, is described here:
> http://mojzis.com/software/curveprotect/
Wow, this is quite a package!
I guess I should comment in more detail on the interaction between
DNSCurve keys and CurveCP keys in DNS. I see three important situations
to cover:
* The sysadmin is installing one CurveCP forwarder with one key to
handle HTTPCurve, SMTPCurve, etc. Presumably the sysadmin also
wants to protect DNS and is installing DNSCurve software, but this
generally won't have the same key.
* The sysadmin has a DNSCurve server "ns" (like ns1.yahoo.com) with
its own key, an SMTPCurve server "mx" (like mx.sourceforge.net)
with its own key, an FTPCurve server "ftp" (like ftp.kernel.org)
with its own key, etc.
* The sysadmin has different keys for different services but has all
the services under the same name: e.g., kernel.org supports both
FTP and HTTP. In this case it's important for an FTPCurve client to
see the sysadmin's FTPCurve key and for an HTTPCurve client to see
the sysadmin's HTTPCurve key.
The easiest way to get keys through DNS to (e.g.) an FTPCurve client is
to put the keys into CNAME records: if there's an alias
ftp.kernel.org CNAME 8675309.kernel.org
8675309.kernel.org A 199.6.1.165
then the FTPCurve client will naturally see 8675309 and check whether
8675309 is an FTPCurve public key. If the FTPCurve client looks up X and
sees
X CNAME Y
Y CNAME Z
Z A 1.2.3.4
then it checks the names X, Y, Z (in that order) for FTPCurve public
keys. DNS doesn't allow CNAME records for names with NS records (such as
kernel.org), so the FTPCurve client also has to watch for NS records and
check for FTPCurve public keys there; if it sees
X A 1.2.3.4
X NS Y
then it checks X and Y for FTPCurve public keys. Note that in both cases
the client checks X first---X can be a "nym" with a public key.
For SMTP clients there's already an extra step of checking for an MX
record. If an SMTPCurve client sees
X MX Y
Y CNAME Z (prohibited by RFCs but supported by MTAs)
Z A 1.2.3.4
then it checks X, Y, and Z for SMTPCurve public keys. If the client sees
no MX but instead
X CNAME Y
Y CNAME Z
Z A 1.2.3.4
then it checks X, Y, and Z for SMTPCurve public keys. If the client sees
no MX but instead
X A 1.2.3.4
X NS Y
then it checks X and Y for SMTPCurve public keys. These no-MX cases
might seem unnecessary (is it so hard for the sysadmin to add an MX?)
but covering those cases will simplify typical implementations.
How does a client check for a key inside a name? It's tempting to limit
variability by requiring keys to appear as the first components of
names, but this would mean getting into fights with other protocols that
succumbed to analogous temptations; so clients check all components,
from left to right. Any CurveCP client needs three pieces of data:
* The CurveCP server public key (255 bits).
* The CurveCP extension address (128 bits).
* A protocol selector allowing the sysadmin to limit this key to
(e.g.) just HTTPCurve so that FTPCurve clients skip the key.
This is too much information to safely pack into one DNS component, so
it has to be split into two successive components. It's tempting to put
the key into one component, using the DNSCurve key encoding---but this
means that CurveCP keys in NS records will be seen by DNSCurve clients.
This works if the sysadmin is installing a grand unified forwarder for
DNSCurve and CurveCP, but it doesn't work in other situations. Much
safer is the following encoding:
* First component: The public key, encoded similarly to DNSCurve but
with uz7 instead of uz5.
* Second component: The extension address, encoded straightforwardly
as 32 hex bytes, optionally followed by a slash and some of the
following: h for HTTP (on UDP port 80), s for SMTP (on UDP port
25). More can be added later, of course; each client simply has to
know its own letter. (FTP is a mess, so specifying FTPCurve would
actually take much more work, and the value would be questionable.)
What does this mean for, e.g., kernel.org? Setting up something like
kernel.org A 149.20.20.133
kernel.org NS ns1.uz5123.kernel.org
kernel.org NS ns2.uz5123.kernel.org
kernel.org NS ns3.uz5123.kernel.org
kernel.org NS uz7456.111/h.uz5123.kernel.org
ns1.uz5123.kernel.org A 149.20.20.144
ns2.uz5123.kernel.org A 149.20.4.80
ns3.uz5123.kernel.org A 199.6.1.176
uz7456.111/h.uz5123.kernel.org A 199.6.1.176
would announce DNSCurve key 123 (whichever NS record the DNSCurve client
chooses, it will find the uz5123) and HTTPCurve key 456 on extension
address 111 (the HTTPCurve client scans all the NS records). Of course,
the 456 and 123 are actually 51 bytes, and the 111 is actually 32 bytes,
but this still fits into a DNS name. Some registrars won't accept such
long NS names, but they can be given just the short ns1, ns2, ns3---the
DNS cache will pick up uz7456.111/h.uz5123.kernel.org from the child
server along with the kernel.org address.
The setup is much more straightforward for, e.g., www.kernel.org:
www.kernel.org CNAME uz7456.111.kernel.org
ns3.uz5123.kernel.org A 199.6.1.176
uz7456.111/h.uz5123.kernel.org A 199.6.1.176
would announce DNSCurve key 123 (whichever NS record the DNSCurve client
chooses, it will find the uz5123) and HTTPCurve key 456 on extension
address 111 (the HTTPCurve client scans all the NS records). Of course,
the 456 and 123 are actually 51 bytes, and the 111 is actually 32 bytes,
but this still fits into a DNS name. Some registrars won't accept such
long NS names, but they can be given just the short ns1, ns2, ns3---the
DNS cache will pick up uz7456.111/h.uz5123.kernel.org from the child
server along with the kernel.org address.
The setup is much more straightforward for, e.g., www.kernel.org:
www.kernel.org CNAME uz7456.111.kernel.org
uz7456.111.kernel.org A 199.6.1.165
This is independent of DNSCurve; it simply advertises CurveCP for all
services on www.kernel.org.
---D. J. Bernstein
Research Professor, Computer Science, University of Illinois at Chicago-- ToshinoriMaeno 2011-05-19 03:35:01