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

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 15 Aug 2018 17:55:15 +0300

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:"

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.

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.

(and note a typo in a second bullet above: s/succesfully/successfully)

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? 

Regards,
Valery.

> Hi,
>
> this message starts extended 4-week Workgroup Last Call for 
> <draft-ietf-uta-smtp-require-tls-03> "SMTP Require TLS Option".
> The WGLC will end on August 15th. Please, review the document
> (especially if you promised to do it earlier).
> 
> Regards,
> Leif & Valery.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 15 Aug 2018 18:13:20 +0100

> advertise in the EHLO response that it supports REQUIRETLS"?

It would not be logically consistent to offer REQUIRETLS in
a plaintext session, since it cannot be supported.  I'd be
happy if the wording only required the TLS is active for
it to be advertised, so covering both STARTTLS and TLS-on-connect
usage.

The first bullet doesn't quite cover that as it is talking about
the REQUIRETLS option on the MAIL command.  If the requirement
on the service extension advertising is sufficiently tight, it
would be enough to say "if the <extension> was not advertised
by the server, the client MAY NOT <use the option>".

[ That is common for ESMTP service extensions; do we have to
  say it?
]
-- 
Jeremy

---

From: Jim Fenton <[email-masked]>
Date: Wed, 15 Aug 2018 10:31:03 -0700

Valery,

Thanks for your review. Responses inline.

> 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".
>        advertise in the subsequent EHLO response that it supports

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?

> to the first para in Section 4.3, where STARTTLS and REQUIRETLS are

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 16 Aug 2018 09:53:16 +0300

Hi Jim,

> compared with "MUST only".

Well, my reasoning for the change is as follows. The "MUST" word is a 
positive imperative (do it), while the "MUST NOT" is a negative one
(don't do it). In fact, the construction "MUST only" changes the imperative
from positive to negative (don't do it unless), so I think that it is more 
appropriate to rephrase the sentence so that uppercase imperative is negative.

> uppercase MUST is proper. Other opinions?

Well, my understanding of using RFC2119 words is that they describe 
the behavior of the protocol being specified. These bullets are not
the REQUIRETLS protocol, they are prerequisites for REQUIRETLS, 
while the behavior of the protocol ("don't use REQUIRETLS unless 
all the prerequisites take place") is described in the previous para, 
where uppercase word is needed. Putting it differently,
I as implementer usually look for all uppercase words in the spec to make 
sure that my implementation meets all the RFC2119 words requirements.
In this case implementers of REQUIRETLS have no control over
these bullets, they take place outside REQUIRETLS code.

Well, in case of any doubt we can leave this to IESG.

> have missed that adjustment here.

That was my point. To be clear - I don't propose advertising REQUIRETLS
in non-TLS sessions, I only want to decouple it from STARTTLS, because 
TLS session can be established either with STARTTLS or implicitly 
by connecting to a port 465, and RFC8314 suggests the latter way
to be preferred over the former.

> rather than "cryptographic integrity".

That would be more correct (at least formally).

Regards,
Valery.

> -Jim
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 16 Aug 2018 10:01:51 +0300

Hi Jeremy,

> it to be advertised, so covering both STARTTLS and TLS-on-connect

That was my point.

> [ That is common for ESMTP service extensions; do we have to

I don't think it's necessary. The 3rd bullet has already said that the server 
must advertise REQUIRETLS for the client to use it. Just decouple it from 
STARTTLS, since the 1st bullet has already said that the session must be TLS
protected (regardless of using STARTTLS or connecting to a an SMTP TLS port).

Regards,
Valery.