On Friday, September 9, 2016 7:28 AM, Hannes Tschofenig wrote: > ... > Hi Christian, > > could you provide a bit more background why you are working on such a > solution?
Daniel and are working on "privacy for DNS-SD discovery." Daniel presented in Berlin this draft: https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. The private discovery solution relies on pre-existing pairings, which provide shared keys between paired devices. The working group consensus was to adopt the work on private discovery, but to separate the pairing work in a different work item. The pairing algorithms typically combine the establishment of a shared secret through an [EC]DH exchange, with the verification of that secret through display and comparisons of "Short Authentication String" (SAS). The secure comparison requires a "commit before disclose" mechanism. We have three possible designs: create a pairing algorithm from scratch, specifying our own crypto exchanges; use an [EC]DH version of TLS to negotiate a shared secret, export the key to the application, and implement the "commit before disclose" and SAS verification as part of the pairing application; or, use TLS, integrate the "commit before disclose" and SAS verification as TLS extensions, and export the verified key to the application. I would rather not create an algorithm from scratch. We would need to reinvent a lot of the negotiation capabilities that are part of TLS, not to mention algorithm agility, post quantum, and all that sort of things. EKR pointed me towards the expired draft by Ian Miers, Matthew Green and him: https://tools.ietf.org/html/draft-miers-tls-sas-00. It is a very close match to our third design option, full integration of SAS in TLS. Hence the interest. Of course, we could also use the middle ground option -- use TLS for [EC]DH, and implement the SAS verification as part of the pairing application. We need to export the key from TLS to the pairing context in any case. The middle ground option would only require us to implement a couple of hashes. The downside is that we would need to negotiate the hash algorithm, unless maybe we can export that too from the TLS context. And then, there are the typical implementation issues. Application level minimizes the dependency on TLS implementing the extensions, but increases the risk of doing it wrong. And vice versa. -- Christian Huitema > On 08/18/2016 07:47 PM, Christian Huitema wrote: > > Daniel Kaiser and I are working on a “pairing” specification in the > > context of DNS SD. Short Authentication Strings are one of the preferred > > methods for verifying pairings. I would like to use TLS as much as > > possible in the pairing protocol. EKR pointed me to the expired draft by > > Ian Miers, Matthew Green and him: > > https://tools.ietf.org/html/draft-miers-tls-sas-00. I am interested in > > reviving that draft. > > > > > > > > The draft implements a classic “coin flipping” protocol into TLS, using > > a “commit before disclose” logic to prevent Nessie from hiding as an > > MITM between Alice and Bob. From my superficial reading, this looks > > fine. I could use a reference to > > http://people.csail.mit.edu/shaih/pubs/hm96.pdf, both to explain why the > > attack by Halevi and Micali does not apply to this particular construct, > > and also to provide a 20 years old reference to similar algorithms, > > which may be useful in this day and age. > > > > > > > > One nit, though. If Nessie has infinite computing resource, she can > > build a catalog of multiple random values that all hash to the same > > string, and then use that catalog to work around the commitment > > protocol. The scheme in the draft prevents that attack by using a hash > > keyed with the master secret, which defeats catalog attacks, and also by > > limiting the length of the nonce to be below the length of the hash, > > which in theory prevents collision attacks. Explaining that would be neat. > > > > > > > > As I said, I am interested in reviving that draft, and adapting it to > > TLS 1.3. Does someone else share the feeling? > > > > > > > > -- Christian Huitema > > > > > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
