Am 30.07.2014 um 01:50 schrieb Viktor Dukhovni: > I'm afraid magical thinking does not make progress in this space. > What's reasonable to do is constrained by what is possible to do, > (additional practical constraints also apply). When you keep > suggesting the impossible, I can only continue to dismiss the > suggestions. > > DANE is quite useful for authenticating the receiving server, even > if it plays no role in authenticating the client. No authentication > system can magically break the asymmetry between the client and > server roles. As I have explained multiple times it is not possible > to prevent MiTM on the server side when all clients are granted > the same authorization (to send mail to the server's domains). > > Only when some clients are more authorized than others does > authentication ensure that MiTMed sessions don't hijack the authorized > privileges of the real client. > > It is not possible to *prevent* MiTM on the server side. The most > you can sometimes do is check that the alleged client identity is not > MiTMed, but that alleged identity may have been modified by the MiTM. > > In other words, you can't stop downgrade attacks on the client > identity. And I mean "can't" in a strong mathematical sense, not > in some practical sense that might change tomorrow. > > Therefore, please cease the repeated suggestions that we do the > impossible. It can't happen, and therefore it won't happen. > > DANE authentication of clients won't stop MiTM. However it can > generate an audit trail of known-good sessions, and can help to > simplify the management of custom access rights, replacing difficult > to coordinate fingerprints with associated verified reference > identities. This could hypothentically also help with reputation > systems, ... > > In no case can this help to thwart active attacks by nation-state > adversaries that want to intercept encrypted traffic. That defense > remains the sole responsibility of the client. No amount of magical > thinking changes this, even if my reasoning seems wrong or unclear.
I have to thank you (and Wietse) for your patience here, it's quite exemplary! So SPF and fingerprinting are the only things I can use to have at least some level of client authentication (authorization security), which still doesn't really help to detect MitM attacks, even if we wish they would do. Well, as an operator I just see the problems I have at present, sorry for the pertinacity here. Not being able to mitigate MitM nor enforcing a certain TLS level downwards to the client is a quite bad thing, especially in a time, where many postmasters still doing nothing to improve their parts of the link, but should. Different security levels in the wild, some are watching their outbound connections, some not, it's really not reliable like this. Regardless how difficult it would be to develop a reliable solution for that, I keep thinking here and throw another idea, inspired by Tor and it's multilayer crypto: Is there a way, once a connection is established to the server, to establish another one downwards within that connection? Like this we could add another layer of trust and MitM sensitivity covering the other direction using the same tools we already have (maybe using SPF to stick to a set of hosts to verify given client certificates against). Is there any possible support for that in the TLS protocol or would it be able to do on the application level (assuming both sides using postfix)? -- BlueStar88 (bluesta...@xenobite.eu)
signature.asc
Description: OpenPGP digital signature
