Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

Shumon Huque <> Fri, 07 July 2017 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DED512EC49 for <>; Fri, 7 Jul 2017 13:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6SmhERhEGIsZ for <>; Fri, 7 Jul 2017 13:01:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 144E612EC1B for <>; Fri, 7 Jul 2017 13:01:54 -0700 (PDT)
Received: by with SMTP id g40so26387182uaa.3 for <>; Fri, 07 Jul 2017 13:01:54 -0700 (PDT)
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=DlwQ3UoOxg7stl+Ra0pb3JoxKgy2pDPHvFFISsoAZrw=; b=AF6x/nzfJEZPdBBwo/vsuex0uJkkVXBnE8Q0itMjSiaGY0nh4KcsmM1uCJ4D30vyhZ cOv5Y+s7pUekV5TRbBapGI8lZkPXsxg6nHuYh2i59MHPENwN6mLYxTqyX3mx7dlYQId1 pc1Q2J2qbeBHvXzbPdDnatlTDb6bH+hUq5RshDeQD9phOhoxOeKVOPblZXuI6J+smpR3 GfHzklJVhM4mm3ZM/AUF8xP/0iXJ95DK8JiFe6sj2ZfQNclAXCtNy/QVVKmfabr+cD4u qd9f4ErS//90tj0qUBgSZbcoD+L5MR5NSc3IDN0BucE1apA/90XdEtpXrMTolVsuo6Vp W0hA==
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=DlwQ3UoOxg7stl+Ra0pb3JoxKgy2pDPHvFFISsoAZrw=; b=LYVajCuffmBKtZxoje/S3namxcsSYpv22vV77ET6qUwDcQ741pfh/xfOBTkqdh4MZy gjHJ1JXbVagtkboUqf6NK87L6DN2dyoCQ4AMZhdIM6c2/lg+SYgVVRhf+HeT3chuuwX+ lhVP7FsSJ4E08AhsHG1QsbJurO3L0/Hg+GjZaTN5UO8DIU509Wd1sZIhT8fiCm3dtBxR B153wJmYvv4uRwgxXEcIS0ZHxMZMMzrR6aY7KkrvddWHGHmArjdwp5YTBTOM+4NfhUQV wwAe9uafkuzRkLeB59rjHuBrNPbVAJJVwJ7iLIi7GmeBH1b7Wh59ZYyQ1d/7hMvmXb/E J8kw==
X-Gm-Message-State: AIVw111TyyM8ekUkcIQ8+fwlwccrdGQtFvtKSVkoZI6pyIB3rMXhQiJr DbvjbxoTtEcwB9OkjIFLGqa2QEkjcxuk
X-Received: by with SMTP id u2mr1756785uaf.109.1499457713084; Fri, 07 Jul 2017 13:01:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Jul 2017 13:01:52 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Shumon Huque <>
Date: Fri, 7 Jul 2017 16:01:52 -0400
Message-ID: <>
To: Tom Ritter <>
Cc: Joseph Salowey <>, "" <>
Content-Type: multipart/alternative; boundary="f40304362188581d600553bfb459"
Archived-At: <>
Subject: Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jul 2017 20:01:56 -0000

On Fri, Jul 7, 2017 at 3:13 PM, Tom Ritter <>; wrote:

> As a note, I didn't see anything in this draft (from a quick read)
> that precludes any of DANE's Certificate Usage, Selector, or Matching
> Type fields. If that's not the case, perhaps someone can correct me.

Yes, that's correct. Is there any reason it should?

TLS applications are free to preclude the use of DANE parameters, but a
more general purpose protocol I feel probably should not. The draft does
refer several times to RFC 7671 (DANE updates and operational guidelines),
which has some recommendations which ought to be followed.

>    A client must not be able to force a server to perform lookups on
>    arbitrary domain names using this mechanism.  Therefore, a server
>    MUST NOT construct chains for domain names other than its own.
> What about the reverse? Do we care about a server tricking a client
> into priming its DNS cache?

> -tom

Yes, we want to avoid that, but I would expect that any sane client
implementation, as a basic precaution, would only accept a DNSSEC chain
corresponding to the TLSA name that it expected to see. If the server
presented anything else, it would not be considered invalid. Similarly, if
the chain included embedded unexpected extraneous records, I would expect
the client implementation to ignore those (or even invalidate the whole
chain if it wanted to be more draconian). If necessary, we could have
explicit text about this.

Shumon Huque