[Lake] evaluation of attestation results by EDHOC "clients"

[Michael Richardson <[e-mail]>]

{sorry for the length}

Yuxuan Song explained her document draft-song-lake-ra to me with the help of
Goran and Malisa.  As I said on the list before, doing remote attestation as
part of an onboarding process makes a lot of sense.
Independant of that process, there are questions.   The documents' diagram:
     https://www.ietf.org/archive/id/draft-song-lake-ra-00.html#figure-1
does map very well to the U/V/W of:
     https://www.ietf.org/archive/id/draft-ietf-lake-authz-01.html#figure-2

{I did not see before that it is proposed to carry the Evidence in message-3.
I thought that would be too late, and it had to go in message-1}

(Except that re-using "V" for Verifier vs JRC is a problem we should avoid.)

My contention, which I think the group agreed with, is that one probably
wants to do continuous assurance, that is, to repeat the remote attestation.

Do you want to have two protocols and two code paths? (redundant code in a
constrained device?).  I suggested that *maybe* the remote attestation should
use it's own /.well-known Path, and that it would just occur after
onboarding, and regularly onwards.  Maybe it's weird to onboard a device only
to kick it out again immediately because it failed remote attestation, but
given continuous assurance, this could happen at any time.
Anyway, if devices are being onboarded and then failing regularly, then I
think there are other, bigger problems.  (And if the battery on the device
gets run down because of this; well... that's one fewer attacker...)

We discussed the possibility that whenever doing a subsequent remote
attestation, that it could happen as part of a PSK-based EDHOC "rekey".
I can live with that.

We also discussed the opposite situation: where a constrained device needs to
consider the security posture of the (edge?) compute node which is going to
collect the sensor data.   This is a far more difficult situation.

In general, the situation is that the device needs to consider the
*Attestation Results*, since there is no reasonable way a constrained device
can competently evaluate the evidence directly.  This is, unlike the above
situation, a passport model.     Somewhere a Verifier has produced the right
results.  The question in this case is how is the U-device provisioned with
the right public key with which to evaluate the results?

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