Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt

Ted Lemon <mellon@fugue.com> Thu, 12 October 2023 12:51 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 D3953C14CE2E for <dnssd@ietfa.amsl.com>; Thu, 12 Oct 2023 05:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 KndUHgLlL4hE for <dnssd@ietfa.amsl.com>; Thu, 12 Oct 2023 05:51:18 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 51A02C14F726 for <dnssd@ietf.org>; Thu, 12 Oct 2023 05:51:17 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id 6a1803df08f44-65b162328edso4902926d6.2 for <dnssd@ietf.org>; Thu, 12 Oct 2023 05:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1697115077; x=1697719877; 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=98w2jcEc6T9N+pEIFecWMVaTyYZ2SCv8AOSY0vkm34g=; b=JsrJvu1dfM5TknBYg+i+v/tjRm7n/vXmjIQRkaUepxyHPK6Nyb52dN5srVMsicG4kL a4hxwqRdBbEQsFB9YAqFFGWiVstgEQa7X89qnl1bf2vTWqK35hgcEsuelog5E8m/Ksw9 WKhitz1AV9IPSMVI0+38CIqxd/3Bo86p6cMCQeTCTtuUL2ZkH3UlZbolka7/wCoNC9k8 assq0lMXpZfxl08nLtCaz205LNo3+NcPjaz8clHDMmEnuf4Sm2/FwQOd2aqwRFeEzOFS B0RZYEPCtw0fKraeq7oAiY7+vHBdfc63xfRHkOlNk6uq5V4jCLf0Y1m1WFBO18vwYtds BJIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697115077; x=1697719877; 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=98w2jcEc6T9N+pEIFecWMVaTyYZ2SCv8AOSY0vkm34g=; b=w3oUA2JCwoyPe624rxn1xG9l2x7wX8/ZUKiC6GcHdFx5bQnKEDI1tWNXVzeIsxV/pz is5CWjd8ozdBdXgL3aD6DNvQPCUEzbCFAOxS1OjKw5BhAqlFtkdfehWVPrumMhF/BkSP yYlmnYq4kivtrQd6mG5pCAF30jkCDNR5Kv8FZL0+TsDyQiUA8SehIOVv52IVtiAT45yX 7vmeOYgVV45MDTYdL2sA7S7pKXSroxjeKqukWXrFzvvD3wmcpLxDLu+Lb19owBB02Pez ylbEG2ArLvS2KsYpowEtHGuypcFz61QRgwOQxfCTNE5FaQkMRJbN6knCXbNPbgnJslwe x5gQ==
X-Gm-Message-State: AOJu0YwvgR1/2qG545OSrF2HOJCpmKFYRD1RJtDUD6DgfyqarW3/L6DU XrinFdpUTmkomBJ4QmW/mEXUo3ICkED/YqH644QPWK1SFIL4RNBeE6U=
X-Google-Smtp-Source: AGHT+IEHNDpr1A/te6OwtpSxCYF+h3R3T6s1eKGgccApeRQgjNi4l12jq6M1JtdBrfAfPXOkB+Wb7oLFnCwmX5l3xg8=
X-Received: by 2002:ad4:418a:0:b0:658:65ed:7e8 with SMTP id e10-20020ad4418a000000b0065865ed07e8mr25718861qvp.57.1697115076931; Thu, 12 Oct 2023 05:51:16 -0700 (PDT)
MIME-Version: 1.0
References: <169118866241.13601.15936262706231533955@ietfa.amsl.com> <ee7f1fcc-ed24-457e-9fad-0248cd2d7fee@app.fastmail.com> <CAPt1N1kxtBAyAMbp=pwneNJEWUE300CGGQtr0wMdPbdUye7YYA@mail.gmail.com> <65676093-1ec8-4693-af49-79141507b6c3@app.fastmail.com> <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com> <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <CAPt1N1nrGnRbkQ6Tt6ztdsKM5YHfSxz2s7deBxfsnh0EKVkDvA@mail.gmail.com> <c66882fb-3495-4cba-b901-067a230100b0@app.fastmail.com>
In-Reply-To: <c66882fb-3495-4cba-b901-067a230100b0@app.fastmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 12 Oct 2023 05:50:40 -0700
Message-ID: <CAPt1N1nOuhcK-4m7sjP1PO9KaKKYujoe-2aLuNuxTaHsn38c9A@mail.gmail.com>
To: Alexander Clouter <alex+ietf@coremem.com>
Cc: "dnssd@ietf.org" <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004dcc1a0607846570"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/r6pCDbRtXqVbfBRyiIdDJPwwckE>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
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: Thu, 12 Oct 2023 12:51:22 -0000

This is why we require a TCP connection for all non-constrained nodes: that
gives us a three-way handshake.

On Thu, Oct 12, 2023 at 2:40 AM Alexander Clouter <alex+ietf@coremem.com>
wrote:

> On Tue, 10 Oct 2023, at 14:27, Ted Lemon wrote:
> > If we'd had this idea early on, I'd say it was a good idea and worth
> doing,
> > but at this point maybe what we have is good enough and we should not
> mess
> > with it.
>
> Thought of something else whilst working on my own SRP implementation.
>
> You may be able to lean on DNS cookies (RFC 7873) which could also provide
> an option for implementers to relax the need for TCP in some situations.
>
> I see the change actually being in the DNS Lease draft and would affect
> the lease times returned by the responder. If there is no server cookie in
> the request, the returned KEY lease time is reduced. When there is a server
> cookie in the request, the request is treated in the existing prescribed
> fashion.
>
> So a implementation could either opt for or provide an administrative
> option on how to behave when:
>
> There is no DNS cookie option:
>
>  * ignore the request
>  * lower the KEY lease to a much smaller value (minutes rather than hours)
>
> There is a DNS cookie but without a server cookie:
>
>  * ignore the request
>  * lower the KEY lease to a much smaller value (minutes rather than hours)
>  * set the KEY lease to zero to indicate for the client to retry the
> original request with the requested lease times; the retry will include the
> server cookie and sail through
>
> If someone is offlink and trying to spoof, they will not be able to retry
> with a cookie.
>
> I am not sure lowering a lease to a lower value adds anything material to
> the problem, but offered it here as an example. Maybe it at least provides
> a way to garbage collect faster and  more interestingly provide an option
> for something actually requesting with a server cookie to kick out a bad
> actor registration without any complexity (server cookie registrations
> cuckoo out non-server cookie registrations).
>
> The only problem I can see is if you have a on-path (RFC 7873, section
> 1.2) bad actor and your legit clients do not implement DNS cookies. The bad
> actor would push out the legit devices. Personally I see this as a reason
> for implementers to include DNS cookie support but this is not a space I
> work in so maybe this along sinks the idea.
>
> A huge improvement over my original GTSM TTL=255 (RFC 5082) suggestion is
> I think this is a lot easier to reason about but more importantly it is
> optional and automatically negotiable between peers, plus is now no longer
> limited to IP traffic.
>
> Thoughts?
>
> If this does not cause too much grumbling, I can try to put together some
> language for your draft(s)? Not a problem if the idea does not stick, it at
> least is food for thought.
>
> Cheers
>