IETF Logo Mail Archive

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

Lucas Pardue <notifications@github.com> Thu, 16 April 2020 15:26 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 482103A0AB7 for <quic-issues@ietfa.amsl.com>; Thu, 16 Apr 2020 08:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.72
X-Spam-Level:
X-Spam-Status: No, score=-1.72 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3U0lMNZ5Vk3w for <quic-issues@ietfa.amsl.com>; Thu, 16 Apr 2020 08:26:10 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC1D3A0A0E for <quic-issues@ietf.org>; Thu, 16 Apr 2020 08:26:09 -0700 (PDT)
Received: from github-lowworker-1b8c660.ash1-iad.github.net (github-lowworker-1b8c660.ash1-iad.github.net [10.56.18.59]) by smtp.github.com (Postfix) with ESMTP id D831A2C15AD for <quic-issues@ietf.org>; Thu, 16 Apr 2020 08:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587050767; bh=XavQ9adq8fToydAd8Csgjb4i/nvPRES+/8Eoi4uzO9M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C5Jr0LukRb3Q0C7jWYdABL53ffZj8WAPKdNkJiNOd+6XfN+3mqzJ7hTd7c9/KZCI2 KRFbiOFHfqP2pghirWZ3LqO4g5yaR63oRGop5w3vLcEhJ0f4CBAm16Vu+T9BZmAOJA e0UOPq99UQ1zZ3EQt6cWzWpviAz9lpr6QndGoudQ=
Date: Thu, 16 Apr 2020 08:26:07 -0700
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6KW4HNWVCWQ2CZHJV4URNA7EVBNHHCHP77D4@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/614722375@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_5e98790fc6fac_43153ff199ccd95c14245e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/HhjaLBG6tEfigQ0K-RXeSCOMo80>
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: Thu, 16 Apr 2020 15:26:11 -0000

I believe what you are asking is already catered for. The requirement for the failure case is MUST close, and the most appropriate error code is defined.

[Draft 27 Section 11 says](https://tools.ietf.org/html/draft-ietf-quic-transport-27#section-11)
```
   The most appropriate error code (Section 20) SHOULD be included in
   the frame that signals the error.  Where this specification
   identifies error conditions, it also identifies the error code that
   is used; though these are worded as requirements, different
   implementation strategies might lead to different errors being
   reported.  In particular, an endpoint MAY use any applicable error
   code when it detects an error condition; a generic error code (such
   as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
   of specific error codes.
```

-- 
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-614722375

v2.23.0 | Report a Bug | By Email