Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)
Keith Moore <moore@network-heretics.com> Wed, 25 October 2017 00:31 UTC
Return-Path: <moore@network-heretics.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF19C13A9F5; Tue, 24 Oct 2017 17:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 V39EjuypbaYa; Tue, 24 Oct 2017 17:31:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A081913955B; Tue, 24 Oct 2017 17:31:45 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EC89120FF9; Tue, 24 Oct 2017 20:31:44 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 24 Oct 2017 20:31:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2v8V9F YkyJUq1WvBII8FZ5Cv7mx6NGTWYyjNi1VJwCE=; b=T8bEyI+7nM/SP/kqHoCCPE 2+rB61TjLr3HzZ+6fNTR3AQQsV1DwcmixkJkK7Zdk9weN8OKVaTVOlHIXlW69d7X aRoRlFRRAa1womlY6sq9RcyHw+tgIO3hBUHvgnTtnPUJALXxA4K4pqZmbgIyq88K LYX1NI8mx+sy3y/iTEBtMCShcgtEvOrtVGkXevDttM/046e7ZbYqyHSAbDD2J4GC 4ZMdBXLkAlopsKon5bwWKOqgBUpGd/8IeSPE2D1Mh66YnAXbJBcVp0k/+/qzRgtw YuilnF61eEe3V0SW1tnRn9lwtYOVS4irK9LWrPpG7ZGequs/VBDmdm7qzIQaeDaA ==
X-ME-Sender: <xms:cNvvWWavAxer8UKa0TDEkX8jb8QOXlV82cHm4v6tCbanw8zhFC-fZg>
Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C7BAF7F9CD; Tue, 24 Oct 2017 20:31:43 -0400 (EDT)
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-uta-email-deep@ietf.org, uta-chairs@ietf.org, leifj@sunet.se, uta@ietf.org
References: <150852235551.15416.1247335476327491501.idtracker@ietfa.amsl.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <98fddd93-a0a8-efa3-ce2e-530449ae536c@network-heretics.com>
Date: Tue, 24 Oct 2017 20:31:41 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <150852235551.15416.1247335476327491501.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/phQ2oXI4wp_GSgHA9aiNQBFCY78>
Subject: Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 00:31:48 -0000
(inline) > Line 186 > TLS, and to encourage a greater consistency for how TLS is used, this > specification now recommends use of Implicit TLS for POP, IMAP, SMTP > Submission, and all other protocols used between a Mail User Agent > Do you want to say RECOMMENDED? Lower case "recommends" (non-2119 meaning) was intentional, though my reasoning may be unclear: One of the first things I learned while studying engineering was to not specify the same thing in two different ways, because subtle differences between the two could create ambiguity. (I remember this point clearly because about a year before, someone had constructed a beautiful piece of cabinetry to my specifications, which completely did not fit into the intended space because I had made this very error.) So when writing technical specifications, I believe there should be a clear distinction between summary text (which glosses over details), and the text that actually defines the requirements of the specification. Admittedly this could be called out more explicitly, though it doesn't seem conventional for IETF RFCs to do so. > Line 199 > greeting, the server and client MUST enter AUTHORIZATION state, even > if client credentials were supplied during the TLS handshake. > You mean TLS client certificates here, right? Maybe say so agreed; fixed in -10. > Line 214 > remainder of the TCP connection. If client credentials were provided > during the TLS handshake that the server finds acceptable, the server > MAY issue a PREAUTH greeting in which case both the server and client > Same comment above about client credentials == certs. also fixed in -10. > Line 304 > preference to services supporting STARTTLS (if offered). (See > also Section 4.5.) > I note that 6186 is kind of unclear on what should go in SNI. It obviously > needs to be what you are checking against (which 6186 gets right) but maybe > it's worth clarifying in this document somewhere. Hmm. I might need to come back to that one. Lots of layers to sift through. Feel free to suggest text. > Line 328 > the TLS ciphersuite of the session in which the mail was received, > in the Received field of the outgoing message. (See Section 4.3.) > Do you want to also suggest that it include the name of the DH group, if any? I've attempted to add that attribute but please check the text: The ESMTPS transmission type <xref target="RFC3848"/> provides trace information that can indicate TLS was used when transferring mail. However, TLS usage by itself is not a guarantee of confidentiality or security. The TLS cipher suite provides additional information about the level of security made available for a connection. This defines a new SMTP "tls" Received header additional-registered-clause that is used to record the TLS cipher suite that was negotiated for the connection. The value included in this additional clause SHOULD be the registered cipher suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included in the TLS cipher suite registry. In the event the implementation does not know the name of the cipher suite (a situation that should be remedied promptly), a four-digit hexadecimal cipher suite identifier MAY be used. In addition, the Diffie-Hellman group name associated with the ciphersuite MAY be included (when applicable and known) following the ciphersuite name. The ABNF for the field follows: <figure> <artwork type="abnf"> tls-cipher-clause = CFWS "tls" FWS tls-cipher [ "group" dh-group ] tls-cipher = tls-cipher-name / tls-cipher-hex tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") ; as registered in IANA cipher suite registry tls-cipher-hex = "0x" 4HEXDIG dh-group = ALPHA *(ALPHA / DIGIT / "_") ; as registered in IANA TLS Supported Groups Registry </artwork> </figure> > Line 363 > refuse a ClientHello message from any client sending a protocol > version number corresponding to any version of SSL or TLS 1.0. > Another way is for the server to accept ClientHello messages from > It's worth being very clear that you mean ClientHello.version, not the record > version, as this has created a lot of interop problems. ok > Line 405 > implementation does not know the name of the cipher suite (a > situation that should be remedied promptly), a four-digit hexadecimal > cipher suite identifier MAY be used. The ABNF for the field follows: > Hard to see how you could realistically get into this state... Chris wrote this so this is just a guess on my part: I'm assuming there are TLS APIs out there that let the caller query which ciphersuite is being used, but the implementation returns an integer rather than the name, and provides no convenience routine to look up the name text. > Line 518 > [RFC7525], TLS 1.1 (or earlier) SHOULD NOT be used unless no > higher version is available during TLS protocol negotiation. > This text doesn't quite seem right, as the client has no idea what the server > supports, it just knows what it negotiated. Can you explain how this would be > implemented? No, I can't explain it either. The client can specify that it can handle TLS version 1.2 or greater, and the server is supposed to return the highest TLS version that it supports that is <= the TLS version specified by the client. But the client has no way to force the server to negotiate the highest TLS version that it supports. The only options the client has are things like abort the connection, and perhaps to try again under different circumstances. Or maybe the client could abort the connection if it knows (by some unspecified mechanism) that the server really does support a higher version. So I think that the corresponding text from RFC 7525 doesn't really apply to a client. Since I don't know what else to suggest here, I'll comment out that sentence. > Line 594 > accounts SHOULD be at least use of TLS version 1.1 or greater, and > successful validation of the server's certificate. (Future revisions > to this specification may raise these requirements or impose > This second requirement is more important. Agree, or at least I think I do (are MiTM attacks taking advantage of no or weak cert validation really more of a threat than attacks on TLS < 1.1 protocol or ciphersuites? yeah, I could see that.). But I certainly want implementors to pay more attention to cert validation. I'm not sure what change to the text you had in mind, but I reversed the order to put cert validation first. > Line 672 > the such confidentiality is provided. Additional advice on > certificate pinning is present in [RFC6125]. > Wow, we have a terrible name clash here, because we also have HPKP which > everyone calls "pinning". I see 6125 calls it that, so maybe on first use (S > 5.3) can you please differentiate from HPKP added a note about this. > Line 679 > TLS handshake unless the server requests one and the client has > determined the certificate can be safely used with that specific > server, OR the client has been explicitly configured by the user to > Can you note that this is just a restatement of the rules in TLS? I attempted to fix this as well as the next item, though it's possible I'm still missing something: MUAs MAY implement client certificate authentication on the Implicit TLS port. An MUA MUST NOT provide a client certificate during the TLS handshake unless the server requests one AND at least one of the following is true: the client has determined the certificate can be safely used with that specific server, OR the client has been explicitly configured by the user to use that particular certificate with that server. How to make this determination is presently implementation specific. (The requirement that the server request a certificate is just a restatement of the TLS protocol rules, e.g. <xref target="RFC5246"/> section 7.4.6. The requirement that the client not send a certificate not known to be acceptable to the server is pragmatic in multiple ways: the current TLS protocol provides no way for the client to know which of potentially multiple certificates it should use; also, when the client sends a certificate it is potentially disclosing its identity (or its user's identity) to the server - perhaps unnecessarily and for no useful purpose. > Line 681 > server, OR the client has been explicitly configured by the user to > use that particular certificate with that server. How to make this > determination is presently implementation specific. > The structure of this text is confusing. The rule is: > > if (server asked && > (client determined safe || certificate configured)) { > can use > } else { > can't use > } reworded text in -10 to try to make this clearer. > Line 781 > or interception; this is not intended to mitigate active attackers > who have compromised service provider systems. > IMPORTANT: Client auth with TLS 1.2 reveals the user's identity. This is a > privacy issue, and so we need to note it. The options here are not great with < > 1.3 because renegotiation is also bad, so I'm not suggesting a normative > change, but I think the doc needs to be clear. Added a paragraph: Implementors should be aware that use of client certificates with TLS 1.2 likely reveals the user's identity to the server and therefore may compromise the user's privacy. There seems to be no easy fix other than to avoid presenting client certificates except when specifically configured to do so. > > Line 959 > in RFC 6186 resolves that critique for email. The second bullet is > correct as well, but not very important because useful deployment of > security layers other than TLS in email is small enough to be > The second bullet is less correct than it used to be because we no longer > support export suites. Ordinarily I wouldn't bother to make this point, but if > we're revisiting this point by point, I think we should note that. added a note for this. Keith
- [Uta] Eric Rescorla's Yes on draft-ietf-uta-email… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Alexey Melnikov
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Chris Newman
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Chris Newman
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Eric Rescorla
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Chris Newman
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Keith Moore
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Chris Newman
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Viktor Dukhovni
- Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-e… Alexey Melnikov