Re: [dnssd] Zaheduzzaman Sarker's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)

Ted Lemon <mellon@fugue.com> Mon, 29 January 2024 22:36 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D54C151064 for <dnssd@ietfa.amsl.com>; Mon, 29 Jan 2024 14:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQGuFR4TL3q8 for <dnssd@ietfa.amsl.com>; Mon, 29 Jan 2024 14:35:59 -0800 (PST)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0ABEC151998 for <dnssd@ietf.org>; Mon, 29 Jan 2024 14:35:59 -0800 (PST)
Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-68c3d51ecebso18022436d6.3 for <dnssd@ietf.org>; Mon, 29 Jan 2024 14:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1706567758; x=1707172558; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j16UvkjQSaVY9GzV4mcekoI03Xf9EXxrCSta2HP96V8=; b=OutJKoHqUyPVmVwnBqH+3EixOqWqd6zhXwy+kt41Tuma6vTzQxoWrlcnismIZwuTXI wlq6rNVuVSB/6NIc9yJPD7P5dbqISF2aR2vCHfscYtcwTWz1lhuFhSNCNs5qzk21rW7L Xf6I48yxA8EN2dDHhHZdpS3/ZXEBQGElWlr8tZTyBaqQVn9opITiTRGPNVepP7s/Swe0 pTZYQbR3hYVpfvLqcvP3QuyOxyas8gOsQSnTVbAIf8qTYj7/Qc78/y/fYbxKp+YGtdXS NzWuRZ3P4PJ7TZJfiwRAYdV6YuE4AY9gdKzpx1SCD4eeFWzRK7kxwyFzssR6Un/QdDfL aYcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706567758; x=1707172558; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j16UvkjQSaVY9GzV4mcekoI03Xf9EXxrCSta2HP96V8=; b=Xk1MFlBk2ZHmxfv6e9tJ+A1BoZXjtf5yX06tZgpkahQ9HfIZ0xUkUvPp0bLt/pENLz jJXaYm48edgtjMjlPGdcZpJ0n+DfzpPRpokxDGoIaP0uJqd3E2ZEp6OEPkW2gwRNkSjH QacZvswgOTZqAvpFH0UjewgwsrDxeRujT65aEnAT0ytgODMkD0si7QWtj73Sf3a64+OJ lFOdKY2/nMOpVjKOMUt7IVaSZ3u5XgUPXomG9B8Cqru06kqgeGNLEfn+IcubKQYyroda 6ZO6yvcOTf0pPhopftYEn+n3o08q3cU1R9QVXLEdZLBFmiM9+43YCKWFGGC6fW7Znomc uSsg==
X-Gm-Message-State: AOJu0YyaM4QHVvriti5Iv1PNsybLapTBUS1Qvaou6VTc8NMNF6akaL3c aGBV0lOtuyGwIPkZM46VIuYdOlJy7WsOiTJe+KE0joAeIG3kvRdGVJUXd+PnpvQ5EsNJtBQzB5m zA1u+msGBrdwghC68081GqinnGAjg4Ag8twYhqQ==
X-Google-Smtp-Source: AGHT+IGy0zrc76ljPtjw/fSh9pNlxFhVIYdFPXx9g/I44hxpeY1rkjwLBueTR5WbVbAUOU4yZu7AaX4NhcUkbVKKTaY=
X-Received: by 2002:a0c:fca5:0:b0:684:1afe:460d with SMTP id h5-20020a0cfca5000000b006841afe460dmr5084132qvq.60.1706567758567; Mon, 29 Jan 2024 14:35:58 -0800 (PST)
MIME-Version: 1.0
References: <169165864311.42464.10328465393713919564@ietfa.amsl.com>
In-Reply-To: <169165864311.42464.10328465393713919564@ietfa.amsl.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 29 Jan 2024 17:35:23 -0500
Message-ID: <CAPt1N1=TVv8PdQ6b57jWjpCE9BxvWCrkx2NEpiMHeEBLuH4ReA@mail.gmail.com>
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnssd-srp@ietf.org, dnssd-chairs@ietf.org, dnssd@ietf.org, dschinazi.ietf@gmail.com
Content-Type: multipart/alternative; boundary="00000000000008ef6506101d45e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/g8D-6r8ZVIKY-jOwH46bFmO_-r8>
Subject: Re: [dnssd] Zaheduzzaman Sarker's No Objection on draft-ietf-dnssd-srp-23: (with COMMENT)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2024 22:36:01 -0000

Zaheduzzaman, thanks for the comments, sorry for the late response (you're
all probably getting tired of hearing this!)

On Thu, Aug 10, 2023 at 5:10 AM Zaheduzzaman Sarker via Datatracker <
noreply@ietf.org> wrote:

> Thanks for working on this specification. Thanks to Joerg Ott for the
> TSVART
> review, and  yes, please respond to his comments.
>

Done, thanks!

I have following observations/questions and hope to get some responses
>
> - This document left me we with the feel that TCP is the only preferred
> transport for the DNS updates when it comes to SRP, even though UDP seems
> like
> a very potential transport for constrained devices. is this the intention?
>

We don't dis-recommend UDP. Our assumption is that for applications where
UDP is appropriate, the implementor will choose it. In fact, e.g. on Thread
networks, UDP is used for registration, although they do specify
DNS-over-TLS (specifically DNS Push) for service discovery queries.


> - Now that we have DoQ (DNS over QUIC), which have similar security/privacy
> properties as DoT and can be used for Zone transfer, and claims to be have
> same
> latency characteristic as DNS over UDP. I was wondering why QUIC a
> transport
> protocol was not considered in the specification. Is that a deliberate
> choice
> by the working group?
>

Two reasons. First, I think it's extra complexity that doesn't add any
obvious benefit—TCP is adequate to the task, and ubiquitous.  Second, when
we started writing this, QUIC was a lot less mature. Sigh.

- Specially this claim about TCP is required -
>
>     This creates the possibility of off-network spoofing, where a device
> from a
>     foreign network registers a service on the local network in order to
> attack
>     devices on the local network. To prevent such spoofing, TCP is
> required for
>     such networks.
>
>   Will this not be fulfilled with QUIC as transport?
>

It would. If at some point we come up with a reason to use QUIC, I don't
think there's any obstacle to doing it. I will confess to being pretty
naive about what functionality QUIC provides—I have a general idea, but
have never actually tried to use it. So possibly I am missing something.