Re: A non-TLS standard is needed

[Mark Nottingham <[e-mail]>]

> On 29 Apr 2020, at 1:31 pm, 援北斗兮酌桂浆 <[e-mail]> 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.

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




Cheers,


> 
> ------------------ 原始邮件 ------------------
> 发件人: "Paul Vixie"<[e-mail]>;
> 发送时间: 2020年4月27日(星期一) 凌晨2:56
> 收件人: "quic"<[e-mail]>;
> 主题: 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:
> >   *   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
> 
> 

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