Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

"Jan Komissar (jkomissa)" <> Wed, 14 February 2018 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEDCE1201FA; Wed, 14 Feb 2018 14:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mThmdqFvivG2; Wed, 14 Feb 2018 14:12:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A681812426E; Wed, 14 Feb 2018 14:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3662; q=dns/txt; s=iport; t=1518646350; x=1519855950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t66nqsmZK2Y/v6sKPnCM+pQcWyQOXDJbxmLknPgZ20s=; b=WozJXNxe20tOjduI43WH8ahUF7Q8WQvHLGnEX5j7i83+THY6rd1Utda5 EjI67Cm8NY1ynCS8YVf9A1z3D2nWDbYR3NbpngCTgHf+OORyvGYuTbkJ0 2qQtHSeZbFpsWaHiIUKab5SArBDoXojqa2hySRJgtAK7SPVvbRR5h0ZAX E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.46,514,1511827200"; d="scan'208";a="70408039"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 22:12:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w1EMCTrt004967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 22:12:29 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 16:12:29 -0600
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 16:12:29 -0600
From: "Jan Komissar (jkomissa)" <>
To: Paul Hoffman <>, dnsop <>
CC: "" <>, "" <>
Thread-Topic: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
Thread-Index: AQHTm5D+P8Hdt54fVUSceurV+Y+5IKOSDxkAgBKMVQA=
Date: Wed, 14 Feb 2018 22:12:29 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Feb 2018 22:12:33 -0000

Two items related to this:

1: I think that it would be better to require TLS for all DSO connections. This document (DSO) specifies that it should use TCP or TLS for connections, but the DNS Push Notification (DPN) draft requires TLS. This would complicate matters if a standard TCP connection was opened for one purpose and later a DPN operation over the same connection was attempted. Also, it improves security for all DSO operations.

2: I also believe this document should only support DSO over TLS, not session based protocols in general. If there is a need/desire for doing DSO over other protocols, a new RFC allowing each protocol would be required. This requirement will ensure that all implementations of this draft would interoperate. (If DSO-over-X and DSO-over-Y both are compliant with this document, they are not likely to interoperate even if both X and Y are session based, which would defeat the purpose of a standard.)



On 2/2/18, 4:58 PM, "DNSOP on behalf of Paul Hoffman" < on behalf of> wrote:

    The current draft is hand-wavy when it comes to which transports DSO can 
    run on.
    Section 2 says "such as":
        The term "connection" means a bidirectional byte stream of reliable,
        in-order messages, such as provided by using DNS over TCP
        [RFC1035][RFC7766] or DNS over TLS [RFC7858].
    Section 4.1 says "are suitable":
        Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858]
        are suitable protocols.
    The document should explicitly list which protocols are currently 
    acceptable, and say that the list can change in the future based on 
    standards-track documents. Proposed wording for both of these above are:
    Section 2:
        The term "connection" means a bidirectional byte stream of reliable,
        in-order messages.
    Section 4.1 says "are suitable":
        DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766]
        or DNS over TLS [RFC7858]. This list might expand in the future, 
        an expansion MUST be in standards-track RFCs.
    Having developers know exactly which protocols can be used is important 
    so that they do not use protocols that they accidentally think are 
    reliable and in-order. For example, the DOH WG is working on a protocol 
    that might initially seem attractive, but it does *not* qualify for DSO.
    --Paul Hoffman
    DNSOP mailing list