Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 06 January 2019 23:03 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A52C13106C; Sun, 6 Jan 2019 15:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 B6sCqxB9Hup2; Sun, 6 Jan 2019 15:03:29 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C226613106A; Sun, 6 Jan 2019 15:03:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DCB4BE2C; Sun, 6 Jan 2019 23:03:26 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FggCw4yanHa; Sun, 6 Jan 2019 23:03:22 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04D01BE24; Sun, 6 Jan 2019 23:03:22 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1546815802; bh=fArfKToS+XSgywJNyb8T4hnEp5cxhZ6uA4FbjVDVs2k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=2UDNcc50l943DsWmqNG0ng/ciqH9xn/JbdXkl6HTJx2nUoYaX3IGgI+pFNCKawF6u 5suAQ/zvw9FmuPIvo0pU8nwxpTaGibqKbOvjnmBB8/ZOi9VDmS8z9NaibhfvBemZ49 TMvnUC9x42OlSVXYY62W0HJUSpQVrbYSf1Pmumtc=
To: Russ Housley <housley@vigilsec.com>, Joel Halpern <jmh@joelhalpern.com>
Cc: LAMPS WG <spasm@ietf.org>, IETF Gen-ART <gen-art@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF <ietf@ietf.org>
References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com> <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com> <F8CF4806-9C7D-47C2-8A0C-F588B287AA6D@vigilsec.com> <dc887c88-dd48-087d-0cf8-b7e08dbddf1e@joelhalpern.com> <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <4c0b5f67-d1f2-d888-0bd2-c1ff620abfc6@cs.tcd.ie>
Date: Sun, 6 Jan 2019 23:03:20 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <8CC5F804-13A9-4AA8-B15B-B99929E67F7E@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yCtIAcH41JGLfgiSt1gdL3mDiKV72GFuL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Y6gKI9VN4z24tFNNcKWbBE3tno4>
Subject: Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Jan 2019 23:03:32 -0000

Hi Russ,

I should probably re-read the draft after the latest changes
but ISTM that the crypto-break reason for problems here is
far far less likely than the mucked-up-HSM reason. I think
that means that calling out the more likely reason is perhaps
a better plan.

In addition, (and this is the bit I need to ponder), if the
lifetime of a root key associated with one of these hashes
(or commitments/pins) is say 10 years, then I'd say that may
make a HSM muck-up sufficiently likely that more than just
clarifying text might be needed. For example, perhaps one
might say that this extension SHOULD only be used if a new
key will go live within a couple of years or something like
that. As I said, I'll re-read the latest draft and see if
I can suggest some text. (Separately, if anyone has some
experience of the relative (in)stability of backup CA keys
over that kind of duration, then that'd be useful information.)

Cheers,
S.

On 06/01/2019 19:25, Russ Housley wrote:
> Joel:
> 
> I propose a replacement paragraph.  I hope it is more clear on the points raised on this thread:
> 
>    The Root CA needs to ensure that the public key in the next
>    generation certificate is as strong or stronger than the key that it
>    is replacing.  Of course, a significant advance in cryptoanalytic
>    capability can break the yet-to-be-deployed key pair.  Such advances
>    are rare and difficult to predict.  If such an advance occurs, the
>    Root CA remains committed to the now broken key.  This leaves the
>    Root CA with no alternative but to deploy a new self-signed
>    certificate that contains a newly-generated key pair, most likely
>    using a different signature algorithm, in the same manner as the
>    initial self-signed certificate, thus losing the benefits of the Hash
>    Of Root Key certificate extension altogether.
> 
> Let me know if this helps...
> 
> Russ
> 
> 
>> On Jan 6, 2019, at 12:27 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>
>> Maybe I am missing something simple, but I do not see where the text in section 5 on dealing with a lost promised key says anything about the need to "go through the process that was used to set up the initial trust anchor."  All it seems to say is "to deploy a new self-signed certificate."  Maybe what is needed is a little elaboration on what that deployment is to be, as it is not the same as deploying a properly promised new key pair.
>>
>> Yours,
>> Joel
>>
>> On 1/6/19 12:09 PM, Russ Housley wrote:
>>> Joel:
>>> As the text already says, the Root CA will need to go through the process that was used to set up the initial trust anchor.  The relying party will not accept the new self-signed certificate until that is done, and that process is completely disconnected from the previous certificate.
>>> The paragraph we are discussing is all about handling a failure, and the new certificate extension is not offering any assistance if the failure occurs.  That is what the paragraph is trying to say.
>>> Russ
>>>> On Jan 4, 2019, at 10:10 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>>
>>>> I understand that the issuer has no choice.
>>>> What I can't see is how any validator will accept the new certificate.
>>>> The new cert will fail the validation check required by the field in the existing certificate.
>>>> So it seems that the only remedy is to wait until the exist certificate expires, so that the hash is no longer valid, and then a new cleann cert can be issued that will be accepted.
>>>>
>>>> But there is no reference in the "remedy" to waiting for the expiration.
>>>> In fact, it is only imiplictly stated that the hash expectation is no longer valid once the certificate is expired.
>>>>
>>>> Another possibility is that I am completely missing the point of the new field.  If the new clean unexpected cert will be accepted, what behavior is improved by having the hash in the current cert.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 1/4/19 9:41 PM, Russ Housley wrote:
>>>>> Joel:
>>>>> If access to the key is lost, the commitment is broken, so the Root CA must make a fresh start using a completely unrelated key.  Maybe the word "remedy" is creating the wrong impression for you.
>>>>> Russ
>>>>>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com> wrote:
>>>>>>
>>>>>> If the new self-signed cert uses a new key, wouldn't that be rejected as violating the promise in the current cert?  I am missing something.
>>>>>>
>>>>>> Thanks,
>>>>>> Joel
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>>>>>
>>>>>> -------- Original message --------
>>>>>> From: Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>
>>>>>> Date: 1/4/19 17:57 (GMT-05:00)
>>>>>> To: Joel Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>>>>>> Cc: IETF Gen-ART <gen-art@ietf.org <mailto:gen-art@ietf.org>>, spasm@ietf.org <mailto:spasm@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org <mailto:draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org>, IETF <ietf@ietf.org <mailto:ietf@ietf.org>>
>>>>>> Subject: Re: Genart last call review of   draft-ietf-lamps-hash-of-root-key-cert-extn-03
>>>>>>
>>>>>> Joel:
>>>>>>
>>>>>> Thanks for the review.
>>>>>>
>>>>>>> Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
>>>>>>> Reviewer: Joel Halpern
>>>>>>> Review Date: 2019-01-04
>>>>>>> IETF LC End Date: 2019-01-10
>>>>>>> IESG Telechat date: Not scheduled for a telechat
>>>>>>>
>>>>>>> Summary: This draft is nearly ready for publication as an Informational RFC.
>>>>>>>
>>>>>>> Major issues: N/A
>>>>>>>
>>>>>>> Minor issues:
>>>>>>>    The explanation at the end of section 5 about the remedy for losing access
>>>>>>>    to the new root key left me confused.
>>>>>>> It looks like the situation is that there is a certificate out there, with the
>>>>>>> hash of root key extensions. The certificate owner loses access to the new key
>>>>>>> pair underlying the hash. The certificate owner clearly has to issue a new key
>>>>>>> pair.  So far, so good.
>>>>>>>
>>>>>>> What the text seems to say is to simply issue a new self-signed certificate.
>>>>>>> There are two possibilities for what is intended. I think the idea is that the
>>>>>>> new certificate will use the existing key pair (not the promised one, nor
>>>>>>> another new one) for its own signature, and include a new hash of root key for
>>>>>>> the newly generated pair.  If the certificate owner can do that (I have not
>>>>>>> dived into the rest of the certificate operations to figure out if that is
>>>>>>> legal) then it works.  Please add some words explaining that better. If the
>>>>>>> certificate owner can not simply issue a new self-signed certificate with the
>>>>>>> existing key pair, then I am lost.  It appears that the text says that the
>>>>>>> certificate owner issues a new self-signed certificate using a new key pair.
>>>>>>> But that will fail the check against the previous certificate hash of root key.
>>>>>>> I am hoping that it is the first of these alternatives, and all that is needed
>>>>>>> is clearer explanatory text stating that the new cert uses the existing key
>>>>>>> pair, and includes a new hash of root key promise.
>>>>>>
>>>>>> Joel, the Root CA want to start using a different key par, but they have lost access to the one that was previously generated for that purpose.  So, the remedy is to create a new self-signed certificate with a newly generated key.
>>>>>>
>>>>>> Does that help?  If so, what would make the paragraph more clear?
>>>>>>
>>>>>> Russ
>>>>>>
>>>>>> _______________________________________________
>>>>>> Spasm mailing list
>>>>>> Spasm@ietf.org <mailto:Spasm@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/spasm
> 
>