Stephen: >>>> >>>>> And to avoid a repeat of Russ' failed justification, many protocols >>>>> use and depend on TLS where the entity controlling the TLS server >>>>> private key materials is not the higher layer sender or receiver, >>>>> so all four points in the definition in 2804 are fully met by your >>>>> wiretapping scheme. >>>> >>>> It is clear that you do not agree with the reasoning that I posted on >>>> Friday. Some people do, and clearly, others do not. >>>> >>>> So, I failed to convince you. However, you have also failed to >>>> convince me that the proposal is wiretapping under the definition in >>>> RFC 2804, Section 3. >>> >>> Consider SMTP/TLS. Where one MTA on the path supports this. >>> Say it's one operated by an anti-spam company for example. >>> That is clearly not the sender nor recipient. >>> >>> That meets all 4 points in 2804, right? >> >> You are pointing to email. Some MTAs will use SMTP over TLS, but many >> others do not. It would be great if they all do, especially for the >> authentication. In your response you are talking about an email system that >> has been using plaintext for ages, and you are trying to apply hop-by-hop a >> mechanism to the delivery. Then, you are saying that the sender and >> receiver have confidentiality expectations that are being violated. I do >> not buy it. > > See [1]. > > Those show nearly 90% of mails being encrypted with > TLS now. > > In many mail deployments there will be an added hop e.g. > for anti-spam (we do that here in tcd) to an outside > party. > > While not 100% of mail is encrypted with TLS on all > hops, much is. (And the UTA WG are developing MTA-STS > to try improve that.) > > If one of those external parties implements your > scheme then mail senders and receivers will not know and > that real TLS application meets the 2804 definition for > lots and lots and lots of emails. > > Hence, 2804 applies here and the standards-track label > ought be removed. > > S. > > [1] https://www.google.com/transparencyreport/saferemail/
I'm glad that TLS is being used to protect email delivery. I do not see how this changes the expectation discussed in RFC 2804, Section 3, Item number 3. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
