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

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.
The MUD policy enforcement point could observe the Server Name Identifier
(SNI) [RFC6066].
Some Enterprises do this already. But, as this involves active termination
of the TCP
connection (a forced circuit proxy) in order to see enough of the traffic,
it
requires significant effort. But, TLS 1.3 provides options to encrypt the
SNI as the
ESNI, which renders the practice useless in the end.

Comment> In TLS 1.3, the client can lie about SNI and a firewall passively
inspecting the handshake cannot identify it without looking into the server
certificate (which is not possible).

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

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.

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.

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

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

Cheers,
-Tiru

On Fri, 9 Dec 2022 at 21:53, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
wrote:

> Dear OPSAWG members,
>
> this email starts a four week period for a Working Group Last Call of
>
> >
> https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-05.html
>
> ending on Friday, January 6th 2023.
>
> Several reviews of this document were submitted. The most recent one
> from the Security Directorate was addressed. The authors believe the
> Internet-Draft is ready for a WGLC and the chairs are in support of a
> WGLC. The draft has been discussed visibly on the list and at previous
> IETF meetings.
>
> Please reply with your active support (+1 required) or objections and
> your assessment of whether or not it is ready to proceed to publication
> before January 6th 2023.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>