Great! Would it be possible to add a clarification along these lines in the text? I would also suggest moving section “5.3 Server DEEP Status” up - to become section 5.1 and then realign the existing text as needed. Logically, first the server ‘publishes’ its policy (expressed in terms of ‘statuses’) for the client to ‘records’ it for potential future use, and only then the client ‘latches’ the statuses that correspond to the current connection. With an updated text flow, it would be easier for the readers to follow and understand the algorithm.
Thanks, Orit. From: Chris Newman [mailto:[email protected]] Sent: Friday, March 18, 2016 1:16 PM To: Orit Levin (CELA) <[email protected]>; Julien ÉLIE <[email protected]>; [email protected] Subject: Re: [Uta] I-D Action: draft-ietf-uta-email-deep-03.txt On March 16, 2016 at 15:42:37 , Orit Levin (CELA) ([email protected]<mailto:[email protected]>) wrote: Chris, I have a follow up question for clarification. From section 5.1: "When a security tag is saved by the client in this way, it is then considered latched." From section 5.3 last par.: "..., then the client SHOULD record the server's DEEP status information..." Are these two different steps or are they the same? My interpretation is that the first one is the "latching" of the 'status' that is being used to secure the current connection in which the status is published. The second one, is to record additional information, i.e. the server's capabilities (or policy) for potential client's upgrade in the future? Is that correct? Yes. - Chris From: Uta [mailto:[email protected]] On Behalf Of Chris Newman Sent: Friday, March 11, 2016 2:04 PM To: Julien ÉLIE <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [Uta] I-D Action: draft-ietf-uta-email-deep-03.txt On March 11, 2016 at 13:34:03 , Julien ÉLIE (mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
