IETF Logo Mail Archive

Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS

"Viktor S. Wold Eide" <viktor.s.wold.eide@gmail.com> Thu, 27 August 2015 09:14 UTC

Return-Path: <viktor.s.wold.eide@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 D72DD1A8F3B for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 02:14:42 -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 MCScS6SQo8i8 for <tls@ietfa.amsl.com>; Thu, 27 Aug 2015 02:14:41 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9C91A8AAF for <TLS@ietf.org>; Thu, 27 Aug 2015 02:14:41 -0700 (PDT)
Received: by igui7 with SMTP id i7so56838668igu.1 for <TLS@ietf.org>; Thu, 27 Aug 2015 02:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=oz6I32dNSWcPP/XpXGrQvb0ErFxO4VsYPpFov/td7Qg=; b=Tt0XRuu3ob+aw8O1g7PSvIjfOCGGMDKhUlKVLX6ApqIJbLK8zgWu7RmaKklcvRJ7k2 XJehN9CzBa/qsgI4/q9jhHHs/+3PhyUJwM80vaJpWSEHVctUVuAUon7gEktQF3/vUmIN KMnajyN8vZq2PNkpvTbaevMmmgvOowiYwzA3Ndhh50P6J/I4xWp4QkD/uqrQXqerXUqC 5Uc+qUV5HcafrMDm69aITF27FJF7uMi5FWzqFiAkd+0D0grNe1Pqw/Aru2zmLAg1O+QX z/S02u4IReqHacM4yH1b/i7VvIHGaBQLKEnniAdJkuyKCFAEtfc2IMsodcxBI4lqSPR2 nY0A==
X-Received: by 10.50.93.102 with SMTP id ct6mr8211864igb.75.1440666881006; Thu, 27 Aug 2015 02:14:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.84.68 with HTTP; Thu, 27 Aug 2015 02:14:01 -0700 (PDT)
In-Reply-To: <CABcZeBNP8SZeWWVj4_fGxZm-SvYG-cmtQoJ1xBaLLWsLKsNc4Q@mail.gmail.com>
References: <CAL6x8mchyh2Qpqcd5Rv-rXgZ+1_CAbV7vkib+-yU4DEDFx82Yg@mail.gmail.com> <CABcZeBNP8SZeWWVj4_fGxZm-SvYG-cmtQoJ1xBaLLWsLKsNc4Q@mail.gmail.com>
From: "Viktor S. Wold Eide" <viktor.s.wold.eide@gmail.com>
Date: Thu, 27 Aug 2015 11:14:01 +0200
Message-ID: <CAL6x8mf6f0_RaUhsXh0dWeB0_=XcCdvbechAcd=q_cq95dB_2w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b160275aea3e7051e47658e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cPbH6Pe7e5maD3O7cn-EwYq2AUE>
Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Aug 2015 09:14:43 -0000

On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> TLS 1.3 encrypts both the client's and server's certificates already.
> The server's certificate is secure only against passive attack. The
> client's is encrypted with a key that the client can authenticate as
> belonging to the server.
>
>

It's good to see that both the client's and the server's certificates are
encrypted in TLS 1.3, providing protection against passive eavesdropping.

For some use cases it might be worthwhile to reduce the information made
available to an active attacker also. Are there any suggestions in this
direction for TLS 1.3?

One might think of a multi stage approach, something like:
- Anonymous connection establishment, resulting in a secure channel.
- Authentication by means of group certificate.
- Authentication by means of a host specific certificate.

The purpose of the second step above is to first only provide the group
identity to an active attacker, and then to reveal the host identities
(certificate information) only after group membership has been mutually
authenticated.

Does something like this seem reasonable for TLS 1.3 or are there any other
ways for providing protection of identities against an active attack?

Best regards
Viktor S. Wold Eide

v2.23.0 | Report a Bug | By Email