IETF Logo Mail Archive

Re: [TLS] Summary of discussion regarding spontaneuous authentication

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 22 October 2014 20:32 UTC

Return-Path: <mpg@polarssl.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFDF1A1AF1 for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 13:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.397
X-Spam-Level:
X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzNINbi3-rCT for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 13:32:38 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5888B1A1ADC for <tls@ietf.org>; Wed, 22 Oct 2014 13:32:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=y/ao4IciSt7zCZpVMglosyhD4+1q9+lVH4yu6fzeFrE=; b=cAKYmCZ2rtlExrdx9zw/mPI1NkmHPG8u5b5dLEXWfOg0oycfoSTV4DjnVOZKRR2XpaTlTYBvG2pc1pZk+IgfZC7xfm1inV2chegVtlL15gSb+7lOkdTg5NBkSD5XLD6YAomuktfjwsjQcqlz/A63HcO2DWWQerRxbQbglckL9GM=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1Xh2a6-0007i0-44; Wed, 22 Oct 2014 22:32:30 +0200
Message-ID: <54481461.8060006@polarssl.org>
Date: Wed, 22 Oct 2014 22:32:33 +0200
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
References: <CABkgnnUAhEV=wLZyTew=ne7VgSq50XYR3Fo5EfjNXc8=_hbpyg@mail.gmail.com> <CABkgnnXAk+HU2yaUJdOQ0w-heHwYrPK6Zf3HrH5tU+2Tk7_cCA@mail.gmail.com> <20141022125359.GA18704@LK-Perkele-VII> <CABkgnnW=aVzsi+cq=icpn4z9PjFuoiu_LQz_mnfeyPPom6LROQ@mail.gmail.com> <20141022132623.GA19894@LK-Perkele-VII> <CABkgnnVe3T56ia-bxgqNrpF_vXQD=T7xisrZb0Szu+L1X05+NQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EV5aB2E8wbGLr1CfjbtobOcmv1Q
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Oct 2014 20:32:39 -0000

On 22/10/2014 17:59, Salz, Rich wrote:
>> I tend to think that we need a more general mechanism for indicating
>> support for certificate types and signature algorithms.  Maybe we could
>> unconditionally include those in the early handshake instead.
> 
> Yes.  In two years when MSFT and Google start deprecating SHA-2 for Keccak,
> it'd be nice to know which cert chain to send.  Or when I don't know whether
> to send an RSA or ECDSA certificate next year.
> 
But you're on the server side, aren't you? There are indeed many reasons (RSA vs
ECDSA, SHA-x vs SHA-y) why a server wants to have many valid certs and pick one
based on what the client supports.

I'm not sure I can imagine so many plausible scenarios where the *client* has
many certs bound to the same identity and would need to pick one based on what
the server supports. Most of the time, the client cert will have been issued by
the same entity that runs the server, anyway.

Manuel.

v2.23.0 | Report a Bug | By Email