Re: Benjamin Kaduk's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 21 January 2021 21:30 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD13A0CE0; Thu, 21 Jan 2021 13:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DwtPta4F1LoX; Thu, 21 Jan 2021 13:30:05 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D01E3A0DE7; Thu, 21 Jan 2021 13:29:55 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10LLTlKr020844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jan 2021 16:29:52 -0500
Date: Thu, 21 Jan 2021 13:29:47 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mark Nottingham <mnot@mnot.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-http@ietf.org, lucaspardue.24.7@gmail.com, quic@ietf.org, quic-chairs@ietf.org
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)
Message-ID: <20210121212947.GI21@kduck.mit.edu>
References: <161116741504.28838.3011643882056868272@ietfa.amsl.com> <93322516-3988-44D9-B495-89816E76B4A3@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <93322516-3988-44D9-B495-89816E76B4A3@mnot.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Iqan4L_3A09cEhyqxkRh54ey2mY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 21:30:08 -0000

Hi Mark,

On Thu, Jan 21, 2021 at 11:09:15AM +1100, Mark Nottingham wrote:
> Ben,
> 
> > On 21 Jan 2021, at 5:30 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > 
> > (discuss point 1)
> > Mike already filed https://github.com/quicwg/base-drafts/issues/4761
> > and I think we can keep the discussion there.
> > But to reiterate, we reference [SEMANTICS] for certificate validation
> > and use in determining authority for the "https" scheme, yet the
> > additional prose discussion we offer (with CN-ID and DNS-ID as the
> > certificate fields to validate against, though not by that name) does
> > not match what's currently present in [SEMANTICS].  Discussion so far on
> > the linked issue against [SEMANTICS] suggests that [SEMANTICS] will
> > change, but we should not go forward with this document until we've
> > resolved the disparity.
> 
> The only situation where that's useful is if you believe certificate validation should operate in a different fashion for HTTP/3 from other versions of the protocol; is that the case?

Well ... that depends on whether HTTP certificate validation is intended to
change from its historical behavior (which is what the current state of
[SEMANTICS] says).

I'm thinking about this from the angle of "we currently are in conflict
with [SEMANTICS], which is an internal inconsistency" and so we can't
publish.  If we wish to defer to [SEMANTICS], whatever it says, then we
would seem to fall under "has a normative reference to a work not at a
similar level of maturity" ... and we still can't publish.  Once we (I
assume) confirm that [SEMANTICS] is not actually intending to drastically
change how HTTP certificate validation works, then we're set.  That's all I
meant to imply.

> >  (One might also wonder whether we need to
> > duplicate the content ourselves or should just reference the other
> > document(s).)
> 
> If the content is indeed the same, I hope we can agree that it shouldn't be duplicated; having every version of HTTP re-specify this isn't really workable.

That would be my preference, yes, though I cannot speak for anyone else,
and I could perhaps imagine an argument being made that there is value in
repeating aspects of it in this document.

Thanks,

Ben