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

Ted Lemon <> Wed, 14 February 2018 23:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46138126CD8 for <>; Wed, 14 Feb 2018 15:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NhkAQhGDLN_K for <>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3524212711B for <>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
Received: by with SMTP id u6so9816737qtg.13 for <>; Wed, 14 Feb 2018 15:13:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LcAG1GklvpMReCOBKC51IEAmNOw3TB+r4CSuOQBhkOc=; b=eVKmsyrUzkwfjZ94ZRyoM+QAnCHI1t1Y9hjCeWPdoWmy+NS/ya2rMwB4FvHI7UxqnQ EAq9oYMES46p/NZsAoeuARDo7tqG7HKvFK60RutU2cRZiy5t8N91Ty8h/fUBmvV3G0iv 0gZEZH/yCElJ/iAhvncMSmnFMbifWa1Kc1oS/6+dr7qysVqli7aUgBrA/TP854Jw6tTQ fNciBKTdQQvl3Tgqx8vcexsK2yIjHZ/qAtpCuSqaXA7sQzTyv2NQXKD8QLP9+Gpc+Q98 0FbOdV+v9r60qKNbbiwP3R5JT+wjlEHNkg1e8i6zCxvEMQMI2a+7/hf34aEDRttVSzgz kE7w==
X-Gm-Message-State: APf1xPCAQ5ykfvO2vyueVMHxb6NzmHRre6jyFTARqONSbIO3UOyoeDjP sSa7MRHtKZ3fF1bDKl6pcjUEXQ==
X-Google-Smtp-Source: AH8x227gc9/qbzlqt8WzTf9jSTvJYejLPKKEUIBbffa6iZ2nsM7Nf65u9tGeng8gc3f8zVRwmcpb3w==
X-Received: by with SMTP id z54mr1266378qtb.278.1518650031207; Wed, 14 Feb 2018 15:13:51 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id w63sm908778qtd.76.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 15:13:50 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
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: <>
Cc: Paul Hoffman <>, dnsop <>, "" <>, "" <>
To: "Jan Komissar (jkomissa)" <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Feb 2018 23:13:54 -0000

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