Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

Yaron Sheffer <> Tue, 18 July 2017 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FF53131803; Tue, 18 Jul 2017 14:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 88G8vUS7muUh; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A99712EC23; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
Received: by with SMTP id 12so46664547wrb.1; Tue, 18 Jul 2017 14:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=SEfm4AnFh5uvikYToVE7bCgWp4QpwSujpNXn8tDVavU=; b=c+0W5RUy/V7SOwv5nZ7wdiSeviDo74WuTrzPp28Pvv2sX6XIMjnxvXTDwlnyUy+TL3 KDiT+bXmYDBK6YpB3ZSD3u9mjmGqP0pE2ESzGYe/8BJNBseR/jnI6HtwrggUb8CNMlje 1oIwmzVj4hh9gcB67rKDcjSzX+NMryJ7Nik1BqHVDHMOLZRhLRL64ntXmjLAeosJO50t vDnkas+2ZxPlwd1d5AvphjPnbVmkHFpYvhce8cBPZceLdYLBkb9IjkbSpz5m2XI1LPi8 PIZDdqCstVY9XpOqDtyNgXbd9BYcM690g5zzwJX7m/XfbEgJBi1Cvl8LbMR8jiYwv22r RTjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=SEfm4AnFh5uvikYToVE7bCgWp4QpwSujpNXn8tDVavU=; b=hVxAB52NN26IFrFPwugowem9iOJEzck0OFRtrJMkNuauDQ3xRQYda6BbAK4eqw0t3k SW+9uqV3CPr2+Csy1chjBSjy1S4BuqUlAuXmJeYFt7tCSGrOPbHVNWH68JiwiIuaeI+q 6iGuPyM0nZCaI8CrO8VEoksbY6WrM1b1ofUy3v1C6p3OrMWY0B43zLvLHHAOHGH/Xgiw +rMDkRXEIjjEtT9lmw5QCWd+4MFREnWQ1GEN1JCIlDwz9ux2t5Xt5SpFGe5iM+UpWcoQ tt+RMKof7LIG3F+Nqd9sSUW1M8zoF3HcssB2M/mZYSuQl2xqW2Sa/E9s+OEdOs+B1ZMW qsdA==
X-Gm-Message-State: AIVw113YG2b99dWr4j0InC2q+5Ocn6pD3giL+E7I05wN+SyS4MLtTs7D kPdm1gWTPUsNp7qkxBo=
X-Received: by with SMTP id c10mr670697wrb.164.1500411996487; Tue, 18 Jul 2017 14:06:36 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id q2sm19585275wmg.3.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jul 2017 14:06:36 -0700 (PDT)
To: Watson Ladd <>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <>
Cc: LURK BoF <>,
References: <> <> <> <> <> <> <>
From: Yaron Sheffer <>
Message-ID: <>
Date: Tue, 18 Jul 2017 23:06:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Lurk] [TLS] WG Call for adoption of draft-rescorla-tls-subcerts
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 21:06:46 -0000

On 18/07/17 18:34, Watson Ladd wrote:
>     I understand the logics but, since LURK boxes don’t scale, the
>     cost to cover your entire footprint for the sporadic cases when
>     the CA is down might be a bit prohibitive.
> CA reliability is not good.
 From my own experience, I agree that CA reliability is "not good". 
However if I'm using short-term certs with say, a 7 day validity, and 
(per draft-ietf-acme-star) the next certificate is issued halfway 
through this period, it means that the CA has to to be unavailable for 
all of 3.5 days for the failure to affect the delegated site. That's a 
lot, even for a CA.

On the other hand the LURK signing box (though managed by the same 
organization, which is a clear benefit) needs to be available at the 
same level of the delegated site - 99.99% of the time or whatever your 
standard is.