Re: [TLS] Reminders

David Benjamin <davidben@chromium.org> Mon, 11 July 2016 16:16 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201CF12D592 for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 09:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 G5ogW7xfv_AD for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 09:16:56 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 DA8BA12B03C for <tls@ietf.org>; Mon, 11 Jul 2016 09:16:55 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id q83so41245196iod.1 for <tls@ietf.org>; Mon, 11 Jul 2016 09:16:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=80949/bhDEPy6J0MeJ4+qhZPemoZ2AFFJ9DOAtnoQho=; b=ATJ+ryhM1Vye1uz/iPqOTRvwi0lEfmI0Y3SDr3LB1PCb7Otqxa2JNkQKUqAlY8PlK+ qMFmFUWSbzJDXAIFpgw4Ax7yQ2TRrq4dROwaH1ALFhlXHF7igyPNfLdyjAXfKE0XQ4E/ WWyeFd7+JKO5MTtdQXuS/Y4YSS0CwAe1L0vuk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=80949/bhDEPy6J0MeJ4+qhZPemoZ2AFFJ9DOAtnoQho=; b=RUHM0x1wrTOzpr+C9jBPn69LJU4Lsm/FDis1NxI5Fzu4MhUl/waDBnOF1rBN/EGtcE CW8NwRRhBxh7zRauDXDM5lMSI/UBmS7wpVZ2tHCPkoYnkAXdHfFZUL81UAxesg2DUiSA e0fR2KvwyEWxeduR6N8hl+bBfSgbvddHEZ9TaviwHVmXECDBU628Nit8XZu8kf+VU5d3 3nmf80Ypf9IY7f/v0Yefg48JaTyqCW5SLmKG9GOTLTf7QcUqy1qIX7yu2ywHt+d38hvo 18cDXuGyGBwDhTviYVgsI1HzqRa/fRrDWeNK6mE8yjX+uy/ShdBgXrqrRJnxiQnMhGPG 2qXQ==
X-Gm-Message-State: ALyK8tJ70T1ZqMiH5ncECxq7i4mbOmfVu37Q+JTJXM3D1JosGIWrq978c7RUUzVCbdIs0dbh+/IizhxCJZ+NqVvQ
X-Received: by 10.107.128.25 with SMTP id b25mr14570344iod.110.1468253815028; Mon, 11 Jul 2016 09:16:55 -0700 (PDT)
MIME-Version: 1.0
References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> <CACsn0c=Svk3Kzcd6x-8z25+2Vv6nFO938hNfQxrBctcbKOuE6A@mail.gmail.com> <CABcZeBP-qfKSbq+WJg71Pz__ng+fozu1voZqddy8MsrPRy1YpA@mail.gmail.com>
In-Reply-To: <CABcZeBP-qfKSbq+WJg71Pz__ng+fozu1voZqddy8MsrPRy1YpA@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 11 Jul 2016 16:16:44 +0000
Message-ID: <CAF8qwaC3=ATowBkcF7tSGABN5To7tDfnVENyqQ8KoGiGyWMkMA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a113fb5961624b405375e7b77
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MyZMcT1JP21I6lOa1XbNuVVRbCY>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Reminders
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 11 Jul 2016 16:16:58 -0000

OpenSSL determines which certificate to use during ClientHello processing,
but it has a mode where, if intermediates were not explicitly configured
and only a leaf, it path-builds right before sending the Certificate
message. But I don't see any reason why it can't be changed to compute this
earlier.

In general, we already require one know the certificate chain before
sending ServerHello. The cipher suite depends on the leaf key type, so that
must be selected already. If there are SCTs to deliver for any
intermediates, the server must know which intermediates will be sent. If
one wishes to consider intermediates' signature algorithms when selecting a
leaf, they must be known too.

If there are are other reasons we'd want to allow sending either hash or
contents (Caching a long-lived intermediate but sending a new short-lived
leaf? Looks like it's all-or-nothing right now. I dunno, I haven't been
paying attention to cached-info yet and assume this is well-trodden ground
by now.), the length still should not be a distinguisher. If needed,
negotiating the extension can tweak the syntax of Certificate message or
something.

David

On Mon, Jul 11, 2016 at 11:35 AM Eric Rescorla <ekr@rtfm.com> wrote:

> I agree with Watson's assessment here. This seems like the wrong design
> choice.
>
> I'm not familiar with OpenSSL's cert selection, but I don't believe that
> the issue
> that this change is intended to address applies to NSS, for two reasons:
>
> 1. NSS does cert selection during client hello processing [0].
>
> http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#9569
>
> 2. Unless I misunderstand the design of cached-info, all the server needs
> to have is the digest of the serialized chain and it could store that at
> the time
> that it configures the cert (or first uses it). This seems like quite a
> small burden.
>
> I believe the prior design was superior.
>
> -Ekr
>
>
>
>
>
>
>
>
>
> On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <watsonbladd@gmail.com>
> wrote:
>
>> On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <sean@sn3rd.com> wrote:
>> > Hi,
>> >
>> > Just wanted to remind everybody that we’ve got two non-TLS1.3 items
>> we’re looking for WG input on:
>> >
>> > - Before 12 July, we’d like to know your thoughts about progressing
>> draft-ietf-tls-pwd (Watson and ekr responded):
>> > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4
>> >
>> > - Before 14 July, we’d like to know your thoughts on the proposed
>> AUTH48 proposed changes (nobody has commented on this):
>> > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk
>>
>> I don't like the AUTH48 changes. I understand the need for changing to
>> MAY, but the proposed method of distinguishing offends my
>> sensibilities. Overloading the length field is just ugly.
>>
>> >
>> > spt
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>