Re: [IPsec] draft-pauly-ipsecme-split-dns

Eric Rescorla <ekr@rtfm.com> Wed, 20 June 2018 18:04 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA5130E03 for <ipsec@ietfa.amsl.com>; Wed, 20 Jun 2018 11:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ALTkp0Q6pfQY for <ipsec@ietfa.amsl.com>; Wed, 20 Jun 2018 11:04:13 -0700 (PDT)
Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 6AD4B130E02 for <ipsec@ietf.org>; Wed, 20 Jun 2018 11:04:13 -0700 (PDT)
Received: by mail-yw0-x242.google.com with SMTP id 81-v6so165258ywb.6 for <ipsec@ietf.org>; Wed, 20 Jun 2018 11:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uW7Yq9bODPHEV67TT0+iABbKJwfaDPouZnlXk2PrPbw=; b=KvNv2boBPPo3DuKcCo+F8ZyT++A2eADOeX2qdTM7gtDqW/VNXIfryfBkQZK/0/5pMg 9cQ0qyW+xft1lgNS3IOeuKWRRv259NWlwO1qaCjSr7n9KVYF9M6UlmIpYZ0LG5zqzPzb LLCx792LQVrFYTRcGVe58vE8oUQVr3BIpLPkF8OVga/+KZkaIhD1nXyKW99J8qDWG4sD srk3nm47SUVY699xJa1WaSv2CdwZ8M9a1LjnpxGdknuBUb1bn7+gY6/cDXpgqYpbt1bl buByvtn0JQ9llZaC+gQ/4yZa9RL9OLtW/jO1GIrmnfHkPAg1KpBK8ecdFxKydd4qvGi3 u/aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uW7Yq9bODPHEV67TT0+iABbKJwfaDPouZnlXk2PrPbw=; b=MMWo2+YSawfbUTqeYRY4e9WwTt4tc//ts+MW8kS/dti3znNN2Z+NPKf+Tgwky/c3eX nHINSKLoiO1ZhqZQj5ce05HLwuIacG9oGVF99ymuUTLqFb2QqlogJv+Z9otqJCKA1Rpv /gBDZzM4/hFnVi1hBbWDHQX22DZfsluTHcgK4UvmV6s6IN93Ni5JddHeYBnTLUm5wBH9 +59WX1dKIswVqF+U63QbBsCFi1JoQOVaQq9eeF1hWhkGqsOBvAj8pe6SF0ThWytld7bo +50xxEJ9s5OTBCnPrcYkxwOjySHtBJXw6iEA/NpYgkrdGZShgdBJlrF750Zkqt7mP4jL asrQ==
X-Gm-Message-State: APt69E1MkeumfL7+KTrgyrHE780q1oOTXMac0GhP1VPpdQH+SiV81xRD 0Z9Nk/ZW1QdB2pAYO/TjUAvTpz5ZZEPD/QEwG0dN4w==
X-Google-Smtp-Source: ADUXVKKJ2TM1Qp2JiaoSFuMCFo3AdP6Om+2NI50jzVNt0+3ullvv+0RBe3yStmf/6/rf7EY6U9eYsI0+KvbXUOzzV+I=
X-Received: by 2002:a0d:e6d4:: with SMTP id p203-v6mr11113781ywe.381.1529517852638; Wed, 20 Jun 2018 11:04:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:613:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 11:03:31 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.21.1806201010490.6077@bofh.nohats.ca>
References: <alpine.LRH.2.21.1806181702230.13143@bofh.nohats.ca> <CABcZeBOa8qMhDyCMzPTAtUBZTYPGehrhPrr6h4cVCjP4QZ1+Ew@mail.gmail.com> <alpine.LRH.2.21.1806191109300.16269@bofh.nohats.ca> <CABcZeBPFw1iuHXV+_sEuMaRCYRSk1nH_FujeimOb=ViEAtvkVA@mail.gmail.com> <alpine.LRH.2.21.1806191159310.26059@bofh.nohats.ca> <CABcZeBN2HwiwVzAUjyZU+Q+toFM2jOKHD9xmKwM1V5qhUoULEQ@mail.gmail.com> <20180619183459.GC4218@localhost> <CABcZeBPh33RMWy=pWVSWPp9cDrzrRrVQXgw1BKPLy_W0_Wrdgg@mail.gmail.com> <20180619224651.GD4218@localhost> <CABcZeBObub+rYYURt9SSumYqqWGxDMqhOG64oA+979n=mduXMw@mail.gmail.com> <20180619230148.GE4218@localhost> <CABcZeBNmavpZvzNRZBdOTKQYZ=yW=y2poaoVtsOeESNyRrG15Q@mail.gmail.com> <alpine.LRH.2.21.1806200002340.18235@bofh.nohats.ca> <CABcZeBPbq9ga8oSQ09GLyonPgZLOpFAy9hDJYAagUFz7GSHEoQ@mail.gmail.com> <alpine.LRH.2.21.1806201010490.6077@bofh.nohats.ca>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 20 Jun 2018 11:03:31 -0700
Message-ID: <CABcZeBO0FjTWhhqv4s9Jf=+Pb61iGx+n=u0DWjDyM7X=NDm6eg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: IPsecME WG <ipsec@ietf.org>, Nico Williams <nico@cryptonector.com>, "draft-ietf-ipsecme-split-dns.all@ietf.org" <draft-ietf-ipsecme-split-dns.all@ietf.org>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary="00000000000048d80e056f16a0f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/uA2MS9RndLZdS4ueP1YGiWr4f7Y>
Subject: Re: [IPsec] draft-pauly-ipsecme-split-dns
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2018 18:04:16 -0000

On Wed, Jun 20, 2018 at 7:15 AM, Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 19 Jun 2018, Eric Rescorla wrote:
>
> Yes, that's technically true, but the question is whether it's in fact
>> practical for people to do that.
>>
>
> I already responded before that yes I think it is practical.
>

Perhaps I have misunderstood you, but that's not what I have been getting
out of this conversation.


>    In most deployment scenario's, the IKE client has an expectation that
>>    it is connecting, using a split-network setup, to a specific
>>    organisation or enterprise.  A recommended policy would be to only
>>    accept INTERNAL_DNSSEC_TA directives from that organization's DNS
>>    names.  However, this might not be possible in all deployment
>>    scenarios, such as one where the IKE server is handing out a number
>>    of domains that are not within one parent domain.
>>
>> Is that text wrong? If not, I suspect we're just quibbling about "common".
>>
>
> I can clarify the text if you tell me what is bothering you.


I thought I had made clear what was bothering me, so I suppose we must be
talking past each other. I read this text as saying that there are
important cases where in fact the client will not have any reasonable  way
of knowing which domains to accept from the server, which, it seems to me,
contradicts the claim above that it's practical. You obviously think i'm
wrong, so how should I be reading this text?

-Ekr