Hi! On Sun, 10 Apr 2016 18:28:14 +0200, ilf wrote: > Is there a convincing reason *not* to support the others? (SHA-224, > SHA-384, SHA-512/224, SHA-512/256) The neccessary code seems minimal > and trivial, so I propose to implement support for all six SHA-2 hash > functions. First, you need a convincing reason to add a feature; the lack of a convincing reason *not* to add it is not sufficient. Second, yes there is a reason not to add them: they provide no additional value and only add confusion. Why should msmtp/mpop support methods for fingerprinting that nobody else uses? > Going further: SHA-3 has been standardized half a year ago. Any > reason for not implementing it? There's free reference code: > https://github.com/gvanas/KeccakCodePackage/blob/master/Standalone/CompactFIPS202/Keccak-readable-and-compact.c > (But I admit, even GnuTLS seems to still be finalizing their code > support.) For SHA-3, the same as above applies, but additionally msmtp/mpop should always use the appropriate GnuTLS (or OpenSSL) function to get a fingerprint and should never implement fingerprint calculation themselves. That can only lead to trouble. > > That keeps MD5 supported although it is discouraged. I expect that > > when certificates are renewed or replaced and thus fingerprints in > > the mpop/msmtp configuration need updating, users will most likely > > use --serverinfo to get the new fingerprint and thus update to > > SHA256 automatically. I see no need to break their configurations > > now. > > That's a good way for now. But since MD5 is seriously broken and > SHA-1 should be avoided, I think they should both be sunsettet. How > about adding a note to the NEWS, that MD5 will be *disabled* in - say > - half a year, and SHA1 will be disabled in one year? > > That may sound drastic, but it's what all the big browsers are doing: > https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html This is a different topic: browsers will soon stop accepting certifcates with SHA1 *signatures* (e.g. in Firefox, see View certficate -> Details -> Certificate Fields -> Certificate Signature Algorithm). This is not the same as a certificate fingerprint. Still of course, SHA1 should be replaced everywhere, including fingerprints. I just think in this case it can be done by letting users do it instead of us breaking their configuration. > On a related note: Is the "tls" option enabled or disabled per > default? The man page only sais: > > > Enable or disable TLS (also known as SSL) for secured connections. > > If it's off by default, I propose changing that to on. It is indeed off by default, and that is unfortunate. See below [*]. > Going even further, I also propose to change the default of > "tls_starttls" to "off". Taking from the SMTP Strict Transport > Security draft: > > > The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and > > hosts to establish secure SMTP sessions over TLS. In its current > > form, however, it fails to provide (a) message confidentiality -- > > because opportunistic STARTTLS is subject to downgrade attacks […] > > https://tools.ietf.org/html/draft-margolis-smtp-sts-00 That text is a different topic and different context that does not apply here. It handles MTA-to-MTA sessions. There you can downgrade when you can modify the start of an SMTP session and prevent the server end from advertising its STARTTLS capability, thereby causing the client end to fall back to unencrypted SMTP. But msmtp/mpop do not do this: they will never fall back to unencrypted SMTP/POP. > Proper TLS beats StartTLS hands-down. I don't think that is true in general. Do you have any information that supports this claim? [*] Today a few msmtp/mpop defaults do not make sense anymore. Msmtp should now default to the mail submission port 587, with TLS enabled (note that this *requires* STARTTLS). That would require changing the defaults for 'port' and 'tls'. For mpop, only the second applies. The problem is that 'tls on' as a default does not simply work, because you need at least 'tls_trust_file', and that is unfortunately different everywhere. Regards, Martin
Attachment:
pgpUB9D0zb1pC.pgp
Description: OpenPGP digital signature