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

[tirumal reddy <[e-mail]>]

On Sun, 22 Jan 2023 at 22:47, Michael Richardson <[e-mail]>
wrote:

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

Agreed. My suggestion is to update the text as follows:

In TLS 1.3 with or without the use of ECH, middlebox cannot rely on SNI
inspection because a malware could lie about the SNI and middlebox without
acting as a TLS proxy does not have visibility into the server
certificate.


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

Got it, Thanks.


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

No, you will have to refer to DDR
(https://datatracker.ietf.org/doc/draft-ietf-add-ddr/) and DNR
(https://datatracker.ietf.org/doc/draft-ietf-add-dnr/).
The draft ietf-add-split-horizon-authority is specific to establishing
local DNS authority in Split-Horizon Environments. I don't think it is
relevant to this document.

-Tiru


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