Re: [TLS] WGLC for draft-ietf-tls-cached-info-19

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Wed, 16 September 2015 03:12 UTC

Return-Path: <karthik.bhargavan@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 3C1131B3231 for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 20:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 sFKruLeYz4BD for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 20:12:06 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 8BE7A1B322B for <tls@ietf.org>; Tue, 15 Sep 2015 20:12:06 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so51453033wic.0 for <tls@ietf.org>; Tue, 15 Sep 2015 20:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KsfdIUTX7QgT8SEvBfyooxgYED4AneuRRAD5C1bN/zY=; b=qyA1iL2ePxdAQlIEJzygKmHqnJmQqzphU2CJFmn4HfoolaKAaEwXJ++Dy0/jltNDhE /ws/qqBqOdI6ykNSqlynwmUUYDTL+92Q2xdw1lj48VaNHwOjNkG/eHizOYJzSNUHdC5Q Q6bEZXva5L2FkpnU1Bhr6qDQRv4wD+IigZDvxXeP38qRQaRsTK0dflTpwtRvVXs0sWa5 gHzgN6GVZNHE81B7bo4Q+2Me1xL2XafencYCJ+AVRCZBzLouP7Q1T+kiw+/Ag+B6Ybj+ rFMdMThxH49UxwuLsORRfVfkCFWPw7+uMjOJCxn/P4KpWvluM/JugBcSzqbpjUdYYxzG FUUA==
X-Received: by 10.180.187.180 with SMTP id ft20mr13758392wic.78.1442373125195; Tue, 15 Sep 2015 20:12:05 -0700 (PDT)
Received: from [192.168.1.44] (149.92.69.86.rev.sfr.net. [86.69.92.149]) by smtp.gmail.com with ESMTPSA id go2sm1989143wib.20.2015.09.15.20.12.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Sep 2015 20:12:04 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <CABkgnnWgZH_RQr8GLOr=P8EzL+CL=pQcOHTOGFymPguGj8KOHg@mail.gmail.com>
Date: Wed, 16 Sep 2015 05:12:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEE86247-BD9E-460E-ADE9-E611F8164614@gmail.com>
References: <CAOgPGoBivgXGKpZH=4mSkrVaKyg9YPi05rphs3VOcvuiFfPzrg@mail.gmail.com> <CABkgnnU++z-r3m2p-+k-6i8BwE5o9wXULS0RVJfCG1+nmkY13Q@mail.gmail.com> <55DB489C.80505@gmx.net> <CABkgnnWXsieUibqFwa_ugm==Vw+5zYpkH6nersxJVvURqf475A@mail.gmail.com> <55F1662C.5050209@gmx.net> <CABkgnnU_r=CmNuaX8kOoxYPoBJ052=4Df88yLb5xxVp4zgRjGw@mail.gmail.com> <CABcZeBP-xGLkMDewK47AVPGqdvzoamQ8R+dj+1=HXF2u-GDMSA@mail.gmail.com> <CABkgnnWTN7bR+jGbSirpqgwa3o+juCBJ60ea=z2jYffnwm7o0w@mail.gmail.com> <CABkgnnWgZH_RQr8GLOr=P8EzL+CL=pQcOHTOGFymPguGj8KOHg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mu67tIiDaCQJYwHaf4JpeG3qYf0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19
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: Wed, 16 Sep 2015 03:12:08 -0000

> Sam just ran the analysis.  The TLS 1.3 proofs they have work without
> Certificate in the transcript, which is equivalent to a zero-bit
> truncated hash.

I assume the client hello extension still has the certificate digest, yes?
This means that the analysis probably relied on agreement of the certificate hash from the client hello.

I’d imagine that a full security analysis of this mode depends on which model of certificate issuance  we use.
For example, is it possible for a website to use the same public key on two certificates for two different purposes? Is it possible for an attacker to obtain a certificate from a CA for a public key even though it does not know the corresponding private key? 

Also, is this mode intended to be used for RSA handshakes in TLS 1.2? In that case the proof of private-key possession comes quite late in the handshake. Even for signature-based ciphersuites, I would need to look
closer to be convinced that the ServerKeyExchange (in TLS 1.2) and ServerCertificateVerify (in TLS 1.3) do 
provide sufficient guarantees on which certificate/private key was used to create the signature.

Best,
Karthik

> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls