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

[tirumal reddy <[e-mail]>]

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.


>
> Some specific questions:
>
>    +--rw supported-tls-version*        ianatp:tls-version
>           +--rw supported-dtls-version*       ianatp:dtls-version
>           +--rw cipher-suite* [cipher hash]
>           |  +--rw cipher    ianatp:cipher-algorithm
>           |  +--rw hash      ianatp:hash-algorithm
>           +--rw extension-type*
>           |       ianatp:extension-type
>           +--rw accept-list-ta-cert*
>           |       ct:trust-anchor-cert-cms
>           +--rw psk-key-exchange-mode*
>           |       ianatp:psk-key-exchange-mode
>           |       {tls13 or dtls13}?
>           +--rw supported-groups*
>           |       ianatp:supported-group
>
> It seems for TLS 1.3, "cipher" is the AEAD cipher. But for TLS 1.2
> this could be a non-AEAD cipher in a ciphersuite that includes the
> DH part in the ciphersuite. How would those be expressed? I
> know the documents point to advise to use only AEAD for TLS 1.2,
> but that does not mean it does not need to be able to express it here?
> eg how to express the TLS 1.2 ciphersuit TLS_DH_DSS_WITH_AES_128_CBC_SHA
> in this model? See also the "supported groups" entry (I assume this is
> about DH groups?)
>

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
.


>
>           +--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.
>
> Section 9:
>
>         An attacker cannot read the MUD URL and identify the IoT device.
>
> Should this be "so that an attacker ....." ?
>
> 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.

Cheers,
-Tiru


>
> Once the above questions are answered and possibly resolved with new text,
> I think the document is ready for IETF LC.
>
> Paul
>
>