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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
