On March 11, 2016 at 13:34:03 , Julien ÉLIE ([email protected]) wrote:
Hi all,
Here are a few remarks:
5.1. Email Security Tags
Each security latch is given a name known as an email security tag.
An email security tag is a short alphanumeric token that represents a
security facility that can be used by an IMAP, POP or SMTP Submission
session. When a server advertises a security tag it is making a
commitment to support that security facility indefinitely and
recommending that the client save that security tag with the account
configuration and require that security feature for future
connections to that server.
=> Does it mean that if a server advertises both "tls11" and "tls12",
and one day TLS 1.1 is declared insecure and its support is deactivated
on the server, "tls11" will still be mandatory to advertise even though
only TLS 1.2 is available?
No, the email security tags communicate the policy the server wants the client
to adopt. If the server operator may want to turn on TLS 1.1 and turn off TLS
1.2 in the future, then the server should advertise the “tls11” email security
tag and not advertise the “tls12” email security tag even if the server is TLS
1.2 only at the moment. If the server operator is committing to supporting TLS
1.2 or later indefinitely and wants clients to require that level of TLS, then
the server operator should advertise only the “tls12” email security tag and
not the “tls11” email security tag.
If I understand well how security tags work, "tls11" will always be
advertised if "tls12" is. So why bother to advertise "tls11"?
That’s not correct.
When TLS 1.3 has been standardized, will it mean that "tls11", "tls12"
and "tls13" will all be advertised and latched?
I don't see the point in having such redundancy.
When the client latches “tls11”, the client will insist the server always
implement TLS 1.1 or later. If the server permanently deactivates the TLS 1.1
protocol but continues offering 1.2, it would stop advertising the “tls11”
email security tag, but would advertise “tls12”. The security feature
associated with the client's “tls11” latch (that the server will provide TLS
1.1 or later) is still met in that case. The client can then update it’s latch
to “tls12”, subsequently preventing use of TLS 1.1 in the future.
So the purpose of the tls11 & tls12 email security tags is to communicate a
minimum TLS version that the client can adapt. If the client has latched
“tls11”, and the server offers TLS 1.0 only, then the client assumes the server
has been compromised and refuses to connect because the conditions of the latch
are not met. For example, with the NSS security library, the version number of
the latch will determine the lowest value the client would pass into the “min”
field of the SSLVersionRange structure when calling SSL_VersionRangeSet.
10.6. Advertisement of DEEP status
MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and
an HTTPS URL that can be used to inform clients of service outages or
problems impacting client confidentiality. Note that advertising
tls-cert is a commitment to maintain and renew server certificates.
=> Couldn't tls12 also be advertised?
Yes. tls12 is a MAY when tls11 is advertised.
11.1. Security Tag Registry
IANA shall create (has created) the registry "Email Security Tags".
=> In order not to duplicate registries in the future, couldn't the IANA
registry be named "Security Tags" or "Security Tags in Applications"
instead of "Email Security Tags"? This way, any protocol could benefit
of the available security tags instead of having to ask for yet another
registry.
If we decide to generalize this work, we can rename the registry. But I want to
get the email work standardized first without being distracted by the
generalization discussion as generalization discussions tend to bog down the
IETF and prevent forward progress.
- Chris
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
