Eliot Lear <[email protected]> wrote: >> Eliot Lear <[email protected]> wrote: > So this raises an interesting >> question, which is probably more > appropriate for RATS. What >> information should be shared with whom and > how? The voucher is >> shipped in the clear without much prompting. >> >> How so in the clear? It's DNS-ID or pinned TLS from Registrar to MASA >> (which is across the Internet). Getting a voucher requires a >> voucher-request, signed by the device. That could be obtained by a >> malicious registrar, true, but that requires on-link-ish access to the >> device.
> Sorry- let me restate: it's not that the voucher or request is not
> encrypted, but rather that the voucher-request is received by a party
> that may not be authorized to onboard that client. The client doesn't
> know that until it sees the response from the MASA. Therefore,
> whatever information it reveals should be minimized at this point in
> the transaction. Once the device has installed a trust anchor, then it
> has at least some reason to trust the other party with what its
> designers may view as more sensitive information.
Yes, that's true. The unknown Registrar could see the Evidence.
The Evidence clearly needs to be encrypted from Attester(pledge) to
Verifier(MASA). This could be done with ECIES, I think.
If there was a need for an audit of the Evidence at the Registrar, then I
think that the MASA could reveal the cipher key to the Registrar after it has
determined that it's the right authorized party.
>> > There are different views about how sensitive software inventory is.
>> > This is why the draft doesn't take a position on the subject, other
>> > than to allow for the notion that some requests *may* need to be >
>> authenticated.
>>
>> I agree that this is the right approach for the document to take. I'm
>> expressing the view that it's fundamentally security through
>> obscurity.
> Fair enough, but I posit a world in which the attacker has at its
> disposal a bag of tricks that is indexed by RATS evidence, and a
> limited window of time to apply those tricks. In that sense, a little
> bit of security through obscurity might prevent some break-ins. Not
> that it's an excuse to not fix those vulnerabilities, of course, but
> simply a bit of defense in depth.
That reads like a poorly researched Hollywood plot to me :-)
We weren't discussing RATS Evidence, we we were discussing the contents of an
SBOM.
There is a difference, I think.
I don't expect the attestation to be done in the clear.
I do think that the list of components of a
not-thought-to-be-vulnerable-at-this-moment device to be visible.
There are many purposes that the SBOM serves, including validation of
licenses, vulnerability to patent-litigation [remember that some countries
respect moral rights], ...
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
