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

Ted Lemon <> Wed, 07 February 2018 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA6BB12D7FB for <>; Wed, 7 Feb 2018 08:24:02 -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 Cgg3qhO6dBCq for <>; Wed, 7 Feb 2018 08:24:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 398E312D7F0 for <>; Wed, 7 Feb 2018 08:24:00 -0800 (PST)
Received: by with SMTP id g14so2378474qti.2 for <>; Wed, 07 Feb 2018 08:24:00 -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=q9FMewqdQx+KfMnYzTh8rqGpFUQkCAz391L6Iio+MmE=; b=DXFZbL6ORZLr0d25Q/DPmcWeT87Vzk1/Gon9VpCetokCsnohDux92ac/QCFszR6/n+ i+Vn4qnyIiTv7yumrPTw7+HQ/hjGbJioW6UgIHwlez15Gc7FPF2pXCQoGRlMf05LR2q7 ao12CJK4YSja2fGnzJfQqTcMHU/t1uF5EbDjHA3OSVKkfuAfWkMxNe9kRM41gwFzz2+x 1oDq6NMEs+as4016H26cEuiPL41oEHTAVwb1mkXcYoJFEbLr6oP5Ke4FMHJnpGVZcf5G JkGlGDVLksbcr3p5o9oUhlPgyTaHSd7ZPvQ5T28NEauwP9f9EVUL5O26hCzoZN9Cqhx7 3HkQ==
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=q9FMewqdQx+KfMnYzTh8rqGpFUQkCAz391L6Iio+MmE=; b=myTAm+kXw8oECVfCXxyrIVjs/a+7Gs79+JFsOaIJiPKioe2K9RaTDDMBaIBcR3OV9H WrW9OHviEvLdAdbEItknZMo3F0lqvy8zOlfoRGNGe5O5tO+fg1uTlxsn8PUj+sBK70lh sqbXiGIpmsuMegsaZCXjWNWK1kmXbKJIIeYpnuAdz5X52IfGdQT4g+Z+lb07gYrd0BmC sjIE7pD81cQxWXHFSBe+CY9BZaa9mCUwwSCSLqANRN93Or2/VMld0u3msesW434mAbFb YTyuVVmeJ1hma+IER+3FFcG6Rg+rz/bDPNm/cJ5RpuAk7gructgityX5mmoiOKnCKZkK nN6w==
X-Gm-Message-State: APf1xPDO+0R93YaYZ4TaLDqy6pSLpMSeRLVEuNlNCUNdDVipI7Gs+uXr UQWzHgPfI5QnldD1uTxBRuFcoA==
X-Google-Smtp-Source: AH8x225WJza/O7omwknq0HHwJiqV9HYORrxdiQDZvBpYgYEPnFuvJPm5KkRBI86M6Skna4HKt8wUzQ==
X-Received: by with SMTP id i13mr9633792qte.116.1518020639351; Wed, 07 Feb 2018 08:23:59 -0800 (PST)
Received: from cavall.lan ( []) by with ESMTPSA id d5sm1306334qtd.91.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:23:58 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F5470E6-7113-4A8D-8A8B-A299952359E5"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 07 Feb 2018 11:23:57 -0500
In-Reply-To: <>
Cc: Tim Wicinski <>, dnsop <>,,
To: Stephane Bortzmeyer <>
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: Wed, 07 Feb 2018 16:24:03 -0000

On Feb 7, 2018, at 9:22 AM, Stephane Bortzmeyer <> wrote:
> The intention of this specification is to enable stateful information
> (connection parameters and DNS data) directly related to the DSO
> Session to be transmitted. This creates trackable state and prevents
> queries from coming from successive privacy addresses, as could be the
> case with regular DNS queries, for a privacy-conscious client. Before
> using DSO (or any kind of long-lived DNS sessions), this consequence
> should be taken into account. The risk is partially mitigated by using
> encryption (which protects against sniffing by a third-party, but not
> against logging by the server.)
> The design of new TLV must also avoid adding any information that
> could make this tracking easier.

Thanks for this text.   I am pretty happy with it; the only thing I'd be tempted to change would be the last sentence, which I would state this way instead:

When designing new TLVs, the potential for the TLV to be used as a tracking identifier should be taken into consideration, and should be avoided when not required.

I say this because in some cases it's perfectly fine to know who you're talking to; e.g. in draft-sctl-dnssd-mdns-relay-02, I specified the use of TLS client authentication, because hybrid relays are network infrastructure.   Although this is happening at the TLS layer and not the session signaling layer, it's effectively the same thing.

Your other comments all make sense to me—thanks for the thorough review and particularly for suggesting text and not just saying "you should change this text."   :)