Subject: [Emu] Comment on 2716bis: Examples in Appendix B

From: <[email-masked]>
Date: Mon, 6 Nov 2006 23:42:03 +0200

First of all, I'd suggest numbering the examples in Appendix B, or
dividing Appendix B to subsections (this would make reading and
commenting them easier).

1) 2nd example ("In the case where the peer and server support privacy
and mutual authentication, the conversation will appear as follows"):
in 6th message, certificate_verify is not sent (as we're not sending a
cert either).

2) 2nd example: it looks like there's a "client_hello" missing in/around
messages 8/9 (the server can't just send server_hello without receiving
client_hello).

3) 2nd example: remove [] around change_cipher_spec (it's not
optional here).

4) 5th example ("In the case where server authentication is
unsuccessful,
the conversation will appear as follows"): client sends 
change_cipher_spec/finished twice?

5) 8th example ("In the case where a previously established session
is being resumed, and the server authentication is unsuccessful, the
conversation will appear as follows:")

I don't see how this message sequence could ever occur. If the client
is not happy with the server's cert anymore, it won't resume the
session.  If the master_secret is not the same, TLS finished message
can't be decrypted, so the conversation will end there. What other
possible reasons there are for the server authentication to be
"unsuccessful"?

(Roughly the same comment applies to the 7th example as well.)

Best regards,
Pasi

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 06 Nov 2006 16:34:37 -0800

>client sends change_cipher_spec/finished twice?

I think the client will send the Alert at that point, no?

>I don't see how this message sequence could ever occur.

It is possible for a session resume attempt to fail, but if so, it will not 
look like the example.  A client could mistakenly attempt a session resume 
with a commonly utilized SSID, but then typically the server will not have 
keying material for the Session-Id so that the session resume attempt will 
fail quickly.

>If the client is not happy with the server's cert anymore, it won't resume 
>the session.

Right.

>If the master_secret is not the same, TLS finished message
>can't be decrypted, so the conversation will end there.

Even getting there assumes that the server has state for the Session-Id 
proposed by the client.  Therefore the failure will typically occur earlier.

As far as I can see, examples 7 and 8 could just be deleted without losing 
anything.

---

From: <[email-masked]>
Date: Tue, 7 Nov 2006 02:45:06 +0200

> I think the client will send the Alert at that point, no?

TLS doesn't really specify when the alerts should be sent.  For
example, if the client doesn't accept the server's certificate, IMHO
the most logical sequence would be to reply with Alert immediately:

      ClientHello    -------->
                                        ServerHello
                                       Certificate*
                                 ServerKeyExchange*
                                CertificateRequest*
                     <--------      ServerHelloDone
      Alert          -------->

While the example in Appendix B completes the handshake, and
only then sends the Alert:

      ClientHello    -------->
                                        ServerHello
                                       Certificate*
                                 ServerKeyExchange*
                                CertificateRequest*
                     <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      ChangeCipherSpec
      Finished       -------->
                                   ChangeCipherSpec
                     <--------             Finished
      Alert          -------->

Do you have information about what existing implementations do?

> As far as I can see, examples 7 and 8 could just be deleted 
> without losing anything.

I agree.

Best regards,
Pasi

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 06 Nov 2006 17:00:01 -0800

Here is a strawman responding to Pasi's comments:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-05.txt

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: RE: [Emu] Comment on 2716bis: Examples in Appendix B
>Date: Mon, 06 Nov 2006 16:34:37 -0800
>