On Sun, Jun 8, 2014 at 1:34 AM, Evert Mouw <post(_at_)evert(_dot_)net> wrote:
On 06/08/2014 05:35 AM, Peter Bowen wrote:
What about bringing HSTS to SMTP as well?
S: 250-STSEC MAX-AGE=31536000
This would indicate that connections must use STARTTLS for future
connections. Ideally, this would allow a client to directly issue
STARTTLS on connect, rather than EHLO (a protocol violation today),
reducing the amount of unencrypted data on the connection and speeding
up the connection sequence.
Would be nice to have. However, I could repeat my doubts about breaking
connectivity with all those mailservers out there that use self-signed
certificates (wat HSTS does). I advocate the use of DANE. If support for
DANE would be mandatory for a "HSTS for SMTP", then it would be a great
solution.
TLSA records make sense in many contexts. Unfortunately the current
spec for using them with SMTP (draft-ietf-dane-smtp-01 and
draft-ietf-dane-srv-05) make them unusable unless both the source and
target domains use DNSSEC. For example, if I have
example.com. IN MX 5 spmx.example.net.
Then both example.com and example.net have to be using DNSSEC.
Without DNSSEC: "If the SRV response was insecure, the client MUST NOT
perform any TLSA queries" and "SRV is insecure: The reference
identifiers SHALL include the service domain and MUST NOT include the
SRV target host name."
This means that the certificate on spmx.example.net must have
example.com in the subject alternative name, most likely as a SRVName.
I am not area of any public CAs that issue certificates with SRVName
in the SAN.
I'm also not sure if any current SMTP clients follow RFC 6125 and RFC
4985 and would check SRVnames in the certificate if it was present.
Thanks,
Peter
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp