On 10/07/17 23:32, Russ Housley wrote: > 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. >
Talk to our (tcd.ie) or gmail's mail admin folks. Their expectations count too. (Or are we against enterprise requirements or something? ;-) S. > Russ > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
