Subject: [secdir] Fw: early SECDIR review of draft-dnssd-pairing-00.txt

From: Steve KENT <[email-masked]>
Date: Tue, 13 Dec 2016 18:31:04 +0000

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
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir