Subject: [Uta] I-D Action: draft-ietf-uta-email-deep-03.txt

From: [email-masked]
Date: Fri, 11 Mar 2016 13:07:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications of the IETF.

        Title           : Deployable Enhanced Email Privacy (DEEP)
        Authors         : Keith Moore
                          Chris Newman
	Filename        : draft-ietf-uta-email-deep-03.txt
	Pages           : 39
	Date            : 2016-03-11

Abstract:
   This specification defines a set of requirements and facilities
   designed to improve email confidentiality between a mail user agent
   (MUA) and a mail submission or mail access server.  This provides
   mechanisms intended to increase use of already deployed Transport
   Layer Security (TLS) technology, provide a model for mail user
   agent's confidentiality assurance, and enable mail service providers
   to advertise improved TLS confidentiality facilities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-uta-email-deep-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-email-deep-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 11 Mar 2016 22:33:52 +0100

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?

If I understand well how security tags work, "tls11" will always be 
advertised if "tls12" is.  So why bother to advertise "tls11"?
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.

   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?

   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.

-- 
Julien ÉLIE

« L'atour est fiel aux Huns valides. »

---

From: Chris Newman <[email-masked]>
Date: Fri, 11 Mar 2016 14:04:20 -0800

On March 11, 2016 at 13:34:03 , Julien ÉLIE ([email-masked]) wrote:
Hi all, 

Here are a few remarks: 

5.1. Email Security Tags 

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.

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.

Yes. tls12 is a MAY when tls11 is advertised.

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

---

From: "Orit Levin (CELA)" <[email-masked]>
Date: Wed, 16 Mar 2016 22:42:26 +0000

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?
Orit.

From: Uta [mailto:[email-masked]] On Behalf Of Chris Newman
Sent: Friday, March 11, 2016 2:04 PM
To: Julien ÉLIE <[email-masked]>; [email-masked]
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-masked]) wrote:
Hi all, 

Here are a few remarks: 

5.1. Email Security Tags

---

From: Chris Newman <[email-masked]>
Date: Fri, 18 Mar 2016 13:16:05 -0700

On March 16, 2016 at 15:42:37 , Orit Levin (CELA) ([email-masked]) wrote:
Chris, 
Yes.

		- Chris

Here are a few remarks:  

5.1. Email Security Tags  

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: "Orit Levin (CELA)" <[email-masked]>
Date: Fri, 18 Mar 2016 23:58:09 +0000

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-masked]]
Sent: Friday, March 18, 2016 1:16 PM
To: Orit Levin (CELA) <[email-masked]>; Julien ÉLIE <[email-masked]>; [email-masked]
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-masked]<mailto:[email-masked]>) wrote:
Chris,

Yes.

                           - Chris
From: Uta [mailto:[email-masked]] On Behalf Of Chris Newman
Sent: Friday, March 11, 2016 2:04 PM
To: Julien ÉLIE <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Uta] I-D Action: draft-ietf-uta-email-deep-03.txt

Here are a few remarks:

5.1. Email Security Tags

_______________________________________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uta