Subject: Re: [Danish] [Iot-directorate] SCVP

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Feb 2021 18:00:19 -0500

For others:
    SCVP = Server-Based Certificate Validation Protocol
    RFC5055.

Russ Housley <[email-masked]> wrote:
    > I have recently learned that the US Department of Treasury operates an
    > SCVP responder associated with the US Government's PKI:

    > 	https://vssapi.treasury.gov/vss/docs/treas_scvp_profile_v1.3.pdf

BTW: This URL returns no MIME type, so sane browsers assume text/plain,
     so you'll have to save-as, as load it locally.
The diagram of the federal PKI is truly impressive.
Is the software that they run available?

    > This Got me to thinking about an IoT device trying to construct a
    > certification path in this complex PKI environment.  Such a SCVP
    > responder could be used to offload this task.  There could be battery
    > consumption to send the request and get the response; however, it may
    > very well be less battery than doing the certification path
    > construction itself.

There are three considerations in the analysis in my opinion:
  1) the network energy cost of connecting.
  2) the local energy cost of being awake to receive the reply.
  3) the network energy cost of retrieving the relevant certificate chains.

I think that a major win for IoT devices on challenged networks is being able
to avoid retrieving any of the subordinate or intermediate CRLs/OCSP results
along the way.
This feels like a service that a powered IoT gateway ought to provide.
This eliminates much of the trust issue.
Also, the odds are all the devices in a sensor network would have to validate
much of the same complex path, so caching would work well.

However, I have yet to see any IoT system that has a PKI more complex than
two levels of private PKI.  But, perhaps that's because more complex
scenarios wouldn't work with SCVP.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2021 06:00:21 -0800

Michael Richardson <[email-masked]> writes:

>     > however, it may very well be less battery than doing the
>     > certification path construction itself.
> 

I think that's a great point.  DANE is likely far less energy intensive
than full PKI -- but you probably need data to prove it (number of CPU
instructions needed or something for full validation via both
certificate verification approaches)
-- 
Wes Hardaker
USC/ISI

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Feb 2021 18:06:26 -0200

> On Feb 16, 2021, at 12:00 PM, Wes Hardaker <[email-masked]> wrote:
> 

DANE-EE(3) requires just a check of the hash of the EE cert, there's no
need for chain validation.  Validation of the associated DNS records
can be amortised by caching, but is otherwise potentially costly if
performed afresh each time.

For DANE on an energy constrained device I'd probably look for a secure
channel (DoH, DoT, or some day QUIC) to a trusted iterative resolver that
can return validated DANE records to the application without the need to
perform any validation locally.  The DANE records can then be cached and
used multiple times up to the returned TTL.  If these are DANE-EE(3) or
similar, then indeed there may be a savings in the cost of signature
verification, because there are no issuer signatures to check.

If on the other extreme DANE is used to pin a "root CA" a few levels
up the issuer stack, then DANE and PKIX are much the same, with
DANE perhaps slightly costlier because the DNS data needs to be
refreshed more often than would a locally configured root CAs.

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2021 12:14:14 -0800

So enumerating the potential things to attempt to measure:

1) Full PKIX -- ignore DNSSEC and DANE
2) DANE with full DNSSEC validation -- DANE-EE and validation from the root (worst case)
3) DANE with DOH/DoT/etc validation done by the upstream resolver that
   you trust to do DNSSEC validation (because you're throwing trust at
   this point).  Also note that in this situation you may or may not be
   using long lived connections with the DoH/DoT provider (which will
   also require PKIX).  (Also note that there is likely varying levels
   of trust for them to properly set the AA bit)

-- 
Wes Hardaker
USC/ISI