>>>>> "TF" == Tony Finch <[email protected]> writes:
TF> James Cloos <[email protected]> wrote: >> A point of discussion is what, if anything, the receiving MTA should do >> dane-wise with and cert offered by the sending MTA. TF> I think this might be interesting to pursue but it could be a deep rat TF> hole. I prefer to get server authentication complete first. Separate draft, then? TF> I believe it would not be feasible to tie the sending host identity to the TF> sending mail domain. That would repeat the error made by SPF. So the only TF> benefit we can get is authenticating the sending host; some other TF> mechanism (i.e. DKIM) is necessary for higher-level identities. +100. I only thought of it as a link in the chain. *If* all of the Received come with confirmed cert comments then *maybe* the path is a bit more trustworthy. Maybe even two bits. :) TF> What benefit would client authentication give you? At the moment we TF> usually assume that bidirectional TCP is good enough for us to believe the TF> client IP address; this is evidently a bit shaky given the lack of routing TF> security, but even if we had secure routing we could still be open to TF> spoofing attacks from sufficiently well-placed on-path attackers. Just a link in a chain, akin to a path through a (weak) web of trust. TF> For intra-domain mail, client authentication is useful for gaining TF> permission to relay arbitrary mail. It's perfectly sensible to use client TF> certificates for this, probably validated using a private CA. If DANE TF> takes off it might be preferable to use the DNS instead. Again, well stated. TF> For inter-domain mail the client IP address is looked up in reputation TF> services and used for tracing and logging. You might care about making TF> this harder to spoof, but it's fairly marginal I think. Indeed. Hense just a bit or so more trustworthy. But in some cases maybe that bit is a back-reinforcing bit? My primary MX shows about 1/8 of my recent mail came from MXs which presented a cert signed by something in my dist's root pool, and about 3/8 were anonymous tls, leaving about 1/2 clear text. FWIW. -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
