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

From: Bill Frantz <[email-masked]>
Date: Mon, 2 Jul 2018 14:17:17 -0700

On 6/25/18 at 9:20 PM, [email-masked] (Joseph Salowey) 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 would like to see a pinning mechanism, and think this Working 
Group is the right place to move the idea forward.

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

Yes.

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

I had difficulty reading the GitHub thread.

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

ditto

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 18:34:44 -0700

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

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

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.

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

-Ekr

> 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: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jul 2018 22:08:52 -0400

> and then wordsmith this explanation.

More precisely, you can configure the client to require the extension,
and yet still interoperate with servers that (support the extension,
but) live in an unsigned zone, or live in a signed zone with no
TLSA records for the service in question.  The server just needs
to be able to return a denial of existence proof for the DS records
of a delegated containing domain or its TLSA records, respectively.

Agree that merging the text for further polish is a logical next step. 

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

Ditto.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jul 2018 12:31:02 +1000

On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey <[email-masked]> wrote:
> 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)?

I don't think that pinning is a good idea.  We've experience that
suggests that it's more of a footgun than a useful mechanism.  That
isn't to say that there isn't a domain where it makes sense.

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

No.  We need fewer extension points, not more.  It's already hard
enough to ensure that the ones we have remain usable.  ekr's
suggestion to reduce the number of *types* of extension point would be
a compromise position here, but I don't think that's the best outcome.

If we mess this one up, we can make another extension, or use another
extension to fix it if that makes more sense.  Yes, that's messy, but
the above assessment supports the notion that we won't need v2.

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

Allowing denial of existence in the extension is fine.  It somewhat
depends on having a prior expectation of having some form of DNSSEC
record there, which hits all the concerns above, so I'm not sure what
concrete value it provides.  I see no harm in allowing it though.

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

I have to confess, I had a lot of trouble reading the new text.  It's
good, and contains much of what is needed, but it's very wordy.  I
think another iteration or two would help.

If I can summarize:

We consider the case where DANE is considered stronger than PKIX or a
valuable addition to PKIX, because this extension is only of use in
those circumstances.  If an attacker can compromise PKIX, then they
can just not send the DANE extension.  With prior knowledge, a relying
party might know to expect DANE, but that isn't always possible,
especially when this mechanism is introduced into a PKIX-only
ecosystem.  A relying party can't assume that use of DANE with one
connection implies that other connections to the same peer will also
be secured with DANE.

There's a lot of extra words around that message, and I fear that the
message will be lost as a result.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jul 2018 22:33:10 -0400

> Do we have a count of major implementors who say they will do so?

Well, what is a "major implementation"?  TLS is not just browsers,
and adoption does not always begin the day the RFC is published.
DANE adoption only started 2+ years after RFC6698, and is still
ramping up.  The important thing here is to not *preclude* adoption
by needlessly limiting the scope to just "greenfield" applications.

It is rather clear that the present draft is only compatible with
applications that mandate the extension.  Some form of "STS-lite"
pinning is needed to support incremental adoption by existing
applications.

> whereas you cannot grease opaque bytes.

It is far from clear why "grease" is applicable here, or what "grease
barriers" either proposed form of the reserved field presents.

    * With the 16-bit field, servers set it to zero until non-zero
      values are specified.

    * With the <0..255> byte value, servers send an empty value
      until non-empty values are specified.

    * In either case clients ignore either non-zero or non-empty
      values, until they implement the specification, and must not
      employ pinning until such time.

I thought the authors wanted this done quickly, but lately they
seem to be in no rush to get the document finished.  If we're no
longer in a hurry to get this out the door before all the issues
are sorted out, we can specify the downgrade protection now, in
which case there's no need for reserved fields, we can define the
pinning approach now.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jul 2018 22:39:19 -0400

> isn't to say that there isn't a domain where it makes sense.

Did you oppose MTA-STS?  The proposed "pinning" is very much like
a simpler form of MTA-STS, and nothing unlike HPKP.

Perhaps it would be much less confusing if we stopped calling it
"pinning" (which seems to be a traumatic memory trigger for the
HTTP community).  We can call this "strict TLS DANE chain" or some
such, which is a much better analogy in any case.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 19:46:13 -0700

On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni <[email-masked]>
wrote:

> Well, what is a "major implementation"?

Well, we could start with "what implementations are going to do this"?

>       employ pinning until such time.

Yes, and this is where grease comes in. Specifically, if implementations
are required to send empty values (or zero) until something is specified,
then implementations which *require* those values and choke otherwise go
undetected. By contrast, if we have a structured Extension code point with
requirements to ignore unknown extensions, then implementations can send
grease extension values and verify that the peer properly ignores them. In
any case, as Martin Thomson says, we have a perfectly good extension
mechanism which can be used to add pinning later without creating any
placeholder here.

> seem to be in no rush to get the document finished.

Well, I'm not an author, so I'm the wrong person to be addressing this to.

If we're no
> which case there's no need for reserved fields, we can define the

That would first require there being consensus to do pinning.

-Ekr

---

From: Melinda Shore <[email-masked]>
Date: Wed, 4 Jul 2018 18:51:46 -0800

> seem to be in no rush to get the document finished. 

I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft or ambiguity.  Unfortunately there doesn't appear to
be one, so compromise is necessary.

I also think there's been already been a pretty serious process abuse
here and tend to think that the new implication that we can go forward
in a timely way if everybody just agrees with you is additionally
problematic.  But as I said earlier, I'll go along with the working
group consensus and will not block a decision I don't happen to like.
That's the implicit contract we sign with the IETF when we decide to
bring work here.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
                 34C0 DFB8 9172 9A76 DB8F

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jul 2018 22:56:55 -0400

> be one, so compromise is necessary.

Since the updated security considerations and new denial of existence
text are not looking controversial, it would be helpful to all
parties to get a new revision out with those merged so they can be
polished and put behind us.  That leaves just the reserved field
unresolved.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Jul 2018 23:16:16 -0400

> Well, we could start with "what implementations are going to do this"?

Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT,
and I am a maintainer of both the TLS features in Postfix, and the
X.509 code in OpenSSL, I expect to add support for DANE chain in
OpenSSL and Postfix in 2019.  Next on the list would be Dovecot and
mutt, but it'd be nice if that was done by one of the primary
maintainers of those packages.

> undetected.

Any broken clients will get fixed.  The client that motivated this
draft is purported to require the extension, and the others will
take some time to appear, highly likely not until the follow-on
spec is written.  The odds of real problems here are negligible.

> By contrast, if we have a structured Extension code point with
> grease extension values and verify that the peer properly ignores them.

There's no need for nested extensions, they serve no purpose.  If DANE
chain STS is in a separate extension, it may as well be top-level.

> mechanism which can be used to add pinning later without creating any

At much too much complexity, unless we fork-lift this extension
plus the additional payload, and largely obsolete this draft.  Using
one extension to pin itself and another is much too cumbersome.

> That would first require there being consensus to do pinning.

That is, to address the security gap highlighted in the upcoming
more complete security considerations.  s/pinning/DANE chain STS/

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 20:42:38 -0700

> maintainers of those packages.

It would be nice to hear from those maintainers, as well as from some of
the bigger email senders (e.g., GMail, Yahoo Mail, etc.)

> spec is written.  The odds of real problems here are negligible.

It has not been my experience or, I think, that of the WG, that this is the
case. Rather, once there is a significant fielded population of intolerant
endpoints, generating the offending PDU causes too much breakage and
instead you have to send something which doesn't break those endpoints. cf.
the padding extension, supported_versions, and the CCS hack.

> one extension to pin itself and another is much too cumbersome.

Yes, I appreciate that this is your opinion.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Jul 2018 23:59:40 -0400 (EDT)

On Wed, 4 Jul 2018, Eric Rescorla wrote:

> In any case, as Martin Thomson says, we have a perfectly good
> extension mechanism which can be used to add pinning later without creating any placeholder here.

The IETF should not publish security protocols that are trivially downgraded.

The work _should_ really be completed within this document to address
all downgrade attacks. As a _compromise_ there have been suggestions
done to let this document be published while commiting to a method for
downgrade protection. That was not an invitation to punt it to infinity
or an invitation to have a bis replace this entire document just to be
ignored because some people only care about the DOH case. Besides, we
would end up with identical specs apart from two bytes and the same
discussion about these two bytes would happen about whether the new
document Obsoletes: this one. It won't resolve the issue at all and
meanwhile some people have implemented and deployed a protocol that can
be trivially downgraded, or bothered to just not implement because it
offers no real security benefit.

If you don't like TLS extension pinning, come up with another mechanism
that resolves the downgrade attack. But note that none of the comments
against using two bytes for hour scale extension pinning withstood
scrutiny and half of them were appeals to authority or based on people's
gut feelings.

So far, I've only heard incorrect comparisons with other pinning mechanism
problems that ignore the fact that the source of this extension material
is in DNSSEC and that the extension data is a "live snapshot" of active
DNSSEC data and thus never stale/old/bad/brokeb.

> That would first require there being consensus to do pinning.

Again, why do you think it would be even valid to have consensus to
deploy a trivially downgradable security mechanism? I would certainly
expect the IESG to send this back to the drawing board, even if they
missed it on their first evaluation round.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Jul 2018 00:01:24 -0400

> the bigger email senders (e.g., GMail, Yahoo Mail, etc.)

The question is premature, some implementations are not candidate
early adopters.  Once library support is there, and there are
some early adopters deployed, then the others follow.

Postfix implemented DANE in 2014, a bunch additional MTAs added
support in 2017 and 2018, and I expect more in 2019.

> case.

Yes, that's true with major TLS revisions.  This extension, however,
will not see such rapid uptake that sloppy early versions will need
to be revised.  You're on the one hand questioning whether any
adoption will take place at all, and on the other concerned that
early adopters will be intolerant of non-sentinel values of the
proposed reserved field.  Your first concern is closer to the mark.

While I'd like to have the second problem, the reality is that for
the first couple of years the number of implementations will be
rather small, and the specification of the reserved field can and
should predate the bulk of the follow-up implementations.

> Rather, once there is a significant fielded population of intolerant

Sure, but "significan fielded population" is not a problem we'll
be having here for some time.  This is a space where uptake will
be slow, and the early adopters will be well aware of the requirements.
By the time the late adopters arrive, we'll have the downgrade
protection fully specified.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Jul 2018 00:40:25 -0400 (EDT)

>       > Well, we could start with "what implementations are going to do this"?

[postfix and openssl apparently not big enough ]

> It would be nice to hear from those maintainers, as well as from some of the bigger email senders (e.g., GMail, Yahoo Mail,
> etc.)

This is not a valid direction for this technical discussion, and goes
pretty directly against the Tao of the IETF. But if you want to go
that way, here is my proposed question to those providers:

 	Do you object to your company's product needing to send two
 	additional zero bytes in a TLS handshake if/when you support
 	DANE stappling in TLS in the case that you do NOT want to be
 	protected from downgrade attacks so that other entities that DO
 	want to support downgrade protection can do so without creating
 	yet another a mostly duplicate internet standard that comes with
 	its own delay in deployment?

I am fine with people believing they do not need downgrade protection,
although in my experience most downgrade possibilities end up getting
abused at some point for malicious purposes. But it would be great if
those people could reciprocate that freedom of choice to those that do
want downgrade protection so they can make actual security decisions
based on this standard.

Thank you,

Paul