Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

Jim Fenton <fenton@bluepopcorn.net> Thu, 28 February 2019 22:49 UTC

Return-Path: <fenton@bluepopcorn.net>
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 5F6A4129A85; Thu, 28 Feb 2019 14:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
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 VCbia1xyXFmw; Thu, 28 Feb 2019 14:49:22 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E9012941A; Thu, 28 Feb 2019 14:49:21 -0800 (PST)
Received: from steel.local ([IPv6:2601:647:4300:2290:214e:1bd0:ac50:a2ec]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x1SMnIhJ027946 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Feb 2019 14:49:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1551394160; bh=P/APT3BCs9WzshpYpoIqfFFgE0ggMxDwK6DS1U8SNps=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XUmelc3m/tMHhMqHME8ywI6mZZadtvd8ULhje3yuoRmzFBqKAq2CPsPVMB/ou/zaP bdePiYc6gkrmhmc+fUK83BgeWmlYeK569pcbTrjYVHCim+riU5rOeD/mY0JU0Mr220 eNOiMc3SCvucJJ8/fXCsSa36/x43zJHWvB9ArgTM=
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: uta@ietf.org, uta-chairs@ietf.org, valery@smyslov.net, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
References: <155072491254.20210.15187912705241578950.idtracker@ietfa.amsl.com> <7061cefb-0f2d-5257-e10c-95be14a7413f@bluepopcorn.net> <20190227201137.GS53396@kduck.mit.edu>
From: Jim Fenton <fenton@bluepopcorn.net>
Openpgp: preference=signencrypt
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ
Message-ID: <f939d44f-1262-ca40-4501-755ed05e4674@bluepopcorn.net>
Date: Thu, 28 Feb 2019 14:49:13 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <20190227201137.GS53396@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/g_v1VPW8Gv0HJTB1RaBdCuO16D0>
Subject: Re: [Uta] Benjamin Kaduk's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 28 Feb 2019 22:49:27 -0000

On 2/27/19 12:11 PM, Benjamin Kaduk wrote:
> On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
>> On 2/21/19 8:55 PM, Benjamin Kaduk wrote:
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I'm pretty sad to see that the "RequireTLS: no" header field has the
>>> name "require TLS" and the opposite semantics.  It seems like the
>>> positvie signal that we are trying to indicate is "Ignore TLS" or "TLS
>>> optional" or similar; why does the header field need to be named
>>> "Require TLS" -- isn't that confusing to users?
>> "Ignore TLS" would have the wrong semantics; even with RequireTLS: NO we
>> want it to negotiate TLS if it can; it's just that the sender is asking
>> that TLS transport not be required by recipient policy for this
>> particular message. "TLS optional" is closer (and is used in the heading
>> of Section 4.2.2), but doesn't quite capture the intended meaning, which
>> is "don't require TLS".
> I think even swapping the order to "TLS Required: no" would be an
> improvement, since it's a declarative statement rather than an imperative.


Works for me. That might also clear up some potential confusion where
the spec refers to the REQUIRETLS SMTP extension and the RequireTLS
header field. It will need to be "TLS-Required: no" so there isn't a
space in the header field name.

>
>>> While I understand that there can be cases where it is desired to ignore
>>> recipient-domain indications to use TLS, such as to report problems with
>>> the TLS capabilities of those domains, I have strong qualms about
>>> describing this protocol as an "override" for DANE and MTA-STS, or that
>>> such recipient-domain signals should be "ignored".  In effect, by
>>> attempting to do so, this document is fundamentally modifying the
>>> protocol semantics for (SMTP) DANE and MTA-STS, something that can only
>>> properly be done by clearly calling out the behavior change and an
>>> Updates: relationship with the documents whose semantics are being
>>> modified.  Alternately, it could also be reasonable to remove claims of
>>> "override" or "ignore" and to leave the semantics of the header field as
>>> being that the sender requests one behavior, and the MTA can balance the
>>> requests of the sender and recipient at their own discretion. This is
>>> still not a great option, though, as it would seem to put multiple IETF
>>> proposed standards at odds with each other.
>> I don't like the "own discretion" option either; I feel like some
>> desired behavior should be specified, even if it's as a SHOULD. Since
>> RequireTLS: NO affects the handling of a single message, it should take
>> precedence over a general policy published by a domain for all messages.
> I seem to be missing some logical steps here.  Why does that conclusion
> follow from that input?


Maybe not exactly in this context, but it's common for finer-grained
directives to take precedence over coarser ones (in routing protocols,
for example). So it seemed at least intuitive if not exactly logical.


>
>> As to whether REQUIRETLS updates those specifications, I understand from
>> Alexey that there is some precedent for not calling out an "Updates"
>> relationship for mail extensions such as this, and he has far more
>> experience than I on such things.
> I think the plan is for the IESG to chat about this topic in real-time next
> week (I was unable to make last week's call, unfortunately).


Yes, I understand the discussion was pushed out.

>
>>> I'm also concerned about the apparent new burden placed on senders to
>>> actively decide whether every outgoing message requires end-to-end TLS
>>> protection or is safe to forward without TLS, especially in light of the
>>> apparent goal (see next paragraph) of quickly achieving (near-)universal
>>> deployment.  There doesn't seem to be much in this document to justify
>>> the stance that the default "don't care" option should be removed.
>> I'm unsure whether or not near-universal deployment will ever be
>> achieved. There are important use cases (reporters in remote
>> jurisdictions sending email to their editors, dissidents communicating
>> among themselves, workers at some sensitive NGOs communicating with
>> their organizations) where limited deployment among these populations
>> would be beneficial to protect their email against MITM attacks by
>> middle-boxes would be beneficial.
>>
>>> The "must chain forward to final delivery" property for the REQUIRETLS
>>> option seems to present some incremental deployment difficulties, in that
>>> it will be nigh-impossible to successfully deliver such a message until
>>> there is fairly significant deployment coverage.  E.g., if any major email
>>> hosting provider does not implement, then it will forever remain a niche
>>> technology.  What indication to we have that this technology can succeed as
>>> specified?  If we anticipate it becoming a part of the de facto core,
>>> mandatory, SMTP feature set, should we not indicate that by an Updates:
>>> relationship?
>> See above; I'm not sure whether it will remain a niche technology or
>> not. I'm also not sure why the deployment coverage has to do with
>> whether there should be an Updates: relationship.
> It's not directly related to the deployment coverage, but rather to the
> sense of "is this something that we consider to be logically part of the
> core minimum implementable unit?".  If the deployment of this is big enough
> that a substantial chunk of normal Internet-wide mail traffic sets the
> REQUIRETLS tag, then de facto you must implement it if you want to keep
> getting mail.  That's the case that I'm worried about, though the
> subsequent discussion has made me less certain that that will be the end
> state of deployment that we reach.


Thanks for explaining. I expect it to remain an optional feature.

>
>>> I'm also unsure exactly how tightly nailed down the (non-DANE) TLS
>>> certificate validation process is supposed to be as a result of this
>>> document; more in the COMMENT section.  It seems that without some form
>>> of strict certificate (host)name validation, this mechanism does not
>>> actually mitigate the lack of server authentication by the client that's
>>> described as a goal.
>> In what respect is the certificate name validation not strict? DNSSEC or
>> MTA-STS is required to make sure that the MX hostname can't be altered
>> in a DNS response, and that should be the name on the certificate.
> DANE and/or MTA-STS give me an MX hostname.  Do I require that exact
> hostname to be present in the X.509 certificate presented by the TLS
> server?  I didn't see any text in the document that clearly says the answer
> is "yes".


I see that Viktor has explained this better than I would have. (Thanks,
Viktor).

>
>>> I'd also like to discuss whether it's safe to require that the tag and
>>> header be mutually exclusive.  (As per the COMMENT section,) I don't have
>>> a great picture on what scenarios could cause that to arise, how common
>>> they are, and what the impact would be for strict enforcement.
>> Section 4.1 describes the behavior if the MAIL FROM option and header
>> field are both present: the MAIL FROM option wins.
> I'm not saying it's under-specified; I'm asking if there's a reason we need
> to allow the combination at all.  Are there existing deployments that allow
> it that we need to be compatible with?  Does it provide some benefit in
> some use case?  If there's no reason to have it, it just seems like
> needless complexity and risk of misimplementation.


No existing deployments exist that we need to be compatible with in this
respect. Since the two mechanisms have opposite effect, the combination
should never happen.

>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> Section 2
>>>
>>>    o  The certificate presented by the SMTP server MUST either verify
>>>       successfully in a trust chain leading to a certificate trusted by
>>>       the SMTP client or it MUST verify successfully using DANE as
>>>       specified in RFC 7672 [RFC7672].  For trust chains, the choice of
>>>       trusted (root) certificates is at the discretion of the SMTP
>>>       client.
>>>
>>> I don't see how this requirement restricts the presented end-entity
>>> certificate so as to eliminate the attacks that exploit "the lack of server
>>> authentication by the client".  What does certificate have to name in order
>>> to be trusted by the client?
>> The certificate has to name the hostname returned by the MX record
>> lookup that the client MTA thinks it is communicating with (or recipient
>> domain name in the case of finding the MTA via an A record lookup). Does
>> this requirement need to be more explicit? I thought it was obvious.
> "verify successfully" is pretty vague.  Do I just verify the signatures
> along the chain?  Do I need to check those fiddly keyUsage bits?  Do I care
> what the CN/SAN is?  We cite RFC 6125 in Section 4.2.1, but it's probably
> prudent to reference it here as well.


See Viktor's response.

>
>>> Section 4.1
>>>
>>>    Upon receipt of the REQUIRETLS option on a MAIL FROM command during
>>>    the receipt of a message for which the return-path is not empty
>>>    (indicating a bounce message), an SMTP server MUST tag that message
>>>    as needing REQUIRETLS handling.
>>>
>>> What processing should happen when REQUIRETLS is received and the
>>> return-path *is* empty?
>> Ben Campbell caught this as well; the exemption for bounce messages in
>> this section needs to be removed.
>>>            If the REQUIRETLS MAIL FROM parameter is specified, the
>>>    RequireTLS header field MUST be ignored but MAY be included in onward
>>>    relay of the message.
>>>
>>> How could this scenario arise?  (Why is it not a user error to attempt to
>>> use both -- isn't one requiring TLS and the other disclaiming its use,
>>> making them mutually incompatible?)
>> It shouldn't normally happen, but I thought it worthwhile to define the
>> behavior of the protocol in this case anyway.
> I agree that it's worthwhile.  Could it be a hard error instead of this?
> (Per https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/)


It could, but two mechanisms occur at different stages (envelope and
message data). The error would not be reported until the end of the DATA
stage of message transmission, although I suppose that's OK. We should
probably allocate another error subcode if we're going to do that.

>
>>> Section 4.2.1
>>>
>>>    2.  If the server lookup is accomplished via the recipient domain's
>>>        MX record (the usual case) and is not accompanied by a valid
>>>        DNSSEC signature, the client MUST also validate the SMTP server
>>>        name using MTA-STS as described in RFC 8461 [RFC8461]
>>>        Section 4.1.
>>>
>>> What happens if this validation fails?  Perhaps the below text "If any of
>>> the above fails" could include "(including MTA-STS validation)" for extra
>>> clarity.
>> In this case, transmission of a REQUIRETLS-tagged message fails.
>>>    3.  Open an SMTP session with the peer SMTP server using the EHLO
>>>        verb.
>>>
>>>    4.  Establish a TLS-protected SMTP session with its peer SMTP server
>>>        and authenticate the server's certificate as specified in
>>>        [RFC6125] or [RFC7672] as applicable.
>>>
>>> "STARTTLS" does not appear in here anywhere.
>>> Separately, is this combination of steps going to preclude any setups that
>>> (e.g., via preconfiguration) go straight to TLS with no STARTTLS
>>> negotiation?
>> Either STARTTLS or implicit TLS (i.e., on a different port) would
>> satisfy this requirement. It's because of the "straight to TLS" case
>> that STARTTLS isn't mentioned here. This is REQUIRETLS, not
>> REQUIRESTARTTLS.
> I'm complaining more about the transition from (3) to (4) than either one
> per se.  If I open a connection and then establish a (new?) TLS-protected
> session, that seems to mostly be STARTTLS.  But if I use implicit TLS, why
> do I need to bother with (3) at all?


There's one circumstance where implicit TLS might happen, and that's
message submission. It's probably step 4 that's the problem there, since
the TLS session is negotiated earlier in that case.

>
>>> What name is used as input to certificate validation (for the 6125 branch)?
>>> Is Appendix B.4 therein supposed to be normative?  (The Appendix B header
>>> indicates that the content is non-normative.)
>> 6125 Appendix B.4 just quotes RFC 4954. Perhaps I need to be normatively
>> referencing the latter instead? In any case, the intent is that the MX
>> hostname match one of the names on the certificate.
> Given that 4954 just talks about the client's "understanding of the server
> hostname", I'd suggest that this document explictly state that the MX
> hostname must match, independently of the question of citing 4954 and/or
> 6125 here.  (Hmm, and Section 14 of 4954, that talks about "server
> hostname", is predicated on supporting SASL [PLAIN] over TLS anyway, which
> isn't particularly general.)  So I'd be onboard with citing 4954 here
> (possibly in addition to 6125?) but there likely still needs to be some
> additional text discussion for clarity.


See Viktor's response.

>
>>> Section 4.2.2
>>>
>>>    Some SMTP servers may be configured to require STARTTLS connections
>>>    as a matter of policy and not accept messages in the absence of
>>>    STARTTLS.  A non-delivery notification MUST be returned to the sender
>>>    if message relay fails due to an inability to negotiate STARTTLS when
>>>    required by the server.
>>>
>>> This is an "inability to negotiate" combined with a rejection of
>>> non-STARTTLS, right?
>> This is just a situation where the server requires that TLS be
>> negotiated, and the client isn't able to do that so delivery fails and a
>> bounce is generated. This behavior isn't specific to REQUIRETLS at all.
> I think we're in violent agreement here.
>
>>> Section 5
>>>
>>>    The path from the origination of an error bounce message back to the
>>>    MAIL FROM address may not share the same REQUIRETLS support as the
>>>    forward path.  Therefore, users requiring TLS are advised to make
>>>    sure that they are capable of receiving mail using REQUIRETLS as
>>>
>>> nit: "requiring TLS for outgoing mail"?
>> Sure, but if you're requiring TLS through this mechanism it's
>> necessarily for outgoing mail.
>>>    If a REQUIRETLS message is bounced, the server MUST behave as if
>>>    RET=HDRS was present as described in [RFC3461].  If both RET=FULL and
>>>    REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
>>>    transformed to RET=HDRS on relay.  The SMTP client for a REQUIRETLS
>>>
>>> If the MAY is not taken, will the next hop be obligated to detect that this
>>> is a bounce and apply the preceding MUSTs?  If not, perhaps this also
>>> should be a MUST?
>> It seems like it should, yes.
> [this is covered downthread, it looks like]
>
>>>    bounce message uses an empty MAIL FROM return-path as required by
>>>    [RFC5321].  When the MAIL FROM return-path is empty, the REQUIRETLS
>>>    parameter SHOULD NOT cause a bounce message to be discarded even if
>>>    the next-hop relay does not advertise REQUIRETLS.
>>>
>>> Perhaps an internal cross-reference up to Section 4.2.1 is in order?
>> This section says, "ignore REQUIRETLS for bounce messages" so it
>> shouldn't be doing section 4.2.1. Or perhaps I misunderstand the comment.
> I was just noting that 4.2.1 had the complementary text that exempted
> bounce messages from certain REQUIRETLS processing; this comment may be
> overtaken by events given some of the other ballot threads, though.


Yes, that's being addressed in response to other comments.

>
>>>    Senders of messages requiring TLS are advised to consider the
>>>    possibility that bounce messages will be lost as a result of
>>>    REQUIRETLS return path failure, and that some information could be
>>>    leaked if a bounce message is not able to be transmitted with
>>>    REQUIRETLS.
>>>
>>> It's not really clear how actionable this is.  If you have a message
>>> that you want to send, you're either going to send it or not send it.
>>> What would you change about the message based on whether or not you
>>> could get a bounce, or whether or not the bounce would leak the message
>>> contents?
>> This is simply, "remember that you might not get a bounce". That's
>> probably true anyway.
>>> Section 6
>>>
>>>    Mailing lists, upon receipt of a message, originate new messages to
>>>    list addresses.  This is distinct from an aliasing operation that
>>>    redirects the original message, in some cases to multiple recipients.
>>>
>>> I'm not entirely sure how universally acknowledged this claim is; at
>>> MIT, we have lots of "mailing lists" implemented via the central Moira
>>> management database, but the actual implementation on the mailhubs is
>>> more like the aliasing operation described in the second sentence.
>>> Is there a need to make this distinction in order to support the
>>> following points, or could they stand on their own without this?
>> There are lots of cases where a new message is originated as the result
>> of a received message, mailing lists (as distinct from distribution
>> aliases) being a very common one. But there are also various other
>> things that originate new messages, like the vacation program, sieve,
>> etc. Perhaps this section should be generalized, but right now it's
>> setting context for how REQUIRETLS could be supported by mailing lists,
>> at the list operator's discretion.
> To be clear, I'm not asking for any change here (and this is the
> non-blocking COMMENT section anyway).  I'm just noting my experience when
> it seems slightly at odds with the text in the document.


We will consider generalizing the text to cover other message
origination cases besides mailing list relay.

>
>>>    The requirement to preserve the REQUIRETLS tag therefore does not
>>>    necessarily extend to mailing lists, although the inclusion of the
>>>    RequireTLS header field MAY cause messages sent to mailing lists to
>>>    inherit this characteristic.  [...]
>>>
>>> Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS
>>> header field have very different characteristics?  I don't understand
>>> which one "this characteristic" is supposed to refer to.
>> Since header fields are typically copied into the messages sent by
>> mailing lists, this would happen in the case of the RequireTLS header
>> field as well.
> Maybe s/this characteristic/the header field/, then?


That's clearer.

>
>>>    Mailing list operators MAY apply REQUIRETLS requirements in incoming
>>>    messages to the resulting messages they originate.  If this is done,
>>>    they SHOULD also apply these requirements to administrative traffic,
>>>    such as messages to moderators requesting approval of messages.
>>>
>>> Maybe note that such administrative traffic can include message contents
>>> intended for the list?
>> I'm not sure what you mean here. The main concern is the compromise of
>> metadata, i.e., that a particular user has subscribed to a list. I
>> realize this isn't perfect, and that there are other ways (such as
>> timing and size of messages) by which this could be inferred.
> I think that the compromise of non-meta data is also a concern, probably a
> contender for "main" concern.
>
> Consider when I send a message, with REQUIRETLS tag and sensitive contents,
> to a moderated mailing list.  Mailman (among others?) will then accordingly
> notify the moderator that a message requires action, and at least in some
> configurations will *include the entire message contents* that need
> moderation.  So I'm saying that mailman should propagate the REQUIRETLS tag
> when it's sending that "action required" message, since otherwise the
> message contents that I, the sender, thought were protected by REQUIRETLS,
> would lose that protection.
>
>>> Section 8.2
>>>
>>>    clear, where they can be intercepted.  REQUIRETLS detects the failure
>>>    of STARTTLS and declines to send the message rather than send it
>>>    insecurely.
>>>
>>> nit: I'd say that REQUIRETLS requires the detection and declining,
>>> rather than doing so itself.
>> Sure.
>>>                                                      REQUIRETLS requires
>>>    successful certificate validation before sending the message.
>>>
>>> (As mentioned above, we need greater clarity about what the validation
>>> specifically entails.)
>> Addressed above.
>>>                  REQUIRETLS requires that the recipient domain's MX
>>>    record lookup be validated either using DNSSEC or via a published
>>>    MTA-STS policy that specifies the acceptable SMTP server hostname(s)
>>>    for the recipient domain.
>>>
>>> Are we then required to use those server hostname(s) in the certificate
>>> validation portion of the TLS connection?
>> Yes.
>>> Section A.1
>>>
>>> In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please
>>> consider using IPv6 examples.
>> OK, although this protocol does not reference IP addresses of any sort,
>> so the improvement would be only decorative.
> Indeed.
>
> -Benjamin
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta