Re: [TLS] TLS 1.3 wishlist - better certificate selection

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 07 December 2013 12:30 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 83CDF1AE2F4 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 04:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_25=0.6, 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 LnnVRDSca6NI for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 04:29:59 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 674A71ADF4E for <tls@ietf.org>; Sat, 7 Dec 2013 04:29:59 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hn9so1936800wib.13 for <tls@ietf.org>; Sat, 07 Dec 2013 04:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mtH+oG8apWd9b+sPafCDIDnDyYBgi8rpvJjucMoMjcs=; b=0HsM334ip28JP1/oD3DcQuuZQ3jrtOqbzPLnTWvyQ2H9ZTecTAgYFQB76ZDbxJo9bj zDyeZCO+IzWFpbNy9JaHAGGCxxi+JXzWjfN9kO1amlsH0nUYWVcOFNN4Eh4pynnVQOZB HXmO6jN/HTsH5ERIEXc973Lk4zNXKfZ3nn3TVyAdt3aVpPiEkXxefsMuRvJTbwyOKqZv uSRdHRtUITTlg4tstSgt/B8V9LVeBKu3o7670tHcL9lDI4Cx8nl2wQbhK6y9utt9zPvs DdqfjeBdIttRp8LX/wiRHrvVYIwmTzjVnyhxrGN6+YRmDRj5YegQ1y3ESsROGMBJlbQl luEQ==
X-Received: by 10.180.74.45 with SMTP id q13mr6631877wiv.47.1386419394818; Sat, 07 Dec 2013 04:29:54 -0800 (PST)
Received: from [192.168.1.99] (33.50.125.78.rev.sfr.net. [78.125.50.33]) by mx.google.com with ESMTPSA id hv5sm5053739wib.2.2013.12.07.04.29.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 04:29:54 -0800 (PST)
Message-ID: <52A314BA.4070005@gmail.com>
Date: Sat, 07 Dec 2013 13:29:46 +0100
From: Anders Rundgren <anders.rundgren.net@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Henry Story <henry.story@bblfish.net>
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net> <52A301C5.50608@gmail.com> <C5C630A5-4E23-4E50-BA93-1326C1E8993E@bblfish.net>
In-Reply-To: <C5C630A5-4E23-4E50-BA93-1326C1E8993E@bblfish.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 wishlist - better certificate selection
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: Sat, 07 Dec 2013 12:30:01 -0000

On 2013-12-07 13:11, Henry Story wrote:
> 
> On 7 Dec 2013, at 12:08, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
>> On 2013-12-07 11:15, Henry Story wrote:
>>>
>>> On 18 Sep 2013, at 20:45, Michael D'Errico <mike-list@pobox.com> wrote:
>>>
>>>> A "wish list" for an upcoming new version of TLS is available
>>>> online (I found it via a message on Twitter):
>>>>
>>>> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
>>>>
>>>> Is it appropriate to discuss this now, prior to rechartering?
>>>
>>> Hi,
>>>
>>>  One thing that would be nice would be some way of having more flexibility
>>> for the server to request a client certificate. In TLS 1.2 it seems
>>> the only way to do this is to use the certificate_authorities
>>> list. 
>>>
>>>  With WebID over TLS [1] a server may in fact be satisfied if the 
>>> Client certificate contains a WebID in the Subject Alternative Name.
>>> But this then leaves the question open as to how the server can transmit
>>> to the client it's ability to accept such certificates.
>>>
>>> The only solution currently available that I know of 
>>> would be to create a CA with DN such as
>>>
>>>   CN=WebID, O={}
>>>
>>> that every WebID enabled certificate would claim it is signed by (somewhere
>>> in the certificte chain)
>>>
>>> Then this could be passed by the server in the certificate_authorities
>>> list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6
>>>
>>>
>>> Some people are worried that this would require CAs to resign their root
>>> CAs with a WebID certificate in case they wanted to release WebID 
>>> certificates.
>>>
>>> Is there a better way to do this currently? Could there be a better 
>>> way to do it?
>>
>> I believe we had this discussion before, so here we go again :-)
>> Making TLS CCA (Client Certificate Authentication) useful for consumer authentication (be it to an enterprise, bank or social network), is IMO unrealistic, no matter how desirable it may be.
>>
>> Technical reasons:
>> http://webpki.org/papers/PKI/webauth.pdf#page=1
> 
> This thread is not about your ideas of what is wrong with TLS and
> why you think it can never be solved, but what can be done to improve
> one particular aspect that concerns me.

Well, the issue you bring up is pretty much related to TLS.

> 
> Btw. your article mixes up User Interface issues which can be sorted by 
> browser vendors UI team with protocol issues which I want to discuss here.
> ( Eg: logging out would be easy if the browser showed the client certificate
> used when logged in ).

There's no logout in TLS CCA.

Currently you need a separate non-standard IDP-like thing + browser-specific logout-junk
to "emulate" what any password-using site can do using out-of-the-box solutions.

Tomcat doesn't even permit unknown CAs like required by WebID.

Note it is not WebID that's bad, it is TLS CCA.

> 
> 
>>
>> TLS CCA is also at odds with the market:
>> http://www.forbes.com/sites/amadoudiallo/2013/11/30/google-wants-to-make-your-passwords-obsolete
>>
>> As an authentication solution for VPNs (and even more "secure box-2-box" communication), TLS CCA is great but that's not "le web".
> 
> WebID allows you to use X509 Certs for global authentication without needing to 
> pass through CAs. We are using this every day and building some very cool apps on it. 
> 
>>
>> Regarding the specific WebID issue, I would be cautious about assigning additional semantics to existing constructs.
>> X.509 offers many other ways of signalling a unique/non-standard use.
> 
> Thanks for this one paragraph that is somewhat closer to being relevant to this thread.
> 
> So clearly if one could have a better way for the server to notify the client which
> certificates it accepts, this would allow selection on other fields of the certificates.
> Perhaps something like a regexpression in the certificate_authorities list, or a
> way to express capabilities of certificates.

IMO the best would rather be to nuke TLS CCA as the foundation for WebID.  It is
much_ simpler (note, I didn't say simple...) establishing something based on app-level security.
With WebCrypto you have it today.  With U2F it gets ubiquitous.

TLS 1.3 is as all other versions only about security enhancements.

Cheers
Anders

> 
> 
>>
>> Cheers,
>> Anders
>>
>>>
>>>
>>> Henry
>>>
>>>
>>> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
> 
> Social Web Architect
> http://bblfish.net/
>