Re: should we specify HTTP/1.1 now that HTTP2 is out?

Patrick McManus <pmcmanus@mozilla.com> Wed, 04 October 2017 23:47 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127C2124B18 for <ietf@ietfa.amsl.com>; Wed, 4 Oct 2017 16:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level:
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ld6OIP3uhyYy for <ietf@ietfa.amsl.com>; Wed, 4 Oct 2017 16:47:24 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id F09C41342F0 for <ietf@ietf.org>; Wed, 4 Oct 2017 16:47:23 -0700 (PDT)
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id 19E773A0A3 for <ietf@ietf.org>; Wed, 4 Oct 2017 19:47:23 -0400 (EDT)
Received: by mail-lf0-f49.google.com with SMTP id b127so15117646lfe.9 for <ietf@ietf.org>; Wed, 04 Oct 2017 16:47:23 -0700 (PDT)
X-Gm-Message-State: AMCzsaVgY5IOAaw3nuGDa2taI0U1Q0Fxzzk+5dRhlHmZzz/u9AyVi2qk yvusF9HJiFeaTyrYoVLcztT7zmE+hgHMPhum3Jg=
X-Google-Smtp-Source: AOwi7QAU093DoSosDvFAV8dWZFDYKw9gMR6gW+fuySuKbrcEZbdJmQv090DKfG1fLGTDKNBBCDRyVWSZsAseM78EYLk=
X-Received: by 10.25.23.214 with SMTP id 83mr4845140lfx.213.1507160841829; Wed, 04 Oct 2017 16:47:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.21.22 with HTTP; Wed, 4 Oct 2017 16:47:20 -0700 (PDT)
In-Reply-To: <20171004222246.GF10456@faui40p.informatik.uni-erlangen.de>
References: <561.1507067891@obiwan.sandelman.ca> <CAOdDvNpXss3-BOLNJPb_y8g7HFfEk2KLcqv7jyp7VAu6w51zgQ@mail.gmail.com> <20171004191523.GE10456@faui40p.informatik.uni-erlangen.de> <CAOdDvNoFrLBRhBEJ_uRn6E_zxMX4YHXK-8FDs7ZHfSnJo3c7xA@mail.gmail.com> <20171004222246.GF10456@faui40p.informatik.uni-erlangen.de>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 04 Oct 2017 19:47:20 -0400
X-Gmail-Original-Message-ID: <CAOdDvNobXfjegW225Or9vA47oG-cugTkxmAZ02_OhPSVhp8MvQ@mail.gmail.com>
Message-ID: <CAOdDvNobXfjegW225Or9vA47oG-cugTkxmAZ02_OhPSVhp8MvQ@mail.gmail.com>
Subject: Re: should we specify HTTP/1.1 now that HTTP2 is out?
To: Toerless Eckert <tte@cs.fau.de>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Michael Richardson <mcr+ietf@sandelman.ca>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142cb3498ca41055ac13a3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SF3k5e76DmMjwtPz9Zt342Q0GSc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 23:47:26 -0000

I'm not really looking for a fight - I'm going to focus on the basic
principles and trying to offer advice in good faith.

I'm also not claiming to fully understand brski (is
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07
right?).

"




*In BRSKI there are state issues with both the TLS and the HTTP process.
The TLS server certificate is not trusted by the client until after at
least one RESTful interaction occurs.  Only once that has occured is the
connection considered secure. *
is the trust established by the above restful interaction trust in the
certificate (which can be extended to future connections with the same
certificate) or is it trust in the connection that did the exchange? I
presume its the former. If its the connection you have a pretty big problem
because all versions of http allow connections to be torn down at any time,
so you can never rely (in a standards way) of being able to get beyond the
initial exchange.


*We are concerned about how the protocol could become broken if used with
HTTP2 with interleaving of requests/responses."*

how does the protocol deal with issues like parallel connections and
pipelines in h1? Its the same problem.

So rather that trying to restrict the protocol to h1, or to profile h2 down
into a overly complex version of h1, the right answer here is what Michael
suggested (and Martin hinted at) early on - solve it in a state machine
above the http transport level because http as a transport isn't robustly
going to give you ordering (now or in the future) - it inherently thinks of
requests as independent of each other and their connections.

as for concerns about constrained processors, is that something the
protocol should be defining or something that should be configured for the
implementation based on their target platforms (which indeed might be
turned down for low end targets)? It seems you're better off with the
latter approach as HTTP was already designed to negotiate that stuff and
then it can evolve naturally as platforms become more capable.

hth.