Subject: [ietf-tls] Suggested Finished Message Processing Improvement

From: [email-masked]
Date: Fri, 22 Dec 2000 12:14:42 -0500

At the San Diego IETF meeting, Win Treese indicated that if anyone wanted to
suggest minor changes to the TLS protocol, now was our last chance to submit
them before it would advance to a Draft Standard.

I am not sure if this is what Win intended or if it was ever discussed on
this mailing list before, but here is a suggested change for the "finished
message" to improve its processing, especially on the server side.

As you know, Section 7.4.9 of RFC2246 mandates that the handshake_messages
for the finished message must include the concatenation of all the data from
all messages up to but not including this message.  From all the messages in
the handshake_messages, the optional server certificate message, which is a
static message from the server, is always the largest of the handshake
protocol.  We would like to suggest that for the server certificate message,
instead of using the whole certificate message in the handshake_messages, it
would be more efficient to only include the appropriate hash of the
certificate message (e.g. MD5 and SHA-1).  These two hashes of the server
certificate message could always be pre-compute by a server and easily be
computed by clients for the optional client certificate verify message and
the client own finished message.

The benefit of this approach is the fact that a server could cache these two
hashes of its server certificate message. Then for each session with a
client, a server would only need to compute the two hashes needed for the
verify_data from all the other shorter messages with the appropriate hash of
its server certificate message.

The finished message could then look like this:

   struct {
       opaque verify_data[12];
   } Finished;

   verify_data
       PRF(master_secret, finished_label, MD5([[MD5(certificate)]] +
       handshake_messages) + SHA-1([[SHA-1(certificate)]] +
       handshake_messages)) [0..11];

   finished_label
       For Finished messages sent by the client, the string "client
       finished". For Finished messages sent by the server, the
       string "server finished".

   handshake_messages
       All of the data from all handshake messages up to but not
       including this message and the optional server certificate
       message. This is only data visible at the handshake layer and
       does not include record layer headers. This is the
       concatenation of all the Handshake structures as defined in
       7.4 exchanged thus far.

   certificate
       The optional server certificate message.

   It is a fatal error if a finished message is not preceded by a change
   cipher spec message at the appropriate point in the handshake.

   The hash contained in finished messages sent by the server
   incorporate Sender.server; those sent by the client incorporate
   Sender.client. The value handshake_messages includes all handshake
   messages starting at client hello up to, but not including, this
   finished message and the server certificate message. This may be
   different from handshake_messages in Section 7.4.8 because it would
   include the certificate verify message (if sent). Also, the
   handshake_messages for the finished message sent by the client will
   be different from that for the finished message sent by the server,
   because the one which is sent second will include the prior one.

Note that as indicated above, the client certificate verify message under
Section 7.4.8 would similarly be impacted by this suggested change since it
also uses the handshake_messages.  The syntax of md5_hash and sha_hash could
then become:

   CertificateVerify.signature.md5_hash
       MD5([[MD5(certificate)]] + handshake_messages);

   Certificate.signature.sha_hash
       SHA([[SHA-1(certificate)]] + handshake_messages); 

   certificate
       The optional server certificate message.

   handshake_messages
       All handshake messages sent or received starting at client
       hello up to but not including this message and the server
       certificate message, including the type and length fields of
       the handshake messages. This is the concatenation of all the
       Handshake structures as defined in 7.4 exchanged thus far.

Finally, the client and server finished messages when a client and server
resume a previous session would not be impacted.

What do others thing of this suggested change?

Merry Xmas and Happy New Year,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 22 Dec 2000 10:30:35 -0800

> What do others thing of this suggested change?
While one might argue that this would be an improvement, it would
completely break existing implementations and would therefore
require changing the version number and quite possible
recycling to Proposed. Doesn't seem worth it to me.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

---

From: "Baber Amin" <[email-masked]>
Date: Fri, 22 Dec 2000 12:02:44 -0700

I agree, it will break existing implementation and add extra code paths, which as we all know always adds bugs :)

Baber Amin

>>> [email-masked] 12/22/00 11:30AM >>>

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked] 
To unsubscribe send a blank email to [email-masked]

---

---

From: Paul Koning <[email-masked]>
Date: Fri, 22 Dec 2000 14:03:05 -0500 (Eastern Standard Time)

I tend to agree with Eric that this is probably not a good time to
make incompatible protocol changes.  

At the risk of being told to go back to the archives, I'll add another
comment...  there seems to be a fair amount of opportunity for
removing computational complexity from the protocol.  Right now it is
very heavily biased to throwing lots of cryptographic functions into
the mix to be very sure that there aren't weaknesses.  Other protocols
(e.g., IKE) are much more minimalist, for example they never hash the
same stuff with two hash algorithms.

Rather than tweak a single bottleneck now, how about revisiting things
more globally for TLS V2.0?

     paul

---