Re: Security

An extra round is not necessarily required. Each request could carry an
associated list of preferred ciphers. The information propogation would be
slow, and the first would be unprotected, but following that the most
preffered shared cipher would be used. Alternately a mandatory for
encryption call could be supplied, that call returns the list of ciphers and
certificates. So there are ways to provide the negotiation without the
explicit negotiation that has become the de facto standard. In even a
company the size of the universe of IP addresses, having a 4 GByte hard disk
would be enough to identify which systems used which of 255 ciphers (the
last being reserved for unnegotiated), so it's not overly expensive to store
the information. For smaller distributed setups a sparse fle would work
nicely.
                            Joe

----- Original Message -----
From: "Rich Salz" <rsalz@zolera.com>
To: "Joseph Ashwood" <jashwood@arcot.com>
Cc: "Clemens F. Vasters" <clemensv@newtelligence.com>; <xml-dist-app@w3.org>
Sent: Thursday, March 15, 2001 5:50 PM
Subject: Re: Security


> > there is no way to negotiate a suite of ciphers
> > to be used (when possible)
>
> Don't you need at least an offer/accept phase of negotation, implying at
> least one extra round-trip? XP hasn't even decided if request/response
> is fundamental, so doing RPC-style security negotiations seems a bit
> premature.  I also disagree with the assertion in your previous note
> that said there is no encryption for RPC.  I'd point to the DCE RPC
> protocol (see DCOM and its security blankets if you prefer), SSL/TLS,
> and NFS RPC.
> /r$
>

Received on Friday, 16 March 2001 15:46:02 UTC