Subject: [dnssd] Pairing Issue: Users might press OK, without actually looking at the SAS

From: Daniel Kaiser <[email-masked]>
Date: Tue, 16 Jan 2018 20:14:44 +0100

[pairing issue 1](https://github.com/huitema/pairing/issues/1)

TL;DR
---

* this is just a UI issue that does not require changes in the protocol
* we could change the "cheatable" compare & confirm UI to a copy & enter UI
* our SAS based solution is better suited as it is not dependent on
pre-existing passwords
  (PAKE achieves authenticity using a pre-existing password, while
manual authentication achieves authenticity by a "personal meeting")

Longer Version:
---

The SAS pairing method we describe in our draft is subdivided into three
phases:

* discovery
* pairing data exchange
* manual authentication

Only the manual authentication phase influences the UI; it is
independent of the other two phases.
The manual authentication again can be subdivided into SAS
representation --- e.g. representing the
SAS as alphanumeric string, as a QR code, or as something more exotic ---
and the SAS verification method.
In our draft, we describe the compare & confirm verification method on a
alphanumeric SAS representation.
The compare & confirm method is indeed "cheatable" by the users of the
pairing devices but has proven to be the most comfortable one.
We can, however, use a copy & enter verification method, which demands
the users to read the SAS representation from one device
and enter it into the second device. This would result in the same UI
that a J-PAKE based protocol would use.

## Comparison

Both methods, ours and J-PAKE, offer secure device pairing.
Both do not depend on a short PIN that is instrumental in the key
generation.

Among the advantages over the respective other protocol family are (I
might add more later...):

### Manual SAS Authentication Methods

* do not need any pre-existing (fixed) passwords
* allow for various verification methods (among them the most convenient
methods: compare & confirm and QR codes)

### PAKE Methods

* do not require an out-of-band channel that grants authenticity (e.g.
the devices "meeting in person")

## Discussion

>From a UI point of view, both methods can offer the copy & enter method.
We do not need to switch to PAKE for offering this.
However, only the SAS method offers the more convenient methods, among
them QR codes (unless the App manages the PAKE passwords).

Further, as a pairing method in the DNS-SD/mDNS area, manual SAS
authentication methods are better suited because they are not dependent on
a pre-existing password.
Using J-PAKE for the pairing of two smart phones, the users of these two
devices need a pre-existing password.
This poses a new question: How do these users agree on a password.
The sociallist millionaires protocol could be used to this end, but it
is less convenient for users than verifying an SAS.

While PAKE achieves authenticity using a pre-existing password, Manual
Authentication achieves authenticity by a "personal meeting".
For the DNS-SD/mDNS area, where devices are assumed be be relatively
close to each other, the "personal meeting" poses way less
overhad than the need for pre-existing passwords.

## Additional: Fixed PIN

Devices that do not feature a display and come with a fixed PIN allow
only for a lower level of privacy because each
device pairing with that device uses the same PIN.
We should treat the case of a fixed PIN separately.

Regarding (fixed) PIN based protocols, it is important that the PIN is
not instrumental in the key generation and just serves authentication
purposes.
PAKE protocols fulfill that, but they do not offer an authenticated PIN
exchange; the PIN (password) is expected to already be known to the
pairing parties.

## Questions

* Should we stick to our Manual SAS Authentication method? (I am in
favor of sticking to it for the afore stated reasons.)
* If yes, should we specify the verification method in the draft?
* If yes, should we specify both compare & confirm and copy & enter
(both could co-exist)?
* If not, which one should we choose?
* Should we specify the use of fixed PINs in this pairing draft?