[TLS] comments & clarifications for rfc4507bis

"Nagendra Modadugu" <ngm+ietf@google.com> Thu, 04 October 2007 20:22 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXDZ-0002Pm-Bo; Thu, 04 Oct 2007 16:22:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdXDY-0002E2-65 for tls@ietf.org; Thu, 04 Oct 2007 16:22:44 -0400
Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdXDH-0006dq-NU for tls@ietf.org; Thu, 04 Oct 2007 16:22:34 -0400
Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id l94KLmbK032477 for <tls@ietf.org>; Thu, 4 Oct 2007 21:21:49 +0100
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:sender:to:subject: in-reply-to:mime-version:content-type: content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UAIkUVv8IwKRsccckdY1Oc8ZyNICd6A3z5TJM5Bs1EkZE3A29qS+ZIdpgb4Slqd6x l04fZUbuxckCaTJHQAfcA==
Received: from nf-out-0910.google.com (nfdc10.prod.google.com [10.48.130.10]) by zps19.corp.google.com with ESMTP id l94KLZaq023054 for <tls@ietf.org>; Thu, 4 Oct 2007 13:21:47 -0700
Received: by nf-out-0910.google.com with SMTP id c10so232630nfd for <tls@ietf.org>; Thu, 04 Oct 2007 13:21:47 -0700 (PDT)
Received: by 10.86.57.9 with SMTP id f9mr1822257fga.1191529306726; Thu, 04 Oct 2007 13:21:46 -0700 (PDT)
Received: by 10.86.73.14 with HTTP; Thu, 4 Oct 2007 13:21:46 -0700 (PDT)
Message-ID: <28425e380710041321w3eb15158o5ba9d2e2157e6766@mail.gmail.com>
Date: Thu, 04 Oct 2007 13:21:46 -0700
From: Nagendra Modadugu <ngm+ietf@google.com>
To: tls@ietf.org
In-Reply-To: <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <28425e380710031503x4c26b1b1r97b9f18fa8892787@mail.gmail.com> <28425e380710031543i28a1274bl6cf25fd270ed3c2d@mail.gmail.com> <28425e380710041156s2a9e3c32vee0d1d612381daaa@mail.gmail.com>
X-Google-Sender-Auth: 059df9aaabd40818
X-Spam-Score: -4.3 (----)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc:
Subject: [TLS] comments & clarifications for rfc4507bis
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

A few more comments:

S3.1: The client caches this ticket along with the master secret and
      other parameters associated with the current session.  When the client
      wishes to resume the session, it includes the ticket in the
      SessionTicket extension within the ClientHello message.

The text is not clear what "includes the ticket" refers to.  It could
either mean the entire NewSessionTicket message, or just
NewSessionTicket.ticket.  The client does not need to echo back
NewSessionTicket.ticket_lifetime_hint, so it is not obvious which of
the two meanings is implied.  The description would be unabiguous if
the text included a struct along the lines of:

  struct {
    opaque NewSessionTicket.ticket<1..2^16-1>
  } SessionTicket;


S4:
      enum {
         anonymous(0),
         certificate_based(1),
         psk(2),
+       (255)
     } ClientAuthenticationType;

On 10/3/07, Nagendra Modadugu <ngm+ietf@google.com> wrote:
> Apologies if the points below have been previously addressed.  The
> comments below are in reference to the version of the draft dated
> August 27, 2007.
>
> S3.3: The server MUST NOT assume that the client actually received the updated
>       ticket until it successfully verifies the client's Finished
>       message.
>
> This text seems incorrect.  The full-handshake case is actually a bit
> awkward, since the server cannot assume that the ticket has been
> received (by the client) until application data is received from the client.
>
> S3.4: 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.
>
> Why are servers afforded the flexibility of simultaneously including an
> extension and session ID?  Or differently put, why should a server ever
> need to generate a session ID if it intends to do stateless resumes?
> (Session IDs generated by the server will be discarded by the client in
> any case.)
>
> S3.4: In this case, the client ignores the Session ID sent in
>       the ServerHello ...
>
> "the Session ID" -> "the Session ID (whether empty or non-empty)"
>
> S3.4: 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 from when it is falling back to a
>       full handshake.
>
> What if the server rejects the ticket in this case?  It seems
> reasonable that the server responds with an empty session ID to
> indicate to the client that a full-handshake is being initiated.
>
> Thanks,
> nagendra
>

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