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.
> 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]
