Apologies for the very late reply; this slipped through the cracks somehow.


On 8/22/16 7:53 AM, Jeremy Harris wrote:
> On 16/08/16 23:09, Jim Fenton wrote:
>> Name:                draft-fenton-smtp-require-tls
>> Revision:    02
> - Section 2, bullet point discussing the DNSSEC parameter:
>
>   Should the requirement for dnssec to extend also to SRV,
>   A and AAAA lookups?

Yes; I'm not sure why I singled out MX and CNAME because I know those
aren't the only ways of locating the server. I would propose to change
"confirm that any MX record or CNAME lookup used to locate the SMTP
server" to "confirm that and DNS record lookup(s) used to locate the
SMTP server".
>
>
> - Section 3.2, last paragraph (onward transmission must use
>   REQUIRETLS):
>
>   Should this have a "MUST" ?

That requirement should have been made elsewhere, but I agree it
wouldn't hurt to use more normative language here.
>
>
> - Section 3.3, on introducing the need to REQUIRETLS to a
>   message transmission chain:
>
>   Currently the only actor described as having this authority
>   is the sourcing MUA.   What about a MAY permitting an MTA to
>   either introduce or upgrade the requirement associated with
>   a message?   Probably best to also specifically "MUST NOT"
>   any downgrade or removal, too.

The phrase "or based on policy" was intended to allow an MTA to
introduce a REQUIRETLS option, but that perhaps isn't clear enough.
Downgrades are definitely a no-no, doesn't hurt to emphasize that.
>
>
> - Should a receiving MTA be required to mark up the
>   Received:  header it adds in some specific way for
>   REQUIRETLS messages?

It would help to diagnose problems. In some circumstances it couldn't be
depended upon (a bad actor MTA could downgrade REQUIRETLS and strip
header fields from Received: header fields as well) but as I have said,
if the MTA you're entrusting your message to is a bad actor, you need
more than transport-level security anyway.

But I'm not clear on the extent to which the content of Received: header
fields is standardized. I don't see any mention in RFC 3207 of
annotating them to indicate the use of STARTTLS (even though I typically
see that), and without that having such a requirement in REQUIRETLS
seems out of place. Does anyone know if that requirement exists elsewhere?

Thanks for the very helpful review.

-Jim

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to