Re: [perpass] Fwd: New Version Notification for draft-fenton-smtp-require-tls-01.txt

[Jim Fenton <[e-mail]>]

On 2/17/16 2:13 PM, Yakov Shafranovich wrote:
> Some minor comments:
>
> Section 1:
> "It also requires that the SMTP server advertise
>    that it also supports REQUIRETLS, in effect promising that it will
>    honor the requirement to require STARTTLS and REQUIRETLS for all
>    onward transmissions of messages specifying that requirement."
> "
>
> The part about "promising" does not seem to go together with the
> optional parameter in section 2 about onward transmission.

If you are saying that the statement in Section 1 is incomplete because
it does not say that the server must honor the requirements of the
optional (server authentication) parameter as well, I agree.

>
> Section 3.1 - tagging:
> I am wondering if an email header should be defined to carry this
> data, which would also allow for auditing by the receiver. Sort of
> similar to the SPF/DKIM headers used today.

One could be defined, but that would be a message format extension (RFC
5322) rather than a mail transport extension (RFC 5321). It would then
be necessary to define under what circumstances the new header field
would be moved into the transport realm.  I thought it to be more
straightforward to consider REQUIRETLS to be an aspect of the message
envelope (like the envelope-to and envelope-from addresses) rather than
a header field.
>
> Section 3.4 - delivery:
> It is unclear what "delivery" means here, especially considering that
> SMTP may relay messages to another server, perhaps reference RFC 5598?
> Also, the parts in section 1 and the optional parameter in section 2
> should play together with this, perhaps by requiring TLS in IMAP, etc.
> or not. Either way, this may need clarification.

I have been trying to void "boiling the ocean" by constraining this
feature to SMTP. From the context, it should be clear that by delivery I
was referring to protocols such as IMAP and POP, although webmail
applies here as well. Are you suggesting that this requirement should be
a MUST rather than the SHOULD I proposed?
>
> Section 5:
> What are the actual added codes? I believe 5.7.10 already exists.

5.7.10 does exist, but seems to have the right semantics ("Encryption
needed"). The others will need to be allocated and since they are
numeric codes I didn't presume to define them myself.

>
> Section 6:
> Maybe reference RFC 4949 for terminology?

I'll have a look at 4949.
>
> One other comment - perhaps some sort of limiting digital signatures
> for headers only like DKIM can be employed by the receiving MTA to
> certify that the receipt and transmission was effective? I am thinking
> along the lines of Received headers or DKIM headers, which would allow
> traceability.

This seems to be a separate feature - authenticated return receipts.
This might be useful, but I don't think it belongs here.  I would hope
that MTAs would add information about REQUIRETLS to their Received:
header fields, much as they do about the use of TLS for messages they
receive, but I haven't worked out quite how to specify that yet.
> Yakov

Thanks for your review!

-Jim