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
- Re: [TLS] Reminders Dave Garrett
- Re: [TLS] Reminders Benjamin Kaduk
- Re: [TLS] Reminders David Benjamin
- Re: [TLS] Reminders Eric Rescorla
- Re: [TLS] Reminders Watson Ladd
- Re: [TLS] Reminders Anirudh Ramachandran
- [TLS] Reminders Sean Turner