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

[Stefan Santesson <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> 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
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/spasm
    > 
    > 
    > 
    > 
    > _______________________________________________
    > Spasm mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/spasm
    > 
    _______________________________________________
    Spasm mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/spasm