Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

Eric Rescorla <> Thu, 05 July 2018 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 874CF130E59 for <>; Wed, 4 Jul 2018 18:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 FrQa-bjWx_32 for <>; Wed, 4 Jul 2018 18:35:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B242F130E68 for <>; Wed, 4 Jul 2018 18:35:26 -0700 (PDT)
Received: by with SMTP id e23-v6so1921292ywe.13 for <>; Wed, 04 Jul 2018 18:35:26 -0700 (PDT)
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=mq1p9wWtxns87HUKgYQv266otGNy+A8DmYYtgRXITwI=; b=mtp9Gt5mqNPKd/nrzrCqq3W22243COLx0KmKNlXa2jnhhbogxqOEHI3+9nrWebc8x5 9xisIedROkS1gj50FwCWc+qtJAdnXvdQ8ColtOF2Ay782sezuuMf/bYmnGIa2w45qK+u 2C39733iDktj4s9Tj7uRwQuZF61Lfr08JJgbCQsthAsoLUcFoe7hjAkMeP8RUEv1Ocav 3jcTWEFZdy1Lr8M9dFUYaLil/QQXcx2BzrQata5eOHjl0J8/0140gA6YdHd06cMSNQyC mBtNSjTfpv7+4TdOzxgA2CZ6Z3UMTCKtI3YTSfa4Ox3yv76N9syNyW0rSS6tEsU8xuXk 12hg==
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=mq1p9wWtxns87HUKgYQv266otGNy+A8DmYYtgRXITwI=; b=oF6OeRa32VcCMhVMpX8gD6jnewxCUFsPMkCvTnEYEV+DBRq+zrCUTT/ylwZ2GNCWew zRLFwFQk1oPQ7r4Up2VbQ+uy0WmDTucq9UfGwMqGKbmaul8vfmFG+tUU2+4yTYdrinBe 1sNvAyJwCQa8cxjOTfVOp4h76enQP7mKVVsKOGtooo+txkJf05xajPJtqL5BnQq8sPc5 KQDUPR5QXfH6f+FXfGWhmfeqLTDSUGAVrntJpR4/8DvFJ3QQ9psZYQ0SdFMaF6qWZexn jx1iGiiIYI2bvVsPnKy3KUrtHphKalL2gRjmNvkoGuTZ9uHsL2fx1ScltQM3R56yYAnA vb/w==
X-Gm-Message-State: APt69E0sfleP8cajCUE4AbZbS0XtSL4Mepr3cEk6lDWXKI7jl2ArDRCE iF0OBaU1Xd+cBtcgk3psbROaE8X6j7tiFtPQTCUeNg==
X-Google-Smtp-Source: AAOMgpfN41VY6K/6F4YYWzeL0Ibpjp2W8DRskfFqADTxqH9A3xJBKm57aobEZobAwGMX9+dgX4/In94119cEdrYwe74=
X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr1890300ywf.167.1530754525471; Wed, 04 Jul 2018 18:35:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 18:34:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Eric Rescorla <>
Date: Wed, 4 Jul 2018 18:34:44 -0700
Message-ID: <>
To: Joseph Salowey <>
Cc: Paul Wouters <>, "<>" <>, Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary="000000000000bac2b60570368f2e"
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-Mailman-Version: 2.1.26
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, 05 Jul 2018 01:35:31 -0000

On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey <> wrote:

> Hi Folks,
> There has been some discussion with a small group of folks on github -
>   I want to make
> sure there is consensus in the working group to take on the pinning work
> and see if there is consensus for modifications in the revision.  Please
> respond to the following questions on the list by July 10, 2018.
> 1.  Do you support the working group taking on future work on a pinning
> mechanism (based on the modifications or another approach)?

Unsure. I'd like to see some real evidence that it will be widely consumed.
Do we have a count of major implementors who say they will do so?

2.  Do you support the reserved bytes in the revision for a future pinning
> mechanism?

No. I'm undecided on whether we should have an extension point here, but
I'm strongly against having it just be opaque reserved bytes. Everywhere
else we have decided to put extension points, we've had them as Extensions,
not just "here are some bytes".  Aside from this being general TLS
practice, it is good futureproofing because one can grease Extensions,
whereas you cannot grease opaque bytes.

3.  Do you support the proof of denial of existence text in the revision?

The mechanism seems fine, but it doesn't seem to me that the specification
is clear on what the semantics are. I think what they are is that you can
configure the client to be in some "DNSSEC required" mode which will
requires that the extension be returned and that it either (a) contain
DNSSEC-signed records for the domain or (b) contain authenticated denial of
existence. Is this correct? If so, I would be happy to have the text merged
and then wordsmith this explanation.

4.  Do you support the new and improved security considerations?

They seem like a good start. I'd be happy to have them merged and wordsmith


> Thanks,
> Joe
> On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters <> wrote:
>> On Mon, 4 Jun 2018, Benjamin Kaduk wrote:
>> Hi Ben,
>> I've taken a stab at putting together some security considerations text
>>> for
>>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of
>>> the
>>> current state of affairs.  It's in a pull request at
>>> , along with
>>> Viktor's
>>> commit to update the text about the actual DNS records involved (which as
>>> far as I can tell seems to improve the technical accuracy of the text),
>>> and
>>> also inserting a variable-length array that's reserved for future
>>> attempts
>>> to mitigate the (now-)documented security considerations.
>> Thanks for writing the proposed text. The new opaque Reserved field
>> along with the denial of existence changes you propose addresses all
>> my concerns.
>> One corner case that might be worth mentioning with the proposed DoE text
>> is the odd corner case of hitting a server with a Host header for which
>> it is not configured. You will hit the "default vhost" but you have no
>> appropriate extension data to populate for that hostname. So either the
>> server will return the (cached) TLSA/DoA data of the 'wrong' hostname,
>> or it could just omit the extension. I'd mostly like to say something to
>> prevent an implementation of forgetting this corner case and causing
>> some vulnerability in their code later on by pointing to bogus memory or
>> crashing on dereferencing a NULL.
>> Some nits:
>>         If the server supports this extension it performs the appropriate
>> DNS queries,
>> In my PR I had changed this into "obtains the appropriate DNS RRsets",
>> because I envision that TLS servers might not do DNS lookups themselves,
>> but just read this via a file or other method. Eg a cron job that
>> regenerates these hourly for all the hosted domains. It also reduces
>> some fear that all TLS servers suddenly could need to link against
>> a DNSSEC library. They don't if they can just reload a blob from disk
>> regularly to serve up.
>> Similarly:
>>         it will need to rebuild
>> is better written as "it will need rebuilt data"
>>         "authenticates the chain"
>> That should probably be "validate the chain", but the document has more
>> mixups of validate vs authenticate. In my PR request I had not corrected
>> them in an effort to keep the diff as small as possible.
>> I had modified the examples slightly, so the NSEC example would show a
>> simpler NSEC chain (from www to zzz) instead of the one wrapping around
>> from www to the zone apex. The example quoted is the wrong NSEC record
>> (the one from apex to does not show that the
>> does not exist, you need the one from
>> <> to the apex at the end of the
>> zone)
>> I'm not sure what you mean with:
>>         validated negative TTL
>> I guess you mean to say the shortest TTL of any data in the chain? But
>> sometimes the negative cache time is larger then the TTL (eg if TTL = 0)
>> Since this is just generic DNS handling, I would probably just write
>> something like "up to the appropriate lifetime" and leave it out of
>> this document.
>>         denial of existence RRset
>> Technically that should be "RRsets" since you usually will need more then
>> one RRset to prove this (to disprove existence of the wildcard record)
>>         -      DNSSEC authentication chain extension from a server,
>> SHOULD use this
>>         +      DNSSEC authentication chain extension from a server, uses
>> this
>> I'm not sure why the SHOULD was removed here? Since it is describing TLS
>> client behaviour the "uses this" confuses me as I dont know if that
>> means MAY, SHOULD or MUST.
>>         + Specifically, the relevant DANE records are included
>>         + in the TLS handshake transcript hash, so both sides
>>         + possess identical records;
>> I'm not sure why you suggest to add this text. A TLS client might still
>> have cached a valid TLSA records from a previous connection 1 second
>> ago and might decide to not use this information at all. Also, it seems
>> to suggest that the transscript hash protects this data, but it is
>> "protection" using the webpki or proof of lack of MITM, but the data
>> does not need this protecting as it is protected by DNSSEC signatures.
>>         + the client remains responsible
>>         + for actually performing the domain name validation of
>>         + the DANE records.
>> Well, if it just fired up a previous TLS connection, perhaps it will be
>> content with the same pubkey used and skip re-validating this data? I
>> guess we sort of say the same thing due to the lack of a MUST ?
>>         + The Reserved field is reserved for future updates to this
>>         + document; in particular it is hoped that the issues discussed
>>         + in <xref target="increasing-trust" /> can be addressed.
>>         + Implementations of this specification MUST send a zero-length
>> vector
>> Perhaps that last line can be clarified a bit:
>>         Implementation not implementing any updates to this document
>>         MUST send a zero-length vector
>> This sentence does not parse:
>>         "whether or not to the exclusion"
>> This text is a little confusing to me:
>>         + certified by the DNS key hierarchy, that the
>>         + server does not support DANE authentication
>> The TLS server itself might support "DANE authentication", but there is
>> simply no data.  Perhaps say that the server's configured hostname does
>> not support DANE authentication?
>> Thanks again for the write up!
>> Paul
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list