On 7/17/19 12:18 PM, Benjamin Kaduk via Datatracker wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm glad that we were able to come to consensus to rename the header
> field to "TLS-Required"; that addresses a key concern of mine.
I like this better too.
>
> I also appreciate the addition of the "Policy Conflicts" section that
> portrays
> a fairly clear picture of the interaction between this mechanism, DANE, and
> MTA-STS. I still wish that we were able to bring the technologies into
> greater
> alignment and not need to convey the sense that standards-track mechanisms
> are in conflict with each other, but cannot justify blocking publication based
> solely on that desire.
> In this space, though, I do request an additional wording tweak in Appendix
> A.2,
> which currently states "The TLS-Required header field is used when the sender
> of the message wants to override the default policy of the recipient domain to
> require TLS." which uses the "override" terminology without couching it as a
> request. Can we reword to include "request" here as well?
How about, "The TLS-Required header field is used when the sender
requests that the mail system not heed a default policy of the recipient
domain requiring TLS."
>
> 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.
>
> 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?
>
> [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.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [original comment section unchanged; contents likely to be stale]
In that case I'll skip trying to respond to the comments.
If the above seems OK, I'll push out a revision to the draft with those
changes.
-Jim
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
