Re: [OPSAWG] 🔔 WG Last Call for draft-ietf-opsawg-mud-iot-dns-considerations-05

[Michael Richardson <[e-mail]>]

tirumal reddy <[e-mail]> wrote:
    > I support progressing the draft and I have the following comments/nits
    > which should be straightforward to address:

    > 1.

    > It has been suggested that one answer to this problem is to provide a
    > forced
    > intermediate for the TLS connections. This could in theory be done for TLS
    > 1.2 connections.

I totally agree.  But, did you want more said here?
I think that Ben's suggestion was to do everything via SOCKSv5, which would
not have quite the same problems, but I think that is completely undeployable.

    > I would say SNI inspection is not useful in TLS 1.3 (with or without ECH).

    > 2.
    > XXX --- explain in detail how this can fail.
    > XXX --- explain N:1 vs 1:1 for virtual hosting.

Nit> You may want to remove "XXX".

I have expanded the contents.  I had feared this work would be impossible,
but with sufficient coffee on a snowy Sunday morning, I think that I
succeeded.
Please see, and comment on:
   https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-mud-iot-dns-considerations/commit/6162d432cbc8395fa79b759f6ee9636a278ef800

I've also appended the text to the end of this message, after my other actions.

    > 3.
    > The third section of this document details how current trends in DNS
    > presolution
    > such as public DNS servers, DNS over TLS (DoT), and DNS over HTTPS (DoH)
    > cause
    > problems for the strategies employed. Poor interactions with
    > content-distribution
    > networks is a frequent pathology that can result.

    Comment> You may also want to refer to DoQ.

Done.

    > 4.
    > A third problem involves the use of HTTPS. IP address literals do not
    > provide enough
    > context for TLS ServerNameIndicator to be useful [RFC6066]. This limits the
    > firmware repository to be a single tenant on that IP address, and for IPv4
    > (at least),
    > this is no longer a sustainable use of IP addresses.

    tiru> You may want to look into
    tiru> https://www.rfc-editor.org/rfc/rfc8738.html, it will address the limitation
    tiru> with IP address as an identifier in certificates.

I don't think that automating IP address inclusion in certificates is useful or the point here.
During a big distribution even, a supplier might massively increase the
number of servers that serve particular content.  (Netflix among others does this)
If HTTPS is to be used, the servers need certificates, and if the servers are
referenced by IP address, then they can't do virtual hosting of any time.

This is contrasted to systems like Amazon S3, where a single *name* could be
distributed among hundreds of servers, and at the same time, those servers
(IP address end-points) could also be hosting content for hundreds of names.

    > 5. Section 6.5> I suggest replacing the references by the drafts adopted by
    > ADD WG (DNR and DDR)..

okay.

   Secure discovery of network provided DoH/DoT resolver is possible using
   the mechanisms discussed in {{?I-D.ietf-add-split-horizon-authority}}
   section-4.

Is this still the right reference?  It seems that section 4 is still correct.

===
the "it won't work" text:

The most naive method is to try to map IP addresses to names using the in-addr.arpa (IPv4), and ipv6.arpa (IPv6) mappings.

## Failing strategy

Attempts to map IP address to names in real time fails for a number of reasons:

1. it can not be done fast enough,

2. it reveals usage patterns of the devices,

3. the mapping are often incomplete,

4. even if the mapping is present, due to virtual hosting, it may not map back to the name used in the ACL.

This is not a successful strategy, its use is NOT RECOMMENDED for the reasons explained below.

### Too slow

Mapping of IP address to names requires a DNS lookup in the in-addr.arpa or ip6.arpa space.
For a cold DNS cache, this will typically require 2 to 3 NS record lookups to locate the DNS server that holds the information required.  At 20 to 100ms per round trip, this easily ads up to significant time before the packet that caused the lookup can be released.

While subsequent connections to the same site (and subsequent packets in the same flow) will not be affected if the results are cached, the effects will be felt.  The ACL results can be cached  for a period of time given by the TTL of the DNS results, but the lookup must be performed again in a number of hours to days.

### Reveals patterns of usage

By doing the DNS lookups when the traffic occurs, then a passive attacker can see when the device is active, and may be able to derive usage patterns.  They could determine when a home was occupied or not.  This does not require access to all on-path data, just to the DNS requests to the bottom level of the DNS tree.

### Mappings are often incomplete

A service provider that fails to include an A or AAAA record as part of their forward name publication will find that the new server is simply not used.
The operational feedback for that mistake is immediate.
The same is not true for reverse names: they can often be incomplete or incorrect for months or even years without visible affect on operations.

Service providers often find it difficult to update reverse maps in a timely fashion, assuming that they can do it at all.
Many cloud based solutions dynamically assign IP addresses to services, often as the service grows and shrinks, reassigning those IP addresses to other services quickly.
The use of HTTP 1.1 Virtual Hosting may allow addresses and entire front-end systems to be re-used dynamically without even reassigning the IP addresses.

In some cases there are multiple layers of CNAME between the original name and the target service name.
This is often due to a layer of load balancing in DNS, followed by a layer of load balancer at the HTTP level.

The reverse name for the IP address of the load balancer usually does not change.
If hundreds of web services are funnelled through the load balancer, it would require hundreds of PTR records to be deployed.
This would easily exceed the UDP/DNS and EDNS0 limits, and require all queries to use TCP, which would further slow down loading of the records.

The enumeration of all services/sites that have been at that load balancer might also consistitute a security concern.
To liimt churn of DNS PTR records, and reduce failures of the MUD ACLs, operators would want to  add all possible names for each reverse name, whether or not the DNS load balancing in the forward DNS space lists that end-point at that moment.

### Names can have wildcards

In some large hosting providers content is hosted under some URL that includes a wildcard.
For instance, github.io, which is used for hosted content, including the Editors' copy of internet drafts stored on github, does not actually publish any names.
Instead a wildcard exists to answer.

github would be unable to provision all infinity of possible names into the PTR records.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide