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

[Jim Fenton <[e-mail]>]

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


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?

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


Will wait to hear from you on this then.

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


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.


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


Will add.

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


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?

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


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.

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


Will do.

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


Yes, it should.

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


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