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

Eric Rescorla <> Thu, 08 February 2018 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3246512DA1A for <>; Thu, 8 Feb 2018 06:50:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqW4pQ3k47WW for <>; Thu, 8 Feb 2018 06:49:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20F0812DA14 for <>; Thu, 8 Feb 2018 06:49:58 -0800 (PST)
Received: by with SMTP id m84so2757988ywd.5 for <>; Thu, 08 Feb 2018 06:49:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4J+39CQaKM1b4tEPTWV4hKAmat8L6rche8Bqs1DYRk=; b=W6Brr30p10yj8Kq6V+Grt5QSIfjsLemKQ+BW9wrlXo8XLhAtr/bf1+JJI5mfvMGgQD K/ICfr8Pp80WQwrAapy7hSvdTIsErduYxPxBAnYjH91ZnFsVoC731d7m8vKQlpwSu4UN 4eeJA5DyTwgKTQI8J86XtkpL8T49inDaWl3bShEVxynw5kCD40lnSWPiX1GVZb+35e1Q uY+UGmT8OGWIGJF/18n+DxdEbnOf7Be6ozQAAnketYbJVr4nkYZLG371uu1x3yCwhmrA 4erWrpIzpQuw3lzO2GX1WLTZueIjCMpbwWr051ZXtmKQImL121Wsqxu0E92v6SyVYt4b IIkA==
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=I4J+39CQaKM1b4tEPTWV4hKAmat8L6rche8Bqs1DYRk=; b=V1HGIqNoc5Ys9EgNqUjDuNxOv2//1lkJs2PGXLZkqL95fkADdx4Lv+hiXoyiX93gtK O1nxRgerJ6sB4amBUxHDa1tHWSZ9vkI0LKZaEWZoMq9YDDRWEkijOoX4NhPHjcw/FOE+ UdgfZIjdrZ+DX/RXLi4BV8QW7qpJlXmWUO7Nk2/wbNWOPdpwClTi1dV0WD2hMo+eYQpf Vcl5HMckMIqcso0CucGUI4JA9VyZd9my1c1tffwkM0I7hmkjIc6HPaK5Gq4kMry8Xl+0 9oYd2Hma5j6nV3b8BfVcrz+3GtXoCJEd1kjHwJuIpfFWMnW9G3udtxG98SkLuK/TTdbI dTuw==
X-Gm-Message-State: APf1xPCqVF7jalpGACcchoUz1XGGOsAyotmhgL8hbG3zSeoMAWVUEbYN 0x51sKibk82o+eor0zFDLzJJHyUZ+gJpWynkLf2GdQ==
X-Google-Smtp-Source: AH8x227LD8RxkYI9T6vqDQZQmcLu+O79UPimWMv9qE4dMRIuqZjxFtKbCAAK44kyqvK4c+pIMHH2b/yJMU4cuhVW/DY=
X-Received: by with SMTP id d124mr681346ybb.200.1518101397138; Thu, 08 Feb 2018 06:49:57 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 8 Feb 2018 06:49:16 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Thu, 08 Feb 2018 06:49:16 -0800
Message-ID: <>
To: Shumon Huque <>
Cc: The IESG <>,, Joseph Salowey <>, tls-chairs <>, TLS WG <>
Content-Type: multipart/alternative; boundary="001a113bccc88281fc0564b48614"
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: Thu, 08 Feb 2018 14:50:02 -0000

On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <> wrote:

> On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla <> wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
> Thanks Eric for your detailed review and comments.
> > This draft seems generally sound, but I believe there are pieces that
> > are still underspecified. These should be easy to fix.
> >
> > the Signer's Name field in canonical form and the signature field
> >    excluded.
> >
> > IMPORTANT: I'm not sure that this is actually sufficient to allow an
> > independent implementation without referring to the other documents. I
> > mean, I think I pretty clearly can't validate this chain from the
> > above.
> We could add an explicit reference here to the DNS protocol document(s)
> and sections within them that define the canonical form of domain
> names (RFC 4034, Section 6 probably is the best reference), or even
> excerpt the relevant text from that document. Would this satisfy your
> concern?

Well, and remove your text about it being possible to implement solely from

We deliberately didn't include in this document a detailed description
> of the DNSSEC validation algorithm. The algorithm is sufficiently
> complicated (and lengthy to describe) that those details are best left
> to the relevant DNSSEC RFCs. I think it would be helpful to point
> specifically to which documents and sections here though (mainly
> RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a
> brief synopsis of the algorithm and refer to these documents for
> further details.

It's not the algorithm. I don't believe this document is sufficient to
parse the

Otherwise, can you suggest more specifically what level of additional
> detail you'd like to see in this document?

See above.

> Similarly, although I think this is enough to break apart the
> > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
> > each other. I think you need to either make this a lot more complete
> > or alternately stop saying it's sufficient.
> We can add some text about this. Basically the client would scan the chain
> reading RRs and group adjacent RRs that share the same RR name, type, and
> class into a distinct RRset.

I'd have to review your text to know if it was sufficient.

> >    abort the connection, the server uses the domain name associated with
> >    the server IP address to which the connection has been established.
> > IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple
> names for the same IP.
> >
> Yes, indeed. This sentence is dealing with the case where the client has
> not indicated to the server which name it wants to connect to, so the
> server is basically guessing anyway. Perhaps we could reword this to say
> something like, "the server picks one of its configured domain names for
> the associated IP address".

Yes, that would be fine.

(This situation could also have been avoided by mandating client use of
> the SNI extension).
> >    DNSSEC authentication chain extension from a server, SHOULD use this
> >    information to perform DANE authentication of the server.  In order
> >    to do this, it uses the mechanism specified by the DNSSEC protocol
> >
> > IMPORTANT: What happens if the DANE validates but the cert is revoked
> > or alternately the cert validates but DANE does not?
> This depends on the mode of DANE in use (i.e. the Certificate Usage
> field of the TLSA record). If I recall correctly, this should all be
> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
> * With DANE-EE, only the EE certificate is matched against the
>   certificate data/hash in the TLSA record. There is no CRL/OCSP
>   style revocation. Revocation would be performed by removing the
>   TLSA record from the DNS.
> * With DANE-TA, the indicated CA certificate referenced in the TLSA
>   record may have advertised revocation mechanisms that need to be
>   consulted.
> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms
>   need to be consulted and honored.

Well, neither of these modes is useful here, as an attacker will simply
ignore the

Would you like us to discuss this in the draft? Or is referring to
> RFC 7671 sufficient?

I think you should discuss it in the draft as it is relevant to TLS

On your last case, "cert validates but DANE does not", I assume
> you mean the cert validates via PKIX but not DANE? I'm not sure this
> is explicitly discussed in any other DANE document but presumably
> if DANE is being used, DANE must validate.

Why would that be so? This only is useful in DANE-EE and DANE-TA modes in
the first place, and so there is a possibilityt aht PKIX is valid.

 note, I believe most envisioned use cases of this draft
> will be for the DANE-* modes. The PKIX constraining modes have the
> issue that for them to work securely, the client must be able to
> confirm the presence of DANE records, which leads to the issues of how
> to mandate use of this mechanism (Section 8 of this document).

Yes, I don't think those modes are useful here.

The TLS version-specific protocol elements involved in delivering this
> extension are described in Section 3. For the Introduction section from
> which the above text is excerpted, I would suggest the following rewrite:
>    The extension described here allows a TLS client to request that
>    the TLS server return the DNSSEC authentication chain corresponding
>    to its DANE record. If the server is configure for DANE ...

Yes, this is fine.

> 3.1.  Protocol, TLS 1.2
> > You should probably provide some guidance about whether the server
> should still
> > provide the whole X.509 chain to the client. I believe with these
> semantics,
> > the server cannot tell which DANE mode the client wants and therefore
> has to
> > provide the entire chain.
> Sure, we can elaborate.
> The DANE mode to be used is advertised by the server in its TLSA record(s),
> so the server already knows whether it needs to return the X.509 chain.
> If the TLSA RRset has only DANE-EE, then only the end-entity certificate
> needs to be returned. If DANE-TA, then only the chain from the TA cert to
> the
> EE needs to be returned. If using the PKIX modes, then yes, the entire
> X.509
> chain has to be sent.

The problem is that the client is the decider about what it wants to
accept, not
the server.

>    arbitrary domain names using this mechanism.  Therefore, a server
> >    MUST NOT construct chains for domain names other than its own.
> > "its own" is a bit fraught, as servers may not actually know all their
> domain
> > names, at least at the TLS layer.. Can you be more specific about what
> the
> > server algorithm is.
> To implement this specification, the TLS layer does need to have
> preconfigured knowledge of the names for which it has DANE records.
> This text is also a bit imprecise and should be improved anyway. The
> server doesn't construct chains for its own domain name, but rather
> the TLSA record name corresponding to that domain name. This domain
> name is either one explicitly indicated by the client via SNI (assuming
> that the indicated name is one the server recognizes as its own),
> or if no SNI is provided, one that the server picks from its known
> set of names (as discussed previously).
> The purpose of the MUST NOT sentence here is to prevent clients from
> using the TLS server to lookup arbitrary domain names.

OK. Well, perhaps some better text is needed here.

>    Servers receiving a "dnssec_chain" extension in the ClientHello, and
> >    which are capable of being authenticated via DANE, SHOULD return a
> >    serialized authentication chain in the extension block of the
> > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below
> is a
> > MAY?
> They should clearly be consistent. My preference would be "SHOULD" for
> both.

That's a WG decision.

> >              opaque AuthenticationChain<0..2^16-1>
> > Is 0 actually appropriate here as a lower bound? Presumably at least one
> such
> > instance must be present?
> Yes, there should be a non-zero number of bytes in the extension data.
> So: opaque AuthenticationChain<1..2^16-1>
> >
> >              RR(i) = owner | type | class | TTL | RDATA length | RDATA
> > I assume the notation here is "i is the ith RR"?
> Yes, we can mention that.
> >
> > Is there a reason not to describe this in TLS language?
> I think because the extension data contains only a sequence of DNS wire
> format RRs which are precisely defined in DNS documents, and we felt it
> was redundant to redefine them in another format.
> >
> >              . DNSKEY
> >              RRSIG(. DNSKEY)
> > How does this differ from the algorithm that you would use in response
> to the
> > TLSA query?
> Sorry, I don't follow your comment here. Differ from what? Can you
> elaborate?

You provided an algorithm for how to construct responses. How is it
different from the
algorithm that the  name server would  use to respond to a query for the
TLSA record.

> >
> >    the draft is adopted by the WG, the authors expect to make an early
> >    allocation request as specified in [RFC7120].
> > Do you want this to be marked RECOMMENDED?
> In response to Mirja's earlier comment, I think we are taking out this
> sentence.

You're still registering the code point, so you need to determine if it's


> Shumon Huque