Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok

From: Christopher Wood <[email-masked]>
Date: Mon, 25 Feb 2019 19:55:37 -0800

(Paging back in discussions from the meeting...)

On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <[email-masked]> wrote:
>
> I'm a little unclear what is being considered single-stage vs two-stage. How is single-stage able to send encrypted without knowing the destination? Is it encrypting a query with an asymmetric private key and multicasting? Or does single-stage refer to the predictable nonce approach? I was considering predictable nonce's two-stage because it has to first discover known peer service instances (stage 1) then perform encrypted queries/responses (stage 2).

If I understand and remember correctly, the single stage approach
would encrypt the service ID in the first query using the recipient's
public key, along with the predictable nonce generated using the
sender's public key. The response would contain the address of the
service in question. If we are concerned with the dictionary attack
mentioned earlier, a second round is required.

I assume the joint design with you, Christian, and Daniel will attempt
to find an appropriate balance here.

Best,
Chris

> Regarding the discussion:
>
> 1. Server mode. My proposal doesn't have a good way to support it. Normal server mode wasn't an important use case for me, but sleep proxy support would be nice. I just don't know how to do it yet, at least not without giving the sleep proxy your keys.
>
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is each device advertising a service instance for each pairing. The network I'm on now has 300+ devices and if each one has 50 friends, that's 15000 service instances on the network, which seems very high.
>
> I tried to reduce this by each device only advertising itself via multicast and then everything else is unicast. The first part of key exchange was also rolled into the advertisement packet to allow a single query packet and single response packet while still maintaining forward secrecy and per-pairing confidentiality.
>
> 3. CPU cost. This seems to be a comparison between more packets, but lower per-packet cost (in the per-pairing service instance model where predictable nonce hashes are precomputed) vs fewer packets, but more expensive per-packet signature verification. The two main use cases I was considering were home networks (where neither traffic nor CPU is likely to be an issue due to the small number of devices) and busy enterprise networks (office, dorm, coffee shop), which I assumed would be more powerful devices (laptops, phones, servers) where reducing traffic would be more important than the CPU usage for checking multicast probes.
>
> 4. One privacy concern regarding predictable nonces is that it would allow spoofing. Anyone with your public key could generate your predictable nonce. It could also enable friend relationships to be recovered. Maybe not a huge concern, but something to consider. Even the signature approach has a replay vulnerability, but it's time bounded.
>
> On Nov 14, 2018, at 5:37 PM, David Schinazi <[email-masked]> wrote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s
>
> During that discussion, the room reached consensus on the following items:
>
> 1) single-stage approach -- Up until now, we were considering two approaches: single-stage (send encrypted and authenticated service identifier, receive encrypted and authenticated service response) and two-stage (send encryption and authenticated identifier, receive encrypted and authenticated response, derive secrets, send and receive subsequent queries encrypted using derived secrets). There was consensus in the room to go with the single-stage approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key exchange mechanism such as TLS. There was consensus in the room that we do not need TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all input and compound it into a single document and only advance that one. We will use draft-ietf-dnssd-privacy since that document has already been adopted by the working group. Christian Huitema has offered for Bob Bradley to join as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12-02.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: David Schinazi <[email-masked]>
Date: Tue, 26 Feb 2019 09:35:25 -0800

Thanks for kicking this discussion off again, Chris!

Bob, Christian, is there anything the chairs can do to facilitate making
progress towards a joint proposal before Prague?

Thanks,
David

On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood <
[email-masked]> wrote:

> > I'm a little unclear what is being considered single-stage vs two-stage.
> How is single-stage able to send encrypted without knowing the destination?
> Is it encrypting a query with an asymmetric private key and multicasting?
> Or does single-stage refer to the predictable nonce approach? I was
> considering predictable nonce's two-stage because it has to first discover
> known peer service instances (stage 1) then perform encrypted
> queries/responses (stage 2).
>
> > 1. Server mode. My proposal doesn't have a good way to support it.
> Normal server mode wasn't an important use case for me, but sleep proxy
> support would be nice. I just don't know how to do it yet, at least not
> without giving the sleep proxy your keys.
> >
> > 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is
> each device advertising a service instance for each pairing. The network
> I'm on now has 300+ devices and if each one has 50 friends, that's 15000
> service instances on the network, which seems very high.
> >
> > I tried to reduce this by each device only advertising itself via
> multicast and then everything else is unicast. The first part of key
> exchange was also rolled into the advertisement packet to allow a single
> query packet and single response packet while still maintaining forward
> secrecy and per-pairing confidentiality.
> >
> > 3. CPU cost. This seems to be a comparison between more packets, but
> lower per-packet cost (in the per-pairing service instance model where
> predictable nonce hashes are precomputed) vs fewer packets, but more
> expensive per-packet signature verification. The two main use cases I was
> considering were home networks (where neither traffic nor CPU is likely to
> be an issue due to the small number of devices) and busy enterprise
> networks (office, dorm, coffee shop), which I assumed would be more
> powerful devices (laptops, phones, servers) where reducing traffic would be
> more important than the CPU usage for checking multicast probes.
> >
> > 4. One privacy concern regarding predictable nonces is that it would
> allow spoofing. Anyone with your public key could generate your predictable
> nonce. It could also enable friend relationships to be recovered. Maybe not
> a huge concern, but something to consider. Even the signature approach has
> a replay vulnerability, but it's time bounded.
> >
> > 1) single-stage approach -- Up until now, we were considering two
> approaches: single-stage (send encrypted and authenticated service
> identifier, receive encrypted and authenticated service response) and
> two-stage (send encryption and authenticated identifier, receive encrypted
> and authenticated response, derive secrets, send and receive subsequent
> queries encrypted using derived secrets). There was consensus in the room
> to go with the single-stage approach.
> >
> > 2) Use of TLS -- The single-stage approach no longer requires a key
> exchange mechanism such as TLS. There was consensus in the room that we do
> not need TLS as part of this protocol.
> >
> > 3) Evolution of documents -- It was proposed that we would take all
> input and compound it into a single document and only advance that one. We
> will use draft-ietf-dnssd-privacy since that document has already been
> adopted by the working group. Christian Huitema has offered for Bob Bradley
> to join as co-author if Bob would like.
> >

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 10:34:47 -0800

I think we understand the envelope of the solutions, but we have to
stabilize three design choices first:

1) Is the server mode important for the scenarios that we are thinking
about?

2) Do we care about compatibility with the existing DNS-SD formats?

3) Do we want private discovery to work as a system component, or as an
app library? (a.k.a. per device or per app.)

We can easily write a spec that works without server mode, using binary
formats, and runs as an app library. That's basically Bob's design, with
an optional tweak to add an hint and minimize the CPU cost of trial
decryption. We could also tweak the same spec and make it somehow fit in
DNS formats, with a liberal usage of TXT records, but I don't know
whether that's justified. We do not have a consensus on a server based
solution, let alone on a server based solution that would reuse DNS
servers. 

Basically, the best way for the chairs and the working group to help is
to focus the work on a key scenario, and answer the three questions above.

-- Christian Huitema

On 2/26/2019 9:35 AM, David Schinazi wrote:
> Bob, Christian, is there anything the chairs can do to facilitate
> making progress towards a joint proposal before Prague?
>
> Thanks,
> David
>
> On Mon, Feb 25, 2019 at 7:56 PM Christopher Wood
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Wed, Nov 14, 2018 at 9:36 PM Bob Bradley <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > I'm a little unclear what is being considered single-stage vs
>     two-stage. How is single-stage able to send encrypted without
>     knowing the destination? Is it encrypting a query with an
>     asymmetric private key and multicasting? Or does single-stage
>     refer to the predictable nonce approach? I was considering
>     predictable nonce's two-stage because it has to first discover
>     > 1. Server mode. My proposal doesn't have a good way to support
>     it. Normal server mode wasn't an important use case for me, but
>     sleep proxy support would be nice. I just don't know how to do it
>     yet, at least not without giving the sleep proxy your keys.
>     >
>     > 2. Multicast traffic. One problem I saw with
>     draft-ietf-dnssd-privacy is each device advertising a service
>     instance for each pairing. The network I'm on now has 300+ devices
>     and if each one has 50 friends, that's 15000 service instances on
>     the network, which seems very high.
>     >
>     > I tried to reduce this by each device only advertising itself
>     via multicast and then everything else is unicast. The first part
>     of key exchange was also rolled into the advertisement packet to
>     allow a single query packet and single response packet while still
>     maintaining forward secrecy and per-pairing confidentiality.
>     >
>     > 3. CPU cost. This seems to be a comparison between more packets,
>     but lower per-packet cost (in the per-pairing service instance
>     model where predictable nonce hashes are precomputed) vs fewer
>     packets, but more expensive per-packet signature verification. The
>     two main use cases I was considering were home networks (where
>     neither traffic nor CPU is likely to be an issue due to the small
>     number of devices) and busy enterprise networks (office, dorm,
>     coffee shop), which I assumed would be more powerful devices
>     (laptops, phones, servers) where reducing traffic would be more
>     important than the CPU usage for checking multicast probes.
>     >
>     > 4. One privacy concern regarding predictable nonces is that it
>     would allow spoofing. Anyone with your public key could generate
>     your predictable nonce. It could also enable friend relationships
>     to be recovered. Maybe not a huge concern, but something to
>     consider. Even the signature approach has a replay vulnerability,
>     but it's time bounded.
>     >
>     > On Nov 14, 2018, at 5:37 PM, David Schinazi
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > Hello everyone,
>     >
>     > 1) single-stage approach -- Up until now, we were considering
>     two approaches: single-stage (send encrypted and authenticated
>     service identifier, receive encrypted and authenticated service
>     response) and two-stage (send encryption and authenticated
>     identifier, receive encrypted and authenticated response, derive
>     secrets, send and receive subsequent queries encrypted using
>     derived secrets). There was consensus in the room to go with the
>     single-stage approach.
>     >
>     > 2) Use of TLS -- The single-stage approach no longer requires a
>     key exchange mechanism such as TLS. There was consensus in the
>     room that we do not need TLS as part of this protocol.
>     >
>     > 3) Evolution of documents -- It was proposed that we would take
>     all input and compound it into a single document and only advance
>     that one. We will use draft-ietf-dnssd-privacy since that document
>     has already been adopted by the working group. Christian Huitema
>     has offered for Bob Bradley to join as co-author if Bob would like.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: David Schinazi <[email-masked]>
Date: Wed, 27 Feb 2019 12:17:54 -0800

Thanks for writing this up Christian.

I went through the minutes of our last in-person meeting in Bangkok
<https://datatracker.ietf.org/meeting/103/materials/minutes-103-dnssd> and
while we did not
explicitly ask for consensus then, I got a feeling that the sense in the
room was:

1) Is the server mode important for the scenarios that we are thinking
about?
    - No one in the room came out strongly in favor of server mode
    - Server mode would add complexity

    My personal recommendation: we declare server mode out of scope for now.

2) Do we care about compatibility with the existing DNS-SD formats?
    - No one in the room came out strongly in favor of this
    - It was mentioned it would be nice to have but not critical
    - This would cause some security tradeoffs regarding hash size

    My personal recommendation: we declare compatibility with existing
formats out of scope for now.

3) Do we want private discovery to work as a system component, or as an app
library? (a.k.a. per device or per app.)
    - We had briefly discussed this at IETF 100 in Singapore following
Stuart's discussion of requirements:

https://tools.ietf.org/html/draft-cheshire-dnssd-privacy-considerations-01#section-3
    - I recall there was support in the room for having finer granularity
such as per-app

    My personal recommendation: we focus on per-app for now.

Based on the above, as chair, I'm proposing we move forward with a reduced
scope solution for now,
that is without server mode, using binary formats, and runs as an app
library.
To clarify, this wouldn't mean we won't try to build a follow-up solution
for those requirements later,
this is just meant as framing to help us make progress towards a concrete
proposal.

Please share your opinions on this potential approach.

Thanks,
David

On Wed, Feb 27, 2019 at 10:35 AM Christian Huitema <[email-masked]>
wrote:

> formats, and runs as an app library. That's basically Bob's design, with an
> optional tweak to add an hint and minimize the CPU cost of trial
> DNS formats, with a liberal usage of TXT records, but I don't know whether
> that's justified. We do not have a consensus on a server based solution,
> let alone on a server based solution that would reuse DNS servers.
>
> Basically, the best way for the chairs and the working group to help is to
> focus the work on a key scenario, and answer the three questions above.
>
> -- Christian Huitema
>
>
>> two-stage. How is single-stage able to send encrypted without knowing the
>> destination? Is it encrypting a query with an asymmetric private key and
>> multicasting? Or does single-stage refer to the predictable nonce approach?
>> I was considering predictable nonce's two-stage because it has to first
>> discover known peer service instances (stage 1) then perform encrypted
>> > 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy
>> is each device advertising a service instance for each pairing. The network
> dnssd mailing [email-masked]://www.ietf.org/mailman/listinfo/dnssd
>
>

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 12:26:48 -0800

On Wed, Feb 27, 2019 at 12:18 PM David Schinazi
<[email-masked]> wrote:
> I went through the minutes of our last in-person meeting in Bangkok and while we did not
> explicitly ask for consensus then, I got a feeling that the sense in the room was:
>
> 1) Is the server mode important for the scenarios that we are thinking about?
>     My personal recommendation: we declare compatibility with existing formats out of scope for now.
>
> 3) Do we want private discovery to work as a system component, or as an app library? (a.k.a. per device or per app.)
>     - We had briefly discussed this at IETF 100 in Singapore following Stuart's discussion of requirements:
>     - I recall there was support in the room for having finer granularity such as per-app
>
> Based on the above, as chair, I'm proposing we move forward with a reduced scope solution for now,
> that is without server mode, using binary formats, and runs as an app library.
> To clarify, this wouldn't mean we won't try to build a follow-up solution for those requirements later,
> this is just meant as framing to help us make progress towards a concrete proposal.
>

+1

This sounds reasonable to me!

Best,
Chris

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 14:17:11 -0800

OK. My next question is then how much commonality we want to have with TLS.

All solutions in this space involve sending a broadcast query that asks
whether some peer is present. The query is secured using some secret
only known to the peers. From the previous discussions, we sort of
agreed that this secret should be a "discovery public key", with the
special twist that this public key should in fact be kept secret. The
exchange would typically be an ECDH exchange, something like that:

* Client broadcast a query, containing its own ECDH half key, a nonce, a
proof, and possibly a hint.

* The proof is secured by a "discovery secret", obtained by combining
the ECDH half key and the server's discovery key. The optional hint is a
cryptographic hash of the coarse time and the discovery secret

* All servers get the message. If the hint is present they can verify
that the query targets them. If no hint is expected, or if the hint
matches, they compute the discovery secret and verify the nonce. If it
is not verified, they just drop the message.

* The responding server confirms the connection, sends its own ECDH half
key, derives a handshake secret, etc.

I notice that this is extremely similar to the TLS handshake, and
especially to the QUIC or DTLS handshakes when using ESNI encryption.
One simple way to deliver the functionality would be, just define a TLS
extension for the "discovery proof". And with that, we would have a
secure and private way to establish a DTLS session or a QUIC connection.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 16:31:48 -0800

> secure and private way to establish a DTLS session or a QUIC connection.

I think this highlights an important difference between the two
proposals on the table. Namely, whether or not service discovery
happens in one or two RTTs or stages. The design you sketch above
permits 1-RTT discovery at the cost of lesser security. (The service
ID is not encrypted, thereby permitting dictionary attacks as we
discussed.) Bob's proposal addresses this by first doing a mutually
authenticated key exchange and then querying for the service in the
second trip.

While no one was opposed to the two stage approach during the last
meeting, I'm not sure we should rule it out. It depends on the threat
model.

So, having said all that, perhaps someone can take a stab at
documenting the threat model here? That might help us choose a
solution given a shared understanding of the problem. I'm happy to
give it a shot.

Best,
Chris

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 16:45:37 -0800

> solution given a shared understanding of the problem. I'm happy to

Or perhaps we can short circuit that discussion entirely and simply
get consensus around the crux of the issue: is the WG comfortable with
the one stage approach and the possible attack(s), or do we think two
stages should be used? I'm quite curious to hear what others think.

Best,
Chris

---

From: David Schinazi <[email-masked]>
Date: Wed, 27 Feb 2019 16:48:42 -0800

<chair hat off>
Given that our main target is local networks, I personally believe spending
an extra round trip to prevent dictionary attacks sounds worth it.

David

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 17:20:37 -0800

> stages should be used? I'm quite curious to hear what others think.

The service ID is in fact encrypted, ESNI stands for "encrypted SNI".
Clearly, this requires TLS 1.3, to guarantee that the server's
parameters are encrypted -- we would not want the server's certificate
in the clear. But we are looking at a direct connection over a local
network, without expected interference from firewalls and other
middle-boxes.

If we align with TLS, we benefit from all the security analysis done for
TLS, and all the design work done for ESNI. I am looking at doing a
prototype using the Picoquic implementation of QUIC and the Picotls TLS
stack, and I think I could have a demo in Prague -- looks like a great
hackathon project. The work is fairly minimal:

1) At the client, provision the server discovery key out of band at
authorized clients, instead of the DNS lookup of the ESNI key of the
client facing server in the standard implementation;

2) At the server, accept the first packet in the exchange over a
broadcast channel,

3) At the server, discard all ClientHello packets that do have an ESNI
extension demonstrating knowledge of the service discovery key by the
client,

4) At the client, latch on the IP address and port of the response.

The ESNI proposal already has a bunch of provisions for securing the
exchange, such as copying a nonce in the server response to demonstrate
that the server correctly decrypted the ESNI.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 17:25:54 -0800

> The service ID is in fact encrypted, ESNI stands for "encrypted SNI".

Ah, well I was operating under the assumption that we were *not* using ESNI.

What is in the discovery proof, then?

> Clearly, this requires TLS 1.3, to guarantee that the server's parameters are encrypted -- we would not want the server's certificate in the clear. But we are looking at a direct connection over a local network, without expected interference from firewalls and other middle-boxes.
>
> If we align with TLS, we benefit from all the security analysis done for TLS, and all the design work done for ESNI. I am looking at doing a prototype using the Picoquic implementation of QUIC and the Picotls TLS stack, and I think I could have a demo in Prague -- looks like a great hackathon project. The work is fairly minimal:
>
> 1) At the client, provision the server discovery key out of band at authorized clients, instead of the DNS lookup of the ESNI key of the client facing server in the standard implementation;
>
> 2) At the server, accept the first packet in the exchange over a broadcast channel,
>
> 3) At the server, discard all ClientHello packets that do have an ESNI extension demonstrating knowledge of the service discovery key by the client,
>
> The ESNI proposal already has a bunch of provisions for securing the exchange, such as copying a nonce in the server response to demonstrate that the server correctly decrypted the ESNI.
>
> -- Christian Huitema
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 17:36:46 -0800

On 2/27/2019 4:48 PM, David Schinazi wrote:
> <chair hat off>
> Given that our main target is local networks, I personally believe
> spending an extra round trip to prevent dictionary attacks sounds
> worth it.

I am thinking of using the ESNI extension, or developing a very similar
extension specifically for the purpose of private discovery. The ESNI
extension format is defined in
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as:

      struct {
          CipherSuite suite;
          KeyShareEntry key_share;
          opaque record_digest<0..2^16-1>;
          opaque encrypted_sni<0..2^16-1>;
      } ClientEncryptedSNI;

The service name is encrypted, but we would have to do something to not
reveal the hash of the key in the "record digest". The digest is used by
servers to quickly identify the public key needed to encrypt the service
name, and we don't want that. KeyShareEntry is very much the same
element as the "ephemeral client key" in Bob's draft.

The encrypted structure contains:

      struct {
          ServerNameList sni;
          opaque zeros[ESNIKeys.padded_length - length(sni)];
      } PaddedServerNameList;

      struct {
          uint8 nonce[16];
          PaddedServerNameList realSNI;
      } ClientESNIInner;

Only the server can decrypt that, and echo the nonce in the encrypted
server extension. The Service Name Identification is not sent in the clear.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 17:40:12 -0800

On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <[email-masked]> wrote:
> Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it.
>
> I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 as:
>
>       struct {
>           CipherSuite suite;
>           KeyShareEntry key_share;
> The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest".

This seems to highlight my main reservation about the 1-RTT approach.
I think we ought not to complicate things and just pay the round trip.

Best,
Chris

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 17:58:21 -0800

> I think we ought not to complicate things and just pay the round trip.

My priority there is not the 1 RTT design, but rather the integration
with TLS. I don't like coming up with a new crypto protocol, even when
using well known patterns.

As for the complication, the only requirement is to omit the
record_digest, or redefine it to include a nonce. Apart from that, the
prototype can just reuse the existing code.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 18:04:26 -0800

On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <[email-masked]>
wrote:

> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <[email-masked]> <[email-masked]> wrote:
>
> My priority there is not the 1 RTT design, but rather the integration with
> TLS. I don't like coming up with a new crypto protocol, even when using
> well known patterns.
>

That’s a fair concern. Note that I’m not advocating for something that’s
not TLS. I’m simply advocating for something that’s not one stage.

As for the complication, the only requirement is to omit the record_digest,
> or redefine it to include a nonce. Apart from that, the prototype can just
> reuse the existing code.
>

The record digest is required to prevent downgrade attacks in the normal
ESNI case. Depending on how the keys are installed, it may be fine to omit
here.

Can you please be specific for how you expect this optional nonce to work?
It would help this discussion, I think.

Thanks,
Chris

---

From: Bob Bradley <[email-masked]>
Date: Wed, 27 Feb 2019 19:32:50 -0800

> On Feb 27, 2019, at 6:04 PM, Christopher Wood <[email-masked]> wrote:
> 
> On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <[email-masked]> <mailto:[email-masked]> wrote:
>>> I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 <https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1> as:
>>> 
>>>       struct {
>>>           CipherSuite suite;
>>>           KeyShareEntry key_share;
>>>           opaque record_digest<0..216-1>;
>>>           opaque encrypted_sni<0..216-1>;
>>>       } ClientEncryptedSNI;
>>> 
> My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.
> 
> 
> That’s a fair concern. Note that I’m not advocating for something that’s not TLS. I’m simply advocating for something that’s not one stage.

I may be missing something, but the TLS/ESNI approach seems to assume you already know the peer you want to communicate with and their IP address to make a TLS connection. For local network communication, you would need some earlier message exchange, such as normal mDNS to discovery that info.

The main reason for the first message (multicast probe) in my proposal was to enable the initial discovery of peers (before any specific queries). Since that message needed to be sent anyway, before any unicast messages could be sent, it included an ephemeral key to also act as the first round of key exchange (1 multicast out, N unicast in).

Since I also wanted to keep the query itself confidential between the two peers (friend A can't decrypt my queries to friend B), the sender couldn't encrypt with its public key unless it include a separate, encrypted query for every peer in its database (likely prohibitive). Given those requirements, the initial multicast probe reduces the number of messages rather than adding additional round trips.
> As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that the prototype can just reuse the existing code.
> 
> 
> The record digest is required to prevent downgrade attacks in the normal ESNI case. Depending on how the keys are installed, it may be fine to omit here. 
> 
> Can you please be specific for how you expect this optional nonce to work? It would help this discussion, I think.
> 
> Thanks,
> Chris
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 19:37:37 -0800

On 2/27/2019 6:04 PM, Christopher Wood wrote:
>>>               opaque record_digest<0..2^^16 -1>;
>>>               opaque encrypted_sni<0..2^^16 -1>;
>>>           } ClientEncryptedSNI;
>>>
>     My priority there is not the 1 RTT design, but rather the
>     integration with TLS. I don't like coming up with a new crypto
>     protocol, even when using well known patterns.
>
>
> That’s a fair concern. Note that I’m not advocating for something
> that’s not TLS. I’m simply advocating for something that’s not one stage.
>
>     record_digest, or redefine it to include a nonce. Apart from that,
>     the prototype can just reuse the existing code.
>
>
> The record digest is required to prevent downgrade attacks in the
> normal ESNI case. Depending on how the keys are installed, it may be
> fine to omit here. 
>
> Can you please be specific for how you expect this optional nonce to
> work? It would help this discussion, I think.

In the ESNI design, the digest is used to verify that the client is
using the published keys and algorithms. We are concerned that DNS
spoofing could enable a downgrade attack, e.g. using an old key now
deemed insecure, or using the same key but with downgraded parameters.
The digest protects the integrity of the transmission between DNS server
and client. Since we don't plan using the DNS, we do not really have
that concern.

In the discussions in Bangkok, we mentioned a "hint", so servers could
rapidly discard requests that are "not for me". In the old proposal, the
nonce was the truncated 64 bit Unix time -- setting the 5 least
significant bits to zero -- and the proof was a hash of the 7 bytes and
the shared secret -- in our case, that would be the public key of the
server. The nonce only changes every 30 seconds or so. Servers have to
compute that proof only once every 30 seconds, which limits the
potential for DOS attacks.

The clients compute the nonce before sending the message. The server
evaluate first whether the nonce has the right format, starts with the
truncated current time plus or minus some estimate of clock drift. If
that passes, the server compares to the pre-computed proof, or compute
it if the clock is in a new interval. If that passes, the server
processes with ESNI decryption, and verifies that the service name is
what it expects.

Of course, we could assume that the discovery key is passed to the peer
in exactly the same format as ESNI:

    struct {
        uint8 checksum[4];
        KeyShareEntry keys<4..2^16-1>;
        CipherSuite cipher_suites<2..2^16-2>;
        uint16 padded_length;
        uint64 not_before;
        uint64 not_after;
        Extension extensions<0..2^16-1>;
    } ESNIKeys;

Hashing that with the nonce will alleviate concerns about clients using
the wrong cipher suite, or the wrong padding length.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 20:15:31 -0800

On Wed, Feb 27, 2019 at 7:37 PM Christian Huitema <[email-masked]>
wrote:

> In the ESNI design, the digest is used to verify that the client is using
> the published keys and algorithms. We are concerned that DNS spoofing could
> enable a downgrade attack, e.g. using an old key now deemed insecure, or
> using the same key but with downgraded parameters. The digest protects the
> integrity of the transmission between DNS server and client. Since we don't
> plan using the DNS, we do not really have that concern.
>
> nonce was the truncated 64 bit Unix time -- setting the 5 least significant
> bits to zero -- and the proof was a hash of the 7 bytes and the shared
> secret -- in our case, that would be the public key of the server. The
> nonce only changes every 30 seconds or so. Servers have to compute that
> proof only once every 30 seconds, which limits the potential for DOS
> attacks.
>
> truncated current time plus or minus some estimate of clock drift. If that
> passes, the server compares to the pre-computed proof, or compute it if the
> clock is in a new interval. If that passes, the server processes with ESNI
> decryption, and verifies that the service name is what it expects.
>
> Of course, we could assume that the discovery key is passed to the peer in
> exactly the same format as ESNI:
>
>     struct {
>         uint8 checksum[4];

Okay, so, as I suspected, this is vulnerable to dictionary attacks if the
public key is leaked. Am I misunderstanding? If so, can you explain why
this is not the case?

Thanks,
Chris

--Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 27 Feb 2019 21:43:37 -0800

On 2/27/2019 8:15 PM, Christopher Wood wrote:

> Okay, so, as I suspected, this is vulnerable to dictionary attacks if
> the public key is leaked. Am I misunderstanding? If so, can you
> explain why this is not the case?

If the public key is leaked, anyone with the leaked key can impersonate
an authorized client, establish a connection, etc. The secrecy of the
public key is what keeps this together. In all these schemes, there has
to be a secret that acts as the seed for the privates exchanges, and in
the scheme I propose that secret is the public discovery key of the server.

-- Christian Huitema

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Feb 2019 22:25:04 -0800

> the scheme I propose that secret is the public discovery key of the server.

Right! That confirms what I said above. Thanks for clarifying.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Feb 2019 09:28:53 -0500

> the scheme I propose that secret is the public discovery key of the server.

Since we have extensive public training that the "public key" is safe to
disclose, this may be confusing for many, as this is no longer the case for this.

May I suggest different terminology?  As the two halves of asymmetric keying
systems are mathematically equivalent, so maybe we could call it the
client-dual-key or something like that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 Feb 2019 10:03:14 -0800

On 2/27/2019 10:25 PM, Christopher Wood wrote:
>
>
> On Wed, Feb 27, 2019 at 9:43 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>

And thanks for clarifying the dictionary attack concern. I was blinded
by the "all bets are off" assumption. If the discovery key of the
service is known by attackers, then the attackers can detect the
presence of the service in a local network. They indeed can, but all
bets are not off. The attackers have to mount an active attack. They
have to attempt a discovery and see whether the service is present and
replies. If we use hints, they can perform a passive dictionary attack,
e.g. browsing logs of traffic and detecting whether the service was
present. The all bets are off assumption is wrong, we have to think of
defense in depth.

Bottom line, the ESNI based solution should use a static proforma
"record_digest", or no record digest at all. No hints, just use trial
decryption, like Bob proposed.

If we become concerned about the cost of trial decryption, we can start
playing with time windows. Many scenarios have a "meeting" structure, "A
meets B and they discover each other". We can arrange mitigations around
that, e.g. only perform trial decryption when the app is actively
waiting for connections.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 Feb 2019 10:05:19 -0800

> client-dual-key or something like that.

It is a server key, not a client key, but I see the issue. I was
thinking of using "discovery key". Would that work?

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 28 Feb 2019 17:34:25 -0500

I probably don't have all the context, but when I start hearing about keeping public keys secret, I always think "why not a PSK?"  Is there a reason that wouldn't work here also?  A PSK ensures that only those who have the key can see that the query is for an entity with the PSK.  You could use DH as well to make the details of the query confidential from those as well.  You don't get authentication unless you also have an asymmetric key, but that's easily doable (with TLS anyway).

On Fri, Mar 1, 2019, at 05:05, Christian Huitema wrote:
> Attachments:
> * signature.asc

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 Feb 2019 15:03:47 -0800

PSK would indeed work, but it is subject to very bad failure modes. If the PSK is compromised, the attackers can not only track clients and servers, but also impersonate servers.

What would be workable is to treat the PSK ID as a discovery ticket, carrying the client discovery key share. The PSK would be derived from the discovery secret. We would probably need to add a proof in the PSK ID, so broadcast receivers could quickly decide that this is "not for me".

In this design, the service name would not be transmitted at all. No SNI, no ESNI. The handshake key and session key would depend on the PSK, which provides all kinds of guarantees. If forward secrecy is required, use PSK + ECDH.

Structuring the PSK-ID seems ugly, but we do that with STEK based tickets all the time.

That may well be a simpler design than trying to reuse ESNI. It also solves a small hole in the ESNI-based proposal: the session key depends on the ESNI nonce, but the handshake key does not.

-- Christian Huitema 

> On Feb 28, 2019, at 2:34 PM, Martin Thomson <[email-masked]> wrote:
>