Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-01

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 27 March 2018 15:50 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49EE12DA6A for <spasm@ietfa.amsl.com>; Tue, 27 Mar 2018 08:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 5eo8vbjdtJ9X for <spasm@ietfa.amsl.com>; Tue, 27 Mar 2018 08:50:36 -0700 (PDT)
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 72CDF12DA69 for <spasm@ietf.org>; Tue, 27 Mar 2018 08:50:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41FF3BE6F; Tue, 27 Mar 2018 16:50:34 +0100 (IST)
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 H9ZRpCeU5ep1; Tue, 27 Mar 2018 16:50:34 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DBF9FBE5C; Tue, 27 Mar 2018 16:50:33 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1522165834; bh=vGR2ZRbyWKN1/u+YX4ApXRF0vQdNyP1DeF8xpcIiqdE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FskceEPxFtHrA3Xsi/qwh9TlNv+1ofUi8D/BWsscmDKVV/kjaWcra/3YyKbQu2dLJ uQnpjzif9FbmwIvA+GVeUCQUtALs2aogchdvkbg0+ur1QU1d/4Yw55QkgQbi4JefDf hMXPDF3nvJxISyeFfg485bgRqXoylAHMjuFjrxKc=
To: Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
References: <bec28481-d4ff-5e6f-48bc-59c55c385321@openca.org> <30637C44-5EF8-4286-A796-E5D8D91CD01A@vigilsec.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ 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+2RuFnxM7BTQRaPVAyARAA+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 +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/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: <4843f85b-737b-5a01-bbd4-a081b55a045a@cs.tcd.ie>
Date: Tue, 27 Mar 2018 16:50:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <30637C44-5EF8-4286-A796-E5D8D91CD01A@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RfsF5nNpHMS7Kn74XyjzNChcEW3B80kh2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/McHBQoBLEMj8e6kEzL-7z4On7jY>
Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2018 15:50:45 -0000


On 27/03/18 16:44, Russ Housley wrote:
> Trimming the distribution to the LAMPS mail list ...
> 
> RFC 3281 includes the definition of noRevAvail certificate extension.  It is defined in X.509, and the definition is repeated in RFC 3281, Section 4.3.6.
> 
> If the CA is not going to publish revocation information about the certificate, I think we should include this extension to tell relying parties not to bother looking for it.

Makes sense to me too.  It's non-critical so shouldn't
break anything.

S.

> 
> Russ
> 
> 
>> On Mar 21, 2018, at 9:08 AM, Dr. Pala <director@openca.org> wrote:
>>
>> Hi all,
>>
>> unfortunately I missed the sec-dispatch session, but I have some important considerations about the document. In general, short-lived certificates have been around for many years and for many different applications (nothing new here), however nobody who have been working with PKI long enough would actually made the case that the security levels of short-lived-no-revo and any-lived-plus-revo are the same (which seems the life-motif of the presentation and the document itself).
>>
>> Other aspects that I think shall be revisited are the lack of considerations about the usability of deployed infrastructures (when no revocation is assumed) and some wrong considerations in the document about validity periods of OCSP Responses and CRLs (that clearly undermine the equivalence claim).
>> Equivalence of Short-Lived w/out Rev Support and Any-Lived w/ Rev Support
>> The statements that made me jump on my seat is the claim that short-lived certificates without revocation support (BTW, short-lived does not necessarily exclude revocation support) and certificates (short-lived or not) vs. any-lived certificates with revocation support have the same level of security as long as the validity period of the short-lived ones is equal or shorter than CRLs or OCSP validity. I find this quite a puzzling statement. For once, there should be considerations about the fact that if a key is compromised and it is used by a malicious entity to attack/disrupt/etc. another entity, the rightful owner of the certificate does not have any possibility to prove that someone else did it - there is no authenticated trail (OCSP response or CRL) that can be used in this case and this can lead, in some environments, to legal implications. I am curious about how do the authors address this point, maybe some considerations shall be made here.
>>
>> Also the claim that:
>>
>> " it is hard to justify why the CA or a delegate needs to both sign blob-1 (the certificate) and also sign blob-2 (the CRL or OCSP response) to tell relying parties that blob-1 is still valid."
>>
>> is quite curious and, I might say, misleading. Although the revocation status (either in the form of an OCSP or CRL) does not provide additional information besides the validity when the certificate is not revoked, it does provide quite a lot of useful information when the certificate is revoked (e.g., when a compromised happened, the reason for revocation - e.g., key compromise, a person has left the organization, a HW token is broken, etc.). I would prefer the authors to explain what they mean in more extensive and engineering-appropriate form. This is another evidence that the two systems are definitely NOT equivalent from a security perspective.
>>
>> Another example about the fact that some form of revocation is still needed comes from the document itself (thus contradicting, IMO, the main claim of the document - 5.1):
>>
>> "No matter how short-term these short term certificates are, there is a certain window of time when the attacker can use the certificate.  This can often be mitigated with application-level measures."
>>
>> this is "application-level measures == application-level revocation". This means that now, instead of having standardized ways to check for the status of certificates, each application need to implement a way to deal with it on an ad-hoc basis and being able to distribute securely this information to all relying parties. Undoubtedly, for anybody who has ever had to deal with such problems this becomes a quite costly and intractable problems very quickly. Maybe some considerations about this should be added in the document as well.
>>
>> Usability of Deployed Infrastructures
>>
>> One important section that is missing is: how do these no-revocation PKIs look like? There are basically two main choices here:
>>
>> Deploy a 2 level-only PKI. That means having a Trust Anchor that issues directly the EE certificates. Besides all security considerations about TAs being online (as required in short-lived environments), this makes it very difficult to deploy. Important considerations should be made in this case.
>>
>> Deploy a 3+ level PKIs (current best practices). This approach involves having (usually one) intermediate CAs (there can be more). In this case, the TAs issue the intermediate CAs' certificates and the last intermediate CAs issue the EE ones. Obviously, intermediate CAs can not have the same short validity period as the EE certs, therefore the need for revocation (at least at the intermediate CAs level) is evident. Important considerations shall be made also in this case.
>> Wrong Considerations about CRLs and OCSP Responses validity periods
>>
>> In the document, statements like the following shall be fixed and expanded for clarity:
>>
>> "If a CRL has a nextUpdate field that is 4 days in the future, a typical system will not attempt to fetch a new one before those 4 days have elapsed."
>>
>> And then it continue by stating the following:
>> "For this reason, moving to STAR certificates provides a similar level of security to what is generally practiced on the web."
>>
>> Since the first statement is incomplete and, thus, misleading - the second statement does not hold. Let me explain further for the people that are not familiar with how CRLs and OCSP are processed. Although there is a validity period for revocation information, it is well-known that the expiration field indicates the time "within a new revocation status information will be made available" and it is NOT "this is the revocation status of the target certificate until the expiration" - common practice is that when a revocation event occurs, new CRLs and OCSP responses for the revoked certificates are made available immediately or within few hours at most.
>> It is an important distinction that highlights also why the lack of revocation information makes the system less secure. Although it is quite evident why and since this is not addressed in the document, it might be useful to spell it out.
>>
>> In a multi-party environment, different applications might have (a) different strategies when it comes to caching of the revocation information and/or (b) check the revocation information at different times. Let's make the case of 2 parties checking the rev info for the same certificate. If party A accesses OCSP/CRLs at {time1} and caches it until {time1 + delta}, party B retrieves it at {time2} and caches it until {time2+delta}. Let's assume that time2 > time1 and that new revocation status information is already available at {time2}. This means that, although party A is still vulnerable until {time1+delta}, party B is not. In a short-lived cert environment w/out revocation ALL parties are VULNERABLE until the compromised {key+certificate} expires.
>>
>> It seems quite clear that the two environments (short-lived w/ no revo and any-lived w/ revo) do not have the same security properties.
>>
>> Therefore I think that the authors ought to demonstrate the equivalence of security levels (not just assume it as hypothesis - given I just disproved it) or to remove all claims that the two environments are actually equivalent from as security perspective and to add specific considerations for short-lived-no-revo about the the fact that not supporting revocation is inherently weaker because it potentially exposes all parties to attacks (e.g., MITM, un-authorized access to resources, etc.) that can not be stopped (unless you implement application-level revocation.. and, therefore, re-introduce revocation from the backdoor in a non-standardized, ad-hoc, hard-to-manage across application fashion).
>>
>> Final Considerations
>>
>> I am not opposed at the concept of this document to be considered for BCP, however all the above issues MUST, IMO, be addressed before the document can be considered further. I think I already raised these considerations at the last IETF, but I do not think the authors missed or have not considered the provided feedback. I hope that a more explicit and written feedback might be taken into considerations.
>>
>> Just my 2 cents form an old barnacle... :D
>>
>> Cheers,
>> Max
>> -- 
>> Best Regards,
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>> <cndojoacigamfbdj.png>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>