IETF Logo Mail Archive

Re: New Version Notification for draft-duke-quic-version-aliasing-01.txt

Paul Vixie <paul@redbarn.org> Sun, 26 April 2020 19:25 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44B83A0F13 for <quic@ietfa.amsl.com>; Sun, 26 Apr 2020 12:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kD0GcjmKpT0D for <quic@ietfa.amsl.com>; Sun, 26 Apr 2020 12:25:22 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6323A0EF9 for <quic@ietf.org>; Sun, 26 Apr 2020 12:25:22 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 02FCCB074A; Sun, 26 Apr 2020 19:25:21 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Ian Swett <ianswett@google.com>, quic@ietf.org
Cc: IETF QUIC WG <quic@ietf.org>, Ryan Hamilton <ryan@optimism.cc>, Martin Duke <martin.h.duke@gmail.com>
Subject: Re: New Version Notification for draft-duke-quic-version-aliasing-01.txt
Date: Sun, 26 Apr 2020 19:25:21 +0000
Message-ID: <3080028.HtEORxsLJ0@linux-9daj>
Organization: none
In-Reply-To: <CAM4esxQOJhBU_7MV_5kRMJWJGeU-XHnOPbt_1Q6Aa4Z7Wft9eQ@mail.gmail.com>
References: <158768580975.15102.13320878640394434826@ietfa.amsl.com> <CAKcm_gOexahkCt9Djyre+_ciRsaiE+1Jknwtvo99jjANkmkMsg@mail.gmail.com> <CAM4esxQOJhBU_7MV_5kRMJWJGeU-XHnOPbt_1Q6Aa4Z7Wft9eQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/EvyizU0J_AFmdW1I7N3sXDpC5Kg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 19:25:25 -0000

On Sunday, 26 April 2020 16:02:24 UTC Martin Duke wrote:
> Alt-svc is a great idea. I might restructure the draft to cover multiple
> delivery systems besides transport parameters.
> 
> The difficulty with DNS is that the DNS server has to have the keys to
> securely generate salts. I would love to have an internet where that was
> easy, but someone who knows more than me about DNS will have to tell me if
> it can be.

DNS expects you to use the in-band dynamic update protocol for this (see RFC 
2136), if you have traditional zones, or else answer all questions for that 
name programmatically (like in the CDN world) if you don't have traditional 
zones.

-- 
Paul

v2.23.0 | Report a Bug | By Email