[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