[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

[TLS] Minimal API for the basic (D)TLS operation? (concerns draft-ietf-taps-transports-usage)

[Naeem Khademi]

Hi

I am writing this as one of the authors of the
draft-ietf-taps-transports-usage and as a result of our WG discussions
during the TAPS meeting in Buenos Aires. This draft tries to derive a list
of transport service features and primitives (function-calls) provided by
the transport protocols to the application. This is an initial milestone
for building a TAPS system. It proposes a 3-pass process as a systematic
way to derive the primitives and transport service features based on the
IETF-based (abstract) APIs of transport protocols that are currently
covered by the draft.

   - The draft can be found here (currently covering TCP and SCTP only):
   https://tools.ietf.org/html/draft-ietf-taps-transports-usage-00
   - A companion draft covering UDP/UDP-Lite (to be merged with above draft
   eventually):
   https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-01

The WG’s plan is to have (D)TLS included, initially as an independent draft
which applies the same exact process (Appendix B of
draft-ietf-taps-transports-usage-00) and eventually merging into our draft
as it matures. However we have some questions with regards to this:



*A) Is there a definition of minimal API available that covers the basic
operation? B) If not, is there enough energy in the WG(s) (UTA, TLS) to
define such an API? *

To clarify: we would like to make our lives easier by being able to just
say that (D)TLS can run OVER our TAPS system - but then it may make sense
to layer (D)TLS under a transport that we would base the TAPS system on, so
this is why things get a bit more complicated here.

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