Subject: Re: Online signing

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Jun 2004 12:19:57 +0200

In your previous mail you wrote:

   Sun commercial grade crypto accelerator 1000 board, part number x6762a,
   currently costs around 2K euro (1339 GBP). A single board is capable
   around 4300 ops/sec for 1024-bit RSA.
   
=> you can buy it for lower price at Broadcom or at some integrators:
http://www.broadcom.com/products/product.php?product_id=CryptoNetX+SSL4000
http://www.interfacemasters.com/products/nic/niagara2100pc-5/index.html

BTW I have two CryptoNetX IPS200A in DELL small servers so if someone
has a benchmark proposal...

Regards

[email-masked]

PS: IMHO 64-bit CPUs are a more efficient way. The only very fine thing
you can get only with crypto boards is not-ridiculous bandwith random
number generators, i.e., no more hard choice between bad quality or
very low bandwith (/dev/urandom or /dev/random).

--
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: Fri, 11 Jun 2004 19:19:13 +0100

--On 11 June 2004 17:53 +0000 Paul Vixie <[email-masked]> wrote:

> yes.  but saying "deploying -bis with nsec synthesis would cause me to
> buy more hardware than i want given my anycast configuration" is not,
> in and of itself, an argument not to forward -bis.  it is in fact a
> tacit approval since it makes the case that under known and reachable,
> though undesirable, circumstances, someone could deploy -bis without
> waiting for -ter.  that's even better than "i can't deploy until -ter
> but i agree that there's a reasonable way of getting to -ter from -bis"
> which is mostly what the -trans (and -ter) authors are hoping for.

For the avoidance of doubt, my argument was not (given w/g consensus etc.)
that -bis should not be forwarded to IESG; my argument was that (a) -trans
should be fixed to show the "wait for -ter" option (as -trans considers
interim options), lest anyone get the impression that online synthesis was
such a no-brainer that "don't deploy until -ter" shouldn't be considered,
and (b) that the cons of synthesis should be fully documented. Neither
synthesis nor "don't deploy until -ter" require of themselves any change to
-bis, so if anything it's an argument *to* forward to the IESG.

Re your point on funding, my current view is I would far rather put funding
up to fix the issue properly (see Ben's work on NSEC2 & BIND), in terms of
protocol development, proof of concept, or getting production code cut,
than put funding up for synthesis; but I am listening to argument. This is
what I meant by the "distraction" argument.

Alex

---

From: [email-masked] (Geoffrey Sisson)
Date: Sat, 12 Jun 2004 00:00:00 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> > ..., I'm leaning towards the vastly cheaper and safer option of having
> > a single (or two) NSEC record(s) that can be used for all denials as the
> > interim measure of choice.
> 
> this will open you up to replay attacks.  anyone who receives one of these
> NSECs, signed by you and clearly covering a large range of existing names,
> would be able to use it along with queryid-guessing to make someone believe
> an existing domain name does not exist.

True . . . but NSEC RR replay attacks may be deeply less interesting
than other DNS m{an,onkey}-in-the-middle attacks.  So, many of the
benefits of DNSSECbis could be realised (including operational
experience) without the increased exposure of private keys which
dynamic NSEC synthesis would entail.  Of course this would be a -trans
mechanism only; authenticated denial-of-existence is ultimately an
important objective of DNSSEC.

Regards

Geoff