Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal

Alessandro Vesely <vesely@tana.it> Tue, 08 January 2019 12:08 UTC

Return-Path: <vesely@tana.it>
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 10CE8130E09 for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Jan 2019 04:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 SrO8DsXZiTII for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Jan 2019 04:08:06 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4152813110C for <ietf-smtp@ietf.org>; Tue, 8 Jan 2019 04:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1546949284; bh=ucfEs+4kJ/O5kx0rwjQARXnifcyvOmgXTMnCTiJK/bs=; l=2075; h=To:Cc:References:From:Date:In-Reply-To; b=AHcM4r17nHfEjJp9YjD2baaTETkOKBx3E+urkb4RxqhNs0mKDVrZEmua07kmHxTVg Jkn5TIFEJujYljSUWQyPE9Sn6KQDePHfSXLqNGPKkmB8Jn2InjjzQairIiGp4uTHSg 4t6sCc7NR2OLEgXPDw5vRUHpIa9Rl10nFjHLF0bzbb0Ugghiax9wK4/Pw065f
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 08 Jan 2019 13:08:04 +0100 id 00000000005DC00B.000000005C3492A4.0000106B
To: John C Klensin <john-ietf@jck.com>, Paul Smith <paul@pscs.co.uk>
Cc: ietf-smtp@ietf.org
References: <CAOEezJQL_2_YUDJ3UW6MJ2pDtBzEwKDMV3a5PAvDqwmg5Gd6Xw@mail.gmail.com> <20190107085807.GA9513@ams-1.poolp.org> <CAOEezJSnPcz919k87fS5RFK5dtVSfqn00ow-QtxudDdm9rP9_w@mail.gmail.com> <20190107111354.GA63927@ams-1.poolp.org> <9e5c4dd8-7acf-8da7-4d4e-9337ef6e6101@pscs.co.uk> <EB46BA67346372B460E3DD0A@PSB>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <baba5992-8cf9-a243-1b04-15cf2de342b8@tana.it>
Date: Tue, 08 Jan 2019 13:08:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <EB46BA67346372B460E3DD0A@PSB>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/bR53zZS1VUv8lbr_ARH7EsKYROs>
Subject: Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal
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: Tue, 08 Jan 2019 12:08:08 -0000

I like Viruthagiri's proposal.

On Mon 07/Jan/2019 13:33:39 +0100 John C Klensin wrote:
>>...
>> A simple TXT record saying "This domain's MTAs support
>> STARTTLS (and, possibly, optionally, this is the certificate
>> fingerprint)" would seem useful and not need anything else,
>> and would protect against STARTTLS downgrade for any sender
>> willing to support it.
>> 
>> Obviously it would be vulnerable to DNS pollution, but so
>> would the original proposal.
> 
> Please see at least one of Burt Hubert's "DNS Camel" pieces
> and/or RFC 8324, and think about not only pollution/cache
> poisoning but about the observation that DNS zone managers and
> email administrators are often in separate departments with less
> effective communication than one might like, before going down
> that path.

Well, yes, tweaking host names in MX record would have been a nice hack.  As it
seems such a hack won't work well, however, it's better to save the camel a
useless burden altogether.  Perhaps, the probability of finding an smtps
service on port 26 can be advertised by some other means.

As for port 26, nmap reports[*] a seldom used, unofficial "rsftp" there:

# Fields : Service name, portnum/protocol, open-frequency, optional comments
#
# [...]

telnet	23/tcp	0.221265
telnet	23/udp	0.006211
priv-mail	24/tcp	0.001154	# any private mail system
priv-mail	24/udp	0.000329	# any private mail system
smtp	25/tcp	0.131314	# Simple Mail Transfer
smtp	25/udp	0.001285	# Simple Mail Transfer
rsftp	26/tcp	0.007991	# RSFTP

Would 24 be better?

Rsftp seems to be a buggy ftp-like program.[†]  Google didn't help me to find
much more.  There are some projects on github called rsftp[‡], but none of them
is that one.

Best
Ale

-- 
[*] https://svn.nmap.org/nmap/nmap-services
[†] http://codegrazer.com/blog/rsftp-to-command-injection.html
[‡] https://github.com/tuzhao/rsftp
    https://github.com/cyroxx/rsftp
    https://github.com/Sage-Bionetworks/Rsftp
    https://github.com/rsWinAutomationSupport/rsFTPAdministration (related)