Re: [DNSOP] Proposal for a new record type: SNI

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 20 February 2017 20:39 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2BE1294B9 for <dnsop@ietfa.amsl.com>; Mon, 20 Feb 2017 12:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dSQxbswuNVlu for <dnsop@ietfa.amsl.com>; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D13129480 for <dnsop@ietf.org>; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id v200so55146990ywc.3 for <dnsop@ietf.org>; Mon, 20 Feb 2017 12:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=I5ZDvlutjMpjsP3qysM4ojF5z0pqZT/0VacMyUQh7Sg=; b=MOn9in3yqaiDOxe/oa6xGbK134OSCPtdXkchmOWuCO0bebH8VAkNcK2IWpuU83Ubdd nvoHIoQhHw8BOVkesfwFWQcqQmz7kUH3TkfEuLym0//UHZueZNdX++okj/lyc4uqhoTV SgA4C/0o62ibD/M141sG11eptpx5+FCbBv8+uwkkpDLrf1GTygdmlb1nFMIzJYzcZ/pE iNHJcRU4fV5z9haTC8BA/bfqJ62D595SrPuqSfz8p033xepYjcqIga+4UzuwoPR4gKkR /j1Tv1Vds4c44+mZxDP9Vk2uSDnIEM93GNfxBR12ubPwIpkvztLLyRdtO64i9tPC7xKJ rb6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=I5ZDvlutjMpjsP3qysM4ojF5z0pqZT/0VacMyUQh7Sg=; b=L3fjU8pdsF2I7hmnMZi/S3Sppm2cNRLbTskf8P3h5t+OxR74I2qZECW/XC2ps2idp/ lkMEkbJPePRorbwv3pq/hsJ412FnjGH0pQCqSHCFHkbblOmJWcwQnEqPrnRQWl3I5Mwn iegez+MG1rcfFNn8ldqFCfYVtR0lSqkdtMQLrTVdjFjmgf4uYAETcdEtFSMZsOql9wzd 6FFPyYNqWnGGt0JiwkPQLvB/clkp2aJuGnbjOFVtq/bPW2ETpmyiOE3z6OZgHgamxsTG hGf5ftNp8VqwG2/6dDFIucVhqdcR53LaD51V7eIRajISR2or5F1YUywYQaZiuKoaWYTs hMMw==
X-Gm-Message-State: AMke39lud/42QK+lxU1+YgL3i8QkLGEVT/C4tc+LZBMt7lVLmMG2mXqFKLZL2sAZz1TjK1nC0efxmqU2aLT8MQ==
X-Received: by 10.129.101.195 with SMTP id z186mr17060267ywb.340.1487623175295; Mon, 20 Feb 2017 12:39:35 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.83.17.140 with HTTP; Mon, 20 Feb 2017 12:39:34 -0800 (PST)
In-Reply-To: <alpine.DEB.2.11.1702201458030.23970@grey.csi.cam.ac.uk>
References: <CAHbrMsA278usgFNzxhrsLS6_EfXPeMoAKN65ec0YhCW93oKNYg@mail.gmail.com> <20170217220309.9637.qmail@ary.lan> <CAHbrMsAdgRU6g4E6wCCA0zs6p=yTU4VJE3UWzvsuU5JAtnxaWQ@mail.gmail.com> <alpine.OSX.2.20.1702172143530.94448@ary.qy> <CAHbrMsApypey9WRvFMzAPupjmts-sdG9N=zuwtP=PZ1cxV=rvg@mail.gmail.com> <alpine.OSX.2.20.1702182014260.99706@ary.qy> <alpine.DEB.2.11.1702201458030.23970@grey.csi.cam.ac.uk>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 20 Feb 2017 15:39:34 -0500
X-Google-Sender-Auth: xRF5_ZZCeOrNxGJofcMKd6POttM
Message-ID: <CAMm+LwjzZ0M4Yt6bpWKXCuKw_Tq4MYNUNTAwNX5azKnCOEDHQg@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Content-Type: multipart/alternative; boundary=001a114c6c9cec6d840548fc4215
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/baS5RY_2WRKmE8CObf7-Y4rODqE>
Cc: Ben Schwartz <bemasc@google.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 20:39:38 -0000

I really don't like the proposal at all. The idea of beginning the TLS
handshake in DNS is sound. But it is a completely new handshake and
authentication layer.

Right now we have a bit of a mess with service discovery. We have a solid
proposal that makes sense written up as a standard and we have a lot of
folk saying we should do something different, either for legacy reasons or
because they find it impure.

The solid proposal is as follows:

* Discover all services using SRV *without exception*

* Use TXT records to provide additional data *that is required for
discovery and binding*

* TXT records may be bound to the service definition, thus covering all
hosts or be bound to a specific host instance.

* Domain names used for services MAY use CNAME or DNAME. Domain names that
identify services MUST NOT.

* Treat everything else as legacy. Expect Port numbers to be supplanted by
SRV prefixes. Accept that TLSA is dead. Don't tilt at windmills with yet
more discovery schemes.

I see a distinction between Hosts and Services. An internet service is
defined by an SRV prefix. A Host has a unique IP address and may support
multiple services which may also share ports.

If the objective is to conceal the service name being connected to, it
follows that any key used to conceal the service negotiation must be bound
to the host rather than the service.

The protocol that these constraints points to would use a lightweight key
agreement with a client supplied nonce and a host specific DNS key to
protect the initial TLS key agreement and then feed that key as one of the
inputs into the KDF for the service level key agreement.

One bonus of this approach is that if you don't care about authentication,
you can dispense with the service authentication altogether and use
encryption based on the host encryption alone. TLS is designed to provide
service authentication that is its purpose and the reason for most of the
complexity.