Re: [TLS] Reminders

Benjamin Kaduk <bkaduk@akamai.com> Mon, 11 July 2016 16:22 UTC

Return-Path: <bkaduk@akamai.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 B52CE12D5C4 for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 09:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level:
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MISSING_HEADERS=1.021, 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=akamai.com
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 5M1QmnMuADGE for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 09:22:43 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 81A3A12D599 for <tls@ietf.org>; Mon, 11 Jul 2016 09:22:43 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ABC2643346A for <tls@ietf.org>; Mon, 11 Jul 2016 16:22:42 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8B21A433403 for <tls@ietf.org>; Mon, 11 Jul 2016 16:22:42 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1468254162; bh=RNqxX9v3VM71pIz3gCElz0kEF2VSzGSnn9TbICQAuLA=; l=10528; h=References:Cc:From:Date:In-Reply-To:From; b=tvtSSG100kfV6OjIuGtqVxYiBcfRvCiKD/+mk6MQ+//hRgcSXwzk0o9uRDOv40z+d yaqsVesxcHymEjrl9qOgYtZgovbYFFMQkzm9H8F3d63OFefb+wcpqWJD2YOhdDqRLP xEbviNQHGF/QkOpAsS7XD8TDBNYwT4zOdO/lXAu0=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 51DC21FC8C for <tls@ietf.org>; Mon, 11 Jul 2016 16:22:42 +0000 (GMT)
References: <47E3268E-46F0-4308-88EA-250042EF2B80@sn3rd.com> <CACsn0c=Svk3Kzcd6x-8z25+2Vv6nFO938hNfQxrBctcbKOuE6A@mail.gmail.com> <CABcZeBP-qfKSbq+WJg71Pz__ng+fozu1voZqddy8MsrPRy1YpA@mail.gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <5783C7D2.6040902@akamai.com>
Date: Mon, 11 Jul 2016 11:22:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBP-qfKSbq+WJg71Pz__ng+fozu1voZqddy8MsrPRy1YpA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060502000801020608070704"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/eopXVd86W7qgvGwv8HNk9XIe72E>
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:22:46 -0000

I also don't like the AUTH48 changes -- there's no protocol-level reason
to weaken the MUST, since a server that can't handle the extra
state/processing can just not implement the extension at all.

-Ben

On 07/11/2016 10:34 AM, Eric Rescorla 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__searchfox.org_mozilla-2Dcentral_source_security_nss_lib_ssl_ssl3con.c-239569&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=GGUhUgPsmo8P-zHms3do7kMl919w4Emye3THqWUMSgY&e=>
>
> 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
> <mailto:watsonbladd@gmail.com>> wrote:
>
>     On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <sean@sn3rd.com
>     <mailto: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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_WrNa7PXTZn2ZhfmoQDA-5FpnUVuN4&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=ZzDtgI_TBc-Nia0FuETErOUeRUXahxu7BclcP8UXy7Q&e=>
>     >
>     > - 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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_aBvqMG7t8qkO5rPt-2DxaMHipuBVk&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=iGwvQ3uwrEzZ6N9yAb5yY5May3Sl2t1r2wy_HvSAhcg&e=>
>
>     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 <mailto:TLS@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/tls
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=4tEhM1I3VnCdJjY-hDncM9jWkxNdHLzpOzvwPBjikg8&e=>
>
>
>
>     --
>     "Man is born free, but everywhere he is in chains".
>     --Rousseau.
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=pVTD_MCGmQI6J5R-ox-R0Wei-_tcv80ZWTMx-e6oZfU&s=4tEhM1I3VnCdJjY-hDncM9jWkxNdHLzpOzvwPBjikg8&e=>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls