Re: [TLS] New direction for TLS?

Yoav Nir <ynir.ietf@gmail.com> Fri, 14 February 2020 21:01 UTC

Return-Path: <ynir.ietf@gmail.com>
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 8BF6D1201DE for <tls@ietfa.amsl.com>; Fri, 14 Feb 2020 13:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wjm1SuWZBeek for <tls@ietfa.amsl.com>; Fri, 14 Feb 2020 13:01:27 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4C71200C3 for <tls@ietf.org>; Fri, 14 Feb 2020 13:01:26 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id a6so12213498wme.2 for <tls@ietf.org>; Fri, 14 Feb 2020 13:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zarNP9Orl6u/RR1Lpuug/VVf32lIXGrMszIevbed80E=; b=nUmypx1hcf/a9qLpOEQkNaFhQYJZPaIsGA6ydAMJp87Ux7tjoBIdAste3xqZ5FiGwL ziDgg6jttHkDg2bKM9z6SUX1pn8d33YWLBtmfx/mM8yGex1GxXX8OFwWcFHhoDlc/oLR as64wJpFF/rLgA9yJYZrG+d8sZh8swVwTfL+D/GYdeGo3hWKfS6RdVy52dLMZVOffQL6 3o3MP52Y8K4iaM8opt248wJJ/LReDRZ3KBGhiBFWrYymISsuOeA7qbqwX3KW4VpCg8UH ESJ7ATftgtEY+spfJ9wuX9v2Nz/kCvHT2M7mmLTyNUxx5p+LywcVrFg+hHu2paxQLtoX rA0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zarNP9Orl6u/RR1Lpuug/VVf32lIXGrMszIevbed80E=; b=YSXXV2OuQVdOYzKOqhM1MtbZtTVLZWeUXV3R13wSbBezrtSlavSpFObFUF3KMhL0gM DPEOzNgJyQf6GTkgO8VXDXlBHyVmimA9nWDup+cIRFyXD5DUf+Kv2/Rt8+sK1RZ7v0wF lOXYJcjZeCScqJ/neDUqJdAybGm8RtH25/7l7+X7Z15QcD6rxKEHOLKtwozMQuQbfaW/ zA5DZc+WIy8FZB9HKE7YIndxRpNUXjoFMlHcSTk9wre8O13+N0ly0FDej15/rFchq+OB c3YFZoDVa1wF94KkaAJ+WHrHXHljMFjDWZB46uGp+N0YMKo0DUEQQ8ePsYqDhPLtTMno 3RhQ==
X-Gm-Message-State: APjAAAUb8nXZsJpJQNQ0NJS6sRxaSdXeitcXhSMpLsR9uC7GI3dSxYsO nXEIsnkv74LJABbvfJNTMGk=
X-Google-Smtp-Source: APXvYqwxtfKdqaJOEGaIMxGtq21HyXVI74JmpzcuBKaUMZ9dTFJB6GoR33I/8NCM9xGKy7Ub5tg0bQ==
X-Received: by 2002:a05:600c:2406:: with SMTP id 6mr6522787wmp.30.1581714085364; Fri, 14 Feb 2020 13:01:25 -0800 (PST)
Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r6sm8676687wrq.92.2020.02.14.13.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Feb 2020 13:01:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20200214200306.GA27885@akamai.com>
Date: Fri, 14 Feb 2020 23:01:22 +0200
Cc: Michael D'Errico <mike-list@pobox.com>, tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <81B6235D-EC94-4477-890C-D51D0EBEF5BE@gmail.com>
References: <c8452bf3-54ed-475e-8040-b3cd520b609e@www.fastmail.com> <20200214200306.GA27885@akamai.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ILb5xMu0tKY4S67woNHsz9SkJcI>
Subject: Re: [TLS] New direction for TLS?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Feb 2020 21:01:30 -0000


> On 14 Feb 2020, at 22:03, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> Hi Mike,
> 
> On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote:
>> Hi,
>> 
>> It's been a long time since I posted to this list but saw that the charter is being updated and wanted to share an idea I had a while ago but have not found the time to work on.  The TL;DR is to deprecate TLS and rebuild security on top of DTLS. With DTLS, you have encrypted packets, so think of them as the new IP and build TCP on top of that.  It'd be like making the internet run on TCP/DTLS instead of TCP/IP, so most of the work is already done.  I think this is all I need to say to get the idea across, but I can add detail if needed.
> 
> This sounds really similar to QUIC

If it’s TCP (rather than HTTP) on top of the encryption layer, it sounds more like transport-mode IPsec. That gives you encrypted packets.

The difference is whether the authentication and encryption is part of the service provided by the OS (like IP) or part of the application.

Yoav