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

From: Allison Mankin <[email-masked]>
Date: Tue, 3 Jul 2018 10:41:18 -0400

I haven't chimed in on the mailing list on this draft, but I'm one of the
people who had discussions with browserfolk in hallways, in the corners of
interim meetings for HTTP2, and other such places, in order to see what it
would take to get a start on TLSA use by browsers.  Due to the floods of
traffic that occurred in this and other chains, I almost missed Joe's call
for answers to consensus questions, but I've responded inline.

Looking forward to discussion in Montreal.

On 26 June 2018 at 00:20, Joseph Salowey <[email-masked]> wrote:

> Hi Folks,
>
> There has been some discussion with a small group of folks on github -
> https://github.com/tlswg/dnssec-chain-extension/pull/19.   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)?
>
​I support future work if there is extensive engagement and involvement by
members of the browser community who have expressed concerns about pinning.

>
> 2.  Do you support the reserved bytes in the revision for a future pinning
> mechanism?
>
​Reserving the bytes without a mechanism is not a good idea, so no.  I
think the method for modifications or another approach is something to be
worked on in future too.

> 3.  Do you support the proof of denial of existence text in the revision?
>
​Yes, this text is good.​

>
> 4.  Do you support the new and improved security considerations?
>
​This text is a good addition - but there are a few things that might be
discussed.
Generally support them.

> Thanks,
>
> Joe
>
>
>
> On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters <[email-masked]> 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
>>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , 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 www.example.com does not show that the
>> _443._tcp.www.example.com does not exist, you need the one from
>> www..example.com <http://www.example.com> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Jul 2018 11:56:04 -0400 (EDT)

On Tue, 3 Jul 2018, Allison Mankin wrote:

> 2.  Do you support the reserved bytes in the revision for a future pinning mechanism?
> 
> ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is
> something to be worked on in future too.

Reserved bytes are always under specified, that is why they are reserved.

For instance, yesterdy ekr filed a draft for encrypted SNI with this:

 	 struct {
 	           uint8 checksum[4];
 	           KeyShareEntry keys<4..2^16-1>;
 	           CipherSuite cipher_suites<2..2^16-2>;
 	           uint16 padded_length;
 	           uint64 not_before;
 	           uint64 not_after;
 	           Extension extensions<0..2^16-1>;
 	       } ESNIKeys;

 	 extensions  A list of extensions that the client can take into
 	      consideration when generating a Client Hello message.  The format
 	      is defined in [I-D.ietf-tls-tls13]; Section 4.2.  The purpose of
 	      the field is to provide room for additional features in the
 	      future; this document does not define any extension.

So there is a whole extension block with no specification and no idea
even if it would ever be needed. That is much weaker then the need for
TLS extension pinning.

Additionally, let me remind you of the direction that the solution
would take if this is punted completely to a new document:

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

The smithee draft is a terrible idea. We can do better.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Jul 2018 22:44:49 -0400

On Tue, Jul 03, 2018 at 10:41:18AM -0400, Allison Mankin wrote:

> would take to get a start on TLSA use by browsers.

The present dilemma for this draft is how to ensure that it has
enough security benefit to warrant deployment and sufficient scope
to cover would-be applications.  The draft as originally approved
had two major defects:

    * Required not only extension support, but also DNSSEC and DANE
      TLSA records in order to support "greefield" applications that
      mandate the extension from the get-go.

    * No plausible path to incremental adoption by existing WebPKI
      applications, that can't mandate the extension (let alone
      DNSSEC and DANE), but might employ DANE when present, but
      otherwise continue with WebPKI alone.

The first defect is addressed by incorporating denial of existence.
This allows a server to present an extension that proves lack of
DNSSEC for a containing DNS zone or just absence of the associated
TLSA records.  In this way "greenfield" applications that mandate
the extension can interoperate with servers that have not yet
deployment DNSSEC or DANE.

The second defect requires at least the ability to mandate the
extension, when a server commits to continue to present it for some
time.  Since pinning is potentially fragile, we should be pinning
as little as possible.  Hence once again only support for the
extension, rather than a continued expectation of DNSSEC, DANE,
particular certificate details, ...  This is NOT HPKP.  This requires
denial of existence support, adding which fortunately seems to have
broad consensus.

> Looking forward to discussion in Montreal.

I'd like to see as much of the discussion as possible on list, where
we can get responsive comments from informed participants, and not
just "humming".

> I support future work if there is extensive engagement and involvement by

    * TLS is not exclusively for HTTPS.

    * This extension is NOT just about browsers. It should support
      IMAP, SUBMIT, POP, XMPP, NNTP, ...

    * The "concerns about pinning" are often related to the
      unsurprising failure of HPKP.  It is unfortunate that HPKP
      has tainted "pinning".  And yet the IETF has just approved
      MTA-STS, which pins a commitment to WebPKI authentication along
      with a list of the domain's MX hosts.

      It is easy to taint the proposed downgrade protection mechanism
      by associating it (incorrectly) with HPKP.  The proposal DOES
      NOT pin the peer certificates or keys.  This is an STS-lite
      proposal, that pins only a capability: support for the extension
      for a particular TLS service endpoint.  And in this case no
      "testing" mode is applicable, and sub-domain pinning is
      impactical.  Looking at the existing STS-like protocols, it is
      easy to see that only their TTL applies here.

> Reserving the bytes without a mechanism is not a good idea, so no.

I don't see a rationale for this.  The mechanism is a TTL to be
carried in those bytes.  We're willing to accept a variable-length
field in order to accommodate objections that a TTL *might* not be
enough, and a compelling case for additional attributes might be
made in the future.  I'm confident that no such case will hold up
to scrutiny.

-- 
	Viktor.