Subject: [Masque] Fleshing out the MASQUE Protocol

From: David Schinazi <[email-masked]>
Date: Thu, 12 Mar 2020 19:10:10 -0700

Hi folks,

I fleshed out a lot of the details in the MASQUE protocol
draft, and have submitted the following revision:
https://tools.ietf.org/html/draft-schinazi-masque-protocol

(note that I renamed it from draft-schinazi-masque to
draft-schinazi-masque-protocol to meet naming requirements.)

I hope that this draft contains enough information to implement
MASQUE Negotiation, and the QUIC Proxying MASQUE Application.

Feedback is most welcome!

Thanks,
David Schinazi

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Mar 2020 19:18:59 +0000

Hi David,

Thanks for this update it looks good and makes things much clearer to me.

I now understand more about the negotiation element, even though that
aspect has not changed in your diff. So I have a comment; initial
connection-wide MASQUE proxy negotiation occurs using a POST method. I'm
wondering how this applies to client applications that can't or shouldn't
know about connection context. Specifically, I'm thinking about cases like
Fetch[1], which prohibits the CONNECT method in order to mitigate a class
of vulnerability[2]. Any thoughts?

Cheers
Lucas

[1] - https://fetch.spec.whatwg.org/#methods
[2] - https://www.kb.cert.org/vuls/id/150227/

On Fri, Mar 13, 2020 at 2:10 AM David Schinazi <[email-masked]>
wrote:

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 16 Mar 2020 12:25:59 -0700

My expectation is that MASQUE needs to know about the connection context
and is not bound by the Fetch spec - in other words, MASQUE is a client
application in its own right that can't be implemented in Web-based
JavaScript for example. Regarding the vulnerability you describe, I think
we'll want to mention this in security considerations and recommend that
implementors have proxying disabled by default unless explicitly enabled by
the server administrator?

David

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 16 Mar 2020 19:42:09 +0000

> the server administrator?

I think that makes sense. If JS-based MASQUE is out of scope, then perhaps
we should also consider preventative techniques on the client side such as
requiring a "Sec" prefixed header such as those used by WebSockets [1].

A more drastic change would be to switch away from POST to something like
extended CONNECT.

Lucas

---

From: David Schinazi <[email-masked]>
Date: Mon, 16 Mar 2020 14:18:16 -0700

I agree. Could you file an issue please so we keep track of this?
https://github.com/DavidSchinazi/masque-drafts/issues/new/choose

David