Re: [DNSOP] Minimum viable ANAME

Havard Eidnes <he@uninett.no> Wed, 03 October 2018 20:50 UTC

Return-Path: <he@uninett.no>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACF712F1AB for <dnsop@ietfa.amsl.com>; Wed, 3 Oct 2018 13:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uninett.no
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 eR0OyZQZOE-w for <dnsop@ietfa.amsl.com>; Wed, 3 Oct 2018 13:50:33 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by ietfa.amsl.com (Postfix) with ESMTP id 610A5129619 for <dnsop@ietf.org>; Wed, 3 Oct 2018 13:50:33 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 97FD443EA41; Wed, 3 Oct 2018 22:50:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1538599831; bh=qRKM1fQ4gNkRT+PIEks5dNS7+DXdnbzaSlo01VWUZAc=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=cY11saTk9Y3aS26DSXxxu033iYeykOaJY9yZ8RZW/a6ElMKjwsuO8i/a027wUlcwh 7hpMVAsBXekzuPW/VloAfqmZGUXcaW6fEUwlXoSrPhNrpTpkt+oC1W0VzI63ZQita0 tiYjWVZYxQ3GZQDcJajLd8vdHgczfMDnFSlGLXxU=
Date: Wed, 03 Oct 2018 22:50:31 +0200 (CEST)
Message-Id: <20181003.225031.1967924798140743636.he@uninett.no>
To: tjw.ietf@gmail.com
Cc: ray@bellis.me.uk, dnsop@ietf.org
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <CADyWQ+HnNfypQ6RBqzjf+PWSweuWpcffAHwUBnmG3mXpS+UaQA@mail.gmail.com>
References: <fdee6f3f-dd86-b482-5263-eb8e2a21bcb7@bellis.me.uk> <20180927.132726.1724872954316078693.he@uninett.no> <CADyWQ+HnNfypQ6RBqzjf+PWSweuWpcffAHwUBnmG3mXpS+UaQA@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 26.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5Bn2kElm8gurKKI7w37gTvzFI3g>
Subject: Re: [DNSOP] Minimum viable ANAME
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2018 20:50:39 -0000

>> > except that we heard at the side meeting in Montreal (albeit from
>> > browser people rather than content people) that they *don't* want
>> > SRV, because it has fields that are not compatible with the web
>> > security model.
>>
>> Can you summarize the particulars of the web security model (I'm not
>> sufficiently well versed in that area to immediately key off that
>> phrase) which makes use of SRV non-attractive?  Is the aspect that a
>> URL can contain a port number part of the problem, or is it
>> something (a lot?) more involved?
>>
>> When defining the use of SRV for the web protocols (something which
>> remains to be done), one could of course standardize "ignore the
>> port number in the SRV record, use the port number from the URL, or
>> whatever http and https defaults to", especially if that makes the
>> problem go away.
>
> What I said in Montreal is SRV works great if you are a robot,
> but when humans are involved it never ends well.

I must say I'm not able to follow that argument.  Can you please
explain?

This is also a different argument than the one I asked about
above, about the web security model and how SRV is incomatible
with it.

> I also don't see the issue with online signing, but that is just me.

There are current operational DNSSEC deployments where the
publishing name servers do not have access to the key material
needed to sign new or "dynamic" records in the zone on the fly.

Insisting that the publishing name servers all have to have the
private key material available in order to sign new or "dynamic"
records is in my view a Major Change to DNSSEC.

Regards,

- Håvard