Re: No Phone Home statement by ACLU, EFF, Brave, CDT, etc.

Andrew, I was curious why it’s “recommended” in ISO 18013-5 but not
optional. You mention “several reasons”. Can you elaborate? It wasn’t clear
to me from the spec.


On Thu, Jun 5, 2025 at 7:26 AM Andrew Hughes <andrewhughes3000@gmail.com>
wrote:

> Server retrieval in ISO 18013-5 is not required for conformance. It is
> recommended (for several reasons) which, using language from other
> standards bodies vocabularies means "SHOULD".
>
> If you can point out to all of us where server retrieval is "mandatory to
> implement", we'd be grateful, and will gladly be corrected.
> andrew.
> ————————
> *Andrew Hughes *CISM
> m +1 250.888.9474
> AndrewHughes3000@gmail.com
>
>
>
> On Thu, Jun 5, 2025 at 7:01 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On Wed, Jun 4, 2025 at 3:24 PM Matteo Frigo <matteof@google.com> wrote:
>> > We believe that a zero-knowledge presentation of the credential, like
>> the scheme we presented to this forum a few weeks ago, would solve this
>> problem.
>>
>> It would, I don't think you would get much push back on that concept.
>>
>> The "No Phone Home" statement is about something slightly different,
>> though, Matteo. It is calling attention to the fact that a global
>> standards organization has created a mechanism that explicitly
>> mandates phoning home in verifiers, and that functionality can be
>> turned on and off dynamically, without the user's knowledge. Even if a
>> ZK presentation system were to exist, the ability of this alternate
>> system to exist and be adopted is still out there.
>>
>> So, we're talking about two related, but mostly independent things.
>>
>> > Are people aware of any attacks that we have not considered?
>>
>> The approach that you and Abhi presented is very exciting to many of
>> us. Many of us do see how it technically addresses one of the biggest
>> problems we're all facing (the ECDSA infrastructure problem). That
>> said, it is very early days and the number of people that understand
>> the processes, optimization points, and cryptography are quite small.
>> It is difficult for many of us to do an analysis because we're all
>> having to come up to speed to understand the entire stack.
>>
>> We are meeting to discuss the approach regularly on Fridays in this
>> community, but its slow going because of the lack of access to experts
>> with the particular approach and having to slog through all the
>> optimization variations.
>>
>> I still need to formulate the questions we need to ask of you and Abhi
>> on what the optimization pain points are.
>>
>> The biggest issue, however, is the time it is going to take to get
>> nation state cryptographic standards organizations to pick it up and
>> use it... any of it. I see the timeline for doing this in years,
>> unless they decide to fast track your proposal in the EU or US. You
>> would have a better understanding of what is going on to make this
>> happen, though my interactions w/ the US side of things are not
>> showing that they're anywhere close to accepting any ZK approaches
>> just yet (they want to see full post-quantum resistance... that is ZK
>> applied to a post-quantum signature).
>>
>> So, the biggest "attack" I see right now is the very slow speed at
>> which nation state standardization bodies work and the general lack of
>> interest they seem to have in privacy preserving cryptography. A
>> number of key individuals I have spoke with care about high-stakes use
>> cases, and for those, they don't see the point in privacy preserving
>> cryptographic protocols. So, unless there is more pressure on use of
>> ZK to protect citizen privacy from the legislative layer... which the
>> EU digital wallet stuff might create... I don't see this moving
>> quickly.
>>
>> > Irrespective of this specific server-retrieval attack, if one is
>> worried about the issuer instructing the relying party to track certain
>> users, it seems to me that any non-ZK presentation is vulnerable to this
>> kind of attack, and that this is not a MDOC-specific problem.
>>
>> Server retrieval is an ISO-18013-5 specific problem. It is true that
>> other digital credential formats could decide to implement server
>> retrieval, but the main point is that they have very specifically NOT
>> done so because they knew how dangerous and privacy invasive dynamic
>> server retrieval would be to an ecosystem. mDL is unique in mandating
>> server retrieval for verifiers, and that's the primary thing that some
>> people were concerned about during IIW.
>>
>> > For example, a sufficiently malicious issuer who wants to instruct
>> relying parties to track certain users could keep generating (r, s) ECDSA
>> signatures until hash(r,s)=0xdeadbeef, and this particular hash would be
>> used by relying parties to phone home the issuer.
>>
>> That's a different attack than server retrieval. It is possible, but
>> the main point of the "no phone home" statement is about server
>> retrieval... not failures at the cryptographic layer, which as you
>> say, are important to protect against as well.
>>
>> > Even with BBS+, if the issuer has a choice of which key to use for the
>> BBS signature, a sufficiently malicious issuer could use a particular key
>> for all users it wants to track, and instruct relying parties to track
>> users that present that key.
>>
>> Yes, legitimate attack that we should protect against, but again, this
>> is not dynamic server retrieval. Dynamic server retrieval is about a
>> standard explicitly telling a verifier how to phone home. It is
>> standardizing phone home, which is the primary concern the "no phone
>> home" statement is attempting to address. It's instructing governments
>> to NOT adopt technology that does this because not using the feature
>> is "privacy by policy". What that group is arguing for is more along
>> the lines of "privacy by cryptography", which is what the solution you
>> and Abhi are pushing for... as are many of the rest of us. The
>> statement is saying that "privacy by policy" is a dangerous way to
>> design identity systems.
>>
>> Does that make sense, Matteo? I don't think most would disagree with
>> many of your assertions, but your assertions are about something other
>> than dynamic server retrieval.
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> https://www.digitalbazaar.com/
>>
>>