On March 24, 2016 at 12:42:07 , Jim Fenton ([email protected]) wrote: Not to distract from the STS discussion, but I thought I'd point out another approach to SMTP TLS 'encouragement' that I submitted a few weeks ago: draft-fenton-smtp-require-tls-01. There has been some discussion of this draft, primarily on the ietf-smtp mailing list and a little on the perpass list.
REQUIRETLS is an SMTP service extension that allows an SMTP client to specify (via a MAIL FROM option) that a given message must be sent over a TLS protected session with specified security characteristics. Options allow the specification of allowable methods of server certificate verification, including web-PKI and DANE. In advertising its support for REQUIRETLS, the SMTP server is promising to honor that requirement. The idea here is that REQUIRETLS allows the SMTP client to override the default "deliver even if you can't do it securely" behavior of SMTP. The philosophy is that the sender of the message (SMTP client) is in the best position to know if a given message should only be sent via TLS, either based on some information it has about the sensitivity of the message or based on the client's local policy. I plan on giving a short talk on REQUIRETLS (remotely) at the BA UTA meeting. Questions or comments are of course welcome, either here or on ietf-smtp. Having a protocol that allows a client to request that a particular SMTP security policy be applied to all hops is an interesting idea. However, I consider it important that we have a single extensible security policy model and syntax if possible. Can you change your proposal to reference the security policy model and syntax in DEEP (which includes extensibility)? If not, can you propose changes to DEEP that would help align these proposals? I’d like to avoid having different ways to specify SMTP security policy in different places (syntax variations are annoying, semantic variations are a concern). https://tools.ietf.org/html/draft-ietf-uta-email-deep-04 - Chris
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
