[TLS] Wireshark Download for TLS1.3

[nalini.elkins]

All,

If you want to download a WorkInProgress version of Wireshark that supports 
TLS1.3 (latest version of draft -18 only!).   Please go to:

https://www.wireshark.org/download/automated/

THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!

We owe HUGE thanks to Peter Wu & Alexis La Goutte (core Wireshark developers) 
for the TLS1.3 dissector.  I did some minor, initial work on the dissector but 
it is really their great effort and continued support that is making this 
dissector available for us.   Thank you guys so much!!!

BTW, we had started an email list to discuss diagnostic & implementation 
experiences for TLS.

https://www.ietf.org/mailman/listinfo/tls-implementers

Shall we move to that list to discuss?   Maybe we can share PCAPs.

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

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

Re: [TLS] Industry Concerns about TLS 1.3

[nalini.elkins]

On 22/09/16 19:36, Yuhong Bao wrote:
> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

>Yuk. Prioritising the needs of those debugging networks
>over the maybe 5-6 orders of magnitude more folks using
>them is ass-backwards IMO. That result looks to me like
>a very bad decision if I'm following it correctly.
Brings to mind the story about the people who were so concerned about having 
the engine stolen out of the car that they bolted the hood shut so you could 
never get in.   So, of course, if there was any maintenance to be done to the 
engine, if was impossible.
I wonder if there is some need for balancing of requirements.
Nalini

> 
> 
> From: TLS  on behalf of BITS Security 
> 
> 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 move off of the desktop 
> and into web browsers and mobile applications, dependence on TLS is 
> increasing.
> 
> Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS 
> 1.2 by major browser vendors, or changes to regulatory standards will force 
> these enterprises - including financial institutions - to upgrade to TLS 1.3. 
>  It is vital to financial institutions and to their customers and regulators 
> that these institutions be able to maintain both security and regulatory 
> compliance during and after the transition from TLS 1.2 to TLS 1.3.
> 
> At the current time viable TLS 1.3-compliant solutions to problems like DLP, 
> NIDS/NIPS, PCAP, DDoS mitigation, malware 

[TLS] Volunteers to Alpha Test Wireshark Dissector for (D)TLS1.3

[nalini.elkins]

All,



I have modified the Wireshark dissectors for TLS and DTLS to recognize and 
parse a fair amount of (D)TLS1.3 traffic.

I took a debug trace that Martin Thomson gave me with (D)TLS1.3 payload data 
only & created PCAP traces with fake IP and TCP/UDP headers so that I could 
have something to dissect. I think I am ready for some other people to look at 
this, if they would like to next week.  Would love to have you guys let me know 
what you think of the decoding & if anything should be changed.

Also, if anyone else has PCAP files with (D)TLS1.3, that will be wonderful.  I 
have only two trace files!   Down the road, I would like to have quite a few 
that are set up.  If you even have debug output with payload, I can use that.  
But, it has to be what actually is sent on the wire.  (Pls let me know if 
questions.)

We have set up a server that we will make available to the entire TLS group 
once the bugs are shaken out.  We will put the various traces on that server so 
that people can see actual packet traffic.  We will also modify the dissectors 
as needed as the spec finalizes.

What I have done for both TLS and DTLS: 

- Client Hello should be good (including Random bytes decoding)
- Server Hello should be good (including Random bytes decoding)
- New Key Share extension added
- New PSK extension added- New Version Negotiation extension added- New cipher 
suites added
- New alert types added

What is left to be done:

- Bug Martin found in TLS1.2 and before for Server Key Share
- I think there may be some problems with some DTLS packets.  Could use some 
help in figuring out exactly what. 
Please let me know unicast if you would like to help.  I am thinking 3 or 4 
people will be good.  The Alpha testing will start Wed. May 18th. 
Please let me know if you want some screen shots of a TLS1.3 Client Hello / 
Server Hello.  I am not able to attach to email. 
Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

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

Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11

[nalini.elkins]

On Mon, Jan 4, 2016 at 7:45 AM,   wrote:
>> Hello All,
>>
>> Please excuse if this topic has been previously discussed.  I have a 
>> question about TCP Keep Alives.
>>
>> Section 5 of draft-ietf-tls-tls13-11 reads:
>>
>> "Three protocols that use the TLS Record Protocol are described in this 
>> document: the TLS Handshake Protocol, the Alert Protocol, and the 
>> application data protocol."
>>
>> Then continues with:
>>
>> "Implementations MUST NOT send record types not defined in this document 
>> unless negotiated by some extension.  If a TLS implementation receives an 
>> unexpected record type, it MUST send an
>> "unexpected_message" alert."
>>
>> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT 
>> TLS Heartbeat).   I take it that this will not work going forth?

>TCP Keep Alive is invisible to the TLS connection.

I see. Then, is it that PACKETS without the TLS record protocol may be sent on 
the TLS connection, but IF the TLS Record protocol IS used, then the record 
types must be one of those described? 

Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to 
TLS?



>  Thanks,
>
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

[TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11

[nalini.elkins]

Hello All,

Please excuse if this topic has been previously discussed.  I have a question 
about TCP Keep Alives.

Section 5 of draft-ietf-tls-tls13-11 reads:

"Three protocols that use the TLS Record Protocol are described in this 
document: the TLS Handshake Protocol, the Alert Protocol, and the application 
data protocol." 

Then continues with:

"Implementations MUST NOT send record types not defined in this document unless 
negotiated by some extension.  If a TLS implementation receives an unexpected 
record type, it MUST send an 
"unexpected_message" alert."

In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS 
Heartbeat).   I take it that this will not work going forth?
 Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

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