IETF Logo Mail Archive

Re: [quicwg/base-drafts] TLS alert no_application_protocol is not always possible (#3580)

Kazuho Oku <notifications@github.com> Fri, 17 April 2020 03:28 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB153A0848 for <quic-issues@ietfa.amsl.com>; Thu, 16 Apr 2020 20:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 z1c_ngQLm7qo for <quic-issues@ietfa.amsl.com>; Thu, 16 Apr 2020 20:28:34 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8794A3A0844 for <quic-issues@ietf.org>; Thu, 16 Apr 2020 20:28:34 -0700 (PDT)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net [10.48.17.68]) by smtp.github.com (Postfix) with ESMTP id 786455204D6 for <quic-issues@ietf.org>; Thu, 16 Apr 2020 20:28:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587094113; bh=RAC1vorsm72RB9H848X35IIBcupYc3BYdFLwRBEBlbk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=H/58a7T85s9Db1cuHEurh3INWasJWRbdyF1o6VGxi/ZB37uV3IeadQqtP4hOek6r0 ELdWCeNEZS4kNMb5Oa8XPZswz7REoieuSjNL1sZCyHHZAlMf/fRJD6xhmo1kEYuSOI 0J99WE2vu1DR1IwPwxRybbe9EdCXgjXaPC1LT3Go=
Date: Thu, 16 Apr 2020 20:28:33 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5BCD7XWHB54BDEDN54UUBWDEVBNHHCHP77D4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3580/615017711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3580@github.com>
References: <quicwg/base-drafts/issues/3580@github.com>
Subject: Re: [quicwg/base-drafts] TLS alert no_application_protocol is not always possible (#3580)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e9922616943b_53883fc16cacd95c36276e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/djXBS-t5PCTDVUjA1xyjjcBevJ4>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2020 03:28:36 -0000

@martinthomson 
> I hope that the application isn't the callback code, but that quicly is involved in this somehow; otherwise, you have just made H2O responsible for fulfilling QUIC requirements that you might assume quicly would be responsible for.

Yeah I think my preference goes to not having an abstraction layer in our QUIC protocol stack for hiding TLS handshake protocol API. I'd argue that the intent of using TLS in QUIC is to reuse TLS including its extensions when possible. Requiring (or recommending) a QUIC stack to provide abstraction for those extensions (that happen at the handshake protocol level) reduces that benefit.

That said, I think we agree that in this particular case a generic alert is fine, and that what we need at most is an editorial improvement.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3580#issuecomment-615017711

v2.23.0 | Report a Bug | By Email