Hi, > When applicable, all guidelines documented in the BCP are true for > both "authenticated through TLS" and "opportunistic use of TLS " > approaches. (The introduction of the lengthy "Applicability > Statement" doesn't help to clarify that and might confuse the > readers.) Therefore, let's keep a very short "applicability > paragraph" capturing this fact in the Introduction and leave all > further "TLS with OE/OS" discussion outside of this document.
The problem is caused by two facts coming together. 1) The first is that this WG seems (AFAICT) always assumed an active attacker, and in that case all OE/OS is moot. In fact, the BCP lacks a threat model. BTW [0]. Correct me if I am wrong, but go ahead and state the threat model you had in mind to see if we were indeed always in agreement on this. 2) The second is that most of the application-layer protocols that we thought of in UTA (so far) assumed an authenticated server in a UA-to-server scenario. Thus, it makes sense to discuss + address authentication, both as a security goal as well as when referencing RFC 5280 for checking host names. Etc. So authentication became an implicit assumption in the introduction and applicability statement. I added the wording in question to the text, but notified Yaron and Peter at the same time that I was unsure about it as it would make it difficult to keep OE/OS in scope. Quite expectedly, people agree. Now we need to find a way to express: * In general, authentication is desired: HTTP, SMTP, and IMAP in UA-to-server. Also BTW [1]. * In some settings, e.g. MTA-to-MTA or XMPP server-to-server, OE/OS is common. Authentication is not required there, and unlikely to come (say some). In general, I tend to go with what Yaron proposed: keep OE/OS in scope. Deal with it in two ways: * By making it clear where authentication is commonly desired, and where it sometimes is not: i.e. examples. * Make the consequences clear to the reader: where authentication is omitted, the other security guarantees only hold against passive attackers. Personally, I would even encourage using authentication in this BCP, despite knowing of the above use cases - this is a document for the 95%, after all. And a client can always choose to ignore a cert sent to him. Would that be a way to go? It would require some reshuffling of the text, but I think that can be done. Ralph [0] And actually, without that one, the recommendations do not make much sense. [1] I know the wording is difficult. I don't even want to enter the realm of MUA and MTA! If we are to assume someone does know what AES stands for, are we sure we want to throw MUA at them? Believe me, none of my graduates today still know that term. They encounter it in class once, and that's it. BTW [2]. [2] Please let's not even talk DANE-TLSA or whatever the record of the day is called. -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18010 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
