[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call for SKIP I-D
> From: ashar@osmosys.incog.com (Ashar Aziz)
> Therefore, at this point in time, I don't have any editorial
> action to take, based on your comments. Of course, if there
> is clarifying text that you would like to suggest that may
> help remove some of the misunderstandings that prompted your
> messages, I will gladly add such text, provided you supply
> me this text.
>
For some odd reason, I awoke this morning with the following text in
mind. Perhaps it was because I spent the holiday with my family, which
enjoys ironic humor. Perhaps it was the private email which thanked me
for providing comic relief in regard to my previous SKIP postings.
Anyway, I am sure that you will "gladly" add the following to SKIP.
Note that I even quoted a portion of your email message:
4.x Master Key Distribution
One of the significant features that keeps SKIP "simple" is the required
use of SneakerNet to distribute master keys, rather than wastefully
passing messages over the InterNet. For each participating node, and
each possible future communicating party, the operator is required to
hand-configure 1024-bit or 2048-bit D-H public-values. At least one
additional party -- the administrator -- is also required to be
hand-configured (see section 1.8.3).
In addition, a separate signature is hand-configured for each D-H
public-value. As noted earlier in section 1.1, the format of the
signature is unconstrained.
Howver, X.509 certificates MUST be supported (see section 4.2). These
may be considerably larger than the D-H public-value itself.
An alternate signature mechanism, described in section 4.1, employs
smaller MD5 128-bit hash signatures. Support for this shortened form is
merely optional, when using the optional certificate discovery protocol
described in section 4.3, and beyond the scope of this section.
Nota Bene:
Experience shows that hand-configuration of long strings of random
digits is often frought with difficulty, and the operators cannot
dependably verify their own work. The authenticated signatures will
help find these problems.
For those circumstances where a large number of parties might
communicate (such as between clients and servers, or among hosts and
routers), the implementation MUST support very large configuration
files.
Millions of nodes simply means a million or so master keys.
If we assume 16 bytes per pre-computed master key, this comes to 16
MegaBytes of storage. Even on very low-end machines, 16MB is a small
amount of storage, since 0.5 to 1 GigaByte disks are pretty normal
storage amounts these days.
Assuming 1024-bit master keys with 2048-bit X.509 certificates are
hand-configured in ASCII hex notation, this comes to only 3 GB for
the configuration files.
Assuming 16 MB spare on a 3 GB disk on a node capable of
communicating with a million other nodes in its lifetime is not
excessive. The only change is that routers and other terminals will
now be required to have hard disks.
Also, the master key public-values and signatures may change from
time to time. The hand-configured public-values and Certificate
Revocation Lists SHOULD NOT change more than once per 6 months.
Based on current InterNet growth rates, estimated maintainance
staffing should be no more than 4,096 clerks and operators (and
1,024 administrators and management) for each server or router.
Think of it as "full employment".
4.3 Certificate Discovery Protocol
An optional protocol is described to enable communicating IP-nodes to
discover each other's certificate(s). This obviates the need for an
on-line certificate directory server.
Nota Bene:
Since this feature is optional, it cannot be depended upon for master
key exchange between parties. However, in order to provide
"zero-message" operation and support unidirectional links, there is
no error message defined when this feature is not present. The
message merely disappears into a black-hole.
Therefore, whenever communication unexplicably stops, the operator is
recommended to use alternate means (such as the telephone) to
communicate with the peer operator for exchange of the public-value
and signature.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2