Subject: [Dance] No privacy discussion in draft-wilson-dance-architecture

From: Robert Moskowitz <[email-masked]>
Date: Sat, 20 Nov 2021 20:44:42 -0500

I had a discussion with the DANE advocate in iata.org friday.  Some 
things came out of that discussion, many not DANE/DANCE related that I 
need to follow up on.  But...

The discussion triggered a couple thoughts about privacy implications of 
DANCE.  In DANE, you don't 'worry' about privacy for the server's 
existance, as the URL is already in DNS.  But DANCE brings different 
bagage.  Those client devices/identities are all of a suddent public 
information.  There is now a publised URL for your thermostat, etc.  
What are the privacy concerns?  Is rawpublickey better as only the URL 
is revealed and no X.509 baggage with risk of privacy leaks?

With UAS, there is already limited privacy in the public airspace. See 
the privacy discussion in draft-ietf-drip-rid.  Also for exposure of the 
Operator ID and location, see my attempt of adding privacy (that has not 
gained any concern):

https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/

Now on to human identities.  Or at least a start.  The introduction 
mentions human identities in regard to them being in enterprise PKI, and 
then does not touch on human identities elsewhere.  Is DANCE use for 
human identities out-of-scope?  What may be done to either dodge privacy 
for human identities or to make some limited attempt?  Like a public 
official's badge number (e.g. police) could be supported with DANCE?

Bob

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 09:45:39 +0100

> On 21 Nov 2021, at 02:44, Robert Moskowitz <[email-masked]> wrote:
> 
> I had a discussion with the DANE advocate in iata.org friday.  Some things came out of that discussion, many not DANE/DANCE related that I need to follow up on.  But...
> 
> The discussion triggered a couple thoughts about privacy implications of DANCE.  In DANE, you don't 'worry' about privacy for the server's existance, as the URL is already in DNS.  But DANCE brings different bagage.  Those client devices/identities are all of a suddent public information.  There is now a publised URL for your thermostat, etc.  What are the privacy concerns?  Is rawpublickey better as only the URL is revealed and no X.509 baggage with risk of privacy leaks?
I think this has been discussed before when working with email addresses in DANE for email e2e security. If I remember correctly the actual email address wasn’t what was stored but a hash. Maybe Victor has a reference to that document as my google skills fail me.

We haven’t really discussed yet what to store in DNS, the name of the entries if it is personal addresses. The original draft was about IoT device names, which has limited privacy concerns.

> 
> With UAS, there is already limited privacy in the public airspace. See the privacy discussion in draft-ietf-drip-rid.  Also for exposure of the Operator ID and location, see my attempt of adding privacy (that has not gained any concern):
> 
> Now on to human identities.  Or at least a start.  The introduction mentions human identities in regard to them being in enterprise PKI, and then does not touch on human identities elsewhere.  Is DANCE use for human identities out-of-scope?  What may be done to either dodge privacy for human identities or to make some limited attempt?  Like a public official's badge number (e.g. police) could be supported with DANCE?
That is interesting usage and for some usages, like SIP, there will be data with privacy concerns. For me, handling privacy concerns and coming up with some kind of recommendation will be critical.

/O
> 
> Bob
> 
> -- 
> Dance mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dance

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 10:04:44 +0100

> On 22 Nov 2021, at 09:45, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
Monday morning. After a cup of tea the skill level was raised :-)
RFC 7929 - experimental:

" For example, to request an OPENPGPKEY resource record for a user
   whose email address is "[email-masked]", an OPENPGPKEY query would
   be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35
   eec8f72e57f9eec01c1afd6._openpgpkey.example.com".  The corresponding
   RR in the example.com zone might look like (key shortened for
   formatting):
“

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 10:17:26 +0100

> On 22 Nov 2021, at 10:04, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
>> On 22 Nov 2021, at 09:45, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On 21 Nov 2021, at 02:44, Robert Moskowitz <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> I had a discussion with the DANE advocate in iata.org <http://iata.org/> friday.  Some things came out of that discussion, many not DANE/DANCE related that I need to follow up on.  But...
>>> 
>    whose email address is "[email-masked] <mailto:[email-masked]>", an OPENPGPKEY query would
>    eec8f72e57f9eec01c1afd6._openpgpkey.example.com <http://openpgpkey.example.com/>".  The corresponding
>    RR in the example.com <http://example.com/> zone might look like (key shortened for
>    formatting):
> “
> 
Added a pull request on the architecture document.
https://github.com/ashdwilson/draft-dance-architecture/pull/1 <https://github.com/ashdwilson/draft-dance-architecture/pull/1>

/O
>>> https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/ <https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Nov 2021 04:54:35 -0500

Robert Moskowitz <[email-masked]> wrote:
    > DANCE.  In DANE, you don't 'worry' about privacy for the server's existance,
    > as the URL is already in DNS.  But DANCE brings different bagage.  Those
    > client devices/identities are all of a suddent public information.  There is
    > now a publised URL for your thermostat, etc.  What are the privacy
    > concerns?

Based upon how I understand that people want to use TLSA records with DANE,
there will not be a DNS record for *your* thermostat.
If you could/wanted to do that, then you could do some other onboarding and
be done with it.

The situation is that thermostat.example, the maker of your thermostat, would
host "sensor8129546.device.thermostat.example" with some record. (Yes, raw
public key is a possibility)

In your control/authorization system, you would enter the above QNAME, and
then could authenticate that device.  How the device learns to talk to your
authorization system is an open question.  Perhaps it involves phoning home
and learning that it should redirect to your system.

    > Now on to human identities.  Or at least a start.  The introduction mentions
    > human identities in regard to them being in enterprise PKI, and then does not
    > touch on human identities elsewhere.  Is DANCE use for human identities
    > out-of-scope? 

Yes-ish, my understanding is that people would like to use DANCE to do
SMTP-client side authentication to relays.  I don't quite understand how the
laptop/phone to DNS provisioning would work though.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 22 Nov 2021 08:26:31 -0500

On 11/22/21 04:04, Olle E. Johansson wrote:
>>> I had a discussion with the DANE advocate in iata.org 
>>> <http://iata.org> friday.  Some things came out of that discussion, 
>>> many not DANE/DANCE related that I need to follow up on.  But...
>>>
>>> The discussion triggered a couple thoughts about privacy 
>>> implications of DANCE.  In DANE, you don't 'worry' about privacy for 
>>> the server's existance, as the URL is already in DNS.  But DANCE 
>>> brings different bagage.  Those client devices/identities are all of 
>>> a suddent public information.  There is now a publised URL for your 
>>> thermostat, etc.  What are the privacy concerns?  Is rawpublickey 
>>> better as only the URL is revealed and no X.509 baggage with risk of 
>>> privacy leaks?
>> I think this has been discussed before when working with email 
>> addresses in DANE for email e2e security. If I remember correctly the 
>> actual email address wasn’t what was stored but a hash. Maybe Victor 
>> has a reference to that document as my google skills fail me.
> "For example, to request an OPENPGPKEY resource record for a user
>     eec8f72e57f9eec01c1afd6._openpgpkey.example.com  <http://openpgpkey.example.com>".  The corresponding
>     RR in theexample.com  <http://example.com>  zone might look like (key shortened for
>     formatting):
> “
>
> /O

So if you know the identity, you can get the key.  Harvesting FQDN/key 
should not yield Identity.  hmmm.

>>
>> We haven’t really discussed yet what to store in DNS, the name of the 
>> entries if it is personal addresses. The original draft was about IoT 
>> device names, which has limited privacy concerns.

Limited but real.

>>
>>>
>>> With UAS, there is already limited privacy in the public airspace. 
>>> See the privacy discussion in draft-ietf-drip-rid.  Also for 
>>> exposure of the Operator ID and location, see my attempt of adding 
>>> privacy (that has not gained any concern):
>>>
>>> mentions human identities in regard to them being in enterprise PKI, 
>>> and then does not touch on human identities elsewhere.  Is DANCE use 
>>> for human identities out-of-scope?  What may be done to either dodge 
>>> privacy for human identities or to make some limited attempt?  Like 
>>> a public official's badge number (e.g. police) could be supported 
>>> with DANCE?
>> That is interesting usage and for some usages, like SIP, there will 
>> be data with privacy concerns. For me, handling privacy concerns and 
>> coming up with some kind of recommendation will be critical.
>>
>> /O
>>>
>>> Bob

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 14:46:53 +0100

> On 22 Nov 2021, at 14:26, Robert Moskowitz <[email-masked]> wrote:
> 
> 
> 
> So if you know the identity, you can get the key.  Harvesting FQDN/key should not yield Identity.  hmmm.
read the security considerations in that RFC :-)
>>> We haven’t really discussed yet what to store in DNS, the name of the entries if it is personal addresses. The original draft was about IoT device names, which has limited privacy concerns.
Oh, absolutely.

Btw, the pull request has been merged by Ash, so in the next revision we’ll
have a starting point for privacy considerations. Thank you for that feedback!

/O

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Nov 2021 08:52:44 -0500

> Limited but real.

I hope that you'll read my reply to you this morning.

Just because some devices are personal devices does not mean that all devices
are personal devices.   If anything, a huge problem in IoT is that devices
intended (and secured and maintained) for personal use are being used
inappropriately in far more hostile settings.

Many many devices are used in buildings and in industrial uses.

The fact that room 3023 in building F at the university has a thermometer is
not violating anyone's privacy.  (note: I didn't say the readings were public)
So even if the certificate said that, and it was places in the universities'
DNS, wouldn't necessarily be a privacy problem.

Should the documents grow a much clearer applicability? Yes.
But, we are just adopting them.

---

From: Ash Wilson <[email-masked]>
Date: Mon, 22 Nov 2021 08:53:08 -0500

Thanks for the PR Olle. I added a note that privacy protection for certain
identities might be accomplished by hashing part of the identifier (as with
SMIMEA) and only using a hash in the certificate association field instead
of the entire certificate (matching type 1 or 2).
An obvious downside to this approach is that the hash can't be used to
validate a signed message (so you might have to include the public key in
the message itself).

On Mon, Nov 22, 2021 at 8:47 AM Olle E. Johansson <[email-masked]> wrote:

> things came out of that discussion, many not DANE/DANCE related that I need
> to follow up on.  But...
>
> information.  There is now a publised URL for your thermostat, etc.  What
> are the privacy concerns?  Is rawpublickey better as only the URL is
> revealed and no X.509 baggage with risk of privacy leaks?
>
> I think this has been discussed before when working with email addresses
> in DANE for email e2e security. If I remember correctly the actual email
> address wasn’t what was stored but a hash. Maybe Victor has a reference to
> that document as my google skills fail me.
>
> With UAS, there is already limited privacy in the public airspace. See the
> privacy discussion in draft-ietf-drip-rid.  Also for exposure of the
> then does not touch on human identities elsewhere.  Is DANCE use for human
> identities out-of-scope?  What may be done to either dodge privacy for
> human identities or to make some limited attempt?  Like a public official's
> badge number (e.g. police) could be supported with DANCE?
>
> That is interesting usage and for some usages, like SIP, there will be
> data with privacy concerns. For me, handling privacy concerns and coming up
> with some kind of recommendation will be critical.
>
> /O
>
>
> Bob
>
>
>
>
> --
> Dance mailing list
> [email-masked]

-- 

*Ash Wilson * | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Ash Wilson <[email-masked]>
Date: Mon, 22 Nov 2021 09:03:51 -0500

> DNS, wouldn't necessarily be a privacy problem.

It's also worth mentioning that DANE for device identity does not eliminate
the need for a good asset management strategy/system for storing metadata
like device location, capabilities, firmware version, or the technical
staff responsible for ongoing management/maintenance of the device. If I
were (for instance) a member of technical staff under the facilities
management organization, I would want to be able to install or replace a
thermostat without requesting a fresh certificate indicating the location
in which I intend to install it.

Does it make sense to provide a section with examples of the metadata that
make sense to be stored in a certificate, and what makes more sense to put
in the asset management system? Or is that over-thinking?

--

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 15:05:53 +0100

> On 22 Nov 2021, at 15:03, Ash Wilson <[email-masked]> wrote:
> 
> Does it make sense to provide a section with examples of the metadata that make sense to be stored in a certificate, and what makes more sense to put in the asset management system? Or is that over-thinking?

In the guidelines-for-usage-authors document some thoughts on this would be good.

/O

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Nov 2021 09:24:48 -0500 (EST)

On Mon, 22 Nov 2021, Olle E. Johansson wrote:

[ no hats on ]

> I think this has been discussed before when working with email addresses in DANE for email e2e
> security. If I remember correctly the actual email address wasn’t what was stored but a hash. Maybe
> Victor has a reference to that document as my google skills fail me.
> 

Yes, but the hash is not meant as a security/privacy feature. The whole
poinr of OPENPGPKEY was so anyone could be able to find your key. Not to
hide your identity :)

> read the security considerations in that RFC :-)

Yes, I wrote it :)

>                   We haven’t really discussed yet what to store in DNS, the name of the entries if it
>                   is personal addresses. The original draft was about IoT device names, which has
>                   limited privacy concerns.
> 
> 
> Limited but real.
> 
> Oh, absolutely.
> 

I do think this issue is very important. I have seen a number of use
cases that want to level DNS and DNSSEC, but fail on the whole thing
being a public database anyone can query.

>                         With UAS, there is already limited privacy in the public airspace.

Indeed. For something like this, where announcing identity is very much
a requirement, I see no privacy issue. But we do need to take other
uses cases into account where privacy is essential. For instance, I feel
the whole ENUM thing failed because it was a public database keyed on
the 1 piece of information I don't want to share publicly, my phone
number.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Nov 2021 09:28:41 -0500 (EST)

On Mon, 22 Nov 2021, Ash Wilson wrote:

> Thanks for the PR Olle. I added a note that privacy protection for certain identities might be accomplished by hashing
> part of the identifier (as with SMIMEA) and only using a hash in the certificate association field instead of the
> entire certificate (matching type 1 or 2). An obvious downside to this approach is that the hash can't be used to
> validate a signed message (so you might have to include the public key in the message itself).

hashing for OPENPGPKEY / SMIMEA is not a security feature. Hashing will
do almost nothing for privacy. rainbow tables et all can be used to
attack this space.

It would be better to use some kind of throw away pseudeo identity so
that even multiple connections of the same TLS client cannot be
determined to be the same TLS client by an on path observer.

Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Nov 2021 15:29:45 +0100

> On 22 Nov 2021, at 15:24, Paul Wouters <[email-masked]> wrote:
> 
Great to know!

> being a public database anyone can query.
Agree fully, that’s why I wanted to quickly add at least some notes about it in the 
architecture document.

> the 1 piece of information I don't want to share publicly, my phone

In one version of my text (that was later removed) I used that example,
but then thought it was something to point at later. Thanks!

So we need to think about DANCE usages where the identifier needs to be 
found but not exposed. 

/O

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Nov 2021 09:49:09 -0500

This seems like another case where the DNSSEC chain TLS extension is
valuable.  In a deployment or profile where chain inclusion is mandatory,
the TLSA records don't actually have to be resolvable, so the leaf names
could plausibly be kept confidential.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Nov 2021 09:49:47 -0500

> determined to be the same TLS client by an on path observer.

Assuming TLS1.3, if the client validates the server's certificate, isn't the
client certificate or TLSA reference now safe from on-path observers, and
on-path attackers?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Nov 2021 10:03:47 -0500 (EST)

On Mon, 22 Nov 2021, Ben Schwartz wrote:

> Subject: Re: [Dance] No privacy discussion in draft-wilson-dance-architecture
> 
> This seems like another case where the DNSSEC chain TLS extension is valuable.  In a deployment or profile where chain
> inclusion is mandatory, the TLSA records don't actually have to be resolvable, so the leaf names could plausibly be
> kept confidential.

If I understand mTLS (1.3) correctly, the server and client exchange
their identities and extensions before authentication has completed of
the server side by the client. So an on-path attacker would still learn
the client identity. I am not sure how using a tls-dnssec-chain would
hide the client identity more than putting the client identity in the
client certificate? Both seem to be exposed to an on-path attacker at
the same time ?

Although I guess it could be used for a pseudo identity that the client
can use that only the real server, but not an attacker, could look up
in a private only part of the DNS tree. It would still allow tracking
of the client unless it has some kind of throwaway identities it can
use.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Nov 2021 11:33:36 -0500

On Mon, Nov 22, 2021 at 10:03 AM Paul Wouters <[email-masked]> wrote:

> valuable.  In a deployment or profile where chain
> > inclusion is mandatory, the TLSA records don't actually have to be
> resolvable, so the leaf names could plausibly be
> > kept confidential.
>
> the server side by the client.

That is not my impression.  See e.g.
https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/#:~:text=its%20TLS%20certificate-,Client%20verifies%20the%20server%27s%20certificate,-Client%20presents%20its