On Thu, Sep 07 2017, Andreas Bartelt <o...@bartula.de> wrote:
> On 07/12/17 18:49, Jeremie Courreges-Anglas wrote:
>> Eric Faurot <e...@faurot.net> writes:
>>
>>> On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote:
>>>> Hi,
>>>>
>>>> earlier this year, jca@ worked on support for DNSSEC and the EDNS0
>>>> extension [1] and committed this work at [2] (thanks!). I tried this
>>>> with SSHFP records to check authenticity of hosts with DNSSEC; but ssh
>>>> reported that the hostkey fingerprints were insecure.
>>>>
>>>> I am using this configuration file:
>>>>
>>>> # cat /etc/resolv.conf
>>>> nameserver 8.8.8.8
>>>> options edns0
>>>>
>>>> And ssh reports the following:
>>>>
>>>> $ ssh -o VerifyHostKeyDNS=yes -vvvv doamin_with_sshpf_dnssec
>>>> ...
>>>> debug3: verify_host_key_dns
>>>> debug1: found 8 insecure fingerprints in DNS
>>>> debug1: matching host key fingerprint found in DNS
>>>> The authenticity of host 'xxxxxxxxxxx (xxxxxxxxxxxx)' can't be established.
>>>> ECDSA key fingerprint is ....
>>>> Matching host key fingerprint found in DNS.
>>>> Are you sure you want to continue connecting (yes/no)?
>>>> ...
>>>>
>>>> I tried to find out why and after going through the asr code, I found
>>>> the following:
>>>>
>>>> Index: lib/libc/asr/res_send_async.c
>>>> ===================================================================
>>>> RCS file: /cvs/src/lib/libc/asr/res_send_async.c,v
>>>> retrieving revision 1.36
>>>> diff -u -p -r1.36 res_send_async.c
>>>> --- lib/libc/asr/res_send_async.c 15 Mar 2017 15:54:41 -0000 1.36
>>>> +++ lib/libc/asr/res_send_async.c 11 Jul 2017 20:09:59 -0000
>>>> @@ -385,7 +385,7 @@ setup_query(struct asr_query *as, const
>>>> _asr_pack_query(&p, type, class, dname);
>>>> if (as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC))
>>>> _asr_pack_edns0(&p, MAXPACKETSZ,
>>>> - as->as_ctx->ac_options & RES_USE_DNSSEC);
>>>> + as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC));
>>>> if (p.err) {
>>>> DPRINT("error packing query");
>>>> errno = EINVAL;
>>>
>>> The current code is correct, RES_USE_EDNS0 does not imply RES_USE_DNSSEC.
>>> The real problem is that there is no resolv.conf option for RES_USE_DNSSEC.
>>
>> RES_USE_DNSSEC is set by applications that *do* care about the AD bit.
>> There's no point in setting globally RES_USE_DNSSEC, so I don't think we
>> need a resolv.conf option.
>>
>
> I recently ran into the same problem regarding the ssh(1) warning.
> I don't understand yet why a global option in resolv.conf would be
> pointless or a bad idea. For example, the following simple patch seems
> to work for me, and I didn't observe any side effects yet:
>
> Index: src/lib/libc/asr/asr.c
> ===================================================================
> RCS file: /cvs/src/lib/libc/asr/asr.c,v
> retrieving revision 1.57
> diff -u -p -u -r1.57 asr.c
> --- src/lib/libc/asr/asr.c 27 Feb 2017 10:44:46 -0000 1.57
> +++ src/lib/libc/asr/asr.c 7 Sep 2017 15:15:44 -0000
> @@ -597,6 +597,8 @@ pass0(char **tok, int n, struct asr_ctx
> ac->ac_options |= RES_USEVC;
> else if (!strcmp(tok[i], "edns0"))
> ac->ac_options |= RES_USE_EDNS0;
> + else if (!strcmp(tok[i], "dnssec"))
> + ac->ac_options |= (RES_USE_DNSSEC |
> RES_USE_EDNS0);
> else if ((!strncmp(tok[i], "ndots:", 6))) {
> e = NULL;
> d = strtonum(tok[i] + 6, 1, 16, &e);
>
> What am I missing here?
Adding a resolv.conf(5) keyword is a kludge, it will only make
all dnssec-validated replies larger for no benefit except ssh -o
VerifyHostKeyDNS=yes and... maybe isakmpd?
>>> It can only be set in user code by tweaking _res.options.
>>
>> ssh(1) uses getrrsetbyname(3) to look at SSHFP records, so the fix is to
>> teach getrrsetbyname to request DNSSEC processing. Eric and I have
>> already discussed this and need to settle on the implementation.
This is the proper way to move forward, sadly the discussion stalled
because of implementation details. Gotta retry.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
