Re: [DNSOP] extension of DoH to authoritative servers

"" <> Thu, 14 February 2019 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7219F131156 for <>; Thu, 14 Feb 2019 00:58:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5MmgCmsCs_0j for <>; Thu, 14 Feb 2019 00:58:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B2B76131056 for <>; Thu, 14 Feb 2019 00:58:44 -0800 (PST)
Received: from Foxmail (unknown []) by (Coremail) with SMTP id AQAAf0ApMLjALWVcuwYgAA--.21847S2; Thu, 14 Feb 2019 16:58:40 +0800 (CST)
Date: Thu, 14 Feb 2019 16:58:38 +0800
From: "" <>
To: Stephane Bortzmeyer <>
Cc: dnsop <>, Paul Wouters <>
References: <>, <>, <>, <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 166[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart706634725425_=----"
X-Coremail-Antispam: 1UD129KBjvJXoW7tryDKw18Ww45tFyrWr4kJFb_yoW8Zr4rpr 4ftrs0kF4DJFyjy3y8ur18W34Yvrs8Xw17Grn8t34jya98XF1DKr17Kwn09FWkCw43Jr10 vrWDGrZ5Ga9xtFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmSb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87 Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAY jxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02 Avz4vE14v_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r 17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBI daVFxhVjvjDU0xZFpf9x07bwiiDUUUUU=
X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/
Archived-At: <>
Subject: Re: [DNSOP] extension of DoH to authoritative servers
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Feb 2019 08:58:48 -0000

sorry, because of my english level, i misused the word "protect".
i know the difference between channel security and object security.
but in my proposal, the premise is the recursive server should completely trust an Authenticated server.
 i think this is simialr in DNSSEC, because if an DNSSEC_enabled authotative server(no matter it is Alice or Bob) is evil and modifies DNS records, 
it will succeed because it has private key and can fake anything.
From: Stephane Bortzmeyer
Date: 2019-02-14 16:33
CC: dnsop; Paul Wouters
Subject: Re: [DNSOP] extension of DoH to authoritative servers
On Thu, Feb 14, 2019 at 02:36:14PM +0800, <> wrote 
a message of 86 lines which said:
> i think both DNSSEC and DoH(or DoT) can protect DNS data,
"Protect" is like "security", a word so vague,  which includes so many
different (and sometimes contradictory) services that it is not very
useful. Writing "both DNSSEC and DoH(or DoT) can protect DNS data"
seems to imply that you did not think enough about the difference
between channel security and object security. This is really the
weakest point in your argumentation. (Yes, djb always make the same
mistake but he is a famous cryptographer so people forget and forgive
about his mistakes.)
> the fundmental point it to establish the trust chain and transit
> trust.
No. The entire point of DNSSEC is that you do not need to trust the
many servers that are between the validator and the origin.
> Regarding the case"secondary name servers mnaged by a different
> organisation", the servers can publish several TLSAs to distingush
> them.
I'm afraid you did not understand. Let me explain with concrete
examples. Suppose organisation Alice subcontracts a secondary name
server to organisation Bob (a very common use case).
1) What is Bob is evil and modify DNS records?
2) What is Bob is sloppy in security and its servers are cracked and
the attacker modify DNS records?
DNSSEC protects against both. DoT and DoH does not protect against
these issues.
> This idea is just a sketch model
The problem is that there are many sketch models floating around and
few serious proposals (and even less implemented and analyzed
DNSOP mailing list