Re: Discussion of 9.2.2

Eric Rescorla <ekr@rtfm.com> Fri, 26 September 2014 15:13 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2E51A8988 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Sep 2014 08:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.065
X-Spam-Level:
X-Spam-Status: No, score=-7.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 eiJ9yAGaBUBM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Sep 2014 08:13:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358761A897C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Sep 2014 08:13:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XXXAX-0002mP-7u for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Sep 2014 15:10:49 +0000
Resent-Date: Fri, 26 Sep 2014 15:10:49 +0000
Resent-Message-Id: <E1XXXAX-0002mP-7u@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ekr@rtfm.com>) id 1XXXAF-0002hu-1A for ietf-http-wg@listhub.w3.org; Fri, 26 Sep 2014 15:10:31 +0000
Received: from mail-we0-f169.google.com ([74.125.82.169]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <ekr@rtfm.com>) id 1XXXA9-0006Rs-W3 for ietf-http-wg@w3.org; Fri, 26 Sep 2014 15:10:30 +0000
Received: by mail-we0-f169.google.com with SMTP id k48so9824497wev.0 for <ietf-http-wg@w3.org>; Fri, 26 Sep 2014 08:09:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/Sp6kOwO7uxrMz+bMRk4vsWXx1+siKG/ZI/2I6DlxM4=; b=lzu/QYUR7HQushs/taIkkcPXn8+aJeZYqPjiTEuw02RoZRbbAThq56G4bwhiEcP35d 01dhq1lqD3184Zt2HMw8bLBL+lzwJjRdnXIfNaX9jmqt7TOvqfVJdbQTippHCF4GHpLE HdXCxrBGWb3QaWaHJ0li/s6p0yaN3DJh/Qs/038SQH2PHu9yDeTTK7y/x0MSS/v3zMfj kh9WvWBYNye0KOigXV/cSl6g0c4XhZt4oQMDRNEJH91Q5JsaDlhIcnv8njAmQBlgbV3u Saoq+HTY2G1tu0KsMF4u65Rwg/bAzDOYxGD1+ptNN56j5qxGbgUWopY+Cfl5sP8BTg/c mvXA==
X-Gm-Message-State: ALoCoQnPisy2+WSH9aKqLc+ezs/Zrmdvjx4oXW1lzOh4ji9ullmmPmEGtj83JKWM1XTyCj3ZJmeJ
X-Received: by 10.180.98.227 with SMTP id el3mr28157317wib.13.1411744199166; Fri, 26 Sep 2014 08:09:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.176.100 with HTTP; Fri, 26 Sep 2014 08:09:19 -0700 (PDT)
In-Reply-To: <67BE9032-4441-46DE-8929-A25E4FEF3CCF@redhat.com>
References: <F0D4BA2A-46B2-4F1A-8A23-1A319A3E5FC0@mnot.net> <CABkgnnWszVer8Y3qgmEQnxNKUhroUEeseC8JkBbGT2P6z3iZxQ@mail.gmail.com> <36736818-C125-4390-841B-94AD76A45EA0@apple.com> <67BE9032-4441-46DE-8929-A25E4FEF3CCF@redhat.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Sep 2014 08:09:19 -0700
Message-ID: <CABcZeBPUihY6-i7EEhWq35=RNA--ZHMqnjkJQnO+_OZkfwoPdQ@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
Content-Type: multipart/alternative; boundary="f46d04447dfd8165a30503f94f16"
Received-SPF: none client-ip=74.125.82.169; envelope-from=ekr@rtfm.com; helo=mail-we0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-2.079, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: maggie.w3.org 1XXXA9-0006Rs-W3 903b9445d9a5be8abb0e82beceee5ed8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Discussion of 9.2.2
Archived-At: <http://www.w3.org/mid/CABcZeBPUihY6-i7EEhWq35=RNA--ZHMqnjkJQnO+_OZkfwoPdQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/27258
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Fri, Sep 26, 2014 at 7:55 AM, Jason Greene <jason.greene@redhat.com>
wrote:

> Has there been any discussion and buy-in with the major TLS implementers
> (OpenSSL, LibreSSL, Microsoft, NSS, etc) about the need to provide a
> characteristic-based priority and introspection API that also allows for
> different policies per TLS version?
>
> According to Michaels investigation it looks like all of them fall short
> of this.


As I indicated previously, NSS provides the necessary introspection API.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2296.html

You don't need a priority API to correctly implement these requirements, nor
do you need one that provides differential requirements for different TLS
versions (other than the ones that are encoded in the TLS specifications
and implemented by the library).

-Ekr



> At a minimum we should at least have a commitment that a complete solution
> meeting the needs of future ciphers, legacy compatibility, and the rules of
> 9.2.2 will even be possible. While this still falls short of “working
> code”, there is at least a chance that it can be implemented without
> breaking standard industry usage patterns.
>
> On Sep 26, 2014, at 7:17 AM, Michael Sweet <msweet@apple.com> wrote:
>
> > I think the lead-in paragraph (everything below only applies to TLS 1.2)
> is confusing when the first item after it then says "this isn't just
> limited to TLS 1.2".  Since all of the others are now explicitly TLS 1.2
> requirements you can probably drop that lead-in paragraph to avoid the
> confusion...
> >
> > And FWIW I still have no interoperable way to implement these
> restrictions in a client or server that supports both HTTP/1.1 and HTTP/2
> with the current TLS libraries, so I'll have to use the sub-optimal
> negotiate-and-then-give-up-forcing-a-new-connection approach if I want to
> enforce the 9.2.2 cipher suite and minimum TLS version requirements.
> >
> >> On Sep 26, 2014, at 1:08 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >>
> >> On 24 September 2014 12:17, Mark Nottingham <mnot@mnot.net> wrote:
> >>> <http://http2.github.io/http2-spec/#rfc.section.9.2.2>
> >>
> >> I've updated my pull request on this subject.  There are a few
> >> editorial changes in the mix, but the commit log shows exactly what
> >> changes are involved:
> >>
> >> https://github.com/http2/http2-spec/pull/615
> >>
> >> I believe that these changes resolve the issues people have raised.
> >> That is, other than the one which states we shouldn't have this
> >> section at all.
> >>
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> >
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>