RE: [TLS] RFC 4507bis

["Joseph Salowey \(jsalowey\)" <[e-mail]>]

Hi Mike,

Thanks for reviewing the document, comments inline below: 

> -----Original Message-----
> From: Mike [mailto:[e-mail]] 
> Sent: Sunday, July 29, 2007 9:58 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
> 

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