IETF Logo Mail Archive

Re: [TLS] Summary of discussion regarding spontaneuous authentication

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 22 October 2014 13:06 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 3B2191A8AFE for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 06:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.747
X-Spam-Level:
X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, 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 ycIAyqlnh8lY for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 06:06:49 -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 BF1371A9119 for <tls@ietf.org>; Wed, 22 Oct 2014 06:06:36 -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=ouX0gqf9c/rrzoQ50IOeGeD1ZjcEWvRp6szfbF8jumg=; b=bdPR28G+85TI5ZRbU7yKIZ0LQ77BzWuhRFPuNe57jHnfrR+/zxJYYuxF+02h+IMdX2E8V5h7JPi+nsh4ZmWgl/9V3nIccSGGOGeFIRaZBDeCMc7e4KAnG8HZ6to6PA9lhju2JK5XppWmyErY1QNY8Ofk7U/Ckn0V1wrO7+FMkYU=;
Received: from guest-rocq-135165.inria.fr ([128.93.135.165]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XgvcU-00078x-3k; Wed, 22 Oct 2014 15:06:30 +0200
Message-ID: <5447ABD5.7020402@polarssl.org>
Date: Wed, 22 Oct 2014 15:06:29 +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: Tom Ritter <tom@ritter.vg>, Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnUAhEV=wLZyTew=ne7VgSq50XYR3Fo5EfjNXc8=_hbpyg@mail.gmail.com> <CABkgnnXAk+HU2yaUJdOQ0w-heHwYrPK6Zf3HrH5tU+2Tk7_cCA@mail.gmail.com> <CA+cU71=nWupBE12neJb_szY89K56T2OWs0ZWr5PoU-DpJ555iw@mail.gmail.com>
In-Reply-To: <CA+cU71=nWupBE12neJb_szY89K56T2OWs0ZWr5PoU-DpJ555iw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 128.93.135.165
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/sbT603b7jeU31HzUfV0SEg4PqjI
Cc: 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 13:06:50 -0000

On 22/10/2014 14:51, Tom Ritter wrote:
> On Oct 22, 2014 8:07 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>
>> I forgot one point that we discussed.
>>
>> We discussed the removal of the CertificateRequest and we will permit
>> the client to unilaterally send authentication.
> 
> Will permit it to be absent, or will remove CertificateRequest entirely?
> 
My understanding is it would be entirely removed.

>> The theory here is that clients tend to know whether they need to
>> authenticate.  Most uses of mutual authentication start with the
>> client knowing that they need to authenticate.
> 
> Well, the human knows he needs a client certificate for this website, the
> Browser does not unless it stores that information. (And still needs to
> learn it for first connect)
> 
> If CertificateRequest is being removed, it's not clear to me how a browser
> would know to include a client cert. An alert and reconnect?  (For other
> applications like VPNs, obviously much easier to solve.)
>
That would be moved to the application layer, eg for HTTP(bis) that would be
addressed by Martin's "cant" draft as he briefly mentioned:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

Manuel.

v2.27.6 | Report a Bug | By Email | System Status