Re: [TLS] TLS 1.3 Application Identifier ?

Paul Lambert <paul@marvell.com> Mon, 21 July 2014 23:41 UTC

Return-Path: <paul@marvell.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 90EAE1A028A for <tls@ietfa.amsl.com>; Mon, 21 Jul 2014 16:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 cyZpg9Kje8Zk for <tls@ietfa.amsl.com>; Mon, 21 Jul 2014 16:41:24 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF161A0282 for <tls@ietf.org>; Mon, 21 Jul 2014 16:41:24 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6LNeSbU031680; Mon, 21 Jul 2014 16:41:23 -0700
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1n8ud7k7dv-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Jul 2014 16:41:23 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 21 Jul 2014 16:41:23 -0700
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>, Pascal Urien <pascal.urien@gmail.com>
Date: Mon, 21 Jul 2014 16:41:17 -0700
Thread-Topic: [TLS] TLS 1.3 Application Identifier ?
Thread-Index: Ac+iOPI4iF58g0r+S8+5Wj0XkPNBcQDA7aSA
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C3D@SC-VEXCH2.marvell.com>
References: <CAEQGKXRhAh2BvwY0xCCf-BN6kh37_athgYQ+Ha7LJE0DYvSCVg@mail.gmail.com> <CAOhHAXxdDqhKu1+d4EUx-=yyJqDhX7i2sFjGTAqo0FP9ox7KxQ@mail.gmail.com> <CFED4154.45D24%paul@marvell.com> <CAEQGKXSA5Y=DEWpXXrNhYE8UnrSwen2iqVUSfWNJ3SNfkEuz2A@mail.gmail.com> <CACsn0cmigM1Y603SNdWah1g7H0kGnmRtB7T+Nhx_aYHPAe2trw@mail.gmail.com>
In-Reply-To: <CACsn0cmigM1Y603SNdWah1g7H0kGnmRtB7T+Nhx_aYHPAe2trw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-20_03:2014-07-18,2014-07-20,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-1407210273
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lt1lAfgdNxmaElwr3IFmQrJ2nag
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: Mon, 21 Jul 2014 23:41:26 -0000


]-----Original Message-----
]From: Watson Ladd [mailto:watsonbladd@gmail.com]
]Sent: Thursday, July 17, 2014 8:33 PM
]To: Pascal Urien
]Cc: Paul Lambert; tls@ietf.org
]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 <pascal.urien@gmail.com>
]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 <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
]>>>
]>>
]>>
]>>
]>
]>
]> _______________________________________________
]> TLS mailing list
]> TLS@ietf.org
]> 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