Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Yuhong Bao]

I can't help but notice the text:
"Versions of TLS before 1.3 supported compression with the list of supported 
compression methods being sent in this field. For every TLS 1.3 ClientHello,  
this vector MUST contain exactly one byte set to zero, which corresponds to the 
“null” compression method in prior versions of TLS. If a TLS 1.3 ClientHello is 
received with any other value in this field, the server MUST abort the 
handshake with an “illegal_parameter”  alert. Note that TLS 1.3 servers might 
receive TLS 1.2 or prior ClientHellos which contain other compression methods 
and MUST follow the procedures for the appropriate prior version of TLS."
IMO, the compression methods section of ClientHello should be ignored as 
mentioned by Martin Rex.

It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST NOT.
One reason for that is that it is not broken the way that say 56-bit encryption 
is.

From: TLS  on behalf of Joseph Salowey 
Sent: Wednesday, October 26, 2016 7:56 PM
To: tls@ietf.org
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
  

This is a working group last call announcement for draft-ietf-tls-tls13-18, to 
run through November  20. If possible, we would like to receive comments on the 
list by November 13 so  they can be discussed at the meeting in Seoul. We hope 
to address any substantive issues raised during that process shortly thereafter.


In order to allow for cryptographic review, we will delay submission of the 
draft to the IESG until the end of January 2017; there will be an opportunity 
to address  any issues discovered by the cryptographic community prior to 
submission to the IESG.


Cheers,


Joe

 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Yuhong Bao]

Adding Andrei Popov.


From: BITS Security <bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; tls@ietf.org
Subject: RE: Industry Concerns about TLS 1.3

Yuhong-Thank you for the response.

Our thinking here is that enterprises who use content delivery networks will 
have the end-user session hidden from them.

The session from the end user to the edge of the content delivery network will 
be a different session than the one from the enterprise sees.  The IP's and 
ports will be different, the TCP layer activity like retransmissions will be 
different, and because of caching the application layer will be somewhat 
different.  There will be times when we need packet level data from the End 
User and TLS decryption of this packet level data for troubleshooting.

With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt 
it with the RSA private key.  With TLS 1.3 we will have to rely on the 
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.  
Unfortunately, Microsoft does not allow this functionality, which is a problem 
in a TLS 1.3 only environment.

-Andrew


From: Yuhong Bao [mailto:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657


From: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
<bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: tls@ietf.org
Subject: [TLS] Industry Concerns about TLS 1.3

To:  IETF TLS 1.3 Working Group Members

My name is Andrew Kennedy and I work at BITS, the technology policy division of 
the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
organization represents approximately 100 of the top 150 US-based financial 
services companies including banks, insurance, consumer finance, and asset 
management firms.

I manage the Technology Cybersecurity Program, a CISO-driven forum to 
investigate emerging technologies; integrate capabilities into member 
operations; and advocate member, sector, cross-sector, and private-public 
collaboration.

While I am aware and on the whole supportive of the significant contributions 
to internet security this important working group has made in the last few 
years I recently learned of a proposed change that would affect many of my 
organization's member institutions:  the deprecation of RSA key exchange.

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.  Unlike some other businesses, financial institutions also rely 
upon TLS traffic decryption to implement fraud monitoring and surveillance of 
supervised employees.  The products which support these capabilities will need 
to be replaced or substantially redesigned at significant cost and loss of 
scalability to continue to support the functionality financial institutions and 
their regulators require.

The impact on supervision will be particularly severe.  Financial institutions 
are required by law to store communications of certain employees (including 
broker/dealers) in a form that ensures that they can be retrieved and read in 
case an investigation into improper behavior is initiated.  The regulations 
which require retention of supervised employee communications initially focused 
on physical and electronic mail, but now extend to many other forms of 
communication including instant message, social media, and collaboration 
applications.  All of these communications channels are protected using TLS.

The impact on network diagnostics and troubleshooting will also be serious.  
TLS decryption of network packet traces is required when troubleshooting 
difficult problems in order to follow a transaction through multiple layers of 
infrastructure and isolate the fault domain.   The pervasive visibility offered 
by out-of-band TLS decryption can't be replaced by MITM infrastructure or by 
endpoint diagnostics.  The result of losing this TLS visibility will be 
unacceptable outage times as support groups resort to guesswork on difficult 
problems.

Although TLS 1.3 has been designed to meet the evolving security needs of the 
Internet, it is vital to recognize that TLS is also being run extensively 
inside the firewall by private enterprises, particularly those that are heavily 
regulated.  Furthermore, as more applications