Re: [Uta] Last call: <draft-ietf-uta-smtp-require-tls-03> "SMTP Require TLS Option"

[Jim Fenton <[e-mail]>]

Valery,

Thanks for your review. Responses inline.


On 8/15/18 7:55 AM, Valery Smyslov wrote:
> Hi,
>
> here is my review of the document.
>
> The draft is well written, however I found few places where it could be improved.
>
> 1. Section 2:
>
> In the following para:
>
>     In order to specify REQUIRETLS treatment for a given message, the
>     REQUIRETLS option is specified on the MAIL FROM command when that
>     message is transmitted.  This option MUST only be specified in the
>     context of an SMTP session meeting the security requirements that
>     have been specified:
>
> The last sentence uses uppercase MUST, while in fact using MUST NOT is more
> appropriate giving the meaning  of the sentence. I.e. "This option MUST NOT be
> specified unless all the following requirements are met in the context of SMTP session:"

"MUST only" is logically equivalent to "MUST NOT...unless". Since 
they're equivalent, I have no objection to the wording you suggest, 
although IMO "MUST NOT...unless" is somewhat of a double negative as 
compared with "MUST only".
>
> And in the following list I believe using uppercase words is unnecessary,
> since they described not a protocol (REQUIRETLS) behavior, but
> the requirements for REQUIRETLS to be used. I suggest changing
> those MUSTs to lowercase.
>
>     o  The session itself MUST employ TLS transmission.
>
>     o  The certificate presented by the SMTP server MUST either verify
>        successfully in a trust chain leading to a certificate trusted by
>        the SMTP client or it MUST verify succesfully using DANE as
>        specified in RFC 7672 [RFC7672].  For trust chains, the choice of
>        trusted (root) certificates is at the discretion of the SMTP
>        client.
>
>     o  Following the negotiation of STARTTLS, the SMTP server MUST
>        advertise in the subsequent EHLO response that it supports
>        REQUIRETLS.

I'm not claiming to be an expert on RFC 2119 usage, but the three MUSTs 
that you cite are absolute requirements of the specification. It could 
be worded to be more normative to the implementation of REQUIRETLS, that 
in order to send a message requiring TLS that the session MUST employ 
TLS transmission, verify certificates, and advertise its support of 
REQUIRETLS in STARTTLS sessions. But I still think that my use of 
uppercase MUST is proper. Other opinions?

>
> 2. I also have a question regarding the last bullet above - why advertising
> REQUIRETLS is linked with negotiation of STARTTLS?
> It is my understanding that TLS session may be established
> without negotiation STARTTLS (as recommended by RFC8314),
> so why the last bullet doesn't say just: "The SMTP server must
> advertise in the EHLO response that it supports REQUIRETLS"?
> Am I missing something here? The same question is applicable
> to the first para in Section 4.3, where STARTTLS and REQUIRETLS are
> also logically linked.

As Jeremy Harris pointed out while I was typing this, REQUIRETLS is only 
accepted within TLS-protected sessions. I had originally proposed 
advertising REQUIRETLS in all EHLO responses (TLS or not) as an 
optimization (don't bother negotiating STARTTLS if you have a message 
requiring TLS and the server doesn't support REQUIRETLS) but that 
wouldn't have been correct.

But you are correct that REQUIRETLS should be advertised in EHLO 
responses for all TLS-protected sessions, not just STARTTLS. Support for 
REQUIRETLS in such sessions was an afterthought on my part and I seem to 
have missed that adjustment here.
>
> (and note a typo in a second bullet above: s/succesfully/successfully)

Thanks!
>
> 3. Section 8.1.
>
>     REQUIRETLS is generally effective against passive attackers who are
>     merely trying to eavesdrop on an SMTP exchange between an SMTP client
>     and server.  This assumes, of course, the cryptographic integrity of
>     the TLS connection being used.
>
> I assume that it is encryption (and not an integrity) that protects
> messages confidentiality against passive eavesdroppers, doesn't it?

I didn't mean content integrity -- I meant that the TLS session has 
integrity (i.e., is secure). But I can see how this might be interpreted 
as you have read it. Perhaps it should say "cryptographic security" 
rather than "cryptographic integrity".

-Jim