The extra messages might be irrelevant for cryptography,
but they're not irrelevant for security or functionality.
E.g. in SSL, you have capability/feature negotiation
(cipher suites, trusted CAs, in TLS 1.2 also signature
algorithms, etc.) which IMHO *is* important for
security (if you consider the security implications of
deploying this over tens of years and hundreds of
millions of hosts).
(But yes, there are variations of SSL where a smaller
number of RTTs might have been sufficient..)
Best regards,
Pasi
-Original Message-
From: travis+ml-cryptography
Sent: 08 November, 2007 21:50
To: Cryptography
Subject: refactoring crypto handshakes (SSL in 3 easy steps)
ASSUMPTIONS:
Network latency is important, and will only become more so, since
light won't go faster in a given medium, and we can't do better than
c, ever.
PROPOSED SOLUTION:
Refactor protocol to minimize number of interlocked steps.
Specifically, reduce the number of messages.
METHODOLOGY:
Identify data which must be transmitted, and identify their
dependencies. Send data on first outbound message to peer after all
its dependencies are available (i.e. on the step after it is
received). Each transmission is a sweep of one level of the
dependency tree, starting at the root and working downward.
PREVIOUS WORK:
Three messages is the proven minimum for mutual authentication. Last
two messages all depend on the previous message, so minimum handshake
time is 1.5 RTTs.
EXAMPLE:
First examine SSL with Mutual Auth, which is detailed here:
http://en.wikipedia.org/wiki/Image:Ssl_handshake_with_two_way_
authentication_with_certificates.png
Here is a refactored version of the important messages:
C-S: hello, RNc, client cert, enc_S(client_cert)
S-C: server cert
C-S: enc_S(PMS)
DISCUSSION:
Providing the datum as soon as its dependencies are satisfied is
well-studied in processor design.
One may have extra messages, but they are implementation artifacts,
completely irrelevant to the cryptography.
Network protocol libraries advance through time monotonically and thus
are analogous to LR(1) language parsers which parse from left to right
and are only able to look at the next token (message); perhaps we can
apply what we already know about them to create unambiguous crypto
handshakes with respectable error handling.
Sending one layer of the dependency tree at once is like a synchronous
circuit; one could also fire off messages as soon the data becomes
available, like an asynchronous circuit, which may reduce overall time
of the handshake due to computation by the endpoints. However, it is
an implementation detail, not important to this analysis.
OPEN QUESTIONS:
When would a handshake require more? Is there such a thing, in any
extant ZKS or PFS systems?
COMMENTS?
--
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]
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
