On Tue, Jan 23, 2024 at 1:20 AM tirumal reddy <[email protected]> wrote:
> Hi Paul, > > Thanks for the review. Please see inline > > On Sat, 20 Jan 2024 at 03:55, Paul Wouters <[email protected]> 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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
