Re: [perpass] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt

Jim Fenton <fenton@bluepopcorn.net> Thu, 18 February 2016 03:43 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2D61A923E for <perpass@ietfa.amsl.com>; Wed, 17 Feb 2016 19:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 gGk736dfWVLf for <perpass@ietfa.amsl.com>; Wed, 17 Feb 2016 19:43:02 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E311A8A01 for <perpass@ietf.org>; Wed, 17 Feb 2016 19:43:02 -0800 (PST)
Received: from splunge.local ([4.31.25.74]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id u1I3gxBi004526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Feb 2016 19:43:01 -0800
To: Yakov Shafranovich <yakov@shaftek.biz>
References: <20160213233657.2473.73478.idtracker@ietfa.amsl.com> <56C0DBC0.2070506@bluepopcorn.net> <CAF5Urx-SUviahM5v0mZ7Z4dD1hWrSjGpfS9A4L=2KeoEa2TGCw@mail.gmail.com>
From: Jim Fenton <fenton@bluepopcorn.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <56C53DC3.4050806@bluepopcorn.net>
Date: Wed, 17 Feb 2016 19:42:59 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CAF5Urx-SUviahM5v0mZ7Z4dD1hWrSjGpfS9A4L=2KeoEa2TGCw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1455766982; bh=sPD0MTujYZTURFxNXjjtO7NlTlgU5HBg4/uV3Uh+Mdw=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=lUR4UuSy9Ln4vTMPpXFWfHXonjQ//bRUL6xuQWRYPqfaAZRndcWKenRM1oogWX4N+ H/MF0LMbWyBqmiUAVzR2UXU+Wa1Q6uhtfFXVWwxUmE3D4Wd6J3wq3UKs1DWA+2iUeF 4G5DIOclVTdM08wmuHYXR/z8ndP3lgYWnSHCkxb0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/TODvTW6a3iuh7bADJZIBAGx613s>
Cc: perpass list <perpass@ietf.org>
Subject: Re: [perpass] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 03:43:04 -0000

On 2/17/16 2:13 PM, Yakov Shafranovich wrote:
> Some minor comments:
>
> Section 1:
> "It also requires that the SMTP server advertise
>    that it also supports REQUIRETLS, in effect promising that it will
>    honor the requirement to require STARTTLS and REQUIRETLS for all
>    onward transmissions of messages specifying that requirement."
> "
>
> The part about "promising" does not seem to go together with the
> optional parameter in section 2 about onward transmission.

If you are saying that the statement in Section 1 is incomplete because
it does not say that the server must honor the requirements of the
optional (server authentication) parameter as well, I agree.

>
> Section 3.1 - tagging:
> I am wondering if an email header should be defined to carry this
> data, which would also allow for auditing by the receiver. Sort of
> similar to the SPF/DKIM headers used today.

One could be defined, but that would be a message format extension (RFC
5322) rather than a mail transport extension (RFC 5321). It would then
be necessary to define under what circumstances the new header field
would be moved into the transport realm.  I thought it to be more
straightforward to consider REQUIRETLS to be an aspect of the message
envelope (like the envelope-to and envelope-from addresses) rather than
a header field.
>
> Section 3.4 - delivery:
> It is unclear what "delivery" means here, especially considering that
> SMTP may relay messages to another server, perhaps reference RFC 5598?
> Also, the parts in section 1 and the optional parameter in section 2
> should play together with this, perhaps by requiring TLS in IMAP, etc.
> or not. Either way, this may need clarification.

I have been trying to void "boiling the ocean" by constraining this
feature to SMTP. From the context, it should be clear that by delivery I
was referring to protocols such as IMAP and POP, although webmail
applies here as well. Are you suggesting that this requirement should be
a MUST rather than the SHOULD I proposed?
>
> Section 5:
> What are the actual added codes? I believe 5.7.10 already exists.

5.7.10 does exist, but seems to have the right semantics ("Encryption
needed"). The others will need to be allocated and since they are
numeric codes I didn't presume to define them myself.

>
> Section 6:
> Maybe reference RFC 4949 for terminology?

I'll have a look at 4949.
>
> One other comment - perhaps some sort of limiting digital signatures
> for headers only like DKIM can be employed by the receiving MTA to
> certify that the receipt and transmission was effective? I am thinking
> along the lines of Received headers or DKIM headers, which would allow
> traceability.

This seems to be a separate feature - authenticated return receipts.
This might be useful, but I don't think it belongs here.  I would hope
that MTAs would add information about REQUIRETLS to their Received:
header fields, much as they do about the use of TLS for messages they
receive, but I haven't worked out quite how to specify that yet.
> Yakov

Thanks for your review!

-Jim