Re: [OPSAWG] AD review draft-ietf-opsawg-mud-tls-12

[Paul Wouters <[e-mail]>]

On Tue, Jan 23, 2024 at 1:20 AM tirumal reddy <[e-mail]> wrote:

> Hi Paul,
>
> Thanks for the review. Please see inline
>
> On Sat, 20 Jan 2024 at 03:55, Paul Wouters <[e-mail]> wrote:
>
>> Hi,
>>
>> I am assisting Rob Wilton with some documents, as so I am the (temporary)
>> responsible AD for draft-ietf-opsawg-mud-tls
>>
>> I have reviewed this document and have a few questions and comments. I
>> think the document generally is clear.
>>
>> I can see the MUD use case for using endpoint recognition based on TLS
>> properties (eg SNI, ClientHello in TLS 1.2, IP addresses and hostnames. I
>> don't have as much faith in using MUD to identify rogue TLS connections
>> based on their cryptographic or extension properties (eg ciphersuites). I
>> would expect that ciphersuites would change, and that an IoT device would
>> mostly only implement the one or two ciphersuites (and TLS extensions) it
>> supports. Malware would have to ensure their C&C can talk all kinds of
>> ciphersuites and extensions to allow all kinds of limited implementation
>> IoT devices to connect to it. So I don't think those parts would likely to
>> trigger a MUD security rule. But there is no harm in trying.
>>
>
> In our research, TLS properties can be used to identify benign and malware
> flows. The results with Google Home and several malware families were
> presented in T2TRG few years back, please see
> https://datatracker.ietf.org/meeting/interim-2020-t2trg-01/materials/slides-interim-2020-t2trg-01-sessa-mud-dtls-profiles-for-iot-devices-00.pdf for
> details.
>

The question remains, is the additional infrastructure being build to
detect this going to be useful for long. I assume the malware will quickly
adept. Anyway, as I said, I don't object to deploying this and seeing how
long it will be useful for.

Good catch, modified the YANG module to use uint16 to represent the cipher
> suite to match the TLS IANA registry of cipher suite (that includes
> non-AEAD ciphers). The supported-group in the YANG module matches TLS
> supported groups registry, see
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> .
>

Sounds good.


>
>
>>
>>           +--rw application-protocol*
>>
>> Is ALPN meant here?
>>
>
> Yes, please see Section 5.3 of the draft
>
>   typedef application-protocol {
>     type string;
>     description
>       "Application-Layer Protocol Negotiation (ALPN) Protocol ID
>        registry as defined in Section 6 of RFC7301.";
>   }
>
>
>> Perhaps using "alpn" instead of "application-protocol"
>> would be clearer? But I'm okay with whatever the WG / authors deem better.
>>
>
I take it you want to leave it as it, which is fine.


>
>> Section 9:
>>
>>         An attacker cannot read the MUD URL and identify the IoT device.
>>
>> Should this be "so that an attacker ....." ?
>>
>
This was not answered, but it is something the RFC Editor or other IESG
members will point out as well.


>
>> It could use a more inclusive term for "man-in-the-middle", eg "on path
>> attacker" or "machine-in-the-middle"
>>
>
> Agreed, updated text as follows:
>
>    The MUD URL MUST be encrypted and shared only with the authorized
> components in the
>    network (see Section 1.5 and Section 1.8 of [RFC8520]) so that an on-
>    path attacker cannot read the MUD URL and identify the IoT device.
>

Sounds good.

Once I see -13, I will initiate the IETF Last Call.

Paul