Subject: A non-TLS standard is needed

From: "援北斗兮酌桂浆" <[email-masked]>
Date: Sun, 26 Apr 2020 16:11:38 +0800

Hi, all:

Currently QUIC has a TLS layer, and it defines a security standard. But we also have inner reliable network, in such network, every host knows each other, so encryption is not necessary. If we use QUIC in such network, the TLS layer will waste much CPU time. So I think QUIC need a standard of non-TLS.

Thanks.

---

From: Lars Eggert <[email-masked]>
Date: Sun, 26 Apr 2020 14:57:39 +0300

Hi,

> Currently QUIC has a TLS layer, and it defines a security standard. But we also have inner reliable network, in such network, every host knows each other, so encryption is not necessary. If we use…

the QUIC WG is only chartered to standardize an always-encrypted version of QUIC.

Thanks,
Kars

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 26 Apr 2020 16:42:11 +0000

*   Currently QUIC has a TLS layer, and it defines a security standard. But we also have inner reliable network, in such network, every host knows each other, so encryption is not necessary. If we use QUIC in such network, the TLS layer will waste much CPU time. So I think QUIC need a standard of non-TLS.

Lars already mentioned the charter, which is the description of what the QUIC WG works on.  Adding plaintext QUIC would require revising that, and it would be surprising to me if there were consensus to do this.

There are also technical problems with this. For example, how does the protocol library “know” that it’s on a secure network? How does it know that node C isn’t trying to read messages that A sends to B? How do you negotiate between encrypted-quic and plaintext-quic, without being “tricked” into downgrading to plaintext over the public Internet, for example?  These are hard problems.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Apr 2020 18:56:39 +0000

rich, lars, 援北斗兮酌桂浆, et al, please read below.

On Sunday, 26 April 2020 16:42:11 UTC Salz, Rich wrote:
>   *   Currently QUIC has a TLS layer, and it defines a security standard.
> But we also have inner reliable network, in such network, every host knows
> each other, so encryption is not necessary. If we use QUIC in such network,
> the TLS layer will waste much CPU time. So I think QUIC need a standard of
> non-TLS.
 
> Lars already mentioned the charter, which is the description of what the
> QUIC WG works on.  Adding plaintext QUIC would require revising that, and
> it would be surprising to me if there were consensus to do this.
 
> There are also technical problems with this. For example, how does the
> protocol library “know” that it’s on a secure network? How does it know
> that node C isn’t trying to read messages that A sends to B? How do you
> negotiate between encrypted-quic and plaintext-quic, without being
> “tricked” into downgrading to plaintext over the public Internet, for
> example?  These are hard problems.

i was directed to the following i-d when i asked about QUIC manageability:

https://tools.ietf.org/html/draft-ietf-quic-manageability-06#section-3

a careful re-reading of this section shows that every possible method by which 
the operator of a hardened private network can detect or block QUIC flows has 
been foreclosed. the outcome of #section-3 is the null set.

the QUIC charter has some security goals but they are all related to third 
parties (on-path adversaries). my security goals are more expansive than this:

1. a rent-seeking browser may prohibit content filtering or ad blocking apps 
from entering its store; this is the "browser-as-platform" business model. 
much filtering and blocking occurs in the OS, hypervisor, proxy, or firewall.

2. malicious content either passive or active, or malware, or IoT, or 
intruders, may wish to make contact with its mothership for tracking or 
command/control or exfiltration purposes.

3. an insider such as a disgruntled employee or disgruntled underaged person 
subject to either corporate or family controls may seek to bypass these. user 
centric or app centric networking is adversarial to such policies and 
controls.

tens of billions of dollars are spent by hardened private network operators 
every year to detect and possibly prevent attacks of these kinds. the demand 
for such services won't shrink any time soon.

because the QUIC model requires encryption and seeks unmanageability, those of 
us operating hardened private networks are in a bad position. the beyondcorp 
model is beyond most of us at this time, for reasons of history outside our 
control.

with the QUIC charter as it is, it'll be broadly necessary to treat UDP itself 
as a privileged activity, such that whenever it occurs it's either explicitly 
expected or implicitly anomalous. this will force the use of an edge proxy 
capable of inspecting most outbound communications to enforce policy. i expect 
that the edge proxy will be permitted by most network policy to regenerate 
outbound flows using QUIC, so QUIC's advantages will be present on the long-
haul and far end, just not on the near end.

hardened private networks include the hypervisor on my laptop. no operating 
system or app i run will be allowed to communicate in any way that i can't 
verify using some BPF application like "tcpdump" or commercial edge protection 
software. i know i'm an outlier on this, but i'm far from alone. government 
and enterprise networks, if told to allow either unmanaged communications on 
their hardened private network, or to move to the beyondcorp model, will do 
neither: they will find a "third way", no matter what their costs.

it's that third way which should concern the authors of the QUIC WG charter. 
we may be best served by cooperating with hardened private network operators 
(a first party), even though these are spectacularly similar to hardened 
national ISP's in authoritative regimes (a third party).

anyhow, this is what went through my mind when i read 援北斗兮酌桂浆's question. 
since your reply and lars' reply were completely on-topic, but the question 
has broader implications, i thought i'd de-cloak for a moment to explain why.

thank you for reading this far.

-- 
Paul

---

From: Töma Gavrichenkov <[email-masked]>
Date: Sun, 26 Apr 2020 22:13:37 +0300

Peace,

> https://tools.ietf.org/html/draft-ietf-quic-manageability-06#section-3

To be honest, and with all due respect to everyone involved, the
manageability draft wasn't properly updated for years (and the authors do
not seem to respond to emails, though this could be possibly attributed to
some sort of email filtering which is common those days).

To be specific, e.g. the section 4.4, as of today, still states that, to
quote, "current practices in detection and mitigation of Distributed Denial
of Service (DDoS) attacks generally involve passive measurement using
network flow data", which is clearly not how it works, as everyone who has
seen reCaptcha interruptions during application layer DDoS could witness.

There's certain amount of hard work required to update this document before
referencing it properly (I volunteer).

--
Töma

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Apr 2020 19:27:15 +0000

> Peace,

and to you.

> seen reCaptcha interruptions during application layer DDoS could witness.

yikes. i had no idea this was already an open issue.

> referencing it properly (I volunteer).

i'd review.

-- 
Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 26 Apr 2020 19:31:28 +0000

Paul,

Thanks for sharing your view.

I'm not participating in that discussion.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Apr 2020 14:56:20 +0300

Hi Paul,

this is definitely a broader discussion - it's popping up in other places as well.

The IETF can certainly have this discussion somewhere, but the QUIC list is probably not the right home for it, esp. not as we've entered the home stretch with regards to closing the final open issues that will let us WGLC the current specs.

Lars

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 27 Apr 2020 13:05:35 +0000

Hi Töma,

we did a couple of small updates from time to time, especially for things we had issues for or where alignment with the transport draft needed updating. However, you are right this document does need more work and review and we believe this will come when the main protocol specs are stable and mostly done.

I’m sorry if we didn’t reply to any of your mails. I thought we looked through all mails when we did the last (small) update and usually I try to reply to any request. Maybe something got actually lost. Please resend if there is something that needs addressing, or file an issue on github as you just did. Thanks for that! If you would like to contribute text feel free to also send an respective PR on github.

Mirja

From: QUIC <[email-masked]> on behalf of Töma Gavrichenkov <[email-masked]>
Date: Sunday, 26. April 2020 at 21:14
To: Paul Vixie <[email-masked]>
Cc: quic <[email-masked]>
Subject: Re: A non-TLS standard is needed

Peace,
On Sun, Apr 26, 2020, 9:57 PM Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:
i was directed to the following i-d when i asked about QUIC manageability:

To be honest, and with all due respect to everyone involved, the manageability draft wasn't properly updated for years (and the authors do not seem to respond to emails, though this could be possibly attributed to some sort of email filtering which is common those days).

To be specific, e.g. the section 4.4, as of today, still states that, to quote, "current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involve passive measurement using network flow data", which is clearly not how it works, as everyone who has seen reCaptcha interruptions during application layer DDoS could witness.

There's certain amount of hard work required to update this document before referencing it properly (I volunteer).

--
Töma

---

From: Roberto Peon <[email-masked]>
Date: Mon, 27 Apr 2020 17:25:24 +0000

Trusting your hosts is not the same as trusting your network. It isn't that difficult to get an observer 3rd party on/into the supposedly secure network.
The larger the network, the easier that is to do.

We'll have forgotten some interesting moderately recent episodes in Internet and IETF history if we go down the plaintext route, and so I'd be surprised if there was consensus around this (as others have said).

-=R

On 4/27/20, 4:57 AM, "QUIC on behalf of Lars Eggert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Paul,

    
    Lars

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Apr 2020 22:46:55 +0000

On Monday, 27 April 2020 11:56:20 UTC Lars Eggert wrote:
> The IETF can certainly have this discussion somewhere, but the QUIC list is
> probably not the right home for it, esp. not as we've entered the home
> stretch with regards to closing the final open issues that will let us WGLC
> the current specs.

lars, et al, thank you for such recognition. if mirjam's draft isn't a WG 
item, i hope that those in charge will find a place for it. i do not expect to 
relitigate the mandate for TLS, but i do hope we can recommend some signal 
beyond destination UDP port number, which is arbitrary given ALT-SVC and the 
HTTPSSVC mechanisms, as the way a hardened private network can recognize some 
UDP flows as likely to be HTTP-related and thus permitted to form outbound 
flows. without this the applicability of QUIC will be less than it could be.

in other words i am requesting advice, a redirect, beyond the source quench.

-- 
Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2020 00:45:54 +0100

Hiya,

On 27/04/2020 23:46, Paul Vixie wrote:
> a hardened private network

I don't know what that is. Can you provide a definition
and/or some verifiable real-world examples?

I'm not being facetious here - while I do think I know
what you are aiming to describe, I also think that concept
may not in fact have a real-world realisation, at least
not if "hardened" is supposed to mean something that
can be detected/decided by software, rather than requiring
political antennae.

Thanks,
S.

---

From: Matt Joras <[email-masked]>
Date: Mon, 27 Apr 2020 18:44:10 -0700

On Mon, Apr 27, 2020 at 3:47 PM Paul Vixie <[email-masked]> wrote:

> > this is definitely a broader discussion - it's popping up in other
> places as
> > well.
> >
> I'm not saying I like the practice, but it is already somewhat common
place to make such decisions based on the ALPN. E.g. you could allow it if
the ALPN is "h3-whatever". This is still possible with QUIC as the ALPN is
encrypted but not private.

Matt Joras

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Apr 2020 03:09:19 +0100

Hi Paul,

Some responses in line:

On Mon, 27 Apr 2020, 23:47 Paul Vixie, <[email-masked]> wrote:

> item, i hope that those in charge will find a place for it.

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

Contributors and reviewers are welcomed.

i do not expect to
> in other words i am requesting advice, a redirect, beyond the source

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.

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?

Cheers
Lucas

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Apr 2020 03:37:14 +0000

please note both apology-for-noise below and the fact that i'm not arguing for 
a non-TLS standard which is the "Subject:" of this thread; this is related by 
motive to that proposal, but is not in fact that proposal.

> and/or some verifiable real-world examples?

i access the internet from beyond its reachability horizon, and i reserve the 
right to veto any flow or to veto all but some flows. (pretend it's a NAT and 
you'll be pretty close.) i don't trust my apps, my operating systems, my 
devices, my supply chain, or my users. yet i am responsible for everything 
they do and anything they injure using the connectivity i acquire.

i am not alone. in fact i represent the majority of non-access-provider users. 
so if you were following my advise above (pretend it's a NAT) then now pretend 
that it's deliberate and has nothing to do with IP address/resource scarcity.

> can be detected/decided by software, rather than requiring

it's a configuration, set by political or economic policy, which i hope to 
make visible to software. i do not believe that "use a fixed remote UDP port 
number" is a reasonable way to do that. so i'm looking for something better.

in mirjam's management draft, several potentials ways for a hardened private 
network operator to recognize a QUIC flow either because the policy is to 
permit such or the policy is to deny such, and then each way is ruled out.

i am hoping to rule something in beyond "make UDP a privilege". but not here 
in quic-wg, which i've been told considers this matter out of scope. so, i'm 
hoping, here, for advice as to where to go to present this problem statement.

i honestly do apologize for the noise. i'll take this elsewhere! (where?)

-- 
Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Apr 2020 04:19:22 +0000

> Some responses in line:

ty!

> ...

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/

> ...

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.

> 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

---

From: "援北斗兮酌桂浆" <[email-masked]>
Date: Wed, 29 Apr 2020 11:31:29 +0800

The plaintext-QUIC is not used between human beings under the same sub-network.
It is used between server-machines.&nbsp;
Server-machines for solving same service in the same equipment room needn't encryption while communicating between each other.
If we use QUIC for these machines communicating between each other, a non-TLS standard is needed.

------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"Paul Vixie"<[email-masked]&gt;;
发送时间:&nbsp;2020年4月27日(星期一) 凌晨2:56
收件人:&nbsp;"quic"<[email-masked]&gt;;

主题:&nbsp;Re: A non-TLS standard is needed

On Sunday, 26 April 2020 16:42:11 UTC Salz, Rich wrote:
&gt;&nbsp;&nbsp; *&nbsp;&nbsp; Currently QUIC has a TLS layer, and it defines a security standard.
&gt; But we also have inner reliable network, in such network, every host knows
&gt; each other, so encryption is not necessary. If we use QUIC in such network,
&gt; the TLS layer will waste much CPU time. So I think QUIC need a standard of
&gt; non-TLS.
&nbsp;
&gt; Lars already mentioned the charter, which is the description of what the
&gt; QUIC WG works on.&nbsp; Adding plaintext QUIC would require revising that, and
&gt; it would be surprising to me if there were consensus to do this.
&nbsp;
&gt; There are also technical problems with this. For example, how does the
&gt; protocol library “know” that it’s on a secure network? How does it know
&gt; that node C isn’t trying to read messages that A sends to B? How do you
&gt; negotiate between encrypted-quic and plaintext-quic, without being
&gt; “tricked” into downgrading to plaintext over the public Internet, for
&gt; example?&nbsp; These are hard problems.

-- 
Paul

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 29 Apr 2020 13:48:44 +1000

> On 29 Apr 2020, at 1:31 pm, 援北斗兮酌桂浆 <[email-masked]> wrote:
> 
> It is used between server-machines. 

Yes, I think I've seen an illustration of a network like that:

Cheers,

> 
> ------------------ 原始邮件 ------------------
> 发件人: "Paul Vixie"<[email-masked]>;
> 发送时间: 2020年4月27日(星期一) 凌晨2:56
> 收件人: "quic"<[email-masked]>;
> 主题: Re: A non-TLS standard is needed
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Paul Vixie <[email-masked]>
Date: Wed, 29 Apr 2020 05:01:19 +0000

On Wednesday, 29 April 2020 03:31:29 UTC 援北斗兮酌桂浆 wrote:
> The plaintext-QUIC is not used between human beings under the same
> sub-network. It is used between server-machines.
> Server-machines for solving same service in the same equipment room needn't
> encryption while communicating between each other. If we use QUIC for
> these machines communicating between each other, a non-TLS standard is
> needed. 

so, i happen to agree, but i also understand very deeply why others disagree. 

first, it's assumed that you have some control over how your servers behave, 
and can program or configure them to use HTTP over TCP, with no TLS or UDP. 
you don't need and won't miss the advantages of QUIC in a pure LAN 
environment.

second, it's widely known that nation-state attackers, mostly domestic but 
also some foreign, will be able to tap into your LAN if they see a need to do 
so, and that this will create risk for all of your counterparties, and for you 
also. the risk to your counterparties is seen as a public digital health risk; 
if your LAN is tapped by some attacker, it could hurt entire economies or even 
the entire world. the injury would be small, but can be like a thousand 
stings.

this community believes it is acting in the public's interest, and has reached 
a consensus that creating new ways to communicate non-secretly is not in the 
public's interest. such non-secret methods are available now, and can still be 
used by any operator who prefers them.

i was in the minority on these decisions, so please don't shoot the messenger.

(my reason for disagreement has to do with hypervisors and sea level rise; to 
be detailed over beer if i'm ever able to see any of you in person again.)

-- 
Paul