Subject: RE: [TLS] RFC 4507bis

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 31 Jul 2007 22:17:02 -0700

Hi Mike,

Thanks for reviewing the document, comments inline below: 

> -----Original Message-----
> From: Mike [mailto:[email-masked]] 
> Sent: Sunday, July 29, 2007 9:58 AM
> To: [email-masked]
> Subject: [TLS] RFC 4507bis
> 
> I'm working on adding support for RFC 4507 to my code and 
> have found a few issues with the draft.
> 
>    - Should the NewSessionTicket message be included
>      in the hash used to create/verify the Finished
>      message.  I believe it should since it's a
>      handshake message, but it's not stated anywhere.
>      I think it would be a good idea to specifically
>      state that it is.
> 
[Joe]It is part of the TLS hello message and is therefore included in
the finished message.  This is part of the TLS extensions spec.  I'm not
sure we need to clarify it here.

>    - Is it legal for the server to resume a session
>      and not provide a NewSessionTicket?  The message
>      flow I'm referring to would look like this:
> 
>      Client                                    Server
>      ClientHello
>      (SessionTicket extension) -->
>                                           ServerHello
>                          (no SessionTicket extension)
>                                    [ChangeCipherSpec]
>                                <--           Finished
>      [ChangeCipherSpec]
>      Finished                  -->
>      Application Data          <->   Application Data
> 
>      If this is not allowed, it should probably be
>      stated that when a server resumes a session using
>      a SessionTicket, it MUST send an empty Session
>      Ticket extension and a NewSessionTicket message
>      (optionally with an empty ticket).
> 
[Joe] It is legal to not provide a new session ticket if you do not
provide an empty session ticket extension from the server. However if
you include an empty session ticket extension from the server you must
provide a NewSessionTicket message (which may be empty).  Some other
reviewers have had similar comments, is there a place where the text
could be clearer?

>    - It may be useful to state that the MAC computation
>      in the ticket is over the encrypted contents to
>      be able to quickly reject a ticket and not have to
>      perform a decryption first.
> 
[Joe] This is a implementation detail that I'm not sure we need to go
into in the specification. 

>    - Should HMAC-SHA256 be recommended instead of
>      HMAC-SHA1?
> 
[Joe] I was under the impression that most people were OK with
HMAC-SHA-1 use for the foreseeable future.  If this is not the case we
can probably change it to HMAC-SHA-256.

>    - StatePlaintext needs more data fields when TLS
>      extensions are used such as max fragment length.
>      This should be obvious, but it wouldn't hurt to
>      state.
> 
> Mike
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tls
> 

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

---

From: Mike <[email-masked]>
Date: Wed, 01 Aug 2007 07:43:55 -0700

> sure we need to clarify it here.

I was referring to the NewSessionTicket message sent by
the server to the client just before ChangeCipherSpec.
I think you should state that it is included in the hash
used to create/verify the Finished messages.

> reviewers have had similar comments, is there a place where the text

The message flow diagram in the draft that shows session
resumption has the server send an empty SessionTicket
extension.  If the message flow above is also allowed
(where no SessionTicket extension is sent by the server),
then I think you should include the diagram in the spec.

> can probably change it to HMAC-SHA-256.

I will leave that up to the experts to decide, but will
use SHA-256 in my code in any case.

Mike

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 01 Aug 2007 17:45:01 +0100

> then I think you should include the diagram in the spec.

I agree that some clarification is needed in that case. I wasn't aware
of a special meaning for an empty ticket in a NewSessionTicket message
either so an explicit mention of that would be helpful.

One other area I'd like clarified is in 3.4:

>    When presenting a ticket, the client MAY generate and include a
>    Session ID in the TLS ClientHello.  If the server accepts the ticket
>    and the Session ID is not empty, then it MUST respond with the same
>    Session ID present in the ClientHello. 

I'm assuming this means that if the server accepts the ticket then it
MUST repond with the same Session ID present in ClientHello (which would
mean it MUST be empty if ClientHello Session ID is empty).

One alternative reading of that would be that the server can send an
empty Session ID if it accepts a ticket even if the ClientHello Session
ID is not empty.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 01 Aug 2007 19:02:15 +0100

Dr Stephen Henson wrote:
> I agree that some clarification is needed in that case. 
> 

Actually now I've re-read it this is exactly what Figure 3 is showing.

I suppose it could emphasize that an empty SessionTicket in ServerHello
MUST be present if and only if a NewSessionTicket message will be
sent.

Steve.

---

From: Mike <[email-masked]>
Date: Wed, 01 Aug 2007 11:50:19 -0700

> Actually now I've re-read it this is exactly what Figure 3 is showing.

But Figure 3 illustrates a full handshake.  The case I'm
talking about is an abbreviated handshake (session resume)
without the server sending an empty SessionTicket extension
or NewSessionTicket message.

Mike