Gorry Fairhurst via Datatracker <nore...@ietf.org> wrote:
> 3. Please could you add text to explain “no transport layer security
> between Registrar-Agent and pledge..” e.g., please explain: Is this
> something that users ought to add to a design? how? why? is it a
> desirable property? Why? ... or is this intended to be explained more
> in the next subsections? ... Especially since 7.1 speaks of optional
> use of TLS.The new (pledge) device: a) has no internet. If it has IP at all, it's via a Soft-AP or an p2p ethernet cable. https://en.wikipedia.org/wiki/SoftAP b) the device has an IDevID, but that's a long-term certificate with no SAN that TLS could verify. So, you can't do DNS-ID verification, so at most any TLS that would be there would be unable to verify anything. A lot of effort for almost no security. The device has no name for any SAN. The device might have only an IPv6-LL address, which might be randomly generated. At most, the Registrar-Agent, which also might have no connectivity, would be able to validate that the IDevID is from a trusted manufacturer. Not every deployment has such a list. See https://www.rfc-editor.org/rfc/rfc8995.html#section-11.5 c) might be connected via USB. BTLE. HTTP-ish/CoAP can run across BTLE using GATT. In theory, the entire Registry Agent could live in a mobile browser. No, we haven't explained this; it would be another document. This is why the PRM mechanism includes so much *object* security including having the pledge sign the Registrar Agent's nonce in the Section 6.2 and 7.1 says a lot about the process expected around HTTP. For instance, the registrar-agent can't put anything useful into the HTTP Host: header either. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
