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

Ben Schwartz <bemasc@google.com> Tue, 08 May 2018 16:44 UTC

Return-Path: <bemasc@google.com>
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 5E0CA126E64 for <doh@ietfa.amsl.com>; Tue, 8 May 2018 09:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Tmd9a9pciZqU for <doh@ietfa.amsl.com>; Tue, 8 May 2018 09:44:19 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0737312EA52 for <doh@ietf.org>; Tue, 8 May 2018 09:44:19 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id f21-v6so39155838iob.13 for <doh@ietf.org>; Tue, 08 May 2018 09:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZOv68iknE5oeONRdZ5fjNmv4WDGE9RELj7lt7wCrC5k=; b=IdE2unIQoSCgLZm4U4icBXBPkf4fSdb1g5pdw/7VabB4HOItiZ15ZC44t1ITBoleny LcxtQnNRK5Fvbd64cFE8buXY/q3OpNbPnMRWHHXtHElJQYuHtEahcAZgOwvt144NK4Ct a3QJ89AVzBPCTdiTjET0vG0POec1Di9jC5NAtmk2fKlhA78CoMOj+KNp2LOweJ0yvfvw O8dbwpRA2MQkmdOB0Pu0nkvRowgqNV+1Nc5zk7f/kayfVFfB5K7KINrUdHEoMPKc3+tJ ekO7ewzg96mVhwqQISCtioNpTH8c9aiIZr5Gy03u2YTghayyQ3wMun64far+vfwdyvBa ciZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZOv68iknE5oeONRdZ5fjNmv4WDGE9RELj7lt7wCrC5k=; b=ZnkxOZ6YLeU8s3Rl4SMSXamJeumSL1LmjYrGs8vfy4tCav7QRXSTjprQAHRQAMRs+8 dwupMpsuUEZ95N2TKsyHnQr3ABPyAvz5tv87CESzqmQnlFhoCSfUBBG2gAk3CrumF+g1 86qXf//PJ4tG7zoUMLJ514BoUo8KYTcQyEfXdHJlxJwdaqKGZWS6xOqRpD0Hgc1axwWM qSqoeL2scKlGMdoMh9NOHkx2BKWe7E3DM3lBDgIlihrXHGjWjVkZ3R6snteySFChQuv6 1rdEHx7yxW/6/HnvHyjGascbEhwE0qhyymcFCejAbJJS+Ya8+akDY2ZJpixppXgp2drd nphw==
X-Gm-Message-State: ALQs6tCZi2nB1BQag1+lVTZW4VFNgB0IyGR7P4QNQy5EKdqJfHdNBHxf EIWg6MGe94dv/obSvdJEN5wVficYf/sq/cmtqRoL7fW2aiI=
X-Google-Smtp-Source: AB8JxZota+YG7EQ0UuOORZxiUA0X91ey987YwKnl4frgR/R6U+PS1TE7SmeVSibP899t7O8OYBonLirbYUdNZuosV6I=
X-Received: by 2002:a6b:697:: with SMTP id f23-v6mr46051022ioi.18.1525797857865; Tue, 08 May 2018 09:44:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.70.12 with HTTP; Tue, 8 May 2018 09:44:17 -0700 (PDT)
In-Reply-To: <CAOdDvNqQmxmj-Akx3VjoGt_r=Q-GRfi+WEz3=vo0AXj6fKTFHg@mail.gmail.com>
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>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 8 May 2018 12:44:17 -0400
Message-ID: <CAHbrMsDPD1KHvWT0nGOLPZmTYWLk8+7ud_07XFCZAQCxFg8qXg@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Mark Nottingham <mnot@mnot.net>, Paul Hoffman <paul.hoffman@icann.org>, DoH WG <doh@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005c00c7056bb47f00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/tpxngdWcFuai60K9TyTQJ9a6Ltk>
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: Tue, 08 May 2018 16:44:23 -0000

On Tue, May 8, 2018 at 12:25 PM, Patrick McManus <pmcmanus@mozilla.com>
wrote:

> On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> > This text reads more fluidly, and that is nice. OTOH it doesn't do much
>> to resolve the core tension in https://github.com/dohwg/draft
>> -ietf-doh-dns-over-https/issues/153. The current ID uses normative
>> language for creating http freshness lifetimes from DNS sets.
>>
>> Well, Paul asked for text...
>>
>> I forgot to say thank you for the text - I just was trying to communicate
> that I think the rationale is more of the blocker for this issue than the
> text. So that's what I'm trying to drill down on here..
>
>
>
>> > Comments from you and Martin (and this text suggestion) support
>> changing this from normative language to advice. The other comments favor
>> the more deterministic behavior we currently have.
>> >
>> > Can you help me understand the argument you are making? Martin
>> primarily suggests having the DNS code check the TTL before use rather than
>> relying on the cache to serve fresh responses - but I think that particular
>> point has met significant pushback largely from the DNS experts in the
>> community..
>>
>> I'm not hearing pushback to this approach on this thread so far, so I'd
>> like to hear (here) what the issue is.
>>
>
> Ben and Dave pushed back in the github - it would be helpful to hear them
> here as well, I agree.
>

As a standards matter, it seems to me that the DNS experts are still
working out the details of when it might be OK to go past the end of TTL
(e.g. https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00).
Allowing DOH to violate TTL would risk pre-empting that DNS discussion.  I
think it's worthwhile for us to be conservative in what we send until
serve-stale and related DNS issues are resolved.


>
>>
>> HTTP caches can and do serve stale content even without those "fancy"
>> things (e.g., when the origin server is disconnected). If you're using HTTP
>> and caching has taken place, you fundamentally need to understand how old
>> the response you're using is if it's time-sensitive -- which this is. That
>> means checking the Age.
>>
>>
> This text doesn't prevent you from serving anything - it just defines how
> you set the freshness lifetime so that an Age calculation at the HTTP level
> actually reflects the fresh/stale status of the DNS content in a
> conservative fashion. A client very concerned about that could make the
> calculation or it can assume that the server did the best it could do (i.e.
> its either fresh, or stale in extremis so use it anyhow) and use it once
> for record types like A.
>
> > The existing draft seems to have caused a little bit of confusion by
>> saying SHOULD match rather than MUST match.. The intent for that was to
>> allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if
>> you cannot figure out the DNS lifetime from your HTTP server code). The
>> subsequent sentence enforced the >= property.
>> >
>> > 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). 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.
>
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>