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

Martin Thomson <martin.thomson@gmail.com> Wed, 16 September 2015 17:39 UTC

Return-Path: <martin.thomson@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 8AF5C1B40D1 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 10:39:19 -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 JZAar1pygVHX for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 10:39:18 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 2A2511B40CE for <tls@ietf.org>; Wed, 16 Sep 2015 10:39:18 -0700 (PDT)
Received: by ykdt18 with SMTP id t18so206341608ykd.3 for <tls@ietf.org>; Wed, 16 Sep 2015 10:39:17 -0700 (PDT)
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:content-transfer-encoding; bh=bZ34dU1jlyJTt8Jg5SFq/0WJajJeCtraVN/5WLL3+ps=; b=Vz4Gxnslnxg6IYTcnzx0iPYfZUBPAteveS1nFYd5Hsel2kmzBfIkDSdWuyDlFurmnc k4bsUgr8CGuGnkEC3yVvfdHdstVvKTmxo/lOGD4cVJuCwza+BUl/NZikbsQLpJ+hNYtC eX1eFisBpZjhOWOI2KjhHPJmeUAE/nkgicIuDBKLd8KchWkW7N4qTnRZbZV/YHaQLI3o bqtbUFXx9UDMS//bX8hVT3IQEyG6yQ3nep7H+f9FretxUnOJdqGTjISeQlFvkDbaMFUY MDBvqtlgdwR3JXxE3S7IQrS4PP+5opZGR/0NZeBmaqkNTgtwWgIEV1hDTNrU5Q+LMUDU sT4g==
MIME-Version: 1.0
X-Received: by 10.129.148.197 with SMTP id l188mr30602506ywg.118.1442425157492; Wed, 16 Sep 2015 10:39:17 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Wed, 16 Sep 2015 10:39:17 -0700 (PDT)
In-Reply-To: <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> <DEE86247-BD9E-460E-ADE9-E611F8164614@gmail.com>
Date: Wed, 16 Sep 2015 10:39:17 -0700
Message-ID: <CABkgnnWvX4evQKhDxL8_cKto8b7O6FreMJigcUBANLa6u7B0dg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/aI6CXyiyee3zVpYUtmLqIODpcu0>
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 17:39:19 -0000

On 15 September 2015 at 20:12, Karthikeyan Bhargavan
<karthik.bhargavan@gmail.com> wrote:
> 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.

This was only in the 1.3 context, and the certificate digest was
completely removed from the handshake...

It was pointed out to me separately that this doesn't work for static
RSA because you need to include the public key in the transcript there
to avoid having an attacker impose a PMS (one of the components of
triple-handshake).  That means that we need a strong hash for that
case.  However, if this is only used for PFS modes, then the analysis
suggests that we are OK to remove or truncate, assuming session-hash.

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

Does any of the existing analyses of TLS permit these changes?

If the same key is used for two different purposes, then the risk of
reaching a state where the purposes are confused seems to be too easy.

Similarly, if I can obtain a certificate for a key without
demonstrating proof of possession, then we're in a bad state.  I would
hope that the ACME protocol does not permit that, certainly this is a
fundamental part of the certificate signing request.