Re: [TLS] Short Authentication Strings for TLS

["Christian Huitema" <[e-mail]>]

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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >