Re: [ietf-smtp] How to encrypt SMTP?

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 17 October 2019 03:03 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8B12081C for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Oct 2019 20:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oKwQfDd_-oa for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Oct 2019 20:03:31 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1CF12080F for <ietf-smtp@ietf.org>; Wed, 16 Oct 2019 20:03:31 -0700 (PDT)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id D8C1C2BDB7E for <ietf-smtp@ietf.org>; Wed, 16 Oct 2019 23:03:29 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <1420291b5ffe6b65da9bd8e933648b6029dd4c94.camel@aegee.org>
Date: Wed, 16 Oct 2019 23:03:29 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: ietf-smtp@ietf.org
Message-Id: <8B777B0F-6CA9-4683-92BD-2882C62A7D36@dukhovni.org>
References: <1420291b5ffe6b65da9bd8e933648b6029dd4c94.camel@aegee.org>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/vqwrD1c0cqN1rE-cQmXcjTIdWIA>
Subject: Re: [ietf-smtp] How to encrypt SMTP?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 03:03:34 -0000


> On Oct 16, 2019, at 1:43 PM, Дилян Палаузов <dilyan.palauzov@aegee.org> wrote:
> 
> Some questions:
> 
> What happens to MTAs, that are so smart to understand MTA-STS or DANE, but offer only weak ciphers?

MTA-STS specifies at least TLS 1.2:

	https://tools.ietf.org/html/rfc8461#section-7.2

So operators who enable MTA-STS, but only TLS 1.0 are negligent, and will encounter
problems.

DANE (~3 years earlier) specifies at least TLS 1.0 and SHOULD TLS 1.2:

	https://tools.ietf.org/html/rfc7671#section-3

The Postfix TLS implementation does not allow enable ciphers
when TLS is mandatory, and these are rapidly disappearing
entirely from TLS stacks.

> Does somebody offer both EC and RSA certificates on its smtp:25 server and had this ever caused problems?

This generally just works.

> Does somebody offer both EC and RSA certificates with DANE on its smtp:25 server and had this ever caused problems?


Yes, there are such sites.  This just works with MTA-STS and DANE-TA(2)
trust-anchor TLSA RRs, as only the name in the certificate matters, the
algorithm is not so important.  With DANE-EE(3), the TLSA RR becomes
public-key-dependent, and multiple TLSA RRs are needed when fielding
certs for multiple algorithms.  See 

    https://www.mail-archive.com/dane-users@sys4.de/msg00284.html
    https://www.mail-archive.com/dane-users@sys4.de/msg00285.html

But multi-cert MTAs are uncommon, and this is not actually difficult
to get right, single-cert rollover blunders account for almost all
problem cases.

> How much bits shall DH params have to support acceptable amount of mailhosts?

I don't know of any MTAs that will refuse 1024-bit DH, but better to
use 2048 and better still ECDHE with P-256.

>  Do too big DH params break some clients?

Yes, Java.

> What elliptic curves shall be offered, so that the communication works with acceptable amount of hosts?

The "market consensus" is NIST P256, everything else is rare,
but you need to enable negotiation, and also support P384,
just in case.  There is also non-trivial use of X25519 these
days, but systems that use it, can also use P256 as needed.

-- 
	Viktor.