Re: A non-TLS standard is needed

[Lucas Pardue <[e-mail]>]

Hi Paul,

Some responses in line:

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

> On Monday, 27 April 2020 11:56:20 UTC Lars Eggert wrote:
> > 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, 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.


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
> 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.
>

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


>