From tls-bounces@lists.ietf.org Thu Dec 01 04:28:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehkjn-00087w-D2; Thu, 01 Dec 2005 04:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehkjl-00085y-8w for tls@megatron.ietf.org; Thu, 01 Dec 2005 04:28:21 -0500 Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11728 for ; Thu, 1 Dec 2005 04:27:35 -0500 (EST) Received: by nproxy.gmail.com with SMTP id b2so77303nfe for ; Thu, 01 Dec 2005 01:28:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:user-agent:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=EwqNVMHHuqOn40jFQymalbTz+roal7ZntdaZfnYXabYhOfcWDNJXd8cTfGuzO4zMd9JNFJv+vVwjrgP7wVUDgtXXirOhkN/xZ+7g/Kgm/cVVZ3EXVCa9q3gJUxs3FRUAiJnjblqN8WRQdo4NO0lfJkM8MR8oOhA8RrfSWtl6BG4= Received: by 10.48.238.8 with SMTP id l8mr244805nfh; Thu, 01 Dec 2005 01:28:19 -0800 (PST) Received: from turtle.i-net.gr ( [143.233.187.83]) by mx.gmail.com with ESMTP id c28sm252019nfb.2005.12.01.01.28.15; Thu, 01 Dec 2005 01:28:18 -0800 (PST) From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] Moving forward on draft-ietf-tls-srp User-Agent: KMail/1.8.2 References: <20051128182600.B7FC222244D@laser.networkresonance.com> <438CA784.5090205@edelweb.fr> <861x0z6yew.fsf@romeo.rtfm.com> In-Reply-To: <861x0z6yew.fsf@romeo.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 1 Dec 2005 10:27:37 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200512011027.37348.nmav@gnutls.org> Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Tuesday 29 November 2005 20:34, Eric Rescorla wrote: > > As already mentioned by Tom, client site validation of the group > > parameters can be easily done > > by comparing it to a fixed list in the client. > That's not really validation: it's effectively a fixed set of system > parameters--which isn't something, for instance, that the current > DH cipher suites have. Indeed but this compromise is there to allow storing a "verifier" instead of the plain password in the server. This is an extra feature not available in other protocols with similar functionality such as PSK. Depending on somebody's needs and the threat model, this extra feature can be crucial to overall security, and the cost of the inability to negotiate other parameters might be negligible. regards, Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 13 12:02:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmDXZ-00010B-PF; Tue, 13 Dec 2005 12:02:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmDXY-0000zy-CN for tls@megatron.ietf.org; Tue, 13 Dec 2005 12:02:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20992 for ; Tue, 13 Dec 2005 12:01:14 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmDYa-0007v9-2m for tls@ietf.org; Tue, 13 Dec 2005 12:03:16 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Dec 2005 09:02:00 -0800 X-IronPort-AV: i="3.99,248,1131350400"; d="scan'208"; a="684139530:sNHT624619820" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBDH1v70001339; Tue, 13 Dec 2005 09:01:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Dec 2005 09:07:58 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69065D9E0F@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket Thread-Index: AcYABuwzh9Z2ByCVSq6d52Y4GXByOg== From: "Salowey, Joe" To: "Rob Dugal" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: [TLS] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Below are the sections from the tls ticket draft that should fix the issue with DTLS. The server is now required to send a SessionTicket handshake extension if it is going to send a SessionTicket handshake message. Let me know if this looks OK. Thanks, Joe=20 3.2 SessionTicket TLS extension The SessionTicket TLS extension is based on [I-D.ietf-tls- rfc3546bis]. The format of the ticket is an opaque structure used to carry session specific state information. This extension may be sent in the ClientHello and ServerHello. If the client posses a ticket that it wants to use to resume a session then it includes it in the SessionTicket extension in the ClientHello. If the client does not have a ticket and it is prepared to receive one in the SessionTicket handshake message then it MUST include a zero length ticket in the SessionTicket extension. If the client is not prepared to receive a ticket in the SessionTicket handshake message then it MUST NOT include a SessionTicket extension unless it is sending a non-empty ticket it received through some other means from the server. The server uses an zero length SessionTicket extension to indicate to the client that it will send a new session ticket using the SessionTicket handshake message described in Section 3.3. The server MUST send this extension in the ServerHello if the server wishes to issue a new ticket to the client using the SessionTicket handshake message. The server MUST NOT send this extension if the client does not include a SessionTicket handshake message in the client hello. If the server fails to verify the ticket then it falls back to performing a full handshake. If the ticket is accepted by the server but the handshake fails the client SHOULD delete the ticket. The SessionTicket extension has been assigned the number TBD1. The format of the SessionTicket extension is given below. < skip ticket format definition > 3.3 SessionTicket handshake message This message is sent by the server during the TLS handshake before the ChangeCipherSpec message. This message MUST be sent if the server included a SessionTicket extension in the ServerHello. This message MUST NOT be sent if the server did not include a SessionTicket extension in the ServerHello. In the case of a full handshake, the server MUST verify the client's Finished message before sending the ticket. The client MUST NOT treat the ticket as valid until it has verified the server's Finished message. If the server determines that it does not want to include a ticket after it has included the SessionTicket extension in the ServerHello then it MAY send a zero length ticket in the SessionTicket handshake message. If the server successfully verifies the client's ticket then it MAY renew the ticket by including a SessionTicket handshake message after the ServerHello in the abbreviated handshake. The client should start using the new ticket as soon as possible after it verifies the Server's finished message for new connections. Note that since the updated ticket is issued before the handshake completes it is possible that the client may not put the new ticket into use before it initiates new connections. The server MUST NOT assume the client actually received the updated ticket until it successfully verifies the client's Finished message. The SessionTicket handshake message has been assigned the number TBD2. The definition of the SessionTicket handshake message is given below. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 14 10:29:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYZ3-0006KV-4V; Wed, 14 Dec 2005 10:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYYz-0006Jz-Io for tls@megatron.ietf.org; Wed, 14 Dec 2005 10:29:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10185 for ; Wed, 14 Dec 2005 10:27:55 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYa0-0003BD-V9 for tls@ietf.org; Wed, 14 Dec 2005 10:30:09 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 04F45100233DA; Wed, 14 Dec 2005 10:28:35 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13033-55; Wed, 14 Dec 2005 10:28:25 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 10306100233DC; Wed, 14 Dec 2005 10:28:25 -0500 (EST) In-Reply-To: <7210B31550AC934A8637D6619739CE69065D9E0F@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: Re: [TLS] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 14 Dec 2005 10:28:50 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 12/14/2005 10:28:50 AM, Serialize complete at 12/14/2005 10:28:50 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: tls-bounces@ietf.org, bminard , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1150167032==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1150167032== Content-Type: multipart/alternative; boundary="=_alternative 00553ABB852570D7_=" This is a multipart message in MIME format. --=_alternative 00553ABB852570D7_= Content-Type: text/plain; charset="US-ASCII" I don't see any problem with the proposed revision. However, I still think the draft could be improved and I don't think the SessionTicket extension can be efficiently supported in DTLS because of how DTLS handles the ChangeCipherSpec message. As I have stated previously on this list I do not like the SessionTicket draft for one fundamental reason. The client does not know that the server is resuming using a ticket unless it receives the ChangeCipherSpec message immediately after the ServerHello. This is not true with regular session resumption. The client knows the server is resuming by a non-empty session id in the ServerHello. With regular session resumption the client desn't have to look at what message arrives next to determine if it is resuming. Because of this when we implemented SessionTicket in our TLS implementation we had to make the handshake state machine more complex. The proposed change will allow us to somewhat simplify our state machine implementation but it will still be less than ideal in my opinion. Your proposed change only indicates if a new ticket will be issued, not whether the server will resume or not. I would prefer that the ServerHello contain something to clearly indicate that the server is resuming using the SessionTicket. This could be done by adding an extension to the ServerHello and have the extension contain some flags that indicate if the session will be resumed and if a new ticket will be issued. Note: this might not be permitted in RFC3546 because I think it says that the extensions in the ServerHello should be empty. As I have stated previously on this list I do not like the DTLS draft because of how it handles the ChangeCipherSpec message. In DTLS only handshake messages have a message sequence number (MSN). The MSN allows the DTLS record layer to determine if handshake messages have been lost and their correct order. However, the ChangeCipherSpec does not have an MSN. Since the CCS always preceeds the Finished message we can only determine it's correct position by decrypting the Finished message. Decrypting the Finished message requires that the handshake layer has already derived the read/write keys from the master secret. If the ChangeCipherSpec message had an MSN then determining it's position in relation to handshake messages would be trivial and would not require decrypting the Finished message. It is interesting to note that the co-author of the DTLS draft wrote the openssl implementation of DTLS and incorrectly coded the ChangeCipherSpec message to contain an MSN. I will be interested in seeing how he resolves this problem in openssl because it caused me some headaches in our own DTLS implementation. In a normal DTLS handshake, when the client receives the ServerHello with a session id it knows the server is resuming, retrieves the saved session state and generates the read/write keys from the master secret. It is then possible to decrypt the Finished message when it arrives and find out the correct position of the CCS. In a SessionTicket DTLS handshake when the client receives the ServerHello it doesn't know if the server is resuming using the ticket. So what should it do? Should the client always assume the ticket will be resumed and generate the read/write keys from the master secret? If It does this and the server then decides to instead do a full handshake then I just wasted time generating the read/write keys. That's not ideal in my opinion. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 12/13/2005 12:07:58 PM: > Below are the sections from the tls ticket draft that should fix the > issue with DTLS. The server is now required to send a SessionTicket > handshake extension if it is going to send a SessionTicket handshake > message. Let me know if this looks OK. > > Thanks, > > Joe > > 3.2 SessionTicket TLS extension > > The SessionTicket TLS extension is based on [I-D.ietf-tls- > rfc3546bis]. The format of the ticket is an opaque structure used to > carry session specific state information. This extension may be sent > in the ClientHello and ServerHello. > > If the client posses a ticket that it wants to use to resume a > session then it includes it in the SessionTicket extension in the > ClientHello. If the client does not have a ticket and it is prepared > to receive one in the SessionTicket handshake message then it MUST > include a zero length ticket in the SessionTicket extension. If the > client is not prepared to receive a ticket in the SessionTicket > handshake message then it MUST NOT include a SessionTicket extension > unless it is sending a non-empty ticket it received through some > other means from the server. > > The server uses an zero length SessionTicket extension to indicate to > the client that it will send a new session ticket using the > SessionTicket handshake message described in Section 3.3. The server > MUST send this extension in the ServerHello if the server wishes to > issue a new ticket to the client using the SessionTicket handshake > message. The server MUST NOT send this extension if the client does > not include a SessionTicket handshake message in the client hello. > > If the server fails to verify the ticket then it falls back to > performing a full handshake. If the ticket is accepted by the server > but the handshake fails the client SHOULD delete the ticket. > > The SessionTicket extension has been assigned the number TBD1. The > format of the SessionTicket extension is given below. > > > < skip ticket format definition > > > > 3.3 SessionTicket handshake message > > This message is sent by the server during the TLS handshake before > the ChangeCipherSpec message. This message MUST be sent if the > server included a SessionTicket extension in the ServerHello. This > message MUST NOT be sent if the server did not include a > SessionTicket extension in the ServerHello. In the case of a full > handshake, the server MUST verify the client's Finished message > before sending the ticket. The client MUST NOT treat the ticket as > valid until it has verified the server's Finished message. If the > server determines that it does not want to include a ticket after it > has included the SessionTicket extension in the ServerHello then it > MAY send a zero length ticket in the SessionTicket handshake message. > > If the server successfully verifies the client's ticket then it MAY > renew the ticket by including a SessionTicket handshake message after > the ServerHello in the abbreviated handshake. The client should > start using the new ticket as soon as possible after it verifies the > Server's finished message for new connections. Note that since the > updated ticket is issued before the handshake completes it is > possible that the client may not put the new ticket into use before > it initiates new connections. The server MUST NOT assume the client > actually received the updated ticket until it successfully verifies > the client's Finished message. > > The SessionTicket handshake message has been assigned the number > TBD2. The definition of the SessionTicket handshake message is given > below. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 00553ABB852570D7_= Content-Type: text/html; charset="US-ASCII"
I don't see any problem with the proposed revision. However, I still think the draft could be improved and I don't think the SessionTicket extension can be efficiently supported in DTLS because of how DTLS handles the ChangeCipherSpec message.

As I have stated previously on this list I do not like the SessionTicket draft for one fundamental reason. The client does not know that the server is resuming using a ticket unless it receives the ChangeCipherSpec message immediately after the ServerHello. This is not true with regular session resumption. The client knows the server is resuming by a non-empty session id in the ServerHello. With regular session resumption the client desn't have to look at what message arrives next to determine if it is resuming. Because of this when we implemented SessionTicket in our TLS implementation we had to make the handshake state machine more complex. The proposed change will allow us to somewhat simplify our state machine implementation but it will still be less than ideal in my opinion. Your proposed change only indicates if a new ticket will be issued, not whether the server will resume or not. I would prefer that the ServerHello contain something to clearly indicate that the server is resuming using the SessionTicket. This could be done by adding an extension to the ServerHello and have the extension contain some flags that indicate if the session will be resumed and if a new ticket will be issued. Note: this might not be permitted in RFC3546 because I think it says that the extensions in the ServerHello should be empty.  

As I have stated previously on this list I do not like the DTLS draft because of how it handles the ChangeCipherSpec message. In DTLS only handshake messages have a message sequence number (MSN). The MSN allows the DTLS record layer to determine if handshake messages have been lost and their correct order. However, the ChangeCipherSpec does not have an MSN. Since the CCS always preceeds the Finished message we can only determine it's correct position by decrypting the Finished message. Decrypting the Finished message requires that the handshake layer has already derived the read/write keys from the master secret. If the ChangeCipherSpec message had an MSN then determining it's position in relation to handshake messages would be trivial and would not require decrypting the Finished message.  It is interesting to note that the co-author of the DTLS draft wrote the openssl implementation of DTLS and incorrectly coded the ChangeCipherSpec message to contain an MSN. I will be interested in seeing how he resolves this problem in openssl because it caused me some headaches in our own DTLS implementation.

In a normal DTLS handshake, when the client receives the ServerHello with a session id it knows the server is resuming, retrieves the saved session state and generates the read/write keys from the master secret. It is then possible to decrypt the Finished message when it arrives and find out the correct position of the CCS.

In a SessionTicket DTLS handshake when the client receives the ServerHello it doesn't know if the server is resuming using the ticket. So what should it do? Should the client always assume the ticket will be resumed and generate the read/write keys from the master secret? If It does this and the server then decides to instead do a full handshake then I just wasted time generating the read/write keys. That's not ideal in my opinion.

 

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 12/13/2005 12:07:58 PM:

> Below are the sections from the tls ticket draft that should fix the
> issue with DTLS.  The server is now required to send a SessionTicket
> handshake extension if it is going to send a SessionTicket handshake
> message.  Let me know if this looks OK.
>
> Thanks,
>
> Joe
>
> 3.2  SessionTicket TLS extension
>
>    The SessionTicket TLS extension is based on [I-D.ietf-tls-
>    rfc3546bis].  The format of the ticket is an opaque structure used to
>    carry session specific state information.  This extension may be sent
>    in the ClientHello and ServerHello.
>
>    If the client posses a ticket that it wants to use to resume a
>    session then it includes it in the SessionTicket extension in the
>    ClientHello.  If the client does not have a ticket and it is prepared
>    to receive one in the SessionTicket handshake message then it MUST
>    include a zero length ticket in the SessionTicket extension.  If the
>    client is not prepared to receive a ticket in the SessionTicket
>    handshake message then it MUST NOT include a SessionTicket extension
>    unless it is sending a non-empty ticket it received through some
>    other means from the server.
>
>    The server uses an zero length SessionTicket extension to indicate to
>    the client that it will send a new session ticket using the
>    SessionTicket handshake message described in Section 3.3.  The server
>    MUST send this extension in the ServerHello if the server wishes to
>    issue a new ticket to the client using the SessionTicket handshake
>    message.  The server MUST NOT send this extension if the client does
>    not include a SessionTicket handshake message in the client hello.
>
>    If the server fails to verify the ticket then it falls back to
>    performing a full handshake.  If the ticket is accepted by the server
>    but the handshake fails the client SHOULD delete the ticket.
>
>    The SessionTicket extension has been assigned the number TBD1.  The
>    format of the SessionTicket extension is given below.
>
>
> < skip ticket format definition >
>
>
> 3.3  SessionTicket handshake message
>
>    This message is sent by the server during the TLS handshake before
>    the ChangeCipherSpec message.  This message MUST be sent if the
>    server included a SessionTicket extension in the ServerHello.  This
>    message MUST NOT be sent if the server did not include a
>    SessionTicket extension in the ServerHello.  In the case of a full
>    handshake, the server MUST verify the client's Finished message
>    before sending the ticket.  The client MUST NOT treat the ticket as
>    valid until it has verified the server's Finished message.  If the
>    server determines that it does not want to include a ticket after it
>    has included the SessionTicket extension in the ServerHello then it
>    MAY send a zero length ticket in the SessionTicket handshake message.
>
>    If the server successfully verifies the client's ticket then it MAY
>    renew the ticket by including a SessionTicket handshake message after
>    the ServerHello in the abbreviated handshake.  The client should
>    start using the new ticket as soon as possible after it verifies the
>    Server's finished message for new connections.  Note that since the
>    updated ticket is issued before the handshake completes it is
>    possible that the client may not put the new ticket into use before
>    it initiates new connections.  The server MUST NOT assume the client
>    actually received the updated ticket until it successfully verifies
>    the client's Finished message.
>
>    The SessionTicket handshake message has been assigned the number
>    TBD2.  The definition of the SessionTicket handshake message is given
>    below.
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 00553ABB852570D7_=-- --===============1150167032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1150167032==-- From tls-bounces@lists.ietf.org Wed Dec 14 14:48:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emcba-0003Dh-UO; Wed, 14 Dec 2005 14:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcbZ-0003By-Dz for tls@megatron.ietf.org; Wed, 14 Dec 2005 14:48:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16144 for ; Wed, 14 Dec 2005 14:46:57 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emcck-0005sJ-DZ for tls@ietf.org; Wed, 14 Dec 2005 14:49:15 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 11:47:47 -0800 X-IronPort-AV: i="3.99,252,1131350400"; d="scan'208"; a="684621231:sNHT36618168" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBEJlkQg023598; Wed, 14 Dec 2005 11:47:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket Date: Wed, 14 Dec 2005 11:53:47 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69065DA16B@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket Thread-Index: AcYAw+vk1fnHX9mxSHiR3/ls1Zd6cQAIDyjg From: "Salowey, Joe" To: "Rob Dugal" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: tls-bounces@ietf.org, bminard , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Rob, The current text in section 3.4 allows the client know whether the server will resume based on the contents of the ServerHello. If the server returns back the sessionID that the client sent in the ClientHello the the client know the server is resuming the session. This achieves the same result as including flags in the SessionTicket extension in the ServerHello. I think that section 3.4 along with the latest modification make it clear what handshake messages the client and server are expected to send and receive.=20 The text is included below, let me know if there is something incorrect or not clear about it.=20 3.4 Interaction with TLS session ID "If a server is planning on issuing a SessionTicket to a client that does not present one it SHOULD include an empty Session ID in the ServerHello. If the server includes a non-empty session ID then it is indicating intent to use stateful session resume. If the client receives a SessionTicket from the server then it discards any Session ID that was sent in the ServerHello. 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. This allows the client to easily differentiate when the server is resuming a session or falling back to a full handshake. Since the client generates a Session ID the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. If a ticket is presented by the client the server MUST NOT attempt to use the Session ID in the ClientHello for stateful session resume. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages." Thanks, Joe =20 > -----Original Message----- > From: Rob Dugal [mailto:RDugal@certicom.com]=20 > Sent: Wednesday, December 14, 2005 7:29 AM > To: Salowey, Joe > Cc: Eric Rescorla; tls@ietf.org; tls-bounces@lists.ietf.org; bminard > Subject: Re: [TLS] Revised sections 3.2 and 3.3 from=20 > draft-salowey-tls-ticket >=20 >=20 > I don't see any problem with the proposed revision. However,=20 > I still think the draft could be improved and I don't think=20 > the SessionTicket extension can be efficiently supported in=20 > DTLS because of how DTLS handles the ChangeCipherSpec message.=20 >=20 > As I have stated previously on this list I do not like the=20 > SessionTicket draft for one fundamental reason. The client=20 > does not know that the server is resuming using a ticket=20 > unless it receives the ChangeCipherSpec message immediately=20 > after the ServerHello. This is not true with regular session=20 > resumption. The client knows the server is resuming by a=20 > non-empty session id in the ServerHello. With regular session=20 > resumption the client desn't have to look at what message=20 > arrives next to determine if it is resuming. Because of this=20 > when we implemented SessionTicket in our TLS implementation=20 > we had to make the handshake state machine more complex. The=20 > proposed change will allow us to somewhat simplify our state=20 > machine implementation but it will still be less than ideal=20 > in my opinion. Your proposed change only indicates if a new=20 > ticket will be issued, not whether the server will resume or=20 > not. I would prefer that the ServerHello contain something to=20 > clearly indicate that the server is resuming using the=20 > SessionTicket. This could be done by adding an extension to=20 > the ServerHello and have the extension contain some flags=20 > that indicate if the session will be resumed and if a new=20 > ticket will be issued. Note: this might not be permitted in=20 > RFC3546 because I think it says that the extensions in the=20 > ServerHello should be empty. =20 >=20 > As I have stated previously on this list I do not like the=20 > DTLS draft because of how it handles the ChangeCipherSpec=20 > message. In DTLS only handshake messages have a message=20 > sequence number (MSN). The MSN allows the DTLS record layer=20 > to determine if handshake messages have been lost and their=20 > correct order. However, the ChangeCipherSpec does not have an=20 > MSN. Since the CCS always preceeds the Finished message we=20 > can only determine it's correct position by decrypting the=20 > Finished message. Decrypting the Finished message requires=20 > that the handshake layer has already derived the read/write=20 > keys from the master secret. If the ChangeCipherSpec message=20 > had an MSN then determining it's position in relation to=20 > handshake messages would be trivial and would not require=20 > decrypting the Finished message. It is interesting to note=20 > that the co-author of the DTLS draft wrote the openssl=20 > implementation of DTLS and incorrectly coded the=20 > ChangeCipherSpec message to contain an MSN. I will be=20 > interested in seeing how he resolves this problem in openssl=20 > because it caused me some headaches in our own DTLS implementation.=20 >=20 > In a normal DTLS handshake, when the client receives the=20 > ServerHello with a session id it knows the server is=20 > resuming, retrieves the saved session state and generates the=20 > read/write keys from the master secret. It is then possible=20 > to decrypt the Finished message when it arrives and find out=20 > the correct position of the CCS.=20 >=20 > In a SessionTicket DTLS handshake when the client receives=20 > the ServerHello it doesn't know if the server is resuming=20 > using the ticket. So what should it do? Should the client=20 > always assume the ticket will be resumed and generate the=20 > read/write keys from the master secret? If It does this and=20 > the server then decides to instead do a full handshake then I=20 > just wasted time generating the read/write keys. That's not=20 > ideal in my opinion.=20 >=20 > =20 >=20 > ----------------------------------------------- > Robert Dugal > Member of Development Group > Certicom Corp. > EMAIL: rdugal@certicom.com > PHONE: (905) 501-3848 > FAX : (905) 507-4230 > WEBSITE: www.certicom.com=20 >=20 > tls-bounces@lists.ietf.org wrote on 12/13/2005 12:07:58 PM: >=20 > > Below are the sections from the tls ticket draft that=20 > should fix the=20 > > issue with DTLS. The server is now required to send a=20 > SessionTicket=20 > > handshake extension if it is going to send a SessionTicket=20 > handshake=20 > > message. Let me know if this looks OK. > >=20 > > Thanks, > >=20 > > Joe > >=20 > > 3.2 SessionTicket TLS extension > >=20 > > The SessionTicket TLS extension is based on [I-D.ietf-tls- > > rfc3546bis]. The format of the ticket is an opaque=20 > structure used to > > carry session specific state information. This=20 > extension may be sent > > in the ClientHello and ServerHello. > >=20 > > If the client posses a ticket that it wants to use to resume a > > session then it includes it in the SessionTicket extension in the > > ClientHello. If the client does not have a ticket and=20 > it is prepared > > to receive one in the SessionTicket handshake message=20 > then it MUST > > include a zero length ticket in the SessionTicket=20 > extension. If the > > client is not prepared to receive a ticket in the SessionTicket > > handshake message then it MUST NOT include a=20 > SessionTicket extension > > unless it is sending a non-empty ticket it received through some > > other means from the server. > >=20 > > The server uses an zero length SessionTicket extension=20 > to indicate to > > the client that it will send a new session ticket using the > > SessionTicket handshake message described in Section=20 > 3.3. The server > > MUST send this extension in the ServerHello if the=20 > server wishes to > > issue a new ticket to the client using the SessionTicket=20 > handshake > > message. The server MUST NOT send this extension if the=20 > client does > > not include a SessionTicket handshake message in the=20 > client hello. > >=20 > > If the server fails to verify the ticket then it falls back to > > performing a full handshake. If the ticket is accepted=20 > by the server > > but the handshake fails the client SHOULD delete the ticket. > >=20 > > The SessionTicket extension has been assigned the number=20 > TBD1. The > > format of the SessionTicket extension is given below. > >=20 > >=20 > > < skip ticket format definition > > >=20 > >=20 > > 3.3 SessionTicket handshake message > >=20 > > This message is sent by the server during the TLS=20 > handshake before > > the ChangeCipherSpec message. This message MUST be sent if the > > server included a SessionTicket extension in the=20 > ServerHello. This > > message MUST NOT be sent if the server did not include a > > SessionTicket extension in the ServerHello. In the case=20 > of a full > > handshake, the server MUST verify the client's Finished message > > before sending the ticket. The client MUST NOT treat=20 > the ticket as > > valid until it has verified the server's Finished=20 > message. If the > > server determines that it does not want to include a=20 > ticket after it > > has included the SessionTicket extension in the=20 > ServerHello then it > > MAY send a zero length ticket in the SessionTicket=20 > handshake message. > >=20 > > If the server successfully verifies the client's ticket=20 > then it MAY > > renew the ticket by including a SessionTicket handshake=20 > message after > > the ServerHello in the abbreviated handshake. The client should > > start using the new ticket as soon as possible after it=20 > verifies the > > Server's finished message for new connections. Note=20 > that since the > > updated ticket is issued before the handshake completes it is > > possible that the client may not put the new ticket into=20 > use before > > it initiates new connections. The server MUST NOT=20 > assume the client > > actually received the updated ticket until it=20 > successfully verifies > > the client's Finished message. > >=20 > > The SessionTicket handshake message has been assigned the number > > TBD2. The definition of the SessionTicket handshake=20 > message is given > > below. > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 15 07:35:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmsKZ-0004Mf-7S; Thu, 15 Dec 2005 07:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmsKW-0004Ma-D2 for tls@megatron.ietf.org; Thu, 15 Dec 2005 07:35:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29725 for ; Thu, 15 Dec 2005 07:34:28 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmsLs-00082F-1Q for tls@ietf.org; Thu, 15 Dec 2005 07:36:55 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 2A49F100233D3; Thu, 15 Dec 2005 07:35:07 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24102-10; Thu, 15 Dec 2005 07:35:00 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id B4C72100233C3; Thu, 15 Dec 2005 07:35:00 -0500 (EST) In-Reply-To: <7210B31550AC934A8637D6619739CE69065DA16B@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: RE: [TLS] Revised sections 3.2 and 3.3 from draft-salowey-tls-ticket MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 15 Dec 2005 07:35:01 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 12/15/2005 07:35:26 AM, Serialize complete at 12/15/2005 07:35:26 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 Cc: tls-bounces@ietf.org, bminard , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684240487==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0684240487== Content-Type: multipart/alternative; boundary="=_alternative 00453B76852570D8_=" This is a multipart message in MIME format. --=_alternative 00453B76852570D8_= Content-Type: text/plain; charset="US-ASCII" Thanks Joe, I now see how section 3.4 allows the client to determine from the ServerHello if the ticket will be resumed. This addresses all my concerens and I think we can also add the extension to our DTLS implementation. "Salowey, Joe" wrote on 12/14/2005 02:53:47 PM: > Hi Rob, > > The current text in section 3.4 allows the client know whether the > server will resume based on the contents of the ServerHello. If the > server returns back the sessionID that the client sent in the > ClientHello the the client know the server is resuming the session. > This achieves the same result as including flags in the SessionTicket > extension in the ServerHello. I think that section 3.4 along with the > latest modification make it clear what handshake messages the client and > server are expected to send and receive. > > The text is included below, let me know if there is something incorrect > or not clear about it. > > 3.4 Interaction with TLS session ID > > "If a server is planning on issuing a SessionTicket to a client that > does not present one it SHOULD include an empty Session ID in the > ServerHello. If the server includes a non-empty session ID then it > is indicating intent to use stateful session resume. If the client > receives a SessionTicket from the server then it discards any Session > ID that was sent in the ServerHello. > > 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. This allows the client to > easily differentiate when the server is resuming a session or falling > back to a full handshake. Since the client generates a Session ID > the server MUST NOT rely upon the Session ID having a particular > value when validating the ticket. If a ticket is presented by the > client the server MUST NOT attempt to use the Session ID in the > ClientHello for stateful session resume. Alternatively, the client > MAY include an empty Session ID in the ClientHello. In this case the > client ignores the Session ID sent in the ServerHello and determines > if the server is resuming a session by the subsequent handshake > messages." > > Thanks, > > Joe > > > > > -----Original Message----- > > From: Rob Dugal [mailto:RDugal@certicom.com] > > Sent: Wednesday, December 14, 2005 7:29 AM > > To: Salowey, Joe > > Cc: Eric Rescorla; tls@ietf.org; tls-bounces@lists.ietf.org; bminard > > Subject: Re: [TLS] Revised sections 3.2 and 3.3 from > > draft-salowey-tls-ticket > > > > > > I don't see any problem with the proposed revision. However, > > I still think the draft could be improved and I don't think > > the SessionTicket extension can be efficiently supported in > > DTLS because of how DTLS handles the ChangeCipherSpec message. > > > > As I have stated previously on this list I do not like the > > SessionTicket draft for one fundamental reason. The client > > does not know that the server is resuming using a ticket > > unless it receives the ChangeCipherSpec message immediately > > after the ServerHello. This is not true with regular session > > resumption. The client knows the server is resuming by a > > non-empty session id in the ServerHello. With regular session > > resumption the client desn't have to look at what message > > arrives next to determine if it is resuming. Because of this > > when we implemented SessionTicket in our TLS implementation > > we had to make the handshake state machine more complex. The > > proposed change will allow us to somewhat simplify our state > > machine implementation but it will still be less than ideal > > in my opinion. Your proposed change only indicates if a new > > ticket will be issued, not whether the server will resume or > > not. I would prefer that the ServerHello contain something to > > clearly indicate that the server is resuming using the > > SessionTicket. This could be done by adding an extension to > > the ServerHello and have the extension contain some flags > > that indicate if the session will be resumed and if a new > > ticket will be issued. Note: this might not be permitted in > > RFC3546 because I think it says that the extensions in the > > ServerHello should be empty. > > > > As I have stated previously on this list I do not like the > > DTLS draft because of how it handles the ChangeCipherSpec > > message. In DTLS only handshake messages have a message > > sequence number (MSN). The MSN allows the DTLS record layer > > to determine if handshake messages have been lost and their > > correct order. However, the ChangeCipherSpec does not have an > > MSN. Since the CCS always preceeds the Finished message we > > can only determine it's correct position by decrypting the > > Finished message. Decrypting the Finished message requires > > that the handshake layer has already derived the read/write > > keys from the master secret. If the ChangeCipherSpec message > > had an MSN then determining it's position in relation to > > handshake messages would be trivial and would not require > > decrypting the Finished message. It is interesting to note > > that the co-author of the DTLS draft wrote the openssl > > implementation of DTLS and incorrectly coded the > > ChangeCipherSpec message to contain an MSN. I will be > > interested in seeing how he resolves this problem in openssl > > because it caused me some headaches in our own DTLS implementation. > > > > In a normal DTLS handshake, when the client receives the > > ServerHello with a session id it knows the server is > > resuming, retrieves the saved session state and generates the > > read/write keys from the master secret. It is then possible > > to decrypt the Finished message when it arrives and find out > > the correct position of the CCS. > > > > In a SessionTicket DTLS handshake when the client receives > > the ServerHello it doesn't know if the server is resuming > > using the ticket. So what should it do? Should the client > > always assume the ticket will be resumed and generate the > > read/write keys from the master secret? If It does this and > > the server then decides to instead do a full handshake then I > > just wasted time generating the read/write keys. That's not > > ideal in my opinion. > > > > > > > > ----------------------------------------------- > > Robert Dugal > > Member of Development Group > > Certicom Corp. > > EMAIL: rdugal@certicom.com > > PHONE: (905) 501-3848 > > FAX : (905) 507-4230 > > WEBSITE: www.certicom.com > > > > tls-bounces@lists.ietf.org wrote on 12/13/2005 12:07:58 PM: > > > > > Below are the sections from the tls ticket draft that > > should fix the > > > issue with DTLS. The server is now required to send a > > SessionTicket > > > handshake extension if it is going to send a SessionTicket > > handshake > > > message. Let me know if this looks OK. > > > > > > Thanks, > > > > > > Joe > > > > > > 3.2 SessionTicket TLS extension > > > > > > The SessionTicket TLS extension is based on [I-D.ietf-tls- > > > rfc3546bis]. The format of the ticket is an opaque > > structure used to > > > carry session specific state information. This > > extension may be sent > > > in the ClientHello and ServerHello. > > > > > > If the client posses a ticket that it wants to use to resume a > > > session then it includes it in the SessionTicket extension in the > > > ClientHello. If the client does not have a ticket and > > it is prepared > > > to receive one in the SessionTicket handshake message > > then it MUST > > > include a zero length ticket in the SessionTicket > > extension. If the > > > client is not prepared to receive a ticket in the SessionTicket > > > handshake message then it MUST NOT include a > > SessionTicket extension > > > unless it is sending a non-empty ticket it received through some > > > other means from the server. > > > > > > The server uses an zero length SessionTicket extension > > to indicate to > > > the client that it will send a new session ticket using the > > > SessionTicket handshake message described in Section > > 3.3. The server > > > MUST send this extension in the ServerHello if the > > server wishes to > > > issue a new ticket to the client using the SessionTicket > > handshake > > > message. The server MUST NOT send this extension if the > > client does > > > not include a SessionTicket handshake message in the > > client hello. > > > > > > If the server fails to verify the ticket then it falls back to > > > performing a full handshake. If the ticket is accepted > > by the server > > > but the handshake fails the client SHOULD delete the ticket. > > > > > > The SessionTicket extension has been assigned the number > > TBD1. The > > > format of the SessionTicket extension is given below. > > > > > > > > > < skip ticket format definition > > > > > > > > > > 3.3 SessionTicket handshake message > > > > > > This message is sent by the server during the TLS > > handshake before > > > the ChangeCipherSpec message. This message MUST be sent if the > > > server included a SessionTicket extension in the > > ServerHello. This > > > message MUST NOT be sent if the server did not include a > > > SessionTicket extension in the ServerHello. In the case > > of a full > > > handshake, the server MUST verify the client's Finished message > > > before sending the ticket. The client MUST NOT treat > > the ticket as > > > valid until it has verified the server's Finished > > message. If the > > > server determines that it does not want to include a > > ticket after it > > > has included the SessionTicket extension in the > > ServerHello then it > > > MAY send a zero length ticket in the SessionTicket > > handshake message. > > > > > > If the server successfully verifies the client's ticket > > then it MAY > > > renew the ticket by including a SessionTicket handshake > > message after > > > the ServerHello in the abbreviated handshake. The client should > > > start using the new ticket as soon as possible after it > > verifies the > > > Server's finished message for new connections. Note > > that since the > > > updated ticket is issued before the handshake completes it is > > > possible that the client may not put the new ticket into > > use before > > > it initiates new connections. The server MUST NOT > > assume the client > > > actually received the updated ticket until it > > successfully verifies > > > the client's Finished message. > > > > > > The SessionTicket handshake message has been assigned the number > > > TBD2. The definition of the SessionTicket handshake > > message is given > > > below. > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/tls > > > > --=_alternative 00453B76852570D8_= Content-Type: text/html; charset="US-ASCII"
Thanks Joe, I now see how section 3.4  allows the client to determine from the ServerHello if the ticket will be resumed.
This addresses all my concerens and I think we can also add the extension to our DTLS implementation.

"Salowey, Joe" <jsalowey@cisco.com> wrote on 12/14/2005 02:53:47 PM:

> Hi Rob,
>
> The current text in section 3.4 allows the client know whether the
> server will resume based on the contents of the ServerHello.  If the
> server returns back the sessionID that the client sent in the
> ClientHello the the client know the server is resuming the session.
> This achieves the same result as including flags in the SessionTicket
> extension in the ServerHello.  I think that section 3.4 along with the
> latest modification make it clear what handshake messages the client and
> server are expected to send and receive.
>
> The text is included below, let me know if there is something incorrect
> or not clear about it.
>
> 3.4  Interaction with TLS session ID
>
>    "If a server is planning on issuing a SessionTicket to a client that
>    does not present one it SHOULD include an empty Session ID in the
>    ServerHello.  If the server includes a non-empty session ID then it
>    is indicating intent to use stateful session resume.  If the client
>    receives a SessionTicket from the server then it discards any Session
>    ID that was sent in the ServerHello.
>
>    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.  This allows the client to
>    easily differentiate when the server is resuming a session or falling
>    back to a full handshake.  Since the client generates a Session ID
>    the server MUST NOT rely upon the Session ID having a particular
>    value when validating the ticket.  If a ticket is presented by the
>    client the server MUST NOT attempt to use the Session ID in the
>    ClientHello for stateful session resume.  Alternatively, the client
>    MAY include an empty Session ID in the ClientHello.  In this case the
>    client ignores the Session ID sent in the ServerHello and determines
>    if the server is resuming a session by the subsequent handshake
>    messages."
>
> Thanks,
>
> Joe
>
>  
>
> > -----Original Message-----
> > From: Rob Dugal [mailto:RDugal@certicom.com]
> > Sent: Wednesday, December 14, 2005 7:29 AM
> > To: Salowey, Joe
> > Cc: Eric Rescorla; tls@ietf.org; tls-bounces@lists.ietf.org; bminard
> > Subject: Re: [TLS] Revised sections 3.2 and 3.3 from
> > draft-salowey-tls-ticket
> >
> >
> > I don't see any problem with the proposed revision. However,
> > I still think the draft could be improved and I don't think
> > the SessionTicket extension can be efficiently supported in
> > DTLS because of how DTLS handles the ChangeCipherSpec message.
> >
> > As I have stated previously on this list I do not like the
> > SessionTicket draft for one fundamental reason. The client
> > does not know that the server is resuming using a ticket
> > unless it receives the ChangeCipherSpec message immediately
> > after the ServerHello. This is not true with regular session
> > resumption. The client knows the server is resuming by a
> > non-empty session id in the ServerHello. With regular session
> > resumption the client desn't have to look at what message
> > arrives next to determine if it is resuming. Because of this
> > when we implemented SessionTicket in our TLS implementation
> > we had to make the handshake state machine more complex. The
> > proposed change will allow us to somewhat simplify our state
> > machine implementation but it will still be less than ideal
> > in my opinion. Your proposed change only indicates if a new
> > ticket will be issued, not whether the server will resume or
> > not. I would prefer that the ServerHello contain something to
> > clearly indicate that the server is resuming using the
> > SessionTicket. This could be done by adding an extension to
> > the ServerHello and have the extension contain some flags
> > that indicate if the session will be resumed and if a new
> > ticket will be issued. Note: this might not be permitted in
> > RFC3546 because I think it says that the extensions in the
> > ServerHello should be empty.  
> >
> > As I have stated previously on this list I do not like the
> > DTLS draft because of how it handles the ChangeCipherSpec
> > message. In DTLS only handshake messages have a message
> > sequence number (MSN). The MSN allows the DTLS record layer
> > to determine if handshake messages have been lost and their
> > correct order. However, the ChangeCipherSpec does not have an
> > MSN. Since the CCS always preceeds the Finished message we
> > can only determine it's correct position by decrypting the
> > Finished message. Decrypting the Finished message requires
> > that the handshake layer has already derived the read/write
> > keys from the master secret. If the ChangeCipherSpec message
> > had an MSN then determining it's position in relation to
> > handshake messages would be trivial and would not require
> > decrypting the Finished message.  It is interesting to note
> > that the co-author of the DTLS draft wrote the openssl
> > implementation of DTLS and incorrectly coded the
> > ChangeCipherSpec message to contain an MSN. I will be
> > interested in seeing how he resolves this problem in openssl
> > because it caused me some headaches in our own DTLS implementation.
> >
> > In a normal DTLS handshake, when the client receives the
> > ServerHello with a session id it knows the server is
> > resuming, retrieves the saved session state and generates the
> > read/write keys from the master secret. It is then possible
> > to decrypt the Finished message when it arrives and find out
> > the correct position of the CCS.
> >
> > In a SessionTicket DTLS handshake when the client receives
> > the ServerHello it doesn't know if the server is resuming
> > using the ticket. So what should it do? Should the client
> > always assume the ticket will be resumed and generate the
> > read/write keys from the master secret? If It does this and
> > the server then decides to instead do a full handshake then I
> > just wasted time generating the read/write keys. That's not
> > ideal in my opinion.
> >
> >  
> >
> > -----------------------------------------------
> > Robert Dugal
> > Member of Development Group
> > Certicom Corp.
> > EMAIL: rdugal@certicom.com
> > PHONE: (905) 501-3848
> > FAX  : (905) 507-4230
> > WEBSITE: www.certicom.com
> >
> > tls-bounces@lists.ietf.org wrote on 12/13/2005 12:07:58 PM:
> >
> > > Below are the sections from the tls ticket draft that
> > should fix the
> > > issue with DTLS.  The server is now required to send a
> > SessionTicket
> > > handshake extension if it is going to send a SessionTicket
> > handshake
> > > message.  Let me know if this looks OK.
> > >
> > > Thanks,
> > >
> > > Joe
> > >
> > > 3.2  SessionTicket TLS extension
> > >
> > >    The SessionTicket TLS extension is based on [I-D.ietf-tls-
> > >    rfc3546bis].  The format of the ticket is an opaque
> > structure used to
> > >    carry session specific state information.  This
> > extension may be sent
> > >    in the ClientHello and ServerHello.
> > >
> > >    If the client posses a ticket that it wants to use to resume a
> > >    session then it includes it in the SessionTicket extension in the
> > >    ClientHello.  If the client does not have a ticket and
> > it is prepared
> > >    to receive one in the SessionTicket handshake message
> > then it MUST
> > >    include a zero length ticket in the SessionTicket
> > extension.  If the
> > >    client is not prepared to receive a ticket in the SessionTicket
> > >    handshake message then it MUST NOT include a
> > SessionTicket extension
> > >    unless it is sending a non-empty ticket it received through some
> > >    other means from the server.
> > >
> > >    The server uses an zero length SessionTicket extension
> > to indicate to
> > >    the client that it will send a new session ticket using the
> > >    SessionTicket handshake message described in Section
> > 3.3.  The server
> > >    MUST send this extension in the ServerHello if the
> > server wishes to
> > >    issue a new ticket to the client using the SessionTicket
> > handshake
> > >    message.  The server MUST NOT send this extension if the
> > client does
> > >    not include a SessionTicket handshake message in the
> > client hello.
> > >
> > >    If the server fails to verify the ticket then it falls back to
> > >    performing a full handshake.  If the ticket is accepted
> > by the server
> > >    but the handshake fails the client SHOULD delete the ticket.
> > >
> > >    The SessionTicket extension has been assigned the number
> > TBD1.  The
> > >    format of the SessionTicket extension is given below.
> > >
> > >
> > > < skip ticket format definition >
> > >
> > >
> > > 3.3  SessionTicket handshake message
> > >
> > >    This message is sent by the server during the TLS
> > handshake before
> > >    the ChangeCipherSpec message.  This message MUST be sent if the
> > >    server included a SessionTicket extension in the
> > ServerHello.  This
> > >    message MUST NOT be sent if the server did not include a
> > >    SessionTicket extension in the ServerHello.  In the case
> > of a full
> > >    handshake, the server MUST verify the client's Finished message
> > >    before sending the ticket.  The client MUST NOT treat
> > the ticket as
> > >    valid until it has verified the server's Finished
> > message.  If the
> > >    server determines that it does not want to include a
> > ticket after it
> > >    has included the SessionTicket extension in the
> > ServerHello then it
> > >    MAY send a zero length ticket in the SessionTicket
> > handshake message.
> > >
> > >    If the server successfully verifies the client's ticket
> > then it MAY
> > >    renew the ticket by including a SessionTicket handshake
> > message after
> > >    the ServerHello in the abbreviated handshake.  The client should
> > >    start using the new ticket as soon as possible after it
> > verifies the
> > >    Server's finished message for new connections.  Note
> > that since the
> > >    updated ticket is issued before the handshake completes it is
> > >    possible that the client may not put the new ticket into
> > use before
> > >    it initiates new connections.  The server MUST NOT
> > assume the client
> > >    actually received the updated ticket until it
> > successfully verifies
> > >    the client's Finished message.
> > >
> > >    The SessionTicket handshake message has been assigned the number
> > >    TBD2.  The definition of the SessionTicket handshake
> > message is given
> > >    below.
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > TLS@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/tls
> >
> >
--=_alternative 00453B76852570D8_=-- --===============0684240487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0684240487==-- From tls-bounces@lists.ietf.org Wed Dec 28 15:50:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriFJ-0000ui-Q9; Wed, 28 Dec 2005 15:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriFH-0000tA-Ln for tls@megatron.ietf.org; Wed, 28 Dec 2005 15:50:03 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08302 for ; Wed, 28 Dec 2005 15:48:53 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EriFG-0002aB-9x; Wed, 28 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Dec 2005 15:50:02 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-07.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-07.txt Pages : 14 Date : 2005-12-28 This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-openpgp-keys-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-openpgp-keys-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-28122525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-28122525.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Thu Dec 29 06:19:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvoS-00038I-3l; Thu, 29 Dec 2005 06:19:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvoP-000386-DE for tls@megatron.ietf.org; Thu, 29 Dec 2005 06:19:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08817 for ; Thu, 29 Dec 2005 06:18:02 -0500 (EST) Received: from uproxy.gmail.com ([66.249.92.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErvsZ-0007xY-PI for tls@ietf.org; Thu, 29 Dec 2005 06:23:36 -0500 Received: by uproxy.gmail.com with SMTP id o2so588259uge for ; Thu, 29 Dec 2005 03:19:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-disposition:message-id:content-type:content-transfer-encoding:sender; b=Y+nQ+GNMAj7N5WVignGgiYRy0tDyUGNTKLPX7Ydt1x1GYIYhUr/VEa2QirdA0hmHZezwvX51GaXLQW94hkjLhnT5rrsq8iRVxFLkXUPWumDi+3BCza79fWP8ZrLuCshAjQOJOn+5syGHIbLdDJnKkkhql5UEvajLUyUKOmbgahc= Received: by 10.66.218.1 with SMTP id q1mr2430793ugg; Thu, 29 Dec 2005 03:19:07 -0800 (PST) Received: from turtle.i-net.gr ( [62.38.143.171]) by mx.gmail.com with ESMTP id k30sm5164465ugc.2005.12.29.03.19.04; Thu, 29 Dec 2005 03:19:06 -0800 (PST) From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Thu, 29 Dec 2005 12:18:44 +0100 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200512291218.44990.nmav@gnutls.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [TLS] draft-ietf-tls-openpgp-keys-07 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hello, A day before I've posted the updated draft-ietf-tls-openpgp-keys. It is a paper that describe a way to negotiate other certificate types, and in particular, the openpgp certificates. It uses the TLS extension mechanism [0]. The latest draft removes all redundant ciphersuites that were defined in previous versions of the document and only includes the required changes for the certificate negotiation. This draft is currently only implemented in the gnutls [1] library. Except for any other comments on this draft, I'd like to know the reactions of the working group and the chair on moving to an informational rfc. regards, Nikos Mavrogiannopoulos [0]. and arbitrarily uses the extension number 7. [1]. www.gnutls.org _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 30 03:51:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsFzS-0001n5-Uw; Fri, 30 Dec 2005 03:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsFzR-0001ke-5a for tls@megatron.ietf.org; Fri, 30 Dec 2005 03:51:57 -0500 Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19982 for ; Fri, 30 Dec 2005 03:50:43 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00GMUZGDG5@szxga03-in.huawei.com> for tls@lists.ietf.org; Fri, 30 Dec 2005 16:55:25 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA007NMZGBNI@szxga03-in.huawei.com> for tls@lists.ietf.org; Fri, 30 Dec 2005 16:55:24 +0800 (CST) Received: from [10.18.18.211] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA00JK3ZU6Y7@szxml01-in.huawei.com> for tls@lists.ietf.org; Fri, 30 Dec 2005 17:03:43 +0800 (CST) Date: Fri, 30 Dec 2005 14:19:19 +0530 From: jimmy To: tls@ietf.org Message-id: <43B4F48F.9000009@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.4.1 (Windows/20051006) Content-Transfer-Encoding: 7BIT Cc: Subject: [TLS] regarding precedence of application data over other data X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, The note about application precedence states that: "Note: Data of different TLS Record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types and therefore handshake records may be held if application data is pending. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection." This was in draft 8, but in draft 9 onwards it's higher precedence for application data. But section 7.4.1.1 has "Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a hello request but does not receive a client hello in response, it may close the connection with a fatal alert." What exactly is the precedence of application data? and why was it changed from lower to higher precedence from draft 9 onwards? On searching the archives i found a post from Eric dated 15 Dec 2004 about the same thing, but he restated the note in his mail as "application data has lower precedence.." and called the other a thinko. A clarification would be greatly appreciated. Thanks in advance, jimmy _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls