> > And because mail server name and email address does not need to be any > > connection also checking of signature of certificate agaist CA does not > > help much. It does not protect attack agaist MX records on DNS. > > true - so in an ideal world, we would need DNSSec everywhere and strict > certificate checking to significantly reduce the possibility of MiTM > attacks. In a not so ideal world, every little bit helps, so if we can > get mail servers to routinely use encryption between each other, that's > a nice first step and using valid certificates that can actually be > verified is a second one. Both will help significantly already. Kari is correct in that server to server SMTP is not protected *at all* with STARTTLS unless server administrators manually configure them to say "anything at example.com must support STARTTLS". That is, unless DNSSEC is used for that domain. For client to server SMTP, some smart MUAs will detect STARTTLS the first time they connect to the server and then from that point on require it and will store the host's name for certificate validate (i.e. not rely on MX), so in this case there are already work arounds. Many MUAs are pretty terrible though, and don't do this. For instance, if you configure Outlook in "auto" mode, it will be vulnerable to MitM every time. I would argue that if server admins and MUAs don't do all of these things, however, there is no "significant" improvement in communications security. It's either possible to read some one else's mail on the wire, or it's not. (We often like to think that security is a continuum of being more or less secure based on level of effort, but in many cases that's simply not true. You're either vulnerable to an issue or you're not.) It's unfortunate that STARTTLS is currently a disaster to configure securely, particularly because it is just a point-to-point encryption mechanism and all of this complexity has to be addressed at every hop. I think as a security community we'd be a lot better off putting our efforts into encouraging end-to-end encryption with S/MIME or PGP/MIME. tim
