Re: [TLS] Short Authentication Strings for TLS

"Christian Huitema" <huitema@huitema.net> Mon, 12 September 2016 16:38 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E538812B333 for <tls@ietfa.amsl.com>; Mon, 12 Sep 2016 09:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmT4n7gCFlbr for <tls@ietfa.amsl.com>; Mon, 12 Sep 2016 09:38:46 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2A212B43B for <tls@ietf.org>; Mon, 12 Sep 2016 09:32:52 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.85) (envelope-from <huitema@huitema.net>) id 1bjUA5-0005ut-3I for tls@ietf.org; Mon, 12 Sep 2016 18:32:50 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bjU9z-0004EG-P8 for tls@ietf.org; Mon, 12 Sep 2016 12:32:47 -0400
Received: (qmail 6414 invoked from network); 12 Sep 2016 16:32:42 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.159.4]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <daniel.kaiser@uni-konstanz.de>; 12 Sep 2016 16:32:41 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Hannes Tschofenig'" <hannes.tschofenig@gmx.net>, <tls@ietf.org>, <imiers@cs.jhu.edu>, <mgreen@cs.jhu.edu>, "'Eric Rescorla'" <ekr@rtfm.com>
References: <BN6PR03MB2675BA146E2ACC19C754B2DCA8150@BN6PR03MB2675.namprd03.prod.outlook.com> <d86c3983-46a2-f0fe-63ae-ade0a8928fc4@gmx.net>
In-Reply-To: <d86c3983-46a2-f0fe-63ae-ade0a8928fc4@gmx.net>
Date: Mon, 12 Sep 2016 09:32:40 -0700
Message-ID: <070401d20d13$488fa980$d9aefc80$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdH5ctgVeV1w1b1MRb+YwaKtrD5LxwRM350AAJp71XA=
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hqjz rBJMgr2mlZXTglAdtdfYE9Fbxkt4a9zS8Otup7TRGlugeeYNRP+TKatltgBEa+jOO+5k046wqf0S EutzqoPubplnbiDyBMUiEvUZuPnV+6xPoqikFlxGE5ethSvjIJZI+lxcZnIhduMqXEDVCZfDqcig OvSxdRnthmhn8Zn6/V+lKE29jDglu10LFa9wy1PsH1QqniimNy9qh2Eko/GUK0vciBekfU6mwXfa SylRGLKn1meRR/jcOZCTAzGMwRMKuUeqX+EE9ftsEQ35CMRUE7Q9WvntXa9VPL9K4cA+8t3Xj/Lz Z5s/OJg1L2asZxEp4Bv7TWEUoKzFQfrYUezLRF4P3cD+yYsyYy0PbXJivfXYa4zafYJGo76gRHJN CirkfYeKydSIUY0HOcUIkoTyqcuDRIDLibiQ8pjP/rLDACMyE+XhWF028w059hjlWNOITDa6LxNU +V0EKPyMEBMkrKDU4kfxpqT7+EMydLi7baW0KlbI7odCZa1sbCHLgYdIPjNne2wo+JnzUL4YmPar JORNVBNenpsQr686JX7e
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.230
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.21)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HfqrvPY0ZRlPg9-QVaTOHOjahME>
Cc: 'Daniel Kaiser' <daniel.kaiser@uni-konstanz.de>
Subject: Re: [TLS] Short Authentication Strings for TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2016 16:38:48 -0000

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
> >