Re: [TLS] Refactoring client auth/re-key

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Sun, 19 October 2014 06:57 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
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 334761A1BF8 for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 23:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Sb13sl5m_S2t for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 23:57:29 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9301F1A1BF7 for <tls@ietf.org>; Sat, 18 Oct 2014 23:57:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,749,1406584800"; d="asc'?scan'208,217";a="83795060"
Received: from 244.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.244]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 19 Oct 2014 08:57:25 +0200
Content-Type: multipart/signed; boundary="Apple-Mail=_201C1A0C-5812-4D8B-B8C2-81E456E60267"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <CABcZeBMxw3Oz1U-6GeTAuUJ1bZbBYhRWsQgscrHFLcTHh=_H1g@mail.gmail.com>
Date: Sun, 19 Oct 2014 08:57:25 +0200
Message-Id: <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr>
References: <CABcZeBOdpK_JEH4EwnsoTA8Rje5pS5CtSbFGh8rHQzse92m9Wg@mail.gmail.com> <CACsn0cmYs8TMeKcTvqxv1DUGizcp5k7uo86muoqYbGRH4xDQHA@mail.gmail.com> <CABcZeBMxw3Oz1U-6GeTAuUJ1bZbBYhRWsQgscrHFLcTHh=_H1g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gXzkdb4HMxRyIPGwgnokDEU4DDI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring client auth/re-key
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: Sun, 19 Oct 2014 06:57:32 -0000

> So I seem to remember DJB telling me that once you have a properly
> made channel via Diffie-Hellman, that authenticating requires just
> signing a value derived from the key. (Sadly I forgot/don't know the
> proof, so someone will have to check this or tell me I'm completely
> wrong) So we don't need the session hash to include the certificates,
> and so don't need to keep the running hash going past the first
> exchange.

At least one form of this construction (as used in IKEv2) is well-explained 
and proved in the original SIGMA paper:
http://www.iacr.org/cryptodb/data/paper.php?pubkey=1495


> Trying to think through this a bit, is this a generic comment on the
> session-hash proposal even for TLS 1.2 where they are careful to
> sign everything up to CertificateVerify? See:

As Ilari hints, it is not enough to hash the client-server key shares into
the master secret. In a negotiated protocol like TLS, we need to add
the DH parameters, the algorithms used to derive the keys, and the
algorithms that the resulting key will be used with. (The crypto proofs
typically fix these values and so they don’t necessarily appear in the
academic protocols.)

For session hash in TLS 1.2, the log up to ClientKeyExchange contains
all this data, and we need to hash at least the Hellos and the KeyExchanges.
So even if the client and server are anonymous the session hash context binds the master secret.

One may argue that the client and server authenticated identities (Certificates) do not
need to be included in the session hash. This would be true for the initial handshake,
but not for resumption. One use of the TLS 1.2 master secret is as a key for session
resumption, and the Triple Handshake attack relies on the master secret not being
bound to the peer’s identity. 

For TLS 1.3, I need to stare about the Update protocol a bit more, but I think authentication
after an initial DH handshake could be made safe (a la SSH and IKEv2). That is,
the first master secret hashes the keyshares, and the second master secret/connection key
hashes in the identities. 

The question that bothers me is which key/master secret would we use for session resumption? If it is the initial (unauthenticated) master secret, I think there will be attacks. 
If we only allow the last (authenticated) master secret to be resumed, we would probably
recover the guarantees of session hash. 




> 
> https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1
> 
> Perhaps one of the authors of that document can weigh in here.
> 
> Best,
> -Ekr
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls