[Diem] Re: [EXT] Re: Some high-level thoughts on scoping
Samit D_CUNHA <sdcunha@icrc.org> Mon, 01 July 2024 17:30 UTC
Return-Path: <sdcunha@icrc.org>
X-Original-To: diem@ietfa.amsl.com
Delivered-To: diem@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C773C1519B4 for <diem@ietfa.amsl.com>; Mon, 1 Jul 2024 10:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qnSWtb82WKd for <diem@ietfa.amsl.com>; Mon, 1 Jul 2024 10:30:52 -0700 (PDT)
Received: from mx002.icrc.org (mx002.icrc.org [80.94.146.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5009C18DB89 for <diem@ietf.org>; Mon, 1 Jul 2024 10:30:51 -0700 (PDT)
Received: from icrc.org (localhost [127.0.0.1]) by mx002.icrc.org (Mission Control Email Gateway, 430) with ESMTP id 4WCY3Z211yz4wwfZ; Mon, 1 Jul 2024 19:30:50 +0200 (MEST)
X-AM-Authentication-Results: icrc-mx001-ch-gen-2; arc=none (no signatures found); dkim=none (no signatures found); x-aligned-from=pass (Address match); x-google-dkim=none (no signatures found); x-return-mx=pass header.domain=icrc.org policy.is_org=yes (MX Records found: mx001.icrc.org,mx002.icrc.org); x-return-mx=pass smtp.domain=icrc.org policy.is_org=yes (MX Records found: mx002.icrc.org,mx001.icrc.org); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256
Authentication-Results: icrc-mx001-ch-gen-2; x-local-ip=pass
Authentication-Results: icrc-mx001-ch-gen-2; dkim=none
From: Samit D_CUNHA <sdcunha@icrc.org>
To: Mallory Knodel <mknodel@cdt.org>, Felix Linker <linkerfelix@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [Diem] Re: [EXT] Re: Some high-level thoughts on scoping
Thread-Index: AQHay9FE2HOYj7cCJUeBP90oUviKS7HiGwEg
Date: Mon, 01 Jul 2024 17:30:48 +0000
Message-ID: <0ef04f88a01749499e6af4213c1b158c@icrc.org>
References: <CABcZeBNxiUuXRykDSZ8rZ64JNKUgO76Ztdd7JwQv-RTqMgyDQg@mail.gmail.com> <C4F779D8-D854-43FA-AA2B-965382DB66EF@gmail.com> <CABcZeBPrpYY8=B8e7XsjnmwDHYbfu2H7NR3P6oFAedzfV8QkYQ@mail.gmail.com> <CF20AA14-151A-485E-959A-CDD5C28A3298@gmail.com> <00162839c1504ea588c59c66508f8e97@icrc.org> <66b35a0a-044a-47e1-b20b-7b3701044b42@cdt.org>
In-Reply-To: <66b35a0a-044a-47e1-b20b-7b3701044b42@cdt.org>
Accept-Language: en-GB, fr-CH, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.15.251]
Content-Type: multipart/related; boundary="_005_0ef04f88a01749499e6af4213c1b158cicrcorg_"; type="multipart/alternative"
MIME-Version: 1.0
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.4 cv=EKDN0EZC c=1 sm=1 tr=0 ts=6682e7c9 a=24553Z0vYNJfZF/Cf4o7IA==:117 a=xqWC_Br6kY4A:10 a=ciN7x6iuT_QA:10 a=4kmOji7k6h8A:10 a=prvSpTE5AAAA:8 a=2B3Y0BStAAAA:8 a=vnREMb7VAAAA:8 a=yXOkaXPSAAAA:8 a=pGLkceISAAAA:8 a=5IsXbjgYAAAA:8 a=48vgC7mUAAAA:8 a=VqAVYmfgAAAA:8 a=wpjqGOILMbNEZjBL_VYA:9 a=QEXdDO2ut3YA:10 a=0P_WyqUejeEA:10 a=B8P2TArViYkA:10 a=-FEs8UIgK8oA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=M6wjoDlfumEIynD9AgQA:9 a=jCaIzIGHiY0jG3lR:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=lqcHg5cX4UMA:10 a=VtIp_ulkjrpNm3hUoAUA:9 a=HXjIzolwW10A:10 a=T6a71-JsGAwA:10 a=JybXOZJJHF7kLPj-BvEA:9 a=SL0DBEudqwAVvfeYPbae:22 a=OqxJBAXuVNdbzA9fgvOY:22 a=ATNfu2mDe1gJ-4-DuY-F:22 a=RR2nPHISKLg-FD_FhCoU:22 a=w1C3t2QeGrPiZgrLijVG:22 a=uO96pGx9uCvlhYk8XcFZ:22 wl=host:39
X-EXP-RefID: 155804::1719855049-4A903629-96511AE6/0/0
X-EXP-Verdict: none
X-LASED-Version: Antispam-Engine: 5.1.3, AntispamData: 2024.7.1.170616
X-LASED-SpamProbability: 8
X-LASED-Hits: HTML_00_01 0.050000, HTML_00_10 0.050000, SUPERLONG_LINE 0.050000
Received: received from trusted host by mx002.icrc.org with SMTP id 4WCY3Y1jwgz4wwfZ; Mon, 1 Jul 2024 19:30:49 +0200 (MEST)
Message-ID-Hash: A4WXPCMOFPIQL5Q4R2X4XBHOTM5F5OUC
X-Message-ID-Hash: A4WXPCMOFPIQL5Q4R2X4XBHOTM5F5OUC
X-MailFrom: sdcunha@icrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "diem@ietf.org" <diem@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Diem] Re: [EXT] Re: Some high-level thoughts on scoping
List-Id: Discussion of digital emblems <diem.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/diem/R0JeIlDtfseI3IROu7V7L6NpODQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/diem>
List-Help: <mailto:diem-request@ietf.org?subject=help>
List-Owner: <mailto:diem-owner@ietf.org>
List-Post: <mailto:diem@ietf.org>
List-Subscribe: <mailto:diem-join@ietf.org>
List-Unsubscribe: <mailto:diem-leave@ietf.org>
Dear Mallory,
That’s an excellent question. Here are some of the things we’ve been working on:
1. Indeed, the technical development and legal/policy process has in a way been mutually reinforcing, but also co-dependent. We don’t advance on the tech without first consulting with States on their needs and requirements to digitalize the Red Cross, Crescent, and Crystal, as well as consulting more broadly with the movement of the RCRC (ICRC + International Federation of the Red Cross and Red Crescent Societies + the 191 national societies that are part of the federation today).
2. Last week, we held a technical meeting open to all States to formally present ADEM to them as a possible solution so we could receive feedback from them. We’ve consulted bilaterally with States in all continents of the world.
3. In fall of this year, we will hold a legal and diplomatic meeting open to all States to consider the various avenues for incorporation into IHL.
* One possibility is an amendment of the Annex of the First Additional Protocol to the Geneva Conventions. Article 98 of API says, in part, “…at intervals of not less than four years, the International Committee of the Red Cross shall consult the High Contracting Parties concerning Annex I to this Protocol and, if it considers it necessary, may propose a meeting of technical experts to review Annex I and to propose such amendments to it as may appear to be desirable… Amendments to Annex I may be adopted at such a conference by a two-thirds majority of the High Contracting Parties present and voting.”
* We have other formal proposals that we are discussing with States, including a possible new Protocol specifically for the digital emblem.
* There are other possible solutions too, e.g. what we call special agreements or unilateral declarations, for the DE’s deployment.
* The decision of States will, in part, rest of what the technical solution is for digitalizing the RCRCRC– and this is why we see the work of the IETF is so important for this process – truthfully, the ICRC doesn’t itself have the technical knowledge to develop this solution on its own. We are relying on a whole new group (for us) of stakeholders to try and solve this problem together and to be honest, are eternally grateful for the interest we’ve seen so far. The ICRC’s work with States is primarily confidential and bilateral, but looking at the geopolitical state of affairs today, it is hardly a shock to say that today, more than ever, the need for a digital RCRCRC is pressing.
4. This year is an International Conference year (https://rcrcconference.org/) The conference takes place once every four years. At this year’s conference, we are proposing a resolution to welcome the ongoing work on the Digital Emblem (see https://rcrcconference.org/app/uploads/2024/06/34IC-Draft-zero-resolution-ICT-June2024-EN.pdf, operative paragraph #11); there is one resolution for States and the Movement, and one only for the Movement (at a separate but related meeting called the Council of Delegates).
Hope this is helpful. Happy to discuss more in Vancouver. Thanks again for the helpful question. Best,
Samit
Samit D’Cunha
Legal Advisor
[cid:image001.png@01DACBED.2CD86DC0]
International Committee of the Red Cross
19, avenue de la Paix 1202 Geneva Switzerland
Email: sdcunha@icrc.org<mailto:sdcunha@icrc.org>
As societies digitalize, cyber operations are becoming a reality of armed conflict. Learn more about the Digital Emblem Project<https://www.youtube.com/watch?v=VpaXOAv3DpQ&ab_channel=InternationalCommitteeoftheRedCross%28ICRC%29> here!
From: Mallory Knodel <mknodel@cdt.org>
Sent: lundi, 1 juillet 2024 18:11
To: Samit D_CUNHA <sdcunha@icrc.org>; Felix Linker <linkerfelix@gmail.com>; Eric Rescorla <ekr@rtfm.com>
Cc: diem@ietf.org
Subject: Re: [Diem] Re: [EXT] Re: Some high-level thoughts on scoping
Dear Samit,
Thank you for that explanation. I hesitate to call it a metaphor when the task ahead is to explicitly digitalise an analog equivalent.
To that end, can you share more on the progress being made-- if any-- on the expansion of international humanitarian law to cover the digitalisation of the emblem? Ideally the technical and the legal efforts are in tight conversation with one another so that this effort is fit for purpose.
Thanks,
-Mallory
On 7/1/24 11:33 AM, Samit D_CUNHA wrote:
Hi Eric, hi Felix,
I just want to jump in on the red paint point – yes, you’re absolutely right, it’s ultimately “easy” to just paint red on your roof. That’s why the distinctive emblem (ie. red cross/crescent/crystal) was conceptualized from the start as needing to be strictly regulated by States under international law. In some ways, it was the impetus for establishing what we refer to today as International Humanitarian Law. States are required for example to suppress violations or misuse of the distinctive emblem. Certain misuses of the emblem (for example using that red paint to paint a red cross and mislead the adversary to then kill or injure them) is a grave breach of the Geneva conventions; a war crime.
I can’t yet say how this translates into cyberspace, but within the context of conflict, to take this metaphor further, misuse of the emblem is not suppressed by regulating red paint. Anyone has access to red paint. It’s by regulating red painters.
For this and other reasons, for the digital emblem to actually be used during armed conflict, it would of course need to either be incorporated into international law, or deployed or operationalized through some diplomatic process, which is the part of the project that I am leading, in consultation with States and other stakeholders.
Cheers,
Samit
PS. I’m not able to follow all discussion here – if anyone has any substantive questions on the law, on the distinctive emblem, etc., please do feel free to reach out to me directly!
From: Felix Linker <linkerfelix@gmail.com><mailto:linkerfelix@gmail.com>
Sent: lundi, 1 juillet 2024 15:30
To: Eric Rescorla <ekr@rtfm.com><mailto:ekr@rtfm.com>
Cc: diem@ietf.org<mailto:diem@ietf.org>
Subject: [EXT] [Diem] Re: Some high-level thoughts on scoping
CAUTION: This email originated from outside the ICRC. If you can't recognize the sender, avoid clicking links or opening attachments. In case of query, please contact the ServiceDesk.
Hi Ekr,
On 1 Jul 2024, at 15:17, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
On Mon, Jul 1, 2024 at 6:09 AM Felix Linker <linkerfelix@gmail.com<mailto:linkerfelix@gmail.com>> wrote:
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.
Well, that's also the case with the red paint, no?
In the digital world, it’s (in general!) much easier to claim that „I didn’t send this bit string!“, whereas in the physical world, if I painted a Red Cross on my balcony, I’d have a hard time explaining to the police that I didn’t put it there. Probably, some law would require me to do my due diligence of guarding my property and removing illegal things.
I added „in general.“ Of course, if emblems were distributed solely by authenticated channels like TLS, then this would change the argument. But I doubt that all use-cases can be addressed by TLS (to be discussed at a point where we decided on the problem to solve).
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.
Thanks for the explanation. A few thoughts:
1. This seems like a rather narrower goal than that which ADEM seems to embody. As I understand ADEM, these certificates also contain endorsements from third parties (e.g., ICRC). Presumably, this is intended to embody authorization to display an emblem, not just after the fact punishment.
2. "Non-repudiation" is a technical property, but it's not clear to me that it's really required for after the fact accountability. We fairly routinely attribute people's online behavior to them based on much weaker non-cryptographic evidence.
1. That is true! There are two concepts to distinguish. What makes a valid emblem under, e.g., the ADEM specification, and what makes an emblem that many people will find trustworthy (i.e., they won’t attack an asset marked with such an emblem). The ADEM spec permits you to deploy emblems without authorization, but it recommends that you do not and also add endorsements from third parties (in order to be more trustworthy).
2. Yes, I see your point. Worthy to be discussed once a problem scope has been decided.
Best,
Felix
-Ekr
Best,
Felix
On 29 Jun 2024, at 23:32, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> 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 -- diem@ietf.org<mailto:diem@ietf.org>
To unsubscribe send an email to diem-leave@ietf.org<mailto:diem-leave@ietf.org>
________________________________
The ICRC - working to protect and assist people affected by armed conflict and other situations of violence. Find out more: www.icrc.org<http://www.icrc.org>
This e-mail is intended for the named recipient(s) only.
Its contents are confidential and may only be retained by the named recipient(s) and may only be copied or disclosed with the consent of the International Committee of the Red Cross (ICRC). If you are not an intended recipient please delete this e-mail and notify the sender.
________________________________
_______________________________________________
Diem mailing list -- diem@ietf.org<mailto:diem@ietf.org>
To unsubscribe send an email to diem-leave@ietf.org<mailto:diem-leave@ietf.org>
--
Mallory Knodel
CTO :: Center for Democracy and Technology
newsletter :: https://internet.exchangepoint.tech
===============================================================================
The ICRC - working to protect and assist people affected by armed conflict and
other situations of violence. Find out more: www.icrc.org
This e-mail is intended for the named recipient(s) only.
Its contents are confidential and may only be retained by the named recipient
(s) and may only be copied or disclosed with the consent of the International
Committee of the Red Cross (ICRC). If you are not an intended recipient please
delete this e-mail and notify the sender.
===============================================================================
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Mauro Vignati
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Mauro Vignati
- [Diem] Re: Some high-level thoughts on scoping Bill Woodcock
- [Diem] Some high-level thoughts on scoping Eric Rescorla
- [Diem] Re: Some high-level thoughts on scoping Orie Steele
- [Diem] Re: Some high-level thoughts on scoping Felix Linker
- [Diem] Re: Some high-level thoughts on scoping Serge Droz
- [Diem] Re: Some high-level thoughts on scoping Felix Linker
- [Diem] Re: Some high-level thoughts on scoping Eric Rescorla
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Samit D_CUNHA
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Samit D_CUNHA
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Samit D_CUNHA
- [Diem] Re: Some high-level thoughts on scoping Eric Rescorla
- [Diem] Re: Some high-level thoughts on scoping Dennis Jackson
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Serge Droz
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Mallory Knodel
- [Diem] Re: [EXT] Re: Some high-level thoughts on … Mallory Knodel
- [Diem] Re: [EXTERNAL] Re: [EXT] Re: Some high-lev… Tommy Jensen