[109452] in cryptography@c2.net mail archive
Re: refactoring crypto handshakes (SSL in 3 easy steps)
daemon@ATHENA.MIT.EDU (travis+ml-cryptography@subspacefie)
Fri Nov 30 10:20:41 2007
Date: Thu, 29 Nov 2007 12:34:19 -0600
From: travis+ml-cryptography@subspacefield.org
To: Pasi.Eronen@nokia.com
Cc: cryptography@metzdowd.com
Mail-Followup-To: Pasi.Eronen@nokia.com, cryptography@metzdowd.com
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2404DEB501@esebe105.NOE.Nokia.com>
--nYySOmuH/HDX6pKp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 15, 2007 at 10:28:43AM +0200, Pasi.Eronen@nokia.com 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=20
> used by the client, or even what certificate is selected,
> depends on these "non-crypto" capability/feature parts.)
>=20
> But as James pointed out, you could probably handle this=20
> 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.
--=20
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 john@subspacefield.org.
--nYySOmuH/HDX6pKp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (OpenBSD)
iQIVAwUBR08GK2QVZZEDJt9HAQII1RAAmqEBSXMHNwXJxfF9uKL650xZqIRwajB+
OoNY/p+lyI/fSjD6gBdiByLVkkjANlR2ctu13j9S6Gp8JlqpvKnbHZvU0RgM+yDS
VWMKw5l2uqA4YIVihSHmzmkQH0vFrJzPJ/ejHDZLPuWzkrZJcr7GohLg1HyQUvsS
M93/NGRf7v57dvbPFm2zVVy4WAI/PgkGXiy4rXkHM4OguQM8rTQVJJnbj38HU0nd
W7oPNos1h9HdAAJCcK+M4cDMhrNTsoifE7xo717f/x464mmd0ysmi/7Mx9suyw8h
T/yj4PvBKdFbid2bhtmvwe/pTT/6TePbpxGGwTg02+phRtxZ1+T4kLgz8pgeuu8N
soS1TMrm1p7jChAwJDZ3LN0tcvzCOFmdamfZl4wPw9cG7mMPTlBP2gepphkFZg4b
jn1nuYrtlyEmUnr/lKHHRpnQz24w7jbJkIaS9gfvHuolsSVfHIfHqT2yr5FmJ/ri
+f553Zgd3ruqNZSES5QvO7+rJxw679sOb16MqjvuT+Ul/gGAkulwqaR7aJ5aqpJK
6tYEiqDUuxbONY2qTaEa7w3FTNpxcAGZwYQfBQ5sHaVTelqDv+qZnRkeJv1Nkbcx
N8p8VAceUELNGflTsLh7DyQLQq/mXMFwmEMzGJEtKh/OI02DEw2LMmHOUh2fgIzr
a0+3Tty+CKE=
=Hm9M
-----END PGP SIGNATURE-----
--nYySOmuH/HDX6pKp--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
