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

Tim Hollebeek <tim.hollebeek@digicert.com> Tue, 27 March 2018 19:48 UTC

Return-Path: <tim.hollebeek@digicert.com>
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 675A512D969 for <spasm@ietfa.amsl.com>; Tue, 27 Mar 2018 12:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=digicert.com
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 t6WX3X-F7_A1 for <spasm@ietfa.amsl.com>; Tue, 27 Mar 2018 12:48:02 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.193]) (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 029A81273E2 for <spasm@ietf.org>; Tue, 27 Mar 2018 12:48:01 -0700 (PDT)
Received: from [216.82.242.36] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta-8.messagelabs.com id F6/BA-00416-0FF9ABA5; Tue, 27 Mar 2018 19:48:00 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0hTYRjG951zdnYSF8dp+TYKaiGUMVEqmBV pRbWioiIJhlFHPW6jXeScKVZ/tG5mjcy05bLmsqzItCxK1C7WKEIDK3PLyizt4i26021k7eys 238/vud5n+/9Xt6PwhUDpJJi820sZ2FMKjKC6Bx/IVH9ztOkS7yaphnsfyjTVPgzNfVeL6Epu +KXpRLasu1tpLbW4SO1VVXfMG111yfpckInNVoyrPnrpIaTpd+wnNYSlF/T/Jmwo8Obd6MIiq DfYrDzZQDbjUZQCtqJwZuWiSI/Q3DjqlZgkk4E/5VbmFAQQzsR7LK7QwXR9Cp40LaXEDiGToP uV0WYyAvg3M99pMAEHQd1tXUhj5xOhw/eIqkQpKA7EVT2u0PCCDoFXEXPZQIjejR8aa0JBeF0 LDx64Qkx0DHQc+82KfIoGHg+LBX96eD+6A2fq+DM666wfxy0exxIuAzoCxgcundRKgpqeOd04 iIvBVdvABNNvQhKj12TiUI81JV8RSKvh7db3GE2w8v+knBBFQ4FvuJwwVj40Xc+LBwlwVV/mB AnmQX7q4X+BCGAweeKbUicnhKedOxCxWhy+T9vLQ/6cNqD4GLTabI8NLUoaDn4ghBN8eCsHQz zFDhROYSLPBNc36+TIk+A/Y4emcjTYejme3QEUdVoEs9yeSynTkpOyOCMeoPNzBhN6qRETYKZ 5XlGz5qYDD4h02o+j4ILt1kiQQ3owKWFXjSGwlSj5L5NTTrFyAxr1gYDwxvWcrkmlveisRSlA nlfRVCL4lg9m59tNAW39rcMVKQqRk4F91Yh53MYM2/Ui1Irmkp1lPUV4FRn/1ABriAsVgurjJ UPC0m0YDXkWv4E/f4B7WicMlqOJBKJIjKH5cxG2//6IIqlkCpa3i2kRBottj/3DQZbwYKt1G9 tEFqxMX8lpR0plrl1gbuzRutzKzsbj6pbXIX3C/Fp9oGFc1fPqJs2xz67UhPxoDtvpVUt8yUv 4W8XW3zHD+14mu5PPePwuzzzzr0vxXXbHyf/sNTk8g07ce6nI+V7Sdeiu2uIYdSz4uPiQFZX4 5qHp9CdBknc5et7NhaaDdkpzanzh8+2lfkGVqkI3sAkxeMcz/wC7YzkTfwDAAA=
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-16.tower-94.messagelabs.com!1522180079!186231447!1
X-Originating-IP: [216.32.180.48]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 116494 invoked from network); 27 Mar 2018 19:47:59 -0000
Received: from mail-by2nam03lp0048.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) (216.32.180.48) by server-16.tower-94.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 27 Mar 2018 19:47:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N1dwTa6lipF8+tzdVmz/GKLPeQUU1TgY6umKSNabc5Y=; b=uwXiKXNG/cN8iqImgJJ+bT9ArGh/FDSk+9LesmwyemaS0JkriRFVbyV93CWMG77fK+5+Zclnm+SHpva3jbWbqB07ubDkDz7d9PQcYCb9sTdUP2xcZTC1IgXcAsVTEUO3RXnYOaJyxNevmKxnu9EvxK6/6XZXcAfXLox4aa7xcng=
Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1568.namprd14.prod.outlook.com (10.173.234.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Tue, 27 Mar 2018 19:47:56 +0000
Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd%17]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 19:47:56 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Stefan Santesson <stefan@aaa-sec.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Russ Housley <housley@vigilsec.com>, LAMPS <spasm@ietf.org>
Thread-Topic: [lamps] Considerations and Clarifications about draft-nir-saag-star-01
Thread-Index: AQHTwRW4eNEoTpa7PEmoGQqs7AdAaKPkQq+AgAAB0ICAAEBQAIAAALww
Date: Tue, 27 Mar 2018 19:47:56 +0000
Message-ID: <MWHPR14MB1376CA49B1071D706D516C1783AC0@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <bec28481-d4ff-5e6f-48bc-59c55c385321@openca.org> <30637C44-5EF8-4286-A796-E5D8D91CD01A@vigilsec.com> <4843f85b-737b-5a01-bbd4-a081b55a045a@cs.tcd.ie> <C52393D3-AFA2-4AC4-AEEF-CC9F2028A4AA@aaa-sec.com>
In-Reply-To: <C52393D3-AFA2-4AC4-AEEF-CC9F2028A4AA@aaa-sec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [98.111.253.132]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR14MB1568; 7:6xbRTs/YFN0lcEHMGwpjRxct4MvEokNJHvbW0AKxIWLH5V+BD0MkslmKE/dZS6zaICSFg+MRbTL1NZz7gP51C/nbckW3Tb51Quoq1qbHBS6amcWhggB/+YJcO9nPWLHrX94XpZXW8b9q/sfz0zLcoKQuTGV7OXnzO512DwBE3w7Cax+KjdfiRQ2jBPGMR/9LTRSmYsaK+eAd7ETMT5r3yxg64MYG4ifne3iVMatqv5k5006chBez73ol0XwqzHeY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 0264770a-be1a-44fd-e767-08d5941ba343
x-microsoft-antispam: UriScan:(32856632585715); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1568;
x-ms-traffictypediagnostic: MWHPR14MB1568:
x-microsoft-antispam-prvs: <MWHPR14MB15687C69969E74796556A82783AC0@MWHPR14MB1568.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(32856632585715)(278428928389397)(209352067349851)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:MWHPR14MB1568; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1568;
x-forefront-prvs: 0624A2429E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(39860400002)(346002)(396003)(199004)(13464003)(51444003)(53754006)(189003)(377424004)(7696005)(68736007)(110136005)(316002)(59450400001)(186003)(11346002)(14454004)(6436002)(66066001)(229853002)(26005)(86362001)(53546011)(93886005)(6506007)(76176011)(102836004)(33656002)(5660300001)(99286004)(3660700001)(966005)(478600001)(476003)(446003)(2906002)(106356001)(6306002)(3280700002)(3846002)(7736002)(305945005)(25786009)(55016002)(53936002)(6246003)(2900100001)(74316002)(5250100002)(6116002)(8936002)(9686003)(81166006)(99936001)(8676002)(105586002)(81156014)(486005)(486005)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1568; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: s2wg3UtIYZl0Dig0Y0JwcofgYnjZE7RJHfEzb9iA4tY4VJpk34Wo+L9PhsrWK5YLDC3WKw6h5hChV0eOinbCuOwgseVTfEvEapgsLSCy9Yk1vk7odGYy9BIzp/AUrw4zfYA/ybYPTef9nSY/IXiVjpdrDqLpvjnssPr8eK+F6yVSGd1FSCsohVeg/4se92ajhHQPXxIFweU3o63z31lSwk9OJGWDIZu4owFyCnZVw2dlqtido5GgCRN4Eavkn2CMKzAB/ydrd7LEzqkBOCsKgKxoLLgQxkHy51dVkQfgNwSD6kVYThbwZXEEGX+JuMsTw1dtdg6SXqaiYfK3kWg6kw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0199_01D3C5E2.F8259650"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0264770a-be1a-44fd-e767-08d5941ba343
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 19:47:56.4769 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1568
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/HwJef5qJEe-lb7JHW1KXTBt-dQk>
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 19:48:07 -0000

It's not widely known, but Firefox already skips revocation checking if the lifetime
is short enough (that code was added after the previous discussion of whether it
was necessary to omit the information).  You don't actually have to modify the cert 
at all if you don't want to.

-Tim

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stefan Santesson
> Sent: Tuesday, March 27, 2018 3:41 PM
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; Russ Housley
> <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
> Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-
> 01
> 
> We had a long discussion in ETSI about this.
> 
> One aspect is that the absence of revocation information actually breaks
> several implementations.
> One idea was to publish an empty CRL + an extension with the semantics =
> "You may skip the rev checking, because the CRL is empty"
> 
> This way you would have the cake and eat it too. Old systems would use the
> CRL and work. New systems would understand the extension and skip CRL
> checking.
> 
> But maybe this is to overcomplicate things.
> 
> /Stefan
> 
> 
> 
> 
> On 2018-03-27, 17:50, "Spasm on behalf of Stephen Farrell" <spasm-
> bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:
> 
> 
> 
>     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
>     >
>     _______________________________________________
>     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