Subject: [pkix] Validating Certs w/out reliable source of Time

From: "Dr. Pala" <[email-masked]>
Date: Thu, 4 Oct 2018 08:21:58 -0600

Hi all,

I am struggling with one issue that we have been seeing more and more 
often with the introduction of small IoT devices that connect to clouds 
and need to validate the other party's certificate chain.

In particular, the problem is that without a reliable (or trusted) 
source of Time information, devices can not really validate certificates 
(i.e., is the certificate even valid... ? is it expired ? is the 
revocation info fresh enough ?) and my question for the list is about 
best practices in the space.

Do you know if there are indications / best practices from ITU or from 
IETF (or other organizations) on how to deal with this issue ?

Cheers,
Max

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

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 4 Oct 2018 16:36:04 +0000

Hi Max,

This is an issue that is dealt with in onboarding too. https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16#section-2.6 has some text around it. It states “It is reasonable that the
      notBefore date be after the pledge's current working reasonable
      date.  It is however, suspicious for the notAfter date to be
      before the pledge's current reasonable date.  No action is
      recommended, other than an internal audit entry for this.”
IMO, if someone trusted a server cert chain because he didn’t have proper time at the time, he should generate an audit log that can be used to go back to validate when more accurate time available.

There was also a discussion in LAMPS about trusting expired certs in the initial enrollment https://mailarchive.ietf.org/arch/browse/spasm/?q=%22Permissibility+of+expired+cert+renewal%22 . Caching revocation info for the chain is important in these cases.

Rgs,
Panos

From: pkix <[email-masked]> On Behalf Of Dr. Pala
Sent: Thursday, October 04, 2018 10:22 AM
To: PKIX <[email-masked]>
Subject: [pkix] Validating Certs w/out reliable source of Time

Hi all,

I am struggling with one issue that we have been seeing more and more often with the introduction of small IoT devices that connect to clouds and need to validate the other party's certificate chain.

In particular, the problem is that without a reliable (or trusted) source of Time information, devices can not really validate certificates (i.e., is the certificate even valid... ? is it expired ? is the revocation info fresh enough ?) and my question for the list is about best practices in the space.

Do you know if there are indications / best practices from ITU or from IETF (or other organizations) on how to deal with this issue ?

Cheers,
Max
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]

---

From: Rob Stradling <[email-masked]>
Date: Thu, 4 Oct 2018 17:02:28 +0000

Hi Max.  The most promising solution I've seen to this problem is 
Google's Roughtime protocol.

Adam Langley's blog post:
https://www.imperialviolet.org/2016/09/19/roughtime.html

Protocol description:
https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md

Open-source implementation:
https://roughtime.googlesource.com/roughtime

Cloudflare's Roughtime service:
https://blog.cloudflare.com/roughtime/

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [email-masked]

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 8 Oct 2018 08:12:39 -0600

Hi Panos, all,

thanks for the info. It seems nobody has a good story around it - the 
onboarding provides some obvious paths, but it does not provide really a 
good story around it and it is very prone to implementation errors (it 
seems more like giving up in having a good answer / system when you do 
not trust the network itself - which is the case I am trying to cover).

Although I totally agree with the difficulty around providing a 
solution, I am a bit worried about devices keeping logs/audit traces and 
then follow up on them at a later time - especially without providing 
guidance about what is a trusted source of time... :D I would expect 
many devices not to really check the validity of certificates after they 
have been "used" already.

In my specific use-case (which is not a generic case), I am leaning 
toward building a signed time service w/ a simple challenge-response 
mechanism that can be proxy and verified by the device... since we 
already have domain-specific trust anchors deployed, we might leverage 
those also for this use-case.

Last but not least, it might be useful to define a TLS extension that 
would carry such a record so that time-synchronization becomes less of 
an issue... does such an extension already exists?

Thanks again,

Cheers,
Max

On 10/4/18 10:36 AM, Panos Kampanakis (pkampana) wrote:
>
> Hi Max,
>
> This is an issue that is dealt with in onboarding too. 
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16#section-2.6 
> has some text around it. It states “It is reasonable that the
>
> IMO, if someone trusted a server cert chain because he didn’t have 
> proper time at the time, he should generate an audit log that can be 
> used to go back to validate when more accurate time available.
>
> There was also a discussion in LAMPS about trusting expired certs in 
> the initial enrollment 
> https://mailarchive.ietf.org/arch/browse/spasm/?q=%22Permissibility+of+expired+cert+renewal%22 
> . Caching revocation info for the chain is important in these cases.
>
> Rgs,
>
> Panos
>
> *From:*pkix <[email-masked]> *On Behalf Of *Dr. Pala
> *Sent:* Thursday, October 04, 2018 10:22 AM
> *To:* PKIX <[email-masked]>
> *Subject:* [pkix] Validating Certs w/out reliable source of Time
>
> Hi all,
>
> often with the introduction of small IoT devices that connect to 
> clouds and need to validate the other party's certificate chain.
>
> source of Time information, devices can not really validate 
> certificates (i.e., is the certificate even valid... ? is it expired ? 
> is the revocation info fresh enough ?) and my question for the list is 
> about best practices in the space.
>

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

---

From: Tom Ritter <[email-masked]>
Date: Mon, 8 Oct 2018 15:00:39 +0000

On Mon, 8 Oct 2018 at 14:13, Dr. Pala <[email-masked]> wrote:

> seems more like giving up in having a good answer / system when you do not
> trust the network itself - which is the case I am trying to cover).
>
> Although I totally agree with the difficulty around providing a solution,
> I am a bit worried about devices keeping logs/audit traces and then follow
> up on them at a later time - especially without providing guidance about
> what is a trusted source of time... :D I would expect many devices not to
> really check the validity of certificates after they have been "used"
> already.
>
> In my specific use-case (which is not a generic case), I am leaning toward
> building a signed time service w/ a simple challenge-response mechanism
> that can be proxy and verified by the device... since we already have
> domain-specific trust anchors deployed, we might leverage those also for
> this use-case.
>

If you use OCSP in a challenge-response mode with nonces - you could get
this within established TLS/PKIX standards. Although OCSP
challenge/response (as opposed to stapling) is falling out favor; and OCSP
nonces stopped being used over a decade ago. But I don't think the code is
removed from tools; just uncommonly used.

Caveats being; of course, the uptime of your time/OCSP server; difficulty
of rotating that server's certificate, what to do when you don't get a
response....

-tom

---

From: Denis <[email-masked]>
Date: Mon, 8 Oct 2018 17:06:15 +0200

Hi Max,

You wrote:

    the problem is that without a reliable (or trusted) source of Time
    information, devices can not really validate certificates
    (i.e., is the certificate even valid... ? is it expired ? is the
    revocation info fresh enough ?) and my question for the list is
    about best practices in the space.

If your PKI includes an OCSP responder, then you can get the UTC time 
rather easily. You use a nonce as defined in section 4.4.1 from RFC 6960 
in an OCSP request.
The field producedAt (section 2.4) of the response gives you the time at 
which the OCSP responder signed this response. This works if your IoT 
element has an internal timer.

Denis

PS. I just realized that Tom Ritter provided you with roughly the same 
answer. Since my email was ready, I send it to you anyway.

> onboarding provides some obvious paths, but it does not provide really 
> a good story around it and it is very prone to implementation errors 
> (it seems more like giving up in having a good answer / system when 
> you do not trust the network itself - which is the case I am trying to 
> cover).
>
> solution, I am a bit worried about devices keeping logs/audit traces 
> and then follow up on them at a later time - especially without 
> providing guidance about what is a trusted source of time... :D I 
> would expect many devices not to really check the validity of 
> certificates after they have been "used" already.
>
>> certificates (i.e., is the certificate even valid... ? is it expired 
>> ? is the revocation info fresh enough ?) and my question for the list 
>> is about best practices in the space.
>>
>> Do you know if there are indications / best practices from ITU or 
>> from IETF (or other organizations) on how to deal with this issue ?
>>
>> Cheers,
>> Max
>>
>> -- 
>>
>> Best Regards,
>>
>> Massimiliano Pala, Ph.D.
>> OpenCA Labs Director
>>
>> OpenCA Logo
>>
>
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 8 Oct 2018 09:45:22 -0600

Hi Tom,

On 10/8/18 9:00 AM, Tom Ritter wrote:
> On Mon, 8 Oct 2018 at 14:13, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Panos, all,
>
>     [...]
>
>
> If you use OCSP in a challenge-response mode with nonces - you could 
> get this within established TLS/PKIX standards. Although OCSP 
> challenge/response (as opposed to stapling) is falling out favor; and 
> OCSP nonces stopped being used over a decade ago. But I don't think 
> the code is removed from tools; just uncommonly used.
>
> Caveats being; of course, the uptime of your time/OCSP server; 
> difficulty of rotating that server's certificate, what to do when you 
> don't get a response....

For our specific case, we considered using the OCSP responses since our 
servers do support NONCEs and do not have ridiculously long 
validity/caching period (as it seems current practices from many CAs), 
however that might not be a good path for a generic solution (beacuse of 
current practices). I am also considering other protocols (e.g., SCVP) 
and cross-protocols options (e.g., DNS entries/extensions, etc.) - 
however the constraints on network access might make these approaches 
also difficult...

Thanks again,

Cheers,

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