Re: [TLS] ticket_lifetime and generic network layer
Mark Dunn <mark.dunn@objectiveintegration.uk> Mon, 13 February 2017 17:30 UTC
Return-Path: <mark.dunn@objectiveintegration.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E81296FC for <tls@ietfa.amsl.com>; Mon, 13 Feb 2017 09:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuFo3ULXtQTK for <tls@ietfa.amsl.com>; Mon, 13 Feb 2017 09:30:25 -0800 (PST)
Received: from mail.objectiveintegration.uk (objectiveintegration.uk [134.213.135.47]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C50129559 for <tls@ietf.org>; Mon, 13 Feb 2017 09:30:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.objectiveintegration.uk (Postfix) with ESMTP id 965C11A02E40 for <tls@ietf.org>; Mon, 13 Feb 2017 17:30:23 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at objectiveintegration.uk
Received: from mail.objectiveintegration.uk ([127.0.0.1]) by localhost (mail.objectiveintegration.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ4rKWGEsfh4 for <tls@ietf.org>; Mon, 13 Feb 2017 17:30:01 +0000 (UTC)
Received: from [192.168.110.205] (host5-81-99-138.range5-81.btcentralplus.com [5.81.99.138]) (Authenticated sender: mark.dunn@objectiveintegration.uk) by mail.objectiveintegration.uk (Postfix) with ESMTPSA id AE5621A01A96 for <tls@ietf.org>; Mon, 13 Feb 2017 17:30:01 +0000 (UTC)
To: tls@ietf.org
References: <000001d282d1$7769bdc0$663d3940$@objectiveintegration.uk> <20170209190530.GA20340@LK-Perkele-V2.elisa-laajakaista.fi>
From: Mark Dunn <mark.dunn@objectiveintegration.uk>
Message-ID: <afc92d03-28cb-96f9-b963-52f5b6e06fbe@objectiveintegration.uk>
Date: Mon, 13 Feb 2017 17:30:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170209190530.GA20340@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------8F51043D1B83AF385CE31064"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gQrek8uJ9sHdwT0kREi3Pw5eEuo>
X-Mailman-Approved-At: Tue, 14 Feb 2017 12:18:55 -0800
Subject: Re: [TLS] ticket_lifetime and generic network layer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 17:30:27 -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. On 09/02/17 19:05, Ilari Liusvaara wrote: > On Thu, Feb 09, 2017 at 12:38:50PM -0000, Mark Dunn wrote: >> 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) > AFAIK, it is arbitrary. However, long validity periods bring security > issues, with having to store and protect symmetric keys for a long > time. If it IS arbitrary, could we have a recommendation rather than a "Servers MUST NOT use any value more than 604800 seconds (7 days)" >> 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 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.
- [TLS] ticket_lifetime and generic network layer Mark Dunn
- Re: [TLS] ticket_lifetime and generic network lay… Ilari Liusvaara
- Re: [TLS] ticket_lifetime and generic network lay… Mark Dunn