回复： A non-TLS standard is needed

[援北斗兮酌桂浆 <[e-mail]>]

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.




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

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



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

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.

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