Re: [ietf-smtp] Review of draft-moore-email-tls-00.txt
Keith Moore <moore@network-heretics.com> Thu, 31 October 2013 20:00 UTC
Return-Path: <moore@network-heretics.com>
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 0912F11E81D7 for <ietf-smtp@ietfa.amsl.com>; Thu, 31 Oct 2013 13:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7eBN7Kuh5QJ for <ietf-smtp@ietfa.amsl.com>; Thu, 31 Oct 2013 13:00:02 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3511E8155 for <ietf-smtp@ietf.org>; Thu, 31 Oct 2013 13:00:02 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7A68F213EE; Thu, 31 Oct 2013 15:59:58 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 31 Oct 2013 16:00:00 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type; s=smtpout; bh=CPyO 7AtZoJlMOaRTJIETT056dBY=; b=GZjNEO7yR3gbdhEDYMJADqetTlu/8jwAL+My Y+RohWLjDPEg3xAzkJG/lz8JfNx4ckpc4lAUH5/jB1NJFfMMq0A59c8e65aJnRoL GudNR4EZIWBhjdR7RdfZGKWEKuYp2SNMwH3v6HEkv6ryb+0AP+pbqloCGwcD+FuD VqPr5zg=
X-Sasl-enc: 6Ynqa0PeXQiihibQ6FhVstHClIEWvvPKA9O5vlmDJIqh 1383249596
Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 49E5EC00E92; Thu, 31 Oct 2013 15:59:56 -0400 (EDT)
Message-ID: <5272B6BA.1050700@network-heretics.com>
Date: Thu, 31 Oct 2013 15:59:54 -0400
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <CAAFsWK1OROeda-=Ov9pGs=TpeDcxm=d6MDKVxw4Vi6X4LxWLYw@mail.gmail.com> <52680BD1.5020807@network-heretics.com> <527291C3.4080100@isode.com>
In-Reply-To: <527291C3.4080100@isode.com>
Content-Type: multipart/alternative; boundary="------------060906010803010504070801"
Cc: ietf-smtp@ietf.org
Subject: Re: [ietf-smtp] Review of draft-moore-email-tls-00.txt
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 31 Oct 2013 20:00:08 -0000
On 10/31/2013 01:22 PM, Alexey Melnikov wrote: > Hi Keith, > I am glad to see your draft. Some specific comments: > > 2.1. Mail Server Requirements > > The following requirements apply to IMAP, POP, and Submission server > implementations: > > All IMAP, POP, and Submission servers MUST be configurable to support > the use of TLS and the Implicit TLS mechanism when communicating with > MUAs. > > While reading your document I was wondering where the secure submission > is defined. Then I finally found a request for a new port in the IANA > considerations section. > > Several MUAs and multiple MSPs implement secure submission on port 465. > This was never document and is not registered. (I think this was a > Microsoft > invention, but I don't know exact history.) The port is officially > assigned to another protocol. > > There are a couple of problems with that. One is trying to register > unofficially used 465. > Alternatively, we can try to register a new port, but what are the > chances of people > actually migrating to the new default for secure submission? I think it might be tricky to get approval for a standard recommending use of an already-assigned port 465 for mail submission. So I suspect the right thing to do is to still ask IANA for a new port for Submission over TLS, but to document (non-normatively) that some implementations are using port 465 for this purpose. Note that if an MSP advertises its submission servers using SRV records, it can use any port(s) it wishes to use. > > 2.2. Mail User Agent Requirements > > This section describes requirements on Mail User Agents (MUAs) using > IMAP, POP, and/or Submission protocols. > > Note: Requirements pertaining to use of Submission servers are also > applicable to use of SMTP servers (whether on port 25 or on another > port as advertised by a SRV record with _smtp._tcp or _smtps._tcp > label) for mail submission. > > This note seems a bit out of place, as you already mentioned elsewhere > that MTA-to-MTA SMTP is out of scope for this document. Plus you are sort > of trying to register smtps here, but you really don't. The note could certainly use rewording. But the basic idea is that either a) an MSP's SRV records could advertise _smtp._tcp (or _smtps._tcp if such a thing existed), but not _submissions._tcp, in which case the MUA should probably assume that that service is the way to submit mail OR b) an MSP could document (say on its web pages) that MUAs should be configured to submit mail to server xxx.example.com at port 25 and in either of those cases the requirements defined for mail submission by an MUA still apply: e.g. if the configuration says "TLS required", then the MUA MUST use TLS (whether Implicit TLS or STARTTLS) and MUST NOT submit mail without using TLS, it MUST use the certificate verification rules and name matching rules, it MUST NOT blindly trust SRV records unless they're DNSSEC signed and verified, etc. I think the _smtps._tcp is just an oversight. I wasn't intending to propose that we define an smtps service. > > > 2.2.8. Requirements for MUA use of TLS > > MUAs MUST use the procedure defined in [RFC6125] to determine whether > a server's TLS certificate contains an identifier which matches the > DNS name to which the MUA is attempting to connect, and MUST abort > the TLS session if the server's certificate does not present an > identifier that matches one of the MUA's predetermined reference > identifiers for that server. > > It is important to avoid using DNS names obtained from SRV records > (rather than from explicit user configuration) as reference > identifiers when comparing with presented identifiers in TLS server > certificates, unless those SRV records were signed with DNSSEC and > the signatures were verified by the MUA. > > Note in Draft: [I-D.melnikov-email-tls-certs] describes a profile of > [RFC6125] for use in MUA checking of presented identifiers in TLS > server certificates. > > Not surprisingly, I think that you should delete the second quoted > paragraph > (my draft already includes it) and update the first paragraph to > reference > [I-D.melnikov-email-tls-certs]. This would also make > [I-D.melnikov-email-tls-certs] > normative. > > The problem with your first paragraph is that just referencing RFC > 6125 is > not enough to get interoperability, because any use of RFC 6125 > needs to describe use or non use of several parameters, like SRV-ID, > CN-ID, etc. I certainly agree that 6125 is not sufficient. If I recall correctly, I had some questions about melnikov-email-tls-certs that made me somewhat reluctant to reference it as normative for my -00 draft. But I'll reread your draft (hopefully before Monday) and get back to you about it. I took a stab at writing a profile of 6125 myself, and found it difficult to write text that clearly described what needed to happen. There are lots of different error conditions that need to be considered, and it wasn't clear to me what was the right thing to do for every case. > > > 2.2.12. Use of DANE by MUAs > > o TLSA record exists and has a valid DNSSEC signature, and the > public key specified in a TLSA record matches the public key in > the X.509 certificate presented by the server. However, the > server certificate is not signed by a trusted certificate > authority, > > I think this might not be relevant, depending on the TLSA record type > used. The DANE/TLSA text in my draft currently doesn't go into anywhere nearly enough detail, and needs a lot of work. For version -01 I plan to crib from draft-ietf-dane-smtp-with-dane but I want to double check it to make sure it makes sense. Aside: One thing about DANE that I find very dubious is the idea that a DNSSEC-signed TLSA record is a suitable /replacement/ for a certificate signed by a CA. I don't know of any reason to assume that the chain of DNSSEC signatures from the root to the zone that signs the TLSA record is any more trustworthy than the signature of a well-known CA. Yes, we know of cases where the latter have proven untrustworthy - presumably because the CA acted inapporpriately or because its private key was compromised - but I don't know why this is less likely to happen for DNSSEC signatures. I'm all for using TLSA records to provide an additional trust anchor for a server's certificate beyond that provided by the server's CA - so that the attacker will have to compromise multiple parties in order to impersonate the server - but doubt that it's a good idea to say that a signed TLSA record is sufficient by itself. Relying entirely on signed TLSA records actually appears to me to be structurally weaker than relying entirely on well-known CAs. (And I understand that small-scale servers would like to use self-signed certificates, but I haven't yet figured out how to permit that without making users vulnerable.... except by allowing MUAs to "pin" certificates that aren't verifable. And even that seems like shaky ground, but it's probably needed for testing anyway.) > > nor has the MUA been explicitly configured ("pinned") > to accept that particular certificate. In this case the > connection MUST gracefully terminate the session with the server > without attempting to authenticate or request services. > > Isn't this the case for asking the user to pin the certificate? I would like to clearly separate two conditions: - during configuration, it's okay to for an MUA to say "This server's certificate isn't verifable, but if you know for sure that it's valid, you can configure the account to trust it. If you don't know for sure that it's valid, you should contact your mail service provider to verify it." - during normal mail reading, submission, etc., it's NOT okay to offer to let the user pin the certificate. IMO, the MUA should report this to the user as a potential attack and refuse to read/submit mail until the condition is fixed. The user should probably contact his/her mail service provider for further instructions. Now maybe this isn't exactly how things should be implemented. But the point is, if the user interface makes it too easy for the user to just 'click past' warnings without really understanding what's going on or verifying that the condition is reasonable, we haven't gained anything in terms of privacy in exchange for the added complexity - we've only gained the illusion of privacy. > > 3.3. TLS Server Certificate Requirements > > MSPs MUST maintain valid server certificates for all servers. Those > server certificates MUST present DNS-IDs and SRV-IDs conforming to > [RFC6125] and which will be recognized by MUAs meeting the > requirements of this memo. In addition, those server certificates > MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for > compatibility with legacy MUAs. > > Again, I think this should reference [I-D.melnikov-email-tls-certs]. > > > [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", > RFC 4409, April 2006. > > This was obsoleted by RFC 6409, so there is no need to reference both > Normatively. > good catch. thanks. Keith
- [ietf-smtp] Request for discussion of Mandatory S… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… Timo Sirainen
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… Martijn Grooten
- Re: [ietf-smtp] Request for discussion of Mandato… John C Klensin
- Re: [ietf-smtp] Request for discussion of Mandato… SM
- Re: [ietf-smtp] Request for discussion of Mandato… Paul Smith
- Re: [ietf-smtp] Request for discussion of Mandato… Alessandro Vesely
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… Timo Sirainen
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… John Levine
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… MH Michael Hammer (5304)
- Re: [ietf-smtp] Request for discussion of Mandato… Martijn Grooten
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… John C Klensin
- Re: [ietf-smtp] Request for discussion of Mandato… John C Klensin
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] Request for discussion of Mandato… John C Klensin
- Re: [ietf-smtp] DKIM encryption, was Request for … Carl S. Gutekunst
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … John C Klensin
- Re: [ietf-smtp] Request for discussion of Mandato… Brandon Long
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… Arnt Gulbrandsen
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] Request for discussion of Mandato… John Levine
- Re: [ietf-smtp] Request for discussion of Mandato… Timo Sirainen
- Re: [ietf-smtp] DKIM encryption, was Request for … John C Klensin
- Re: [ietf-smtp] DKIM encryption, was Request for … Richard Clayton
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Robert A. Rosenberg
- Re: [ietf-smtp] DKIM encryption, was Request for … Russ Allbery
- Re: [ietf-smtp] DKIM encryption, was Request for … Alessandro Vesely
- Re: [ietf-smtp] Request for discussion of Mandato… Arnt Gulbrandsen
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] DKIM encryption, was Request for … Martijn Grooten
- Re: [ietf-smtp] DKIM encryption, was Request for … Murray S. Kucherawy
- Re: [ietf-smtp] DKIM encryption, was Request for … Rolf E. Sonneveld
- Re: [ietf-smtp] DKIM encryption, was Request for … Steve Atkins
- Re: [ietf-smtp] DKIM encryption, was Request for … Dave Crocker
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Martijn Grooten
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] Request for discussion of Mandato… Wei Chuang
- Re: [ietf-smtp] DKIM encryption, was Request for … Richard Clayton
- Re: [ietf-smtp] Request for discussion of Mandato… SM
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … SM
- Re: [ietf-smtp] DKIM encryption, was Request for … Rolf E. Sonneveld
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Rolf E. Sonneveld
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … John C Klensin
- Re: [ietf-smtp] DKIM encryption, was Request for … Wei Chuang
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Wei Chuang
- Re: [ietf-smtp] DKIM encryption, was Request for … Russ Allbery
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … John R Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … Dave Crocker
- Re: [ietf-smtp] DKIM encryption, was Request for … John Levine
- Re: [ietf-smtp] DKIM encryption, was Request for … Ned Freed
- Re: [ietf-smtp] DKIM encryption, was Request for … Wei Chuang
- Re: [ietf-smtp] DKIM encryption, was Request for … Martijn Grooten
- Re: [ietf-smtp] DKIM encryption, was Request for … Steve Atkins
- Re: [ietf-smtp] DKIM encryption, was Request for … Martijn Grooten
- Re: [ietf-smtp] DKIM encryption, was Request for … James Cloos
- Re: [ietf-smtp] DKIM encryption, was Request for … Wei Chuang
- [ietf-smtp] Two recent Internet-Drafts about usin… Keith Moore
- Re: [ietf-smtp] Two recent Internet-Drafts about … Paul Smith
- Re: [ietf-smtp] Two recent Internet-Drafts about … Stephan Bosch
- Re: [ietf-smtp] Two recent Internet-Drafts about … Rolf E. Sonneveld
- Re: [ietf-smtp] Two recent Internet-Drafts about … Wei Chuang
- Re: [ietf-smtp] Two recent Internet-Drafts about … Keith Moore
- Re: [ietf-smtp] Two recent Internet-Drafts about … Ned Freed
- Re: [ietf-smtp] Two recent Internet-Drafts about … John Levine
- Re: [ietf-smtp] Two recent Internet-Drafts about … John Levine
- Re: [ietf-smtp] Two recent Internet-Drafts about … Wei Chuang
- Re: [ietf-smtp] Two recent Internet-Drafts about … Brandon Long
- Re: [ietf-smtp] Two recent Internet-Drafts about … Wei Chuang
- Re: [ietf-smtp] Two recent Internet-Drafts about … Wei Chuang
- Re: [ietf-smtp] Two recent Internet-Drafts about … Ned Freed
- Re: [ietf-smtp] Two recent Internet-Drafts about … Dave Crocker
- Re: [ietf-smtp] Two recent Internet-Drafts about … Paul Smith
- [ietf-smtp] Review of draft-moore-email-tls-00.txt Alexey Melnikov
- Re: [ietf-smtp] Review of draft-moore-email-tls-0… Keith Moore