Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?

Mark Nottingham <mnot@mnot.net> Mon, 14 May 2018 02:23 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001661289B0 for <doh@ietfa.amsl.com>; Sun, 13 May 2018 19:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=uJzes1cJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=icYUjD4D
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMaQD592wpRY for <doh@ietfa.amsl.com>; Sun, 13 May 2018 19:23:02 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F60128954 for <doh@ietf.org>; Sun, 13 May 2018 19:23:02 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 87B1F24E77; Sun, 13 May 2018 22:23:01 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 13 May 2018 22:23:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=3o0QyJkacXljXSkM6zMG/Rjwysjzy A8CRQA6+A6GJBw=; b=uJzes1cJ/tFRYHo97SwVruDBGZX5NS+W3aPd0eEUHeQIa 6yF3aOhWasSfIgDoNfv6nUG4UhcEIgj4L+MQUYVzk+KhzamlA2iA3xSd4uxDMtsa i7Wzmc8LTDtE9+Qd3w91xGbTvwdCD0/JXyfucFL+YPSDicTf0XPPa67FcXjH8PMN KjAQkY3wqQzVNdKh9WlmGR3Tr/udRQ4UpaMg6CQtHllGXJU729DtLTmnLN17wYTg E3tRaEyN3a+WU5ZL13hrrkJxePPsBEl1L9on1YJGoSKM+946a31xuUtz2Ia/Pv4l 9FCq1uEejdvSOs8rxuDR0teAuVU7IVR79I7h6UGPw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3o0QyJ kacXljXSkM6zMG/RjwysjzyA8CRQA6+A6GJBw=; b=icYUjD4DNgaokWYpK6YaIV SAbuKrF6xbJ85uYzu8MC+n7trMqAhBIruXXE3zD+lC1QmfljVDZNNCdp5lzg/+ww GjfzM+8X4UpmcxObg1H1yLOTdxKiwwWf636hEiZylXokmlAZjVPZRs6ITpDtcP/I qHhYXSj6xdCBdN5o9hfViL3QnHwi208CFQLy1wygipLzzbNOvJXFmlN1qa3yvAlf DqUnHwTgJg7RlEEj49Dj/umpnXJdv/0R+wY/EBQhgNxTvpakhAUM00SlOwZLDI1Q pi+df+jizERYVbw2eUiaZTuyXxqEE5bnOpiXMT1aG44/jjh9OPcshZfhvuOEIMWQ ==
X-ME-Sender: <xms:BfP4WvsF2J-am5Z931hTHr0Gz2538A-IVcwzz__s6TsP5yBGOjRevQ>
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id EC3101027B; Sun, 13 May 2018 22:22:59 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAOdDvNqQmxmj-Akx3VjoGt_r=Q-GRfi+WEz3=vo0AXj6fKTFHg@mail.gmail.com>
Date: Mon, 14 May 2018 12:22:57 +1000
Cc: Paul Hoffman <paul.hoffman@icann.org>, DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD7F3451-2979-455C-AA1B-DA2839EAE7D8@mnot.net>
References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <CAOdDvNoQC=e8GTHU5Bw1KkR0r+dyKhqsVDRXvuyJb+jQSKn8GQ@mail.gmail.com> <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> <CAOdDvNqQmxmj-Akx3VjoGt_r=Q-GRfi+WEz3=vo0AXj6fKTFHg@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/3hKsD49wtbLV2PyXSYKGG-6HNRI>
Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL?
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 02:23:05 -0000

Sorry, I had a weekend.

I'm OK with the text that Patrick incorporated, it's not worth getting too far into the weeds here. But, to answer a question / explain where I'm coming from:

> On 9 May 2018, at 2:25 am, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
>> > Is there another aspect to the question I'm missing?
>> 
>> It looks like you're using RFC2119 requirements to bring attention to important parts of the specification ("we really mean that this could trip you up"), rather than stating actual requirements for interoperability. These MUSTs aren't testable, and they may be too confining in some deployments. This stuff really is advice, of the "if it hurts, don't do that" sort -- not requirements.
> 
> I must be misunderstanding what you mean by not testable - the alignment of expiration information seems pretty observable. And there is an operational impact to terminal clients without caches (either DNS or HTTP) which simply want to lookup a record and use it having to retry to get non-expired info (and the rather large risk of them not trying and using old data instead).

I don't understand how the location of the cache has anything to do with this. If a client gets a stale response -- as I said, this is very possible today despite the language in the draft -- they need to be able to deal with it. If the client wants to act like that's not a possibility, they're going to have a bad time.

> So I guess you can argue that without 2119 language the DOH client and server can communicate, but without normative provisions constraining the server you can't interop well with the Internet.. seems 2119 in scope to me.

The style of requirements used doesn't tell consumers what to do when they're violated, and -- as we've seen many times -- implementers tend to read too much into them, e.g., refusing messages which violate them, even though no such thing is specified. 

In other words, specifying in terms of ideal requirements (e.g., "the message MUST look like foo") hurts interop. It's much more effective to specify requirements in terms of producer and consumer behaviours, and to use those requirements sparingly. 

E.g., in the previous text, it said:

"""
The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response.
"""

This is better stated as something like:

"""
The DNS API server MUST NOT generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

That said, another reason to avoid requirements here is that, as discussed, there might be future uses for stale responses, but now they'll be forbidden by something that doesn't really need to be a requirement, and so the document will have to be updated -- creating friction against these uses. This is why I prefer something like:

"""
The DNS API server should typically generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

The current text isn't bad, but the SHOULDs are unqualified, and IME SHOULDs like that just confuse people.

Cheers,

--
Mark Nottingham   https://www.mnot.net/