Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey))

From: "Mark Tillinghast" <[email-masked]>
Date: Wed, 1 Aug 2007 11:46:22 -0700

Hi Joe,

I am very concerned about sha1 vs sha256.
I have two different certificates with the same signature complements of
Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu.
 
Nist guidance I think is along the lines of moving forward, SHA-256
should be used, TLS 1.2 is a big part of the moving forward.

To quote Bruce Schneier quoting the NSA "Attacks get better; they never
get worse."

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 9:00 AM
To: [email-masked]
Subject: TLS Digest, Vol 37, Issue 1

Send TLS mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of TLS digest..."

Today's Topics:

   1. RE:  RFC 4507bis (Joseph Salowey (jsalowey))
   2. Re:  RFC 4507bis (Mike)

----------------------------------------------------------------------

Message: 1
Date: Tue, 31 Jul 2007 22:17:02 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Subject: RE: [TLS] RFC 4507bis
To: "Mike" <[email-masked]>, <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

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
> 

------------------------------

Message: 2
Date: Wed, 01 Aug 2007 07:43:55 -0700
From: Mike <[email-masked]>
Subject: Re: [TLS] RFC 4507bis
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

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.

>>    - 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?

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.

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

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

Mike

------------------------------

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

End of TLS Digest, Vol 37, Issue 1
**********************************

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Sun, 19 Aug 2007 20:41:58 -0700

Does anyone object to changing the example ticket integrity to
HMAC-SHA-256?  If not I'll look into getting this done.  

Joe 

> From: Mark Tillinghast [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 11:46 AM
> To: [email-masked]
> Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey))
> 
> Hi Joe,
> 
> I have two different certificates with the same signature 
> complements of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu.
>  
> Nist guidance I think is along the lines of moving forward, 
> SHA-256 should be used, TLS 1.2 is a big part of the moving forward.
> 
> To quote Bruce Schneier quoting the NSA "Attacks get better; 
> they never get worse."
> 
> Mark
> 
> 
> [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.
> 
> 
> [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?
> 
> [Joe] This is a implementation detail that I'm not sure we 
> need to go into in the specification. 
> 
> HMAC-SHA-1 use for the foreseeable future.  If this is not 
> the case we can probably change it to HMAC-SHA-256.
> 
> 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.
> 
> 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.
> 
> I will leave that up to the experts to decide, but will use 
> SHA-256 in my code in any case.
> 
> Mike
> 
> 
>