Subject: [Uta] AD review of draft-ietf-uta-smtp-require-tls-06

From: Alexey Melnikov <[email-masked]>
Date: Wed, 9 Jan 2019 16:34:01 +0000

Hi,

Sorry for the delay in reviewing this. I reviewed it in 2018, but needed 
to work on expanding/decoding my notes so that they become useful for 
other readers.

The document needs to specify line length increase and whether the 
extension is allowed for SMTP Submission and LMTP (I think the answer is 
Yes to both).

In Section 4.2.1:

RFC 6125 use needs more details, in particular on whether CN-IDs are 
allowed, use of wildcards in certificates. I will followup on this 
separately.

 > 6.  The SMTP client SHOULD also require that meaningfully secure
 >     cipher algorithms and key lengths be negotiated with the server.
 >     The choices of key lengths and algorithms change over time, so a
 >     specific requirement is not presented here.

This SHOULD is not implementable as written. The document needs to 
provide more details on where this information can be found. (Imagine 
that I implement a new MTA that supports this.)

5.7.x error code needs to be marked for IANA to assign. Please add an 
IANA Consideration for it.

In Section 4.2.2:

This section is not clear about when to insert RequireTLS: NO header 
field in the message!

At this point in the document it is not even very clear that the 
REQUIRETLS MAIL FROM parameter can have multiple values! In fact, the 
document has no examples and no ABNF, so I don't even know what the 
syntax is!

In Section 5:

 > The SMTP client for a REQUIRETLS
 > bounce message MUST use an empty MAIL FROM return-path as required by
 > [RFC5321].

Don't use RFC 2119 language, as this is already required by RFC 5321. I 
suggest you just use non normative language here.

 > 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.

Shouldn't this be mentioned in one of 4.X sections?

In Section 8:

 >   The purpose of REQUIRETLS is to improve communications security for
 >   email by giving the originator of a message an expectation that it
 >   will be transmitted in an encrypted form "over the wire". When used,
 >   REQUIRETLS changes the traditional behavior of email transmission,
 >   which favors delivery over the ability to send email messages using
 >   transport-layer security, to one in which requested security takes
 >   precedence over delivery and domain-level policy.

Is this still true when "RequireTLS: NO" is used?

It looks like RFC 7672 reference should be Normative.

Best Regards,

Alexey

---

From: Jim Fenton <[email-masked]>
Date: Thu, 10 Jan 2019 11:48:43 -0800

Thanks for your review, Alexey. Responses and a few clarifying questions
below.

On 1/9/19 8:34 AM, Alexey Melnikov wrote:
> Hi,
>
> Sorry for the delay in reviewing this. I reviewed it in 2018, but
> needed to work on expanding/decoding my notes so that they become
> useful for other readers.
>
>
> extension is allowed for SMTP Submission and LMTP (I think the answer
> is Yes to both).

Specify line length increase: I'm not sure what you mean here;
presumably something having to do with the additional length from the
presence of the REQUIRETLS MAIL FROM parameter?

Submission: will add. LMTP: I have never run into it, and it is
informational. Does anyone actually use it?

> allowed, use of wildcards in certificates. I will followup on this

Will wait to hear from you on this then.

> that I implement a new MTA that supports this.)

As may be clear from the specification, I struggled with this a bit. I
didn't want to put in a specific requirement because I don't like the
idea of lots of specifications calling out specifics and then having to
be revised as things change. I'd rather point to a BCP, if there is an
appropriate one, that specifies this and changes from time to time. Is
there such a BCP? Or I could perhaps just leave this out, because it's
somewhat obvious and clients shouldn't be accepting insecure lengths and
algorithms anyway.

> IANA Consideration for it.

Will add.

> This section is not clear about when to insert RequireTLS: NO header

That more properly belongs in Section 3, "The RequireTLS Header Field",
since 4.2.2 deals with the mechanics of what to do when it is there. The
answer is that the header field is inserted by the originator when
sending a message for which they want delivery to have clear precedence
over security by ignoring MTA-STS and DANE if necessary. Should this be
more explicit there?

> document has no examples and no ABNF, so I don't even know what the

Per WG consensus, the options for the REQUIRETLS MAIL FROM parameter no
longer exist. If I missed something and there is still some text
referring to them, please let me know.

Examples/ABNF, I had thought this was simple enough that these weren't
needed, but fair point, will add.

> Don't use RFC 2119 language, as this is already required by RFC 5321.
> I suggest you just use non normative language here.

Will do.

> Shouldn't this be mentioned in one of 4.X sections?

Yes, it should.

> Is this still true when "RequireTLS: NO" is used?

No, this needs to be updated.

> It looks like RFC 7672 reference should be Normative.

Yes.

Look for a revision in a week or so.

-Jim

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Jan 2019 11:23:26 +0000

Hi Jim,

Very quick comment on just one point:

> needed, but fair point, will add.

For new header fields it is important to show whether any CFWS are 
allowed in values, so I prefer ABNF for that.

I also find examples help in understanding protocol, even if text says 
exactly the same thing.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Jan 2019 11:37:13 +0000

Hi Jim,

Below I removed comments where we are in agreement (or which we already 
discussing separately). I will reply to a few remaining comments separately.

> presence of the REQUIRETLS MAIL FROM parameter?
Yes. This is a generic requirement for specifying SMTP extensions which 
extend MAIL FROM or RCPT TO. If neither is extended, saying so would 
also be beneficial.
> informational. Does anyone actually use it?
Yes, it is used. Both by open source (etc least Cyrus, Dovecot, EXIM, 
Postfix) and commercial (Oracle, Isode) software.

  [snip]

> somewhat obvious and clients shouldn't be accepting insecure lengths and

We have an RFC for this that came from this WG: RFC 7525. It is a BCP. 
If problems are found with this document, it will be updated.

So if you say "RFC 7525 or its successor", that would be fine with me.

Best Regards,

Alexey