Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] RE:  RFC 4507bis (Joseph Salowey (jsalowey))
Date: Sun, 19 Aug 2007 20:41:58 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE504578691@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <1D526804BA83A2459C60E28CA73ABD9001FC9DE0@TUS1XCHCLUPIN03.enterprise.veritas.com>
Thread-Topic: [TLS] RE:  RFC 4507bis (Joseph Salowey (jsalowey))
Thread-Index: AcfUVRePRd0P445dQU+ceHtZv6t9ngAFZLyAA5xQI0A=
From: "Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>
To: "Mark Tillinghast" <Mark_Tillinghast@symantec.com>, <tls@lists.ietf.org>
Cc: 
Precedence: list
Errors-To: tls-bounces@lists.ietf.org

Does anyone object to changing the example ticket integrity to
HMAC-SHA-256?  If not I'll look into getting this done. =20

Joe=20

> -----Original Message-----
> From: Mark Tillinghast [mailto:Mark_Tillinghast@symantec.com]=20
> Sent: Wednesday, August 01, 2007 11:46 AM
> To: tls@lists.ietf.org
> Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey))
>=20
> Hi Joe,
>=20
> I am very concerned about sha1 vs sha256.
> I have two different certificates with the same signature=20
> complements of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu.
> =20
> Nist guidance I think is along the lines of moving forward,=20
> SHA-256 should be used, TLS 1.2 is a big part of the moving forward.
>=20
> To quote Bruce Schneier quoting the NSA "Attacks get better;=20
> they never get worse."
>=20
> Mark
>=20
>=20
> -----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
>=20
> Send TLS mailing list submissions to
> 	tls@lists.ietf.org
>=20
> 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
>=20
> You can reach the person managing the list at
> 	tls-owner@lists.ietf.org
>=20
> When replying, please edit your Subject line so it is more=20
> specific than
> "Re: Contents of TLS digest..."
>=20
>=20
> Today's Topics:
>=20
>    1. RE:  RFC 4507bis (Joseph Salowey (jsalowey))
>    2. Re:  RFC 4507bis (Mike)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> 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:
> =09
> <AC1CFD94F59A264488DC2BEC3E890DE5043F329D@xmb-sjc-225.amer.cisco.com>
> Content-Type: text/plain;	charset=3D"us-ascii"
>=20
> Hi Mike,
>=20
> Thanks for reviewing the document, comments inline below:=20
>=20
> > -----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
> >=20
> > I'm working on adding support for RFC 4507 to my code and=20
> have found a
>=20
> > few issues with the draft.
> >=20
> >    - 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.
> >=20
> [Joe]It is part of the TLS hello message and is therefore=20
> included in the finished message.  This is part of the TLS=20
> extensions spec.  I'm not sure we need to clarify it here.
>=20
>=20
> >    - 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:
> >=20
> >      Client                                    Server
> >      ClientHello
> >      (SessionTicket extension) -->
> >                                           ServerHello
> >                          (no SessionTicket extension)
> >                                    [ChangeCipherSpec]
> >                                <--           Finished
> >      [ChangeCipherSpec]
> >      Finished                  -->
> >      Application Data          <->   Application Data
> >=20
> >      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).
> >=20
> [Joe] It is legal to not provide a new session ticket if you=20
> do not provide an empty session ticket extension from the=20
> server. However if you include an empty session ticket=20
> extension from the server you must provide a NewSessionTicket=20
> message (which may be empty).  Some other reviewers have had=20
> similar comments, is there a place where the text could be clearer?
>=20
> >    - 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.
> >=20
> [Joe] This is a implementation detail that I'm not sure we=20
> need to go into in the specification.=20
>=20
> >    - Should HMAC-SHA256 be recommended instead of
> >      HMAC-SHA1?
> >=20
> [Joe] I was under the impression that most people were OK with
> HMAC-SHA-1 use for the foreseeable future.  If this is not=20
> the case we can probably change it to HMAC-SHA-256.
>=20
> >    - 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.
> >=20
> > Mike
> >=20
> > _______________________________________________
> > TLS mailing list
> > TLS@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/tls
> >=20
>=20
>=20
>=20
> ------------------------------
>=20
> 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=3DISO-8859-1; format=3Dflowed
>=20
> >>    - 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=20
> included in=20
> > the finished message.  This is part of the TLS extensions=20
> spec.  I'm=20
> > not sure we need to clarify it here.
>=20
> I was referring to the NewSessionTicket message sent by the=20
> server to the client just before ChangeCipherSpec.
> I think you should state that it is included in the hash used=20
> to create/verify the Finished messages.
>=20
> >>    - 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=20
> > provide an empty session ticket extension from the server.=20
> However if=20
> > you include an empty session ticket extension from the=20
> server you must
>=20
> > provide a NewSessionTicket message (which may be empty). =20
> Some other=20
> > reviewers have had similar comments, is there a place where=20
> the text=20
> > could be clearer?
>=20
> The message flow diagram in the draft that shows session=20
> resumption has the server send an empty SessionTicket=20
> extension.  If the message flow above is also allowed (where=20
> no SessionTicket extension is sent by the server), then I=20
> think you should include the diagram in the spec.
>=20
> > [Joe] I was under the impression that most people were OK with
> > HMAC-SHA-1 use for the foreseeable future.  If this is not=20
> the case we
>=20
> > can probably change it to HMAC-SHA-256.
>=20
> I will leave that up to the experts to decide, but will use=20
> SHA-256 in my code in any case.
>=20
> Mike
>=20
>=20
>=20
> ------------------------------
>=20
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
>=20
>=20
> End of TLS Digest, Vol 37, Issue 1
> **********************************
>=20
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
>=20

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls