Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

Ted Lemon <mellon@fugue.com> Thu, 02 August 2018 14:54 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F7130E8D for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 07:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 3ryu0O40Scl1 for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 07:54:41 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFBB130E8B for <dnsop@ietf.org>; Thu, 2 Aug 2018 07:54:38 -0700 (PDT)
Received: by mail-it0-x243.google.com with SMTP id h20-v6so3635341itf.2 for <dnsop@ietf.org>; Thu, 02 Aug 2018 07:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WtPM2RwLGGXDP/Ql2qpmXvnPjUWuIoeEIu1cK1XHizc=; b=dAh7RGbE0P77X9sWjTcA3sjjzwtAd/SpJ5nD1892d2yvORyeonFS3QiHhwpN6/pyRX COP/JHPok7NsLM/CRxeJXjYOuHdKYY4/3zHwUq2kcKQAkauZT404hQiu+7ACvgksKNmF SAMo1KphKnrwBq7egsTCWVDMOqOerB7DFz/6lBhpM+OtRqZbzNQ54it7Cqs/8PEVIh7n d6sdgekxSGoChyW0mt2PiAMHOeqXGOqaxI1kkKME6/e+OsfvZaKnnHrCb0stHkEEKUOz uFCuPrLldNume+03L3pWUjPVCiwAQNaW9nXfczRVh4aLk9B0ed0EEO62nJDwRcHz8ewj XkIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WtPM2RwLGGXDP/Ql2qpmXvnPjUWuIoeEIu1cK1XHizc=; b=GUasgzhlVSXNOZSN4CS5wIMLHJK0cjWh1+hXrmiatn6KMzifi4CD5by/1GLQCtkEfu y+eaeXOwD8vYn5r8hpokuANfhOQrwGU650arKyAxbWQLULrskmPhIgIaQjjJlfeWvNIk 5HQH4JOs5MXhmqvJuh9olS5UT5HeEtKfunnTyyXyYw10ncVw/5zTqo9IVwqFZEDg7QbQ t+jqjWF+T0wxCwvWQE76eWKjsXkNtVQi3NnTZOZyTWcTF95iqovOkGg4kRPl+dvswWNi uSFre3t0cUv7A7xTRIvDbm4G3QB2+XrSi826AszhHStehAtjZ4bJtmGyEgtjFX9qztg0 a1+g==
X-Gm-Message-State: AOUpUlFGhpaV0gSS+8gLlKc0Ep5xz0EvT9+kSQTEq6atcCkEWYaJozG0 xff0rMPl2bnezbUPI//PaGsVow4ih+72LcaU8n15tA==
X-Google-Smtp-Source: AAOMgpeH3xhRn+Mu/fy6krL0aFlmyqpZvm/9ksliRBCfLvvb9zSMhdCEuBvwmLo6QPo0Ls+zGBUAUwmhB2kqHntLexo=
X-Received: by 2002:a24:8a85:: with SMTP id v127-v6mr2811842itd.98.1533221678026; Thu, 02 Aug 2018 07:54:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 07:53:57 -0700 (PDT)
In-Reply-To: <20180802135436.GF96369@kduck.kaduk.org>
References: <153270509617.32757.1191915890190419981.idtracker@ietfa.amsl.com> <EFFB4DC5-5A4B-4EAB-8B9F-56229080CDF0@bangj.com> <20180802135436.GF96369@kduck.kaduk.org>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 02 Aug 2018 10:53:57 -0400
Message-ID: <CAPt1N1nBjdb4H91bLR1u1XbNJ5L0Rw=Q9_T_8HVWYq+bUocNkg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Tom Pusateri <pusateri@bangj.com>, The IESG <iesg@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop WG <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007b2f96057274fd32"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NDyw7TOrIwXsgcIkQ1B3nD2HLFg>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2018 14:54:44 -0000

On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> > We specifically didn’t want to reference DoH since HTTP is unsuitable
> for long lived connections and DSO wouldn’t apply here. We didn’t want to
> imply that DoH was suitable by referencing it.
>
> Hmm.  I think DoH is clearly a non-UDP transport for DNS, and it is hard to
> argue that it is not being specified.  My parenthetical suggestion was
> probably a bit unclear -- I was proposing to add DNS over HTTP to the list
> in the first sentence, and change the second sentence to start as "Some
> such transports can offer persistent[...]".  Does that still seem like it
> runs the risk of implying that DoH is suitable, to you?
>

Rr.   Okay, I agree with you and when I went to do this, it occurred to me
that we are being silly here—this document has no applicability section.
 Adding one will really clean this up a lot.   So I've done that:

@@ -106,9 +106,11 @@ This document updates RFC 1035 by adding a new DNS
header opcode and result code

 # Introduction

-The use of transports for DNS other than UDP is being increasingly
specified,
-for example, DNS over TCP {{!RFC1035}} {{!RFC7766}} and DNS over TLS
{{?RFC7858}}.
-Such transports can offer persistent, long-lived sessions and therefore
when
+This document specifies a mechanism for managing stateful DNS connections.
+DNS most commonly operates over a UDP transport, but can also operate over
+streaming transports; the original DNS RFC specifies DNS over TCP
{{!RFC1035}}
+and a profile for DNS over TLS {{?RFC7858}} has been specified.
+These transports can offer persistent, long-lived sessions and therefore
when
 using them for transporting DNS messages it is of benefit to have a
mechanism
 that can establish parameters associated with those sessions, such as
timeouts.
 In such situations it is also advantageous to support server-initiated
messages
@@ -399,43 +401,40 @@ and to assure client and server that they still have
connectivity to each other.

 ***

+# Applicability {#applicability}
+
+DNS Stateful Operations are applicable in cases where it is useful to
maintain an open session
+between a DNS client and server, where the transport allows such a session
to be maintained, and
+where the transport guarantees in-order delivery of messages, on which DSO
depends.  Examples of
+transports that can support session signaling are DNS-over-TCP
{{?RFC1035}} {{?RFC7766}} and
+DNS-over-TLS {{?RFC7858}}.
+
+Note that in the case of DNS over TLS, there is no mechanism for upgrading
from DNS-over-TCP
+to DNS-over-TLS (see {{?RFC7858}} section 7).
+
+DNS Stateful Operations are not applicable for transports that cannot
support clean session
+semantics, or that do not guarantee in-order delivery.   While in
principle such a transport
+could be constructed over UDP, the current DNS specification over UDP
transport {{RFC1035}}
+does not provide in-order delivery or session semantics, and hence cannot
be used.  Similarly,
+DNS-over-HTTP {{?I-D.ietf-doh-dns-over-https}} cannot be used because HTTP
has its own
+mechanism for managing sessions, and this is incompatible with the
mechanism specified here.
+
+No other transports are currently defined for use with DNS Stateful
Operations.  Such transports
+can be added in the future, if they meet the requirements set out in the
first paragraph of this
+section.
+
 # Protocol Details {#details}

 ## DSO Session Establishment {#establishment}

-DSO messages MUST NOT be carried in protocols and
-environments where a session can't be established.   For example,
-DNS over plain UDP {{?RFC0768}} is not appropriate since it does not
provide
-in-order message delivery, and, in the presence of NAT gateways and
firewalls
-with short UDP timeouts, it cannot provide a persistent bi-directional
-communication channel unless an excessive amount of DSO keepalive traffic
is used.
-UDP also doesn't provide a way to mark the start of a session and the end
-of a session.
-
-At the time of publication, DSO is specified only
-for DNS over TCP {{!RFC1035}} {{!RFC7766}}, and
-for DNS over TLS over TCP {{?RFC7858}}.
-Any use of DSO over some other connection technology needs to be
-specified in an appropriate future document.
-
-Determining whether a given connection is using DNS over TCP, or DNS
-over TLS over TCP, is outside the scope of this specification, and
-must be determined using some out-of-band configuration information.
-There is no provision within the DSO specification to
-turn TLS on or off during the lifetime of a connection.
-For service types where the service instance is discovered
-using a DNS SRV record {{?RFC2782}},
-the specification for that service type SRV name {{?RFC6335}}
-will state whether the connection uses plain TCP, or TLS over TCP.
-For example, the specification for the
-"_dns‑push‑tls._tcp" service {{?I-D.ietf-dnssd-push}},
-states that it uses TLS.
-It is a common convention that protocols specified to run over TLS
-are given IANA service type names ending in "‑tls" {{IANA-SRVNAMES}}.
+In order for a session to be established between a client and a server,
the client must first
+establish a connection to the server, using an applicable transport (see
{{applicability}}).

 In some environments it may be known in advance by external means
 that both client and server support DSO, and in these cases either
-client or server may initiate DSO messages at any time.
+client or server may initiate DSO messages at any time.  In this
+case, the session is established as soon as the connection is established;
+this is referred to as implicit session establishment.

 However, in the typical case a server will not know in advance whether a
 client supports DSO, so in general, unless it is known in advance by other
means
@@ -443,10 +442,11 @@ that a client does support DSO, a server MUST NOT
initiate DSO request messages
 or DSO unacknowledged messages
 until a DSO Session has been mutually established
 by at least one successful DSO request/response exchange
-initiated by the client, as described below.
-Similarly, unless it is known in advance by other means that a server
-does support DSO, a client MUST NOT initiate
-DSO unacknowledged messages until after a DSO Session has been mutually
established.
+initiated by the client, as described below.   This is referred to as
explicit
+session establishment.
+
+Until a DSO session has been implicitly or explicitly established, a
client MUST NOT initiate
+DSO unacknowledged messages.

 A DSO Session is established over a connection by the client
 sending a DSO request message, such as a DSO Keepalive request message
({{keepalive}}),


> > How about:
> >
> > When a new TLV is defined, the specification MUST include whether the
> DSO-TYPE can be used as the Primary TLV, used as an Additional TLV, or used
> in either context for both requests and responses.
>
> That's probably better (but maybe another comma before "for both requests
> and responses"?  OTOH, the RFC Editor has a consistent style book to
> apply...)
>

I updated the text to make it more generally imperative, and to be really
explicit about the point you're making rather than just hoping the comma
will be enough.  :)

Specifications that define new TLVs must specify whether the DSO-TYPE
can be used as the Primary TLV, used as an Additional TLV, or used in either
context, both in the case of requests and of responses.
The specification for a TLV must also state whether,
when used as the Primary (i.e., first) TLV in a DNS request message (i.e.,
QR=0),
that DSO message is to be acknowledged.
If the DSO message is to be acknowledged, the specification
must also state which TLVs, if any, are to be included in the response.
The Primary TLV may or may not be contained in the response,
depending on what is specified for that TLV.