Re: [TLS] TLS 1.3 Application Identifier ?

Alfredo Pironti <alfredo@pironti.eu> Fri, 18 July 2014 08:07 UTC

Return-Path: <alfredo@pironti.eu>
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 670381A00DE for <tls@ietfa.amsl.com>; Fri, 18 Jul 2014 01:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 AtacTmWbSPNb for <tls@ietfa.amsl.com>; Fri, 18 Jul 2014 01:07:31 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0284C1A00D2 for <tls@ietf.org>; Fri, 18 Jul 2014 01:07:30 -0700 (PDT)
Received: by mail-oi0-f53.google.com with SMTP id e131so1750383oig.40 for <tls@ietf.org>; Fri, 18 Jul 2014 01:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lzyb2ySqU+4o7Owlte2RUjPDVahNb/Dk6Wl3eL9nd8U=; b=BzUf3R9yAS3pAstgYoqlVSA+q5V/oScGQWLCrJLKsHVt1Cfby1t8QPKge3XD/FtPe2 jE+wLJZWa2gSbBeEL80L3Id/fzIWdTCKrdkxE/D79SnP6xGnaM22I1iak26zadqymZvb CSvRfXzKtg0/w8Kofcl7avXdcNIt5ZcguVV4k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lzyb2ySqU+4o7Owlte2RUjPDVahNb/Dk6Wl3eL9nd8U=; b=G4GB+XNvKpDS43QiFuQ9ujPSKVoQ213IrfycjBupVwibUaggRwMqUYl8QlpxaeZZtZ tpC/036hbUG2pxMqOwDFiTTq6atMiuRXpEYgIPeej6yP2C4nBuwsHGgKYBDXGmxQ79aO snSbapHH7ZNdmYSaawzdVJFp+dGhIV2TTm2Cm1dudcFVJXnwLq3YZ8Ne3Pc+srpARTm7 KLguPCgrBMolhlrifSVZUEj3etDA+fVaEybwPIWh8El+U50itm8/oyiFMzHhyLEr+uEu nr4cOy2tGTjkoXTSWarHbrdaC/osddCGi/TC/Xt/sZTvKBCPKjv4W+mRjHI+jKtXprN2 VR9Q==
X-Gm-Message-State: ALoCoQm0AerBoWbZSNpnQDsmqkM4FZ6yl4H/bnHzvda8tEFgR85IJ7iad0si+9AfpZg9KjyPaKGE
MIME-Version: 1.0
X-Received: by 10.182.211.16 with SMTP id my16mr3957938obc.43.1405670850046; Fri, 18 Jul 2014 01:07:30 -0700 (PDT)
Received: by 10.76.25.42 with HTTP; Fri, 18 Jul 2014 01:07:29 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <CAEQGKXTcqaRR0qkYVNiUGxwastr5Sq3VXe4_C5qrgwJJsWZiYg@mail.gmail.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> <CAEQGKXTcqaRR0qkYVNiUGxwastr5Sq3VXe4_C5qrgwJJsWZiYg@mail.gmail.com>
Date: Fri, 18 Jul 2014 10:07:29 +0200
Message-ID: <CALR0uiL4+XpuH4tCa63Ho2ca--zb+5RyrsVXhmDzM6AebSHVoA@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Pascal Urien <pascal.urien@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f83a985b0424304fe733f84
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K_uZ3euPynC-3J8H_3txTIe5IpM
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: Fri, 18 Jul 2014 08:07:36 -0000

On Fri, Jul 18, 2014 at 10:00 AM, Pascal Urien <pascal.urien@gmail.com>
wrote:

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

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


>
> Regards
> Pascal
>
>
>
> 2014-07-18 5:32 GMT+02:00 Watson Ladd <watsonbladd@gmail.com>om>:
>
> 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 <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
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>