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'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. 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. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
