IETF Logo Mail Archive

Re: Conflicting requirements?

Christian Huitema <huitema@huitema.net> Mon, 08 June 2020 21:13 UTC

Return-Path: <huitema@huitema.net>
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 82A233A0063 for <quic@ietfa.amsl.com>; Mon, 8 Jun 2020 14:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 h7jkzkEoeEIg for <quic@ietfa.amsl.com>; Mon, 8 Jun 2020 14:12:59 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 62D6F3A0062 for <quic@ietf.org>; Mon, 8 Jun 2020 14:12:59 -0700 (PDT)
Received: from xse174.mail2web.com ([66.113.196.174] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jiP4c-000hOA-F1 for quic@ietf.org; Mon, 08 Jun 2020 23:12:58 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49gmDW2d9dz2tm for <quic@ietf.org>; Mon, 8 Jun 2020 14:12:43 -0700 (PDT)
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jiP4V-0003yD-7h for quic@ietf.org; Mon, 08 Jun 2020 14:12:43 -0700
Received: (qmail 12934 invoked from network); 8 Jun 2020 21:12:42 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 8 Jun 2020 21:12:42 -0000
Subject: Re: Conflicting requirements?
To: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <CAM4esxSg=oWNLUoNK6Rg6x1KL5NvtWz8qyvk3aa-UWL3HtaodA@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <0cde7047-7856-97c5-5e3e-0f0ad380451a@huitema.net>
Date: Mon, 08 Jun 2020 14:12:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CAM4esxSg=oWNLUoNK6Rg6x1KL5NvtWz8qyvk3aa-UWL3HtaodA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------595D21BEBB84B5F58E3E485E"
Content-Language: en-US
X-Originating-IP: 66.113.196.174
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.174/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.174/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fwuhl+SFh+udCLiTeLN1rOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ft0VWvQEKRy6njUpt9IaltjU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/YxFBjiwvt8YGG8KnqhbQXbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilZpnfSx1WjM8 Y221ho/pD3/YTgm/NnC/c8YEQ5zoBxO0grdS7Rh5sH3gRcQbBXAoPEFgpch+Ue6WLYWFoyi0E6VU PVcmx1QL+XiKf76y/BgKM+kBC+3ISsPcm/xMvGjFNPKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8dyr00deay+U3cA4KLzNxeDXg724gFzhHYUe+7aKm0vVMjzgoJvC4aZvfZOucZxEfTi+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chiaI0MTr3GW/OYY+JBcn69qp7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i_9vmzLYYXLlbJn6Mn3dNAgPJ9g>
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:13:07 -0000

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

v2.23.0 | Report a Bug | By Email