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

Ted Lemon <mellon@fugue.com> Wed, 14 February 2018 23:13 UTC

Return-Path: <mellon@fugue.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 AA2F5126FB3 for <dnssd@ietfa.amsl.com>; Wed, 14 Feb 2018 15:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 Le3Fa5Ng3d3k for <dnssd@ietfa.amsl.com>; Wed, 14 Feb 2018 15:13:54 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 3444112700F for <dnssd@ietf.org>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id c19so9816562qtm.7 for <dnssd@ietf.org>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LcAG1GklvpMReCOBKC51IEAmNOw3TB+r4CSuOQBhkOc=; b=bIBOALsByzQrUvYRCy1SGL7HL7nq0XIj6lbmHqpkohJypQkqEMP8MyGkE2ZoYpr2Km lT+yexGD8e+c+hh0FjcI4uE13uA5xLBfCdaZlpiyRizp+riLtxCj4evhRLD3huG3SuEA qkU8R6mUwpgzGA7nM+lFuQzFUGOG40KRcPsyRjmXy43ID1NvUqHuYXpr/Fd9VxE+nKFc 6pLynsK1iwPN10/uDBna3hYoPPxfYGY+ruAQhCAnMV6jvh24XZPFAm2Aw61Ut8k5kesF O11ul0MM8WpvcSSZGSiNQH9cp/D2X4ViVDJb+TpmZVDXOW3gW4dhogN3N1r3DxeENlnE goyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LcAG1GklvpMReCOBKC51IEAmNOw3TB+r4CSuOQBhkOc=; b=jIpsk8HjWnBJJdfoJ0uvRIwIER8YD6QorS3+S0HnJ77mzPRN/NXbB3l2IR85vVZVD/ eb+khSnb0SjlvCJzW68ziRRm/0R1R61HbWGEHEO50f0wpYCcTUf13ViG2m8atx+MRX0a YVZKvf/GQUJ3MhrPMHknD51dk0nD2sTzYCEiIeGaKyQgF0NIcUlL6kD4z2QHEUCcgBCa KZiOH8KMNssFpuNajzkm6VAJcloRl/ncCegWd1Grqfacc75SAS3Iklyv3o/DemyHfWL5 JbEiAwu9tJddC5NQXuxm4zGW2SN9xbHbozTubZtv09wwtyf8lyPF0uaqz0uijmp9VZKc Hw7g==
X-Gm-Message-State: APf1xPAg5FcQYEqxP8pmRfbGFqambo9K5eaACqaojvJN0c/God8S4UHG TCanA7axfAOKYnEb+fU3qz5LxMf3GYc=
X-Google-Smtp-Source: AH8x227gc9/qbzlqt8WzTf9jSTvJYejLPKKEUIBbffa6iZ2nsM7Nf65u9tGeng8gc3f8zVRwmcpb3w==
X-Received: by 10.200.53.121 with SMTP id z54mr1266378qtb.278.1518650031207; Wed, 14 Feb 2018 15:13:51 -0800 (PST)
Received: from [10.0.1.16] ([8.20.190.66]) by smtp.gmail.com with ESMTPSA id w63sm908778qtd.76.2018.02.14.15.13.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 15:13:50 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_06F1DF30-8E0D-43FB-991F-A0C44D12D6F3"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 14 Feb 2018 18:13:47 -0500
In-Reply-To: <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@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>
To: "Jan Komissar (jkomissa)" <jkomissa@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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/-3s9eiA0T6P9vQxaQqr4BSwSHAc>
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:13:56 -0000

On Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) <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?

>  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.

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?