SMTP STARTTLS - "best practices"?

[Per Thorsheim]

Hi,

RFC3207 says publicly available servers are required to support
plaintext and fallback to plaintext if cipher negotations etc fail.

wikileaks.org - self-signed cert, supports SSLv3, TLSv1, TLSv1.1 and
TLSv1.2, AnonDH, key size 2048 bits, weakest cipher essentially zero.

google.com - TTP cert, supports SSLv3, TLSv1, TLSv1.1 and TLSv1.2, key
size 2048 bits, weakest cipher suite with 128 bits.

postfix.org (cloud9.net) - TTP cert, supports SSLv2, SSLv3 and TLSv1,
AnonDH, key size 2048 bits, weakest cipher essentially zero.

verisign.com - TTP cert with invalid hostname, supports SSLv3 and TLSv1,
key size 2048 bits, weakest cipher suite with 128 bits.

porcupine.org - STARTTLS not supported

https://starttls.info/ have checked MX's of Alexa Top 1 million + 
more for starttls support, with stats and comparisons available:
https://starttls.info/stats
https://starttls.info/stats/com/net (.com vs .net)

It seems to me as if mailadmins prefer supporting "everything",
since anything is better than plaintext. On the other side webadmins
and crypto people saying that SSLv3, 128 bit, 2048 bit key and
valid cert should be a minimum.

I would really like to hear honest and justified opinions on what
to consider "good" and "best" practices on this matter.

Regards,
Per Thorsheim

Re: SMTP STARTTLS - "best practices"?

[Per Thorsheim]

Den 23.04.2014 16:35, skrev Viktor Dukhovni:
> On Wed, Apr 23, 2014 at 04:21:14PM +0200, Per Thorsheim wrote:
> It seems to me as if mailadmins prefer supporting "everything",
> since anything is better than plaintext.
> Correct.  This is called "opportunistic TLS".  For an explanation
> of why that's the best possible for SMTP at Internet scale without
> DNSSEC see (version may change from 08 at some point):
>
> 
> http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-08.html#channelsecurity
Very helpful, thank you! Still reading, but I see there's more to it
than I thought.

>> I would really like to hear honest and justified opinions on what
>> to consider "good" and "best" practices on this matter.
> There's an air of superiority in that question, avoid the temptation
> to demand explanations.
Working for "big five" long time ago, learned to never offer "best
practice", as it couldn't be proven, thus risk of getting sued. Use
"good practice" instead, which was "reasonable", but hard to sue
somebody over.

My worries here, as with HTTPS, is users (mailadmins?) putting way too
much trust into it, as soon as they see a mailheader saying SSLv2
ciphers were used. Moving from plaintext to anything better suddenly
requires an active act to mitm, instead of just passive eavesdropping.
Somehow I do prefer "if you are going to use crypto, at least use strong
crypto" as an argument for disabling 40/56bit, SSLv2, AnonDH and using a
TTP cert, although lots of attacks still works, and it still cannot be
"trusted". It just feels "better". Catch-22.

> Better than opportunistic TLS for SMTP requires DNSSEC + DANE.
> Have you implemented DNSSEC for your domain? Published TLSA records?
>
> Planning to go to Patrick Koetter's talk at Linuxtag Berlin on May
> 10th?
>
> http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=3111
>
Didn't know about that one, and no chance of attending this time.

Thank you for an honest reply and the very useful link to your
explanations and recommendations.

Regards,
Per Thorsheim

Re: Disabling Anonymous Diffie Hellman

[Per Thorsheim]

As the initiator of https://starttls.info/ (developed and run by Einar
Otto Stangvik), let me just say that I've e-mailed this list earlier on
this topic.

While Viktor shows very clearly why starttls by itself is insufficient
through his IETF draft, I still personally vote for disabling SSLv2 and
ANON ciphers used with STARTTLS as we do today. My reasoning is simple:
if we continue to support old & insecure ciphers etc, there is less
incentive for moving forward to safer solutions. We did discuss and
change the scoring soon after the service launched, while originally
being based on the scoring system from Ivan Ristic @ Qualys at
ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
creating our own scoring system.

On May 13 Facebook published "The Current State of SMTP STARTTLS Deployment"
https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223

Allow me to quote them:
"The majority of encrypted email is sent with the ECDHE-RSA-RC4-SHA or
DHE-RSA-AES256-SHA cipher suite. This is likely due to those being the
preferred cipher suites of the major providers. DHE-RSA-AES128-SHA,
however, is the preferred cipher suite for the largest percentage of
deployments. AES128-SHA is the next most prevalent, which is concerning
because it does not provide Perfect Forward Secrecy."

Facebook are concerned over the lack of PFS. Right. Well, we started out
by saying we were concerned over SSLv2, ANON suites and expired
certificates.

One of our goals with starttls.info was to aid in the global deployment
of STARTTLS, another goal was to improve the minimum level used by
anyone deploying STARTTLS. That is until Viktors IETF proposal, or
anything similar, reaches broad adoption on the Internet.

Best regards,
Per Thorsheim



Den 20.05.2014 15:35, skrev Colin Fowler:
> Thank you Viktor (and other commenters)
>
> One of the primary reasons I use {ostfix is because of its great
> track record in security (its stability, performance and feature set
> are also great too). It would be foolish of me to disregard the devs
> who have achieved helped give Postfix its recommendation. I'll stick
> with excluding EXPORT and LOW as you mentioned earlier.
>
> BTW, this whole thing came about from me testing using
> https://starttls.info/ which scored what I thought was a well secured
> server quite badly. I see now that the testing site is itself the
> problem, not my original config.
>
> thanks again, Colin
>
>
>
> On 20-05-2014 14:25, Viktor Dukhovni wrote:
>> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>>
>>>> Opportunistic TLS is sometimes counter-intuitive, attempting
>>>> to make it stronger by removing weaker features actually makes
>>>> it weaker.  Don't give in to the urge to tweak TLS settings,
>>>> they are largely fine as they are.
>>>>
>>>
>>> Is it not true though that allowing weak features merely gives
>>> the illusion of security?
>>
>> Opportunistic TLS, is only secure against passive attacks.
>> Against passive attackers, any encryption, even weak is better than
>> no encryption.  This applies even more strongly to authentication
>> or lack thereof.  Authentication adds no protection against
>> passive attacks, once you've negotiated ephemeral keys (ideally
>> with PFS, see http://www.postfix.org/FORWARD_SECRECY_README.html)
>> you're set.
>>
>>> It could be argued that a weak method is technically no better
>>> than no encryption so removing the weak method just removes the
>>> illusion (which some would say was a gain).
>>
>> All kinds of misguided points of view could be argued. :-)
>>
>>>> Most other "hardening" configuration changes are likely to
>>>> reduce, rather than improve SMTP transport security.
>>>
>>> I've heard anecdotes of clients not using the best mutually
>>> supported encryption and instead just using whatever's first in
>>> the list of methods accepted by the server. I don't have anything
>>> to back this up though. Ever heard of this? If this was true,
>>> then disabling weak methods might be beneficial.
>>
>> This is not how TLS works, the client sends a list of
>> cipher-suites, and the server chooses exactly one of these.
>> Depending on server configuration, this is either the client's most
>> preferred cipher also supported by the server or else the server's
>> most preferred cipher supported by the client.
>>
>> Grossly misconfigured clients or servers might choose weak
>> cipher-suites, but I've never seen this happen in practic

Re: Disabling Anonymous Diffie Hellman

[Per Thorsheim]

"Useless" and "Clueless" is rather harsh Viktor, and you most certainly
don't us what we're trying to accomplish.

Fact is we've achieved quite a lot by launching this service, several
ISPs have implemented STARTTLS, same goes for large companies and
government organisations after launch and media coverage of them not
having STARTTLS at all. Several others have added certs from CA's,
renewed expired certs, renewed certs because of Heartbleed (...) and
more. While I cannot prove they did these things because of this useless
and clueless service, sometimes I like to believe for myself that it
just might made a positive difference to some. It will continue to
operate, and I hope we'll be able to expand it to do additional checks
of configurations such as those proposed by you.

Best regards,
Per Thorsheim



Den 20.05.2014 15:56, skrev Viktor Dukhovni:
> On Tue, May 20, 2014 at 02:35:04PM +0100, Colin Fowler wrote:
>
>> BTW, this whole thing came about from me testing using
>> https://starttls.info/ which scored what I thought was a well secured server
>> quite badly. I see now that the testing site is itself the problem, not my
>> original config.
> Yep, the site is clueless.  My DNSSEC + DANE validated domain scores a "D":
>
> mx1.dukhovni.org: Grade: D (43.5%)
>
> Certificate:
>
>   * The certificate is not valid for the server's hostname.
>   * There is a self-signed certificate in the trust chain. It may be a
> configuration problem.
>   * There are one or more fatal problems which causes the
>   certificate not to be trusted.
>
> There are validity issues for the certificate. Certificates
> are seldom verified for SMTP servers, so this doesn't mean that
> STARTTLS won't be used.
>
> [ Actually, I have one of the few SMTP domains whose certificate can be
>   used for MiTM-resistant authentication. ]
>
> Generally speaking it's a bad practice not to have a valid
> certificate, and an even worse practice not to verify them.
> Any attempted encrypted communication is left all but wide open
> to Man-in-the-Middle attacks.
>
> [ Except that not authenticating certificates is exactly what one
>   needs to do with SMTP. ]
>
> Protocol:
>
>   * Supports SSLV3.
>   * Supports TLSV1.
>   * Supports TLSV1.1.
>
> Key exchange:
>
>   * Anonymous Diffie-Hellman is accepted. This is suspectible to
>   Man-in-the-Middle attacks.
>
> [ But DANE clients won't offer this.  And server support of aNULL ciphers
>   is always harmless, and makes it easier to determine which clients are
>   not authenticating the server.  Pretending client offers of aNULL ciphers
>   did not happen does not improve security. ]
>
>
>   * Key size is 1024 bits; that's somewhat insecure.
>
> [ Fine, will be changed when the server is upgraded... ]
>
> Cipher:
>
>   * Weakest accepted cipher: 0.
>   * Strongest accepted cipher: 256.
>
> [ Scoring aNULL as "0" is simply wrong. ]
>
>
> This site is useless.
>

SMTP starttls / DANE TLS

[Per Thorsheim]

https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
"In WG Last Call"

Any estimate on when this might become final Viktor?

After Google named & shamed Comcast for not having starttls, many
well-known services are now establishing RFC 3207 starttls support.
Additionally people are becoming aware of establishing DNSSEC support as
well, which I understand is a prerequisite for the above.

Regards,
Per

Re: SMTP starttls / DANE TLS

[Per Thorsheim]

Den 16.06.2014 17:18, skrev Viktor Dukhovni:
> On Mon, Jun 16, 2014 at 10:12:03AM +0200, Per Thorsheim wrote:
>
>> https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/
>> "In WG Last Call"
>>
>> Any estimate on when this might become final Viktor?
> With any luck, around July IETF.  The WG chairs are trying to
> coordinate progress on both the SMTP and the SRV drafts.  I used
> the pause in the original last call to make various improvements.
>
Sounds good, look forward to see it finalised. Blogged this today:
https://starttls.info/blog/from-zero-to-hero-in-no-time/

ACLU, EFF and many others are now actively promoting starttls
deployment, as you may have seen from the past few weeks with lots of
services announcing support and implementing it quickly. Next step, if
I'm not completly wrong, is to get TLDs to use DNSSEC if they haven't
got it already, then deploy it for your own domains, and then hopefully
your DANE TLS proposal.

I really hope that will catch on and be deployed faster than we've
waited for RFC3207.

Br,
Per

Re: SMTP starttls / DANE TLS

[Per Thorsheim]

Den 17.06.2014 20:59, skrev Viktor Dukhovni:
> Thanks for fighting the good fight.  In the mean-time, any chance
> you could stop fix the misleading TLS support scores starttls.info
> issues to soundly configured MTAs?
>
> * For SMTP, self-signed certificates are as good as CA issued
>   certificates.  The hostname in the certificate is irrelevant.
>
> * For SMTP servers support for anon-DH cipher-suites is a feature,
>   not a bug.
>
> * For opportunistic TLS, even the weakest ciphers are fine,
>   provided strong ones are preferred when offered.
>
> Almost every score-lowering observation leading to 43.5% D for
> dukhovni.org is wrong.
>
I talked to Einar today, my friend who made the service on my request.
We agreed to simplify the scoring, at first down to "passed" as long as
we see starttls support with minimum SSLv3 and no export 40/56bit.

We'll recommend supporting TLSv1.1/2 and using a cert from a TTP, and
probably display the preferred cipher suite from the server, if any.
Will probably not let this affect scoring in any direction, and inform
about your proposal, and recommend DNSSEC deployment in the meantime.

Br,
Per

EFF STARTTLS Everywhere project

[Per Thorsheim]

I don't know if this list is aware of this project?
https://github.com/EFForg/starttls-everywhere

An intermediate effort before DNSSEC and DANE (hopefully) gets seriously
deployed around the world and various TLDs. EFF will talk about this at
PasswordsCon next week in Las Vegas, and I'll make references to this
and DANE TLS in my talk at the DEFCON Crypto & Privacy Village. I'm very
happy to see that these issues are gaining a lot of attention these days.

Viktor: Is the IEEE meeting done yet? Any status update for DANE TLS?

BR,
Per Thorsheim

Re: EFF STARTTLS Everywhere project

[Per Thorsheim]

Den 29.07.2014 16:14, skrev Viktor Dukhovni:
> On Tue, Jul 29, 2014 at 03:57:24PM +0200, Per Thorsheim wrote:
> 
>> I don't know if this list is aware of this project?
>>
>> https://github.com/EFForg/starttls-everywhere
> 
> The EFF folks behind this effort have reached out to me and we've
> discussed some of the issues.  I am somewhat ambivalent about this,
> as it introduces a non-scalable registry that does fully address
> the problem, and perhaps reduces incentives to do it right and
> deploy DANE.  On the other hand, DNSSEC adoption by large providers
> is a non-trivial effort, and they cannot yet deploy DANE as quickly
> as they may be able to sign up for the EFF registry.  So I am not
> sure whether this is a step forward or sideways.

Hm. Yeah, I get your point, and I agree with you. I look forward to talk
to them directly, and will ask them more about the reasoning behind the
project, and how they intend to proceed having it deployed.

>> An intermediate effort before DNSSEC and DANE (hopefully) gets seriously
>> deployed around the world and various TLDs. EFF will talk about this at
>> PasswordsCon next week in Las Vegas, and I'll make references to this
>> and DANE TLS in my talk at the DEFCON Crypto & Privacy Village. I'm very
>> happy to see that these issues are gaining a lot of attention these days.
>>
>> Viktor: Is the IEEE meeting done yet? Any status update for DANE TLS?
> 
> I think you mean IETF (not IEEE).  Yes IETF Toronto is done, and
> the SMTP draft is basically ready and has not been changed in many
> weeks.  The main hold-up is that the WG chairs wanted to publish
> the SMTP and SRV drafts together, but the latter is substantially
> less ready.  Perhaps I should ask the chairs to decouple these.
> 
> The Toronto meeting was looking at the OPS draft which updates DANE
> TLSA in general (not SMTP specific).
> 
> The only issue in the SMTP draft that may require final review by
> the DANE WG is digest agility, I'll post a message to the list 
> this week, now that everyone is back from Toronto, and try to
> wrap it up.

Excellent, thx! I'll make sure to include it in my reference list for my
talks. Look forward to see it finalized.

> In the mean-time Patrick Koetter et. al. are doing great work in
> Germany getting more organizations to deploy DANE.  So far:
> 
>   posteo.de   (email provider)
>   mailbox.org (email provider)
>   bund.de (German Parliament)

This is very good, and can without doubt be communicated to the ACLU and
EFF as well as others, to further improve deployment rates. I'll mention
these as well, and make sure it reaches ACLU & EFF. I'm also working
towards Norwegian government who is evaluating if they should  recommend
all parts of Norwegian government to implement STARTTLS support, as step
1 towards something much better.

Thx Viktor!

BR,
Per

Re: SMTP STS and policy delegation for smtp *client* ?

[Per Thorsheim]

Den 21.03.2016 18.47, skrev Viktor Dukhovni:
> 
>> On Mar 21, 2016, at 12:18 PM, David Schweikert  wrote:
>>
>> I wonder what the Postfix community thinks or plans to do according to
>> this standard that is being written:
>> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/?include_text=1
> 
> My take on the draft is that it is a hack to get the large email providers
> doing SMTP TLS with authentication amongst themselves while they take multiple
> years to ponder DNSSEC, which can be tricky to retrofit onto their complex
> deployments.  The draft still has warts to iron out, I'll help them with 
> those.
> 
> I am not convinced this scales down at all well, but there will likely be 
> demand
> for securing outbound email traffic sent to the large providers.  I am not a 
> big
> fan of code to support the centralized email storage model of the large 
> providers,
> but that battle is lost for now.

Alex Stamos at Facebook has publicly & repeatedly stated that DNSSEC is
"dead". I guess that means no RFC 7672 at Facebook. With him making that
statement I already know others taking the same position. There seems to
be a strong anti-dnssec crowd, complaining primarily on these  issues:

1) Government access / possible interference with dnssec
2) Weak encryption (1024 bit keys)
3) Complexity of configuration & maintenance
4) "only 1 bit to tell you if things are ok or not"
5) DoS capabilities (ppl forget there are other & easier ways)

Google public DNS supports DNSSEC, but afaik no other part of Google
uses it. Although this proposal can live with or without DNSSEC, I am
wondering if Google, Microsoft, Linkedin & other major companies has any
plans to deploy DNSSEC and RFC7672. Or will this proposal be a shorter &
easier step forward, eventually delaying or simply ignoring RFC7672 for
the foreseeable future?

Regards,
Per

Possible SHA-256 SSL cert problems?

[Per Thorsheim]

Mozilla and others have reported on old web clients that doesn't support
the use of new SHA-256 signed SSL certificates on websites. In a recent
thread at Mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=1064387#c6, there's a
reference to Qualys:

"At this time, a site could use two certificates: ECDSA+SHA256 for
modern clients and RSA+SHA1 for older clients."
https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know
A feature supported by Apache at least.

Is this something Postfix can do as well for STARTTLS support?

Eventually any other ideas or experiences with using SHA-256
certificates that have caused problems for STARTTLS, or ex. appliances
that doesn't support it?

I already know that Cisco Ironport and Barracuda appliances only
supports up to and including TLSv1, haven't found any info there for
SHA-256 certificates yet.

BR,
Per Thorsheim

Re: Possible SHA-256 SSL cert problems?

[Per Thorsheim]

Den 02.10.2014 14:38, skrev Wietse Venema:
> Per Thorsheim:
>> Mozilla and others have reported on old web clients that doesn't support
>> the use of new SHA-256 signed SSL certificates on websites. In a recent
>> thread at Mozilla
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1064387#c6, there's a
>> reference to Qualys:
>>
>> "At this time, a site could use two certificates: ECDSA+SHA256 for
>> modern clients and RSA+SHA1 for older clients."
>> https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know
>> A feature supported by Apache at least.
>>
>> Is this something Postfix can do as well for STARTTLS support?
> 
> You mean specify both certificates in the same file?

"If connecting client/server supports SHA-256 signed cert than use that
from our side, else fallback to SHA-1 certificate from our side, with
fallback to plaintext as last resort."

I presume support for TLSv1.1 and TLSv1.2 increases the chances of
SHA-256 certificates being supported as well, but I don't know yet.

I would hate to see use of #starttls dropped because mailservers doesn't
support SHA-256 signed certificates.

BR,
Per

Symantec/Messagelabs starttls - ClientCertificateRequested

[Per Thorsheim]

I've known for many years that Messagelabs, now part of Symantec,
requests a valid client certificate from a narrow list of CAs if you
want to use starttls with their servers, at least *.eu.messaglelabs.com.

This effectively kills off the use of any self-signed, expired and
invalid certificates. Through an intermediate many years ago who talked
to them I learned that they did written peering agreements if you wanted
to use starttls with them. Now the peering agreement seems gone, but the
other requirements are still in place.

Is there anyone out there with a peering agreement, and/or any other
info on the configuration & reasoning behind their selective choices?

I just assume that a whole lot of mail must be sent in plain due to
their very narrow approach?

Regards,
Per Thorsheim

Re: TLS issues with old Exchange Servers

[Per Thorsheim]

Den 05.01.2015 18:59, skrev li...@rhsoft.net:
> 
> Am 05.01.2015 um 18:47 schrieb Viktor Dukhovni:
>> On Mon, Jan 05, 2015 at 06:01:03PM +0100, DTNX Postmaster wrote:
>>
 With RC4-SHA early enough for the 11-year old Microsoft Exchange
 servers.
>>>
>>> Sadly, older Exchange servers (2003 at least) will favour 3DES over RC4
>>> for TLS connections, IIRC.
>>
>> This is not correct.
>>
>>> I don't have the fix we used on hand, as our oldest supported Exchange
>>> version is 2010 these days, but we had an override of some sort that
>>> required forcing 'DES-CBC3-SHA' for that specific box.
>>>
>>> You can specify that as 'DES-CBC3-SHA', or select with something like
>>> this;
>>>
>>> ==
>>> $ openssl ciphers -v 'RSA+3DES'
>>> DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
>>
>> No, this is a bad idea, it is in fact 3DES that is broken with such
>> servers
> 
> shouldn't we start to disable RC4 as well as DES-CBC3-SHA for that
> horrible outdated crap servers and fallback to unencrypted at all
> instead continue to work around them years again?

I wouldn't mind name & shame those who are running outdated crap
servers, with automail to postmaster or something. Progress is made
faster imho that way, instead of trying to be backwards compatible with
*anything*. Do plaintext instead.

.per

SMTP DANE TLS (the death of) DNSSEC

[Per Thorsheim]

Viktor;

Thomas Ptacek doesn't like DNSSEC
http://sockpuppet.org/blog/2015/01/15/against-dnssec/ & followup
http://sockpuppet.org/stuff/dnssec-qa.html, and ImperialViolet has some
opinions as well https://www.imperialviolet.org/2015/01/17/notdane.html

I understand I have lots and lots to read here, but short question is;
how will this eventually impact future deployment of of SMTP security
via opportunistic DANE TLS?

Best regards,
Per Thorsheim

SMTP servers with RSA export suite support

[Per Thorsheim]

According to Twitter.com/einaros, the https://starttls.info/ database
shows 43266 distinct SMTP servers (~12%) supports RSA Export suites, re:
#FREAK attack.

I wonder what percentages would look like for pop/imap servers.

Best regards,
Per Thorsheim

Configuring DANE TLSA - "wizard"

[Per Thorsheim]

Cannot find a simple process guide for configuring DANE TLSA support &
publish relevant DNSSEC signed information. Anyone got a complete guide
from start to finish?

BR,
Per

Re: Configuring DANE TLSA - "wizard"

[Per Thorsheim]

Thx!

Quite a bit of useful info at sys4.de, but in German. Found this english
translation as a rather quick guide for parts of the process:
http://noflex.org/implementing-dnssec-dane-email-step-step/

.per

Den 02.06.2015 10:47, skrev Danny Horne:
> I think this is what I used...a fair bit of scrolling to get to relevant
> information but I hope it helps
> 
> https://ripe68.ripe.net/presentations/253-DANEs_don%27t_lie-20140512.pdf
> 
> 
> On 02/06/2015 9:35 am, Per Thorsheim wrote:
>> Cannot find a simple process guide for configuring DANE TLSA support &
>> publish relevant DNSSEC signed information. Anyone got a complete guide
>> from start to finish?
>>
>> BR,
>> Per
>>
> 

Min/max cipher suite configurations

[Per Thorsheim]

RFC2595 says that TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is REQUIRED when
configuring TLS for IMAP, POP & AMAP.

All other cipher suites are OPTIONAL.

RFC4616 replaced section 6 of RFC2595, with updated info for SASL.

RFC3207 obsoleted RFC247, and covers both TCP/25 and the submission port
(RFC2476). It doesn't specify any REQUIRED cipher suites, like RFC2595
does for IMAP/POP/AMAP.

I'm sure I'm missing out on some info, but basically I'm trying to
figure out the min/max & recommended cipher suite settings for POP/IMAP,
as well as for STARTTLS TCP/25 & TCP/587 without breaking RFCs, "best
practices", or cryptographers ability to sleep well.

BR,
Per Thorsheim

SPF entries for IPv4 & IPv6

[Per Thorsheim]

If using IP addresses in SPF records, is it necessary to specify both
IPv4 & IPv6 addresses? Is there currently a risk of unwanted problems if
only IPv4 (or only IPv6) addresses are specified, when a mailserver is
available using both 4 & 6?

-- 
Best regards,
Per Thorsheim
Twitter: @thorsheim

Re: SPF entries for IPv4 & IPv6

[Per Thorsheim]

Den 02.01.2017 16.41, skrev A. Schulze:
> 
> Am 02.01.2017 um 14:18 schrieb Sebastian Nielsen:
>> OFC you must specify both unless you have completely disabled sending of 
>> outgoing mail via IPv6.
> 
> I think, that's wrong
> 
> One may publish records like "v=spf1 a -all" for a host mail.example.org
> 
> mail.example.org. A   192.0.2.25
> mail.example.org. 2001:db8::6:25
> mail.example.org. TXT "v=spf1 a -all"
> 
> This require two or three dns lookups. (1x TXT, 1x A and 1x  depending on 
> the spf implementation)
> 
> To save lookups and make the authentication more robust it's also possible to
> specify the addresses explicit:
> 
> mail.example.org. A   192.0.2.25
> mail.example.org. 2001:db8::6:25
> mail.example.org. TXT "v=spf1 ip4:192.0.2.25 ip6:2001:db8::6:25 -all"
> 
> this way one minimize the need for a receiver to do "many" lookups. You give 
> the receiver all information
> with the first answer and thus have a higher chance the spf authentication 
> will succeed.

Good points on avoiding many lookups, thank you.

However my other question remains: any knowledge of spammers actively
taking advantage of "incomplete" SPF records, where only IPv4 addresses
are specified but IPv6 is actively in use?

.per

Re: possible to reach hardenize's requirements?

[Per Thorsheim]

Den 12/04/2019 17:09, skrev Scott Kitterman:

On Friday, April 12, 2019 10:46:50 AM micah anderson wrote:

The site https://hardenize.com provides relatively decent Email reports,
along with other reports. It checks a number of things including certs,
MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all
good checks and recommendations, with the exception of the TLS one, I do
not see how its possible to meet their standards, and provide an email
server on the internet. However, I could be wrong, so I'm interested to
know if I am.

If I followed their DMARC recommendation, that would translate into 90% of the
mail I send getting spam foldered or rejected.  At a glance, I'm not convinced
this is any more than "let's make a list of all the things".  For the parts I
looked at, I don't thinks it's all well thought through.

Scott K


I've been a betatester on Hardenize for quite some time, and the service 
is being developed by Ivan Ristic (SSLLabs). I'll leave it to him to 
explain and defend the considerations made, but afaik recommendations 
are based on reading the RFCs and TLS recommendations overall. Yes, some 
attacks are not realistic because smtp != https. For what's its worth, 
the service is very helpful in showing people in shirt & tie how things 
are, and how they preferably should be. Likewise with the tests at 
internet.nl, or MECSA https://mecsa.jrc.ec.europa.eu



.per