IETF Logo Mail Archive

[TLS] TLS 1.3 Application Identifier ?

Pascal Urien <pascal.urien@gmail.com> Wed, 16 July 2014 08:32 UTC

Return-Path: <pascal.urien@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA81B2797 for <tls@ietfa.amsl.com>; Wed, 16 Jul 2014 01:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 x9qCgPr01Nw7 for <tls@ietfa.amsl.com>; Wed, 16 Jul 2014 01:32:32 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132141A036F for <tls@ietf.org>; Wed, 16 Jul 2014 01:32:31 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id e89so446050qgf.17 for <tls@ietf.org>; Wed, 16 Jul 2014 01:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Wn0pupXDJiOYuiZE2D0YReOCXp24MKkSrpCzhqnL3Zk=; b=I/PEzpEUb+tXvmDClIthheSjBuj6UfIS8jmjXWXlx5G/SvgsA4bPSNRJKCVkpymTSo bcmdPEW80oZSuo9G//9HuxZKN9J/w5rtnOG15TflDtpYdVUXThYCh5Lbzf5NeY2Z6i9R AxYnS+9kYkJ1yt/v7gAWzXb1Cg62vxgk6ZtaSXYo9mYdrgXfpDsCPBRui1fAoNv6BB8h 3I4mXuXd06Aoh3PKAlGFsOLmit78COmb7yi/O0mihgkgTgMSXT2OKrkvAyIbc66biWXs otVq4iBRgM5ETy3pkcTEdZ/e0To6WU62q3w6hNFFPMiZDAd1zWw+bGyhNXWGe45I8Axk Sncw==
MIME-Version: 1.0
X-Received: by 10.140.35.232 with SMTP id n95mr41485606qgn.82.1405499551202; Wed, 16 Jul 2014 01:32:31 -0700 (PDT)
Received: by 10.96.194.225 with HTTP; Wed, 16 Jul 2014 01:32:31 -0700 (PDT)
Date: Wed, 16 Jul 2014 10:32:31 +0200
Message-ID: <CAEQGKXRhAh2BvwY0xCCf-BN6kh37_athgYQ+Ha7LJE0DYvSCVg@mail.gmail.com>
From: Pascal Urien <pascal.urien@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c03f347b46d004fe4b5d88"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4fZSpLCCc5qS79bsm2DAHRdfH-M
Subject: [TLS] TLS 1.3 Application Identifier ?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 16 Jul 2014 08:32:33 -0000

Hi All
It seems there is no identifier for the application SDU transported by  TLS
1.3 (which is obviously a transport protocol)

With the legacy TLS, the application is identified by a TCP or UDP port.
Some TLS extensions have been proposed to solve this issue.

What about adding a mandatory application identifier in the client hello
message?.

It could be a two bytes integer (i.e. TCP or UDP port) or something else
such as an application name

A mandatory application identifier in the client hello message avoids
tentative connections to non-available applications. It also could
establish a logical link between client certificate and applications

Regards

Pascal Urien

v2.23.0 | Report a Bug | By Email