Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Willem Toorop <> Fri, 23 February 2018 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 666B2124235; Fri, 23 Feb 2018 02:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7KhOqxmDIln; Fri, 23 Feb 2018 02:49:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B8D9128C0A; Fri, 23 Feb 2018 02:49:05 -0800 (PST)
Received: from [IPv6:2001:980:2283:fe:c559:e689:f783:adea] (unknown [IPv6:2001:980:2283:fe:c559:e689:f783:adea]) by (Postfix) with ESMTPSA id 0AC3D87E3; Fri, 23 Feb 2018 11:49:03 +0100 (CET)
Authentication-Results:; dmarc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1519382943; bh=rJlNX7UfqzY5JL6YBTrlBc6qv+Zyn2JsHDEovPBiSiY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=P7424Q+vdMnPxvA9fhyzghTzinA1Dj2geLSN0uAyw60CLWdZ7nE4AnKl+rATb/ya9 PgscVoXnmTnrOvnLn7X4B+zYSE4EQFb9gwem545qhiCGfaE5xgMcOJyQIo2pAyufwn +HVgS/SHwCKL1OvBpnMFjAVLrEFuFAVLpzGX4tnY=
To: Shumon Huque <>, Paul Wouters <>
Cc: Eric Rescorla <>, TLS WG <>,, The IESG <>, tls-chairs <>
References: <> <> <> <> <> <>
From: Willem Toorop <>
Message-ID: <>
Date: Fri, 23 Feb 2018 11:49:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
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, 23 Feb 2018 10:49:08 -0000

Op 22-02-18 om 16:44 schreef Shumon Huque:
> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <
> <>> wrote:
>     On Wed, 21 Feb 2018, Shumon Huque wrote:
>         Okay, got it. For people that have already implemented this, I think
>         there has been an implicit understanding that the format of the
>         chain
>         data is a sequence of concatenated wire format RRs exactly as
>         they appear
>         in a DNS message section
>     Note, I would not call it "sequence of concatenated wire format RRs", as
>     it is simply the wireformat of a DNS message.
>     The fact that some parts
>     are concatenated RR's is just part of the wireformat of the DNS reply
>     message. That is, this isn't introducing some new form of concatenated
>     content - it is _just_ a regular DNS wire format message, and the
>     document should not go deeper into its explanation.
> It would _not_ be correct to say that this is a "DNS wire format
> message" - that 
> would mean there is a DNS header section with flags and response codes, 
> and other sections. The chain data structure as currently specified
> really is 
> concatenated wire-format RRs (as they appear _within_ a DNS message 
> _section_). Let me know if that is unclear in the draft (or my proposed
> edits).
> I recall at one point way back there was a discussion about whether the
> chain
> data should just be a fully formed DNS message, but I don't believe that
> idea
> had much support in the working group (personally I would have been fine
> with 
> that choice too, if it did have support).

A DNS message is a 12 octet header followed by a question, followed by a
list of RRs.  The header does not contain any relevant information with
respect to the chain query.  The question is unnecessary, because only a
TLSA record for the name and port of the service (or a secure path from
the name of the service, via CNAME or DNAME to the name of the TLSA
RRset), is acceptable for a client, so a client would have to disregard
the question in a DNS message anyway.  The list of RRs remains and is
sufficient for the DNSSEC chain extension.

A response of a rfc7901 EDNS chain query can be used almost directly as
the content for the extension.  You just have to strip/skip the
irrelevant data from the front of the message (i.e. the 12 byte header,
the query name and 8 octets type/class/ttl).

>     I noticed some discussion about the ordering of this content. I am not
>     sure why that should be done. DNS doesn't care about the order, and
>     neither should producers or consumers of this extension. DNS has no
>     ordering inside its message.
> Yes, that is in fact where we ended up, roughly.
> The draft does currently say that the answer record(s) appear first. And
> then
> the authentication chain records follow and that TLS client should be
> prepared
> to receive the authentication chain records in any order. 
> Requiring the answer records first seems logical to me - it is what
> existing 
> libraries do, and also what the EDNS chain query spec does (answer records 
> appear first in the ANSWER section, and DNSSEC authentication chain records
> appear in the AUTHORITY section in any order).
> There is some residual wording in the draft about ordering of CNAMEs etc in
> the answer records part. Assuming the WG agrees, I am fine with relaxing
> that requirement - that ended up in there because although there is no
> defined
> ordering of RRs within a DNS message section, as a practical matter CNAMEs
> are almost always ordered since there are some DNS queriers that get
> confused 
> otherwise. This is a new protocol though, so we can be more faithful to
> the DNS 
> spec.
>     I don't think getting unrelated DNSSEC records would be an issue. TLS
>     has its maximum sizes for the handshake. In fact, it could allow the
>     extension to have some useful data in the case of MX or SRV.  (and could
>     be a feature to build a nice resolver over TLS using 1 tor circuit).
> The draft currently doesn't address the MX or SRV use case. I suggest
> that we tackle that in a future version.
>     I'm also not sure about the talking of unsigned CNAME records from
>     DNAME. The above pseudo code (extended with special cases) should be
>     in some DNS library, and that library will know what records to expect
>     unsigned which are proven by the DNAME (or wildcard) synthesis and knows
>     when/if to add it to the validated cache. I don't think that should be
>     explained in this RFC at all. The DNS implementation does not need
>     to be specified in this document and it should just focus on saying
>     that "the DNS message response is validated and upon validation the
>     content can be considered DANE validated".
> Where we ended up, is that WG participants asked for some level of DNSSEC
> detail to be included in this doc.
> Shumon.