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

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

Joe 

> -----Original Message-----
> From: Mark Tillinghast [mailto:Mark_Tillinghast@symantec.com] 
> Sent: Wednesday, August 01, 2007 11:46 AM
> To: tls@lists.ietf.org
> Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey))
> 
> 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: tls-request@lists.ietf.org [mailto:tls-request@lists.ietf.org]
> Sent: Wednesday, August 01, 2007 9:00 AM
> To: tls@lists.ietf.org
> Subject: TLS Digest, Vol 37, Issue 1
> 
> Send TLS mailing list submissions to
> 	tls@lists.ietf.org
> 
> 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
> 	tls-request@lists.ietf.org
> 
> You can reach the person managing the list at
> 	tls-owner@lists.ietf.org
> 
> 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\)" <jsalowey@cisco.com>
> Subject: RE: [TLS] RFC 4507bis
> To: "Mike" <mike-list@pobox.com>, <tls@ietf.org>
> Message-ID:
> 	
> <AC1CFD94F59A264488DC2BEC3E890DE5043F329D@xmb-sjc-225.amer.cisco.com>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Mike,
> 
> Thanks for reviewing the document, comments inline below: 
> 
> > -----Original Message-----
> > From: Mike [mailto:mike-list@pobox.com]
> > Sent: Sunday, July 29, 2007 9:58 AM
> > To: tls@ietf.org
> > 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
> > TLS@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/tls
> > 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 01 Aug 2007 07:43:55 -0700
> From: Mike <mike-list@pobox.com>
> Subject: Re: [TLS] RFC 4507bis
> To: tls@ietf.org
> Message-ID: <46B09C2B.70609@pobox.com>
> 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
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 
> 
> End of TLS Digest, Vol 37, Issue 1
> **********************************
> 
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls