Re: [TLS] Industry Concerns about TLS 1.3

As one of the WG chairs, it looks like it’s time to bring to a close whether or not we’ll be re-introducing static RSA key exchange.

One digression before that though: I think there is a realization in the IAB, IESG, and many parts of the IETF that significant operational/management issues exist with encryption; the MaRNEW workshop [0][1][2], some related drafts [3][4], and the PLUS/ACCORD BOFs proposals are just some examples that reflect this.

On dropping static RSA key exchange: The DH-only key exchange proposal had a very lengthy and robust discussion.  PFS was definitely a driver [5], but the simplifying effect of removing static RSA key exchange was another one that should not be forgotten; less options, less code, (hopefully) less coding errors.  It is probably also worth pointing out that the "remove RSA key exchange" shoe has been dropping since 2003: “RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications” [6].

On the one hand, I am sympathetic to concerns about impacts resulting from protocol changes.  On the other hand, the cycle of new protocol version followed by product updates is not really that out of the ordinary; this cycle is disliked by those with budgets but normal nonetheless.  Also, there appears to be a couple of different solutions that would allow an enterprise to do what it wants.  I’m not seeing anything that would alter the consensus that we reached earlier to drop static RSA key exchange from TLS 1.3.

spt

[0] https://www.iab.org/activities/workshops/marnew/
[1] https://datatracker.ietf.org/doc/draft-nrooney-marnew-report/
[2] https://www.ietf.org/proceedings/94/slides/slides-94-saag-1.pdf
[3] https://www.ietf.org/archive/id/draft-mm-wg-effect-encrypt-03.txt
[4] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-management/
[5] https://datatracker.ietf.org/doc/rfc7525/
[6] https://datatracker.ietf.org/doc/rfc3447/

> On Oct 05, 2016, at 15:37, BITS Security <BITSSecurity@fsroundtable.org> wrote:
> 
> Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few years back that moved Diffie Hellman to the top cipher suite priorities which broke security and fraud monitoring, APM reporting, and sniffer troubleshooting for a financial services client and at least one other organization in a different industry.  
> 
> The solution, at the time, was to put the PFS options (choices we will no longer in 1.3) at the bottom of the priority list.  I don't know how much of this was communicated back to the vendors at the time.  
> 
> In retrospect, this could have been seen as the canary in the coalmine... but here we are now at least.  
> 
> - Andrew 
> 
> 
> -----Original Message-----
> From: Florian Weimer [mailto:fw@deneb.enyo.de] 
> Sent: Wednesday, October 5, 2016 2:17 PM
> To: BITS Security <BITSSecurity@fsroundtable.org>
> Cc: tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
> 
> * BITS Security:
> 
>> Deprecation of the RSA key exchange in TLS 1.3 will cause significant 
>> problems for financial institutions, almost all of whom are running 
>> TLS internally and have significant, security-critical investments in 
>> out-of-band TLS decryption.
>> 
>> Like many enterprises, financial institutions depend upon the ability 
>> to decrypt TLS traffic to implement data loss protection, intrusion 
>> detection and prevention, malware detection, packet capture and 
>> analysis, and DDoS mitigation.
> 
> We should have already seen this with changing defaults in crypto libraries as part of security updates.  That should have broken passive monitoring infrastructure, too.
> 
> Maybe some of the vendors can shed some light on this problem and tell us if they ever have received pushback for rolling out ECDHE-by-default.  (I know that some products have few capabilities for centralized policy management, which is why defaults matter a lot
> there.)
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls