Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted

Adam Langley <agl@google.com> Thu, 18 February 2010 16:53 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDB23A7FB7 for <tls@core3.amsl.com>; Thu, 18 Feb 2010 08:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.834
X-Spam-Level:
X-Spam-Status: No, score=-104.834 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUe1Oea0rujc for <tls@core3.amsl.com>; Thu, 18 Feb 2010 08:53:40 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C1C703A7FBC for <tls@ietf.org>; Thu, 18 Feb 2010 08:53:39 -0800 (PST)
Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id o1IGtL6L014490 for <tls@ietf.org>; Thu, 18 Feb 2010 08:55:22 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266512122; bh=9WnIt3OtqJbZlhAWA+er4/gbyfw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=IQI17yEcRk0n2TR2BYP2ihC6IQxbOY1CT/ElJkoJfX9y9ggc0iV5p+zVYwRgWLnsS /5jtskDBOaqDb/k1/WOzw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=E2Y475Y1ZOrs0JWP2MfwN+/B8M6qq4Qeg5018k5HOVjivG5TIXIkp92pYMXhYhI20 8VsIyFu22D6bdGBjl+8eQ==
Received: from pzk14 (pzk14.prod.google.com [10.243.19.142]) by spaceape12.eur.corp.google.com with ESMTP id o1IGtJmk003836 for <tls@ietf.org>; Thu, 18 Feb 2010 08:55:20 -0800
Received: by pzk14 with SMTP id 14so10012312pzk.3 for <tls@ietf.org>; Thu, 18 Feb 2010 08:55:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.4.12 with SMTP id 12mr6568361wfd.138.1266512119149; Thu, 18 Feb 2010 08:55:19 -0800 (PST)
In-Reply-To: <a84d7bc61002180831n412afe3aubffd4708a02b1dd3@mail.gmail.com>
References: <C7A2FC2B.85D4%stefan@aaa-sec.com> <C7A30236.85DC%stefan@aaa-sec.com> <a84d7bc61002180831n412afe3aubffd4708a02b1dd3@mail.gmail.com>
Date: Thu, 18 Feb 2010 11:55:18 -0500
Message-ID: <a84d7bc61002180855k42ac03b8m8eae0a4596f7be03@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2010 16:53:40 -0000

On Thu, Feb 18, 2010 at 11:31 AM, Adam Langley <agl@google.com>; wrote:
> 1) makes the extension symmetrical and it seems like there might be
> something in the future that the server would like to predict from the
> client. At the moment we suggest that the server might want to support
> predicting the client's certificate. Often a CertificateRequest
> handshake is a renegotiation and a higher level knows what certificate
> the client should be presenting.

wtc pointed out to me that this might be unclear. The situation that I
have in mind is this:

A user is using HTTPS to navigate a web site and reaches a point where
they need to authenticate. They enter their username in a text field
and hit "Login using certificate". This triggers a renegotiation with
a CertificateRequest and, at this point, the server knows the
certificate that the client should be presenting. The client could
even use this to guide the user in the selection of the certificate.

People might feel that this is a little contrived and I wouldn't mind
in the slightest if it was dropped. But it seems simpler that the
extension should be symmetrical and odd to assume that we'll never
need to predict anything from the client.


Cheers

AGL