Subject: [Uta] I-D Action: draft-ietf-uta-tls-for-email-00.txt

From: [email-masked]
Date: Mon, 26 Nov 2018 06:57:20 -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 WG of the IETF.

        Title           : Use of TLS for Email Submission and Access
        Authors         : Loganaden Velvindron
                          Stephen Farrell
	Filename        : draft-ietf-uta-tls-for-email-00.txt
	Pages           : 5
	Date            : 2018-11-26

Abstract:
   This specification updates current recommendation for the use of
   Transport Layer Security (TLS) protocol to provide confidentiality of
   email between a Mail User Agent (MUA) and a Mail Submission Server or
   Mail Access Server.  This document updates RFC8314.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-uta-tls-for-email-00
https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls-for-email-00

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: Vittorio Bertola <[email-masked]>
Date: Mon, 26 Nov 2018 16:33:13 +0100 (CET)

> Il 26 novembre 2018 alle 15.57 [email-masked] ha scritto:
> 

I think there's a bug in section 3, second substitution: you may want to add "TLS 1.1" to the list of deprecated TLS versions in the NEW text.

Also, would it make sense to add some text suggesting to set appropriate algorithm exclusions and priority orders in application configurations, so that the insecure ones (RC4 etc.) are not used unless it's strictly necessary? I don't think there's any in RFC 8314 now.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Nov 2018 21:35:11 -0500

1.  I especially appreciate this document being expressed as deltas to 
RFC 8314, as I believe this makes it much easier for a reader 
(especially an implementor or mail service operator) to understand 
exactly what's being changed.

2.  For existing accounts that have already been established between an 
MUA and a mail service, should updated MUAs that follow these revised 
recommendations continue to regard TLS 1.1 as providing the minimum 
confidentiality level?    Or should such MUAs now warn users that these 
services no longer provide adequate confidentiality?   Or are there 
specific server profiles (e.g. certain ciphersuites) of TLS 1.1 that 
still provide adequate confidentiality which can be detected by the client?

IMO there is a delicate compromise to be made between:

- encouraging service operators to upgrade their security,

- not encouraging users to worry needlessly about security risks that 
don't actually exist, and especially,

- not conditioning users to ignore security warnings because they're too 
frequently present.

So when an updated MUA uses an existing account configuration to make a 
connection with a server that supports TLS 1.1 at most, IMO it should 
still regard that connection as providing minimum confidentiality as 
long as there's no reason to believe that the connection is insecure.  
(Updated MUAs will still flag newly established connection to that 
server as not having minimum confidentiality, so operators still have 
some incentive to .)

However if the TLS 1.1 connection (for example) is using a ciphersuite 
now known to be insecure, an updated MUA should begin to flag those 
connections as no longer having minimum confidentiality.

(The theory that I have is that if security warnings to users are 
consistently accurate and provide a warning of severity that is 
proportionate to the threat, users will learn to treat them as credible.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Nov 2018 21:41:52 -0500

I knew I forgot something:

4. I think it would be appropriate for the title of this document to be 
something that relates it to RFC 8314, for example:

Updates to Use of Transport Layer Security (TLS) for Email Submission 
and Access

The current title reads as if this document were the main body of 
recommendations.

Keith

On 11/27/18 9:35 PM, Keith Moore wrote:
> 2.  For existing accounts that have already been established between 
> an MUA and a mail service, should updated MUAs that follow these 
> revised recommendations continue to regard TLS 1.1 as providing the 
> minimum confidentiality level?    Or should such MUAs now warn users 
> that these services no longer provide adequate confidentiality?   Or 
> are there specific server profiles (e.g. certain ciphersuites) of TLS 
> 1.1 that still provide adequate confidentiality which can be detected 
> by the client?
>
> - not conditioning users to ignore security warnings because they're 
> too frequently present.
>
> So when an updated MUA uses an existing account configuration to make 
> a connection with a server that supports TLS 1.1 at most, IMO it 
> should still regard that connection as providing minimum 
> confidentiality as long as there's no reason to believe that the 
> connection is insecure.  (Updated MUAs will still flag newly 
> established connection to that server as not having minimum 
> confidentiality, so operators still have some incentive to .)
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta