Subject: [dns-privacy] DNS stamps

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 9 Jan 2020 15:35:54 +0100

Could be useful specially for secure and public resolvers, may be
worth of some IETF work?

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 08:13:47 -0800

> Could be useful specially for secure and public resolvers, may be

In order for this to actually be useful, two things would be required.

1. The assertions about resolver behavior (e.g., logging, etc) would have to be signed
2. The signature would have to be validatable back to a specific entity that is legally competent to make promises
3. There would have to be some legal mechanism, whether actual law or precedent, saying that these assertions, when made by competent legal entities, constitute a contract.
4. It would have to be possible to automatically determine based on some trust model that a particular identity corresponded to an entity that qualified under (2)
5. Someone(s) would have to operate (4)

So basically this document does just the easy part, and none of the hard part.   And the bulk of the hard part is probably out of scope for the IETF, although a model like ACME could work.

I’m not arguing for or against doing this, but let’s be clear about how much work it is and what kind of work it is! :)

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 9 Jan 2020 18:21:15 +0100

These stamps do contain interesting ideas, I believe.

On 1/9/20 5:13 PM, Ted Lemon wrote:
> [...]

Depends what you'd want from the stamps.  If the main point is to
configure by an URI that's easy to copy&paste, I don't think you really
need these details.  I imagine you'd copy it from an https site of the
operator or got through another trusted (chain of) means.  And I'd
certainly not expect binding such format to some legal mechanisms,
etc... perhaps you could just add policy and some "small print" legalese
to that site as well.

Someone would need to "author" it here.  I don't expect DNSCrypt people
to push it forward within IETF.  I'm not sure what would happen if WG
decides to change the format in an incompatible way, but perhaps that
could be avoided.

BTW, do we want to keep this (whole) thread in *both* mailing-lists at once?

--Vladimir

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 09:37:38 -0800

On Jan 9, 2020, at 9:21 AM, Vladimír Čunát <[email-masked]> wrote:
> Depends what you'd want from the stamps.

If the stamps make assertions about what service is offered, I’d want that to be verifiable.  Otherwise, I can send you a stamp that makes promises I don’t intend to keep, and there’s no signature on it, so you have no reason to complain when I don’t do what I said I would.   So what’s the point, in that case, of making promises?   It’s like the “please respect my privacy” browser bit.   Useless.

---

From: Vladimír Čunát <[email-masked]>
Date: Thu, 9 Jan 2020 19:22:46 +0100

On 1/9/20 6:37 PM, Ted Lemon wrote:
> On Jan 9, 2020, at 9:21 AM, Vladimír Čunát <[email-masked]
> <mailto:[email-masked]>> wrote:
> If the stamps make assertions about what service is offered, I’d want
> that to be verifiable.  [...]

I'd personally have stamps without these assertions (or without giving
them any weight).

I see a bigger problem that some of desired assertions are in principle
unverifiable, e.g. "no logging".  Of course, we could (optionally)
extend the string by a signature, but I suspect that'd increase the
length a lot without sufficient gain in exchange.

---

From: Dan Wing <[email-masked]>
Date: Fri, 10 Jan 2020 09:45:53 -0800

On Jan 9, 2020, at 10:22 AM, Vladimír Čunát <[email-masked]> wrote:
> I see a bigger problem that some of desired assertions are in principle unverifiable, e.g. "no logging".  Of course, we could (optionally) extend the string by a signature, but I suspect that'd increase the length a lot without sufficient gain in exchange.

The signature could be retrieved and validated separately from the stamp itself.  For example, after getting the DNS stamp, retrieve a well-known DNS object (TXT, new RR, whatever) which is signed by the external entity.  That would keep the signature short and keep the problem away from the signature.  With that, DoH could obtain the signature from the TLS certificate itself, if we wanted, rather than by retrieving a (DNS) object

-d

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2020 10:03:32 -0800

> The signature could be retrieved and validated separately from the stamp itself.  For example, after getting the DNS stamp, retrieve a well-known DNS object (TXT, new RR, whatever) which is signed…

Sure, if the stamp had a validation process, that would address one of the issues I raised.   :)