Re: Conflicting requirements?

Martin Duke <martin.h.duke@gmail.com> Mon, 08 June 2020 21:14 UTC

Return-Path: <martin.h.duke@gmail.com>
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 CE0763A00C4 for <quic@ietfa.amsl.com>; Mon, 8 Jun 2020 14:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 71W9XOlVTzQO for <quic@ietfa.amsl.com>; Mon, 8 Jun 2020 14:14:42 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09653A00B2 for <quic@ietf.org>; Mon, 8 Jun 2020 14:14:42 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id c8so20423115iob.6 for <quic@ietf.org>; Mon, 08 Jun 2020 14:14:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KABJF9e84JET0N/tqqIYgIoZblHgUDpR9PXtFJMZ8Mg=; b=EtlNKiEL4Fnk/dwqc4VMzhKKR+HYYqBcNDbzT1H/h6BYFXXTwEvvELN93k+eC3T7uz G2aYg/3JeiTTNksh3lk0vPQXwXK64BVi8ZDfnf4qhy7A6xnx8Qhfh0xot4gXACXkwEA4 AaSE46GniIuzsMayQwPhq9Ott4tcAAf6O6KzRnRF9AhUJ1IJABNL9K98P/qW4cy4hw9Y SnMgVuS7O/LCH7qfz9k/Zc1tGCAfxbBr12gHdz51j7EAM66YQ4hSZPSBQ0gsUSqHtZPs ZoPzXk2IKgsq0+Nu1coMfy9KXozigsXLZwNevRrV7jhb+xaU2LSHEmeNi5KI6vL6kJkU B86g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KABJF9e84JET0N/tqqIYgIoZblHgUDpR9PXtFJMZ8Mg=; b=FrxVr1WXsM2tlbCA8Ci1+BRZI/ntBMhyw/F0QAzuFpF600dkJx2D/QiuN4qHlkwszR jMZ8yTULHKsPayPQN/TN9m6CiLOVrOufVuR3X2DwB5gfGmMxniz6wOrcE3NlJ/HIFcHS aRWWCJTrm2XGnMcJK+La9XGJNpQTWzzrDVQqF8JNdXnB94QwTyloN0uMj1k84damu9DY GSRMKRYjNz9jOymj92tFYJEP1bMK2FwruvFHqhfDTToSDJJ+Cj1lOzog6QjSccX8pdzI cWjU6d76VgtPQgYV1OwM+UyvW819cVGm4qn+0qpX1pEn4bnizJSDuxpO7cV9t642p8oq +U3w==
X-Gm-Message-State: AOAM530BjY4o1kmmG4auA9szRJ3rJw2arIwbD2WziamtbASJ2m6wiKQZ kF75rfAWaC4Z687WDhjsiXapFLCMKE+gqNEzIkzr1ufc
X-Google-Smtp-Source: ABdhPJzgxNItsoTiL1/HG3Trg6qp17+Ogl2Z2N3d9bF+16ZXlBqxyJ1IIPyK5Jadb5cjrm/WhcC1Vsy0mEARWn3/TkI=
X-Received: by 2002:a6b:fd18:: with SMTP id c24mr22368180ioi.97.1591650881651; Mon, 08 Jun 2020 14:14:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxSg=oWNLUoNK6Rg6x1KL5NvtWz8qyvk3aa-UWL3HtaodA@mail.gmail.com> <0cde7047-7856-97c5-5e3e-0f0ad380451a@huitema.net>
In-Reply-To: <0cde7047-7856-97c5-5e3e-0f0ad380451a@huitema.net>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 8 Jun 2020 14:14:30 -0700
Message-ID: <CAM4esxQ+i=6d6U6iWTe5Ym=2F4-kt5BTqS-Bp=FPM1NBhnN+YA@mail.gmail.com>
Subject: Re: Conflicting requirements?
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068475005a7991941"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/y_YCC75R3k9X53vF2Zt7eMAwiSY>
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: Mon, 08 Jun 2020 21:14:45 -0000

I'm not debating the relative merits. We let our customers set this as they
wish. I'm just asking what the spec is requiring here, and if there's an
editorial change needed in one of the drafts.


On Mon, Jun 8, 2020 at 2:12 PM Christian Huitema <huitema@huitema.net>
wrote:

> On 6/8/2020 2:00 PM, Martin Duke wrote:
>
> In section 8.1 of quic-transport,
> When using ALPN, endpoints MUST immediately close a connection (see
> Section 10.3 of [QUIC-TRANSPORT
> <https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#QUIC-TRANSPORT>])
> with a no_application_protocol TLS alert (QUIC error code 0x178; see Section
> 4.10 <https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#tls-errors>)
> if an application protocol is not negotiated.
>
> In 4.10 of quic-tls,
> Endpoints MAY use a generic error code to avoid possibly exposing
> confidential information.
>
> Which one takes precedence? May the server send a generic error when there
> is no ALPN code?
>
>
> That's a very old debate. More specific the error codes make debugging
> easier but do expose details of implementation or configuration, so there
> is a tension. The usual  compromise is that privacy conscious applications
> can always be configured to send generic error codes.
>
> -- Christian Huitema
>