Re: [DNSOP] [dnssd] 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: 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 22F731201FA for <dnsop@ietfa.amsl.com>; Wed, 14 Feb 2018 15:13:54 -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=ham 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 l595EcsO1Q-D for <dnsop@ietfa.amsl.com>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 344E912704A for <dnsop@ietf.org>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id k25so3838393qtj.9 for <dnsop@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=WNNoef8BAMjIB3V361jPZVVgI4D+VgVfSJzrNxTcCJFYOcmqdwQMI47beHk6K0PxTL svYw7yeTW8l8Fy/KM6zGO3hezU20Ee8fvUgtT9bDxb38ltPO/sNTZwcIvhpV7jtdS6EC RDym7D/q7gONSBM5w/Ny43O0dZnb01MoOZNMWiwJoNtzjVfswLeZZZmW6Kr2s9OT3t9U vn6dp/ufPzIOphCVHqYrZKfkvPF05Nhe3gfj6cM4lpUAWw5Qo0CPopbY+QaE1Z48cpAS dS3HDD4q/E1ddp9u7ziYUCsXhMDXbTz+tlwxphZU6FggO0G60KsVJU3AxPoe2UdlMEP5 h6cw==
X-Gm-Message-State: APf1xPDIlPwAeNj4AwK6OAh624vccEMJZcg0W1eNN0ijTtdnYDHQUWpQ ggf5FAk3la+zECCQaVeDuXt36w==
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/dnsop/fyLyshfLGH4EQbS0NG3Fgm7aY0c>
Subject: Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 14 Feb 2018 23:13:54 -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?