On Jul 10, 2017 4:09 PM, "Eric Mill" <e...@konklone.com> wrote:
On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley <hous...@vigilsec.com> wrote: > > >> 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. > It seems like a weak counterargument to say that because there remain areas where mail servers don't use TLS, that senders and receivers have no expectation of confidentiality with email at all. Are you really saying that if an MTA used this static-DH draft version of TLS to maintain keys to decrypt email traffic, despite it only being "intended" for enterprise use, that it wouldn't be wiretapping? What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit 100% before it's suddenly wiretapping for any given MTA to surreptitiously use the static DH version of TLS that was "intended" only for enterprise use? I don't read RFC 2804 as applying to cases where intermediaries authorized by a party to view information are handing it over. The MTA is authorized by the recipient to be in the path and to look at the emails for all sorts of reasons, and if they decide to hand over all your emails to someone else via FTP, that's not a reason to be against FTP. If it was to apply anything where a proxy service can be behind another proxy would run afoul of this: they would proxy through the evesdropper. So would reply-all, the most blatant cause of accidental evesdropping online. Historically 2804 came out of (I think) a different situation where signaling information related to interception was going to be included in the protocol. Sadly it talks about sender and recipient without considering cases where the identity is confused by subcontracting, and doesn't distinguish cases like this which are similar to key escrow except there is only one entity involved in the escrow. -- Eric [1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06 > Russ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
