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

Benjamin Kaduk <> Thu, 21 January 2021 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3BD13A0CE0; Thu, 21 Jan 2021 13:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DwtPta4F1LoX; Thu, 21 Jan 2021 13:30:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D01E3A0DE7; Thu, 21 Jan 2021 13:29:55 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 <>
To: Mark Nottingham <>
Cc: The IESG <>,,,,
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:
> > 
> > (discuss point 1)
> > Mike already filed
> > 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.