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

Thomas Peterson <nosretep.samoht@gmail.com> Fri, 03 May 2019 16:29 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 33DE4120179 for <dns-privacy@ietfa.amsl.com>; Fri, 3 May 2019 09:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.335
X-Spam-Level: *
X-Spam-Status: No, score=1.335 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no 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 nR8NUqAz8ovm for <dns-privacy@ietfa.amsl.com>; Fri, 3 May 2019 09:29:16 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 4D334120167 for <dns-privacy@ietf.org>; Fri, 3 May 2019 09:29:14 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id p21so7797980wmc.0 for <dns-privacy@ietf.org>; Fri, 03 May 2019 09:29:14 -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-language:content-transfer-encoding; bh=j1iQkqOTW42UbX+zzk/8lhzvau0KbAnvd9Km/yiM/ZM=; b=hf5CJalrEZVLGsb8wiaH7INcBOFw+3/oA1O+ixcz3LpCRbo6F0dRM1tI6hBNHZ8NH1 js6udwVFKHQCG5ay5lLhPP6QWdNccnCl4ttCpkbHGVd7dqxE/MfJjKA0+jVb1hJpHNjB TWZdalephhThcHuxxmMOt+KJ6HEz8CKIz1H3HgumX4R6cyh6smCZM0rfYijDdF57T9MU m6BbAFPvVSZLFJrnd0tnQrerR/k2nMtOMffsQIffvThpDqr+u/HEuJxzXA8W8fb2dYEm asxNqEHrzbH4kT4hFVsIXvlh5nKtpECqqe+NAt1pTL8qYCf6aWluYbYpdll2YNji3fjr qK3Q==
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-language :content-transfer-encoding; bh=j1iQkqOTW42UbX+zzk/8lhzvau0KbAnvd9Km/yiM/ZM=; b=qTKk1arHWrcht/DFtXXu3cIogmZH8MDx50dIQzsse0Hnlw91I6uXAjZIl4EBJc32iG uV7TydW944I5uSN/1XIpT/ApOAOpr1tqXmilLKGkz6SgZU32VPa/+q8+Khu1Kdy8O6C0 e2g46txMWyeFDSLHgnWskjtszY7SbvqFBXxJJguXQz6OZVx+5eaYC/5IPxy3iHb08bCn rISGcibiiJYODgWPQ7wo/yV99CPA6vPUUYp+BvoSac9vHLkEnASmgxYu4T8Yttvwi8up srlHEHo487WPPNeEon8+9svCALt7lfGfm83v6UZzlkGmVzdNYr8w4qFHoBLVX1JM6x6k hvOA==
X-Gm-Message-State: APjAAAWhw2AM0jg/RKIL1XagJq5aULeZIgn1NK4mNCLC+k8oD9r6zcKu emfQ3Fu0IcP9iIu9sfLbcGdKy6Vf
X-Google-Smtp-Source: APXvYqwmeQLJqad+poBAfFkhooGerdYXTM9E0YsyIAI3Hmfex+lkaYSMh9uRDdXglzlxmcWhHtBIZw==
X-Received: by 2002:a1c:14:: with SMTP id 20mr7330394wma.66.1556900952320; Fri, 03 May 2019 09:29:12 -0700 (PDT)
Received: from ROADKILL.local ([132.185.158.37]) by smtp.gmail.com with ESMTPSA id n6sm1960565wmn.48.2019.05.03.09.29.11 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 09:29:11 -0700 (PDT)
To: Martin Thomson <mt@lowentropy.net>
Cc: dns-privacy@ietf.org
References: <155637241515.19889.8043108886886364414.idtracker@ietfa.amsl.com> <9a851741-c4e3-44fd-e659-91e7eec8a88a@gmail.com> <60e1d104-a484-e786-5f27-b37916db8ca6@riseup.net> <fa17715a-74a8-77f3-5310-3da10c40224c@gmail.com> <794f6a22-27f0-4652-ac88-a1dc5584e4c3@www.fastmail.com>
From: Thomas Peterson <nosretep.samoht@gmail.com>
Message-ID: <977f05e9-36a8-2f1b-14ed-ba4e5e4bcb69@gmail.com>
Date: Fri, 03 May 2019 17:29:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Thunderbird/67.0
MIME-Version: 1.0
In-Reply-To: <794f6a22-27f0-4652-ac88-a1dc5584e4c3@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/GrIAP8UMtE7I4AbPayuPrVUj8n4>
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: Fri, 03 May 2019 16:29:18 -0000

Thanks Martin.

I believe there's a trade off decision between providing multiple IP 
addresses and de-duplicating with Do53 options, offering host names, and 
complexity. I've updated my version[0] with an attempt to solve the 
de-duplication, one way we could implement host name support is to 
either include another field designating the DNS server field as a 
single host name, or mandate it be such and not have the field.

Your opinions and those of others on the list appreciated.

Regards


0: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-peterson-dot-dhcp.txt&url2=https://thpts.github.io/draft-peterson-dot-dhcp/draft-peterson-dot-dhcp.txt

On 29/04/2019 01:50, Martin Thomson wrote:
> For DoT and Do53 are similar enough that they can use the same IP address and the DoT configuration only contains a target name.  There is a problem with the first in terms of signaling that DoT is present, but that the server will be using an IP certificate.  I don't know what the answer is there.  I'd first try to see if requiring a name works.
> 
> I certainly think that one name is sufficient.  Multiple IP addresses might be useful, but they can all answer to the same name (at least for the same provisioning domain).
> 
> DoH is different, and I think that your other draft is right in saying that you just have to use Do53 (or even DoT, though why you would...) to find the IP address for that name.
> 
> 
> On Sun, Apr 28, 2019, at 21:12, Thomas Peterson wrote:
>> 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
>>>
>>>
>>>
>>