Re: [TLS] Review of PR #209

Martin Thomson <> Tue, 15 September 2015 22:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B550B1B2C50 for <>; Tue, 15 Sep 2015 15:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JzOdgRA7ozgy for <>; Tue, 15 Sep 2015 15:26:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 284F51B2C37 for <>; Tue, 15 Sep 2015 15:26:00 -0700 (PDT)
Received: by ykdt18 with SMTP id t18so181053979ykd.3 for <>; Tue, 15 Sep 2015 15:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ole6IQsVTM1ahUf3RI65WB5YO5BjJp0XPSx65jS9UDI=; b=YxP6TO7ooN+PNnormkwpUM9RahkPg2rwrI1Fn02pH43Le/s4J5Pqzys3jVFG/br2ft reY4e2H01F9bu6Laxs8nKP778I02ho3Qn4+sr4mRBpW1HJFUafLCTFPQGaY0z6JomTN9 8VLcAJz/VaV5R9UfnPNrCoPT2Fr8uIqUJ9nBsFWHGvSk6lJnj/Q5G/O/wbgla26yWGfs VFVw51cLqkXBIOvNG1fPL8BJD3KXpdHP3Pt5j2oY3EjG3w4vFR+iEK61FT9ZlyATXqcf wBOnu5FNKXZ81+7z23jyzFBFDTr8U9ZRuh5DvACAt9wk15i9oIco76Yx0icqzyhWK4uP M9Ng==
MIME-Version: 1.0
X-Received: by with SMTP id p1mr24302666ykd.101.1442355959445; Tue, 15 Sep 2015 15:25:59 -0700 (PDT)
Received: by with HTTP; Tue, 15 Sep 2015 15:25:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 15 Sep 2015 15:25:59 -0700
Message-ID: <>
From: Martin Thomson <>
To: Andrei Popov <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Review of PR #209
X-Mailman-Version: 2.1.15
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: <>, <>
X-List-Received-Date: Tue, 15 Sep 2015 22:26:01 -0000

On 15 September 2015 at 15:03, Andrei Popov <> wrote:
>> That is, how does the server identify whether this is unilateral or in response to its own request?
> The model I'm thinking of is where the server receives a request from the client, determines that the request requires authentication, then queries session state to see whether a suitable client credential is available.
> If such client credential is not available, the server sends CertificateRequest. In this model, it does not matter whether the client volunteered a credential or responded to the server's request.

I'm concerned that this produces an indeterminate state on the server.
Say that the server receives a Certificate after it sends
CertificateRequest.  What if that Certificate doesn't conform to the
request in some way: was the Certificate just a unilateral offer that
was sent before the client received the CertificateRequest, is the
client unable to understand the CertificateRequest, or is the client
in error?  Depending on which of these is really the case, the server
is unable to decide whether it should continue awaiting a Certificate
or not.

It's not a huge issue, but I'd be happier if we nailed this sort of thing down.

>> How does a client determine if the NewSessionTicket that it receives includes its authentication? That is, how can a client know whether a resumed session will need a certificate or not?  (I'm not sure about this one, but the first thought that occurs is that the server could include an indicator in the NewSessionTicket message.)
> I'd say the client should send the latest ticket it has, assume that it has all session context including client identity, and the server will request creds if this is not the case.

That doesn't work for clients that send credentials without prompting.

>> What value do you see in having a spontaneous NewSessionTicket messages?  Is this just a case of not wanting to bind it more formally to something that the client sends?
> The reason I want to allow NewSessionTicket messages in mid-stream is to allow the server to include newly obtained client creds in the session state. If the server wants to do this, it can send NewSessionTicket after processing the client's CertificateVerify.

Would you be OK with saying that NewSessionTicket can only be sent in
response to CertificateVerify or Finished?