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

Ben Schwartz <bemasc@google.com> Mon, 20 February 2017 21:08 UTC

Return-Path: <bemasc@google.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 3C81C1294FF for <dnsop@ietfa.amsl.com>; Mon, 20 Feb 2017 13:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 q1e3Vt0BcYe5 for <dnsop@ietfa.amsl.com>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 B002E1294B9 for <dnsop@ietf.org>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id 203so84246565ith.0 for <dnsop@ietf.org>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sZopbgG/Yk+qdMcXAagygEgfRnHnmxbPP50+4vLWYEk=; b=kpcesnvnkn2AoFLGtgZncNyEf0bdNl/xgjbZ3Wj3APLMYP8i51SH7zbA4LskFbkCvd OQboZn/5PHE4qq5i9iTbkPN5rLvFR93LIxosFOYzk/nxYPD5d1stms7L6OAmTmN/YdZ5 K1YvT8u63ppRayPQ/VgmDAeqllQyM0HAheGH3tAfHtLwQMTsqjMEWtfVQPzM+88Pb4Oo Cdk/MlQS3dNoMta6uyJURFBsBbNG1alN2yeAyRJEqFFSoLE5FixM+vvFVic44eFcxE4v xYErPyCfJs29ti32D4MTnBrBURHu0Xvh1yiteSgar8U8thABfcIaWyusXtMJ/5kSUane vWoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sZopbgG/Yk+qdMcXAagygEgfRnHnmxbPP50+4vLWYEk=; b=sTVwqfvrzYIClRNuYhIKcj1v7csel0X4U8ojThQQwqiAWq9hJwdbo5y3krnadpS3iw t3rHxPd9GKQm7GG9yO6pqrGwnoVYmqfmP47t4juLoPv7Ynj+Ui0HA2i16SjWSX4E1MqZ PHxYPuHyD5J2rVqUdgmmOqijafLLgpMgMYjLJVAvUBq1HUsLOL6vkqyr48/lyb0Nkkov Jm466eqs7EmXWrab5NufkUxGQJPGB58ORQixD2rfbVBzop9q+Adbg0aqJg+NZDnSIQWr +6mxCzgkNkxruyIpt9qv4IJcJ3xOR7A+tx+GM/X0LUBXuEsrq5bR48kJq0Ifz8p4DMVX F5cQ==
X-Gm-Message-State: AMke39mDjmR5O3BwjkRDC66TSJpmb7v1SXDAttOtFwzF9uebgxJnWc7UeBMMJIrqkklQVhNjT2Ruw0X0AfA/b3e4
X-Received: by 10.36.25.83 with SMTP id b80mr13404624itb.98.1487624913659; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
In-Reply-To: <CAMm+LwjzZ0M4Yt6bpWKXCuKw_Tq4MYNUNTAwNX5azKnCOEDHQg@mail.gmail.com>
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> <CAMm+LwjzZ0M4Yt6bpWKXCuKw_Tq4MYNUNTAwNX5azKnCOEDHQg@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 20 Feb 2017 16:08:33 -0500
Message-ID: <CAHbrMsAFn4VfXaOdP7p8vYv-v4_0h_5siQ+QB_S1eMX7-6D68A@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114401829139300548fcaa56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2DZFX1USaMAkqcx3j8gtRrrK9EM>
Cc: Tony Finch <dot@dotat.at>, "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 21:08:36 -0000

On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <phill@hallambaker.com
> wrote:

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

What you're proposing does sound like a completely new handshake.  To be
clear, this proposal makes no change to TLS.


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

Could you point me to which document you're referring to?


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

I'm not sure I understand this distinction.

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

How many DNS and destination roundtrips does this require?  My impression
is that SRV records have proven unpopular in part because they generally
add a DNS roundtrip delay to each initial connection.


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