Re: [TLS] TLS 1.3 wishlist

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 07 December 2013 11:06 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 619131AE2CE for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 03:06:16 -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 qrsJOR0qMgcF for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 03:06:15 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDA1AE2D4 for <tls@ietf.org>; Sat, 7 Dec 2013 03:06:14 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id w62so1659429wes.21 for <tls@ietf.org>; Sat, 07 Dec 2013 03:06:10 -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=76YQDa11lpeupgm2pZ72yHx3tlmSlTiHrNXGC/IlQoY=; b=TfT821kDolBJhZ6BxZrwA9xvRvOkb9KEDpflU8ZT+HcFC9IS+qtr4Sgrjzp8MwLFDk zvKdLA7XcEG861cHYlONX2tmc4RMskXzt2wocTqkwLwFl6xwvkR1dx02CRlVUrqkHG7T kEfhQ34FfQvGx9PD45Us3LlwRQxVkwvu4wskIi7tb3LMeev7Dh/SX/hhweSierngeXob DJ83HpWtIHzx9VCx/qY8rm/8CVCZGhZUDECjwTMRM5n1xVOfXFHwSa6LM41RI3xyve+M qIcpFqh7FhZt687TYwPsbGwYTBfQCI7GEsdcAxePAWHPHk7t4XGq+2h9axQYb0tPJo1R IWMw==
X-Received: by 10.180.91.11 with SMTP id ca11mr6454651wib.39.1386414370437; Sat, 07 Dec 2013 03:06:10 -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 fj8sm3496109wib.1.2013.12.07.03.06.09 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 03:06:10 -0800 (PST)
Message-ID: <52A3011A.8070903@gmail.com>
Date: Sat, 07 Dec 2013 12:06:02 +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>, Michael D'Errico <mike-list@pobox.com>
References: <5239F4C9.5090805@pobox.com> <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
In-Reply-To: <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 08 Dec 2013 19:42:32 -0800
Cc: TLS Mailing List <tls@ietf.org>, public-webid WebID Group <public-webid@w3.org>
Subject: Re: [TLS] TLS 1.3 wishlist
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 11:06:16 -0000

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

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".

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.

Cheers,
Anders

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