Re: A non-TLS standard is needed

Paul Vixie <paul@redbarn.org> Tue, 28 April 2020 04:19 UTC

Return-Path: <paul@redbarn.org>
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 D8A163A0829 for <quic@ietfa.amsl.com>; Mon, 27 Apr 2020 21:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XExYLnvzzdtD for <quic@ietfa.amsl.com>; Mon, 27 Apr 2020 21:19:23 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892DF3A081E for <quic@ietf.org>; Mon, 27 Apr 2020 21:19:23 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 386CFB074A for <quic@ietf.org>; Tue, 28 Apr 2020 04:19:23 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: quic <quic@ietf.org>
Subject: Re: A non-TLS standard is needed
Date: Tue, 28 Apr 2020 04:19:22 +0000
Message-ID: <8728182.4ulF62aDUA@linux-9daj>
Organization: none
In-Reply-To: <CALGR9obi+uogBVGrSVAmEx-YNG=w-Vxj2ntH+KcGc_k49xGUyQ@mail.gmail.com>
References: <tencent_458BB4AFD3E32DBAAEA3F09FAEF063800605@qq.com> <2010266.tehQBtF6zN@linux-9daj> <CALGR9obi+uogBVGrSVAmEx-YNG=w-Vxj2ntH+KcGc_k49xGUyQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/nr4K2e6rt2eiDwp-nStLr5Of_bk>
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: Tue, 28 Apr 2020 04:19:25 -0000

On Tuesday, 28 April 2020 02:09:19 UTC Lucas Pardue wrote:
> Hi Paul,
> 
> Some responses in line:

ty!

> ...
> 
> Just to clarify things here, draft-ietf-quic-applicability and
> draft-ietf-quic-applicability are adopted documents with milestones.
> 
> Contributors and reviewers are welcomed.

since you named the same draft two times, i thought you might mean these two:

https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/

> ...
> 
> Personally I see the applicability and management as succeeding the charter
> goal without relitigation.
> 
> Maybe there are more general statements to be said about the conditions
> that could affect the ability to make and maintain QUIC connections in
> different deployment architectures. I defer to the document editors'
> judgement here.

i'd like to proceed on that basis, but i will wait for the editors' response 
to your intervention here before i move forward. i think if the rest of the 
specification is ready to go, that nobody is going to want to hold that up 
while manageability or applicability is being debated. and if the rest goes 
out, it won't matter what kind of management or applicability mechanisms may 
reach consensus later on. so, i think the result i'm facing is pretty grim.

> However, beyond the QUIC WG we also have MASQUE which has been discussing
> use cases and potential solutions related to proxying and tunneling. One
> case is similar to how an enterprise might set up restricting outbound HTTP
> over TCP (and TLS) today: deny all outbound traffic apart unless it goes
> via a forward proxy. One proposal to achieve this is the definition of a
> CONNECT_UDP method which is a request by the client asking the proxy to
> form an outbound "UDP connection" to the target. This could be used to
> provide an enforcement function based on the request metadata.
> 
> Maybe that is along the lines of what you are describing?

that will help, but it won't solve my more fundamental problem which is that a 
non-proxy aware QUIC initiator inside my network can't be allowed to succeed, 
but there is not a reliable way to prevent only that -- so i'll be preventing 
quite a bit more than i want to. (some members of the community have told me 
privately that this is by design, but i don't believe it.)

so while actual manageability mechanism would allow QUIC initiation packets to 
be recognized by a gateway, and answered with an ICMP to give them a hint that 
what the initiator wants to do won't work until they learn the local policy 
which will likely involve a proxy. but i think noone knows how to secure such 
a thing against downgrade attacks, so i'm asking only for recognizability, not 
a proxy registration or negotiation protocol.

-- 
Paul