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

Ben Schwartz <> Mon, 20 February 2017 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C81C1294FF for <>; Mon, 20 Feb 2017 13:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q1e3Vt0BcYe5 for <>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B002E1294B9 for <>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
Received: by with SMTP id 203so84246565ith.0 for <>; Mon, 20 Feb 2017 13:08:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id b80mr13404624itb.98.1487624913659; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Feb 2017 13:08:33 -0800 (PST)
In-Reply-To: <>
References: <> <20170217220309.9637.qmail@ary.lan> <> <alpine.OSX.2.20.1702172143530.94448@ary.qy> <> <alpine.OSX.2.20.1702182014260.99706@ary.qy> <> <>
From: Ben Schwartz <>
Date: Mon, 20 Feb 2017 16:08:33 -0500
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a114401829139300548fcaa56"
Archived-At: <>
Cc: Tony Finch <>, "" <>
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <
> 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.