Re: [dns-privacy] Fwd: New Version Notification for draft-peterson-dot-dhcp-00.txt

Thomas Peterson <nosretep.samoht@gmail.com> Sun, 28 April 2019 11:12 UTC

Return-Path: <nosretep.samoht@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB9120112 for <dns-privacy@ietfa.amsl.com>; Sun, 28 Apr 2019 04:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qqGWRePWvExb for <dns-privacy@ietfa.amsl.com>; Sun, 28 Apr 2019 04:11:58 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 3F63912004F for <dns-privacy@ietf.org>; Sun, 28 Apr 2019 04:11:58 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id z6so7290283wmi.0 for <dns-privacy@ietf.org>; Sun, 28 Apr 2019 04:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=j1a61NUK+vCLatb4uP0rSndXk/bIzgLxhNJq+G/wg/I=; b=RRTkT1h2Dz1pvNCmprTqhrLd1lzmmb4kIs5Q4F7c4UwihBvaQE4Gel1eQgwGClxyM8 9efX/oWaDG0fUCAPz9TD801NqtWF/TNnpM5VgosLIvtmoTdGiUDXoP+XzcNdcS8JwNof oDOjE1ji9dMh/4OT4ReG+qeTGm6W0RdXImJ9UrimuYQoekvwHf1VbAr2uMVQezjhNIXW lhb/ELypxZvobhimxGYYzoVR6k6MtF8GR80t2qmbWspuZ2EEhfC9Hgmo9M4Mgz39L8xS 7ToESNHVwsmGd8yT7ELcjUO3YZk6MtMSajg6D576Aia5XdP/OkoJqxhYjKY9k72TFYZB +ldw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=j1a61NUK+vCLatb4uP0rSndXk/bIzgLxhNJq+G/wg/I=; b=jUejomuO508oy2ZmOcpEXBOStZ+lVoaob01Bmg7K0Nx3bZI+rY3jZLtGZKLXX7eDd6 8U2ATkuKK/7Ic2oR1+qGn5STiHDjvMTuR7iHYzL1ejEHa1/nuHdyVuWj/gY6Nljtq/M9 wuuZ8XKD2zuqm4vhS+aodOggFWuj85z22pDOiACVfspp8TCwqTdOFxd1ziryrByAN7uX v04hXH7FYPVgbYxhlnUoRN1toCI1IHB/+a4C5bZlYqTKv/6/0gJxC1Zok6DsVJRRgJL4 8MiAxTgNmiec6l9hDGYkmZzHka1kBJCeL0UB3ybO88VME/yQI0/r6tc4nf9L8+ewBncI IMvg==
X-Gm-Message-State: APjAAAUB5jinIfLPcQ9iT2lfPFkP47W//T07RnnyqejSyHvcSt42nM7T w84FXPHDwvYE2jbPRU7tOEs=
X-Google-Smtp-Source: APXvYqyr/8lsP+p60sX7mwOOqy81HTq0yXHo44hpyvBc95CIw/t1VzdJ1OkKH6a25lybK2sWgeDlWw==
X-Received: by 2002:a7b:c182:: with SMTP id y2mr13359604wmi.83.1556449916750; Sun, 28 Apr 2019 04:11:56 -0700 (PDT)
Received: from COMPAKKTA.home (host86-141-0-30.range86-141.btcentralplus.com. [86.141.0.30]) by smtp.gmail.com with ESMTPSA id r16sm24755175wrx.37.2019.04.28.04.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Apr 2019 04:11:55 -0700 (PDT)
To: nusenu <nusenu-lists@riseup.net>
Cc: dns-privacy@ietf.org, Martin Thomson <mt@lowentropy.net>
References: <155637241515.19889.8043108886886364414.idtracker@ietfa.amsl.com> <9a851741-c4e3-44fd-e659-91e7eec8a88a@gmail.com> <60e1d104-a484-e786-5f27-b37916db8ca6@riseup.net>
From: Thomas Peterson <nosretep.samoht@gmail.com>
Message-ID: <fa17715a-74a8-77f3-5310-3da10c40224c@gmail.com>
Date: Sun, 28 Apr 2019 20:11:54 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <60e1d104-a484-e786-5f27-b37916db8ca6@riseup.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/VB7AZL-zYdH-ztoQd1dquMRhLNM>
Subject: Re: [dns-privacy] Fwd: New Version Notification for draft-peterson-dot-dhcp-00.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 28 Apr 2019 11:12:00 -0000

Thank you for the feedback.

I agree with your suggestion around having host names and pins present 
in the response and I'll have a think what it might look like - 
suggestions here or on Github[0] welcome.

However I disagree that combining both DoT and DoH is appropriate - to 
me they are different protocols and I am concerned around complexity and 
size limitations (particularly for DHCPv4) that would be needed.

Regards


0: https://github.com/thpts/draft-peterson-dot-dhcp

On 2019/04/28 4:12, nusenu wrote:
> Thomas Peterson:
>> In a recent discussion in the DoH mailing list around a draft that
>> describes resolver discovery, Martin Thomson made the suggestion[0]
>> to use DHCP and RA options instead to transmit both DNS over HTTP
>> resolver addresses, but more relevant to this WG also DNS over TLS
>> endpoints as well. I have published draft-peterson-dot-dhcp, which
>> describe the relevant DHCPv4, DHCPv6, and RA options to support
>> this.
> [...]
>> 0:
>> https://mailarchive.ietf.org/arch/msg/doh/A2YthHjFwwwpC3d0MrOm1-syH48
> Thanks for starting this I-D.
>
> from the I-D:
>> Length:  Length of the DNS Servers list in octects
>>
>> DNS Servers:  One or more IPv4 addresses of DNS servers
> The I-D currently only contains IP addresses, not names as
> proposed by Martin:
>
> To quote Martin Thomson's email:
>> 2. We add a field to DHCP and RA that carries the "DoT resolver".
>> When this is present, the client resolves this name using the
>> resolver.  This resolution is unsecured.  The client then connects to
>> the resulting IP address and validates the certificate it presents
>> using this name.  This enables easier deployment of DoT because a
>> certificate for a name is easier to get than an IP certificate (it
>> also enables use of 1918 address and the like).
> So I'd suggest to have multiple fields:
> - IP address (optional)
> - name (for PKIX verification) (optional)
> - SPKI pins? (optional)
>
> I'd like to see a single document covering DoT and DoH
> DHCP/RA options (as Martin Thomson suggested)
> instead of two documents doing the same thing
> for each protocol separately.
>
> kind regards,
> nusenu
>
>
>