If a mechanism that facilitates certificate validation is important then
the only two options I believe we have are:
A: Providing a host name only within the option, and expect clients to
use Do53 to resolve it, performing host name validation against the
certificate CommonName or SubjectAltName.
B: Using IP address(es) only, with either Do53 option or this option
providing the IP addresses, in addition to a non-DNS related identifier
to facilitate certificate validation - perhaps the Serial Number,
Subject Key Identifier or some other field or a derived field of data.
Having an option with both a host name and IP addresses makes no real
sense to me.
It seems the first option is probably the most appropriate and I should
rewrite the draft accordingly, would you agree?
Regards
On 06/05/2019 05:25, Martin Thomson wrote:
So the plan is:
1. new option has > 0 entries: use those IP addresses with DoT.
2. new option has 0 entries: use the other entry, but you can use DoT with
confidence.
3. no new option: you are left guessing, but you might be stuck with Do53.
No mention here of how you get the name for certificate validation still.
That's still important.
On Sat, May 4, 2019, at 02:29, Thomas Peterson wrote:
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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
