Re: [TLS] TLS 1.3 Application Identifier ?

Paul Lambert <> Fri, 18 July 2014 20:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C0BB1A020A for <>; Fri, 18 Jul 2014 13:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2rIFb4IaUWCY for <>; Fri, 18 Jul 2014 13:47:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DC031A0065 for <>; Fri, 18 Jul 2014 13:47:45 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.5/8.14.5) with SMTP id s6IKkf3C019766; Fri, 18 Jul 2014 13:47:44 -0700
Received: from ([]) by with ESMTP id 1n6q3fkby6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Jul 2014 13:47:43 -0700
Received: from ([]) by ([::1]) with mapi; Fri, 18 Jul 2014 13:47:31 -0700
From: Paul Lambert <>
To: Pascal Urien <>, Watson Ladd <>
Date: Fri, 18 Jul 2014 13:47:28 -0700
Thread-Topic: [TLS] TLS 1.3 Application Identifier ?
Thread-Index: Ac+iyX3EonXbzhFWQNWui8zAR2ihog==
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CFEED3C846346paulmarvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-18_05:2014-07-18,2014-07-18,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407180243
Cc: "" <>
Subject: Re: [TLS] TLS 1.3 Application Identifier ?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Jul 2014 20:47:47 -0000

Hi  Alll
According to TLS1.3 “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications”

 In my mind an application identifier identifies the application SDU transported by TLS 1.3.  An application identifier could a be a name or a hash value of an application name

Yes – as mentioned before, for wireless application/service discovery we are pursuing hash values as identifiers.  These enable large numbers of applications without a registry.  They also offer some small measure of privacy since the identifiers are not registered and the small size (6 octets) is somewhat ambiguous.   The truncated hash also provides some  compression (over string based names).

Hash based “service identifiers" are also framework neutral – the “service name” can be Bonjour, DLNA/UPnP or any other name space.  Identifiers may also be explicitly obscured by including a shared key with the service name in the hashing process.

Hash identifiers could also map into a bloom filter based representation if you have relatively large numbers of services.


 At the beginning SSL was designed to secure HTTP, and used the 443 port, HTTP was implicitly the application. Many internet applications used a TCP/UDP port as application identifier with SSL/TLS

 With ALPN the client used an extension that contains several applications name (such as "http/1.1", "spdy/1"), and the server selects one of them. So ALPN realizes two things, it identifies application, and the server selects of them. ALPN in not mandatory anyway.

 For future use of TLS1.3 I believe that application identification and selection is important.

Why not a list of application identifiers in the server finished message…

And the selected application identifier in the client finished message…


2014-07-18 5:32 GMT+02:00 Watson Ladd <<>>:
What do you mean by "application identifier"? Is http enough, or
should it be the application on top of http?

What do you need it for? Why does it need to be manadatory: why not
require clients to use ALPN?

If you want to link the client cert to application (what does that
mean?) why can't the ChannelID draft serve your purposes?

On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien <<>> wrote:
> Hi All
> Finished messages are encrypted. That are produced first by server and
> second by client.
> The today semantic (TLS1.3) of these messages is server finished and client
> finished (a cryptographic proof of the knowledge of secrets)
> They could be used also to transport protected application identifiers for
> both server and client ?!
> Regards
> Pascal
> 2014-07-17 18:05 GMT+02:00 Paul Lambert <<>>:
>> It may or may not map well into TLS, but in other forums, we’re using a 6
>> octet identifier to describe services (aka applications).
>> It’s formed as a truncated hash of a “service name”
>>        serviceId = SHA256( serviceName )[0:6]
>> It can also be obscured by concatenating the Service Name with a key
>> before creating the identifier.
>> Paul
>> Hi Pascal
>> You may have a look at the following document:
>> Or
>> Best regards
>> Badra
>> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <<>>
>> wrote:
>>> 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
>>> _______________________________________________
>>> TLS mailing list
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin