Re: [TLS] Review of PR #209

Martin Thomson <> Tue, 15 September 2015 23:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 89C731B29D1 for <>; Tue, 15 Sep 2015 16:53:12 -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 Y3JyZiQQjqcN for <>; Tue, 15 Sep 2015 16:53:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F9A11B29D0 for <>; Tue, 15 Sep 2015 16:53:11 -0700 (PDT)
Received: by ykft14 with SMTP id t14so51198356ykf.0 for <>; Tue, 15 Sep 2015 16:53:10 -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=wo3gpVqfXrwmjL9IQjZe8/cmzY3Iyg1zCbMPcyFeZTY=; b=p+fF3uk7VtKT1VtT6RRMZoFNI4KlPwxE/2CGWx7VsL/ts277Ob2L3Rg32k5gFqNDKl 6/f8eq0jZefoYb/wveHxE23uotTKVF2zmGeoNxlL+s7lQFjORQfZbUVrNus4qQu/BBBr hu/XxNGEsQjUwUkuqS2Qb0G0Vbd6TC3lwvi4uAIug1lwa9ZF3LxpwQcaunDfPHvsAmI8 +B6YQyRTw2k1LhhkaLoKc54SFQ/4osFQjPMearDS+mZI1cO3AsZx6ke22jKQEBIeyi33 11Xe984KpTLHOJXRN1BHaBZIV+DL13bgwz+jli+E7UPx/G8Lj/Bc4FwFZg1yaaUDtLMo vuHg==
MIME-Version: 1.0
X-Received: by with SMTP id u5mr22821569ywd.154.1442361190376; Tue, 15 Sep 2015 16:53:10 -0700 (PDT)
Received: by with HTTP; Tue, 15 Sep 2015 16:53:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 15 Sep 2015 16:53:10 -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 23:53:12 -0000

On 15 September 2015 at 16:19, Andrei Popov <> wrote:
>> I'm concerned that this produces an indeterminate state on the server.
>> 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?
> Traditionally, it was not an error for the client to send an empty Certificate message, or to offer a credential that does not match the parameters in the CertificateRequest. From the server's perspective, it doesn't matter what went wrong: the server treats the client as unauthenticated in this case (and possibly alerts/disconnects).

Right, but not all applications work on that model.  Some make the
request and block on a response.

> Because we want to allow the client to volunteer a certificate, there can be a situation where the server sends a CertificateRequest and receives an unsolicited client cert before the client can respond to CertificateRequest. We can add a flag to the client Certificate message to distinguish unsolicited creds from requested ones. Would this address the concern?

That would work.

>> That doesn't work for clients that send credentials without prompting.
> Not sure what you mean, can you elaborate on the scenario?

Client connects to server and completes the handshake.
Client sends certificate immediately after Finished.
Server sends NewSessionTicket after seeing Finished or
CertificateVerify; client is unable to tell which.
Later, Client resumes using the ticket.

The client is now uncertain about whether the server has remembered
their certificate.  That's bad if there are actions that might be
denied to the client in the absence of the certificate.

You could say that the easiest remedy is to offer the certificate
again, because that removes the uncertainty.  But a major reason for
having resumption is to avoid the public key operations on both peers,
so that's not a great solution.

This isn't a problem with TLS <=1.2, because there is no client
authentication without prompting, but that doesn't mean that someone
couldn't build a system that offers different content in response to
client authentication AND that system could have TLS 1.3 clients
authenticate without prompting in order to get that different content.
After all, asking has consequences that you might want to avoid, like
the "pick a certificate" dialog in browsers.  (Maybe you only need
this behavior for bespoke clients.)