Re: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt

Ted Hardie <ted.ietf@gmail.com> Tue, 07 July 2015 15:17 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C4E1A88C3 for <dns-privacy@ietfa.amsl.com>; Tue, 7 Jul 2015 08:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 CWCghMhQz9xb for <dns-privacy@ietfa.amsl.com>; Tue, 7 Jul 2015 08:17:29 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 82D1F1A88C2 for <dns-privacy@ietf.org>; Tue, 7 Jul 2015 08:17:28 -0700 (PDT)
Received: by wifm2 with SMTP id m2so62875148wif.1 for <dns-privacy@ietf.org>; Tue, 07 Jul 2015 08:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AAlYFUj8BXQtHbt+OwTHpph6C57oZN0L718UOJkHd1k=; b=SkRTnyC9CW5QMUOLodFb1nCfikonuqm9j60R8k7qk4ZdX2ZArOjoYMRHPo9QtP+MJ5 U+yg0LzLBWBWozw04X8NA4wW1VphkEuxsNBTWbcZXRs8QpfEWvKDbAXj0dTagYy4bl2J u7MNGJvc/0B5pst/OORrBbiqp+IVLV8gQxUPfpmFxqbzLHUub67GkmhXdoNSVxq8r+ZN gqrAK3UmWXW7v0US8nutUqo9dp2+uUXJflZ7FC6YRTv6sqfCh22SquMhodzRY8cNeTYD IGA5mSOBJA6DI45HyJPFVJUqU5i45FEa38RHfO1/P696D89t0YoMAmsHJGpi/+6HfcKw T/xA==
MIME-Version: 1.0
X-Received: by 10.194.85.116 with SMTP id g20mr9242666wjz.154.1436282247145; Tue, 07 Jul 2015 08:17:27 -0700 (PDT)
Received: by 10.194.25.74 with HTTP; Tue, 7 Jul 2015 08:17:27 -0700 (PDT)
In-Reply-To: <2015070714161016259349@cnnic.cn>
References: <2015070714161016259349@cnnic.cn>
Date: Tue, 07 Jul 2015 08:17:27 -0700
Message-ID: <CA+9kkMAoRAiiLf7uFKP_UFpfvKpT-d=i_KpNxaFQKXcPaxZkMA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: yaojk <yaojk@cnnic.cn>
Content-Type: multipart/alternative; boundary="047d7bfcfd5023705c051a4a8572"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dns-privacy/CFjcl-E1XiM_7fYoW-kmpGA5HHQ>
Cc: dns-privacy <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] Fw: Fw: New Version Notification for draft-zuo-dprive-encryption-over-udp-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2015 15:17:31 -0000

Howdy,

A couple of questions.  First, the document appears to say that the stub
gets the public key of the recursive resolver from the certificate
authority infrastructure, and it cites RFC 5280; that would tell you how to
identify a public key from within a cert, but I'm not clear on how you
expect the stub to get the cert.  Can you explain.

Second, the draft says this:

    If the query name is very common and not
   relating to user privacy, the stub resolver can do name resolution
   through traditional unencrypted way and thus does not need to
   implement the approach proposed in this draft.  While if the query
   name relates to user privacy, the stub resolver can use the method
   presented in this draft to encrypt the DNS queries.  And accordingly,
   the recursive server also encrypts the DNS response with the public
   key extracted from the DNS query.

This provides a flag to attackers on what traffic is "sensitive" and should
be avoided.  Also, the draft does not suggest the rate at which the stub
should change its associate public key, but it clearly should do so or it
will create a long-lived association of identity with the queries that
impacts privacy.

It's also not clear to me, given that the stub public key is sent in the
query to the recursive resolver how you avoid an attacker standing up a
back-to-back user agent which strips that option, substitutes its own
public key, gets the data and then passes it on.  (It may be, of course,
that this attack is out of scope).

thanks again,

Ted

On Mon, Jul 6, 2015 at 11:16 PM, Jiankang Yao <yaojk@cnnic.cn> wrote:

>  Dear all,
>
>    We have uploded a draft (below) about encryption of message through PKI
> mechanism over UDP.
>
>   any comments are welcome.
>
>   *From:* internet-drafts <internet-drafts@ietf.org>
> *Date:* 2015-07-02 17:30
>
>
> A new version of I-D, draft-zuo-dprive-encryption-over-udp-00.txt
> has been successfully submitted by Jiankang Yao and posted to the
> IETF repository.
>
> Name: draft-zuo-dprive-encryption-over-udp
> Revision: 00
> Title: Approach on encrypting DNS message over UDP
> Document date: 2015-07-02
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/internet-drafts/draft-zuo-dprive-encryption-over-udp-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-zuo-dprive-encryption-over-udp/
> Htmlized:
> https://tools.ietf.org/html/draft-zuo-dprive-encryption-over-udp-00
>
>
> Abstract:
>    This document offers an approach to encrypt DNS queries and responses
>    between the stub resolver and the recursive server over UDP to
>    protect user privacy.  The public key of the recursive server is
>    distributed to the stub resolver through the Certificate Authority
>    infrastructure, and the public key of the stub resolver is sent to
>    the recursive server together with the DNS query where the public key
>    is inserted to the additional section of the DNS query.  Then the
>    recursive server encrypts the DNS responses sent to the stub resolver
>    with the public key of that stub resolver, and similarly the DNS
>    query sent to the recursive server is encrypted by the stub resolver
>    with the public key of that recursive server and thus the user
>    privacy is protected.
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>