Re: [TLS] TLS 1.3 Application Identifier ?

Pascal Urien <pascal.urien@gmail.com> Thu, 17 July 2014 22:09 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 7499A1B2829 for <tls@ietfa.amsl.com>; Thu, 17 Jul 2014 15:09:38 -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 Q0VwGK7twvYK for <tls@ietfa.amsl.com>; Thu, 17 Jul 2014 15:09:36 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6379D1B2807 for <tls@ietf.org>; Thu, 17 Jul 2014 15:09:36 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id r5so2708869qcx.13 for <tls@ietf.org>; Thu, 17 Jul 2014 15:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdM5b0xO0nEQ9xVPJvaG5Gg340LCgExNK6Nxln8xaoU=; b=M1M66FxIIb4BiEKOp7Fw6JKQ0mI0e8mDbj9paaGuvLjaDh1Fn3gPNB/CdcyZlZqTAI OO/rJQmrMPJ6PYmFR/ql/q4Cs8GEiI+3OwbRkxUZb9vKsyQ0gZvpc5Tb5dx8R88H7BMR LLxitko7ZRjI26h7mWdRDt1cY0qkJXGgI6tU0mRCCvr2tuqqhjmX9QRGr/h2cypYQOSU kgDQQNqeKcdzTf5CipyhY2B2nVufiFfzDvasreG3zbYicJ4CDb4uizWVtwEqCA6ZRTS8 o93TnCe8GT3kl5fujLJTlQhQj2uIZr0Z/ead7Ua28spzjqwbA4LwYJqBLjAgZlDGE2Fi sD7w==
MIME-Version: 1.0
X-Received: by 10.224.28.65 with SMTP id l1mr192524qac.87.1405634975583; Thu, 17 Jul 2014 15:09:35 -0700 (PDT)
Received: by 10.96.194.225 with HTTP; Thu, 17 Jul 2014 15:09:35 -0700 (PDT)
In-Reply-To: <CFED4154.45D24%paul@marvell.com>
References: <CAEQGKXRhAh2BvwY0xCCf-BN6kh37_athgYQ+Ha7LJE0DYvSCVg@mail.gmail.com> <CAOhHAXxdDqhKu1+d4EUx-=yyJqDhX7i2sFjGTAqo0FP9ox7KxQ@mail.gmail.com> <CFED4154.45D24%paul@marvell.com>
Date: Fri, 18 Jul 2014 00:09:35 +0200
Message-ID: <CAEQGKXSA5Y=DEWpXXrNhYE8UnrSwen2iqVUSfWNJ3SNfkEuz2A@mail.gmail.com>
From: Pascal Urien <pascal.urien@gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary=001a11c2cd2867559a04fe6ae51c
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/99oYuo-hIb5N-jIQZ-uDiPDa2P4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Thu, 17 Jul 2014 22:09:38 -0000

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>om>:

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