[Diem] Re: Some high-level thoughts on scoping

[Felix Linker <[e-mail]>]

Hi Ekr,

I wanted to quickly jump in and discuss point [0].

I think there is a significant risk associated with unauthenticated emblems. It could turn out that they are distributed in bad faith so often that people would stop paying attention to any emblem. The signal-to-noise ratio would be simply too low.

Nevertheless, I think that anyone should be able to deploy emblems. This is why we aimed to provide accountability with ADEM. We require parties to bind their signing keys to their domain name in a non-repudiable way. So you at least put your domain name at stake when distributing fraudulent emblems. Such emblems in some sense are unauthenticated (they don’t like back to a „root CA“), but they still can be authentically associated with a domain name.

Best,
Felix

> On 29 Jun 2024, at 23:32, Eric Rescorla <[e-mail]> wrote:
> 
> Hi folks,
> 
> I've been reading the mailing list and wanted to offer some high
> level comments.
> 
> PROBLEM STATEMENT
> We have two problem statement documents here which seem to have
> different ideas of what the problem is. I would characterize
> these as:
> 
> - Port emblems from the physical to the digital domain (draft-linker)
> - Improve on the security properties of physical emblems for physical
>   objects by digitizing them (draft-haberman)
> 
> These seem like quite different objectives, made more different by the
> assumption that both PS documents seem to make that the digital
> emblems have to be hard to forge [0]. For instance, the mechanism
> described in draft-adem-wg-adem-core-latest ties the emblem to some
> network identifier for an element (the IP address or a domain name),
> but this does not transfer in an obvious way to physical object.
> 
> The emblem being physically attached to the object doesn't really help
> here because the attacker might copy (if it's copyable) or move the
> emblem (if it's uncopyable, though of course this is quite hard to do
> while also having it be cheap) I see that in
> (https://mailarchive.ietf.org/arch/msg/diem/-5sgtyo8hbCq7rLEDRVPZb8krMQ/)
> Bill Woodcock observes that the emblem might carry various attributes
> about the physical properties of the asset, but this seems like
> a much weaker form of binding as there are going to be a very large
> number of assets and the ability to positively identify each one
> by properties such as size and mess will necessarily be quite limited.
> Even ignoring everything else, just specifying the parameters one
> would use in order to provide such a binding between emblem and
> object seems challenging, and not really something that the IETF
> is well suited to address (how does one distinguish between a pile
> of more or less identical looking 40ft shipping containers?).
> 
> 
> ARCHITECTURE
> Conceptually, it seems to me that there are at least four technical
> problems to solve:
> 
> 1. The information to be conveyed about the asset (e.g., "This is a
>    hospital").
> 
> 2. The binding of the information to the asset (e.g., "this asset
>    has this IP address" or "this asset is a crate with the following
>    properties")
> 
> 3. How the information is delivered to the verifying party.
> 
> 4. How the information is attested to (e.g., the trust hierarchy).
>    Obviously, if we decided not to authenticate the information
>    we wouldn't need this.
> 
> My sense is that while (1) and (4) are potentially common to both the
> digital and physical domains, (2) and (3) will necessarily be
> quite different. For instance, draft-adem-wg-adem-tls specifies
> a binding of ADEM to TLS in the NewSessionTicket message, whereas
> in the context of physical assets I've heard people suggest
> QR codes or RFID tags [1].
> 
> 
> NEXT STEPS
> I see that there is some debate about whether we need to address the
> physical domain at all. I don't have an informed opinion on this
> topic, but based on the above it seems to me that (1) the digital
> domain is going to be quite a bit easier and (2) there is a
> well-identified stakeholder (ICRC) which wants to do it and is
> participating on this list. To that end, I think it's worth
> considering whether it would be best for a potential WG to
> start by trying to address the digital domain and then consider
> expanding scope once the easier problem is well understood.
> 
> -Ekr
> 
> 
> [0] I actually think this assumption deserves some examination.  There
> aren't really any technical mechanisms that stop me from painting a
> red cross on a military target. Rather, there are legal restrictions
> on doing so. It's not entirely clear to me from reading the
> various documents people have pointed to why that's insufficient in
> the digital domain. It would certainly be much easier to design
> a system like this if it just allowed for unverifiable claims
> about the protected status of some asset.
> 
> [1] I'm not sure if RFID tags can be covertly verified.
> _______________________________________________
> Diem mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]