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

"Jan Komissar (jkomissa)" <jkomissa@cisco.com> Thu, 15 February 2018 22:34 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 198F812D947; Thu, 15 Feb 2018 14:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 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, 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 (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 aFhGgi9S5Uym; Thu, 15 Feb 2018 14:34:50 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DEA12D837; Thu, 15 Feb 2018 14:34:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15936; q=dns/txt; s=iport; t=1518734090; x=1519943690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rpNomXkibcde4/zpprxgOXJqv8U1kFY5ctkdsAjoFAA=; b=M51IRbDgAn0R420mYYDk98cWmKA6ZGCTmobqj3stfMD9WYJUDDjOedZI 6Tx0wiWQCa9SJ/h54ei0qvvM8mOGjRfBUaE/QSIpW+jRImHsCDWvk4OCo tvLVTiDRtlUjzroCHzgrLIzJ6I4R/i01hNse/h04MqZj0nhNfYr82WY6t 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DPAADNCoZa/51dJa1dGQEBAQEBAQEBAQEBAQcBAQEBAYJaeGZwKAqDW4oljgKCAnwbkGmFXIIYCoU7AhqCKFQYAQIBAQEBAQECayiFIwEBAQQjVhACAQgOAwMBAigDAgICMBQJCAIEDgWJUWSvP4InJohPghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhQOCJ4FXgWgpgk82hQw2FoJhMYI0BaQyCQKWA5RGl28CERkBgTsBHzmBUXAVZwGCG4R3eIx9AYEYAQEB
X-IronPort-AV: E=Sophos; i="5.46,518,1511827200"; d="scan'208,217"; a="70920066"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 22:34:49 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w1FMYmOK011153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 22:34:48 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; Thu, 15 Feb 2018 16:34:48 -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; Thu, 15 Feb 2018 16:34:48 -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//uH4AgABVzICAATOegA==
Date: Thu, 15 Feb 2018 22:34:48 +0000
Message-ID: <3F61D530-DD24-40A3-B6C8-C6EC7936784E@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> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com>
In-Reply-To: <34561144-6844-4E00-90E9-41095A9E14E6@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_3F61D530DD2440A3B6C8C6EC7936784Eciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/KDYvu9TS4CJ-q9kvzy-C1JVtyZA>
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: Thu, 15 Feb 2018 22:34:53 -0000

Hi Ted,

After pondering your response, my comments are inline:

From: Ted Lemon <mellon@fugue.com>
Date: Wednesday, February 14, 2018 at 6:13 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 6:06 PM, Jan Komissar (jkomissa) <jkomissa@cisco.com<mailto:jkomissa@cisco.com>> wrote:
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.

Hm, is that really true?   What is the scenario that you envision here?  Like, when would this actually happen?   What's the client that's making the connection?   How is it that it is the same client that's doing DPN?   If it is configured to support TLS, why isn't it defaulting to that?

Jan:
I was imagining a single operating system service performing all DSO based operations on behalf of various applications, but it would probably more likely be one service for all DPN users and another for protocol Z users, and the existing stub resolver for traditional DNS queries. And in that case, there would be no reason to force all DSO based operations into TLS. I can live with that.

 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.

I think I've heard other suggestions that we should enumerate which protocols are supported explicitly, but I don't think there's a requirement to support DSO over anything.   We're just describing a new DNS message type that can be used with any connection-oriented protocol.

Jan:
Upon further review, I agree.

You didn't answer my third question:

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?

Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP optional?

Jan:
It would be nice if we could make steps towards more secure DNS communications, and since DSO requires new client code, it could be a way of moving in that direction. I’m not ready to deprecate DNS-over-TCP, there are probably too many existing clients and servers deployed to start that process. On the other hand, if we want to improve communications security, it might be good to find ways that strongly encourage implementers in our space to adopt secure protocols, and making new features secure is a way to do that. So, it’s not that DSO is special, but It’s an opportunity to improve DNS security. That’s why I would prefer the draft to require TLS. If the WG disagrees, so be it.

Regards,

Jan.