[TLS] New Draft: Symmetric TLS
Rick van Rein <rick@openfortress.nl> Fri, 11 March 2016 14:36 UTC
Return-Path: <rick@openfortress.nl>
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 B2A9712D7C8 for <tls@ietfa.amsl.com>; Fri, 11 Mar 2016 06:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 CscUr0muQlzT for <tls@ietfa.amsl.com>; Fri, 11 Mar 2016 06:36:25 -0800 (PST)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638E12D767 for <tls@ietf.org>; Fri, 11 Mar 2016 06:35:09 -0800 (PST)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Ueb71s02010HQrX01eb8v6; Fri, 11 Mar 2016 15:35:08 +0100
Message-ID: <56E2D799.4030102@openfortress.nl>
Date: Fri, 11 Mar 2016 15:35:05 +0100
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8QaE42VpYg7k8HBDgvuaWKLHAqo>
Subject: [TLS] New Draft: Symmetric TLS
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: Fri, 11 Mar 2016 14:36:27 -0000
Hello, I wrote a straightforward I-D to permit Symmetric TLS, by which I mean letting go of predefined client/server roles. This is useful if the layers on top and/or below TLS are neutral in this respect. The approach is through a TLS Extension that holds a tie-breaker; both ends send a ClientHello containing such a random value. > Name: draft-vanrein-tls-symmetry > Revision: 01 > Title: Symmetry for Transport Layer Security > Document date: 2016-03-11 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-symmetry-01.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-symmetry/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-symmetry-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-symmetry-01 > > Abstract: > TLS connections can be run over various transports, and can in turn > carry many application protocols. All current transports and at > least some application protocols are capable of running between > symmetric end points, in what could be called peer-to-peer mode, but > the use of TLS introduces a requirement to always assign a client and > server role. This specification defines a TLS Extension to remedy > that stringency of TLS. Cheers, -Rick
- [TLS] New Draft: Symmetric TLS Rick van Rein