Re: [TLS] TLS 1.3 Application Identifier ?

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 <paul@marvell.com>:

>
> 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 <pascal.urien@gmail.com>
> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
>