Re: [quicwg/base-drafts] Guidance for port number use (#495)

Martin Thomson <notifications@github.com> Fri, 05 May 2017 01:28 UTC

Return-Path: <noreply@github.com>
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 C92731250B8 for <quic-issues@ietfa.amsl.com>; Thu, 4 May 2017 18:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.901
X-Spam-Level:
X-Spam-Status: No, score=-7.901 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 Jo3ZtABFx8CP for <quic-issues@ietfa.amsl.com>; Thu, 4 May 2017 18:28:03 -0700 (PDT)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2CE126557 for <quic-issues@ietf.org>; Thu, 4 May 2017 18:28:03 -0700 (PDT)
Date: Thu, 04 May 2017 18:28:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1493947682; bh=YWtHLwkky5XOjJOJ8N0Jh6+wgO7ZCJZ3YTitD4dQRas=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=gAZDEcA6Imo6cCHDuL5zXH0gojbFA4kJQL42q+aC257YK4opufKsUlU1fqJqO4gDO 1wMSqjJ46zrV3iGt4knoqeFaDYpmZZQt9bUGiOR4yy9L6TIQMwty8FwJOuI9Sfd9jJ RNPk9qYvQ8sAe8iPiHcfLjeeokBmQopPU5EhavVc=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7ec88fff067ade18114a151441d7b9a67f6b02ff92cf000000011523972292a169ce0d78bf28@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/495/299350939@github.com>
In-Reply-To: <quicwg/base-drafts/issues/495@github.com>
References: <quicwg/base-drafts/issues/495@github.com>
Subject: Re: [quicwg/base-drafts] Guidance for port number use (#495)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_590bd5226f870_2d63ff8bf477c3052565"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/4owBmyDE4gnw8Mh4KCX59VJsUOo>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 01:28:05 -0000

@hardie hit on an issue that I thought about a bit, but as long as we go to TCP first, I can't see QUIC having any role here.  The URI scheme kinda determines that.  This is why I understand why @MikeBishop wants to mint a new scheme, but it doesn't make me any more inclined to think that it will succeed.

As for running services on ports <1024, as long as you have root access once, it's possible to run a userland service, see https://serverfault.com/a/112798 for example.  Most servers use setuid() instead, of course.  That suggests to me that issues with running as root is completely workable from a security perspective.

The ossification question seems to be the most relevant question.  I agree with Ted about the value for WebRTC in having an unmodified protocol.  Though we might find some of the mechanisms we build are duplicative and so we have to disable certain things (consent to send is pretty tightly integrated into WebRTC; we have very little of that in QUIC now, but probably will build *something*).

-- 
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/495#issuecomment-299350939