Subject: [TLS] ticket_lifetime and generic network layer

From: "Mark Dunn" <[email-masked]>
Date: Thu, 9 Feb 2017 12:38:50 -0000

I am reading your TLS 3.1 Standard and the mailing list.

It looks great. 

I am particularly interested in using the 0-RTT feature for IoT timestamped
data, which would seem immune from replay attacks

I have a couple of questions

1) The maximum ticket lifetime is set to 7 days. Is this based on hard
science or arbitrary?

If it is arbitrary then 8 days for weekly intervals or 32 for days for
monthly intervals would  make better commercial sense

               (allowing for variability in wake-up times for constrained
devices)

2) Have you considered using TLS for a generic network layer?

               I am thinking along the lines of a protocol like geneve
(https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/ )

Use cases would be

               Insert TLS 1.3 between the physical layer and the MAC (data
link) layer

               For WAN and WWAN devices

               Insert TLS 1.3 between the MAC layer and IP layer or
IP/TLS/VXLAN/IP

               Use any of your favourite virtualisation protocols here.

               For securing virtual networks

               Insert TLS 1.3 between IP layer and UDP/TCP layers 

For securing  legacy network applications (SIP, RTP and RTCP for example)

It looks, from my point of view, that a small addition  could transform this
protocol from an application oriented

security mechanism, into a general internet workhorse. Providing a simpler
solution for both the IoT and Cloud

Other protocols call this 

               Protocol (IPv4)

               Next Header (IPv6)

               Ethertype (Ethernet)

And then you would also need to register this generic TLS 1.3 protocol with
Iana to register your own protocol Id

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 9 Feb 2017 21:05:30 +0200

>                (allowing for variability in wake-up times for constrained

AFAIK, it is arbitrary. However, long validity periods bring security
issues, with having to store and protect symmetric keys for a long
time.

> 2) Have you considered using TLS for a generic network layer?

Note that TLS requires in-order reliable delivery (DTLS doesn't, but
DTLS 1.3 is currently just handwaving), and neither is available below
transport layer.

-Ilari

---

From: Mark Dunn <[email-masked]>
Date: Mon, 13 Feb 2017 17:30:01 +0000

Thanks for taking the time to read and respond to my queries, my 
understanding of this protocol is incomplete, but I am working hard to 
remedy that.

> issues, with having to store and protect symmetric keys for a long
If it IS arbitrary, could we have a recommendation rather than a

"Servers MUST NOT use any value more than 604800 seconds (7 days)"
> DTLS 1.3 is currently just handwaving), and neither is available below

Yes DTLS, of course you are correct. I will try and rephrase my questions.

I understand "TLS 1.3 requires in-order reliable delivery", but of 
course, if the protocol relies on in-order reliable data delivery then 
it cannot be secure.
The protocol must assume the opposite in fact, that an attacker will 
break boththose requirements in every way possible.
As the TLS 1.3 protocol seems to have been tested(designed) against a 
formal state machine then clearly someone agrees with me.

If the protocol's responsibility is to secure the application data from 
the insecure world of the Internet

Application | TLS :| TCP | IP | 
<-------------------------------------------> | IP | TCP |: TLS | 
Application
\----------------------------------\/---------------------------------/
                                                 Insecure Internet

then the protocol cannot rely on the TCP handshake, neither can it rely 
on TCP's packet ordering. It would seem TCP is largely redundant as IP 
does the fragmentation and re-assembly.
TCP's only role seems to be to hold open the NAT on a firewall!

Which is why when I look at this protocol, I overlook the ordered data 
in-session ability of TLS ( /head/-of-line blocking.. blah, blah)and in 
my blinkered view see the resumption/0-RTT ability as DTLS.
Any protocol which uses IP directly (including TCP) is responsible for 
reliable data delivery whether it is as simple as an ack/nack/retry or 
uses the sophisticated windowing etc. of TCP.
If these protocols sat on (D)TLS then each of these protocols would 
drive their reliable delivery through the TLS state machine. *(this is 
exciting)*

So, for example if TCP relied on TLS instead of the other way around 
then TCP would be protected under TLS's umbrella of security.

Application | TCP | TLS | IP | 
<-------------------------------------------> | IP |: TLS | TCP | 
Application
\----------------------------\/---------------------------/
                                                 Insecure Internet

TCP's sliding window would work, but the syn/syn-ack/ack handshake would 
be sub-optimal again as early data is not available during authentication.
(D)TLS key changes look like they would happen seamlesslyunderneath.

For the Machine to Machine (or Internet of Things) world however, things 
look much rosier (to me) as "Machines Don't Browse!".
Once the server/client authentication handshake is complete:

1) is it possible to use"resumption" as a three way handshake to 
securely deliver a single packet
2) Is it possible to use "0-RTT" as a mechanism to deliver a single 
packet (if slightly less securely)

Thinking this through (slightly) more carefully now, It would not be 
possible to place (D)TLS between the IP layer and Ethernet Layer as 
Ethernet does not have fragmentationand re-assembly
3) Do you agreethat securing virtualisation with (D)TLS should be 
possible (Application / TCP / IP / VXLAN / (D)TLS / IP)
4) Do you think wireless protocols are candidates as many wireless 
protocols have small packets and perform fragmentation/re-assembly.