On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
> On 2/21/19 7:07 AM, Eric Rescorla wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Benjamin's DISCUSS. > > > > To elaborate on one point a bit: it seems to me that it's harmful to > > security to allow the sender to unilaterally override the recipient's > > preferences that something be encrypted. To forestall one argument, > > yes, the sender knows the contents of the message, but the recipient > > knows their own circumstances, and they may be at particular risk > > > The general approach of REQUIRETLS is that the sender is in a good > position to determine the sensitivity of the message(s) they are > sending, because they know what the message is. Right, this is what I am disputing. Ultimately, for the last > hop anyway, the recipient has the ultimate control: they can refuse to > accept a message unless STARTTLS has been negotiated. Actually, this doesn't work for two reasons: 1. There might be an active attacker. 2. Requiring TLS on the *receiver* side means that you can't talk to clients which don't speak TLS. -Ekr For intermediate > hops, it's a matter of trying to balance the (perhaps) conflicting > wishes of the sender and recipient. And as Viktor has pointed out, this > provides a workaround for misconfigured mail systems. RequireTLS: NO is > not a very robust mechanism in any case, because it's very possible that > a relay MTA will not support REQUIRETLS and will ignore the header > field. But it's an attempt to get explicitly non-sensitive messages > through. > > > > > > > The choices of key lengths and algorithms change over time, so a > > specific requirement is not presented here. > > > > This is not a verifiable conformance requirement. You > > either need to not have a 8174 SHOULD here, or actually specify what > > "meaningfully secure" means. > > > This text was removed in the -07 draft, and now has a reference to RFC > 7525 for TLS negotiation requirements. Let me know if this addresses > this issue. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > email by giving the originator of a message an expectation that it > > will be transmitted in an encrypted form "over the wire". When used, > > REQUIRETLS changes the traditional behavior of email transmission, > > > > This does not seem to accurately describe "RequireTLS: NO" > > > This text was also corrected in the -07 draft. >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
