On 8 October 2013 22:14, Stephen Farrell <[email protected]> wrote: > > > Hi, > > Steve's mail argues for the current IETF position that > mandatory-to-implement (MTI) is the correct target IETF > specifications. > > Some folks (me included to be honest) wonder if the current > situation argues for raising the bar there somewhat on the > basis that MTI security features are frequently turned off > or not sufficiently well tested to be usable. (Pick your > favourite example, mine are usually rfc4744 or Diameter > being run in clear.) And an upshot from that is that that > helps those who want to pervasively monitor everything. > > > Others argue that that'd be the IETF straying into the > space of policy - all we should do is define how to use > strong security features and make sure the code is there so > they can be turned on and the rest is policy. > > I'm sure there are loads more arguments, and I do think > it'd be useful to see those discussed here.
How about a distinction in compliance? That is, you can say you comply to RFC xyzw if you implement it, but to say you _securely_ comply, you have to switch on the MTUFS (mandatory to use for security) and switch off MTNUFS (mandatory to not use for security) features in the RFC. Some RFCs could only have a secure compliance mode, of course. That way, those who argue that the security is too expensive/not needed for their use case can disable it, but then can't claim that they're secure (regardless of the name of the RFC :-). So, in TLS, for example, secure compliance might consist of TLS 1.2 + AEAD modes only (note: really an example, not an actual proposal). _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
