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

"Jan Komissar (jkomissa)" <jkomissa@cisco.com> Wed, 14 February 2018 23:07 UTC

Return-Path: <jkomissa@cisco.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CFA12700F; Wed, 14 Feb 2018 15:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QZoaubZDB1tx; Wed, 14 Feb 2018 15:06:58 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1855512704A; Wed, 14 Feb 2018 15:06:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11714; q=dns/txt; s=iport; t=1518649618; x=1519859218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J6G+VX0rxrp4D1kfjqb54u3X5v0S92NI+wVlCYFm2tk=; b=Ij9wm9Zucn5q4UbI7KViwccxpTUoVjyFhTXv0JjJvfor14DuDP+DIrOp ip1uL1n0JJNrN94NDz/OPLvcooY8HZjTsiR7eEUHAHzO+ySbEiBMUX1g+ USFX9ZKYCz46bcC43DJFjIvZ+kCdrhEd9UWOX+lMliKm24Ornr/Qfd9C1 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CcAgDVwIRa/4cNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJaeGZwKAqDW5goggKBF5BnhVuCGAqFOwIagmNWFgECAQEBAQEBAmsohSMBAQEEI1YQAgEIDgMDAQIoAwICAjAUCQgCBA4FiVFksAaCJyaIYYITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYUCghWBV4FoKYMFhQw2FoJhMYI0BaQvCQKWA5RFl2wCERkBgTsBJgsngVBwFWcBghuEd3iMaQGBGAEBAQ
X-IronPort-AV: E=Sophos; i="5.46,514,1511827200"; d="scan'208,217"; a="70392283"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 23:06:43 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1EN6hDl019437 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 23:06:43 GMT
Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 17:06:42 -0600
Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 17:06:42 -0600
From: "Jan Komissar (jkomissa)" <jkomissa@cisco.com>
To: Ted Lemon <mellon@fugue.com>
CC: Paul Hoffman <paul.hoffman@vpnc.org>, dnsop <dnsop@ietf.org>, "dnssd@ietf.org" <dnssd@ietf.org>, "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
Thread-Index: AQHTm5D+P8Hdt54fVUSceurV+Y+5IKOSDxkAgBKMVQCAAFapAP//uH4A
Date: Wed, 14 Feb 2018 23:06:42 +0000
Message-ID: <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com>
References: <CADyWQ+GsU9dL8D58Eko0w9mVRMMTZ7f9NQKx3a0XS7oUGHjniQ@mail.gmail.com> <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com>
In-Reply-To: <976312C8-4424-4642-A150-21F25FB137EE@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.67.103]
Content-Type: multipart/alternative; boundary="_000_5AFBBFBECF5A4F7A9AC9F7E0040BBABDciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/inYOEr8ar0xClziVQdsBjSWP5qg>
Subject: Re: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2018 23:07:00 -0000

Hi Ted,

I’ll try to clarify:

Currently, there are only plans for DPN, and that would force every connection to be TLS. However, if a future protocol “Z-over-DSO” does not require TLS, it is possible that a client would create a TCP connection for Z and later would want to send DPN operation to the same server. Note that the DSO client may represent a single computer, while the Z and DPN requests represent applications on that computer that implicitly depend on those two protocols. I guess a new connection could be created, but it would be better if not necessary.

The interop issue is related to section 4.1 that says that any session based protocol is suitable for DSO. If you make a server that only supports DSO over TCP and I make a client that only supports DSO over QUIC, they are both compliant with the draft, but they cannot communicate with each other. To avoid this, I suggest that this draft only supports TLS (and possibly TCP), and supporting DSO on any other underlying protocol would require a new document.

Better?

Thanks,

Jan.


From: Ted Lemon <mellon@fugue.com>
Date: Wednesday, February 14, 2018 at 5:22 PM
To: "Jan Komissar (jkomissa)" <jkomissa@cisco.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsop <dnsop@ietf.org>, "dnssd@ietf.org" <dnssd@ietf.org>, "doh@ietf.org" <doh@ietf.org>
Subject: Re: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

On Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) <jkomissa@cisco.com<mailto:jkomissa@cisco.com>> wrote:
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.

Jan, I'm having trouble following your reasoning here.   The client that makes the connection presumably knows whether or not it's going to do DPN.   Why would there be any confusion?

DNS-over-TCP and DNS-over-TLS are standards.   It's hard to see where the interop issue would be.   Can you expand on that?

Also, do you think that DNS-over-TCP should be formally deprecated?   If so, perhaps that's the right way to address this.   If not, can you say why DSO is special and requires TLS, when DNS-over-TCP does not?