On Thu, Nov 15, 2007 at 10:28:43AM +0200, [EMAIL PROTECTED] wrote:
There's a dependency from negotiated capabililities
to the cryptographic things included in the first message
from client to server (since e.g. what algorithm is
used by the client, or even what certificate is selected,
depends on these non-crypto capability/feature parts.)
But as James pointed out, you could probably handle this
in optimistic mode; i.e. make a guess what the negotiated
capabilities are likely to be, and fall back to more
RTTs if the guess is wrong.
One could theoretically send all of the permutations prior to
negotiation. However, there would be a bandwidth penalty, a privacy
penalty (any listener knows all cryptographic identities), and a
possible security penalty (if any of the supported methods are
undesirably weak).
However, if you only have strong ciphers and don't care about
cryptographic identity protection, it could be useful.
Note that all these weaknesses already exist, as they could be
triggered by communicating with a less-capable client, or one
controlled by an adversary. Whether or not it matters depends on some
contextual details.
(BTW, usually we also want the capability negotiation
to be secure; SSL simply exchanges MACs of all messages
once the key for MAC has been agreed on. Would this
add 0.5 or 1RTT? Or perhaps there's some clever
way to do it without additional RTT?)
Schneier suggests keeping a running MAC over the entire datastream,
the state of which is sent with each logical message. I think that's
a simple and safe way to do it, and so there's no extra messages
involved. You always check the MAC first, before operating on the
data, and you abort whenever you receive one with a message with an
invalid MAC. The MAC with each message attests to the integrity of
all data ever sent over that connection, period.
The obvious way - doing a specific step just to verify the handshake -
is the kind of code-centric thinking that I'm trying to avoid. I'm
having trouble finding the right words for it. Basically an encrypted
network protocol is a language in which a transmission is
syntactically correct if and only if all the security properties hold.
In some ways current protocols are like a poorly-written language
whose parser that needs a seperator character between statements
instead of being able to detect the syntax error when it starts
processing the following statement. Basically it lacks even a single
symbol look-ahead.
--
Life would be so much easier if it was open-source.
URL:https://www.subspacefield.org/~travis/ Eff the ineffable!
For a good time on my UBE blacklist, email [EMAIL PROTECTED]
pgpjHn1QEV8i0.pgp
Description: PGP signature
