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

From: "Dr. Pala" <[email-masked]>
Date: Mon, 2 Apr 2018 18:30:53 -0600

Hi Tero,

On 3/26/18 11:45 AM, Tero Kivinen wrote:
> Dr. Pala writes:
>> Putting it in a different way: for the case with revocation
>> information, the attacker not only need to be able to compromise the
>> private key, but it also need to own all possible paths to the
>> revocation information whilst for the short-revo case, the
>> compromise of the key is a sufficient condition to successfully
>> carry out the attack. Don't you agree ?
> In most protocols there is a way to provide the revocation status
> (OCSP, CRLs etc) inband in side the protocol itself, thus attacker
> does not need to control anything in the network, it simply send the
> certificate and the revocation information to the received, and as
> long as the revocation information is still valid the receiver will
> accept it and do not even try to fetch anything from the network. This
> means that attacker can usually even force the receiver to accept CRLs
> or OCSP responses as long as they are valid, even if there would be
> new ones created already.
That is true especially in the browsers environment. However, deciding
if a revInfo is "fresh" enough is a policy/application decision -
therefore, even with valid revocation info, if the validity period or
(better) the producedAt field is too far in the past, the relying party
(server or client) can decide to fetch new revInfo even when OCSP
Stapling has been used. This should always be configured in an
application to make sure the revocation information is fresh enough.

For CRLs.. is there an equivalent mechanism to OCSP-stapling (like CRL
stapling) ?

> For the receiver point of view he will get valid certificate and
> signed revocation information telling that certificate is still valid
> until nextUpdate time, so why should it fetch anything from the net.
Policy and Configuration. Since applications do not have the possibility
to choose what the OCSP or CRLs (or Certificates for that matter)
validity is, they can always reject that because it is not compliant to
the application security settings.
> Attacker of course does not include the latest revocation information
> which marks certificate revoced, but the old one which did not do that
> yet, as long as the nextUpdate is not in the past.
Naive applications (or, better, applications that have not been written
with security in mind) perform that way, but not all of them :D

Anyway, no matter how we skin the cat, I think it is pretty clear how
(a) the considerations in the document hold for TLS (maybe IKE)
environment only, (b) they do not apply to the WWW because of
certificate transparency, and (c) [the main point] the two environments
(revo vs. no-revo) are NOT equivalent in security (since I can model a
simpler attacker for the non-revo case).

The last (c) point is what (being an academic) is important to me since
the two environment do not have the same level of security.

Cheers,

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 2 Apr 2018 18:36:15 -0600

Hi Ben,

On 3/26/18 9:45 AM, Benjamin Kaduk wrote:
> On Sat, Mar 24, 2018 at 03:26:15PM -0600, Dr. Pala wrote:
>> On 3/22/18 5:10 AM, Yoav Nir wrote:
>>> Sure. As soon as the CA receives a report that a certificate is
>>> compromised, a new CRL (or OCSP response) is issued. However, assuming
>>> the RP has downloaded the CRL 1 day earlier, that CRL marked as having
>>> a nextUpdate 3 days later. The RP will not download the new CRL for 3
>>> more days, and will therefore continue to accept the compromised
>>> certificate for 3 days.
>> Maybe also here I was not really clear enough - sorry. What you are
>> saying is true for ONE RP, but when there are multiple RPs that might
>> access the revocation information at different times, what you describe
>> is actually a limited view of the problem.
> That depends on the security model and what capabilities you are
> willing to grant to the attacker.  Which relates directly to the
> question I asked in my previous message on this thread -- are you
> planning to reply to it?
>
I thought I did extensively in my reply on 3/26. If that does not
address it, I might have misunderstood your question then.

Please let me know,

Cheers,

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo