Re: [TLS] security considerations for draft-rescorla-tls-subcerts

Simon Friedberger <simon.tls@a-oben.org> Wed, 05 April 2017 21:52 UTC

Return-Path: <simon.tls@a-oben.org>
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 0C11E1294B9 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 14:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DppLa_Jc_s06 for <tls@ietfa.amsl.com>; Wed, 5 Apr 2017 14:52:30 -0700 (PDT)
Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DEB1294A2 for <tls@ietf.org>; Wed, 5 Apr 2017 14:52:28 -0700 (PDT)
Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <simon.tls@a-oben.org>) id 1cvsqZ-0007jG-PP for tls@ietf.org; Wed, 05 Apr 2017 23:52:26 +0200
To: "tls@ietf.org" <tls@ietf.org>
References: <m27f362zxm.fsf@dhcp-89ad.meeting.ietf.org> <MWHPR15MB1455F0758BE196CAB4BDF8BDB6360@MWHPR15MB1455.namprd15.prod.outlook.com> <c5799647-4568-4cbf-1708-52934a961f67@akamai.com> <d93fe5c1-5236-f86c-34d0-2606204d672d@a-oben.org> <f4aeff835aa4437f8d2996cba926bc11@usma1ex-dag1mb1.msg.corp.akamai.com> <df23dab4-d8cd-7d7e-3372-1dfed4457d45@a-oben.org> <MWHPR15MB145571244E36DA811C5F6CDCB60A0@MWHPR15MB1455.namprd15.prod.outlook.com>
From: Simon Friedberger <simon.tls@a-oben.org>
Message-ID: <e88addbe-7ca2-5a7d-8a06-4d92d71c1bb2@a-oben.org>
Date: Wed, 05 Apr 2017 23:52:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <MWHPR15MB145571244E36DA811C5F6CDCB60A0@MWHPR15MB1455.namprd15.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1aQm4xxlUNVEsczfIfpImxI_yPk>
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts
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: Wed, 05 Apr 2017 21:52:32 -0000

On 05/04/17 18:07, Subodh Iyengar wrote:
>
> The threat model here is that since if a less-trusted host having a
> key is compromised for a certain period of time without detection, and
> an attacker can steal private keys during that period. In many
> situations we are fine with giving the TLS terminator a certificate /
> key, i.e. they actually have a trust relationship, however we want a
> compromise to only give the attacker a limited power to use the
> credential. Revocation is arguably effective, so we would not be okay
> with giving a less trusted host a long term private key. However we'd
> be okay with giving a less-trusted host a short term key.
>
Your argument hinges somewhat on the ineffectiveness of revocation but
I'm not sure how true that it is. Also, if it is shouldn't the fix be
applied there instead?

> >  To me the increase in security weighted with the difficulty of
> obtaining
> such short-lived certificates from a CA probably does not justify the
> extra
> complexity of adding subcerts.
>
>
> @Simon Friedberger Do you feel that short lived CA certificates are
> actually deployable in large server deployments? I do not see that to
> be the case. I see a security gain here but just being able to deploy
> short lived credentials to not only less trusted locations, but also
> to more trusted locations as well which is another use case that I
> want to use this for. 
>
You original mail seemed to imply that is doable but tedious and given
that some CAs seem to offer interfaces that can be automated it should
be possible for many servers but I am in no way an expert on the matter.

Considering however the very specific case that is required for a
security gain (undetected & temporary compromise & revocation
ineffective) it might still not be worth the increased complexity.
Also, take into account that a compromise that leaks certificates will
potentially put an adversary in a position to carry out whatever attack
he wants to perform directly without stealing the certificates.


But I'm not saying there is no security gain, I just wanted to point out
that it seems to me it's not worth any extra complexity.


Best,
Simon