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. > > 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 > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
