Re: [TLS] draft-rescorla-tls-subcerts-01

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 21 April 2017 10:49 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A534126B71 for <tls@ietfa.amsl.com>; Fri, 21 Apr 2017 03:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 ToqtNZxOg9u1 for <tls@ietfa.amsl.com>; Fri, 21 Apr 2017 03:49:02 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 62343126D73 for <tls@ietf.org>; Fri, 21 Apr 2017 03:49:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 944382454C; Fri, 21 Apr 2017 13:48:59 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 8WgFhdjCEPTD; Fri, 21 Apr 2017 13:48:59 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5C377C4; Fri, 21 Apr 2017 13:48:59 +0300 (EEST)
Date: Fri, 21 Apr 2017 13:48:57 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20170421104857.GA20822@LK-Perkele-V2.elisa-laajakaista.fi>
References: <bea3cb60-fdfc-950f-f628-90eb87ed42ef@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <bea3cb60-fdfc-950f-f628-90eb87ed42ef@gmx.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GboqvtC9BcallwcnHwmLgF10Cvc>
Subject: Re: [TLS] draft-rescorla-tls-subcerts-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 21 Apr 2017 10:49:05 -0000

On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
> questions.
> 
> I have been wondering why the TLS server operator obtains an end-entity
> certificate from a CA (which cannot be used to sign further
> certificates) instead of running an intermediate CA him-/herself
> instead. This would work without requiring any changes to the client
> side. The proposed solution, although technically feasible, will
> unfortunately take a long time to deploy since it requires cooperation
> from clients, servers, and also from CAs.

There is enormous amount of red tape obtaining intermediates, even
technically constrained ones. And as consequence, it is enormously
expensive (through not nearly as expensive as public CA).

Defining new extensions is much more deployable, as slow as it is
(AFAICT, no BR changes needed).

Regarding clients, I think the draft specifies LURK as backup plan
for clients that don't support subcerts (which causes some extra
latency if triggered).

> What is also not clear to my why some of the certificate management
> protocols, which provide the necessary level of automation, cannot be
> used with CAs to request short-lived certificates.

AFAIK, that would cause issues with CT and OCSP signing.

The latter would be fixable by reintroducing CABForum ballot 153 and
passing it (the reasons 153 failed were obviously political instead of
technical).


-Ilari