IETF Logo Mail Archive

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

Ted Lemon <mellon@fugue.com> Wed, 14 February 2018 22:22 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 7B1E8126B6E for <dnsop@ietfa.amsl.com>; Wed, 14 Feb 2018 14:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, 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 KIhNcgtk6ikX for <dnsop@ietfa.amsl.com>; Wed, 14 Feb 2018 14:22:41 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 6159312426E for <dnsop@ietf.org>; Wed, 14 Feb 2018 14:22:41 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id g129so14111924qkb.13 for <dnsop@ietf.org>; Wed, 14 Feb 2018 14:22:41 -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=Va/WnRcXkAVQ7RmBTM2qWR0Jt7LMH1XDRxKLreaKw8Y=; b=ajep751TJKDRT0Wa21TH7que9tRmEDdbR3HOCq3+0Yyi0XIX73MAy+Fa3/nkz6cC9J 4sVY2WfqRo++tgDpVjx46alWa3h6S9hZhZn62m5OOhth22kZzgm3tyOPm0MufvJD6Zkh YwrgnP2QQkTTWU3sfn/wSK/bHju4KwSZiFr1HmPuUdjd1891uLlABbY+pzDKO+FRSHY/ DzNKBeCTJG5+AUQ2kBpl2sTW0KxWF2HAtu0Bbvm5r16Ib8C9QIgvyHYaOIIgb2FJgaY5 XW1s8k15YITSkpSrYEgJB/h5+TFLY5j/WSXiRrD0LKc2suWI+dwl7X//RBYarT/tZp6o Ebxg==
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=Va/WnRcXkAVQ7RmBTM2qWR0Jt7LMH1XDRxKLreaKw8Y=; b=jVl7za/4AqIu5C6rZoVaUWQcn6+K1vNNvlZZaikUF3Dv5rvmSG4xvhpBISe1Z1e3K0 npGSZApxUmTrhE7PPxVI0vfQoMeCXKfSpSK0aykU9s6g3d+nO5WNaBxZYgpfXvNEABvl fo3EoSyb19gywZ7ikB/dW2F1CSEY5C2tb0elPUNNxrpRxPhJ+NFaBM5TGW2sOc/wLzBt O7bNF0GfhgNYQfhNfczoUxgzo9gNlltlICYRLjaeUaP8mlkgM3DsoUI5VUSe+hHlVey2 hiVNimVC5LujSXxxhzts5CzZUhJLpPRLpJPSAAKbRMhtkzNOaH3+zVNJowbGHAWvjYsL 7y6Q==
X-Gm-Message-State: APf1xPD8jQqtbMak9QvN8VnY8FyGIpWDD7bP48UPQzA5gC5l/1OkqE2f 6BI8Mo4mQySkXPQO+Cz9905Bcw==
X-Google-Smtp-Source: AH8x226x9yEXS91ogH/bJ60toKV6PCc+/yRoVhhGQ6CymFupAzKkFQ+zX2tj/YchSceR8iju/YII+w==
X-Received: by 10.55.102.134 with SMTP id a128mr1021837qkc.122.1518646960576; Wed, 14 Feb 2018 14:22:40 -0800 (PST)
Received: from [10.0.1.16] ([8.20.190.66]) by smtp.gmail.com with ESMTPSA id g42sm1044260qtb.96.2018.02.14.14.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 14:22:40 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <976312C8-4424-4642-A150-21F25FB137EE@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7307901A-0BFE-4C86-8B0D-9CEB69592114"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 14 Feb 2018 17:22:38 -0500
In-Reply-To: <02FF7C21-3421-40C5-A530-BE1D814237B2@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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hLjumKUgENhbAo8ct5lgTatAIpk>
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 22:22:44 -0000

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

v2.23.0 | Report a Bug | By Email