Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B37130E0C for ; Mon, 12 Nov 2018 01:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.469 X-Spam-Level: X-Spam-Status: No, score=-8.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxVmrjYSj8AV for ; Mon, 12 Nov 2018 01:53:30 -0800 (PST) Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7C6130E30 for ; Mon, 12 Nov 2018 01:53:30 -0800 (PST) Date: Mon, 12 Nov 2018 01:53:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542016410; bh=dYP8NsO/Mdi2O1Y53FQOgYW1GxVDw8A896NJqO8gbSA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=GiXV10DAL3id2Dbx6K9+HthhxVt90xJhQKhPlqEW/zmNjEnpLJv8WsNjOUeBc1GC/ ztyxe1yKkABZFOPWo7NlJWZXljdHPQVuyXnfItCcWwroiRghkoIaxhaQ/j9gjyV6US 0+xbllQ/NjueJfd1zO73NI7JPmZ0384y04qEVRss= From: Anne van Kesteren Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: Subject: [quicwg/base-drafts] Introduce a bit to indicate the server doesn't do IP-based authentication (#1993) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5be94d99ede7a_2e3b3fed214d45c42322d9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: annevk X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 09:53:40 -0000 ----==_mimepart_5be94d99ede7a_2e3b3fed214d45c42322d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Web browsers have needed to invent a variety of schemes to talk to servers, such as the [CORS protocol](https://fetch.spec.whatwg.org/#http-cors-protocol) for HTTP and WebSocket as some kind of TCP, to avoid allowing `attacker.example` access to IP-authenticated data (e.g., intranets without the best security setup). It'd be nice if this kind of thing could be done at the base protocol level. This would also allow browsers to expose a QUIC^W??? API to communicate with arbitrary servers that have the relevant bit set. (If such an API saw adoption that might also be a further incentive for middleware to get their act together.) This would not obviate the need for something like CORS entirely, as requests containing cookies or HTTP authentication data would still require explicit consent, but it would allow browser-based applications to more usefully take part in the ecosystem. cc @jakearchibald -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/issues/1993 ----==_mimepart_5be94d99ede7a_2e3b3fed214d45c42322d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Web browsers have needed to invent a variety of schemes to talk to servers, such as the CORS protocol for HTTP and WebSocket as some kind of TCP, to avoid allowing attacker.example access to IP-authenticated data (e.g., intranets without the best security setup).

It'd be nice if this kind of thing could be done at the base protocol level. This would also allow browsers to expose a QUIC^W??? API to communicate with arbitrary servers that have the relevant bit set. (If such an API saw adoption that might also be a further incentive for middleware to get their act together.)

This would not obviate the need for something like CORS entirely, as requests containing cookies or HTTP authentication data would still require explicit consent, but it would allow browser-based applications to more usefully take part in the ecosystem.

cc @jakearchibald

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5be94d99ede7a_2e3b3fed214d45c42322d9--