Early Review of draft-ietf-dnssd-pairing-00
review-ietf-dnssd-pairing-00-secdir-early-kent-2016-12-15-00

sent to authors on 12/5, but I forgot to copy the list ...

----

I generated an early review of this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written with the intent of improving security
requirements and considerations in IETF drafts.  Comments not addressed in last
call may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call
comments.

This document proposes a mechanism for a pair of (human-operated) devices to
establish a secure binding to one another. The binding must put in place crypto
keys that enable authenticated, encrypted communication between the devices.
There is also a desire to establish device IDs that will hide the identities of
these devices from other entities.

The document is written in the style of a paper that might appear in  a
conference proceedings. If it were destined to become an informational RFC that
would be OK. However, the style seems inappropriate for a standards track
document. I suggest splitting the i-D into two documents: sections 1-3 could
become an informational RFC. Sections 4, and 5 could become a standards track
document. With references to the former, informational document as needed.

Section 2 provides a statement of the problem, examines requirements for
candidate solutions, and discusses why existing pairing mechanisms are not
perceived as adequate. It notes that the goal of this mechanism is to be
independent of underlying (local net) technology, in contrast to extant
BlueTooth and WiFi pairing protocols. The authors want a solution that works
over any IP-capable network, and which addresses UI limitations that have
arisen in previously-proposed mechanism. This section provided a detailed
analysis of the perceived shortcomings of existing pairing methods, including
susceptibility to MITM attacks. They plan to effect discovery of the devices to
be paired, using DNS service discovery, making use of either “friendly” or
random names, depending on the context in which the pairing takes place. The
authors elect to use TLS with extensions for short authentication string
verification, and “commit before disclose” mechanisms. The section ends with an
explanation of why they reject the use of QR codes. The arguments presented
here seem a bit weak, compared to those in prior subsections. In particular,
they note that a MITM attack can cause the procedure to fail, and thus prevent
it from being fully automated. Although that’s true, one might argue that in
the vast majority of cases there will be no MITM, and thus the procedure will
be simpler for most users almost all of the time.

Section 3 provides an overview of the pairing mechanism design. The design is
separated into three phases: (device) discovery, (key) agreement, and
authentication.

I was a bit surprised to see the discovery phase discuss optional use of QR
codes, after Section 2.7 criticized them, but their use here is limited to
device discovery. The authors the observe  that QR codes are attractive here if
supported by both devices; I agree with this sentiment. The non-QR approach
relies on DNS-SD, which is not required if QR codes are employed. The agreement
phase also offers two options: one uses short authentication strings and the
other uses QR codes. The discussion of intra-user pairing (where one user
controls both devices) introduces the notion of using an USB device to create
an OOB channel. This seems somewhat at odds with the prior discussions where
the focus is on a user reading a display or using a camera to acquire a QR code
from a display. This subsection needs more work, as the authors note. There is
also a very brief discussion of how a user might leverage pairing with one
device from a friend into pairing with other devices associated with the same
individual. This seems like a useful feature, but the discussion here is too
brief.

Section 4 presents the solution selected by the authors. As the authors note at
the beginning of this section, it needs more work. The structure of the section
is good, dividing the solution description into  discovery vs. agreement and
authentication. Use of existing, standard mechanisms (DNS-SD and mDNS) for
discovery seems reasonable, with use of a QR code as an optional OOB method.
(As the authors note, the format for the QR code data needs to be specified.)

Use of TLS 1.2 for the agreement and authentication also seems like a good
choice. However, the specification seems to be a bit too flexible here, in some
respects. For example, the TLS cipher suite TLS_DH_anon_WITH_AES_256_CBC_SHA256
is a SHOULD, not a MUST, which means that the text does not mandate any cipher
suite as MTI, hence no guarantee of interoperability. The admonition contained
here to upgrade to TLS 1.3 isn’t useful in a standards track document, as there
is not yet an RFC for that protocol.

The Security Considerations section (5) notes the requirement to maintain
privacy by hiding the pairing between devices, and states that the chosen
discovery mechanism does that. It would be good to remind the reader of the
assumed context associated with this assertion; specifically, the client and
user are in close, physical proximity and thus a human user can visually
acquire and verify the pairing information. In a more general context the use
of DNS probably would not confer the desired privacy.

There is mention of the need for nodes to store the shared secret “safely” and
the need to be able to “quickly revoke” a compromised pairing. Absent
illustrative examples, the quoted terms are ambiguous.

_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir