[secdir] Advice on pairing specification, TLS, etc.

"Christian Huitema" <huitema@huitema.net> Tue, 04 October 2016 04:40 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8F912940E for <secdir@ietfa.amsl.com>; Mon, 3 Oct 2016 21:40:27 -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 Ql7xI0KNbush for <secdir@ietfa.amsl.com>; Mon, 3 Oct 2016 21:40:25 -0700 (PDT)
Received: from mx36.antispamcloud.com (mx36.antispamcloud.com [209.126.110.250]) (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 385621200DF for <secdir@ietf.org>; Mon, 3 Oct 2016 21:40:24 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1brHWh-0008Qe-4L for secdir@ietf.org; Tue, 04 Oct 2016 06:40:24 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1brHWc-00010M-4S for secdir@ietf.org; Tue, 04 Oct 2016 00:40:22 -0400
Received: (qmail 9047 invoked from network); 4 Oct 2016 04:40:17 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <daniel.kaiser@uni-konstanz.de>; 4 Oct 2016 04:40:17 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: <secdir@ietf.org>
Date: Mon, 3 Oct 2016 21:40:13 -0700
Message-ID: <001f01d21df9$66466f80$32d34e80$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdId9wjlcw7T5rW8SrOHZbiK9XlfbQ==
Content-Language: en-us
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dHEJL963yvZzofOAehTafloeD9ey9972JZ1Xcr1RWHu8UvfgoE7Tx8PYIcekOty5V8/1 7Ag8wtD2TJMLVVqjXv532s4RcMeaqgJ+knaOuDWHUV8ShebT8U8Xw9HTDfreWQUhw0NOE6GJ4h1S yx3SVxwAHipOgYHuTWrgWy9HdVyatXEhj8EK+HsAUQsUJ5UViSERbInMiTBIUBbQ/Dy6Ip65STY7 l95uSQXuDttVfirReN+nPOThvNMbaJkwAzpLvdjedJpPdGd4M3H04f+dLFn3Y80OmAux3oN13+zt UzneQStaz8oVbDEOn0N5SprgYxq5k9b3r8eYLgArMMuSf+d22E6MO50XfD46wv4v/HrW8AUy9fur wzjHps/+CPPDQ5nY6UdwTAUdOhwsK6fGLondgVgKTjt9nKq3Gw+3KmSNlHQHrP4vlFnRrJb8siOD 2YPAgTtUp75uqlx0KezvZHWZkXA2Rzv0GuvoC4ptsIakTG2DhCXROOtiZYOBMnaUKgEiRQv+PVjj wa+Z5RFCOMS3ylvKYrKemIoGlpsypPJAli8SkxIjuZViW+LZJXST85TbLDrPzkvdTIJ076hDdLsR ZMxd0ZLZrOPTv3nlZv/9
X-Report-Abuse-To: spam@mx99.antispamcloud.com
X-Originating-IP: 168.144.250.245
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.61)
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/94qpBqyVhQPoxIveBXdAUn8DkdY>
Cc: 'Tim Chown' <Tim.Chown@jisc.ac.uk>, 'Daniel Kaiser' <daniel.kaiser@uni-konstanz.de>, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: [secdir] Advice on pairing specification, TLS, etc.
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2016 04:40:27 -0000

Sometimes, one thing leads to another. Daniel and I are working in the
DNS-SD working group on a specification for "private discovery". The idea is
that you come to some open space, say a Wi-Fi hot spot, and you can find
your buddies. But the process is kept private, so that third parties cannot
find out who you are, and only your "friends" can discover and access the
services that you are publishing. That was the first thing. It is specified
in https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. But the
specification assumes that the devices that can be discovered have gone
through a "pairing" process, in order to set up some PSK that is then used
to obfuscate the discovery and secure access to the services. Which is how
it led to the next step, specifying a pairing system.

We are giving it a shot. The first version of the pairing draft is at
https://datatracker.ietf.org/doc/draft-kaiser-dnssd-pairing/. It specifies
how to set up a pairing using TLS with [EC]DH anon, then exchange random
numbers using a commitment before disclosure protocol, so that the
verification of a Short Authentication String provides robustness against
MITM. But we have plenty of questions. Should we specify the protocol as an
extension to TLS, as was once proposed in
https://tools.ietf.org/html/draft-miers-tls-sas-00, a draft that is now
expired? Should we use TLS resume tickets instead of passwords? 

The DNS-SD working group is probably not well equipped to look at these
issues. Would some participants to SAAG give us advice?

-- Christian Huitema