Re: [DNSOP] [dnssd] 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 2FC6B126E01 for <>; Thu, 15 Feb 2018 15:36:37 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5v4SNQ2hO5Bh for <>; Thu, 15 Feb 2018 15:36:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1905D1243F3 for <>; Thu, 15 Feb 2018 15:36:35 -0800 (PST)
Received: by with SMTP id b130so1795502qkg.9 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=D5Lxt4pG/ev/LoCPVrmoKwhm/Glj6OG+2PSPoKSOP2lHXjHonVovCZPZJQXX2LJEAj 2foilTuTFdLJ7o5uhXxdUz+rwveFXtHC9zuh3rvIQXqf2vUVYOenVuCc0Iv+igt6EcEm rDFrvbSc9AWLyKgSBpHJ7B+jvvQ64Q5d9NYnJhJG/JnoVMoNIYdeAcseKIf95IEaycjt rjreFHue3vQPninKxEq/XzvE8jYNQDBS5Adey4MEbYTts9cE8uGszFUabN1PihKuUSWw WTtmel+ZFWZLDilVm6cNj+/KegpDapgDy1ieBrfVckmE7eUQDpgllThC/J3/2bCRj0bW rHfw==
X-Gm-Message-State: APf1xPAP+2ccBOSjN/k04a3G3m6gOtZD+D+1bnhAPFt40IxLEUpMk9Eu 2Vb9T6PcHX4gqXUA5nL6bij/jQ==
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: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Feb 2018 23:36:37 -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.