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

Shumon Huque <> Wed, 21 February 2018 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1CF612D7F4; Wed, 21 Feb 2018 07:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 zO3uFpWuhyjl; Wed, 21 Feb 2018 07:52:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E776124B17; Wed, 21 Feb 2018 07:52:40 -0800 (PST)
Received: by with SMTP id 30so2612955iog.2; Wed, 21 Feb 2018 07:52:40 -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=mM2Yl5HWRdrz1OM25KeQ/+rNRDnB4y4Ip81fQDFC2uk=; b=BQtvX76mkjH5k9XHUjuayDQ547ln2htQmOx/ELtRirStU41bjM8pcKD3dUxOJWOA6Z IZ1EQbxcgzfwMQY5lU9u4tQ0x2N7RC5Ab/FP02HhRurZD3y5E1gurRQayRzWn9vjc7kD BpFmXkKpqscEfpQZQPXpyR+F3soBUzqd8zQufV1zM83WJi3NRxXLnsWh8B+AYB9XWAhX I6TgztLbZ4H22SWbyII7VnX4YxVOFx0Sxr0xrp6+DZegv27BbfJu2U4WOYKXV7OwNiSc potpDppkr+t5jtaya5xSQq9VDlqnZF/vB9y/pr6IZq0rD5ncWlw1CTERj6l+dyk9693B jf6w==
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=mM2Yl5HWRdrz1OM25KeQ/+rNRDnB4y4Ip81fQDFC2uk=; b=DCkg92mdKkABcKkTflflzMz/nsWo+1PugPYFW7eTFAIFlRkKia2X/4wdU9k5oMFdTR 5EL4SEE2N0voQvP0QMyHuCrPxkeKCYKDrrbz6lCG8QtyZ8E2VojLSf0CPTQK/ieEOpvn Fp2A03OlMRJr3ryqvCw3vr8eSH7j2wP2q03rhQ/+eyHvNEbt3eS0E1mMF49CZY3Aiyh3 7vlc0ou8a52FOzQ3RWT67v8UC03gDIsehYYcShZW7n0dLI+64VXe2c92kxnkFTl29lsU zjRdYneUbpaMK1Az4zpyPyyCcoNagWgdmhB0srY/AtYVFsHn18a0mxvNRmS1pF4aDhd9 K0Jw==
X-Gm-Message-State: APf1xPBy1RIhNMPyqIiFY15Y1PpEfDoW+xNmyIOEcdW9mFmj94DRRD/K sjs3EB9Yy0YrcKzKZusJ77nwtdge6h5RfGnH/BGMX/aC
X-Google-Smtp-Source: AG47ELuMI2ggHRlvT7lUgQ5lQ5A89qz1L6yyDoXonr6PKd1Wjk2gzyxXCSK01aKRf6OfL6qG9JHj+cVpKahd686HieU=
X-Received: by with SMTP id w200mr4583987iow.128.1519228359103; Wed, 21 Feb 2018 07:52:39 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 Feb 2018 07:52:38 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Shumon Huque <>
Date: Wed, 21 Feb 2018 10:52:38 -0500
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,, Joseph Salowey <>, tls-chairs <>, TLS WG <>
Content-Type: multipart/alternative; boundary="001a1146325ead8a580565baeaa3"
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: Wed, 21 Feb 2018 15:52:43 -0000

Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..

On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla <> wrote:
> On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <> wrote:
> > > 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
> this
> document.

Yes, I agree, we need to remove that.

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

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 (with one injunction against doing DNS name
compression). I'll write some text to make this more explicit and describe
the format in more detail with references to the appropriate DNS specs.

This is also the format that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the following
assumption: "... (assuming that the data will be prepared and consumed
by a DNS-specific library) ..."

> > 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
> > reading RRs and group adjacent RRs that share the same RR name, type,
> > class into a distinct RRset.
> >
> I'd have to review your text to know if it was sufficient.

Ok. I'm working on text for this ..

> >
> > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
> >   need to be consulted and honored.
> >
> Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> extension.

Just to confirm, I assume the attacker here is an entity attempting
to impersonate the TLS server (with presumably valid PKIX credentials).
If so, yes it can trivially ignore the extension, but this is the case
for any DANE usage mode (not just the PKIX constraining ones).

As discussed in Section 8, the protocol as currently specified really
only allows opportunistic DANE authentication, unless some mechanism
external to TLS is employed to mandate DANE usage. (The protocol could
be extended to require TLS servers to also provide a DNSSEC proof that
they don't have a signed TLSA record, but that could only be deployed
in a TLS application system where all servers supported this extension).

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

I think Viktor's earlier reply to this thread goes into detail about
client behaviors here and what we might recommend (which seems reasonable
to me). I'll follow-up there.

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

My comment was about what DANE mode choices the server is offering to
the client. Certainly, the client can decide whether it wants to use
DANE or not, and whether it wants to fallback to PKIX. The protocol
should probably not be proscriptive here, and allow different TLS
applications (or configurations of such applications) to make choices.
But maybe there are some general recommendations to be made.

One additional comment about PKIX fallback on DANE failure: If a
server is using DANE-EE or DANE-TA, it has the ability to send back
a much shorter Certificate message - just the EE certificate for the
former, and typically a very short X.509 chain for the latter. But
this means that for fallback to PKIX, the client would have to start
a new handshake omitting the dnssec_chain extension. For efficient
fallback within the same handshake, the server would always have to
send back the full PKIX X.509 chain. Maybe that's what we need to
recommend for servers that support both DANE and traditional PKIX.

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

Fair enough. I'll propose some new text to make this clear.

> >    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
> > is a
> > > MAY?
> >
> > They should clearly be consistent. My preference would be "SHOULD" for
> > both.
> >
> That's a WG decision.

Ok. Let me know how you want to handle this question. I'd be happy to
send a separate note to the WG list about it.

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

Well, the algorithm the DNS server (specifically a DNSSEC aware
resolver) uses is the DNS iterative resolution algorithm - the TLS server
would just treat that as a blackbox (unless it implemented its own

I think the more important question is how the TLS server issues a
sequence of queries to the resolver to obtain the data it needs to
the dnssec chain, and then extracts the corresponding RRsets from the
responses to those queries.

Section 4 (paragraphs 4 through 6) describe that process. Again, we could
go into more detail here, but we were working with the assumption in the
intro ( ".. the data will be prepared and consumed by a DNS-specific

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

Sorry for being dense - this protocol requires a new codepoint. Do we
need to say we RECOMMEND that a new code point be registered?

Or are you asking that we RECOMMEND that IANA allocates our preferred
extension type value (53)?