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

Ted Lemon <> Thu, 15 February 2018 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 904D01243F3 for <>; Thu, 15 Feb 2018 15:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 55rBXQPlmXaB for <>; Thu, 15 Feb 2018 15:36:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DCBA127419 for <>; Thu, 15 Feb 2018 15:36:35 -0800 (PST)
Received: by with SMTP id n198so1800710qke.7 for <>; Thu, 15 Feb 2018 15:36:35 -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=0yaGdAfOHbPLrs65bAX2XuzMgQaBTAFEMFd7jQ0E74M=; b=1KxMT45LKsxKpJ0pwPbPLrvbeA9rJcvJ87kH/YEsaiq81hUNUhDxlHrZerLKYNYYeO EWE9WylBy/ASXB1DJRke3AjSb/CjNrWPBDoFGsBnAW0WsorOmsOWsJLj0FpbtK7S3gTk iSWVG7foIqSlBSmt5CsTJOuCG+hyM/7A1H40IfGT5qn+Zu7qbX2LL5FL3Zovm/EvjbMh Lod7ZDYyfp9dpN4jzSnCtljE59/0fli/HYaGIaOgD4qQ74uPc+zDlLsC8s6Yw29Ne6uc GZOIpHJhYokD/ZwUlc3eX+Jm6LmO3KweJGiVxtEE8op8CYl3cRJTbeOVPv7CjVnnJ9u6 iagA==
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=0yaGdAfOHbPLrs65bAX2XuzMgQaBTAFEMFd7jQ0E74M=; b=t3E6Sfp0hA9Hvgl0nENT70MInSUH0nZOeekXz6CApDueR40xCCgfVvsliJ7TQ459HB 7P+d7h+6F/15tw3d/75fAL/JAK1RbO6p+Kp9a7fzuJ92S6mMGuxXJ/lBz9qjO17xIrE7 LDGzAp27/Z+e4SemIN2J+fHnGyJr6tmxVzz/WPNLMLi5JxaoHssfknVsYr2Yh0vmrRZK /zSnoJEsDD5MaCGWemUyEBOGO6RxaBqCBD6I9yFx4ogrVKdqNCZZ7jDyjiUN3uBF06aa cWXFtFl4o8NNbn8Iy75zC4AtY7dTDoThfO0lnyilulpLYapjBSwLHTVvEcYmRM4haPy2 UFQA==
X-Gm-Message-State: APf1xPD7NdLTMG3V1jOo4Mbq6q3qEG25kdovh1nw0kcaYxz/UeMeqMPQ TDrb53dRC2ZFgByo1GBsuG+Zbw==
X-Google-Smtp-Source: AH8x227z98pmMrQgs8EIv0uRAat7dnUUkpoKgll4hrATmNXMKeMdCosf+VEwILp4m7UfY2u/aFIadQ==
X-Received: by with SMTP id f20mr7079721qkf.290.1518737794189; Thu, 15 Feb 2018 15:36:34 -0800 (PST)
Received: from cavall.lan ( []) by with ESMTPSA id l80sm1469620qki.92.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 15:36:33 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_561A9D11-9ED4-4695-8315-4EE7D0B0284A"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 15 Feb 2018 18:36:31 -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: Thu, 15 Feb 2018 23:36:38 -0000

On Feb 15, 2018, at 5:34 PM, Jan Komissar (jkomissa) <> wrote:
> After pondering your response, my comments are inline:


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

Understood.   One way in which this certainly makes sense is that although DNSSEC can be used to authenticate DNS data, DSO data can't really be validated that way.   And we don't have TSIG either.   So it's certainly worth considering.