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

[Jim Fenton <[e-mail]>]

On 7/30/19 5:02 PM, Benjamin Kaduk wrote:
> On Tue, Jul 30, 2019 at 04:11:36PM -0700, Jim Fenton wrote:
>> On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote:
>>
>>> The following paragraph (unchanged from my ballot on -07) received only minimal
>>> discussion so far:
>>> I'm also concerned about the apparent new burden placed on senders in
>>> Section 4.3 to actively decide whether every outgoing message requires
>>> end-to-end TLS protection or is safe to forward without TLS ("when TLS
>>> is to be required, [...].  When TLS is not to be required, [...]"), where both
>>> "[...]" require new behavior not present in a client that does not implement
>>> this specification.  To some extent this is an editorial matter of how the
>>> new mechanisms are portrayed, but I don't see much in this document to justify
>>> the stance that the default "don't care" option should be removed (for clients
>>> that implement this specification at all).
>>
>> The justification here is much the same as for MTA-STS (RFC 8461).
>> Paragraph 2 of the introduction of RFC 8461 presents the justification,
>> and paragraph 3 of the introduction to this draft says much the same thing.
>>
>> This work was inspired by a paper, "Neither Snow Nor Rain Nor MITM ...An
>> Empirical Analysis of Email Delivery Security"
>> http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf that there was a
>> presentation about at an IETF meeting a few years ago (can't find it on
>> datatracker currently). If you think the draft would benefit from
>> additional motivation, I could mention this paper and add an informative
>> reference to it.
> This makes it sound like your stance is roughly, "we want to make TLS on by
> default but have to deal with deployed reality in order to get there",
> which would seem to have the consequence that "MTAs implementing
> require-TLS should default to requiring TLS and only request no-TLS in
> special cases".  I would support such a position, and in that case would be
> less concerned about the apparent lack of a "don't care" option, since
> there is less of a decision burden when there is a clear default behavior.
>
> That would also make this very solidly an editorial matter, in which case I
> am happy to suggest text modifications but cannot put a blocking Discuss
> position in place...


I'm confused by your comment (as was Viktor). My comment above was 
motivation for having a REQUIRETLS option. Nobody is suggesting that we 
get rid of or otherwise change the default "don't care" -- REQUIRETLS is 
an option, and SMTP will continue to work the way it currently does when 
REQUIRETLS is not applied to a message.


>
>>> It seems that we are in agreement that it's okay to have a "don't care" option,
>>> which is indicated by not using the extension at all.  That said, I still think that
>>> the specific text of Section 4.3 conveys an impression that there is a requirement
>>> to actively decide, with the language about "has the authority to decide whether to
>>> require TLS", "when TLS is  to be required", "when TLS is not to be required", and
>>> "in either case, the decision [...] MAY be done based on [...]".   Perhaps I'm just misreading
>>> the text, but I haven't seen any signals to that effect yet.  I'd suggest (but am open
>>> to further refinement" changing to "has the option to decide whether to require TLS"
>>> and "if one of these cases is selected, the decision [...]" as a way to clarify the language used.
>>
>> Here's a revision to that paragraph that I think makes it clearer that
>> it's OK not to decide:
>>
>> An MUA or other agent making the initial introduction of a message has
>> the option to decide whether to require TLS. If TLS is to be required,
>> it MUST do so by negotiating STARTTLS and REQUIRETLS and include the
>> REQUIRETLS option on the MAIL FROM command, as is done for message relay.
>>
>> Does that convey this adequately?
> ...whereas this goes in a different direction, and makes a different
> editorial clarification.  So, yes, this is fine, but if we want to go the
> other direction we can talk about that, too.


This was the intended direction of the clarification.

>
>>> [discussion of "de facto part of the core SMTP spec" removed, on  indications
>>> that this is not the intent]
>>>
>>> We had some good discussion about the three potential cases for authenticating
>>> the TLS connection:
>>> (1) Dane per RFC 7672
>>> (2) MTA-STS per RFC 8461
>>> (3) DNSSEC-validated MX records + WebPKI authentication of the MX hosts
>>>
>>> I think a little more specificity is needed for the (3) case; we do say to use
>>> the RFC 6125 procedures but still need to specify (e.g.) that the DNS-ID name
>>> type is used and (IIRC) that the hostname resulting from the MX lookup is
>>> used as the DNS-ID to be validated.
>>
>> How about if I add the following text to 4.2.1 step 4:
>>
>> The hostname from the MX record lookup (or the domain name in the
>> absence of an MX record where an A record is used directly) MUST match
>> the DNS-ID or CN-ID of the certificate presented by the server.
> That would work pretty well.  I do have to ask/check whether deployed
> reality means we have to keep CN-ID or could try to ditch it, as is slowly
> happening in the web world, though.


The RFC 7672 definition of Reference Identifier includes the CN-ID, so 
it would be more consistent to include it when referencing 6125 as well.

-Jim