Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Philip Homburg <> Tue, 10 July 2018 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB97D131194; Tue, 10 Jul 2018 10:32:22 -0700 (PDT)
X-Quarantine-ID: <9TF0ePKQLBHg>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9TF0ePKQLBHg; Tue, 10 Jul 2018 10:32:20 -0700 (PDT)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DE37131188; Tue, 10 Jul 2018 10:32:20 -0700 (PDT)
Received: from (localhost [::ffff:]) by with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fcwUq-0000GvC; Tue, 10 Jul 2018 19:32:16 +0200
Message-Id: <>
Cc: Ted Lemon <>
Cc: DoH WG <>,, HTTP Working Group <>
From: Philip Homburg <>
References: <> <> <> <> <> <> <>
In-reply-to: Your message of "Tue, 10 Jul 2018 12:41:46 -0400 ." <>
Date: Tue, 10 Jul 2018 19:32:15 +0200
Archived-At: <>
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2018 17:32:24 -0000

>The ip= modifier would be a great way to arrange for something to look like
>it came from a different source than its actual source.   I'm sure there's
>an attack surface in there somewhere.

That's a rather fundamental issue.

In the context of TLS, and a DNSSEC insecure zone, there are two realistic
attack scenarios:
- an attack on DNS that returns different addresses for a DNS lookup
- a routing attack, that reroutes traffic.

Both types of attacks are realistic and happen quite frequently.

If we decide that TLS is strong enough to defend against these attacks,
then there is no need to secure the DNS lookup, other than to reduce
the risk of denial of service and for privacy reasons. Then such an ip=
modifier would be fine, because the worst thing that can happen is denial
of service.

On the other hand, if we don't trust TLS, then we have a bit of a problem.
Too many people using public resolvers. Route hijacks are quite easy, etc.