Re: [TLS] ALPN concerns

Pascal Urien <pascal.urien@gmail.com> Mon, 09 December 2013 20:39 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 A09021AE0A7 for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 12:39:13 -0800 (PST)
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 Wyc-_fjNMQmt for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 12:39:11 -0800 (PST)
Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 872D31AE07F for <tls@ietf.org>; Mon, 9 Dec 2013 12:39:11 -0800 (PST)
Received: by mail-bk0-f54.google.com with SMTP id v16so1592707bkz.27 for <tls@ietf.org>; Mon, 09 Dec 2013 12:39:05 -0800 (PST)
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=tSxHcOkCPx70KdRnjwhcdTYNXBrNI8Pp6ZQ4Go96X1o=; b=j88u8CEbdwsfj+HEXg1JDIJjWNLKpJy9OlMgDGpVnWGvgbBcMCvmhnmL7WEq4VipF1 h4BthrOiBKM9f8YS6Hm00CB8ISaN+vTV3sqcaK4Z/2mhhcZt8YrTBke61EpJpHvlbsSW RENQCxAfeTvQDqYmuSgo4ubDJZAzGD2b84ulHwE2R7ZeLzGHKcJw40jkIPQqaXz3pPgq 4JO6kvo3zqyrPdAmPlzjxaWSrkv4fjHrVB21RaOPDhJUq16FzcqnhUxaD/H9MBvbJDpX Dx7fh3PjQaIGxmB6SeAoLjyDeAjYysaSEr08FrVof07paeJDujTNU3hFjDp8SRjbCtCG mA0A==
MIME-Version: 1.0
X-Received: by 10.205.68.69 with SMTP id xx5mr1262926bkb.143.1386621545793; Mon, 09 Dec 2013 12:39:05 -0800 (PST)
Received: by 10.204.51.141 with HTTP; Mon, 9 Dec 2013 12:39:05 -0800 (PST)
In-Reply-To: <e343ad5e45ac42ad8114ac4ebc09a1ca@BL2PR03MB194.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAFewVt5K07p4UTzpkaXMxscbUuBo-jNB=VGF_cscGY3ZhPss-Q@mail.gmail.com> <e343ad5e45ac42ad8114ac4ebc09a1ca@BL2PR03MB194.namprd03.prod.outlook.com>
Date: Mon, 09 Dec 2013 21:39:05 +0100
Message-ID: <CAEQGKXSB7XO=HLCcDik6jgaZKC+hdNZVAb7VGdZ-VD_fwpjQ5A@mail.gmail.com>
From: Pascal Urien <pascal.urien@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary="f46d041039d3acfa2c04ed1ffcd4"
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 09 Dec 2013 20:39:13 -0000

Hi all


2013/11/19 Andrei Popov <Andrei.Popov@microsoft.com>

> Hi Brian,
>
> I totally agree that we need to encrypt more information in the TLS
> handshake, including the client cert and the contents of various
> extensions, such as SNI and ALPN. Unfortunately, the only way to make this
> information confidential in the existing versions of TLS is to incur
> additional round-trips (by using renegotiation, or otherwise exchanging
> messages after the TLS handshake is complete). This is one of the reasons
> why the TLS WG is pushing hard to make progress on TLS1.3.
>

Encryption of the client's certificate is possible without renegociation

See
http://tools.ietf.org/id/draft-urien-badra-eap-tls-identity-protection-01.txt

The idea is very simple, just add a key for the client's certificate
encryption such as

  enc-key = PRF(SecurityParameters.master_secret,
                 "client_certificate",
                  SecurityParameters.client-random +
                  SecurityParameters.server-random);

Some slides from the IETF 66th

http://www.ietf.org/proceedings/66/slides/emu-2/sld1.htm

This feature has been implemented and tested with TLS1.0


Regards

Pascal Urien