Re: HTTPSSVC record draft

Ben Schwartz <bemasc@google.com> Wed, 03 July 2019 20:24 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2961200D7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 3 Jul 2019 13:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.25
X-Spam-Level:
X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 48QIsFsTGspU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 3 Jul 2019 13:24:34 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488421200C7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 3 Jul 2019 13:24:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hillz-00065j-Ev for ietf-http-wg-dist@listhub.w3.org; Wed, 03 Jul 2019 20:22:35 +0000
Resent-Date: Wed, 03 Jul 2019 20:22:35 +0000
Resent-Message-Id: <E1hillz-00065j-Ev@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <bemasc@google.com>) id 1hilly-00064t-6b for ietf-http-wg@listhub.w3.org; Wed, 03 Jul 2019 20:22:34 +0000
Received: from mail-vs1-xe2f.google.com ([2607:f8b0:4864:20::e2f]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <bemasc@google.com>) id 1hillw-000437-Bi for ietf-http-wg@w3.org; Wed, 03 Jul 2019 20:22:33 +0000
Received: by mail-vs1-xe2f.google.com with SMTP id s141so603486vsc.3 for <ietf-http-wg@w3.org>; Wed, 03 Jul 2019 13:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8L3W8TaNzHjN0U1JTOjaO2KTpH2pDFFsp8738Z1Ga34=; b=pAfzdF/u7c4JqXIY3vejfSJsRBwx9Pevq8CQJh1D94k5h25pbEpe9V0XOyf3Z54XhR tqoSM0u7aZy358HqIl9GZd0CjiWZdTUZlTEFtG+8a3Ekgx9OM/T66EiiycJHJp0Ci75q MFKSlqlMljqzD1GLazRCB1Ei7Pt2a0ipKlu7N6LGmsXpZuYYfKHty0gaX3Eah3aqw1Ot e02s6KtD6oaeyuEQ9hKIGlbUUCqzVohFSp1sdYxh5eupdc6o8hiDdPQM9JvEGcTI9WL4 gEOxtPQfoODGKFRm0KMa9KCJxRL6yLLapbFZJUwH5C+ZaSbonHEQrgWEfkeISjp4SiXz OIJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8L3W8TaNzHjN0U1JTOjaO2KTpH2pDFFsp8738Z1Ga34=; b=IAtK/Nxojf4L0gMtTh2UP4GDH05zPeKWQqcKrURqwCmPeUY5paS8NP2eCRGlsCvDx8 mKp36RXUdtrHDfqiq2AfuuLJwTn90V9GjCP7pngGvDlbVv/S8qeaQqP9DTOi2LgFxNSl vDbTruQIm0W7U5VeuV9ANSPSG5TfPFUI+2aWi6rJT62rJLmhoZyCk6H4TVZymAq2J9XV v96osDaUI1MKg62kdvBnJ2y3Ov8ILOV7CSXnKsfKki1Xrwu+lM0PIwmssXDjSGEkhfN8 tx1ajuo2E1mnt+kmidoKU7AmTZDeyts5HyDZDsXwWlIJOyjV21JpedqVwHzyE1e4bzwp WqUg==
X-Gm-Message-State: APjAAAXfFD4xk9ByXD7jtX20VmPuPxwNHi4ulds6mEFtzZREDSvw2Kh/ mfuAhb5BGbc2EYpLy1fXn5TvTKiGCwF7EefDHexFovDB
X-Google-Smtp-Source: APXvYqxzEGAnTfJmD7CeFw2kFn80mAMFiyhLjdf5AvHk4uwGvcLgmCry1lrybvsqPmdL6TEJLm6L4wx+6OtZdRGN7JY=
X-Received: by 2002:a67:cd9a:: with SMTP id r26mr19577607vsl.152.1562185330575; Wed, 03 Jul 2019 13:22:10 -0700 (PDT)
MIME-Version: 1.0
References: <CAKC-DJikByP+wX-GoD6ntpUWTbr6ioJzB4i8nGQL4NtPWePL3g@mail.gmail.com> <20190703195457.GA2536105@LK-Perkele-VII>
In-Reply-To: <20190703195457.GA2536105@LK-Perkele-VII>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 03 Jul 2019 16:21:59 -0400
Message-ID: <CAHbrMsDZ2D_e2xWbNnc3CcR-Sf7oQZc+6_qRjjk=JCw3zedAKQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000be383e058ccc9d3f"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e2f; envelope-from=bemasc@google.com; helo=mail-vs1-xe2f.google.com
X-W3C-Hub-Spam-Status: No, score=-18.8
X-W3C-Hub-Spam-Report: AWL=1.833, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hillw-000437-Bi c96160f075ea86a38055d73ee6510e01
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTPSSVC record draft
Archived-At: <https://www.w3.org/mid/CAHbrMsDZ2D_e2xWbNnc3CcR-Sf7oQZc+6_qRjjk=JCw3zedAKQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36749
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Wed, Jul 3, 2019 at 3:58 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Jul 03, 2019 at 02:45:47PM -0400, Erik Nygren wrote:
> > Ben, Mike, and I have submitted the first version of a proposal for an
> > "HTTPSSVC" DNS record.
> >
> > TL;DR:  This attempts to address a number of problems (ESNI, QUIC
> > bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for
> HTTP,
> > etc) in a holistic manner through a new extensible DNS record, rather
> than
> > in a piecemeal fashion.  It is based on some previous proposals such as
> > "Alt-Svc in the DNS" and "Service Bindings" but takes into account
> feedback
> > received in DNSOP and elsewhere.
> >
> > Feedback is most welcome and we're looking forward to discussing with
> > people in Montreal.
> >
> > Draft link:
> >
> >       https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01
>
> Some quick comments:
>
> - What if SvcDomainName has length different from its length field?
>   DNS wire-form names are self-delimiting (DNS message parsing relies
>   on this).
>

Thanks for the review!  The serialization format can definitely be
improved; we want to make it easy to implement and consistent with typical
DNS practices.

The current rationale for the length field is that we need some way of
distinguishing the empty name (i.e. "", meaning "absent") from a name
consisting of an empty label (i.e. ".").  I agree; there's probably a more
intuitive way to represent that.  Suggestions welcome.


> - What does it mean for SvcDomainName to be absent in alternative
>   service form? I would guess it means "same as RRNAME".
>

Sort of.  Alt-Svc has a concept of "uri-host omitted", in which case the
connection proceeds to the same host.  I think the net effect is the same.

I agree, this seems like something the draft should clarify.  We also need
to figure out what the text representation is.


> - Why there is length field for SvcFieldValue? Why not let it run to
>   the end of record?
> - 2 byte length field can encode values up to 65535, not 65536.
>   And the length of SvcFieldValue can not be that big, because
>   RRDATA and DNS message length limits (both 65535) would be hit.
>

Suggestions welcome.


> - Why 302 redirects instead of 307? 302 is frequently buggy.
>

You're right, 307 is probably closer to what we mean.


> - I-D.ietf-tls-tls13 -> RFC8446.
> - Is there any envisioned use for chained HTTPSSVC records, except
>   for type 0 record pointing to type 1 record?
>

You can also have longer chains, (0 -> 0 -> 1), but type 1 does not chain
further.


> - The MUST requirement to have only one type 0 record and then
>   SHOULD behave non-deterministically if this is violated is pretty
>   odd.
>

Agreed, we can improve that recommendation.


>
>
> -Ilari
>
>