Thanks Ben and Eliot for the feedback. Please see inline On Tue, 15 Sep 2020 at 14:51, Eliot Lear <l...@cisco.com> wrote:
> Hi Ben > > Thanks for the response. Please see below. > > > > > Agreed ... but this proposal appears to be predicated on a contrary > assumption. It assumes that it is difficult for malware to learn the TLS > profile of the device, and then proceeds to place this profile information > in the (public) MUD file, where malware can easily retrieve it. > > Ok, I didn’t take that from this discussion. > I see the confusion, will try to clarify the issues raised: a) The MUD URL includes privacy sensitive device details like (device type and firmware version), and it should be stored in a secure location (like TEE to avoid exposure to an unauthorized software) and to avoid sending the MUD URL in clear text otherwise it will help an attacker to exploit a vulnerability on the IoT device. It is already discussed in RFC8520. b) One of the comments is that an attacker can observe the traffic from the IoT device, learn the TLS profile and try to mimic some of the TLS profile parameters of legitimate clients. This attack is discussed in detail in Sections 3 and 5. Please have a look. c) The proposed mechanism not only helps detecting malware but also helps identifying TLS and cryptographic vulnerabilities on the IoT device (to prevent the device from getting compromised in the first place). > > > > > I'm not thinking of the hours-days timescale of MUD file updates; I'm > thinking of the months-years timescale of updating standards to support new > features. How long does a device have to wait after a new protocol > revision comes out before it can start using the new protocol? > > Ok, I see what you are saying. Thanks for getting me there. > > The question is what to do when you start seeing something you don’t > understand. Let’s take a TLS extension, for instance. If the TLS > extension is unknown to the f/w but is declared somehow, that tells the > firewall that they have some coding to do, and should be conservative about > complaining over something that is out of profile. Yes. > I don’t see that as a show stopper. What I do see as a showstopper would > be if, as is written and you rightly observe, a new rev of a YANG model is > required to introduce the TLS extension, so that part would need to be > described in a more flexible manner (e.g, an IANA registration or > similar). I’d suggest the authors consider that. > Agreed, the YANG model relies on IANA for TLS parameters values including extension type values. Even if a f/w does not support a new extension, it can still identify whether the new extension is included in the MUD profile. If the extension is not included in the MUD profile, presence of unauthorized software is detected. We will update the draft to make it more clear. -Tiru > Eliot > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
