Subject: [TLS] TLS 1.3 Application Identifier ?

From: Pascal Urien <[email-masked]>
Date: Wed, 16 Jul 2014 10:32:31 +0200

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

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 16 Jul 2014 10:17:09 +0100

>Some TLS extensions have been proposed to solve this issue.

Perhaps I am misunderstanding: are you not describing ALPN? It seems what you want is an ALPN identifier for your protocol, am I correct?

ALPN seems to be proposed as the preferred way to do this for 1.3, is my understanding.

There are obvious metadata concerns involving an untrusted intermediary identifying and demultiplexing different applications transported over TLS (current ALPN is plaintext) and ways to address this are being explored by the WG (although this has tension with those who run large-scale traffic balancers which would prefer to avoid doing crypto for both scale and key security reasons; I'm not sure that can be cleanly resolved in a privacy-preserving manner which satisfies everyone).

- --
/akr

---

From: Pascal Urien <[email-masked]>
Date: Wed, 16 Jul 2014 15:32:09 +0200

It could be  like ALPN

But ALPN is an extension from previous versions of TLS, and is not mandatory

Pascal

2014-07-16 11:17 GMT+02:00 Alyssa Rowan <[email-masked]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Perhaps I am misunderstanding: are you not describing ALPN? It seems what
> you want is an ALPN identifier for your protocol, am I correct?
>
> There are obvious metadata concerns involving an untrusted intermediary
> identifying and demultiplexing different applications transported over TLS
> (current ALPN is plaintext) and ways to address this are being explored by
> the WG (although this has tension with those who run large-scale traffic
> balancers which would prefer to avoid doing crypto for both scale and key
> security reasons; I'm not sure that can be cleanly resolved in a
> privacy-preserving manner which satisfies everyone).
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQI3BAEBCgAhBQJTxkMVGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
> jtkWi2t6KOoP/jnvQ4WhOW1/1U1AeFn8p/y3qlaBEelH04jasu3PClTNk8c2ddGx
> ICv6rE1rv8xIA6m1LrqG5kUVqctnUq2JuH6G6FRg2cu8N7QkImaIIZXZzgpmIXmW
> wVTCQ+RN4kmpsYMwdd+ZcwHVORbu09lnG9MI+Bt3Ybv2ck1NLjVz5+o0Iai6HOwu
> S0zMl8cjB2husFluuUUkt4Rk56l415hQf8VF4I4zHkIYcx5b5DHBrZRD+COCCuKO
> kqzeDSl09HVAGYQfkf1WzubUpq501mi39uHvFAY/NYrY51/e6g0fDQavd795bxXT
> rldVix9o8Y6CXSBkK/aKTMgvhoa5GCiBRE3zOAYuSZbpvTUbWwLFDHASkasnQCo1
> yyDgGJXuY8P0dWMKQ0ufOmJ7AgLJnp8EaqjWY1BXAticEPPhQYAtY9oMriuyzd2p
> rw7HkHmIwpCb0Cqu705jFSY+x0F3R+QvhDdGg2jHQIxCUF+2L81oD4n/ekqRZK/n
> B1CkATZoxq4mLHS7rPDLU9HNqRHbhkkUSFmpiE+4KIIarNRfUp+tJzZtAvazo5hw
> iDY+IvQ8mWpUCvvL95LwSSWE4D4PPDMCltcT/6HSBT1080BtaU+r+5HeSAaQRsSq
> 94EtgkuczqRbQjvvgc1nqe11ZK3MZx+RQI9+Qu3r1i3151yV/qPczonh
> =x0a+
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 09:25:39 -0700

> But ALPN is an extension from previous versions of TLS, and is not mandatory

How is that a problem?  If you need the functionality, then
implementing ALPN is not especially onerous.  Actually, I can only
think of negative characteristics of having it be mandatory.

---

From: Pascal Urien <[email-masked]>
Date: Wed, 16 Jul 2014 21:21:56 +0200

For me TLS is a transport layer

UDP or TCP are transport layers. They identify the transported apps pdu by
a port number

Without a mandatory application identifier the TLS 1.3 will not give by
default any information on the transported application

I believe that a client certificate should be bound to an application.

If no application identifier is available the client could set it to null.

Regards
Pascal

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 16 Jul 2014 22:49:41 +0300

On 16.7.2014, at 22.21, Pascal Urien <[email-masked]> wrote:
> UDP or TCP are transport layers. They identify the transported apps pdu by a port number

I'm a bit lost here, as far as I know TLS always works on top of UDP or TCP, and therefore the port numbers identifying transported apps apply there as well.

> Without a mandatory application identifier the TLS 1.3 will not give by default any information on the transported application

It does give information with either the port number, and if e.g. 443 is always used for firewall compatibility, then ALPN works.

> I believe that a client certificate should be bound to an application.

Can you give some specific reasoning for this? I don't see anything forbidding certificate selection based on ALPN either. Or you can run TLS in different TCP ports for different applications.

> If no application identifier is available the client could set it to null.

Or it could simply not send the ALPN extension.

Juho

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 17 Jul 2014 01:37:22 +0400

Hi Pascal
You may have a look at the following document:
http://tools.ietf.org/html/draft-badra-tls-multiplexing-01
Or
http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06

Best regards
Badra

On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <[email-masked]>
wrote:

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

---

From: Pascal Urien <[email-masked]>
Date: Thu, 17 Jul 2014 00:02:59 +0200

I believe that TLS 1.3 should work for the next 20 years, in ecosystems
such as IoT or others

And so for future framework, no mandatory means to identify the transported
applications ?. No relationships between certificates and applications ?

TLS 1.3 should be just a security layer, with no links with transported
apps ?

Pascal

2014-07-16 21:49 GMT+02:00 Juho Vähä-Herttua <[email-masked]>:

> I'm a bit lost here, as far as I know TLS always works on top of UDP or
> TCP, and therefore the port numbers identifying transported apps apply
> there as well.
>
> It does give information with either the port number, and if e.g. 443 is
> always used for firewall compatibility, then ALPN works.
>
> Can you give some specific reasoning for this? I don't see anything
> forbidding certificate selection based on ALPN either. Or you can run TLS
> in different TCP ports for different applications.
>

---

From: Peter Bowen <[email-masked]>
Date: Wed, 16 Jul 2014 18:30:45 -0700

> applications ?. No relationships between certificates and applications ?

TLS does not require certificates, so that it out of scope.  There are
existing RFCs that cover including service information in
certificates, such as RFC 4985 (http://tools.ietf.org/html/rfc4985).
I suspect that this will cover the use case you are discussing.

Thanks,
Peter

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jul 2014 04:46:46 +0200 (CEST)

> I believe that TLS 1.3 should work for the next 20 years, in ecosystems

Considering the number of tentative changes from TLSv1.2 to TLSv1.3 so far,
I considert it extremely likely that TLSv1.2 will be with us in 20 years...

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Jul 2014 20:31:59 -0700

And if there were zero changes beyond those necessary to deal with
Triple Handshake, removal of weak ciphersuites, and 1RTT this would be
different why?

Furthermore, it's clear that the complexity of TLS doesn't solve the
real problem of user (or mutual) authentication that is deployable.
Interoperation with X509 makes authentication hard, which is why it is
rarely done.

Sincerely,
Watson Ladd

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

---

From: Paul Lambert <[email-masked]>
Date: Thu, 17 Jul 2014 09:05:29 -0700

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

Best regards
Badra

On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Pascal Urien <[email-masked]>
Date: Fri, 18 Jul 2014 00:09:35 +0200

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 <[email-masked]>:

>
> 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).

---

From: Watson Ladd <[email-masked]>
Date: Thu, 17 Jul 2014 20:32:45 -0700

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 <[email-masked]> wrote:
>>> tentative connections to non-available applications. It also could establish
>>> a logical link between client certificate and applications
>>>
>>> Regards
>>>
>>> Pascal Urien
>>>
>>>
>>>

---

From: Pascal Urien <[email-masked]>
Date: Fri, 18 Jul 2014 10:00:57 +0200

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

 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…

Regards
Pascal

2014-07-18 5:32 GMT+02:00 Watson Ladd <[email-masked]>:

> establish

---

From: Alfredo Pironti <[email-masked]>
Date: Fri, 18 Jul 2014 10:07:29 +0200

On Fri, Jul 18, 2014 at 10:00 AM, Pascal Urien <[email-masked]>
wrote:

>  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.
>

That would be too early. Although Finished messages are encrypted, by the
time they're sent the encryption keys are not confirmed yet. Indeed, the
Finished message content (verify data) is the way keys get confirmed.
Hence, in TLS 1.2 you'd need another round trip, or give up the secrecy of
such information. This has been thoroughly discussed in the ALPN vs NPN
thread.

Best,
Alfredo

>> >> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <[email-masked]
>> >
>> >> wrote:
>> >>>
>> >>> Hi All
>> >>>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 18 Jul 2014 13:47:28 -0700

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.

Paul

 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.

Regards
Pascal

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

On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien <[email-masked]<mailto:[email-masked]>> wrote:
> 2014-07-17 18:05 GMT+02:00 Paul Lambert <[email-masked]<mailto:[email-masked]>>:
>
>>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 21 Jul 2014 16:41:17 -0700

]-----Original Message-----
]From: Watson Ladd [mailto:[email-masked]]
]Sent: Thursday, July 17, 2014 8:33 PM
]To: Pascal Urien
]Cc: Paul Lambert; [email-masked]
]Subject: Re: [TLS] TLS 1.3 Application Identifier ?
]
]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?

ALPN requires IANA registration of 'applications' (negative from my perspective)
Registration also exposes the applications allowing some servers to be discriminated
against based on applications served.

Paul

]
]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 <[email-masked]>
]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 <[email-masked]>:
]>
]>>
]>> 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:
]>> http://tools.ietf.org/html/draft-badra-tls-multiplexing-01
]>> Or
]>> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06
]>>
]>> Best regards
]>> Badra
]>>
]>>
]>> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien
]>> <[email-masked]>
]>> 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
]>>> [email-masked]
]>>> https://www.ietf.org/mailman/listinfo/tls
]>>>
]>>
]>>
]>>
]>
]>
]> _______________________________________________
]> TLS mailing list
]> [email-masked]
]> https://www.ietf.org/mailman/listinfo/tls
]>
]
]
]
]--
]"Those who would give up Essential Liberty to purchase a little
]Temporary Safety deserve neither  Liberty nor Safety."
]-- Benjamin Franklin