Subject: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

From: Jim Reid <[email-masked]>
Date: Wed, 5 Jul 2017 17:30:49 +0100

I’ve got a few concerns/issues with the document.

1) There probably needs to be clearer guidance about the use cases for this extension and the trade-offs between TLS clients doing DNSSEC validation for themselves instead of sending DNS lookups to a validating resolver server. How does an application developer decide which approach would or wouldn’t be appropriate?

2) I’m not sure there is much of an "associated latency penalty” from DNS lookups. Something’s going to esxperience this one way or another. Either the TLS client takes that hit or the TLS server does it for them before it sends back the requested DNS data. And in both cases, whatever is making the DNS lookups should be benefitting from what’s in the resolver’s cache. That cached data may even have been validated too.

3) Something should be said about algorithm agility. We can be reasonably sure web browsers, DNS servers, smart phones and so on will generally have up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire and forget embedded systems, IoT devices, etc -- might never get updated once they’re deployed. If these clients use their own DNSSEC validators, they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds a new flavour of ECC or even an all-new signing protocol.

4) It’s not clear if TLS clients can or should cache the DNS data (and the resulting validations?) returned though this extension. Suppose a jabber client validates foo.com, does it have to start at the root and work all the way down to validate bar.com? Could it start that validation at the previously validated and new cached trust anchor for .com? Can/should negative answers -- NOHOST/NXDOMAIN responses -- be cached?

5) How does a TLS client behave when its DNSSEC validation of a TLSA record or whatever fails? Can/should it give up or fall back to conventional validation of the certificate via a CA?

6) The draft doesn't seem to take account of key rollovers when DNS data will be signed by two or more keys. Zone signing keys are missing from the examples too. These might well have been omitted for cosmetic reasons. IMO they need to be included in the final document to illustrate what implementers can expect to find when the DNS returns signed data.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Jul 2017 17:12:11 +0000

On Wed, Jul 05, 2017 at 05:30:49PM +0100, Jim Reid wrote:

> 1) There probably needs to be clearer guidance about the use cases for
> this extension and the trade-offs between TLS clients doing DNSSEC
> validation for themselves instead of sending DNS lookups to a validating
> resolver server. How does an application developer decide which approach
> would or wouldn't be appropriate?

On today's Internet, DNSSEC is not generally available to end-user
devices.  There are too many "last mile" problems.  Thus, while
direct acquisition of DANE TLSA records works for (e.g.) dedicated
SMTP servers, any end-user application that wants to do DANE TLS
needs to use the proposed extension.

Perhaps you're asking whether once the relevant records are obtained,
their validation should be via library calls to a suitable API, or
via a suitable protocol to the local resolver?  The latter would
just be another "suitable API".  So I think this issue falls outside
proper subject matter for the IETF.  Whatever the validation method
is, it must avoid using untrusted oracles or leaking the records
in the clear.

> 2) I'm not sure there is much of an "associated latency penalty" from DNS
> lookups. Something's going to experience this one way or another. Either
> the TLS client takes that hit or the TLS server does it for them before
> it sends back the requested DNS data.

Except that the records will be warm in the server's cache, since
many clients will be asking it for the *same* data.  The same is
not as likely to be true at the client.  So there is indeed a likely
latency reduction in farming out the lookups to the server.

> 3) Something should be said about algorithm agility. We can be reasonably
> sure web browsers, DNS servers, smart phones and so on will generally have
> up-to-date DNSSEC validators and/or TLS code. Some TLS clients -- fire
> and forget embedded systems, IoT devices, etc -- might never get updated
> once they're deployed. If these clients use their own DNSSEC validators,
> they will be screwed when/if DNSSEC drops SHA1 signatures (say) or adds
> a new flavour of ECC or even an all-new signing protocol.

SHA2 is already defined and widely used for DS records.  The X25519
and X448 EC algorithms are already defined (or will be by the time
this draft becomes an RFC).  So there's not much churn on the
immediate horizon.  Devices doing all the validation locally will
need software updates roughly once a decade (DNS parameters change
slowly).  A secure channel to a *trusted* resolver would avoid the
problem, but trustworthy off-device resolvers are very unlikely to
be ubiquitous.

> 4) It's not clear if TLS clients can or should cache the DNS data (and
> the resulting validations?) returned though this extension.

The server will return TTLs, and caching per those TTLs is no less
appropriate than it is in DNS generally.

> Suppose a
> jabber client validates foo.com, does it have to start at the root and
> work all the way down to validate bar.com? Could it start that validation
> at the previously validated and new cached trust anchor for .com? Can/should
> negative answers -- NOHOST/NXDOMAIN responses -- be cached?

Negative answers will not generally appear in this protocol, since
the server is just returning its TLSA records and associated
signatures.  The only "negative" answers are NSEC/NSEC3 records
that validate wildcard responses.  There's little need to cache
these, it suffices to just cache the TLSA records associated
with the server, and forget the supporting validation RRs.

> 5) How does a TLS client behave when its DNSSEC validation of a TLSA record
> or whatever fails? Can/should it give up or fall back to conventional
> validation of the certificate via a CA?

This is application/configuration dependent.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 6 Jul 2017 21:47:04 -0400

> I’ve got a few concerns/issues with the document.

Hi Jim,

I largely agree with the responses Viktor gave in a previous message. I'll
comment on the last point where he did not:

> 6) The draft doesn't seem to take account of key rollovers when DNS data
> will be signed by two or more keys. Zone signing keys are missing from the
> examples too. These might well have been omitted for cosmetic reasons. IMO
> they need to be included in the final document to illustrate what
> implementers can expect to find when the DNS returns signed data.
>

I assume you're referring to the examples in Appendix D (Test Vectors)?

These are working examples that implementers can test code against. But it
looks like the testbed involved in these examples uses combined signing
keys (i.e. ones that are both the zone's secure entry point and the ZSK).
Perhaps we should use an example with the KSK/ZSK split to make them look
more like the real world. Let me discuss with Willem Toorop (co-author) who
generated these ...

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Thu, 6 Jul 2017 21:53:26 -0400

On Wed, Jul 5, 2017 at 1:12 PM, Viktor Dukhovni <[email-masked]>
wrote:

> this draft becomes an RFC).

RFC 8080, defining Ed25519 and Ed448 for DNSSEC, is already published.
There are already some early implementations (PowerDNS and NLnet Labs'
Unbound; maybe others).

> So there's not much churn on the

Regarding churn, I expect we'll have several post quantum signature
algorithms for DNSSEC in the 5 to 10 year horizon.

-- 
Shumon Huque

---

From: Jim Reid <[email-masked]>
Date: Fri, 7 Jul 2017 15:11:20 +0100

> On 5 Jul 2017, at 18:12, Viktor Dukhovni <[email-masked]> wrote:
> 

I am too painfully aware of those last mile issues.
 
IMO the draft could be clearer about the fact it’s aimed at TLS clients that don’t have access to or a trust relationship with a validating DNS resolver. It might also be worthwhile explaining the trade-offs between the DNSSEC lookup and TLS chaining approaches and how an implementer or operator can choose between them when/if both are available. Though if the spec was to say “don’t bother with DNSSEC lookups at all and just use this chaining extension”, that would be fine.

> via a suitable protocol to the local resolver?

No. I couldn’t care less about API issues or how the RRSIGs get validated. They’re implentation details for the implementation detail. I am uneasy at the prospect of every TLS client application include what will be essentially its own validating DNS resolver when there could/should be one of these already running on the device itself.

> latency reduction in farming out the lookups to the server.

OK.

It might be helpful to explicitly say “TLS server” rather than “server” to avoid confusion or ambiguity. Sometimes this is obvious from the context. But at other places in the draft “server” could be read as “DNS server”.

> appropriate than it is in DNS generally.

Is there some reason why this isn’t in the draft?

> This is application/configuration dependent.

That probably needs to be captured in the document too.

---

From: Jim Reid <[email-masked]>
Date: Fri, 7 Jul 2017 15:14:51 +0100

> On 7 Jul 2017, at 02:47, Shumon Huque <[email-masked]> wrote:
> 

Yes.

> These are working examples that implementers can test code against. But it looks like the testbed involved in these examples uses combined signing keys (i.e. ones that are both the zone's secure entry point and the ZSK). Perhaps we should use an example with the KSK/ZSK split to make them look more like the real world. Let me discuss with Willem Toorop (co-author) who generated these ...

Willem told me he’d used the KSK as the ZSK for cosmetic reasons. Examples showing the KSK/ZSK split would show how things generally work the real world.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 7 Jul 2017 11:06:45 -0400

On Fri, Jul 7, 2017 at 10:11 AM, Jim Reid <[email-masked]> wrote:

> IMO the draft could be clearer about the fact it’s aimed at TLS clients
> that don’t have access to or a trust relationship with a validating DNS
> resolver.

It is not aimed solely at those clients.

The intro mentions 3 things: (1) TLS clients don't need to do any
additional DNS lookups for DANE/DNSSEC - the latency issue, (2) TLS clients
don't need to deal with breakage caused by middlebox/last mile issues if
they tried to do those lookups, and (3) they don't have secure access to a
validating resolver. If an application has any subset of these issues, it
might be candidate user of this extension.

> No. I couldn’t care less about API issues or how the RRSIGs get validated.
> They’re implentation details for the implementation detail. I am uneasy at
> the prospect of every TLS client application include what will be
> essentially its own validating DNS resolver when there could/should be one
> of these already running on the device itself.
>

Maybe some day all end user machines will have a validating resolver, but
this isn't remotely close to a reality today.

> It might be helpful to explicitly say “TLS server” rather than “server” to
> avoid confusion or ambiguity. Sometimes this is obvious from the context.
> But at other places in the draft “server” could be read as “DNS server”.
>

Ok, we can look through the text and disambiguate where needed.

> Is there some reason why this isn’t in the draft?

We've had this discussion numerous times over the life of this draft, and
there was never any consensus for the client caching or not. An
implementation could have the client cache the data, and only validate the
portion of the chain that it needs to, without any wire protocol change.
I'm okay with mentioning that possibility.

IMO, the real gain from having the client cache data, is that the server
could then potentially send a much smaller DNSSEC chain. But this requires
the client to signal what they've cached, and makes the protocol more
complex. I would prefer to leave that to a future revision of the spec,
after we've gained some operational experience with the current one.

-- 
Shumon Huque

---

From: Jim Reid <[email-masked]>
Date: Fri, 7 Jul 2017 16:34:57 +0100

> On 7 Jul 2017, at 16:06, Shumon Huque <[email-masked]> wrote:
> 
> IMO, the real gain from having the client cache data, is that the server could then potentially send a much smaller DNSSEC chain. But this requires the client to signal what they've cached, and makes the protocol more complex. I would prefer to leave that to a future revision of the spec, after we've gained some operational experience with the current one.

Shumon, I think the biggest gain would be fewer RRSIGs for the client to validate. Having the server send a smaller DNSSEC chain (and perhaps add something to the protocol for a client to signal that) probably won’t have the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS client didn’t need to revalidate everything in the chain for tlsa.foo.com after closing and reopening a TLS session to that end-point or it could start at the previously validated delegation for .com when the TLS server returned the full chain for tlsa.bar.com.

As you hint at, it would be good to get more data and operational expertise.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 7 Jul 2017 11:50:03 -0400

On Fri, Jul 7, 2017 at 11:34 AM, Jim Reid <[email-masked]> wrote:

> Shumon, I think the biggest gain would be fewer RRSIGs for the client to
> validate. Having the server send a smaller DNSSEC chain (and perhaps add
> something to the protocol for a client to signal that) probably won’t have
> the right cost/benefit optics. YMMV. It would be a Good Thing if a TLS
> client didn’t need to revalidate everything in the chain for tlsa.foo.com
> after closing and reopening a TLS session to that end-point or it could
> start at the previously validated delegation for .com when the TLS server
> returned the full chain for tlsa.bar.com.
>

Okay, absent any strenuous objections, I propose that we mention that the
client may cache data from the chain. For the case of a TLS client
re-connecting to the same end point, most likely TLS session resumption
would be used (thus dnssec_chain re-validation wouldn't be needed) so this
optimization doesn't gain anything. But yes, it would help save the client
some signature validation work in the case of tlsa.foo.com to tlsa.bar.com.

-- 
Shumon Huque

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 7 Jul 2017 23:05:05 +0000

> after we've gained some operational experience with the current one.

Once the client obtains a validated TLSA RRset for the service
endpoint, it may (up to the TTLs of the provided records, validated
to conform to the max ttl of the RRSIGs and not exceed the RRSIG
expiration) simply not omit the extension in subsequent requests,
and validate the server certificate per the cached TLSA RRs.

This requires no complex protocoll machinery, just caching of the
validated TLSA RRset.  This is essentially the same as obtaining
validated TLSA records via DNS, where they are cached in the client's
resolver up to the relevant TTL.  Only here the client can choose
to cap the TTL to a lower value, and ask the server again sooner.
The client cannot as easily cap the maximum cache TTL of its
iterative resolver.

So, indeed I would not try to engineer partial caching, with the
client soliciting a portion of the complete set of validation
RRsets.  However, simple caching of the given server's validated
TLSA RRset for repeat visits is not unreasonable, if the client
implementation chooses to do that.

Servers may wish to cap their TLSA record TTLs knowing that they
may be cached by clients.  Clients might also save some CPU by
not revalidating previously validated RRsets, but they will not
avoid the overhead of receiving the full set of records from
the server.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 7 Jul 2017 21:03:03 -0400

> and validate the server certificate per the cached TLSA RRs.

( assumed typo: s/not omit/omit/ )

This is quite a reasonable and simple optimization, and I think we should
document it in the draft. It may often be short circuited by TLS session
resumption, but it's so simple that it's probably worth doing.

Thanks!
--
Shumon Huque