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.
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?)
+--rw application-protocol*
Is ALPN meant here? 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"
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
