From nobody Fri Jun 1 06:30:37 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774D12751F; Fri, 1 Jun 2018 06:30:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152785983554.14699.4435544739023643415.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 06:30:35 -0700 Archived-At: Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 13:30:36 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-ipsecme-11-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't object to this proposed charter going for internal review, but do have one question. When looking at some of the work items, I see "A possible starting point is draft-yeung-g-ikev2" (nit, missing closing period) "draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be good starting points for ESP compression." "draft-smyslov-ipsecme-ikev2-compression and raft-smyslov-ipsecme-ikev2-compact are good starting point for IKEv2 compression." (nit, should be "starting points") "draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point for this item." If you're using different language to convey a nuance, that would be fine (I'm missing it, but I miss things). If you're saying the same thing in all four cases, I'd suggest using the same phrasing in each case. so working group chairs and participants aren't trying to figure out whether "possible starting point" and "could be used as a starting point" are the same as "expected to be good starting points" and "are good starting points". I think I see "A possible starting point is" in most charters that point to individual drafts, which lets the working group decide whether to adopt that proposal or work on a different approach, but do the right thing, of course. From nobody Fri Jun 1 13:01:45 2018 Return-Path: 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 BFBD012D94D; Fri, 1 Jun 2018 13:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 Qhkz8PDnFBGO; Fri, 1 Jun 2018 13:01:33 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (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 CBB0612D7F3; Fri, 1 Jun 2018 13:01:32 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id w13-v6so2306828ywa.5; Fri, 01 Jun 2018 13:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywr2Apy8qVr+W76P4eyGVnPDGb+ygE6g2WMqlVxe0yg=; b=bJpmZVmMICZHe9ElL3QFJOhAQJ9EEIL0JEjumpCc7OHGHqG+M8u2V1zCJKN+ZVp+sP tXmiwWhgXtKrYlWiNOakmKN6ir7nB6b1iq9y4Hxk/f7XUSw6EbfFxX9Et35iSlcRuNJV usw/S1DlA+op5RlJgB4fi7lvfeUzw+p05LDnsy8DWT8Z9nqSxP5iVLpIhvxXegAl1KUv r3Zp2yUctb/DvephTx1YBVd5+ffQx58bpea8TpCr2M/ab8Z/uyVWjNIg6ig+UvuMP106 2q4ph8eXmSt4iGYsB2RtXQs7W/FqOfLExTKDDf/uJUHbkU/jlqT/rjVy621BmLDBRWbT 8m1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ywr2Apy8qVr+W76P4eyGVnPDGb+ygE6g2WMqlVxe0yg=; b=M7lJ4VXKaEOiGVDB4DW4WganGhCOprJm5WQ4iJzJrlq540Px+sLL/3GKiie8OpBJe1 sCCalLCictIZlIPWgJpFCKhoeDpiakRzq6Qe0OUlwZSdxWoRYvAT3jvN0dVkCcKMZ1V1 PBhg55m9y9RAaQrJEvR4HIDqK3tvqsPv+I4rDPVSehZjRFQ9gtyLVw8E4xJM8n5WTxeO 0Fx5QHvc8uFYCcLXChxItBOvdWnZyPjYKB5IHgV6tov8oBPUt4sakb9Hv8bYJI3zcmpd CS1YTkGbO5u+vToKT+tkrFjGKNyMtfbULdL3FzjLTr4OaZEOmVYL89YAiJ9fb4O8l1UF Necg== X-Gm-Message-State: ALKqPwd9QfYXHO8/CY/l81YGizRhBr6Vu723Y7apKTE6dGBkC9M/g1U+ 3Kph02NXtFPYtNCs++qPzIXxN2Bwl3TID3FiNxk= X-Google-Smtp-Source: ADUXVKJfbQYhtXjaovWc+HN8GEplrXwUHC/AZTFt8YfwC3OrmFnj830IW60/ExWKC1/mCcmCDSYDfI9lVQpW8RnixSY= X-Received: by 2002:a81:5f84:: with SMTP id t126-v6mr6744694ywb.19.1527883291760; Fri, 01 Jun 2018 13:01:31 -0700 (PDT) MIME-Version: 1.0 References: <152785983554.14699.4435544739023643415.idtracker@ietfa.amsl.com> In-Reply-To: <152785983554.14699.4435544739023643415.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 1 Jun 2018 15:01:19 -0500 Message-ID: To: IESG Cc: IPsecME WG , ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000dd1bd6056d9a0c2e" Archived-At: Subject: Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:01:36 -0000 --000000000000dd1bd6056d9a0c2e Content-Type: text/plain; charset="UTF-8" Thanks, Benjamin, for catching this ... On Fri, Jun 1, 2018 at 8:30 AM Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-ipsecme-11-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't object to this proposed charter going for internal review, but do > have > one question. > I don't object to this proposed charter going for EXTERNAL review, either, and that's actually what Eric is asking the IESG to ballot on ... Sorry! Spencer When looking at some of the work items, I see > > "A possible starting point is draft-yeung-g-ikev2" (nit, missing closing > period) > > "draft-mglt-ipsecme-diet-esp and > draft-mglt-ipsecme-ikev2-diet-esp-extension > are expected to be good starting points for ESP compression." > > "draft-smyslov-ipsecme-ikev2-compression and > raft-smyslov-ipsecme-ikev2-compact > are good starting point for IKEv2 compression." (nit, should be "starting > points") > > "draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point > for > this item." > > If you're using different language to convey a nuance, that would be fine > (I'm > missing it, but I miss things). > > If you're saying the same thing in all four cases, I'd suggest using the > same > phrasing in each case. so working group chairs and participants aren't > trying > to figure out whether "possible starting point" and "could be used as a > starting point" are the same as "expected to be good starting points" and > "are > good starting points". > > I think I see "A possible starting point is" in most charters that point to > individual drafts, which lets the working group decide whether to adopt > that > proposal or work on a different approach, but do the right thing, of > course. > > > --000000000000dd1bd6056d9a0c2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Benjamin, for catching this ...

On Fri, Jun 1, 2018 at 8:30 AM Spencer Da= wkins <spencerdawkins.i= etf@gmail.com> wrote:
Spence= r Dawkins has entered the following ballot position for
charter-ietf-ipsecme-11-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-= ipsecme/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't object to this proposed charter going for internal review, but = do have
one question.

I don't object to thi= s proposed charter going for EXTERNAL review, either, and that's actual= ly what Eric is asking the IESG to ballot on ...

S= orry!

Spencer

When looking at some of the work items, I see

"A possible starting point is draft-yeung-g-ikev2" (nit, missing = closing period)

"draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-ext= ension
are expected to be good starting points for ESP compression."

"draft-smyslov-ipsecme-ikev2-compression and raft-smyslov-ipsecme-ikev= 2-compact
are good starting point for IKEv2 compression." (nit, should be "= starting
points")

"draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting p= oint for
this item."

If you're using different language to convey a nuance, that would be fi= ne (I'm
missing it, but I miss things).

If you're saying the same thing in all four cases, I'd suggest usin= g the same
phrasing in each case. so working group chairs and participants aren't = trying
to figure out whether "possible starting point" and "could b= e used as a
starting point" are the same as "expected to be good starting poi= nts" and "are
good starting points".

I think I see "A possible starting point is" in most charters tha= t point to
individual drafts, which lets the working group decide whether to adopt tha= t
proposal or work on a different approach, but do the right thing, of course= .


--000000000000dd1bd6056d9a0c2e-- From nobody Tue Jun 5 13:21:21 2018 Return-Path: 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 7785A131196; Tue, 5 Jun 2018 13:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 U-8mZwYYrECG; Tue, 5 Jun 2018 13:21:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CE6131193; Tue, 5 Jun 2018 13:21:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w55KKufD019708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Jun 2018 23:20:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w55KKtOl006948; Tue, 5 Jun 2018 23:20:55 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23318.61607.819308.318996@fireball.acr.fi> Date: Tue, 5 Jun 2018 23:20:55 +0300 From: Tero Kivinen To: Spencer Dawkins Cc: "The IESG" , ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org In-Reply-To: <152785983554.14699.4435544739023643415.idtracker@ietfa.amsl.com> References: <152785983554.14699.4435544739023643415.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 20:21:13 -0000 Spencer Dawkins writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't object to this proposed charter going for internal review, but do have > one question. > > When looking at some of the work items, I see > > "A possible starting point is draft-yeung-g-ikev2" (nit, missing closing period) > > "draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension > are expected to be good starting points for ESP compression." > > "draft-smyslov-ipsecme-ikev2-compression and raft-smyslov-ipsecme-ikev2-compact > are good starting point for IKEv2 compression." (nit, should be "starting > points") > > "draft-boucadair-ipsecme-ipv6-ipv4-codes could be used as a starting point for > this item." > > If you're using different language to convey a nuance, that would be fine (I'm > missing it, but I miss things). It is supposed to be same. I.e., we already have some draft that is expected to be the draft we are going to consider as WG work draft in the future. The reason why the text is different for each of those is because different people wrote the texts. I.e., before we considered items to be added to charter, we wanted the people interested in item provide good enough charter item so we can understand what we are adding, and this means different people used different words to provide same meaning. . > If you're saying the same thing in all four cases, I'd suggest using the same > phrasing in each case. so working group chairs and participants aren't trying > to figure out whether "possible starting point" and "could be used as a > starting point" are the same as "expected to be good starting points" and "are > good starting points". That is ok for me. I also think that we as wg chairs and members already understand that, so it is not really necessarely, but if it makes it easier for someone else I have no objections changing the text (and I do not really care which version is used). > I think I see "A possible starting point is" in most charters that point to > individual drafts, which lets the working group decide whether to adopt that > proposal or work on a different approach, but do the right thing, of course. That is fine for me. -- kivinen@iki.fi From nobody Wed Jun 6 12:34:40 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32082120049; Wed, 6 Jun 2018 12:34:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831367012.6362.4051379754783235897.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 12:34:30 -0700 Archived-At: Subject: [IPsec] Alissa Cooper's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 19:34:31 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-ipsecme-11-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive comments: (1) I don't see the value in having an expiration date in a WG charter because it's not enforced in practice. The previous version of this charter said the WG would close if the charter wasn't updated by Dec 2017, but the WG continued to exist without the charter being updated. This charter seems tightly scoped enough to just get the work done according to the milestone dates or close sooner if people lose interest. (2) I think it might be worth a few words to state the reason why the goal was for the new IKEv2 mode to have the same quantum resistant properties as existed in IKEv1, rather than better/fuller quantum resistance. Nits: Based on the number of grammar and wording errors I found in this charter, I would strongly suggest doing a clean-up pass to make sure all of the text reads properly. Here is what I found: (1) s/to have similar quantum resistant properties than IKEv1 had/to have similar quantum resistant properties that IKEv1 had/ (2) s/in form of counter/in the form of a counter/ (3) I can't parse this sentence: "A growing number of use cases for constrained network - but not limited to - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields." (4) OLD Currently IKE peers have no explicit way to indicate each other which signature format(s) the support, that leads to ineroperability problems. NEW Currently IKE peers have no explicit way to indicate to each other which signature format(s) they support. That leads to ineroperability problems. (5) The milestones need to be updated. Some of the dates and draft names are wrong. From nobody Wed Jun 6 13:15:52 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7AE130DEE; Wed, 6 Jun 2018 13:15:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152831614275.6240.13480291312131109445.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 13:15:42 -0700 Archived-At: Subject: [IPsec] Ben Campbell's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 20:15:44 -0000 Ben Campbell has entered the following ballot position for charter-ietf-ipsecme-11-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's substantive and editorial comments. From nobody Wed Jun 6 14:37:15 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210F130DD3; Wed, 6 Jun 2018 14:37:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152832103138.6280.2877071506266435390.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 14:37:11 -0700 Archived-At: Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_chart?= =?utf-8?q?er-ietf-ipsecme-11-01=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 21:37:12 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-ipsecme-11-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree that I don’t see value in having the expiration date. Why does the working group feel this is needed? s/IPsec SA. non-standard/IPsec SA. Non-standard/ From nobody Wed Jun 6 23:38:25 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB003130E7C; Wed, 6 Jun 2018 23:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152835349472.6332.16442078486085339623.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2018 23:38:14 -0700 Archived-At: Subject: [IPsec] Suresh Krishnan's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 06:38:15 -0000 Suresh Krishnan has entered the following ballot position for charter-ietf-ipsecme-11-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- For the "The internal address failure indication in IKEv2" item it might be good to talk to 3GPP since they seem to be the only potential consumer of this work. From nobody Thu Jun 7 06:46:36 2018 Return-Path: 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 97D28131121; Thu, 7 Jun 2018 06:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 9-qcEp_bwx2b; Thu, 7 Jun 2018 06:46:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262C7131123; Thu, 7 Jun 2018 06:46:20 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w57DkGV3011723 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jun 2018 16:46:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w57DkF4L014861; Thu, 7 Jun 2018 16:46:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23321.14119.925224.292972@fireball.acr.fi> Date: Thu, 7 Jun 2018 16:46:15 +0300 From: Tero Kivinen To: Suresh Krishnan Cc: "The IESG" , ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org In-Reply-To: <152835349472.6332.16442078486085339623.idtracker@ietfa.amsl.com> References: <152835349472.6332.16442078486085339623.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] Suresh Krishnan's No Objection on charter-ietf-ipsecme-11-01: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:46:25 -0000 Suresh Krishnan writes: > Suresh Krishnan has entered the following ballot position for > charter-ietf-ipsecme-11-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-ipsecme/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > For the "The internal address failure indication in IKEv2" item it might be > good to talk to 3GPP since they seem to be the only potential consumer of this > work. The work originiated from 3gpp, and they tried to get numbers allocated from the IANA registry, but expert (me) asked them to first talk to the wg and see if there is interest working about the issue there. Working group discussed this and said that the work might be useful for other contextes than 3gpp too, so wg decided that we are going to take it as WG item instead of going forward as individual author RFC. -- kivinen@iki.fi From nobody Mon Jun 11 12:58:37 2018 Return-Path: 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 5F9BE130ECB for ; Mon, 11 Jun 2018 12:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DDx8YLMIaQps for ; Mon, 11 Jun 2018 12:58:32 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0975130EB1 for ; Mon, 11 Jun 2018 12:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528747112; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4YhW/1MU1zN0e1k+W9M3xLAp3XZ5hShGGZYga8UDCHU=; b=UIaZBFWAeLIalDlGulYFaT4yORig5hYySYUQBlvruiuFCPDfbYNWtFV7JkBxGGbi qhnSsUx0urCqe6Oxnecc1B+vWaKqITcUXfr+mgAPssftd6gEZ2PDbtSyiPRSYQnh WFXInR8waR34crXvF1D8d+UDm/lJEhX77LsGdp8kqM8=; X-AuditID: c618062d-a81ff70000001885-20-5b1ed467c23e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id BD.B5.06277.764DE1B5; Mon, 11 Jun 2018 21:58:32 +0200 (CEST) Received: from EUSASMB503.ericsson.se (147.117.188.221) by EUSAAHC004.ericsson.se (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 11 Jun 2018 15:58:31 -0400 Received: from EUSASMB503.ericsson.se (147.117.188.239) by EUSASMB503.ericsson.se (147.117.188.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 11 Jun 2018 15:58:30 -0400 Received: from EUSASMB503.ericsson.se ([147.117.188.239]) by EUSASMB503.ericsson.se ([147.117.188.239]) with mapi id 15.01.1466.003; Mon, 11 Jun 2018 15:58:30 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: Small update on netdev 0x12 conference @IETF102 Montreal Thread-Index: AdQBvXhXmz+a6RCYThqeCbmDWAFjvwAANQTw Date: Mon, 11 Jun 2018 19:58:30 +0000 Message-ID: References: <25b73d55141f4299a5541c303530017a@ericsson.com> In-Reply-To: <25b73d55141f4299a5541c303530017a@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.8] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiG7GFblog7NPuC32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI0vHjAXbBCtuHtQp4HxhUgXIyeHhICJxLKV85m7GLk4hASO MkrsnTCDHcLZxiixdNcUqMwPRolpUyYwQTgrGCUuHjzEBtLPJmAk0XaoH6iFg0NEQF5i5o1M kLCwgKPExOvPmUFsEQE3iWernzFBlBhJ9L2zAAmzCKhKNF2/yAhi8wpYS1z+fJcNpEQIyN68 NR4kzClgI3H+yBZ2EJtRQEzi+6k1TCA2s4C4xK0n85kgHhCQWLLnPDOELSrx8vE/VghbUeLz 6RtghzELaEqs36UP0aooMaX7ITvEVkGJkzOfsEBs1ZB4dU9yAqP4LCQLZiE0z0LSPAtJ8wJG llWMHKXFBTm56UYGmxiBEXJMgk13B+P96Z6HGAU4GJV4eBcclYsWYk0sK67MPcQowcGsJMLr pQAU4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvGkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwKj+YPna dyEdq+5w6wgUvIi6uEDTyNUyTGNzyI7fpUxzq//fDyu/9+pzik3u4tWPvksu1xO7M0uV8/X1 U/OP7D5SxKFmUdOwbKHr2+b0RfdYma7ymZ6K8Txy/JyYVN5aMUdni4ddh2csUmG6XK5+8yBv 57bLp485yG2Z3d3qGyM0p0dTWZK9NlWJpTgj0VCLuag4EQC4WYT5jAIAAA== Archived-At: Subject: [IPsec] Small update on netdev 0x12 conference @IETF102 Montreal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:58:36 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhbiB1cGRhdGUgb24gdGhlIG5ldGRldiAweDEyIGNvbmZlcmVu Y2UuIFRvcGljcyBoYXZlIGJlZW4gYXJyYW5nZWQgYWNjb3JkaW5nIHRvIElFVEYgYXJlYXMgZm9y IG1vcmUgcmVhZGFiaWxpdHkgYnkgSmFtYWwuDQoNClRoZSBjb25mZXJlbmNlIGlzIGp1c3QgcHJp b3IgdGhlIElFVEYgMTAyIGFuZCBvbmx5IGEgNSBtaW51dGUgd2FsayBmcm9tIElFVEYgbG9jYXRp b24hIFdlIGhvcGUgdG8gc2VlIHlvdSB0aGVyZSENCg0KWW91cnMsIA0KRGFuaWVsICANCg0KLS0t LS0tDQoNCioqS2V5bm90ZSBieSB0aGUgbGVnZW5kYXJ5IFZhbiBKYWNvYnNvbg0KaHR0cHM6Ly93 d3cubmV0ZGV2Y29uZi5vcmcvMHgxMi9uZXdzLmh0bWw/a2V5bm90ZS12YW4tamFjb2Jzb24tZXZv bHZpbmctZnJvbS1hZmFwLXRlYWNoaW5nLW5pY3MtYWJvdXQtdGltZQ0KDQpUcmFuc3BvcnQgQXJl YSB0YWxrcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQkJSeDogRXh0ZW5kaW5nIEJCUiBmb3Ig Q3VzdG9taXplZCBUQ1AgUGVyZm9ybWFuY2UgaHR0cHM6Ly93d3cubmV0ZGV2Y29uZi5vcmcvMHgx Mi9zZXNzaW9uLmh0bWw/YmJyeC1leHRlbmRpbmctYmJyLWZvci1jdXN0b21pemVkLXRjcC1wZXJm b3JtYW5jZQ0KDQpBIFBDQy1WaXZhY2UgS2VybmVsIE1vZHVsZSBmb3IgQ29uZ2VzdGlvbiBDb250 cm9sIGh0dHBzOi8vd3d3Lm5ldGRldmNvbmYub3JnLzB4MTIvc2Vzc2lvbi5odG1sP2EtcGNjLXZp dmFjZS1rZXJuZWwtbW9kdWxlLWZvci1jb25nZXN0aW9uLWNvbnRyb2wNCg0KRGV2ZWxvcGluZyBh bmQgRGVwbG95aW5nIGEgVENQIFJlcGxhY2VtZW50IGZvciB0aGUgV2ViIGh0dHBzOi8vd3d3Lm5l dGRldmNvbmYub3JnLzB4MTIvc2Vzc2lvbi5odG1sP2RldmVsb3BpbmctYW5kLWRlcGxveWluZy1h LXRjcC1yZXBsYWNlbWVudC1mb3ItdGhlLXdlYg0KDQpIb3cgaGFyZCBjYW4gaXQgYmU/IEFkZGlu ZyBNdWx0aXBhdGggVENQIHRvIHRoZSB1cHN0cmVhbSBrZXJuZWwgaHR0cHM6Ly93d3cubmV0ZGV2 Y29uZi5vcmcvMHgxMi9zZXNzaW9uLmh0bWw/aG93LWhhcmQtY2FuLWl0LWJlLWFkZGluZy1tdWx0 aXBhdGgtdGNwLXRvLXRoZS11cHN0cmVhbS1rZXJuZWwNCg0KUmVzdHJ1Y3R1cmluZyBFbmRwb2lu dCBDb25nZXN0aW9uIENvbnRyb2wgaHR0cHM6Ly93d3cubmV0ZGV2Y29uZi5vcmcvMHgxMi9zZXNz aW9uLmh0bWw/cmVzdHJ1Y3R1cmluZy1lbmRwb2ludC1jb25nZXN0aW9uLWNvbnRyb2wNCg0KVHV0 b3JpYWwgb24gU2VydmVyIE1pZ3JhdGlvbiB3aXRoIFRDUF9SRVBBSVIgaHR0cHM6Ly93d3cubmV0 ZGV2Y29uZi5vcmcvMHgxMi9zZXNzaW9uLmh0bWw/c2VydmVyLW1pZ3JhdGlvbi13aXRoLXRjcF9y ZXBhaXINCg0KU2VjdXJpdHkgQXJlYToNCi0tLS0tLS0tLS0tLS0tLS0NCg0KSVBTZWMvSUtFIHR1 dG9yaWFsDQpodHRwczovL3d3dy5uZXRkZXZjb25mLm9yZy8weDEyL3Nlc3Npb24uaHRtbD9pcHNl Y2lrZS10dXRvcmlhbGxhYg0KDQpSb3V0aW5nIEFyZWE6DQotLS0tLS0tLS0tLS0tDQoNClR1dG9y aWFsOiBJbnRyb2R1Y3Rpb24gdG8gRnJlZSBSYW5nZSBSb3V0aW5nKEZSUikgaHR0cHM6Ly93d3cu bmV0ZGV2Y29uZi5vcmcvMHgxMi9zZXNzaW9uLmh0bWw/aW50cm9kdWN0aW9uLXRvLWZycm91dGlu Zw0KDQpJbnRlcm5ldCBBcmVhOg0KLS0tLS0tLS0tLS0tLS0NCklkZW50aWZpZXIgTG9jYXRvciBB ZGRyZXNzaW5nIHVuZGVyIHRoZSBob29kIGh0dHBzOi8vd3d3Lm5ldGRldmNvbmYub3JnLzB4MTIv c2Vzc2lvbi5odG1sP2lkZW50aWZpZXItbG9jYXRvci1hZGRyZXNzaW5nLXVuZGVyLXRoZS1ob29k DQoNCldvcmtzaG9wIG9uIElPVC82bG93cGFuIGFuZCByZWxhdGVkIE1BQyBhcmVhcyBodHRwczov L3d3dy5uZXRkZXZjb25mLm9yZy8weDEyL3Nlc3Npb24uaHRtbD93b3Jrc2hvcC1vbi1pb3QtcmVs YXRlZC1tYWMtbGF5ZXJzLWhlYWRlci1jb21wcmVzc2lvbi1hbmQtcm91dGluZy1wcm90b2NvbHMN Cg0K From nobody Tue Jun 12 01:53:55 2018 Return-Path: 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 6309A131113 for ; Tue, 12 Jun 2018 01:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 J2uaRJj5cwRC for ; Tue, 12 Jun 2018 01:53:49 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 E072D130E18 for ; Tue, 12 Jun 2018 01:53:48 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id j15-v6so21721004wme.0 for ; Tue, 12 Jun 2018 01:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=93ZDxjTHr/pW8tSSzmMOXeRoIEs7C2Dv7kjERfEhXO4=; b=o/CUo3ChwKB4RW5I7O1jlulKxjgwg3i2oGSZZoMn+o1v1ksVPv92zAhjMFahqHTHlE /zJo2R5ytJmr6lwqMRGsBNOgdaAGiJiF3q7gkn59u20WVqIJ0PIFH+dty2KV01yFqdvw 14UTAVcTXKamdm/eTSKLZ0pDLxlLOYeX5wIUnbr4WbjS8K4wQtQXRm4HVX19bYDB6cv7 Tw7oVtaBp0c+M8IKmrt/0MY90DT9gSz02fHR8yyj/V53gt1g6DlIEuINkDIFGWcXwGZb G+wyPnHDQ52zb2JMqyk+OBYvBIBy83fn1mKP74vuH6dnJWVCmlxv5Dg2IxqOgobIa20U 3HCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=93ZDxjTHr/pW8tSSzmMOXeRoIEs7C2Dv7kjERfEhXO4=; b=RrV2lssiWpgLLcvdQWn9wLg7nKFpCwlYynXpeaJiWcul/MbKzbFqiJe34MTDC6xQpA MrAkCgBNYMIxjKTh6/i//JLdmHHEzx9DmU9Zq7C5UiUNtShsKXo2U6ciyKFtc88teAfo UlgTLQisUQTbLQ4SFeaStwyl1J7uM/QjVWSrlKONbGXEculQ6H55saPhmwrLGT3Me2tp utgytjA14wu67U2oEyxOm75fpXLuNseQTwFTRZp9veZkSWTmmR7Ps64bm30GdFKbxqHU vjigqMGrX5xjjol9dFc+km7JbNumRZUSJhRzjEYI3Cv/CfgxZAhn6SF0cmjnpeQmwXwb UAoQ== X-Gm-Message-State: APt69E0oAWcKfMFcelbJq6lTfjnbq0XYIsISsqisLleMVFyouLTb2gJL BSS6xUG+pQCTxv5RYVpEciMQgGklAyz/ltPtzZesIg== X-Google-Smtp-Source: ADUXVKIk3s/knPWQ6AVXtFmNHmQP1zUnXgT7OYIGcenOioax6Ow7C/6BhHSq3KAVM4k9L+Qc6SMHIlRzGNKq3piIKUM= X-Received: by 2002:a50:8cb7:: with SMTP id q52-v6mr2721990edq.17.1528793627231; Tue, 12 Jun 2018 01:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:a593:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 01:53:46 -0700 (PDT) From: riyaz talikoti Date: Tue, 12 Jun 2018 14:23:46 +0530 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000001609b2056e6e0150" Archived-At: Subject: [IPsec] INITIAL_CONTACT in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 08:53:52 -0000 --0000000000001609b2056e6e0150 Content-Type: text/plain; charset="UTF-8" Hi All, Need help with couple of questions related to INITIAL_CONTACT in IKEv1 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE? Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being created as part of just completed AGGRESSIVE MODE exchange? If we receive INITIAL_CONTACT notification in QUICK MODE, as a responder should we ignore the notification? 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to delete all IPSec SA's(Phase 2 SA's) which are part of that particular IKE SA(Phase 1 SA) ? Because the whole purpose is to inform responder to delete all previous connection related to this identity as initiator is coming UP freshly. Regards Riyaz --0000000000001609b2056e6e0150 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
Need help with couple of questions related to = INITIAL_CONTACT in IKEv1

1. Is it NOT wrong to send= INITIAL_CONTACT notification in QUICK MODE?
Will it NOT en= d up in deleting the IKE SA(Phase 1 SA) which is being created as part of j= ust completed AGGRESSIVE MODE exchange?
If we receive INITIAL_CON= TACT notification in QUICK MODE, as a responder should we ignore the notifi= cation?

2. On receiving INITIAL_CONTACT we delete = IKE SA. Doesn't it make sense to delete all IPSec SA's(Phase 2 SA&#= 39;s) which are part of that particular IKE SA(Phase 1 SA) ?
Beca= use the whole purpose is to inform responder to delete all previous connect= ion related to this identity as initiator is coming UP freshly.
=

Regards
Riyaz
--0000000000001609b2056e6e0150-- From nobody Tue Jun 12 10:04:52 2018 Return-Path: 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 964D6130F5C for ; Tue, 12 Jun 2018 10:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 EStEDKTG4-kD for ; Tue, 12 Jun 2018 10:04:47 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 B246E1277BB for ; Tue, 12 Jun 2018 10:04:46 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id o12-v6so24839544wrm.12 for ; Tue, 12 Jun 2018 10:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QbsXKsX5GxdPqxwmlKxZCd85bFFeA75Xc67mnuCd4ng=; b=QENtn2IzkvU1HYl4+vt4KqKW+hmfyRTj+IGyO3fcvQnEIqdcJTf5wh84vW4FafIGKG iuiV55eL7tyyrvc/Y+/XZ7Iq/HOO6IJ+nJLS/QqDcs7QAtmfouWIj8FJIwOzdpDbElPc 3BRLlGS7FnVFJFoyWH4gCxXukxMUljxioPSBm0g6vT7ExLb2hBukTrZTEKvThm+JcPD/ s02mtCxme9PAPWmg0VzxaxaltqobAQVVcJ1rZsNRbFHNL3dNgWLSK8F4slfxOUe0u6c5 15cwxD3TpwPuY763W5sq8tn1uO4bjNNf22QEydRyNLAtSA3jkjDDB9DL7zu+WSV/nyX0 QgWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QbsXKsX5GxdPqxwmlKxZCd85bFFeA75Xc67mnuCd4ng=; b=c5Td/qxdpUyZjQwoh4W1lB0/HXTlZUU4B2NYBYWjREPse3y4lQfCDTDgvYxjWqKW+v Tzw27fih/unTxWawdndVrN3x982jWD2I3yo2+H/nnJGmp0RC/KaqSLcrmRXqJM7XsiNn Ib5cabaIw1zkgDqibEFepKlttrf6zo9wUKm2OUFANv5hfdFMhVF/cLHCn2fE1QwgGdxi 4uCEzIRgzVz+1yo++jVerk2N0j1ZAGGwc8QyJQd8Tc9eMJuShhcLIGo3+IfFA9tIAZdg VE8TSkyQABISXBIdMYP7wgP6qx0s6aqYapsUGfSTCYfVyNWRUU5I1XzkRKb1PCrEKjzU QLmg== X-Gm-Message-State: APt69E3ag/IMnOVagEVd8Sg/WzWHXMLAwmExr/7bxgk01a3pAUg+FDm1 77iWBbLfnBGhRome5VxG2b4= X-Google-Smtp-Source: ADUXVKIk9rwV1pB67bx7XTp1eu6AxdDabRDQpyJb6yF6biPt+NM5Kw8wBSaNccDdZEur1PZBmrZmYw== X-Received: by 2002:adf:88ca:: with SMTP id g10-v6mr913446wrg.62.1528823085235; Tue, 12 Jun 2018 10:04:45 -0700 (PDT) Received: from [192.168.1.17] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id h193-v6sm1255132wmd.25.2018.06.12.10.04.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 10:04:43 -0700 (PDT) From: Yoav Nir Message-Id: <683BEC43-A0E4-4AF2-8C0E-B36B852601D7@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D4035F3E-50B5-479F-814D-F13DA69B273C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 12 Jun 2018 20:04:40 +0300 In-Reply-To: Cc: ipsec@ietf.org To: riyaz talikoti References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [IPsec] INITIAL_CONTACT in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 17:04:50 -0000 --Apple-Mail=_D4035F3E-50B5-479F-814D-F13DA69B273C Content-Type: multipart/alternative; boundary="Apple-Mail=_8F0963E5-2719-4887-9E22-D5654E00A5C4" --Apple-Mail=_8F0963E5-2719-4887-9E22-D5654E00A5C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Jun 2018, at 11:53, riyaz talikoti wrote: >=20 > Hi All, > Need help with couple of questions related to INITIAL_CONTACT in IKEv1 >=20 > 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK MODE? > Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being = created as part of just completed AGGRESSIVE MODE exchange? > If we receive INITIAL_CONTACT notification in QUICK MODE, as a = responder should we ignore the notification? >=20 > 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make = sense to delete all IPSec SA's(Phase 2 SA's) which are part of that = particular IKE SA(Phase 1 SA) ? > Because the whole purpose is to inform responder to delete all = previous connection related to this identity as initiator is coming UP = freshly. >=20 Hi, Riyaz INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407. It does not = specify that this notification should only be sent in phase 1 messages, = although I agree that it makes little sense in the context of QUICK = MODE. So the answer to #1 is that it is not wrong. The meaning of this notification is that all IKE SAs except the one = being used or created in this negotiation is not known to the sender. = RFC 2407 unfortunately talks only of an =E2=80=9CSA=E2=80=9D without = specifying whether this is about an IKE SA or an IPsec SA. I think the = only sane interpretation is that this is about IKE SAs. So if an = AGGRESSIVE negotiation created an IKE SA and this IKE SA is used to = protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE = negotiation was used to create a different IKE SA, then it will be = deleted. You are always allowed to ignore an INITIAL_CONTACT notification. It is = meant to help you with state management. If you use some other IKE SA = created before you received the INITIAL_CONTACT, you are very likely to = get an error. Regarding question #2: To clarify, on receiving INITIAL_CONTACT you = delete all the other IKE SAs, not the one used in the negotiation. The question of deleting the associated IPsec SAs when deleting an IKE = SA is, unfortunately, not answered in the IKEv1 RFCs. Most vendors = followed Cisco=E2=80=99s example and deleted them. A few didn=E2=80=99t. = In the case of INITIAL-CONTACT it makes even more sense than when an = IKE SA is explicitly deleted with a DELETE payload. HTH Yoav --Apple-Mail=_8F0963E5-2719-4887-9E22-D5654E00A5C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 12 Jun 2018, at 11:53, riyaz talikoti <riyazinbec@gmail.com> wrote:

Hi All,
Need help with couple of questions = related to INITIAL_CONTACT in IKEv1

1. Is it NOT wrong to send = INITIAL_CONTACT notification in QUICK MODE?
Will it NOT end up in deleting the IKE SA(Phase 1 SA) which = is being created as part of just completed AGGRESSIVE MODE = exchange?
If we receive INITIAL_CONTACT = notification in QUICK MODE, as a responder should we ignore the = notification?

2.= On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to = delete all IPSec SA's(Phase 2 SA's) which are part of that particular = IKE SA(Phase 1 SA) ?
Because the whole purpose is = to inform responder to delete all previous connection related to this = identity as initiator is coming UP freshly.

Hi, = Riyaz

INITIAL_CONTACT is defined in = section 4.6.3.3 or RFC 2407.  It does not specify that this = notification should only be sent in phase 1 messages, although I agree = that it makes little sense in the context of QUICK MODE.

So the answer to #1 is that it is not = wrong. 

The meaning of this = notification is that all IKE SAs except the one being used or created in = this negotiation is not known to the sender. RFC 2407 unfortunately = talks only of an =E2=80=9CSA=E2=80=9D without specifying whether this is = about an IKE SA or an IPsec SA. I think the only sane interpretation is = that this is about IKE SAs. So if an AGGRESSIVE negotiation created an = IKE SA and this IKE SA is used to protect the QUICK MODE, that IKE SA is = safe. If the AGGRESSIVE negotiation was used to create a different IKE = SA, then it will be deleted.

You are = always allowed to ignore an INITIAL_CONTACT notification. It is meant to = help you with state management.  If you use some other IKE SA = created before you received the INITIAL_CONTACT, you are very likely to = get an error.

Regarding question #2: = To clarify, on receiving INITIAL_CONTACT you delete all the other IKE SAs, = not the one used in the negotiation.
The question of deleting = the associated IPsec SAs when deleting an IKE SA is, unfortunately, not = answered in the IKEv1 RFCs. Most vendors followed Cisco=E2=80=99s = example and deleted them. A few didn=E2=80=99t.  In the case of = INITIAL-CONTACT it makes even more sense than when an IKE SA is = explicitly deleted with a DELETE payload.

HTH

Yoav

= --Apple-Mail=_8F0963E5-2719-4887-9E22-D5654E00A5C4-- --Apple-Mail=_D4035F3E-50B5-479F-814D-F13DA69B273C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlsf/SgACgkQuEkLFQpY zJl4uQgAgNd/f6qjxqAxei4xIwrxunYnCilBL+hTMIwsb/ULC1BJASU8y42OfeER JniPvjZ3zS2sLF7Ny35FF3dfSyXYAiCPF3NNue9KZ9MeAhUdcPNQv0dOen6v2TB5 uIt7rflzuH/ZBs8yLMVK1xPOvVWxLPdUVYrG1xS9+fmQUnEF9Xt0fR4yaXjQ7a3S udkFYC2Z3VgoBqxaM8ZzgF4fpMLKNjxHzp69Ytn8NZtzvLBVMBBf8rsvI0+3kDz3 QQTCO3J9bOtCiKHaZCWTupc8Zlg7P0ttkqxO6PM6DITZPpTBrZIuKF/vPsC0iT6H Eaz+CakZbTZWQ/fDInmA9gL1HRxUvQ== =diK6 -----END PGP SIGNATURE----- --Apple-Mail=_D4035F3E-50B5-479F-814D-F13DA69B273C-- From nobody Thu Jun 14 09:03:34 2018 Return-Path: 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 BD540130E42 for ; Thu, 14 Jun 2018 09:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 kR-ieR0_XVNV for ; Thu, 14 Jun 2018 09:03:29 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 5F7DA130E36 for ; Thu, 14 Jun 2018 09:03:29 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id a63-v6so3473531pfl.1 for ; Thu, 14 Jun 2018 09:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IalKWZPeeoSTZuBVfuNEY+KlDO58w/fWRr7szL16am8=; b=qxOICxWjORHlutKZ4mOlnB8aFuOZ6qHV/Li76aexlcZzSVZ+GDGl26lcakKfN/NlBa v8R0sMu/m9fBclfIggf8M4nRWYe3rCL9DAR0KEXH5vZOhMAFrtmbJx6ARfbo45i+I4ua NUuumJ+ezCEW9QUxhmiIM9ZICXXxes+VaFQzf/mxnroArQ9lJ1pQpUHrv6fHmi9j1bqJ XWMJ3klz8w8ppzX7QhloqcYFbSglTz3nb4mSqP/8B/VVmMbVELgatPhbxblM0Z3SIdHW aj6kqmyJZjbQ9Rbd9g423ktn6TsxhFxnO/omzIiFPrbt14RGWnEFlMz5pZB5c3T0cUTQ kT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IalKWZPeeoSTZuBVfuNEY+KlDO58w/fWRr7szL16am8=; b=KQLjqMKbIqZXysZ6JnQQDmXb1Xgg6GIBy51apH1n9HRGORxk/eTIGnVd8a9Pc3YDrI SFk+LJOlfbQKlHrrKHdDwhv1gUlaIe1TPCZXIJSmmtmaZYFRZwc/7LPJfmNdO6DaBwWC PwDaR9tGBdRMpQJXLWrEW7p1nkONjwVS4VEmMnlatViyCGaTvbvBd+p+QobhQMDJvN0z r/4quVkB1aNOEeA7z1tfDrmOcl8olcZcr6QZNgSwI6oWjsI7AofstHj9cME1vK33nbbK lS7wDXedUrdlU2pHVIEdFnylAknWrC+J1kJl45V7tcenqNDiJ552KCM8mle8Jbh8IiSy lU/A== X-Gm-Message-State: APt69E0/I7BINLsDowC+GeAV8qrxk5FbS0J4JB35XZMqwEDd9YqcwUuA VV9XjRunlp3EZS8E8xoXK6k= X-Google-Smtp-Source: ADUXVKIc4+tP0MzpLcrWH3QMJPHi//Hx25SsAFB0regZ0t4vUzKzCufDdF4kxm8KokBkDnRaxqj6HQ== X-Received: by 2002:a62:40dc:: with SMTP id f89-v6mr9976836pfd.194.1528992208724; Thu, 14 Jun 2018 09:03:28 -0700 (PDT) Received: from ?IPv6:2001:420:c0e0:1006::41a? ([2001:420:c0e0:1006::41a]) by smtp.gmail.com with ESMTPSA id k24-v6sm8266437pff.118.2018.06.14.09.03.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 09:03:27 -0700 (PDT) From: riyaz talikoti Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5102175F-7BA7-4258-BAB2-07449150C720" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 14 Jun 2018 21:33:23 +0530 In-Reply-To: <683BEC43-A0E4-4AF2-8C0E-B36B852601D7@gmail.com> Cc: ipsec@ietf.org To: Yoav Nir References: <683BEC43-A0E4-4AF2-8C0E-B36B852601D7@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [IPsec] INITIAL_CONTACT in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 16:03:32 -0000 --Apple-Mail=_5102175F-7BA7-4258-BAB2-07449150C720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav, Thanks a lot for the response. Just a quick question on top of what you wrote.=20 If a responder did not delete IPSec SA=E2=80=99s and only deletes IKE SA = when it receives IC.=20 Will it not result in blackhole?=20 Lets say=20 PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 = =E2=80=94 =E2=80=94 PEER-B IKE SA(XX) IKE SA(XX) IPSEC SA(SPI AA) IPSEC SA(SPI AA) PEER-A starts initiating new session and starts AGGRESSIVE_MODE.=20 PEER-B receives IC and lets say PEER-B deletes ONLY IKE = SA(XX)(recommended by RFC),=20 But will NOT delete IPSEC SA(SPI AA)(as RFC does not mention anything = about it). And AM and QM exchanges gets completed and new sets of SA=E2=80=99s = comes UP on both sides Now=20 PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 = =E2=80=94 =E2=80=94 PEER-B IKE SA(YY) IKE SA(YY) IPSEC SA(SPI BB) IPSEC SA(SPI BB) IPSEC SA(SPI AA) =E2=80=94= > NOT DELETED When IC is received. For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will it = NOT get dropped at PEER-A with INVALID_SPI. So does it not make sense to delete all IPSec SA=E2=80=99s when IC is = received. Regards Riyaz > On 12-Jun-2018, at 10:34 PM, Yoav Nir wrote: >=20 >=20 >> On 12 Jun 2018, at 11:53, riyaz talikoti > wrote: >>=20 >> Hi All, >> Need help with couple of questions related to INITIAL_CONTACT in = IKEv1 >>=20 >> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK = MODE? >> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being = created as part of just completed AGGRESSIVE MODE exchange? >> If we receive INITIAL_CONTACT notification in QUICK MODE, as a = responder should we ignore the notification? >>=20 >> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make = sense to delete all IPSec SA's(Phase 2 SA's) which are part of that = particular IKE SA(Phase 1 SA) ? >> Because the whole purpose is to inform responder to delete all = previous connection related to this identity as initiator is coming UP = freshly. >>=20 >=20 > Hi, Riyaz >=20 > INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407. It does = not specify that this notification should only be sent in phase 1 = messages, although I agree that it makes little sense in the context of = QUICK MODE. >=20 > So the answer to #1 is that it is not wrong.=20 >=20 > The meaning of this notification is that all IKE SAs except the one = being used or created in this negotiation is not known to the sender. = RFC 2407 unfortunately talks only of an =E2=80=9CSA=E2=80=9D without = specifying whether this is about an IKE SA or an IPsec SA. I think the = only sane interpretation is that this is about IKE SAs. So if an = AGGRESSIVE negotiation created an IKE SA and this IKE SA is used to = protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE = negotiation was used to create a different IKE SA, then it will be = deleted. >=20 > You are always allowed to ignore an INITIAL_CONTACT notification. It = is meant to help you with state management. If you use some other IKE = SA created before you received the INITIAL_CONTACT, you are very likely = to get an error. >=20 > Regarding question #2: To clarify, on receiving INITIAL_CONTACT you = delete all the other IKE SAs, not the one used in the negotiation. > The question of deleting the associated IPsec SAs when deleting an IKE = SA is, unfortunately, not answered in the IKEv1 RFCs. Most vendors = followed Cisco=E2=80=99s example and deleted them. A few didn=E2=80=99t. = In the case of INITIAL-CONTACT it makes even more sense than when an = IKE SA is explicitly deleted with a DELETE payload. >=20 > HTH >=20 > Yoav >=20 --Apple-Mail=_5102175F-7BA7-4258-BAB2-07449150C720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Yoav,
Thanks a lot for the response.
Just a quick question on top of what you = wrote. 

If = a responder did not delete IPSec SA=E2=80=99s and only deletes IKE SA = when it receives IC. 
Will it not result in = blackhole? 

Lets say 
PEER-A = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94 = =E2=80=94 PEER-B
IKE SA(XX) =          IKE SA(XX)
IPSEC SA(SPI AA)             =       IPSEC SA(SPI AA)

PEER-A starts initiating new session = and starts AGGRESSIVE_MODE. 
PEER-B receives = IC and lets say PEER-B deletes ONLY IKE SA(XX)(recommended by = RFC), 
But will NOT delete IPSEC SA(SPI AA)(as = RFC does not mention anything about it).

And AM and QM exchanges gets completed = and new sets of SA=E2=80=99s comes UP on both sides

Now 
PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 =E2=80=94 =E2=80=94 PEER-B
IKE = SA(YY) =           IKE = SA(YY)
IPSEC SA(SPI BB)         =           IPSEC SA(SPI BB)
=   IPSEC SA(SPI AA) =E2=80=94&g= t; NOT DELETED When IC is received.

For outgoing traffic from PEER-B, if = SPI AA is chosen from SADB, will it NOT get dropped at PEER-A with = INVALID_SPI.
So does it not make sense to delete = all IPSec SA=E2=80=99s when IC is received.

Regards
Riyaz



On = 12-Jun-2018, at 10:34 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 12 = Jun 2018, at 11:53, riyaz talikoti <riyazinbec@gmail.com> wrote:

Hi All,
Need help with couple of questions = related to INITIAL_CONTACT in IKEv1

1. Is it NOT wrong to send = INITIAL_CONTACT notification in QUICK MODE?
Will it NOT end up in deleting the IKE SA(Phase 1 SA) which = is being created as part of just completed AGGRESSIVE MODE = exchange?
If we receive INITIAL_CONTACT = notification in QUICK MODE, as a responder should we ignore the = notification?

2.= On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to = delete all IPSec SA's(Phase 2 SA's) which are part of that particular = IKE SA(Phase 1 SA) ?
Because the whole purpose is = to inform responder to delete all previous connection related to this = identity as initiator is coming UP freshly.

Hi, Riyaz

INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407. =  It does not specify that this notification should only be sent in = phase 1 messages, although I agree that it makes little sense in the = context of QUICK MODE.

So the answer to #1 is that it is not wrong. 

The meaning of this = notification is that all IKE SAs except the one being used or created in = this negotiation is not known to the sender. RFC 2407 unfortunately = talks only of an =E2=80=9CSA=E2=80=9D without specifying whether this is = about an IKE SA or an IPsec SA. I think the only sane interpretation is = that this is about IKE SAs. So if an AGGRESSIVE negotiation created an = IKE SA and this IKE SA is used to protect the QUICK MODE, that IKE SA is = safe. If the AGGRESSIVE negotiation was used to create a different IKE = SA, then it will be deleted.

You are always allowed to ignore an = INITIAL_CONTACT notification. It is meant to help you with state = management.  If you use some other IKE SA created before you = received the INITIAL_CONTACT, you are very likely to get an = error.

Regarding= question #2: To clarify, on receiving INITIAL_CONTACT you delete all the other IKE SAs, = not the one used in the negotiation.
The question = of deleting the associated IPsec SAs when deleting an IKE SA is, = unfortunately, not answered in the IKEv1 RFCs. Most vendors followed = Cisco=E2=80=99s example and deleted them. A few didn=E2=80=99t.  In = the case of INITIAL-CONTACT it makes even more sense than when an IKE SA = is explicitly deleted with a DELETE payload.

HTH

Yoav


= --Apple-Mail=_5102175F-7BA7-4258-BAB2-07449150C720-- From nobody Thu Jun 14 09:25:35 2018 Return-Path: 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 21D4F13118F for ; Thu, 14 Jun 2018 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nVNZDoS33KQu for ; Thu, 14 Jun 2018 09:25:25 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 94E0613116D for ; Thu, 14 Jun 2018 09:25:24 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id 69-v6so13105349wmf.3 for ; Thu, 14 Jun 2018 09:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NnNGIcXl9NwZ4UUNp2kB8XKhWWG/12is6Q9qY9cSSy4=; b=EJjBqNwmqc54vKAJMdl7hFKrDmLabEd1Vap6FJtiSLTbCIolm/kLRyvTOZXBxOgRX7 pSuT3xnCoHe2oiDyB3+by7A43SqfCuyGsuc5/cigqoJY5k8Onnrdq516rTq/QQ072KDn FtigBKEkFvH1BO79aWZvEtL0BdrFzXHaI+yY3wvI2lEvqgH0no/WUQ4PEk8NfW4yKwx+ 2DgKHGgUj6TT2pC4Y+imRYbVxHkqDf0pSxffIHOWr66G1P93JPF9H5Ho44/HLiH9eu4+ PXiG8eg2tJWC54ddD9NiPs6xzNck/lgbcgaqj/j4lZYeUE4qAy8odnBof+J1NC4/M3pq GcSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NnNGIcXl9NwZ4UUNp2kB8XKhWWG/12is6Q9qY9cSSy4=; b=FDr5QG4Y6ChRHHCyoX+VMPWG62s5Jr9jQifTk4uG1aaY9EUuMtcxlElvtPKd6+KzmJ HoZ/1oDoE18QoIyfKMAaLLE/SVDfzHbJj1yWKc8hN6QpX7/mRJZb+NHDa1zt78GLi+yJ TaYRBiEMrkmWZLlQRIzjRRyPQPV6bmxlDwvebyLPAYYPN71gDtVbQQI9tvkGUKo9IDgL 1OIfrU3mzL4DjIj0r8FbiD7VY5pe1n23XaWJXW33Sk7zfmr9dH3T3tjpQUQpmq4K3yL2 MDL94iIw3LGpj3M4gLHVCo2rvdit3ShoiOHo4u9YzoVjavWa2gfSyuaSpQfftyIoIlrV tlMg== X-Gm-Message-State: APt69E1RPtxxnkxt37s+/qe0QxQcvyMPx/y0RhvvC5XQozIWDAW/BwyA d9bLq51OTJXahRxRYR4uP5c= X-Google-Smtp-Source: ADUXVKKDvbePr7xUi14EWm77KpYFgrvA4gu8kHXKKGsZNJmC9iSIT/rf1Fu3Kf8w5RuBZ3lvMTCBKw== X-Received: by 2002:a1c:328a:: with SMTP id y132-v6mr2391073wmy.70.1528993523154; Thu, 14 Jun 2018 09:25:23 -0700 (PDT) Received: from [192.168.1.17] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y8-v6sm8308214wrq.35.2018.06.14.09.25.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 09:25:22 -0700 (PDT) From: Yoav Nir Message-Id: <9A51739F-544F-4066-980A-6C8422500F14@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AA0392B3-81EF-43AE-ADD6-6236718EC7C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 14 Jun 2018 19:25:20 +0300 In-Reply-To: Cc: ipsec@ietf.org To: riyaz talikoti References: <683BEC43-A0E4-4AF2-8C0E-B36B852601D7@gmail.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [IPsec] INITIAL_CONTACT in IKEv1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 16:25:33 -0000 --Apple-Mail=_AA0392B3-81EF-43AE-ADD6-6236718EC7C1 Content-Type: multipart/alternative; boundary="Apple-Mail=_C494F88D-C339-4B38-B9E9-CA19E98F2177" --Apple-Mail=_C494F88D-C339-4B38-B9E9-CA19E98F2177 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think at a minimum we have to have the behavior well-defined rather = than open to interpretation. That IMO is the most important thing we got = in IKEv2. As long as some IKE SA exists between PEER-A and PEER-B, the peer that = does not have the IPsec SA can inform the other side with an INVALID_SPI = protected notification. But I agree it=E2=80=99s better to not get into = this situation by wiping out the IPsec SAs with the IKE SA. Like we do = in IKEv2. > On 14 Jun 2018, at 19:03, riyaz talikoti wrote: >=20 > Hi Yoav, > Thanks a lot for the response. > Just a quick question on top of what you wrote. >=20 > If a responder did not delete IPSec SA=E2=80=99s and only deletes IKE = SA when it receives IC. > Will it not result in blackhole? >=20 > Lets say > PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 = =E2=80=94 =E2=80=94 PEER-B > IKE SA(XX) IKE SA(XX) > IPSEC SA(SPI AA) IPSEC SA(SPI AA) >=20 > PEER-A starts initiating new session and starts AGGRESSIVE_MODE. > PEER-B receives IC and lets say PEER-B deletes ONLY IKE = SA(XX)(recommended by RFC), > But will NOT delete IPSEC SA(SPI AA)(as RFC does not mention anything = about it). >=20 > And AM and QM exchanges gets completed and new sets of SA=E2=80=99s = comes UP on both sides >=20 > Now > PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 = =E2=80=94 =E2=80=94 PEER-B > IKE SA(YY) IKE SA(YY) > IPSEC SA(SPI BB) IPSEC SA(SPI BB) > IPSEC SA(SPI AA) =E2=80=94= > NOT DELETED When IC is received. >=20 > For outgoing traffic from PEER-B, if SPI AA is chosen from SADB, will = it NOT get dropped at PEER-A with INVALID_SPI. > So does it not make sense to delete all IPSec SA=E2=80=99s when IC is = received. >=20 > Regards > Riyaz >=20 >=20 >=20 >> On 12-Jun-2018, at 10:34 PM, Yoav Nir > wrote: >>=20 >>=20 >>> On 12 Jun 2018, at 11:53, riyaz talikoti > wrote: >>>=20 >>> Hi All, >>> Need help with couple of questions related to INITIAL_CONTACT in = IKEv1 >>>=20 >>> 1. Is it NOT wrong to send INITIAL_CONTACT notification in QUICK = MODE? >>> Will it NOT end up in deleting the IKE SA(Phase 1 SA) which is being = created as part of just completed AGGRESSIVE MODE exchange? >>> If we receive INITIAL_CONTACT notification in QUICK MODE, as a = responder should we ignore the notification? >>>=20 >>> 2. On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make = sense to delete all IPSec SA's(Phase 2 SA's) which are part of that = particular IKE SA(Phase 1 SA) ? >>> Because the whole purpose is to inform responder to delete all = previous connection related to this identity as initiator is coming UP = freshly. >>>=20 >>=20 >> Hi, Riyaz >>=20 >> INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407. It does = not specify that this notification should only be sent in phase 1 = messages, although I agree that it makes little sense in the context of = QUICK MODE. >>=20 >> So the answer to #1 is that it is not wrong. >>=20 >> The meaning of this notification is that all IKE SAs except the one = being used or created in this negotiation is not known to the sender. = RFC 2407 unfortunately talks only of an =E2=80=9CSA=E2=80=9D without = specifying whether this is about an IKE SA or an IPsec SA. I think the = only sane interpretation is that this is about IKE SAs. So if an = AGGRESSIVE negotiation created an IKE SA and this IKE SA is used to = protect the QUICK MODE, that IKE SA is safe. If the AGGRESSIVE = negotiation was used to create a different IKE SA, then it will be = deleted. >>=20 >> You are always allowed to ignore an INITIAL_CONTACT notification. It = is meant to help you with state management. If you use some other IKE = SA created before you received the INITIAL_CONTACT, you are very likely = to get an error. >>=20 >> Regarding question #2: To clarify, on receiving INITIAL_CONTACT you = delete all the other IKE SAs, not the one used in the negotiation. >> The question of deleting the associated IPsec SAs when deleting an = IKE SA is, unfortunately, not answered in the IKEv1 RFCs. Most vendors = followed Cisco=E2=80=99s example and deleted them. A few didn=E2=80=99t. = In the case of INITIAL-CONTACT it makes even more sense than when an = IKE SA is explicitly deleted with a DELETE payload. >>=20 >> HTH >>=20 >> Yoav >>=20 >=20 --Apple-Mail=_C494F88D-C339-4B38-B9E9-CA19E98F2177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think at a minimum we have to have the behavior well-defined rather than = open to interpretation. That IMO is the most important thing we got in = IKEv2.

As long as = some IKE SA exists between PEER-A and PEER-B, the peer that does not = have the IPsec SA can inform the other side with an INVALID_SPI = protected notification. But I agree it=E2=80=99s better to not get into = this situation by wiping out the IPsec SAs with the IKE SA. Like we do = in IKEv2.

On 14 Jun 2018, at 19:03, riyaz talikoti = <riyazinbec@gmail.com> wrote:

Hi Yoav,
Thanks a lot for the response.
Just a quick question on top of what you = wrote. 

If = a responder did not delete IPSec SA=E2=80=99s and only deletes IKE SA = when it receives IC. 
Will it not result in = blackhole? 

Lets say 
PEER-A = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94 = =E2=80=94 PEER-B
IKE SA(XX) =          IKE SA(XX)
IPSEC SA(SPI AA)             =       IPSEC SA(SPI AA)

PEER-A starts initiating new session = and starts AGGRESSIVE_MODE. 
PEER-B receives = IC and lets say PEER-B deletes ONLY IKE SA(XX)(recommended by = RFC), 
But will NOT delete IPSEC SA(SPI AA)(as = RFC does not mention anything about it).

And AM and QM exchanges gets completed = and new sets of SA=E2=80=99s comes UP on both sides

Now 
PEER-A =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 =E2=80=94 =E2=80=94 PEER-B
IKE = SA(YY) =           IKE = SA(YY)
IPSEC SA(SPI BB)         =           IPSEC SA(SPI BB)
=   IPSEC SA(SPI AA) =E2=80=94&g= t; NOT DELETED When IC is received.

For outgoing traffic from PEER-B, if = SPI AA is chosen from SADB, will it NOT get dropped at PEER-A with = INVALID_SPI.
So does it not make sense to delete = all IPSec SA=E2=80=99s when IC is received.

Regards
Riyaz



On = 12-Jun-2018, at 10:34 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:


On 12 = Jun 2018, at 11:53, riyaz talikoti <riyazinbec@gmail.com> wrote:

Hi All,
Need help with couple of questions = related to INITIAL_CONTACT in IKEv1

1. Is it NOT wrong to send = INITIAL_CONTACT notification in QUICK MODE?
Will it NOT end up in deleting the IKE SA(Phase 1 SA) which = is being created as part of just completed AGGRESSIVE MODE = exchange?
If we receive INITIAL_CONTACT = notification in QUICK MODE, as a responder should we ignore the = notification?

2.= On receiving INITIAL_CONTACT we delete IKE SA. Doesn't it make sense to = delete all IPSec SA's(Phase 2 SA's) which are part of that particular = IKE SA(Phase 1 SA) ?
Because the whole purpose is = to inform responder to delete all previous connection related to this = identity as initiator is coming UP freshly.

Hi, Riyaz

INITIAL_CONTACT is defined in section 4.6.3.3 or RFC 2407. =  It does not specify that this notification should only be sent in = phase 1 messages, although I agree that it makes little sense in the = context of QUICK MODE.

So the answer to #1 is that it is not wrong. 

The meaning of this = notification is that all IKE SAs except the one being used or created in = this negotiation is not known to the sender. RFC 2407 unfortunately = talks only of an =E2=80=9CSA=E2=80=9D without specifying whether this is = about an IKE SA or an IPsec SA. I think the only sane interpretation is = that this is about IKE SAs. So if an AGGRESSIVE negotiation created an = IKE SA and this IKE SA is used to protect the QUICK MODE, that IKE SA is = safe. If the AGGRESSIVE negotiation was used to create a different IKE = SA, then it will be deleted.

You are always allowed to ignore an = INITIAL_CONTACT notification. It is meant to help you with state = management.  If you use some other IKE SA created before you = received the INITIAL_CONTACT, you are very likely to get an = error.

Regarding= question #2: To clarify, on receiving INITIAL_CONTACT you delete all the other IKE SAs, = not the one used in the negotiation.
The question = of deleting the associated IPsec SAs when deleting an IKE SA is, = unfortunately, not answered in the IKEv1 RFCs. Most vendors followed = Cisco=E2=80=99s example and deleted them. A few didn=E2=80=99t.  In = the case of INITIAL-CONTACT it makes even more sense than when an IKE SA = is explicitly deleted with a DELETE payload.

HTH

Yoav



= --Apple-Mail=_C494F88D-C339-4B38-B9E9-CA19E98F2177-- --Apple-Mail=_AA0392B3-81EF-43AE-ADD6-6236718EC7C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlsilvAACgkQuEkLFQpY zJl56Af8C/nelF2xyLfvI/MRJ+iuZ6uFKYih2g2XwsTVW6T0XROWeOUq0ocO+Jxj sUOFOYqKOOFty/N02RW/kHOadkwYNsG0SZXehMwL2RsHxODH1Wxq8PdRWdVWqoK3 LFF95I8OGMqxxYH5mTeksd/YMy/Ng3gH1I6eQM22Q47FkEKAEbrinnNOnNI7yn3D UytFrqBtHrRZx2p6rkQjmbI232W+sNWdTAdzUWi1nyxKDbJQKB4ApZ5qnE4bitME wdMyejr9NrozxrMOdovy1TQPr9vHnbY2bm+y6D6xeun+O0WvgsqokpCpEnTW+n5R taYuokbRW4ZRhuiSWU3aEzqNXOt9QQ== =D7P8 -----END PGP SIGNATURE----- --Apple-Mail=_AA0392B3-81EF-43AE-ADD6-6236718EC7C1-- From nobody Mon Jun 18 06:39:17 2018 Return-Path: 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 576D7130DE5 for ; Mon, 18 Jun 2018 06:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 eotEjjW_lgoK for ; Mon, 18 Jun 2018 06:39:13 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16161294D7 for ; Mon, 18 Jun 2018 06:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SmlDQB7rA57EGBr5rB95wQYEI74ox/R+NIvvYICa2mk=; b=G/HW8pcx4WeXXyJRow5kOfzWqBgMxbyy89UVl/TNXCU7EO1ds5Q9pmQoLGnqv1cTUEzrzzHO+CvY0u+0sds9Ut1TkOBxfAqP8fhawth8unKS2cKhZ18R6sFyBWjrWTi32wKxVpg42KbKJ1EkXqQ/rvS8EG6cVvJzTJaCkuSE3Ps= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2305.namprd09.prod.outlook.com (52.132.18.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.15; Mon, 18 Jun 2018 13:39:12 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::3c98:cfaf:a2bb:ec5a]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::3c98:cfaf:a2bb:ec5a%4]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 13:39:12 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-implicit-iv-04 Thread-Index: AdQHCOIZDeHfpv+0T/+/EAsCUK7hpQ== Date: Mon, 18 Jun 2018 13:39:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2305; 7:NnyhiSAGwLa57HBJNO6/5u95ixgUQhWymetF3DwWYT5tmvB5j10H8XKN9iRNRKN/eeE5eBnBMk+LjROaiXI/Svp6fZhNZ6WZtDgDIUGoydVMnVpKArfaaowxkyW6Jgtqg6IcPcTptnymCMBKc9mU/376eDldBMJk6IrRA+RLOQvTpX4d7ohUFknv/PrsOqq1i5w5mRpSa1h8Q0s0ixHluq/8XVZbNNrL8XD6JQB+1GncwMbyacLtND6Ydp8vpsRE x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ca007832-c60b-4ac8-e518-08d5d520e054 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR0901MB2305; x-ms-traffictypediagnostic: BL0PR0901MB2305: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BL0PR0901MB2305; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2305; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(39380400002)(366004)(346002)(376002)(199004)(189003)(74316002)(8936002)(99286004)(6116002)(6306002)(6436002)(55016002)(486006)(14454004)(102836004)(5250100002)(25786009)(476003)(6916009)(9686003)(106356001)(33656002)(7736002)(8676002)(53936002)(5660300001)(305945005)(3846002)(6506007)(2900100001)(81166006)(81156014)(316002)(7696005)(86362001)(26005)(186003)(478600001)(105586002)(68736007)(3660700001)(2906002)(3280700002)(97736004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2305; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: Csd/9CZBdnKAxAESiZSu1qp2QE99IXgKJw2ek2H3z8N+QlugE90ydtd4voArw29OpPmoNMHi2l5vRAQ/tQkD/2ctjuOD2N8P7FlkuYZpdpkAPL0EiWVk1Y7cYQ35vWQzClQBSNGt/VBoAn81xUnSXvrYtU8VVKhGr4m2w7nr0t/mR/o9QKFTMGQ8rTg/RF8/w66AZ9tttJ7TA1wVbftJlMACsghC7CsRDGKC1tt8QFNgQaA4CoBsgaD6XUtTfXyDE5A3208Ubgg61h6fl8kuZTiYyHYIYvRuqVgVHHPE/TSv4Mdu5QD4wcJ0tbgUvPeOTtEpdpxiIpEufWgSlkA3Kg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: ca007832-c60b-4ac8-e518-08d5d520e054 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 13:39:12.0716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2305 Archived-At: Subject: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 13:39:16 -0000 This message starts a working group last call (WGLC) on draft-ietf-ipsecme-= implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. Please r= eview and provide feedback on the -04 version (https://datatracker.ietf.org= /doc/draft-ietf-ipsecme-implicit-iv/). Please indicate if you believe this = draft is ready for publication or if you have comments that must be address= ed before the draft progresses. Regards, Dave From nobody Mon Jun 18 07:43:37 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA91C120049; Mon, 18 Jun 2018 07:43:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152933300976.3319.10351091430975348964@ietfa.amsl.com> Date: Mon, 18 Jun 2018 07:43:29 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:43:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-03.txt Pages : 18 Date : 2018-06-18 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 18 09:01:37 2018 Return-Path: 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 175C9130E01 for ; Mon, 18 Jun 2018 09:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 N2nXfrz4W-tg for ; Mon, 18 Jun 2018 09:01:20 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0115.outbound.protection.outlook.com [23.103.200.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B017F130DF9 for ; Mon, 18 Jun 2018 09:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n0t4jGYm4HQUFqQv2Q5nGD8qnRL+i/e0jzvRvsTnWRo=; b=PKBWwLJ9U6HWl+oNuRu8zGen5cG5tYgxLZU/7j2LbllYOvg6eOOqJku6axv0Qfcxx8xzYNL1L05A7TTU2w0ABidEy83P0yGEIZI7Mk+m+NP4+Pm4Li5SwX730ZU5yYhIR2c3/h+6D6g/2Sub0EvtKW/McOA23CxfSQpOBZjm+1Q= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2305.namprd09.prod.outlook.com (52.132.18.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.15; Mon, 18 Jun 2018 16:00:55 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::3c98:cfaf:a2bb:ec5a]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::3c98:cfaf:a2bb:ec5a%4]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 16:00:55 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-implicit-iv-04 Thread-Index: AdQHCOIZDeHfpv+0T/+/EAsCUK7hpQAFHLIQ Date: Mon, 18 Jun 2018 16:00:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2305; 7:boTiYWmg/2L3UK9bQSwvgJm9d8o4rh17g0ftYjE8nPkj+m3T1pp+ZxA3mIhSnRW+nHJTLP8CuySkb6qjydEt8uyyBLcyUNn3Xtqg3lxYmkD/9FhDpmA8jN9/Dz/IANcTkrfF/yeDE5lU6CUExEES3QtcxTb974nl/Tbr7WkiLLEzOeJEDyr7eAoRwNeC+s46DIX6itG+Gn0Ik9TftxS6uGy64zvhRHqeIZ0jrXAKBOVYhmM6Hno+om7wiTQoW+AG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 31173e16-8d51-4ec5-9efe-08d5d534acd4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR0901MB2305; x-ms-traffictypediagnostic: BL0PR0901MB2305: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BL0PR0901MB2305; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2305; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(366004)(396003)(39850400004)(13464003)(199004)(189003)(86362001)(186003)(478600001)(316002)(81166006)(81156014)(59450400001)(26005)(7696005)(6246003)(446003)(97736004)(66066001)(3280700002)(105586002)(2940100002)(2906002)(3660700001)(68736007)(76176011)(14454004)(229853002)(53546011)(5250100002)(102836004)(99286004)(8936002)(74316002)(55016002)(486006)(6116002)(6306002)(6436002)(53936002)(7736002)(8676002)(6506007)(2900100001)(305945005)(5660300001)(3846002)(6916009)(9686003)(476003)(25786009)(106356001)(33656002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2305; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1Kv+NSM+PQtKg49bzM6WtdoevQKv8Il3bXRHLfzbJEwYnhQ+UgS7ZfkvLNnXlaC04ugEKgJ72MEsUbRfKLRRG27Joqtcx0kd7ysEBJwSLWs9IfTgRaB+kpaoZj+YOKY92Au+7c8BrcnmEmcmPezo0W157yxUYt+o5ftiO2M7zrjqpkksHDW2A9rRpIWohLg1K2JyJsPomNfQijB32j7DjrobxN69mH0q/tdX0Gw+4q6mSI+e6G60NPs0cdLdPSQTb9q/iwFlaDj9mZB4DSaRdJVcC24G0imxRn8CGlJ+eB6DwpXYnyCg/A5zSLqbedkNPOWLBaADxREmGZ74Rau5Fg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 31173e16-8d51-4ec5-9efe-08d5d534acd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 16:00:55.7111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2305 Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:01:29 -0000 Please note, this is a follow-up to the previous WGLC. This is to confirm W= G consensus on the draft before sending it forward to the IESG. Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Monday, June 18, 2018 9:39 AM > To: IPsecME WG > Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04 >=20 > This message starts a working group last call (WGLC) on draft-ietf-ipsecm= e- > implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. Please= review > and provide feedback on the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). Pleas= e indicate > if you believe this draft is ready for publication or if you have comment= s that > must be addressed before the draft progresses. >=20 > Regards, > Dave From nobody Mon Jun 18 09:18:04 2018 Return-Path: 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 8531C130DE0 for ; Mon, 18 Jun 2018 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2ZYy3UIGy5iX for ; Mon, 18 Jun 2018 09:18:01 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 AA6DC130DDF for ; Mon, 18 Jun 2018 09:18:00 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id y20-v6so25594202lfy.0 for ; Mon, 18 Jun 2018 09:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IAI8R6ft+jZEoNkjdxmY961hS9iNU/aSWR8PC1Q9u0I=; b=bWBh2cKR2szOebQqE+H4vxst07uxRngRGhabDufndLzeaGBVdudvQK4NftAq1S3cFZ XRrcKqtOl2l+d8JRMl/XYkdvdRIo+s2K0BKBRfbRoo3WKxyboKghshWHzWNbYnyybxxs +qKiVo3hFESAOI6I8xH/wFUDRYuBlrcgeDO6TJ+gOcpf9GWilqpWpEzZVNqLNLTxogXa cdvvxwHLvwZWfshUhrzEWBqXFbw2aHazB3KsNR9UlP+RXyajzCaJvThBPxTwQEZayMuf X3kpf1HnAA6OvEn+9OAijdxZvX6CJ18g6kopO8CugGqigA+N6jsWLmLv3veTh8xks5aq 5i7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IAI8R6ft+jZEoNkjdxmY961hS9iNU/aSWR8PC1Q9u0I=; b=O3nCpfs3jN7BzQoy+w8bgBxmm2ut+E0H8opHfl717NlJAuIAPkh7tX0/eLtE+YqGk8 r9rT1mYFR+J0en6A+rtpPvBL4QRkCqEv0vW0S6su97S8Sd3vFRQgBDw6IJErYGpyLrYD v5u/QIdxI4YGWIPibphqlPYw11GxVYQ1ya/76QJZ2iqABsuD4ymDPZ2/ypKOd0rEk5vC L1/TsS+eGRG7Z5z0kaQobCkF+8xQfZc8C3fMgpn5fddr0n7NYTecch/QI98h0CJnSZ8/ QpWmi6NpLutLv3ElNGsUMPE/G2JAnHJku7SCERPhfOYG2AGmjRsUf2TjNEkUyn57gIcO pF9A== X-Gm-Message-State: APt69E2zg53u3pxVWyucOehn7h0KhexYwA1Vsv+qI37+cpJjHvMa/avA lmLbGuuGZjgaUtDJ1MwDIiCdXz0lCITomUF8Xr8= X-Google-Smtp-Source: ADUXVKLWtcST532IkPIFRsgtrkN7KDGLxi/iAI/nYNr22RRLeMoF0CTNNgQvxgpPs6DVNsHtZOgx8vwWLS+lK5AN8hA= X-Received: by 2002:a19:184e:: with SMTP id o75-v6mr6946732lfi.118.1529338679010; Mon, 18 Jun 2018 09:17:59 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:97d1:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 09:17:58 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Mon, 18 Jun 2018 12:17:58 -0400 X-Google-Sender-Auth: UMM8kVxTs1t_hnDBuvY03xVmma4 Message-ID: To: "Waltermire, David A. (Fed)" Cc: IPsecME WG Content-Type: multipart/alternative; boundary="000000000000b42e10056eece8ef" Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:18:03 -0000 --000000000000b42e10056eece8ef Content-Type: text/plain; charset="UTF-8" as a co-author, I believe that all comments received so far have been addressed and the resulting document is in good shape for the IESG. Yours, Daniel On Mon, Jun 18, 2018 at 12:00 PM, Waltermire, David A. (Fed) < david.waltermire@nist.gov> wrote: > Please note, this is a follow-up to the previous WGLC. This is to confirm > WG consensus on the draft before sending it forward to the IESG. > > Thanks, > Dave > > > -----Original Message----- > > From: Waltermire, David A. (Fed) > > Sent: Monday, June 18, 2018 9:39 AM > > To: IPsecME WG > > Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04 > > > > This message starts a working group last call (WGLC) on > draft-ietf-ipsecme- > > implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. > Please review > > and provide feedback on the -04 version > > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). > Please indicate > > if you believe this draft is ready for publication or if you have > comments that > > must be addressed before the draft progresses. > > > > Regards, > > Dave > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000b42e10056eece8ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
as a co-author, I believe that all comments received = so far have been addressed and the resulting document is in good shape for = the IESG.

Yours,
Daniel

On Mon, = Jun 18, 2018 at 12:00 PM, Waltermire, David A. (Fed) <= david.walter= mire@nist.gov> wrote:
Pleas= e note, this is a follow-up to the previous WGLC. This is to confirm WG con= sensus on the draft before sending it forward to the IESG.

Thanks,
Dave

> -----Original Message-----
> From: Waltermire, David A. (Fed)
> Sent: Monday, June 18, 2018 9:39 AM
> To: IPsecME WG <ipsec@ietf.org>
> Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04
>
> This message starts a working group last call (WGLC) on draft-ietf-ips= ecme-
> implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. Ple= ase review
> and provide feedback on the -04 version
> (https://datatracker.ietf.org/<= wbr>doc/draft-ietf-ipsecme-implicit-iv/). Please indicate
> if you believe this draft is ready for publication or if you have comm= ents that
> must be addressed before the draft progresses.
>
> Regards,
> Dave

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--000000000000b42e10056eece8ef-- From nobody Mon Jun 18 09:49:06 2018 Return-Path: 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 48D0B130DCD for ; Mon, 18 Jun 2018 09:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mi5EvHYlci4j for ; Mon, 18 Jun 2018 09:49:03 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB43E130DDA for ; Mon, 18 Jun 2018 09:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529340542; x=2393254142; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FFPHZ/WUp+Ioaxueq/h0Y7BxvgrHQQiPj1qS0EJs9ig=; b=tUBKpK6BFEimjaJoXqnPOHPjgqnHGU71lPZ7RDQQOWlqzJCc54/lSisBXYZgf1Fp vuQjobvoCsm2TLdqfdP6sanajtL/YyEs5XChLaUfPIrVAuEv1A+1WUNLhVm3HI8I RYmTcJjJhi7WFBBJKalB1UKuqY2ABlX54EiXp5oWlAx80x/qpIEiRk1MdzrrJHYU nU1QqQyN7+tNB5hsRzMGS14p8dQX4jA1rLWsyot/Bf3ZE/rjmuxdk7UA6oarMfVT ZLIWU2CnT0g+Odjt25UFEg8Y2JBv2Zmstl104lB+lkMu3S9Kyy7VwYCmogWEW5/T CJTQoFGu8+AIONr6FG9bug==; X-AuditID: 11973e16-6d9ff7000000740c-35-5b27e27e2146 Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 28.CE.29708.E72E72B5; Mon, 18 Jun 2018 09:49:02 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pPaIUVWTnww9AcUScgEf7g)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PAJ009DJ2PP48E0@ma1-mtap-s02.corp.apple.com>; Mon, 18 Jun 2018 09:49:01 -0700 (PDT) Received: from [17.234.1.1] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAJ00BYF2PKHA00@nwk-mmpp-sz10.apple.com>; Mon, 18 Jun 2018 09:49:00 -0700 (PDT) X-Va-A: X-Va-T-CD: 56b3185ae703ea15d0b702e7c2396bf2 X-Va-E-CD: e580a0fc7bdcd93266f30ba6a4588526 X-Va-R-CD: c8d028932563255214d8e7d1debc824b X-Va-CD: 0 X-Va-ID: d51e21e9-8e5b-4ee6-ad7a-a7851ddc25a8 X-V-A: X-V-T-CD: a1cb37c879f25cdb3a488d10cd2bbb3c X-V-E-CD: e580a0fc7bdcd93266f30ba6a4588526 X-V-R-CD: c8d028932563255214d8e7d1debc824b X-V-CD: 0 X-V-ID: c5b42c65-e27b-4c73-85ad-0e142936a313 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-18_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Sender: dschinazi@apple.com From: David Schinazi Message-id: <888FDA82-180D-4656-B097-6643893A3DB0@apple.com> Date: Mon, 18 Jun 2018 09:48:55 -0700 In-reply-to: Cc: "Waltermire, David A. (Fed)" , IPsecME WG To: Daniel Migault References: X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUiqOHDplv3SD3aoOuuusWU6XvYLDb2/GOz 2L/lBZsDs8evr1fZPJYs+cnkce3kX9YA5igum5TUnMyy1CJ9uwSujOW/LzEX/NGveHt/BnsD 40PNLkZODgkBE4ldu08zdjFycQgJ7GOS6G+6yQqS4BUQlPgx+R4LiM0sECbR1bOEHaJoI5NE 3+r7bBDOJ0aJd6cOs0CMYpf482sHlK0t8Xb/JTYYe+eqSewwduu5yVA1XBILtp5mhbB1JX7c W8YIYbNJrD+xhAnC1pL4234Ezv7xbwsjjH3v8QKoXk6J818mQs3Xkfh05DvU/GyJqytfAN3A AWQHS+x/qwwSFhaQlui6cJcVJMwGNObAGiOIf20kll3dygxRYiexat08sOksAqoSB47dAItz Ak3pffCPGRIm0RKH+r6C1YgIGEi8nLATGiQNTBL7TsyAel1JYvr322wTGOVmIYXpLKQwhbC1 JL4/agWKcwDZ8hIHz8tChDUlnt37BFWiLfHk3QXWBYxsqxiFchMzc3Qz88z1EgsKclL1kvNz NzGCksd0O7EdjA9XWR1iFOBgVOLhbdioHi3EmlhWXJl7iFGag0VJnPfpHaCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxvqW8PJ8++a9pWn2ttqNd06vZe4pX9TamyE3xVDPPFP3UeZTxrCi 5xeFtTlfPVH7u+/Umsd6tx7ysuy7/qP/XoRE18/7K7RPLr0dGOmSI8pmd9JyfmLkzEDF9eW/ V/4z2P5C2SpIYsomk2zJEFfFdR1JCxbMt2w67dnZYK3+edvEAi8D+9h7SizFGYmGWsxFxYkA WUn8gv8CAAA= Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:49:06 -0000 --Boundary_(ID_pPaIUVWTnww9AcUScgEf7g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, I have read and reviewed the last few revisions of the draft and I believe it is ready for publication. I also implemented Implicit IV for ChaCha20-Poly1305 and it was pretty straightforward. Thanks, David Schinazi > On Jun 18, 2018, at 09:17, Daniel Migault wrote: > > as a co-author, I believe that all comments received so far have been addressed and the resulting document is in good shape for the IESG. > > Yours, > Daniel > > On Mon, Jun 18, 2018 at 12:00 PM, Waltermire, David A. (Fed) > wrote: > Please note, this is a follow-up to the previous WGLC. This is to confirm WG consensus on the draft before sending it forward to the IESG. > > Thanks, > Dave > > > -----Original Message----- > > From: Waltermire, David A. (Fed) > > Sent: Monday, June 18, 2018 9:39 AM > > To: IPsecME WG > > > Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04 > > > > This message starts a working group last call (WGLC) on draft-ietf-ipsecme- > > implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. Please review > > and provide feedback on the -04 version > > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ ). Please indicate > > if you believe this draft is ready for publication or if you have comments that > > must be addressed before the draft progresses. > > > > Regards, > > Dave > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_pPaIUVWTnww9AcUScgEf7g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi,

I = have read and reviewed the last few revisions of the draft and I believe = it is ready for publication.
I also implemented = Implicit IV for ChaCha20-Poly1305 and it was pretty = straightforward.

Thanks,
David Schinazi


On Jun 18, 2018, at 09:17, Daniel Migault = <daniel.migault@ericsson.com> wrote:

as a co-author, I believe that all comments = received so far have been addressed and the resulting document is in = good shape for the IESG.

Yours,
Daniel
On Mon, Jun 18, 2018 at 12:00 PM, = Waltermire, David A. (Fed) <david.waltermire@nist.gov> wrote:
Please note, this is a = follow-up to the previous WGLC. This is to confirm WG consensus on the = draft before sending it forward to the IESG.

Thanks,
Dave

> -----Original Message-----
> From: Waltermire, David A. (Fed)
> Sent: Monday, June 18, 2018 9:39 AM
> To: IPsecME WG <ipsec@ietf.org>
> Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04 >
> This message starts a working group last call (WGLC) on = draft-ietf-ipsecme-
> implicit-iv-04, which will conclude on June 29, 2018 at UTC 23:59. = Please review
> and provide feedback on the -04 version
> (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). = Please indicate
> if you believe this draft is ready for publication or if you have = comments that
> must be addressed before the draft progresses.
>
> Regards,
> Dave

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_pPaIUVWTnww9AcUScgEf7g)-- From nobody Mon Jun 18 13:35:37 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68456130E42; Mon, 18 Jun 2018 13:35:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152935413537.2922.1950626583854164930@ietfa.amsl.com> Date: Mon, 18 Jun 2018 13:35:35 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 20:35:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-08.txt Pages : 13 Date : 2018-06-18 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-08 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 19 08:45:22 2018 Return-Path: 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 DCB87130F56 for ; Tue, 19 Jun 2018 08:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] autolearn=ham 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 PNvh-zQk6Hhm for ; Tue, 19 Jun 2018 08:45:17 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 DD7DC130DC0 for ; Tue, 19 Jun 2018 08:45:16 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id d19-v6so164257oti.8 for ; Tue, 19 Jun 2018 08:45:16 -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=kZ1RxOebE2HbQkvbqUVrm+0Hk6SlnSWClRdABfs58NE=; b=fZ+qDYQs3QwSlx+NKQf5WDVGtd16XHfe58A3XXiER+OHIo4hiVa2DsJTEim0erWU+J uVohF+5MIpNjdjm4c41LiI594RSQ+4eOjEYyeOsYV0hcBePqFXyvE1VMFZkdhKmRHhtp 0wK5eSSp8W/gybUJC3RD7Jj6kBVHHZX1i4ROt6LSuvzFtqghZFHI7KDa8tL7P5sHjK7h VI9VBYgvXud4Nnq2Lnsl89sbnuymCUTNeH38fVBNYl3D9Ku3oWgwwJu5oqOv9Dpo9Ghl Khumhsgo5cnZPGEUZ5dRPjY2wT+jJP8kkptPdILnX6aEDxyDqCvUtICsLodkXMjIXzjv Al6g== 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=kZ1RxOebE2HbQkvbqUVrm+0Hk6SlnSWClRdABfs58NE=; b=sG0brMbb1d1DNnX6MpgP29Ni0QakRZmjy4briSI0b2WICXTomOrmFx5NnUxlwoPTjm JV9IXgHJIy4CI8V31mQkFlysHFe8Muwiz9VL8wI1FaX9egTUBR3rWahoKEtBVtlKBS2f VMcGFwpQvKIlpWsS6F6o+k3EAvCy1nY35RE3yWnFG4syCJF1ffX7PV5QXDFcg5qvhuYf lcRLBNlD9Fbd6v/v97ZBS+IbCwnpALj/Jq92LAj+PfVZCoe0RtNxF6fnZV85+tIpcT8s VPFnLa1MKkhkpmQ/1lRmTqKD5KkE0xk/LIMmnKGr6zGvytxqT+kpnceKcHgRyp9kJL71 b1HQ== X-Gm-Message-State: APt69E1A14HUJdYClxmatALovVxYghEuPwJj2kiOU9p8SO4sals8gVlA DkXbESengWyx3gNsSO5DNAfGCc+sgGyPFKUVbpyf0Q== X-Google-Smtp-Source: ADUXVKJ4DCPFGJ2kHrbfwk+X0GkUt/1X0C7ez+W3qkHIWqW2iqNKR6O/32bwpouBZL3ZXk7XWILrx4unQe2i4CYKFls= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr11477215otb.371.1529423116164; Tue, 19 Jun 2018 08:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:44:35 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 19 Jun 2018 08:44:35 -0700 Message-ID: To: Paul Wouters , IPsecME WG Cc: "Waltermire, David A. (Fed)" , Tero Kivinen , "draft-ietf-ipsecme-split-dns.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008cf42a056f0091df" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:45:20 -0000 --0000000000008cf42a056f0091df Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters wrote: > On Mon, 18 Jun 2018, Eric Rescorla wrote: > > Right but the problem is that accepting the TA for a given domain allows >> the IPsec endpoint to act as a TLS endpoint for that domain >> (assuming that the TLS client supports DANE). >> > > Yes. You are the Enterprise customer. It's a feature. Not all enterprises who use VPNs want to run a MITM proxy. The basic problem here is that the security properties of DNS are radically different from those of the WebPKI (which is why we routinely rely on HTTPS in cases where DNS is untrustworthy). So, it's totally unexpected that allowing the VPN operator to inject a new DNS trust anchor would allow them to attack HTTPS connections. The problem with this design is that it ties those properties together. This is a problem for the users but also for the enterprise because it takes something which might have been offline signed and makes it online. Client > implementations can limit these domains, eg using VPN profiles > that the user has to agree to. There is not much more we can do > at the protocol leven, than say the two things we already say: > > 1) If not split-view, do not accept any DNS trust anchors > > This prevents third party VPN providers from injecting rogue trust > anchors. Note that in this case you already _are_ giving all your > traffic including DNS to the VPN server. (but hey, we have DOH) > > 2) Don't accept trust anchors for anything not specifically > split-redirected into the VPN infrastructure > > So in my redhat case, I would either allow "redhat.com" or > "internal.redhat.com" to be redirected through my VPN profile > and not anything else. (well, actually some reverse zone parts too) > There are actually a number of oither things you could do: - Totally forbid the use of TLSA signed by non-default trust anchors - Make the use of TLSA signed by non-default trust anchors a separate protocol option with those trust anchors defined separately. I imagine there are other choices. > Yes, but it's not clear to me that clients can adequately determine which >> domains >> are internal -- they just get that information with some VPN config they >> got >> from their VPN provider. The text in the document says as much: >> > > Yes. And that is the same DNS problem in general when connecting to a > network and running your own recursive server. You usually get only one > domain via DHCP, but universities tend to have dozens, and they demand > you give them all your DNS queries so they can screw with internal only > domains for you on the fly. You just have to drop DNSSEC to let them do > that. That is a situation that needs fixing, and at least if you connec > to those networks using a VPN, this document is that fix. It allows the > network to send more than one DNS domain, and let's the client decide > whether or not to accept it. Where yes, most clients will do this based > on trusting their administrator of the VPN they are connecting to. Others > could have VPN software that lets them (de)select the ones they would > not accept. > Trust isn't a monolithic thing. It's one thing to trust the administrator to route your packets and quite another to trust them to MITM TLS. Again, this is why it's mostly safe to use HTTPS on networks owned by other people. Note that without this document, the only way for VPN clients to get > functional DNS beyond the 1 hardcoded domain, is to give the VPN all > your DNS queries, which allows even more manipulation (especially with > an installed Enterprise CA cert, now they can override gmail.com) > I'm not saying this document is bad. I'm saying it should exclude TLSA. > So it seems to me that the likely consequence of this function is that a >> lot of >> clients will be accepting what amounts to MITM certificates (again, >> assuming >> that they support DANE) as part of their VPN config. >> > > Not doing this makes the situation even worse. Do you have a proposal > that would make it better? I cannot think of one. > Why does it make the situation worse? Again, what's the use case why it's needed to have the VPN install a new WebPKI trust anchor. > > Also, part of your concerns could be mitigated by CT as well for the > TLS cases. I assume if browsers require CT, that internal-only domains > also need to get some kind of CT logging (redacted or not) and that > would also prevent a rogue gmail.com TLSA from being accidentally > accepted by the user at the IKE/VPN first as 'internal domain' and > then additionally at the TLS/TLSA layer? > Well, the semantics of CT+DANE are totally undefined, but generally, no, I wouldn't expect things that were TLSA-authorized to be CTed. If anything, I would expect them to use some sort of CT-for-DNS, but of course that doesn't exist. And of course, with raw public keys that's not even possible. Paul > ps. I'd really prefer this discussion to be in public on the list. > Please do any replies to this to the ipsecme list. You have my > permission to quote anything I wrote in this offlist mail thread. > Sure. We really need aliases that do the right thing here. -Ekr --0000000000008cf42a056f0091df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 18 Ju= n 2018, Eric Rescorla wrote:

Right but the problem is that accepting the TA for a given domain allows the IPsec endpoint to act as a TLS endpoint for that domain
(assuming that the TLS client supports DANE).

 Yes. You are the Enterprise customer. It's a feature.
=
Not all enterprises who use VPNs want to run a MITM proxy.

The basic problem here is that the security propert= ies of DNS are
radically different from those of the WebPKI (whic= h is why we
routinely rely on HTTPS in cases where DNS is untrust= worthy).
So, it's totally unexpected that allowing the VPN op= erator to
inject a new DNS trust anchor would allow them to attac= k HTTPS
connections. The problem with this design is that it ties= those
properties together. This is a problem for the users but a= lso for
the enterprise because it takes something which might hav= e
been offline signed and makes it online.


Client
implementations can limit these domains, eg using VPN profiles
that the user has to agree to. There is not much more we can do
at the protocol leven, than say the two things we already say:



1) If not split-view, do not accept any DNS trust anchors

This prevents third party VPN providers from injecting rogue trust
anchors. Note that in this case you already _are_ giving all your
traffic including DNS to the VPN server. (but hey, we have DOH)

2) Don't accept trust anchors for anything not specifically
=C2=A0 =C2=A0split-redirected into the VPN infrastructure

So in my redhat case, I would either allow "redhat.com" or
"internal.redhat.com" to be redirected through my VPN profil= e
and not anything else. (well, actually some reverse zone parts too)

There are actuall= y a number of oither things you could do:

- Totall= y forbid the use of TLSA signed by non-default trust anchors
- Ma= ke the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.

I imagine there are other choices.

= =C2=A0
Yes, but it's not clear to me that clients can adequately determine whi= ch domains
are internal -- they just get that information with some VPN config they go= t
from their VPN provider. The text in the document says as much:

 Yes. And that is the same DNS problem in general when connecting to a
network and running your own recursive server. You usually get only one
domain via DHCP, but universities tend to have dozens, and they demand
you give them all your DNS queries so they can screw with internal only
domains for you on the fly. You just have to drop DNSSEC to let them do
that. That is a situation that needs fixing, and at least if you connec
to those networks using a VPN, this document is that fix. It allows the
network to send more than one DNS domain, and let's the client decide whether or not to accept it. Where yes, most clients will do this based
on trusting their administrator of the VPN they are connecting to. Others could have VPN software that lets them (de)select the ones they would
not accept.

Trust isn't a monolithi= c thing. It's one thing to trust the administrator to route
y= our packets and quite another to trust them to MITM TLS. Again, this is
why it's mostly safe to use HTTPS on networks owned by other peo= ple.


Note that without this document, the only way for VPN clients to get
functional DNS beyond the 1 hardcoded domain, is to give the VPN all
your DNS queries, which allows even more manipulation (especially with
an installed Enterprise CA cert, now they can override gmail.com)

I'm not saying this docum= ent is bad. I'm saying it should exclude TLSA.


So it seems to me that the likely consequence of this function is that a lo= t of
clients will be accepting what amounts to MITM certificates (again, assumin= g
that they support DANE) as part of their VPN config.

 Not doing this makes the situation even worse. Do you have a proposal
that would make it better? I cannot think of one.

=
Why does it make the situation worse? Again, what's the use = case why
it's needed to have the VPN install a new WebPKI tru= st anchor.
=C2=A0

Also, part of your concerns could be mitigated by CT as well for the
TLS cases. I assume if browsers require CT, that internal-only domains
also need to get some kind of CT logging (redacted or not) and that
would also prevent a rogue gmail.com TLSA from being accidentally
accepted by the user at the IKE/VPN first as 'internal domain' and<= br> then additionally at the TLS/TLSA layer?

Well, the s= emantics of CT+DANE are totally undefined, but generally,
no, I w= ouldn't expect things that were TLSA-authorized to be CTed.
I= f anything, I would expect them to use some sort of CT-for-DNS, but
of course that doesn't exist. And of course, with raw public keys
that's not even possible.


Paul
 ps. I'd really prefer this discussion to be in public on the list.
Please do any replies to this to the ipsecme list. You have my
permission to quote anything I wrote in this offlist mail thread.

Sure. We really need aliases that do the right t= hing here.

-Ekr


=
--0000000000008cf42a056f0091df-- From nobody Tue Jun 19 08:55:09 2018 Return-Path: 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 971A5130DEC for ; Tue, 19 Jun 2018 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] autolearn=ham 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 KMGtH8UJyVsV for ; Tue, 19 Jun 2018 08:55:04 -0700 (PDT) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 9552612777C for ; Tue, 19 Jun 2018 08:55:04 -0700 (PDT) Received: by mail-ot0-x242.google.com with SMTP id p95-v6so216979ota.5 for ; Tue, 19 Jun 2018 08:55:04 -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=9arIVTA0nc+nGUHy9fO5czNVc36EF7uoaXlfeml5dJk=; b=cJNlqN9SauU+86/YoVZ1qSQeyWLDlBFtZBA4pgyICMGVsQVy/+2RlolIkdcZeJcPIK UWIhewNpQyqctthzlHfZwaO5fR0Q5/S8HA6hemmCsrx3vopDaKg7cySc99NerEfkgRnX LFqq+A7ANX4+rCyrc+W1hv4zE1QPnSM/XyTl/cqJuUGKWxwYZKEngBsMNtgAMAhJTKif maswqywW8UUh5dNrDfKr9ugaP8909FQPb0zzElSS5M5skO+BI0a6T45Bk/LaG2YzYbTZ UVTg2Fvng5FXCCRMjE1zjr4VN8FqnU9eDLuDwPM5QqzSSY8LYzyslYoK0lTKSqjRfZHZ kWbA== 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=9arIVTA0nc+nGUHy9fO5czNVc36EF7uoaXlfeml5dJk=; b=DcIQfgMTRVlaYkW3NdfqCrWzW0ljLwVnGUtwbnSuQwTNi1/1cuxFOIu76ZHrC4m0tf akjZZb9XnuY963VSAwHisGedXLBvhfkysoX5xnz1CTRj5LSR5p+x+G+SgXYIUMDA+VGH TD9v9uWQHPys2wr40r/9sCiIIwu/HF2oOwT06jC/1oI4Q/GV8A28BXvvyNnRfD9KCPcy xwi/JVxtNaQn6L6jjd9Fs38aEW6T9yvj+bQSYOyVPtixlJv+yAFYiPV/NPgU9v8Q/Mp3 XKGFJhXovLvQLb5wMO89GyRmRx/jS9krxVBBu88toH0kfJkDtcz+4b7B9QC+MJMql7ml 7wyg== X-Gm-Message-State: APt69E0sIIyBKFaWJVGF1rrk6gF3Dl5Pr/Nqcct7EmcTjbvZofL7t5AN R0lBC6/hogHtfOmRsk2rISB5rHLbvm9hj+VIMy0b5w== X-Google-Smtp-Source: ADUXVKLBee4IbBFA48lF3rDInbiA8kgrWvDpo/N63bL2JYmzO+rm6FqPyQlOYssCwYtDyVgh9zUCZr9TvlLB4gED23M= X-Received: by 2002:a9d:2f2a:: with SMTP id h39-v6mr10093934otb.214.1529423703919; Tue, 19 Jun 2018 08:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:54:23 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 19 Jun 2018 08:54:23 -0700 Message-ID: To: Paul Wouters , IPsecME WG Cc: "Waltermire, David A. (Fed)" , Tero Kivinen , "draft-ietf-ipsecme-split-dns.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095609c056f00b4c8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:55:09 -0000 --00000000000095609c056f00b4c8 Content-Type: text/plain; charset="UTF-8" For reference, here is my original review. Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3046 The security considerations seem to omit a fairly serious potential attack. Consider the case in which the client supplies this payload and the server provides resolvers and DNSSEC anchors for some domain it does not actually control, such as www.example.com. It then provides a bogus IP address (of its own) and a TLSA(2) or TLSA(3) record asserting its own key pair. In this case, if the client supports DANE, then you have at least potentially circumvented the PKI. This is far more serious than a bogus IP. The most likely defense against this is for the client to filter the domains for which it accepts anchor overrides. However, even if you do that, this still introduces a weakness: if you are using straight DNSSEC, then signing can be offline, but because the TA is not signed by an offline key, compromise of the VPN endpoint means that you can forge DNSSEC records. COMMENTS > > 2. Background > > Split DNS is a common configuration for enterprise VPN deployments, > in which only one or a few private DNS domains are accessible and > resolvable via an IPsec based VPN connection. I see the "only" binding to one, but isn't also generally the case that they are only accessible via the VPN connection. > o Digest Type (0 or 1 octet) - DS algorithm value from the IANA > Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms > Registry. > > o Digest Data (0 or more octets) - The DNSKEY digest as specified in > [RFC4034] Section 5.1 in presentation format. I'm having a little trouble reading this. Is the reason these would be 0 because you are using the empty format? > o Digest Data (0 or more octets) - The DNSKEY digest as specified in > [RFC4034] Section 5.1 in presentation format. > > 5. Split DNS Usage Guidelines > > If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes, The rules in this section are kind of hard to follow. I'm not sure what the best way to restructure them are, but perhaps: (1) If the domain list is empty, you can use the internal servers for anything (2) If the list is non-empty, you MUST use the internal servers for any entries not prohibited by local policy, including total limits , and should accept 1918 addresses fore those domains and SHOULD NOT use the internal servers for anything else. - > servers. > > If the initiator host is configured to block DNS answers containing > IP addresses from special IP address ranges such as those of > [RFC1918], the initiator SHOULD allow the DNS domains listed in the > INTERNAL_DNS_DOMAIN attributes to contain those Special IP addresses. I would rewrite this with the SHOULD first,, i..e, "SHOULD allow, even if" because you want this SHOULD to apply even if you aren't configured this way. > no guarantee of being answered. For example, if the > INTERNAL_DNS_DOMAIN attribute specifies "example.com", then > "example.com", "www.example.com" and "mail.eng.example.com" MUST be > resolved using the internal DNS resolver(s), but "anotherexample.com" > and "ample.com" SHOULD NOT be resolved using the internal resolver > and SHOULD use the system's external DNS resolver(s). This paragraph seems to to some extent duplicate the paragraph starting with "For each INTERNAL_DNS_DOMAIN..." On Tue, Jun 19, 2018 at 8:44 AM, Eric Rescorla wrote: > > > On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters wrote: > >> On Mon, 18 Jun 2018, Eric Rescorla wrote: >> >> Right but the problem is that accepting the TA for a given domain allows >>> the IPsec endpoint to act as a TLS endpoint for that domain >>> (assuming that the TLS client supports DANE). >>> >> >> Yes. You are the Enterprise customer. It's a feature. > > > Not all enterprises who use VPNs want to run a MITM proxy. > > The basic problem here is that the security properties of DNS are > radically different from those of the WebPKI (which is why we > routinely rely on HTTPS in cases where DNS is untrustworthy). > So, it's totally unexpected that allowing the VPN operator to > inject a new DNS trust anchor would allow them to attack HTTPS > connections. The problem with this design is that it ties those > properties together. This is a problem for the users but also for > the enterprise because it takes something which might have > been offline signed and makes it online. > > > Client >> implementations can limit these domains, eg using VPN profiles >> that the user has to agree to. There is not much more we can do >> at the protocol leven, than say the two things we already say: >> > > > >> 1) If not split-view, do not accept any DNS trust anchors >> >> This prevents third party VPN providers from injecting rogue trust >> anchors. Note that in this case you already _are_ giving all your >> traffic including DNS to the VPN server. (but hey, we have DOH) >> >> 2) Don't accept trust anchors for anything not specifically >> split-redirected into the VPN infrastructure >> >> So in my redhat case, I would either allow "redhat.com" or >> "internal.redhat.com" to be redirected through my VPN profile >> and not anything else. (well, actually some reverse zone parts too) >> > > There are actually a number of oither things you could do: > > - Totally forbid the use of TLSA signed by non-default trust anchors > - Make the use of TLSA signed by non-default trust anchors a separate > protocol option with those trust anchors defined separately. > > I imagine there are other choices. > > > >> Yes, but it's not clear to me that clients can adequately determine which >>> domains >>> are internal -- they just get that information with some VPN config they >>> got >>> from their VPN provider. The text in the document says as much: >>> >> >> Yes. And that is the same DNS problem in general when connecting to a >> network and running your own recursive server. You usually get only one >> domain via DHCP, but universities tend to have dozens, and they demand >> you give them all your DNS queries so they can screw with internal only >> domains for you on the fly. You just have to drop DNSSEC to let them do >> that. That is a situation that needs fixing, and at least if you connec >> to those networks using a VPN, this document is that fix. It allows the >> network to send more than one DNS domain, and let's the client decide >> whether or not to accept it. Where yes, most clients will do this based >> on trusting their administrator of the VPN they are connecting to. Others >> could have VPN software that lets them (de)select the ones they would >> not accept. >> > > Trust isn't a monolithic thing. It's one thing to trust the administrator > to route > your packets and quite another to trust them to MITM TLS. Again, this is > why it's mostly safe to use HTTPS on networks owned by other people. > > > Note that without this document, the only way for VPN clients to get >> functional DNS beyond the 1 hardcoded domain, is to give the VPN all >> your DNS queries, which allows even more manipulation (especially with >> an installed Enterprise CA cert, now they can override gmail.com) >> > > I'm not saying this document is bad. I'm saying it should exclude TLSA. > > >> So it seems to me that the likely consequence of this function is that a >>> lot of >>> clients will be accepting what amounts to MITM certificates (again, >>> assuming >>> that they support DANE) as part of their VPN config. >>> >> >> Not doing this makes the situation even worse. Do you have a proposal >> that would make it better? I cannot think of one. >> > > Why does it make the situation worse? Again, what's the use case why > it's needed to have the VPN install a new WebPKI trust anchor. > > >> >> Also, part of your concerns could be mitigated by CT as well for the >> TLS cases. I assume if browsers require CT, that internal-only domains >> also need to get some kind of CT logging (redacted or not) and that >> would also prevent a rogue gmail.com TLSA from being accidentally >> accepted by the user at the IKE/VPN first as 'internal domain' and >> then additionally at the TLS/TLSA layer? >> > > Well, the semantics of CT+DANE are totally undefined, but generally, > no, I wouldn't expect things that were TLSA-authorized to be CTed. > If anything, I would expect them to use some sort of CT-for-DNS, but > of course that doesn't exist. And of course, with raw public keys > that's not even possible. > > > Paul >> ps. I'd really prefer this discussion to be in public on the list. >> Please do any replies to this to the ipsecme list. You have my >> permission to quote anything I wrote in this offlist mail thread. >> > > Sure. We really need aliases that do the right thing here. > > -Ekr > > > --00000000000095609c056f00b4c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For reference, here is my original review.
=
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.ne= t/D3046


The security considerations seem to omit a fairly se= rious potential
attack. Consider the case in which the client supplies t= his payload
and the server provides resolvers and DNSSEC anchors for som= e domain
it does not actually control, such as www.example.com. It then
provides a bogus IP address (of i= ts own) and a TLSA(2)=C2=A0 or TLSA(3)
record asserting its own key pair= . In this case, if the client
supports DANE, then you have at least pote= ntially circumvented the
PKI. This is far more serious than a bogus IP.= =C2=A0 The most likely
defense against this is for the client to filter = the domains for which
it accepts anchor overrides. However, even if you = do that, this still
introduces a weakness: if you are using straight DNS= SEC, then signing
can be offline, but because the TA is not signed by an= offline key,
compromise of the VPN endpoint means that you can forge DN= SSEC
records.




COMMENTS
>=C2=A0=C2=A0
>= =C2=A0=C2=A0 2.=C2=A0 Background
>=C2=A0=C2=A0
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Split DNS is a common configuration for enterprise VPN d= eployments,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in which only one or a fe= w private DNS domains are accessible and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 resolvable via an IPsec based VPN connection.

I see the "on= ly" binding to one, but isn't also generally the case
that they= are only accessible via the VPN connection.


>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 o=C2=A0 Digest Type (0 or 1 octet) - DS algorithm value fro= m the IANA
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Delegati= on Signer (DS) Resource Record (RR) Type Digest Algorithms
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Registry.
>=C2=A0=C2=A0
&= gt;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 Digest Data (0 or more octets) - = The DNSKEY digest as specified in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [RFC4034] Section 5.1 in presentation format.

I'= m having a little trouble reading this. Is the reason these would be
0 b= ecause you are using the empty format?


>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 o=C2=A0 Digest Data (0 or more octets) - The DNSKEY digest as spe= cified in
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC4034]= Section 5.1 in presentation format.
>=C2=A0=C2=A0
>=C2=A0=C2= =A0 5.=C2=A0 Split DNS Usage Guidelines
>=C2=A0=C2=A0
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 If a CFG_REPLY payload contains no INTERNAL_DNS_DO= MAIN attributes,

The rules in this section are kind of hard to follo= w. I'm not sure
what the best way to restructure them are, but perha= ps:=C2=A0 (1) If the
domain list is empty, you can use the internal serv= ers for anything
(2) If the list is non-empty, you MUST use the internal= servers for
any entries not prohibited by local policy, including total= limits ,
and should accept 1918 addresses fore those domains and SHOULD= NOT use
the internal servers for anything else.=C2=A0=C2=A0=C2=A0 -
=

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 servers.
>=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the initiator host is configured to = block DNS answers containing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP addre= sses from special IP address ranges such as those of
>=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [RFC1918], the initiator SHOULD allow the DNS domains liste= d in the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTERNAL_DNS_DOMAIN attribut= es to contain those Special IP addresses.

I would rewrite this with = the SHOULD first,, i..e, "SHOULD allow, even
if" because you w= ant this SHOULD to apply even if you aren't
configured this way.
=

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 no guarantee of being answered.= =C2=A0 For example, if the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 INTERNAL_D= NS_DOMAIN attribute specifies "example.= com", then
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "example.com", "www.example.com" and "mail.eng.example.com" MUST be
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 resolved using the internal DNS resolver(s), but "anotherexample.com"
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 and "ample.com" SHOULD NOT be resolved using the internal resolver
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 and SHOULD use the system's external DNS resol= ver(s).

This paragraph seems to to some extent duplicate the paragra= ph
starting with "For each INTERNAL_DNS_DOMAIN..."


On Tue, J= un 19, 2018 at 8:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Jun 19, 2018 at 8= :26 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 18 Jun 2018, Eric Rescorla wrote:

Right but the problem is that accepting the TA for a given domain allows the IPsec endpoint to act as a TLS endpoint for that domain
(assuming that the TLS client supports DANE).

 Yes. You are the Enterprise customer. It's a feature.
=
Not all enterprises who use VPNs want to run a MITM p= roxy.

The basic problem here is that the security = properties of DNS are
radically different from those of the WebPK= I (which is why we
routinely rely on HTTPS in cases where DNS is = untrustworthy).
So, it's totally unexpected that allowing the= VPN operator to
inject a new DNS trust anchor would allow them t= o attack HTTPS
connections. The problem with this design is that = it ties those
properties together. This is a problem for the user= s but also for
the enterprise because it takes something which mi= ght have
been offline signed and makes it online.


Cl= ient
implementations can limit these domains, eg using VPN profiles
that the user has to agree to. There is not much more we can do
at the protocol leven, than say the two things we already say:



1) If not split-view, do not accept any DNS trust anchors

This prevents third party VPN providers from injecting rogue trust
anchors. Note that in this case you already _are_ giving all your
traffic including DNS to the VPN server. (but hey, we have DOH)

2) Don't accept trust anchors for anything not specifically
=C2=A0 =C2=A0split-redirected into the VPN infrastructure

So in my redhat case, I would either allow "redhat.com" or
"internal.redhat.com" to be redirected through my VPN profil= e
and not anything else. (well, actually some reverse zone parts too)

There are actually a = number of oither things you could do:

- Totally fo= rbid the use of TLSA signed by non-default trust anchors
- Make t= he use of TLSA signed by non-default trust anchors a separate
pro= tocol option with those trust anchors defined separately.
I imagine there are other choices.

=C2= =A0
Yes, but it's not clear to me that clients can adequately determine whi= ch domains
are internal -- they just get that information with some VPN config they go= t
from their VPN provider. The text in the document says as much:

 Yes. And that is the same DNS problem in general when connecting to a
network and running your own recursive server. You usually get only one
domain via DHCP, but universities tend to have dozens, and they demand
you give them all your DNS queries so they can screw with internal only
domains for you on the fly. You just have to drop DNSSEC to let them do
that. That is a situation that needs fixing, and at least if you connec
to those networks using a VPN, this document is that fix. It allows the
network to send more than one DNS domain, and let's the client decide whether or not to accept it. Where yes, most clients will do this based
on trusting their administrator of the VPN they are connecting to. Others could have VPN software that lets them (de)select the ones they would
not accept.

Trust isn't a mo= nolithic thing. It's one thing to trust the administrator to route
your packets and quite another to trust them to MITM TLS. Again, this= is
why it's mostly safe to use HTTPS on networks owned by ot= her people.


Note that without this document, the only way for VPN clients to get
functional DNS beyond the 1 hardcoded domain, is to give the VPN all
your DNS queries, which allows even more manipulation (especially with
an installed Enterprise CA cert, now they can override gmail.com)

I'm not saying this document = is bad. I'm saying it should exclude TLSA.
<= br>

So it seems to me that the likely consequence of this function is that a lo= t of
clients will be accepting what amounts to MITM certificates (again, assumin= g
that they support DANE) as part of their VPN config.

 Not doing this makes the situation even worse. Do you have a proposal
that would make it better? I cannot think of one.

=
Why does it make the situation worse? Again, what's t= he use case why
it's needed to have the VPN install a new Web= PKI trust anchor.
=C2=A0

Also, part of your concerns could be mitigated by CT as well for the
TLS cases. I assume if browsers require CT, that internal-only domains
also need to get some kind of CT logging (redacted or not) and that
would also prevent a rogue gmail.com TLSA from being accidentally
accepted by the user at the IKE/VPN first as 'internal domain' and<= br> then additionally at the TLS/TLSA layer?

<= /div>
Well, the semantics of CT+DANE are totally undefined, but = generally,
no, I wouldn't expect things that were TLSA-author= ized to be CTed.
If anything, I would expect them to use some sor= t of CT-for-DNS, but
of course that doesn't exist. And of cou= rse, with raw public keys
that's not even possible.
=


<= /span>
Paul
 ps. I'd really prefer this discussion to be in public on the list.
Please do any replies to this to the ipsecme list. You have my
permission to quote anything I wrote in this offlist mail thread.

Sure. We really need aliases that do the = right thing here.

-Ekr



--00000000000095609c056f00b4c8-- From nobody Tue Jun 19 09:41:23 2018 Return-Path: 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 307E7131189; Tue, 19 Jun 2018 09:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 aYbynjeSV0nY; Tue, 19 Jun 2018 09:41:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E251311AD; Tue, 19 Jun 2018 09:41:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419DHJ0RrTzF5H; Tue, 19 Jun 2018 18:41:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529426460; bh=MbkDt1BBuml2Auk/wWXPTMolxFBuwx47rPt5pL5UHio=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Xj8zLjIcF2GfvA6HcMnIbTNnXRc9sZaJoHUE5b7WwxLQfDKR6Ma7WqikPhA1MTSsD jArv+EuHJBXx99Y0aUrYchNymA+TINQClkNX8Uvouk7m8LNnACt43a3ABVjXiArtrg aZaxisyXdqqrYqw6GpLaKvVlFTlBheAPqvVaPeUw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id F6nqtrIZ1wpi; Tue, 19 Jun 2018 18:40:57 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Jun 2018 18:40:56 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7C0EC4FB769; Tue, 19 Jun 2018 12:40:55 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7C0EC4FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 72A7D4070C0D; Tue, 19 Jun 2018 12:40:55 -0400 (EDT) Date: Tue, 19 Jun 2018 12:40:55 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: IPsecME WG , "Waltermire, David A. (Fed)" , Tero Kivinen , "draft-ietf-ipsecme-split-dns.all@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 16:41:22 -0000 On Tue, 19 Jun 2018, Eric Rescorla wrote: > Yes. You are the Enterprise customer. It's a feature. > > Not all enterprises who use VPNs want to run a MITM proxy. So only specify INTERNAL_DNS_DOMAIN with "internal.example.com" and all TA's outside that domain would not be accepted by the client. > The basic problem here is that the security properties of DNS are > radically different from those of the WebPKI (which is why we > routinely rely on HTTPS in cases where DNS is untrustworthy). > So, it's totally unexpected that allowing the VPN operator to > inject a new DNS trust anchor would allow them to attack HTTPS > connections. The problem with this design is that it ties those > properties together. This is a problem for the users but also for > the enterprise because it takes something which might have > been offline signed and makes it online. Local policy gives clients the chance to only allow preconfigured domain(s) to be accepted for redirection over the VPN, with or without trust anchors. If the network operator is smart, they have only one internal-only zone in use. And the client accepting that trust anchor is not a problem. In the case of the network insisting you need to accept dozens of trust anchors, then yes the network administrator makes it hard or impossible for their users to engage in anything other then blind trust of their enterprise devices. (but to be fair, you are in that situation already when you take that enterprise pre-installed laptop) > Client > implementations can limit these domains, eg using VPN profiles > that the user has to agree to. There is not much more we can do > at the protocol leven, than say the two things we already say: > > 1) If not split-view, do not accept any DNS trust anchors > > This prevents third party VPN providers from injecting rogue trust > anchors. Note that in this case you already _are_ giving all your > traffic including DNS to the VPN server. (but hey, we have DOH) > > 2) Don't accept trust anchors for anything not specifically >    split-redirected into the VPN infrastructure > > So in my redhat case, I would either allow "redhat.com" or > "internal.redhat.com" to be redirected through my VPN profile > and not anything else. (well, actually some reverse zone parts too) > > > There are actually a number of oither things you could do: > > - Totally forbid the use of TLSA signed by non-default trust anchors The IKE/IPsec protocol should not modify the DNS protocol. The fact that control of a certain (sub)domain is transfered via a private view reachable via IPsec is a feature, not a bug. That would also break the use of TLSA records in those private/internal views. Practically speaking, in my setup, the unbound daemon cannot tell the difference between trust anchors loaded via IKE/IPsec or via another method. > - Make the use of TLSA signed by non-default trust anchors a separate > protocol option with those trust anchors defined separately. That goes against the goal of the protocol. The goal _is_ to place a certain (internal only) domain fully under control of the network of the VPN server. Including all security features and trust anchors within that zone. > I imagine there are other choices. This protocol extension is explicitely to add or a move a subdomain in the public DNS view to a private DNS view, after the user has given permission for this. Any suggestions to do otherwise is undesired. > Trust isn't a monolithic thing. Right, we are in fact carving out a little bit to move that trust from the public DNS view to a private trusted actor. > It's one thing to trust the administrator to route > your packets and quite another to trust them to MITM TLS. MITM TLS for those domains you have given them permission for. > Again, this is > why it's mostly safe to use HTTPS on networks owned by other people. And it is _still_ save to use other people's domains unrelated to the internal vpn zone(s) for HTTPS and no new trust anchors are added that would compromise that security. Also, look at it from the reverse perspective. The enterprise might like the security of their highly valuable non-public servers/data to be higher then trusting 500+ webpki entities and google/mozilla, patched up with CT. They might want to rely on DANE/DNSSEC that's actually fully under only their own organisations sole control, bys using that overriding local trust anchor. Including for TLSA/HTTPS on their private servers. Why would you want to prevent them from leveling that extra security? > Note that without this document, the only way for VPN clients to get > functional DNS beyond the 1 hardcoded domain, is to give the VPN all > your DNS queries, which allows even more manipulation (especially with > an installed Enterprise CA cert, now they can override gmail.com) > > > I'm not saying this document is bad. I'm saying it should exclude TLSA. I'm saying that cannot happen without breaking to use of TLSA in internal networks. Also, then the issue moves to IPSECKEY records which have an even stronger case to be used with internal DNSSEC based trust anchors. How is a DNS server to know which TLSA records to ignore? And are browsers going to clear their DNS cache when a VPN goes up or down? Modifying the DNS protocol seems rather unrealistic. > So it seems to me that the likely consequence of this function is that a lot of > clients will be accepting what amounts to MITM certificates (again, assuming > that they support DANE) as part of their VPN config. You could ask IKE client implementations what they plan to do for INTERNAL_DNSSEC_TA. Our implementation will allow specifying a list of domains for which you will allow redirection and trust anchors. And I would set this to "redhat.com, 10.in-addr.arpa" to prevent the corporate network from installing anything else on my machine. > Not doing this makes the situation even worse. Do you have a proposal > that would make it better? I cannot think of one. Because in the current situation, the protocol does not allow to request only DNS queries for one or some domains. You can only ask for none or all DNS queries. That has a huge privacy impact. So only power users like us can tweak things like adding a forward_zone to unbound to ensure only the internal-domain DNS queries go the the server. > Why does it make the situation worse? Again, what's the use case why > it's needed to have the VPN install a new WebPKI trust anchor. Because the public DNSSEC view proves the internal view does not exist, so you need an override. Because the private DNS wants to use DNSSEC too. > Also, part of your concerns could be mitigated by CT as well for the > TLS cases. I assume if browsers require CT, that internal-only domains > also need to get some kind of CT logging (redacted or not) and that > would also prevent a rogue gmail.com TLSA from being accidentally > accepted by the user at the IKE/VPN first as 'internal domain' and > then additionally at the TLS/TLSA layer? > > > Well, the semantics of CT+DANE are totally undefined I was not talking about CT+DANE. I was talking about browsers mandating CT and browsers not being aware that internal.redhat.com would need to be treated differently. So even for those internal domains will need to publish valid CT data (redacted or not) which would further reduce the effects a malicious INTERNAL_DNSSEC_TA could do even if the client accepted one for a domain not under enterprise control. Paul From nobody Tue Jun 19 10:04:41 2018 Return-Path: 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 B105F13115A; Tue, 19 Jun 2018 10:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 0ZgFBN23P9Aw; Tue, 19 Jun 2018 10:04:37 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91489130DE3; Tue, 19 Jun 2018 10:04:37 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 0B00330002BA8; Tue, 19 Jun 2018 10:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=jgLm6oP6n6xWg6 5zN+qv29xkuQE=; b=iGmVZsKE0ZTDyC7CjAJ+2rYEdKRJSPISQGnfpbf8zf1TJe VLEwcoC2TgsZQTYKmXwnyWk6zM7uieNQpogeiVTjQyBlRQuFqW30cbGMh/xalr8V UHalEoSP6/uayA1n1fVUmVUfYc7gOkVMx4g+Fqk3+vcNqXRZVcUsTjIi6zD+M= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 5673330002BA9; Tue, 19 Jun 2018 10:04:35 -0700 (PDT) Date: Tue, 19 Jun 2018 12:04:33 -0500 From: Nico Williams To: Paul Wouters Cc: Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619170432.GB4218@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:04:40 -0000 On Tue, Jun 19, 2018 at 12:40:55PM -0400, Paul Wouters wrote: > On Tue, 19 Jun 2018, Eric Rescorla wrote: > > > Yes. You are the Enterprise customer. It's a feature. > > > >Not all enterprises who use VPNs want to run a MITM proxy. > > So only specify INTERNAL_DNS_DOMAIN with "internal.example.com" > and all TA's outside that domain would not be accepted by the client. What the I-D has to say is that the VPN client MUST support local policy for what domains it will accept TAs for from the SG. This is far simpler for the client than having to have local DNS configuration including TAs for split-DNS. A perfectly valid configuration would have the SG MITM all external DNS too, thus sending the client only TAs for . [and possibly internal domains if the client only wants those, but then the client will not be able to use DNSSEC for external domains]. If the client doesn't want this, then it mustn't use that SG. In practice, for enterprises, the client gets no choice, and may even be built, configured, maintained, and provided by the enterprise. This I-D would be useful if the enterprise provides and maintains the VPN client: it makes it easier to maintain clients by reducing the amount of configuration to update as keys are rotated or policy changed. This is just a matter of Security Considerations wordsmithing. Nico -- From nobody Tue Jun 19 10:14:35 2018 Return-Path: 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 D123D131185 for ; Tue, 19 Jun 2018 10:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] autolearn=ham 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 8rSIL8B1OOtb for ; Tue, 19 Jun 2018 10:14:28 -0700 (PDT) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 60C48130DE3 for ; Tue, 19 Jun 2018 10:14:28 -0700 (PDT) Received: by mail-ot0-x242.google.com with SMTP id p95-v6so518658ota.5 for ; Tue, 19 Jun 2018 10:14:28 -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=KFth4xc5gUnG7zpjyM+liBjiQR+8T0OZEuItSCYu22I=; b=IfVmYTSQT8heQs+B2BRmv18Lz5Pp86vNhMwYEpzzpYgZZvL915F+nQRAidVFu9VzvC PyluxLR6BqX2WsVzIE8fsdHXmPjC7eum640jBKLNONl+cK+XLDchXitvO1gTfCHLtBtm 9NrLvqfKhM3nKUo5CLZyG66+cxZYB6UrmIhQX/DUa6OKvMGHpyab6FxHi9D/PIO2r/bq gGaTEOt7ZbyrYejZL4GWseP41MV3mUFR0xmxBz5zv5mBafKS3hHtwa/hbdm9zyvbWTYf Hd0TDC70QoYOPYi+2dX4ehIjnc8Qr3x0VCtZfDqvkjHLawyoMSF0CupvdSXEyMkF9Syw hMpg== 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=KFth4xc5gUnG7zpjyM+liBjiQR+8T0OZEuItSCYu22I=; b=ly602B+IXqelc2CfUMSqhU4PC3nB0NOtba/Dw7z4lvzEtfFhHtkxKnvaiX6Vc5wJxx rnDuNf6+qEGrUwv4//5BSC7806gZjRwrgzH/LaB2vEag29S639T0TiRCh6R4heRMWfCt cL7PgkRePgHRean1aSpNmV2lldA//dM5VijbpDzWz1S+6LGh8YvqK+aKck+qczr8iS5c oNIjGf+Pj3xpTn9GjIEuPDN5+QbPhPgZiJgtUbq1KOIKPgtnQgJJRrh8NAxc54uRy8DC tJD0QZaJpu+kXabCnbbfBRjpqLp8kn6mu9ZyZCEPUehmc4RxC7769ZV6tcAet248w3bP o2lA== X-Gm-Message-State: APt69E12V12EF41BrLSfELnY1m0cJx6VjnCcRTB1uRrZCjG74/TVZWM9 gCOhrmzlXF+Dre1xWfhI5ys7kb8I7OXGwdGqvWXl2Q== X-Google-Smtp-Source: ADUXVKIGjqmX2zmNL4tjfHUNZDVes9oYUPE85WleUTGrOecCWrZnFQhapvF3g0P9su5MmPjIXpLFheVFUkbu6YjX8Tg= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr11698743otb.371.1529428467648; Tue, 19 Jun 2018 10:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 10:13:47 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 19 Jun 2018 10:13:47 -0700 Message-ID: To: Paul Wouters Cc: IPsecME WG , "Waltermire, David A. (Fed)" , Tero Kivinen , "draft-ietf-ipsecme-split-dns.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086242c056f01d01d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 17:14:33 -0000 --00000000000086242c056f01d01d Content-Type: text/plain; charset="UTF-8" I don't think that going point-by-point is getting us very far, so I'm going to try to restate what i think the situation is, from the top. 1. In the current design, many clients (those whose enterprises have any significant number of domains) are just going to have to accept whatever domains the VPN server claims should be treated as internal, and to accept the trust anchors the VPN server claims 2. Because the current design also allows those trust anchors to sign TLSA records, any TLS client which accepts those TLSA records is subject to MITM by the VPN server 3. Even if enterprise doesn't intend to run a MITM proxy, this means that any compromise of the VPN server automatically makes it an MITM proxy for the Internet as a whole, because the person who compromises it can simply reconfigure it to advertise any domain of its choice as internal, as well as the corresponding keys and TLSA records. What, if any, of the above do you disagree with? -Ekr On Tue, Jun 19, 2018 at 9:40 AM, Paul Wouters wrote: > On Tue, 19 Jun 2018, Eric Rescorla wrote: > > Yes. You are the Enterprise customer. It's a feature. >> >> Not all enterprises who use VPNs want to run a MITM proxy. >> > > So only specify INTERNAL_DNS_DOMAIN with "internal.example.com" > and all TA's outside that domain would not be accepted by the client. > > The basic problem here is that the security properties of DNS are >> radically different from those of the WebPKI (which is why we >> routinely rely on HTTPS in cases where DNS is untrustworthy). >> So, it's totally unexpected that allowing the VPN operator to >> inject a new DNS trust anchor would allow them to attack HTTPS >> connections. The problem with this design is that it ties those >> properties together. This is a problem for the users but also for >> the enterprise because it takes something which might have >> been offline signed and makes it online. >> > > Local policy gives clients the chance to only allow preconfigured > domain(s) to be accepted for redirection over the VPN, with or > without trust anchors. If the network operator is smart, they have > only one internal-only zone in use. And the client accepting that > trust anchor is not a problem. In the case of the network insisting > you need to accept dozens of trust anchors, then yes the network > administrator makes it hard or impossible for their users to engage > in anything other then blind trust of their enterprise devices. > (but to be fair, you are in that situation already when you take > that enterprise pre-installed laptop) > > Client >> implementations can limit these domains, eg using VPN profiles >> that the user has to agree to. There is not much more we can do >> at the protocol leven, than say the two things we already say: >> >> 1) If not split-view, do not accept any DNS trust anchors >> >> This prevents third party VPN providers from injecting rogue trust >> anchors. Note that in this case you already _are_ giving all your >> traffic including DNS to the VPN server. (but hey, we have DOH) >> >> 2) Don't accept trust anchors for anything not specifically >> split-redirected into the VPN infrastructure >> >> So in my redhat case, I would either allow "redhat.com" or >> "internal.redhat.com" to be redirected through my VPN profile >> and not anything else. (well, actually some reverse zone parts too) >> >> >> There are actually a number of oither things you could do: >> >> - Totally forbid the use of TLSA signed by non-default trust anchors >> > > The IKE/IPsec protocol should not modify the DNS protocol. The fact > that control of a certain (sub)domain is transfered via a private > view reachable via IPsec is a feature, not a bug. That would also break > the use of TLSA records in those private/internal views. > > Practically speaking, in my setup, the unbound daemon cannot tell the > difference between trust anchors loaded via IKE/IPsec or via another > method. > > - Make the use of TLSA signed by non-default trust anchors a separate >> protocol option with those trust anchors defined separately. >> > > That goes against the goal of the protocol. The goal _is_ to place a > certain (internal only) domain fully under control of the network of > the VPN server. Including all security features and trust anchors within > that zone. > > I imagine there are other choices. >> > > This protocol extension is explicitely to add or a move a subdomain in > the public DNS view to a private DNS view, after the user has given > permission for this. Any suggestions to do otherwise is undesired. > > Trust isn't a monolithic thing. >> > > Right, we are in fact carving out a little bit to move that trust > from the public DNS view to a private trusted actor. > > It's one thing to trust the administrator to route >> your packets and quite another to trust them to MITM TLS. >> > > MITM TLS for those domains you have given them permission for. > > Again, this is >> why it's mostly safe to use HTTPS on networks owned by other people. >> > > And it is _still_ save to use other people's domains unrelated to the > internal vpn zone(s) for HTTPS and no new trust anchors are added > that would compromise that security. > > Also, look at it from the reverse perspective. The enterprise might like > the security of their highly valuable non-public servers/data to be higher > then trusting 500+ webpki entities and google/mozilla, patched up with CT. > They might want to rely on DANE/DNSSEC that's actually fully under only > their own organisations sole control, bys using that overriding local > trust anchor. Including for TLSA/HTTPS on their private servers. Why would > you want to prevent them from leveling that extra security? > > Note that without this document, the only way for VPN clients to get >> functional DNS beyond the 1 hardcoded domain, is to give the VPN all >> your DNS queries, which allows even more manipulation (especially >> with >> an installed Enterprise CA cert, now they can override gmail.com) >> >> >> I'm not saying this document is bad. I'm saying it should exclude TLSA. >> > > I'm saying that cannot happen without breaking to use of TLSA in > internal networks. Also, then the issue moves to IPSECKEY records > which have an even stronger case to be used with internal DNSSEC > based trust anchors. > > How is a DNS server to know which TLSA records to ignore? And are > browsers going to clear their DNS cache when a VPN goes up or down? > > Modifying the DNS protocol seems rather unrealistic. > > So it seems to me that the likely consequence of this function >> is that a lot of >> clients will be accepting what amounts to MITM certificates >> (again, assuming >> that they support DANE) as part of their VPN config. >> > > You could ask IKE client implementations what they plan to do for > INTERNAL_DNSSEC_TA. Our implementation will allow specifying a list > of domains for which you will allow redirection and trust anchors. > And I would set this to "redhat.com, 10.in-addr.arpa" to prevent > the corporate network from installing anything else on my machine. > > Not doing this makes the situation even worse. Do you have a proposal >> that would make it better? I cannot think of one. >> > > Because in the current situation, the protocol does not allow to request > only DNS queries for one or some domains. You can only ask for none or > all DNS queries. That has a huge privacy impact. So only power users > like us can tweak things like adding a forward_zone to unbound to ensure > only the internal-domain DNS queries go the the server. > > Why does it make the situation worse? Again, what's the use case why >> it's needed to have the VPN install a new WebPKI trust anchor. >> > > Because the public DNSSEC view proves the internal view does not exist, > so you need an override. > > Because the private DNS wants to use DNSSEC too. > > Also, part of your concerns could be mitigated by CT as well for the >> TLS cases. I assume if browsers require CT, that internal-only >> domains >> also need to get some kind of CT logging (redacted or not) and that >> would also prevent a rogue gmail.com TLSA from being accidentally >> accepted by the user at the IKE/VPN first as 'internal domain' and >> then additionally at the TLS/TLSA layer? >> >> >> Well, the semantics of CT+DANE are totally undefined >> > > I was not talking about CT+DANE. I was talking about browsers mandating > CT and browsers not being aware that internal.redhat.com would need to > be treated differently. So even for those internal domains will need to > publish valid CT data (redacted or not) which would further reduce the > effects a malicious INTERNAL_DNSSEC_TA could do even if the client > accepted one for a domain not under enterprise control. > > Paul > --00000000000086242c056f01d01d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think that going point-by-point is gettin= g us very far, so I'm going to try to restate what i think the situatio= n is, from the top.

1. In the current design, = many clients (those whose enterprises have any significant number of domain= s) are just going to have to accept whatever domains the VPN server claims = should be treated as internal, and to accept the trust anchors the VPN serv= er claims
2. Because the current design also allows those tru= st anchors to sign TLSA records, any TLS client which accepts those TLSA re= cords is subject to MITM by the VPN server
3. Even if enterprise = doesn't intend to run a MITM proxy, this means that any compromise of t= he VPN server automatically makes it an MITM proxy for the Internet as a wh= ole, because the person who compromises it can simply reconfigure it to adv= ertise any domain of its choice as internal, as well as the corresponding k= eys and TLSA records.

What, if any, of the above d= o you disagree with?

-Ekr


On Tue, Jun 19,= 2018 at 9:40 AM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 19 Jun 2018, Eric Rescor= la wrote:

=C2=A0 =C2=A0 =C2=A0 Yes. You are the Enterprise customer. It's a featu= re.

Not all enterprises who use VPNs want to run a MITM proxy.

 So only specify INTERNAL_DNS_DOMAIN with "internal.example.com&q= uot;
and all TA's outside that domain would not be accepted by the client.

The basic problem here is that the security properties of DNS are
radically different from those of the WebPKI (which is why we
routinely rely on HTTPS in cases where DNS is untrustworthy).
So, it's totally unexpected that allowing the VPN operator to
inject a new DNS trust anchor would allow them to attack HTTPS
connections. The problem with this design is that it ties those
properties together. This is a problem for the users but also for
the enterprise because it takes something which might have
been offline signed and makes it online.

Local policy gives clients the chance to only allow preconfigured
domain(s) to be accepted for redirection over the VPN, with or
without trust anchors. If the network operator is smart, they have
only one internal-only zone in use. And the client accepting that
trust anchor is not a problem. In the case of the network insisting
you need to accept dozens of trust anchors, then yes the network
administrator makes it hard or impossible for their users to engage
in anything other then blind trust of their enterprise devices.
(but to be fair, you are in that situation already when you take
=C2=A0that enterprise pre-installed laptop)

=C2=A0 =C2=A0 =C2=A0 Client
=C2=A0 =C2=A0 =C2=A0 implementations can limit these domains, eg using VPN = profiles
=C2=A0 =C2=A0 =C2=A0 that the user has to agree to. There is not much more = we can do
=C2=A0 =C2=A0 =C2=A0 at the protocol leven, than say the two things we alre= ady say:

=C2=A0 =C2=A0 =C2=A0 1) If not split-view, do not accept any DNS trust anch= ors

=C2=A0 =C2=A0 =C2=A0 This prevents third party VPN providers from injecting= rogue trust
=C2=A0 =C2=A0 =C2=A0 anchors. Note that in this case you already _are_ givi= ng all your
=C2=A0 =C2=A0 =C2=A0 traffic including DNS to the VPN server. (but hey, we = have DOH)

=C2=A0 =C2=A0 =C2=A0 2) Don't accept trust anchors for anything not spe= cifically
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0split-redirected into the VPN infrastruct= ure

=C2=A0 =C2=A0 =C2=A0 So in my redhat case, I would either allow "redhat.com" or
=C2=A0 =C2=A0 =C2=A0 "internal.redhat.com" to be redirected = through my VPN profile
=C2=A0 =C2=A0 =C2=A0 and not anything else. (well, actually some reverse zo= ne parts too)


There are actually a number of oither things you could do:

- Totally forbid the use of TLSA signed by non-default trust anchors

 The IKE/IPsec protocol should not modify the DNS protocol. The fact
that control of a certain (sub)domain is transfered via a private
view reachable via IPsec is a feature, not a bug. That would also break
the use of TLSA records in those private/internal views.

Practically speaking, in my setup, the unbound daemon cannot tell the
difference between trust anchors loaded via IKE/IPsec or via another
method.

- Make the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.

 That goes against the goal of the protocol. The goal _is_ to place a
certain (internal only) domain fully under control of the network of
the VPN server. Including all security features and trust anchors within that zone.

I imagine there are other choices.

 This protocol extension is explicitely to add or a move a subdomain in
the public DNS view to a private DNS view, after the user has given
permission for this. Any suggestions to do otherwise is undesired.

Trust isn't a monolithic thing.

 Right, we are in fact carving out a little bit to move that trust
from the public DNS view to a private trusted actor.

It's one thing to trust the administrator to route
your packets and quite another to trust them to MITM TLS.

 MITM TLS for those domains you have given them permission for.

Again, this is
why it's mostly safe to use HTTPS on networks owned by other people.

And it is _still_ save to use other people's domains unrelated to the internal vpn zone(s) for HTTPS and no new trust anchors are added
that would compromise that security.

Also, look at it from the reverse perspective. The enterprise might like the security of their highly valuable non-public servers/data to be higher<= br> then trusting 500+ webpki entities and google/mozilla, patched up with CT.<= br> They might want to rely on DANE/DNSSEC that's actually fully under only=
their own organisations sole control, bys using that overriding local
trust anchor. Including for TLSA/HTTPS on their private servers. Why would<= br> you want to prevent them from leveling that extra security?

=C2=A0 =C2=A0 =C2=A0 Note that without this document, the only way for VPN = clients to get
=C2=A0 =C2=A0 =C2=A0 functional DNS beyond the 1 hardcoded domain, is to gi= ve the VPN all
=C2=A0 =C2=A0 =C2=A0 your DNS queries, which allows even more manipulation = (especially with
=C2=A0 =C2=A0 =C2=A0 an installed Enterprise CA cert, now they can override= gmail.co= m)


I'm not saying this document is bad. I'm saying it should exclude T= LSA.

 I'm saying that cannot happen without breaking to use of TLSA in
internal networks. Also, then the issue moves to IPSECKEY records
which have an even stronger case to be used with internal DNSSEC
based trust anchors.

How is a DNS server to know which TLSA records to ignore? And are
browsers going to clear their DNS cache when a VPN goes up or down?

Modifying the DNS protocol seems rather unrealistic.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So it seems to me that the likely= consequence of this function is that a lot of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clients will be accepting what am= ounts to MITM certificates (again, assuming
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that they support DANE) as part o= f their VPN config.

 You could ask IKE client implementations what they plan to do for
INTERNAL_DNSSEC_TA. Our implementation will allow specifying a list
of domains for which you will allow redirection and trust anchors.
And I would set this to "redhat.com, 10.in-addr.arpa" to prevent
the corporate network from installing anything else on my machine.

=C2=A0 =C2=A0 =C2=A0 Not doing this makes the situation even worse. Do you = have a proposal
=C2=A0 =C2=A0 =C2=A0 that would make it better? I cannot think of one.

 Because in the current situation, the protocol does not allow to request only DNS queries for one or some domains. You can only ask for none or
all DNS queries. That has a huge privacy impact. So only power users
like us can tweak things like adding a forward_zone to unbound to ensure only the internal-domain DNS queries go the the server.
Why does it make the situation worse? Again, what's the use case why it's needed to have the VPN install a new WebPKI trust anchor.

 Because the public DNSSEC view proves the internal view does not exist,
so you need an override.

Because the private DNS wants to use DNSSEC too.

=C2=A0 =C2=A0 =C2=A0 Also, part of your concerns could be mitigated by CT a= s well for the
=C2=A0 =C2=A0 =C2=A0 TLS cases. I assume if browsers require CT, that inter= nal-only domains
=C2=A0 =C2=A0 =C2=A0 also need to get some kind of CT logging (redacted or = not) and that
=C2=A0 =C2=A0 =C2=A0 would also prevent a rogue gmail.com TLSA from being accide= ntally
=C2=A0 =C2=A0 =C2=A0 accepted by the user at the IKE/VPN first as 'inte= rnal domain' and
=C2=A0 =C2=A0 =C2=A0 then additionally at the TLS/TLSA layer?


Well, the semantics of CT+DANE are totally undefined

 I was not talking about CT+DANE. I was talking about browsers mandating
CT and browsers not being aware that internal.redhat.com would need to=
be treated differently. So even for those internal domains will need to
publish valid CT data (redacted or not) which would further reduce the
effects a malicious INTERNAL_DNSSEC_TA could do even if the client
accepted one for a domain not under enterprise control.

Paul

--00000000000086242c056f01d01d-- From nobody Tue Jun 19 11:35:06 2018 Return-Path: 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 D04AE130E10; Tue, 19 Jun 2018 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 lYbJ8D1WPzOm; Tue, 19 Jun 2018 11:35:03 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781D9130E1C; Tue, 19 Jun 2018 11:35:03 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 5AF3030002BA9; Tue, 19 Jun 2018 11:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=fPoI/pTBw08GIt Dc1RcMBwzjpBA=; b=lx8NDQ544QH4BVvEFATFTDl5S3hAm9mAUiPy9YNE0LYBO3 zuSkNQvAqg44cZmS+YkYDX/uZW96Da+F5i9n85skrYWXa00pu4TbcfeQn8GONdNi O+u/nutc/fwZNBkpxo+s7VxOQyaLxvx+Ko2btYdsQafTDuVaj2e8Vh14v/5Kw= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id C5C5D30002BAC; Tue, 19 Jun 2018 11:35:01 -0700 (PDT) Date: Tue, 19 Jun 2018 13:34:59 -0500 From: Nico Williams To: Eric Rescorla Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619183459.GC4218@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 18:35:06 -0000 On Tue, Jun 19, 2018 at 10:13:47AM -0700, Eric Rescorla wrote: > I don't think that going point-by-point is getting us very far, so I'm > going to try to restate what i think the situation is, from the top. > > 1. In the current design, many clients (those whose enterprises have any > significant number of domains) are just going to have to accept whatever > domains the VPN server claims should be treated as internal, and to accept > the trust anchors the VPN server claims The I-D should say that clients MUST allow local configuration of what domains to accept trust anchors for, and SHOULD allow local policy to list . as a domain for which to accept trust anchors. This local configuration should be per-SG. > 2. Because the current design also allows those trust anchors to sign TLSA > records, any TLS client which accepts those TLSA records is subject to MITM > by the VPN server And SSHFP. And anything else that might be security-relevent (all of DNS, really). This definitely merits a Security Considerations note even if this property were actually the point of this protocol. > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that > any compromise of the VPN server automatically makes it an MITM proxy for > the Internet as a whole, because the person who compromises it can simply > reconfigure it to advertise any domain of its choice as internal, as well > as the corresponding keys and TLSA records. Sure, but it's not like clients will be choosing to connect to any VPN servers. Generally the client must already have a trust anchor for the SG to begin with. Painting this as a security threat to the entire Internet is going a bit too far. > What, if any, of the above do you disagree with? (3). Nico -- From nobody Tue Jun 19 12:03:22 2018 Return-Path: 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 112811311CD; Tue, 19 Jun 2018 12:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 ivpF3jyIGYZ6; Tue, 19 Jun 2018 12:03:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCC1130EF6; Tue, 19 Jun 2018 12:02:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419HQc2JkyzF8K; Tue, 19 Jun 2018 21:02:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529434952; bh=bYA5oMHasQASCDUZUaepZ3q1/KTdYvjBH+f4lUfsox8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OzAE9/oRFgudgWUna5BCIiEfe/cFtANfdvYoKQT/oQPMmAafH3izNIFR0d5pyiLDK x+FGgzdUim/CbQmpqZss9pu80v+usD0bgORSx2gzxrTl/4d4qK2kIC+X9TPUV6U1V7 6iDAN9+rxPe03CxlHxlUswoDIG/5Zbuq3P4dW6ko= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kX7s0hmJKpS7; Tue, 19 Jun 2018 21:02:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Jun 2018 21:02:30 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 584F64FB769; Tue, 19 Jun 2018 15:02:29 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 584F64FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4D33F4070C0D; Tue, 19 Jun 2018 15:02:29 -0400 (EDT) Date: Tue, 19 Jun 2018 15:02:29 -0400 (EDT) From: Paul Wouters To: Nico Williams cc: Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: <20180619183459.GC4218@localhost> Message-ID: References: <20180619183459.GC4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:03:19 -0000 On Tue, 19 Jun 2018, Nico Williams wrote: > The I-D should say that clients MUST allow local configuration of what > domains to accept trust anchors for, and SHOULD allow local policy to > list . as a domain for which to accept trust anchors. It already says so: If a client is configured by local policy to only accept a limited number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other INTERNAL_DNS_DOMAIN values. However, "limited number" is confusing and it should be reworded to say "to only accept certain specific domain names" >> 2. Because the current design also allows those trust anchors to sign TLSA >> records, any TLS client which accepts those TLSA records is subject to MITM >> by the VPN server > > And SSHFP. And anything else that might be security-relevent (all of > DNS, really). > > This definitely merits a Security Considerations note even if this > property were actually the point of this protocol. That is all stated in section 6: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-08#section-6 Paul From nobody Tue Jun 19 12:07:14 2018 Return-Path: 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 12C9E130FA2; Tue, 19 Jun 2018 12:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 p076L5F1QtZB; Tue, 19 Jun 2018 12:07:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512DB130E20; Tue, 19 Jun 2018 12:07:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419HWq6Wg8zF8K; Tue, 19 Jun 2018 21:07:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529435223; bh=gVHpgRjPHAXhIvNoXDqUlWd7dvwHIF1reiV0Rc9873E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BQjfY511vAh1w//jmDPmClovc2XnpZ3BRCtp2FbvAk9NhTU+l3tcknsZd5aKNoayP e9jdEj7bP9Tf1jMBmp4lds2T9606gXcBN80b15iU+BcuWDGGUES1RRsLOV9jzdGUdl hWz1GPXZysQSzOrpY0Og0bDHt/iweMTEcOXspzrE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jModMsT8NwL2; Tue, 19 Jun 2018 21:07:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Jun 2018 21:07:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 32F834FB769; Tue, 19 Jun 2018 15:07:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 32F834FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 29E6C4070C0D; Tue, 19 Jun 2018 15:07:02 -0400 (EDT) Date: Tue, 19 Jun 2018 15:07:02 -0400 (EDT) From: Paul Wouters To: Nico Williams cc: Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: <20180619183459.GC4218@localhost> Message-ID: References: <20180619183459.GC4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:07:12 -0000 On Tue, 19 Jun 2018, Nico Williams wrote: > The I-D should say that clients MUST allow local configuration of what > domains to accept trust anchors for, and SHOULD allow local policy to > list . as a domain for which to accept trust anchors. Just one note. This draft is mean ONLY for use with split-tunnel VPNs. If you are sending all traffic over the VPN, then INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA are irrelevant and MUST be ignored, because you are no longer talking about a public vs private view. You are just changing the entry point to the public view. Was that not clear from the existing text? Adding an option for "." as override trust anchor seems unneccessary for any non-malicious use case I can think of. Can you give an example of a valid use case? Paul From nobody Tue Jun 19 12:27:07 2018 Return-Path: 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 3E48D130ECA for ; Tue, 19 Jun 2018 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] autolearn=ham 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 jgNzziwP2TeI for ; Tue, 19 Jun 2018 12:26:51 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 A1D1D130F0D for ; Tue, 19 Jun 2018 12:26:51 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id k17-v6so15611180ita.0 for ; Tue, 19 Jun 2018 12:26:51 -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=UqOPfFbbpOkVjPDZ9sO/lKv3zbcARthdsARU5+96KIQ=; b=zaKetd0EqhnBMBkD8MgOpqLRrFpBCpKAS75fvEZ8E1EDCA22WDkDfdRsJK6IUQTwzC 1VIM+ACNoqZJzPiIkRs5J+XcfcdWqJsMzNt0PaU13TwsXcWXA8gpk6Bg+Cum7bX8giRf +GZaHXSuQSjjDOIvL5zJtokNmm+28lqU0Fi4JRm0dOMkIszuL4h95olnpEW5xCPEO7Vt Ie0JOW7Sa4/YkX2Uqn0EvaP21wVB38VcsAysndAuij1TtzT3gEXzs5bhwGYfywPMZ/32 NFJKzsNYF5kSGFYqRjfH+iViGKPFMqgE7s4VMt3ZPlJ9UCGtWGu1MG/V+dkq+snDowz2 KKSQ== 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=UqOPfFbbpOkVjPDZ9sO/lKv3zbcARthdsARU5+96KIQ=; b=GH+s9jPnx8N7+hMdUyHchS4TJlxj+RHLCregoOl5nF0StDIkMl8Wsb0KPzEQE8Hq12 WOkiPL4L4O7PQV3Qn21HW48QpYa8NFOjUIhDsGTrr+FYgAmMpb5G280/Xl3fhOUph8o0 RW+Ws8ZvU+PqEJ7bue+Vc13anzezlI6DyLbj9jGijWjiGPvAFj30uePBZNb2nXk91PDf F7g5ZJ5roffb81WryegzDXF6t/Vc9YLgnuQWBVKjQFhIrFe6DKEB1EUuroaAsgxCGRxw 6Yu26FYwiG/9ML4lu5QjEg38ZJ54zB7VFm9wxkmB91EvzXl4+u6mssFdSxC+iNRewuVD s25A== X-Gm-Message-State: APt69E2vY+DSSLSjwhQoeuh/3kTkrHT7oOxu9Qo1s6OAg0UC/IsiZAhK 03iI4/emFiAKOz0xGtN4x22DiXlQSumgIdPNuvjkcg== X-Google-Smtp-Source: ADUXVKIIjUVbAVfviq7cwjaeme3fs3T561qIbKiaR0z1YLbu3i8+Fwcn/9Sfyflx0GIJYJdjGYWSjJQQkG86RU9wuEE= X-Received: by 2002:a24:5913:: with SMTP id p19-v6mr13594511itb.126.1529436410986; Tue, 19 Jun 2018 12:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:4c45:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:26:10 -0700 (PDT) In-Reply-To: <20180619183459.GC4218@localhost> References: <20180619183459.GC4218@localhost> From: Eric Rescorla Date: Tue, 19 Jun 2018 12:26:10 -0700 Message-ID: To: Nico Williams Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000fbcf53056f03a977" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:27:06 -0000 --000000000000fbcf53056f03a977 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams wrote: > On Tue, Jun 19, 2018 at 10:13:47AM -0700, Eric Rescorla wrote: > > I don't think that going point-by-point is getting us very far, so I'm > > going to try to restate what i think the situation is, from the top. > > > > 1. In the current design, many clients (those whose enterprises have any > > significant number of domains) are just going to have to accept whatever > > domains the VPN server claims should be treated as internal, and to > accept > > the trust anchors the VPN server claims > > The I-D should say that clients MUST allow local configuration of what > domains to accept trust anchors for, and SHOULD allow local policy to > list . as a domain for which to accept trust anchors. > > This local configuration should be per-SG. > The ID can say that, but as a practical matter, any enterprise that has a reasonable number of internal domains is just going to tell people to configure their client to accept any domain name. > 2. Because the current design also allows those trust anchors to sign TLSA > > records, any TLS client which accepts those TLSA records is subject to > MITM > > by the VPN server > > And SSHFP. And anything else that might be security-relevent (all of > DNS, really). > Well, different parts of DNS are differently security relevant. For instance, the IP-address mapping usually isn't that big a deal because the network attacker can reroute you anyway. This definitely merits a Security Considerations note even if this ] > property were actually the point of this protocol. > > > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that > > any compromise of the VPN server automatically makes it an MITM proxy for > > the Internet as a whole, because the person who compromises it can simply > > reconfigure it to advertise any domain of its choice as internal, as well > > as the corresponding keys and TLSA records. > > Sure, but it's not like clients will be choosing to connect to any VPN > servers. Generally the client must already have a trust anchor for the > SG to begin with. Why? That trust anchor doesn't need to allow the creation of arbitrary WebPKI certs. All that is needed is to be able to authenticate the VPN server itself. Painting this as a security threat to the entire > Internet is going a bit too far. > Why? -Ekr --000000000000fbcf53056f03a977 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Tue, Jun 19, 2018 at 10:13:47AM -0700, Eric Rescorla wrote:
> I don't think that going point-by-point is getting us very far, so= I'm
> going to try to restate what i think the situation is, from the top. >
> 1. In the current design, many clients (those whose enterprises have a= ny
> significant number of domains) are just going to have to accept whatev= er
> domains the VPN server claims should be treated as internal, and to ac= cept
> the trust anchors the VPN server claims

The I-D should say that clients MUST allow local configuration of wh= at
domains to accept trust anchors for, and SHOULD allow local policy to
list . as a domain for which to accept trust anchors.

This local configuration should be per-SG.

<= div>The ID can say that, but as a practical matter, any enterprise that has=
a reasonable number of internal domains is just going to tell pe= ople
to configure their client to accept any domain name.


<= span class=3D"">
> 2. Because the current design also allows those trust anchors to sign = TLSA
> records, any TLS client which accepts those TLSA records is subject to= MITM
> by the VPN server

And SSHFP.=C2=A0 And anything else that might be security-relevent (= all of
DNS, really).

Well, different parts of = DNS are differently security relevant. For instance,
the IP-addre= ss mapping usually isn't that big a deal because the network
= attacker can reroute you anyway.
This definitely merits a Sec= urity Considerations note even if this

]
<= /div>
property were actually the point of this protocol.

> 3. Even if enterprise doesn't intend to run a MITM proxy, this mea= ns that
> any compromise of the VPN server automatically makes it an MITM proxy = for
> the Internet as a whole, because the person who compromises it can sim= ply
> reconfigure it to advertise any domain of its choice as internal, as w= ell
> as the corresponding keys and TLSA records.

Sure, but it's not like clients will be choosing to connect to a= ny VPN
servers.=C2=A0 Generally the client must already have a trust anchor for th= e
SG to begin with.=C2=A0

Why? That trust anc= hor doesn't need to allow the creation of arbitrary
WebPKI ce= rts. All that is needed is to be able to authenticate the
VPN ser= ver itself.


Painting this as a security threat to the entire
Internet is going a bit too far.

Why?

-Ekr

--000000000000fbcf53056f03a977-- From nobody Tue Jun 19 12:48:49 2018 Return-Path: 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 5FB91130EC1; Tue, 19 Jun 2018 12:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 JEyF4LBMKQNC; Tue, 19 Jun 2018 12:48:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749F2130E6E; Tue, 19 Jun 2018 12:48:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419JRt0VKvzF8M; Tue, 19 Jun 2018 21:48:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529437722; bh=qQH+zPhe8QJXYU/rHBQSJtV8fRWrZn3/axX2d6wdiJw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Yho4Jubme2FdDHlqICbO+In7eJbUSlrBe7a3TpeW+tHI8GucH+8FV9aFZyO9ZyjAl VrBh3tqkURyf/8KURXlrCUC7VR9Zeo5DDBoduKPPKodDYeAbK3Efl/TqM/HLTyOe+b EFY3FB1egxtKaC49Hb6SmYp0a11BoCvTQoZykuKM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RRSHmO7fF5lB; Tue, 19 Jun 2018 21:48:40 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Jun 2018 21:48:39 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 869754FB769; Tue, 19 Jun 2018 15:48:38 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 869754FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7AB434023307; Tue, 19 Jun 2018 15:48:38 -0400 (EDT) Date: Tue, 19 Jun 2018 15:48:38 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:48:48 -0000 On Tue, 19 Jun 2018, Eric Rescorla wrote: > 1. In the current design, many clients (those whose enterprises have any significant number of domains) are just going to have to accept > whatever domains the VPN server claims should be treated as internal, and to accept the trust anchors the VPN server claims I don't agree clients have to accept anything. Currently, my iphone will prompt me with this when installing a VPN Profile: The network traffic of your iPhone may be secured, filtered, or monitored by a VPN server. It's easy for it to extend this with: The VPN profile is requesting to take control of the domain name(s) "redhat.com" Or if the VPN profile wouldn't constrain the DNS names, upon connecting to the VPN it could warn the user and store the decision: The VPN server is requesting to take control of the domain name(s) "redhat.com", "centos.org", "openstack.com". If it later wants to add "gmail.com", the phone could do the popup again, and hopefully the user would say no to that. In addition, the current CT requirements would block rogue attempts by the VPN server to take over domains not under its control, as a rogue enterprise certificate for "gmail.com "would not appear in any CT logs, and the browser would not be aware whether or not this domain would be a private or public view. > 2. Because the current design also allows those trust anchors to sign TLSA records, any TLS client which accepts those TLSA records is subject > to MITM by the VPN server Again, this is the feature, not the bug. We want to use TLSA records in the enterprise network. > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that any compromise of the VPN server automatically makes it an MITM > proxy for the Internet as a whole, because the person who compromises it can simply reconfigure it to advertise any domain of its choice as > internal, as well as the corresponding keys and TLSA records. If the server constrained itself in the VPN profile given to the client, it cannot modify this later on when there is a VPN server compromise. If the profile did not constrain itself, a popup could ask the user once the server requests to install trust anchors for new domains. CT would further prevent a compromised server from making up certificates for domains not under its control. If you wanted, you could add some new EKU or HSTS or other TLS mechanism marking a domain name as never appearing as an internal zone. > What, if any, of the above do you disagree with? The premise that enterprise deployments are a bug instead of a feature. The premise that this auto-configuration issue is more important than allowing DNSSEC to be used on internal-only domains and that it cannot be contained with local client policy. Compare this to the current webpki, where I don't even get notified by the browser when it adds/removes a webpki CA that can say anything about everything on the internet _at all_. It is fully blind trust and I don't have an enterprise trust relationship with them. Or compare it with openvpn, that allows the server to execute arbitraty commands on the client. There is no IETF protocol that allows for reconfiguration of trust anchors. If there was, we could have used that here. A VPN enterprise profile is a trust relationship. This draft tries to limit the amount of trust the client needs to have while ensuring that the DNS protocol still works as expected. That is why it does not support "." or "send everything over the VPN" deployments. I am happy to clarify text if that is not clear enough, but I think it is unreasonable to start talking about DNS filters or modifying DNS protocol behaviour other then the (re)configuration of specific mutually agreed DNS zones and trust anchors. Paul From nobody Tue Jun 19 13:01:04 2018 Return-Path: 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 C5E4F130EC6; Tue, 19 Jun 2018 13:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 EXBs4SCDkQU5; Tue, 19 Jun 2018 13:00:54 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E92F130ECD; Tue, 19 Jun 2018 13:00:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419Jjg3jW7zF8N; Tue, 19 Jun 2018 22:00:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529438439; bh=f0TdvRBMRD5zX/sMvEwn/onTdBdx0DCZX6s+D9E/jIQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FnrOeY1iBW0E6TeZ4/cCiocqh5Ten4qAYpX+R6ZhQCkagW1Ja+YSyfginkfHGO56R IJN97tEQka2OaPG4oWuqMFHJN/j3DZ/7vTuzKh3DKYzYSiSa1m1BsVDK5Ar5X3jn/1 TM+DBJqF3cxHanjIfV5+GgDi1kSGS4WS08P7mKpo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XHBFy0jc_2-H; Tue, 19 Jun 2018 22:00:38 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Jun 2018 22:00:37 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9567F4FB769; Tue, 19 Jun 2018 16:00:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9567F4FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8CD874023307; Tue, 19 Jun 2018 16:00:36 -0400 (EDT) Date: Tue, 19 Jun 2018 16:00:36 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: Nico Williams , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: Message-ID: References: <20180619183459.GC4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:00:56 -0000 On Tue, 19 Jun 2018, Eric Rescorla wrote: > The ID can say that, but as a practical matter, any enterprise that has > a reasonable number of internal domains is just going to tell people > to configure their client to accept any domain name. Which is the equivalent of an enterprise that requires you to accept the TLS middleware box and its additional webpki CAs. Except we made it more restrained to prevent abuse. > Sure, but it's not like clients will be choosing to connect to any VPN > servers.  Generally the client must already have a trust anchor for the > SG to begin with.  > > Why? That trust anchor doesn't need to allow the creation of arbitrary > WebPKI certs. It doesn't allow creation of _arbitrary_ webpki certs, only webpki certs under mutually agreed domain names. > All that is needed is to be able to authenticate the VPN server itself. This draft has nothing to do with authentication of the VPN server. That is all done in IKE, possibly with certificates, but nothing related to DNS whatsoever. This draft is about using a split-DNS setup where the VPN client can keep using its own validating DNSSEC capable recursive server, while allowing a cryptographic acception for mutually agreed enterprise domains while still supporting DNSSEC for those enterprise domains to protect against inside attackers. Paul From nobody Tue Jun 19 13:27:08 2018 Return-Path: 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 0EBCB130E18 for ; Tue, 19 Jun 2018 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] 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 iDUDZ1uvLU8s for ; Tue, 19 Jun 2018 13:27:05 -0700 (PDT) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 4DB1C130ECA for ; Tue, 19 Jun 2018 13:20:56 -0700 (PDT) Received: by mail-ot0-x242.google.com with SMTP id w9-v6so1151133otj.7 for ; Tue, 19 Jun 2018 13:20:56 -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=jMOUz8CcbqUDYee+HTjYLcjJl3LyqkIs9TB4C2vRzS0=; b=ZauJFhVDvWAbRMKPZSuOQ11YrQwtncmFAs06tXA9cmNecfxYts3EPzXtI7g3EumTTT zsADBc2/IYGELpnbYjuAf466cWbfOVQ2bjNbEeAutFwHfQdGJqvnJegy2mpShI5nKuoM a0DL9cxrVfSUITwLUgBTMuhhnuozuKELdaqMNdyeaR24LTElAg5Pb1FrnUNvcOTPaLPF WxMN/5zj3b73RzkBGiftfPJ9SUYKg3fkWBKk/d/l5epCvlCkBVmAcAmUE4SpzwghmkXU /eBebW0Oq5oVM3V6hRPVIICgkyQw0s2L+hPjBJVJidC/bY65Ii21yiHktKy17FFy6xhL 4FKA== 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=jMOUz8CcbqUDYee+HTjYLcjJl3LyqkIs9TB4C2vRzS0=; b=Ry8fNZyr10v9ZhIolemFukTOxTh7iHpbpHK51RuzDoiFt2HpfXUfkHNf/OfX35TQ2k lStLCCpOq/hwUPSNKxEiGnF3lQghQfKMhiUBCy/+1FpR6y/tECjZM48hQm0I3l4RhP+e 6bTQawQMImHIg3pgAHKNYYqVyYvwqLwkD8ZLMXoghT01AvVM+HR0Jqk9r/wkWgTwkDdr TrWvIWVzCntxLbRFbe2OeL9ZS5CPYmWJ7RE2R1ldgA5G+Lg1H4zyWx9fqFypGN/XxtuN dv5l6b3uPeYL8yXMEOtl10l754ZfcFyUDWyges8PD4QEtBv0qb0659BjEeNj5/Hd7V5h EckA== X-Gm-Message-State: APt69E2caqHa8/MiiKkFVEg/p3tHG2mVRuHe+ASM1yyca8qm2OSeyR4d u1ryhlP9ge8tNL2j6MWM3LHkG3jjIv3mjDk3JclkckAYLAEb6w== X-Google-Smtp-Source: ADUXVKJwL0noabfB9lMxGeBQ6n6bGL9MvQ7/wKOcx/CBlKq7dNKuI8eEZtkDwE56168CNImXZYyBJ086PD3nnARAdbg= X-Received: by 2002:a9d:5912:: with SMTP id t18-v6mr11715238oth.217.1529439655687; Tue, 19 Jun 2018 13:20:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 13:20:15 -0700 (PDT) In-Reply-To: References: <20180619183459.GC4218@localhost> From: Eric Rescorla Date: Tue, 19 Jun 2018 13:20:15 -0700 Message-ID: To: Paul Wouters Cc: Nico Williams , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="00000000000062070b056f046bbd" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 20:27:07 -0000 --00000000000062070b056f046bbd Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 1:00 PM, Paul Wouters wrote: > On Tue, 19 Jun 2018, Eric Rescorla wrote: > > The ID can say that, but as a practical matter, any enterprise that has >> a reasonable number of internal domains is just going to tell people >> to configure their client to accept any domain name. >> > > Which is the equivalent of an enterprise that requires you to accept the > TLS middleware box and its additional webpki CAs. Except we made it more > restrained to prevent abuse. > I'd prefer to establish the facts of the matter before we debate what ought to happen. My contention here is that as a practical matter, many clients will be required to accept any domain name that the VPN server asserts is internal. As far as I can tell, this is what the document itself says: 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. What am I misunderstanding? All that is needed is to be able to authenticate the VPN server itself. >> > > This draft has nothing to do with authentication of the VPN server. That > is all done in IKE, possibly with certificates, but nothing related to > DNS whatsoever. This draft is about using a split-DNS setup where the > VPN client can keep using its own validating DNSSEC capable recursive > server, while allowing a cryptographic acception for mutually agreed > enterprise domains while still supporting DNSSEC for those enterprise > domains to protect against inside attackers. > Yes, I appreciate that point. I was responding to Nico's comment that "Generally the client must already have a trust anchor for the SG to begin with. " And it's not correct that in order to have a VPN gateway, you need to give it a full TA. -Ekr --00000000000062070b056f046bbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 1:00 PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 19 Jun 2018, Eric Rescorla wrote:

The ID can say that, but as a practical matter, any enterprise that has
a reasonable number of internal domains is just going to tell people
to configure their client to accept any domain name.

 Which is the equivalent of an enterprise that requires you to accept the TLS middleware box and its additional webpki CAs. Except we made it more restrained to prevent abuse.
=

I'd prefer to establish the facts of the matter bef= ore we debate what
ought to happen.

My contention here is that as a practical matter, many clients will be req= uired
to accept any domain name that the VPN server asserts is in= ternal. As far
as I can tell, this is what the document itself sa= ys:

=C2=A0=C2=A0 In most deployment scenario's= , the IKE client has an expectation that
=C2=A0=C2=A0 it is connecting, = using a split-network setup, to a specific
=C2=A0=C2=A0 organisation or = enterprise.=C2=A0 A recommended policy would be to only
=C2=A0=C2=A0 acc= ept INTERNAL_DNSSEC_TA directives from that organization's DNS
=C2= =A0=C2=A0 names.=C2=A0 However, this might not be possible in all deploymen= t
=C2=A0=C2=A0 scenarios, such as one where the IKE server is handing ou= t a number
=C2=A0=C2=A0 of domains that are not within one parent domain= .

What am I misunderstanding?


=
All that is needed is to be able to authenticate the VPN server itself.

 This draft has nothing to do with authentication of the VPN server. That is all done in IKE, possibly with certificates, but nothing related to
DNS whatsoever. This draft is about using a split-DNS setup where the
VPN client can keep using its own validating DNSSEC capable recursive
server, while allowing a cryptographic acception for mutually agreed
enterprise domains while still supporting DNSSEC for those enterprise
domains to protect against inside attackers.

Ye= s, I appreciate that point. I was responding to Nico's comment that
"Generally the client must already hav= e a trust anchor for the
SG to begin with. " And it's not correct that in order to h= ave a VPN
gateway, you need to give it a full TA.

<= /div>
-Ekr

--00000000000062070b056f046bbd-- From nobody Tue Jun 19 15:46:59 2018 Return-Path: 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 BCB9A130FCD; Tue, 19 Jun 2018 15:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 z1nXdLCRsg1y; Tue, 19 Jun 2018 15:46:56 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000F4130FD4; Tue, 19 Jun 2018 15:46:55 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 44C9130002BA9; Tue, 19 Jun 2018 15:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=EZTl1MWU58qO4u vAYIrBGFmY2u4=; b=rZU4oQiCA15lR/VvuRAnS7D+vnh9Zr2vnApIz1EcNdX2jf y0gzZW3xVm94PfF2YNAwFi/ol3vn4CJsxBobqorowkYrXXRPV4l5VUKn7QrSSeLP F6F6cZUQbNpQcIamCrWi3KQIb9PRazrBer+AjjOgT7Oj6WzqOLXlnjLMZzT04= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id B1C9A30002BA8; Tue, 19 Jun 2018 15:46:54 -0700 (PDT) Date: Tue, 19 Jun 2018 17:46:52 -0500 From: Nico Williams To: Eric Rescorla Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619224651.GD4218@localhost> References: <20180619183459.GC4218@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:46:58 -0000 On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote: > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams > wrote: > > The I-D should say that clients MUST allow local configuration of what > > domains to accept trust anchors for, and SHOULD allow local policy to > > list . as a domain for which to accept trust anchors. > > > > This local configuration should be per-SG. > > > > The ID can say that, but as a practical matter, any enterprise that has > a reasonable number of internal domains is just going to tell people > to configure their client to accept any domain name. And what's the problem with that? If it's your own device you might balk, so get your employer to provide you with theirs. Or just accept it as part of the employment deal. The I-D should have Security Considerations text about it and that's that. > > 2. Because the current design also allows those trust anchors to sign TLSA > > > records, any TLS client which accepts those TLSA records is > > > subject to MITM by the VPN server > > > > And SSHFP. And anything else that might be security-relevent (all > > of DNS, really). > > Well, different parts of DNS are differently security relevant. For > instance, the IP-address mapping usually isn't that big a deal because > the network attacker can reroute you anyway. This definitely merits a > Security Considerations note even if this > > property were actually the point of this protocol. Yes, a Security Considerations note should be a) required, b) sufficient. > > > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that > > > any compromise of the VPN server automatically makes it an MITM proxy for > > > the Internet as a whole, because the person who compromises it can simply > > > reconfigure it to advertise any domain of its choice as internal, as well > > > as the corresponding keys and TLSA records. > > > > Sure, but it's not like clients will be choosing to connect to any VPN > > servers. Generally the client must already have a trust anchor for the > > SG to begin with. > > Why? That trust anchor doesn't need to allow the creation of arbitrary > WebPKI certs. All that is needed is to be able to authenticate the > VPN server itself. Why on Earth would I connect to some random SG I don't know? > > Painting this as a security threat to the entire > > Internet is going a bit too far. > > Why? Because my VPN clients don't connect promiscuously. I can't say no promiscuous VPN clients exist, but I imagine that none do. And any promiscuous VPN clients get what they deserve. Nico -- From nobody Tue Jun 19 15:52:43 2018 Return-Path: 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 B7FEE130FCD for ; Tue, 19 Jun 2018 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] 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 uv9oLEvMcGfj for ; Tue, 19 Jun 2018 15:52:36 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (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 C90CE130FA6 for ; Tue, 19 Jun 2018 15:52:36 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id q17-v6so1598527otg.2 for ; Tue, 19 Jun 2018 15:52:36 -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=Q5E0JtkLE3OutxmwP0p6q4cN7/IfB8JdYsHQX3GgQRU=; b=imMc62JHNoj494IDub+vwqIdCr6eFpjs1c74DwDpWvh0ITr98/7YfPvPjja3wTPP/e mz+/mWj2eGl7cOzhk6wIc2w41APUyKw0epDuejXFd25myv5Wb7sSfDs0ISKXfYFC7YiW c8bIr/ary6hO5Su3J0DmsdPkoqSm9uyFy/SxOf++LZGjNPgYRXxLfolfZ8ald3SVXrru qDnfAzX/JZBJOvYBpIMeT7vSw35cdiydPFVN+10YntOThfHLvOnLEHd28GgMwm8Ul+n/ JPl9w8lVyYOM/H9IrdvOhqyGigwwvtxWuT2Yy4tHMa0ATGpG2jUpp3IpL8CAprn6/hF3 XT4A== 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=Q5E0JtkLE3OutxmwP0p6q4cN7/IfB8JdYsHQX3GgQRU=; b=uBy/zyDkkGqxWoZLrC15c1y4bXqpmtI21PmfNDnMnvaTpc0qpSCU/LsSjyzc7hKX4t VPpoJR5p+4Ll0hIriuU+U8kmuMUICMAvhR7KLlfTM1QeGsDBvY6ChCb3kcGSv1lBa7Wy VA0ffFSJ8kklm+OEwcgnBWf/tFGZcjJtjtfESX2ZEwelWrI4JaKMxGUoolq/hPdz2UNf AEzvEXjRsnRJYObQ2SjZQ9Tp1qIUc0pWLjddQpITcHdHesCmzxVMAOVoY0nU4HZhZWco TeZEEVNGgQU8IC1k0QfwnyX3knczw+HgzS5fB0zFEeoOb33ph7hV1/+gjO2zKMZNqgUK EgnQ== X-Gm-Message-State: APt69E0ccbH4UlYdKC9IAj1UGNu0xioZAFYGKqzq/7x3Ous/veV1+FH+ 6QOHT5W9f0t8eIJg7wtU6Ij02Y5PAgK5NFaUykhKH9Oi X-Google-Smtp-Source: ADUXVKLKBH4r++eJAD0jW/vXjdZZUQn7Z+CH8Yd9DxZhiZ8j0P9VGmdl9i0lDUwGtE3O7r9odp/qliVR+JR5ihgJw3E= X-Received: by 2002:a9d:55d0:: with SMTP id z16-v6mr12339695oti.176.1529448756151; Tue, 19 Jun 2018 15:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 15:51:55 -0700 (PDT) In-Reply-To: <20180619224651.GD4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> From: Eric Rescorla Date: Tue, 19 Jun 2018 15:51:55 -0700 Message-ID: To: Nico Williams Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000d01713056f0689ed" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 22:52:41 -0000 --000000000000d01713056f0689ed Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams wrote: > On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote: > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams > > wrote: > > > The I-D should say that clients MUST allow local configuration of what > > > domains to accept trust anchors for, and SHOULD allow local policy to > > > list . as a domain for which to accept trust anchors. > > > > > > This local configuration should be per-SG. > > > > > > > The ID can say that, but as a practical matter, any enterprise that has > > a reasonable number of internal domains is just going to tell people > > to configure their client to accept any domain name. > > And what's the problem with that? > > If it's your own device you might balk, so get your employer to provide > you with theirs. Or just accept it as part of the employment deal. > Again, right now I'm just trying to establish the facts of the matter. Do you agree this is going to be a common scenario? -Ekr --000000000000d01713056f0689ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote:
> On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > The I-D should say that clients MUST allo= w local configuration of what
> > domains to accept trust anchors for, and SHOULD allow local polic= y to
> > list . as a domain for which to accept trust anchors.
> >
> > This local configuration should be per-SG.
> >
>
> The ID can say that, but as a practical matter, any enterprise that ha= s
> a reasonable number of internal domains is just going to tell people > to configure their client to accept any domain name.

And what's the problem with that?

If it's your own device you might balk, so get your employer to provide=
you with theirs.=C2=A0 Or just accept it as part of the employment deal.

Again, right now I'm just trying to e= stablish the facts of the matter. Do you agree
this is going to b= e a common scenario?

-Ekr


--000000000000d01713056f0689ed-- From nobody Tue Jun 19 16:01:57 2018 Return-Path: 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 AE72D130E40; Tue, 19 Jun 2018 16:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 HUwbD-uSl6sr; Tue, 19 Jun 2018 16:01:53 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB6A130E35; Tue, 19 Jun 2018 16:01:53 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 8F5F830002BA8; Tue, 19 Jun 2018 16:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Fx5t8wh8e41ZuE jlpizLDjK5bu8=; b=oRukGID5nFVPo/u6EzpezdHMtr4GG3trI1P0MvJ/UkWEGF 3WAxQiUBQ2B1Tr56an6pH8mRqG6tvFY49JN8BhhOl3KoPQ/qhgV+N+B8IMKmcQ08 hV8Su5iWHlqVi9OUVUSqHe2Sf392/NaJgvqf2jkBDl15M8J+GQFDVpl1Qgi0g= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 025FE30002B9D; Tue, 19 Jun 2018 16:01:51 -0700 (PDT) Date: Tue, 19 Jun 2018 18:01:50 -0500 From: Nico Williams To: Eric Rescorla Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619230148.GE4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:01:56 -0000 On Tue, Jun 19, 2018 at 03:51:55PM -0700, Eric Rescorla wrote: > On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams wrote: > > On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote: > > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams wrote: > > > > The I-D should say that clients MUST allow local configuration of what > > > > domains to accept trust anchors for, and SHOULD allow local policy to > > > > list . as a domain for which to accept trust anchors. > > > > > > The ID can say that, but as a practical matter, any enterprise that has > > > a reasonable number of internal domains is just going to tell people > > > to configure their client to accept any domain name. > > > > And what's the problem with that? > > > > If it's your own device you might balk, so get your employer to provide > > you with theirs. Or just accept it as part of the employment deal. > > Again, right now I'm just trying to establish the facts of the matter. > Do you agree this is going to be a common scenario? I don't know what the antecedent of "this" in your question. If you mean that BYODs will have to accept policies users don't want, well, that's pretty much true anyways (e.g., you have to accept proxy configurations that can and _will_ MITM you). For public VPNs (that the user pays for) the user will want the client to accept TAs for no domain. For private VPNs the user will generally not really have a choice. I don't think there's a question of what is a common scenario, but of what the I-D should say. It should say that with these TAs the SG can MITM DNSSEC and DNSSEC-based security technologies like DANE, and it should say that clients MUST be able to configure a list of domains for which they'll accept TAs. And that should be sufficient to handle your concern. Are you objecting to the I-D altogether -- objecting to the feature it adds -- or asking what the I-D should say about your concern? Objecting to enterprise features would be fair, though I don't think the IETF rejects enterprise features, nor should it. Nico -- From nobody Tue Jun 19 16:12:00 2018 Return-Path: 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 4B325130FF9 for ; Tue, 19 Jun 2018 16:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, URIBL_BLOCKED=0.001] 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 qd-1LYEbaYcK for ; Tue, 19 Jun 2018 16:11:55 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 18F06130FF5 for ; Tue, 19 Jun 2018 16:11:55 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id 14-v6so1339558oie.3 for ; Tue, 19 Jun 2018 16:11:55 -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=pHZUiM6gkAwF2YV7reDec+Jq1DR895YPQx52UZg+8FQ=; b=jLrLntAZPq35go/jj+qb8jswTK4yo5dm7Gz/yZxbpoUBqTonzY/J455yvDV4/RYmQd IzawmYI6frixfj/H2jptnnSiOxtIEUkF+tAkTChBK7BDkRlD+n/6emRjY6V+vZeMa62/ EozJXI/U/MtlfhH8GppBhw/pBGnTc6xzH0XCs7txPxgal52IEN/cVfEQBab7/I6b0SsH HKKJDdMiQBdeHH5DyHvHkvnvKnCOFTF3PvHYpVQN5CqTq9wi4sgzDCJ8mHqBxolv3Imp 7th79/JqfGQKgvhOK+2Qecwv97Ngee4EnczeVDm83l8BRfON3su7Q9BgLqGIjAcadkOr +XGw== 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=pHZUiM6gkAwF2YV7reDec+Jq1DR895YPQx52UZg+8FQ=; b=LZ8RuEs01/+11EzwskzsYqOdXkQZRNpepcyzKLh6aZa/AT1LbcoHmTFm39OSFBdAH1 HETBPx4/W3WmghHj6dGfk+79tY9qqLtAHAR3Fzkm1mzhF6ncBn+axz7hM/fQPlUEdiD5 MCqf+spi6y9Nzau7mcR0cATFZSAujyTqN90ZKGotXkz2h3uKD/kVe/LT3HrpTOFw1MpJ eqG4uTLXxNMekZ1E/cqKvpFQ4OnS4IYjAhQEGv9knZNCUghYtVA+TWoPnrJnfTojtjEW NoGxscuojsI8hmjycG+yieATFci5g0LqfBPlaRGsV658I6C/AvfmN625XeVI0xPP8sBc ZSCQ== X-Gm-Message-State: APt69E2MltUTY4K1PzHNIcP2OoEUbEEW7eE8hhGrOrS35IVSenmTgmMk 3mizjCktnd36y7YJ472K7NDTdm6LZGlRMHU11/RZCw== X-Google-Smtp-Source: ADUXVKJjnNU40KaZtqplpKlBwgMzNHadvapjBHPyFdqGDHm/mKc81boNosziBdYPnm87rbh+x1fLjcHWjaXa0e/yFQY= X-Received: by 2002:aca:e2d3:: with SMTP id z202-v6mr8562397oig.262.1529449914298; Tue, 19 Jun 2018 16:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 16:11:13 -0700 (PDT) In-Reply-To: <20180619230148.GE4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> From: Eric Rescorla Date: Tue, 19 Jun 2018 16:11:13 -0700 Message-ID: To: Nico Williams Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000d80b52056f06ce1e" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:11:59 -0000 --000000000000d80b52056f06ce1e Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 4:01 PM, Nico Williams wrote: > On Tue, Jun 19, 2018 at 03:51:55PM -0700, Eric Rescorla wrote: > > On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams > wrote: > > > On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote: > > > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams < > nico@cryptonector.com> wrote: > > > > > The I-D should say that clients MUST allow local configuration of > what > > > > > domains to accept trust anchors for, and SHOULD allow local policy > to > > > > > list . as a domain for which to accept trust anchors. > > > > > > > > The ID can say that, but as a practical matter, any enterprise that > has > > > > a reasonable number of internal domains is just going to tell people > > > > to configure their client to accept any domain name. > > > > > > And what's the problem with that? > > > > > > If it's your own device you might balk, so get your employer to provide > > > you with theirs. Or just accept it as part of the employment deal. > > > > Again, right now I'm just trying to establish the facts of the matter. > > Do you agree this is going to be a common scenario? > > I don't know what the antecedent of "this" in your question. If you > mean that BYODs will have to accept policies users don't want, well, > that's pretty much true anyways (e.g., you have to accept proxy > configurations that can and _will_ MITM you). > I'm asking if a common scenario will be that users of enterprise VPNs who implement this feature will end up in a situation where the VPN can impose TAs for any domain. As a followup question, I claim that that's not presently true with existing VPNs. In some cases, the VPN requires you to install a new trust anchor in order to accept its cert, but that's not an inherently necessary practice. Separately, an enterprise may require you to accept an MITM cert, but these are conceptually distinct. Do you disagree with that? Are you objecting to the I-D altogether -- objecting to the feature it > adds -- or asking what the I-D should say about your concern? > Again, right now I'm trying to establish the facts of the matter. I'd prefer to do that prior to discussing what is good or bad. -Ekr --000000000000d80b52056f06ce1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 4:01 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Tue, J= un 19, 2018 at 03:51:55PM -0700, Eric Rescorla wrote:
> On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams <nico@cryptonector.com> wrote= :
> > On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote: > > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <nico@cryptonector.com> wrote:
> > > > The I-D should say that clients MUST allow local config= uration of what
> > > > domains to accept trust anchors for, and SHOULD allow l= ocal policy to
> > > > list . as a domain for which to accept trust anchors. > > >
> > > The ID can say that, but as a practical matter,= any enterprise that has
> > > a reasonable number of internal domains is just going to tel= l people
> > > to configure their client to accept any domain name.
> >
> > And what's the problem with that?
> >
> > If it's your own device you might balk, so get your employer = to provide
> > you with theirs.=C2=A0 Or just accept it as part of the employmen= t deal.
>
> Again, right now I'm just trying to establish the facts of the mat= ter.
> Do you agree this is going to be a common scenario?

I don't know what the antecedent of "this" in your que= stion.=C2=A0 If you
mean that BYODs will have to accept policies users don't want, well, that's pretty much true anyways (e.g., you have to accept proxy
configurations that can and _will_ MITM you).

I'm asking if a common scenario will be that users of enterprise=
VPNs who implement this feature will end up in a situation where= the
VPN can impose TAs for any domain.

= As a followup question, I claim that that's not presently true with
existing VPNs. In some cases, the VPN requires you to install
<= div>a new trust anchor in order to accept its cert, but that's not an
inherently necessary practice. Separately, an enterprise may
=
require you to accept an MITM cert, but these are conceptually
distinct. Do you disagree with that?


Are you objecting to the I-D altogether -- objecting to the feature it
adds -- or asking what the I-D should say about your concern?

Again, right now I'm trying to establish the fac= ts of the matter. I'd prefer
to do that prior to discussing w= hat is good or bad.

-Ekr

=

--000000000000d80b52056f06ce1e-- From nobody Tue Jun 19 16:31:41 2018 Return-Path: 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 25E11130E4B; Tue, 19 Jun 2018 16:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 XlysoBMCpRmJ; Tue, 19 Jun 2018 16:31:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA0C130FF5; Tue, 19 Jun 2018 16:31:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419PNx67KTzB0t; Wed, 20 Jun 2018 01:31:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529451089; bh=Xq59EqcrYl3m2ncSEcFUGDcMx/VwtDY/9Ur2xeejaZI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=j28SyZb/S7h8KtV+m7N/ti71JXwGjYEyrT0RdcuUoJJSoq8tq1kjR7eqO7O1t5uuo zxfJfOV2w52S11OFEy9o1RQOGe2nAnSBMNfTGhRVB8xUWqi3Mci/t3k3r2Z6hW0hvb BjovpMqhqAEHqIeoPz6VMsxtIeGOdH4H+LxSn+h4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id IZGsJA5cJqpH; Wed, 20 Jun 2018 01:31:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 01:31:25 +0200 (CEST) Received: from [193.111.228.72] (unknown [193.111.228.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id A9A5D4FB769; Tue, 19 Jun 2018 19:31:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A9A5D4FB769 Content-Type: multipart/alternative; boundary=Apple-Mail-B1F72DC1-A1BD-4E9C-B731-AB4615A8A547 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15F79) In-Reply-To: <20180619224651.GD4218@localhost> Date: Tue, 19 Jun 2018 19:31:24 -0400 Cc: Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Transfer-Encoding: 7bit Message-Id: <3D85F03B-5D1B-4E74-AFA4-FF9419418FE5@nohats.ca> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> To: Nico Williams Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:31:39 -0000 --Apple-Mail-B1F72DC1-A1BD-4E9C-B731-AB4615A8A547 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 19, 2018, at 18:46, Nico Williams wrote: >=20 >=20 > Because my VPN clients don't connect promiscuously. I can't say no > promiscuous VPN clients exist, but I imagine that none do. And any > promiscuous VPN clients get what they deserve. Opportunistic IPsec exists and are =E2=80=9Cpromiscuously=E2=80=9D. And the d= raft opens the Security Considerations section with: The use of Split DNS configurations assigned by an IKEv2 responder is predic= ated on the trust established during IKE SA authentication. However, if IKEv= 2 is being negotiated with an anonymous or unknown endpoint (such as for Opportunistic Security [RFC7435]), the initiator MUST i= gnore Split DNS configurations assigned by the responder. Paul --Apple-Mail-B1F72DC1-A1BD-4E9C-B731-AB4615A8A547 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jun 19, 201= 8, at 18:46, Nico Williams <nico= @cryptonector.com> wrote:


Because my VPN clients don't connect promiscuously.  I c= an't say no
promiscuous VPN clients exist, but I imagine tha= t none do.  And any
promiscuous VPN clients get what th= ey deserve.

Opportunistic I= Psec exists and are =E2=80=9Cpromiscuously=E2=80=9D. And the draft opens the Security Consider= ations section with:

 The use of Split DNS configurations assigned by an IKEv=
2 responder is
   predicated on the trust established during IKE SA authentication.
   However, if IKEv2 is being negotiated with an anonymous or unknown=

endpoint (such as for Opportunistic Secu=
rity [RFC7435]), the
   initiator MUST ignore Split DNS configurations assigned by the
   responder.

Paul


= --Apple-Mail-B1F72DC1-A1BD-4E9C-B731-AB4615A8A547-- From nobody Tue Jun 19 16:42:06 2018 Return-Path: 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 A488A1311CB; Tue, 19 Jun 2018 16:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 YzEyFloBi8Me; Tue, 19 Jun 2018 16:41:58 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A461311EA; Tue, 19 Jun 2018 16:41:56 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 9D0CE30002BAC; Tue, 19 Jun 2018 16:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=JmgLtOKBSgdZsA QRJyBHJdcEyMQ=; b=D4bQifgsIShtpT490P2JOpO6nso1zxghCWj7HJMm7XAOys jzhLzLkgksuvKufZbIvqm8o/E3wBJh/CueY5t7EfVNYpD0zmpkIs2t0mj0beF7ei lZAKRrYZy5Q7IWXRazcRc+Xs/Vgt16dO4EyaPnxwASLgTPP9ZXSjJbzn2RQeE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 24B9130002BA9; Tue, 19 Jun 2018 16:41:55 -0700 (PDT) Date: Tue, 19 Jun 2018 18:41:53 -0500 From: Nico Williams To: Eric Rescorla Cc: Paul Wouters , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619234151.GF4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:42:05 -0000 On Tue, Jun 19, 2018 at 04:11:13PM -0700, Eric Rescorla wrote: > On Tue, Jun 19, 2018 at 4:01 PM, Nico Williams > wrote: > > I don't know what the antecedent of "this" in your question. If you > > mean that BYODs will have to accept policies users don't want, well, > > that's pretty much true anyways (e.g., you have to accept proxy > > configurations that can and _will_ MITM you). > > I'm asking if a common scenario will be that users of enterprise > VPNs who implement this feature will end up in a situation where the > VPN can impose TAs for any domain. I think that will be (and probably already is) common in enterprises, but not for public VPNs. > As a followup question, I claim that that's not presently true with > existing VPNs. In some cases, the VPN requires you to install > a new trust anchor in order to accept its cert, but that's not an > inherently necessary practice. Separately, an enterprise may > require you to accept an MITM cert, but these are conceptually > distinct. Do you disagree with that? Requiring that the client accept arbitrary trust anchors in this protocol is "not an inherently necessary practice" practice either. Do you disagree? The protocol's purpose is to enable split-dns, not to enable MITM for all domains, though it does also do the latter if the client accepts it. > > Are you objecting to the I-D altogether -- objecting to the feature it > > adds -- or asking what the I-D should say about your concern? > > Again, right now I'm trying to establish the facts of the matter. I'd > prefer to do that prior to discussing what is good or bad. My prediction of which configurations will be common is hardly a fact :) From nobody Tue Jun 19 16:42:54 2018 Return-Path: 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 E9120130FDE; Tue, 19 Jun 2018 16:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 vTXWgtbQvBIV; Tue, 19 Jun 2018 16:42:50 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8893C130E4F; Tue, 19 Jun 2018 16:42:50 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 4C9FD30002BA9; Tue, 19 Jun 2018 16:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=KQzzrQOAf/VNsJB8l6F2HoVhm8k=; b=RiQPWRdJLnn F0vMCzFSb5sHEMNPKliNuCMAEL8Kcaipsf8YyShxVE8c39zNGVtToTgq5KcMhpl8 J/0JP26dLEHVdAY5pUw/p+PrJHUKQq9ufo5JQnuD9wvyYeDjqoChyw5CHmsdGHMe u/f5St2GZZHzhzZ7I67CdUvE2TMLAPoY= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id B69F230002BA8; Tue, 19 Jun 2018 16:42:49 -0700 (PDT) Date: Tue, 19 Jun 2018 18:42:47 -0500 From: Nico Williams To: Paul Wouters Cc: Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180619234247.GG4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <3D85F03B-5D1B-4E74-AFA4-FF9419418FE5@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3D85F03B-5D1B-4E74-AFA4-FF9419418FE5@nohats.ca> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:42:53 -0000 On Tue, Jun 19, 2018 at 07:31:24PM -0400, Paul Wouters wrote: > > On Jun 19, 2018, at 18:46, Nico Williams wrot= e: > >=20 > >=20 > > Because my VPN clients don't connect promiscuously. I can't say no > > promiscuous VPN clients exist, but I imagine that none do. And any > > promiscuous VPN clients get what they deserve. >=20 > Opportunistic IPsec exists and are =E2=80=9Cpromiscuously=E2=80=9D. And= the draft > opens the Security Considerations section with: But is it opportunistic VPN? Regardless, that's fair enough. From nobody Tue Jun 19 21:38:33 2018 Return-Path: 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 8440E130EBA; Tue, 19 Jun 2018 21:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 BjeO3UBsrR_R; Tue, 19 Jun 2018 21:38:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614F1130EA1; Tue, 19 Jun 2018 21:38:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419XC425mbz1rR; Wed, 20 Jun 2018 06:38:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529469504; bh=U/gQv2FLM2Pkcp2gSqUTjM1UX1p3N3LI3UKAUpWxRRI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZCc3/G0o1dzzv8b/tHcjwMVYGVFPY81VSg2jckFbWUDZR1ylOEf2jXFkgBfS2Qcru hSD6kePEOd62DLJ9+P3JrqQgc44PaUE5h0Ps7Yd203/a4l+GvZvLLAYqZaym/eJK1Z pEv9ZtvKTjoYvveh+qDgPomkEUtOh/j46Ts+yT/0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KScRue7nWyLV; Wed, 20 Jun 2018 06:38:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 06:38:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 92C1F4FB769; Wed, 20 Jun 2018 00:38:20 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 92C1F4FB769 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8C41E4023307; Wed, 20 Jun 2018 00:38:20 -0400 (EDT) Date: Wed, 20 Jun 2018 00:38:20 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: Nico Williams , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: Message-ID: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 04:38:31 -0000 On Tue, 19 Jun 2018, Eric Rescorla wrote: > I'm asking if a common scenario will be that users of enterprise > VPNs who implement this feature will end up in a situation where the > VPN can impose TAs for any domain. I explained before that I think "for any domain" can be strictly limited on the client side, either by preconfiguration or by confirmation on the VPN client side. In IKEv1, the XAUTH attribute relaying the domain name typically only appears once. When checking the Cisco documentation, I see: domain name Example: Router (config-isakmp-group)# domain cisco.com Specifies the Domain Name Service (DNS) domain to which a group belongs. This does not suggest that there can be more than one. So my educated guess here is that implementations in IKEv1 typically did not support setting more the one domain name (we only support sending and receiving one). Note that the _use_ of the domain name attribute in IKEv1 is a bit unclear. Is it to be used only for resolv.conf style search lists, or was it to constrain the domain(s) that should be looked up with the supplied nameserver IPs? Again speaking for our implementation, if we detect a local DNS server running, we use the domain name and the obtained nameserver IPs to reconfigure the DNS server to add a forward for only this domain name via these nameserver IPs. If we did not find a local DNS server running we will add the domain to the search option in /etc/resolv.conf and prepend the nameserver IPs to /etc/resolv.conf. (and on termination of VPN, we restore the old resolv.conf) So I think most Enterprise configurations will only use one domain, but most likely still expect the client to give them all DNS traffic so they can just take over or make up any domains they want. With more validating (stub) resolvers on devices, this will become more problematic over time, and I suspect these networks will have to consolidate things under their own internal domain. Because even if the VPN will allow multiple domains via this draft, wifi and LAN connections don't support this. > As a followup question, I claim that that's not presently true with > existing VPNs. In some cases, the VPN requires you to install > a new trust anchor in order to accept its cert, but that's not an > inherently necessary practice. Note that the VPN server authentication is not under discussion here at all. I'm not sure why you keep bringing this up. You almost certainly will need to install some local webpki trust anchor to make use of your internal TLS servers reachable via the IPsec VPN. For example, to reach any of our internal redhat servers over HTTPS, I need to install a redhat internal CA into my system/browser. I believe this is extremely common (although I do hope it is less common to give these internal CA's the CN="Certificate Authority") Paul From nobody Tue Jun 19 22:23:25 2018 Return-Path: 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 368AE131032 for ; Tue, 19 Jun 2018 22:23:23 -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 o4q2JnSIf_XF for ; Tue, 19 Jun 2018 22:23:20 -0700 (PDT) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 B38AC13103F for ; Tue, 19 Jun 2018 22:23:20 -0700 (PDT) Received: by mail-ot0-x244.google.com with SMTP id p95-v6so2348858ota.5 for ; Tue, 19 Jun 2018 22:23:20 -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=eBLdzwzBi0kK0pMH+Bv5JNwje3c10cc4qnqQZnHoAPM=; b=qlsNrb6Zcbry4dVg1PEvRyisi9suh0BmoqU1A3SfPtBzcYq6VbrWrShoi6Ef6r9ijB ItTrS7XDv9Tt4k0M8Revn2VIebXWJQXF3aOOxoVvqye/ikeHbIyJqJmWFAGeaAsmZ9w8 AaDnGm/GtRBKsWQy6Lh44D8HnR6PZbmQ5XPmRX66SPc4qfdUc5otNatx3PGAqXrxkKah q+l08XRJqHSboI/BnLoRxaoa6Nz9loQMRzSWkd6KwQ2t8OOMK0lB6tdO2UXrSqLXXZLS ZlH1bgmXqjDDV8T2fL/bTz3j+DG/riSuCdchsgiIkQGAGc6EtVR4RG98AuYgyWkjM/Pw WYWA== 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=eBLdzwzBi0kK0pMH+Bv5JNwje3c10cc4qnqQZnHoAPM=; b=hkyQJrRR5nH7CM+iNyttOkMBCXs61jzOypPabJcEHYstxWE6leANAw+gPEhHxCgtV/ slrzZ+cfPirZfWrdiOOiwjZ5K1THOXPBa/FM+YyTaoEz3zJFsBKsxG2NUNsuKs+i2Ajb TEAHef3w/6j2DNdOIe2Tux/4L9l/+Rx4vy+pyOVEkOcOG5v866Y8zpyv16BrbVmJ86ci UdQcAzrdlRa+LqucML/Lh8rwL8/EgiVZG3oLOCMSCMr1OM6JF/z9PxFfn2JaI8/az2Rv Y1ij9toF1eqURXvK6EtjWkq5KmyhLz5xifbnPn6nVmP1TYEFyvdB1MCJJfKo4GdDuYPI S+Xw== X-Gm-Message-State: APt69E0Cl5eD5Mip74L+eyt1D7AAjI6vyriW1ltx6SdNm1WqcxazjIXy j+RGuFSVm5ywQU2v9+vj70XA60s5D01dAER++N/gQ8o23tPlWA== X-Google-Smtp-Source: ADUXVKKf+H0dijawy5GNy8XiXgKkNB0Bz2ue2F/4MUQ0Lmq8ToZ2jYvQImdmJDoApOCX8axAiRwCT5J65KS7foDVUFo= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr13016871otb.371.1529472200104; Tue, 19 Jun 2018 22:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:3a8a:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 22:22:39 -0700 (PDT) In-Reply-To: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> From: Eric Rescorla Date: Tue, 19 Jun 2018 22:22:39 -0700 Message-ID: To: Paul Wouters Cc: Nico Williams , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="0000000000002e77a0056f0bff89" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 05:23:24 -0000 --0000000000002e77a0056f0bff89 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 19, 2018 at 9:38 PM, Paul Wouters wrote: > On Tue, 19 Jun 2018, Eric Rescorla wrote: > > I'm asking if a common scenario will be that users of enterprise >> VPNs who implement this feature will end up in a situation where the >> VPN can impose TAs for any domain. >> > > I explained before that I think "for any domain" can be strictly limited > on the client side, either by preconfiguration or by confirmation on the > VPN client side. > Yes, that's technically true, but the question is whether it's in fact practical for people to do that. I'm sorry to repeat myself, but once again the document clearly states that this can happen: 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". -Ekr --0000000000002e77a0056f0bff89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 19, 2018 at 9:38 PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 19 Jun 2018, Eric Rescorla wrote:

I'm asking if a common scenario will be that users of enterprise
VPNs who implement this feature will end up in a situation where the
VPN can impose TAs for any domain.

 I explained before that I think "for any domain" can be strictly = limited
on the client side, either by preconfiguration or by confirmation on the VPN client side.

Yes, that's techni= cally true, but the question is whether it's in fact
practica= l for people to do that. I'm sorry to repeat myself, but once
again the document clearly states that this can happen:

=C2=A0=C2=A0 In most deployment scenario's, the IKE client has a= n expectation that
=C2=A0=C2=A0 it is connecting, using a split-network = setup, to a specific
=C2=A0=C2=A0 organisation or enterprise.=C2=A0 A re= commended policy would be to only
=C2=A0=C2=A0 accept INTERNAL_DNSSEC_TA= directives from that organization's DNS
=C2=A0=C2=A0 names.=C2=A0 H= owever, this might not be possible in all deployment
=C2=A0=C2=A0 scenar= ios, such as one where the IKE server is handing out a number
=C2=A0=C2= =A0 of domains that are not within one parent domain.

Is that text wrong? If not, I suspect we're just quibbling abou= t "common".

-Ekr

=
--0000000000002e77a0056f0bff89-- From nobody Wed Jun 20 07:15:48 2018 Return-Path: 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 64AAF1292AD; Wed, 20 Jun 2018 07:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 EqhUnrcvJ4xw; Wed, 20 Jun 2018 07:15:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F6D130EA5; Wed, 20 Jun 2018 07:15:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419n1C672fz39Q; Wed, 20 Jun 2018 16:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529504143; bh=AKJY2WO215ubZOxvbc3s3I/04VTciZ5O5nnqaj44WbM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ag0KUFHk7oPJTd9pcl4Uz6St7+tiS6qlPCivIAqPQGj6itEMDcSmI9XZP8nmcF760 G1ZTOLhJcq2IbQl0nMRRmQK3ogIqms/JwSx/WLMuyR06/ib/lWxdoKlfeqbrHfnkCL GIgMFnBVESdETDke6R96E9AtCYwarEbrGubb2GzY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id s65qJz-fUd_1; Wed, 20 Jun 2018 16:15:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 16:15:42 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F10934FB768; Wed, 20 Jun 2018 10:15:41 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F10934FB768 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E50F240D72BD; Wed, 20 Jun 2018 10:15:41 -0400 (EDT) Date: Wed, 20 Jun 2018 10:15:41 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: IPsecME WG , Nico Williams , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: Message-ID: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:15:46 -0000 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. > I'm sorry to repeat myself, but once > again the document clearly states that this can happen: I also answered this question twice already. If you are waiting for a trigger in any possibly answer, why not just tell us what that trigger is and we can discuss it? >    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. Or you can suggest text. Paul From nobody Wed Jun 20 11:04:17 2018 Return-Path: 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 ; 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 ; 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 ; Wed, 20 Jun 2018 11:04:13 -0700 (PDT) Received: by mail-yw0-x242.google.com with SMTP id 81-v6so165258ywb.6 for ; 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: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> From: Eric Rescorla Date: Wed, 20 Jun 2018 11:03:31 -0700 Message-ID: To: Paul Wouters Cc: IPsecME WG , Nico Williams , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Content-Type: multipart/alternative; boundary="00000000000048d80e056f16a0f1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:04:16 -0000 --00000000000048d80e056f16a0f1 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 20, 2018 at 7:15 AM, Paul Wouters 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 --00000000000048d80e056f16a0f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 20, 2018 at 7:15 AM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 19 Ju= n 2018, Eric Rescorla wrote:

Yes, that's technically true, but the question is whether it's in f= act
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.<= /div>

=C2=A0=C2=A0 In most deployment scenario's, the IKE client has an expec= tation that
=C2=A0=C2=A0 it is connecting, using a split-network setup, to a specific =C2=A0=C2=A0 organisation or enterprise.=C2=A0 A recommended policy would b= e to only
=C2=A0=C2=A0 accept INTERNAL_DNSSEC_TA directives from that organization= 9;s DNS
=C2=A0=C2=A0 names.=C2=A0 However, this might not be possible in all deploy= ment
=C2=A0=C2=A0 scenarios, such as one where the IKE server is handing out a n= umber
=C2=A0=C2=A0 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 su= ppose we must be talking past each other. I read this text as saying that t= here are important cases where in fact the client will not have any reasona= ble=C2=A0 way of knowing which domains to accept from the server, which, it= seems to me, contradicts the claim above that it's practical. You obvi= ously think i'm wrong, so how should I be reading this text?
<= div>
-Ekr



<= div>


--00000000000048d80e056f16a0f1-- From nobody Wed Jun 20 12:22:03 2018 Return-Path: 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 E4180131106; Wed, 20 Jun 2018 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 DKKyaqhnKrgh; Wed, 20 Jun 2018 12:22:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B701310AB; Wed, 20 Jun 2018 12:21:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419vpW57HkzF3y; Wed, 20 Jun 2018 21:21:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529522515; bh=bHYn9zr50gS3eCmJnU9BaL8elFlVHI5MDrjRW7VH0PI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=BZPrdez8QlMN57Ud/J6qHKuzYNWHVG5BEVmUkaUaqMnHpgv6KfB3Q/4H/RQaB3yWx sFB3mxSBQVQP4nPlkgzt5zKy1T9XaZkSTxLfCERh0IOwtME01d/kYmPUYKr4smj5V0 oZeSLwYQfyABRFIOx45fkXMByXPvVhVlGEB5lNi0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eJxRZyH4eoW3; Wed, 20 Jun 2018 21:21:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 21:21:53 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 74CCCB8AF; Wed, 20 Jun 2018 15:21:52 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 74CCCB8AF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6880E407821F; Wed, 20 Jun 2018 15:21:52 -0400 (EDT) Date: Wed, 20 Jun 2018 15:21:52 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: IPsecME WG , Nico Williams , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen In-Reply-To: Message-ID: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:22:02 -0000 On Wed, 20 Jun 2018, Eric Rescorla wrote: > 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? I understand what bothers you. You see browsers getting non-public TLSA answers and you are concerned about webpki bypass and enterprise meddling. I see text restricting and notifying users of the domain names that will be part of the IKE configuration or negotiation allowing them to reject inappropriate domains. You fear the user will just click yes. Then you somehow would like to know how common this new behaviour would be and how reasonable it is for a client to understand what is happening. I cannot answer how common this would be other than stating in the past this wasn't possible at all. And that client understanding could be presented cleanly and I gave an example. To me, the only question is how to change the text so this is all clear to you, but you say you are still gathering facts and you are not ready yet to evaluate any proposed changes. Maybe some other people can chime into this discussion and/or provide text to clarify things to you better than I am able to. Paul From nobody Wed Jun 20 12:32:42 2018 Return-Path: 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 8511813111F; Wed, 20 Jun 2018 12:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 98rP7hrwb70Z; Wed, 20 Jun 2018 12:32:38 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC78D130F11; Wed, 20 Jun 2018 12:32:36 -0700 (PDT) X-AuditID: 12074422-d23ff70000001a12-94-5b2aabd3f5ed Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B9.B2.06674.3DBAA2B5; Wed, 20 Jun 2018 15:32:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w5KJWYtx009202; Wed, 20 Jun 2018 15:32:34 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5KJWS6D025222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2018 15:32:31 -0400 Date: Wed, 20 Jun 2018 14:32:28 -0500 From: Benjamin Kaduk To: Paul Wouters Cc: Eric Rescorla , IPsecME WG , Nico Williams , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" , Tero Kivinen Message-ID: <20180620193225.GL4946@kduck.kaduk.org> References: <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUixG6nont5tVa0wf8/lhYbe/6xWRztd7ZY 8focu8X+LS+AvPPP2SxOXTvCZvH+1iUmB3aPl6fOMXosWfKTyePw14UsHtdO/mX1+D6PyWPy 4zbmALYoLpuU1JzMstQifbsErozzS/8wFsySrtg+saqB8bVoFyMnh4SAicTTH2uYuxi5OIQE FjNJLDvxHMrZyCjx6GQDlHOVSeL0qg8sIC0sAqoSXXNXM4HYbAIqEg3dl5lBbBEBRYlJZx6x gDQwC+xiktg55TYbSEJYwEjizYofjCA2r4CxxMeuM2BxIYEbLBKnXjhDxAUlTs58AraAWUBH YufWO0A1HEC2tMTyfxwQYXmJ5q2zwXZxCjhKNM9aATZSVEBZYm/fIfYJjIKzkEyahWTSLIRJ s5BMWsDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4WlyUdjBO/Od1iFGA g1GJh/dGmFa0EGtiWXFl7iFGSQ4mJVFe/hqgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeNbOB crwpiZVVqUX5MClpDhYlcd7cRYzRQgLpiSWp2ampBalFMFkZDg4lCd7Zq4AaBYtS01Mr0jJz ShDSTBycIMN5gIaXgtTwFhck5hZnpkPkTzHqcnw4NLmHWYglLz8vVUqcNxGkSACkKKM0D24O KMlJZO+vecUoDvSWMO9CkCoeYIKEm/QKaAkT0JLqZrAlJYkIKakGxkZpOa5zwj1Mrudvx0vz cAtNPLxq1eG5B8ttlOS+aEyJad5w59eSBJeToQnfUl4JvWXc8lBgj47gsU0RhSm1r9+xHz3+ qseer8PhyOtzLfvYL3XmLFiR/EfWOX6HltVjyWWf5r3gVOLgOXUomG+L2ucgz/lHdhj9vHJG VU/h9rXv1ZaLkzXuKimxFGckGmoxFxUnAgC8yoL8TQMAAA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:32:41 -0000 On Wed, Jun 20, 2018 at 03:21:52PM -0400, Paul Wouters wrote: > On Wed, 20 Jun 2018, Eric Rescorla wrote: > > > 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? > > I understand what bothers you. You see browsers getting non-public TLSA > answers and you are concerned about webpki bypass and enterprise > meddling. > > I see text restricting and notifying users of the domain names that will > be part of the IKE configuration or negotiation allowing them to reject > inappropriate domains. > > You fear the user will just click yes. Then you somehow would like to This seems like the main fear, yes, but perhaps not exclusively so. It's kind of how users "always" click through certificate warnings in browsers, or "alway" grant a mobile app all the requested permissions. If, to expand unreasonably upon a previous example, connecting to the Red Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com, rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com, realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it reasonable to expect the user to look at the list and pick out "realham.googleapps.com" as not belonging? Maybe they think it's a codename for some Red Hat project, but maybe it's something totally unrelated and reflects overreach by the VPN provider. It seems to border on unreasonable to have such a long list and expect user knowledge. On the one hand, the VPN provider "ought to know" what domains it's responsible for (and are on the internal view), but on the other hand this is essentially a self-certification and does not inherently have any level of trust. It would be great if there was some third party that could provide some certification that the list of controlled domains is valid, or at least not present in the public view and controlled by someone else (since there will presumably be cases when internal names are not expected to be visible in the public view at all). I'm not coming up with a great technical solution off the top of my head, though. "Something in the public DNS" might work, if you can forgive the incredibly vague idea. > know how common this new behaviour would be and how reasonable it is > for a client to understand what is happening. I cannot answer how common > this would be other than stating in the past this wasn't possible at > all. And that client understanding could be presented cleanly and I gave > an example. I think it will be very common for users to "click through" without actually looking at the list, with fairly high confidence. I expect (but at a lower level of confidence) that it will also be common for enterprises to have lists of more than three domains in the internal view. -Benjamin > To me, the only question is how to change the text so this is all clear > to you, but you say you are still gathering facts and you are not ready > yet to evaluate any proposed changes. > > Maybe some other people can chime into this discussion and/or provide > text to clarify things to you better than I am able to. > > Paul From nobody Wed Jun 20 12:55:12 2018 Return-Path: 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 9FBF2130DC2; Wed, 20 Jun 2018 12:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 R3RWdqXeCoqy; Wed, 20 Jun 2018 12:55:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6011294D0; Wed, 20 Jun 2018 12:55:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 419wXp25J3zF3y; Wed, 20 Jun 2018 21:55:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1529524506; bh=TIiVmvvK1LdzMk0qGU1vIucLndUjBW7W7WnupdI4QOI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NP/Nm+rSukJTCBPKLcgj/6VnIa3KuI06esCwkbC6ClpjEzZRQDcGjQ0NJ94bEpv7O yGNd/gwwnKka8/NoDxRYYJCeCKj3zZYms/DwCc9ISUZYB8Bvh3Ak30oAtEwt2OyEIK y7e0aWLevXL0WUPVzv2UpMjxyLmUB8cMraPdJBhw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id e6CQJYU3SjSM; Wed, 20 Jun 2018 21:55:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Jun 2018 21:55:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6D297B8AF; Wed, 20 Jun 2018 15:55:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6D297B8AF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6142A407821F; Wed, 20 Jun 2018 15:55:02 -0400 (EDT) Date: Wed, 20 Jun 2018 15:55:02 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: Eric Rescorla , "draft-ietf-ipsecme-split-dns.all@ietf.org" , Tero Kivinen , IPsecME WG , "Waltermire, David A. (Fed)" , Nico Williams In-Reply-To: <20180620193225.GL4946@kduck.kaduk.org> Message-ID: References: <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> <20180620193225.GL4946@kduck.kaduk.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:55:11 -0000 On Wed, 20 Jun 2018, Benjamin Kaduk wrote: > This seems like the main fear, yes, but perhaps not exclusively so. > It's kind of how users "always" click through certificate warnings in > browsers, or "alway" grant a mobile app all the requested permissions. > If, to expand unreasonably upon a previous example, connecting to the Red > Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com, > rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com, > realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it > reasonable to expect the user to look at the list and pick out > "realham.googleapps.com" as not belonging? Maybe they think it's a > codename for some Red Hat project, but maybe it's something totally > unrelated and reflects overreach by the VPN provider. If you are thinking of such a large list, then this information could be conveyed via the Enterprise VPN Profile that the user must install. Then you could either not allow any changes from that profile without updating, or you could decide as a client to present only new names to the user. This is all local policy between enterprise server and client. Just like the mandatory use of some algorithms can be (and are) set in those profiles. > It seems to border on unreasonable to have such a long list and expect user > knowledge. On the one hand, the VPN provider "ought to know" what domains > it's responsible for (and are on the internal view), but on the other hand > this is essentially a self-certification and does not inherently have any > level of trust. It would be great if there was some third party that could > provide some certification that the list of controlled domains is valid, or > at least not present in the public view Names might be present in the public view and private view. That is not a valid criteria. > and controlled by someone else If you solve the Public Suffix list problem, there are more people interested in how they can use that information :) Although again, draft-pwouters-powerbind comes close to offering that functionality. > (since there will presumably be cases when internal names are not expected > to be visible in the public view at all). I'm not coming up with a great > technical solution off the top of my head, though. "Something in the public > DNS" might work, if you can forgive the incredibly vague idea. That would mean publishing something about private domains in the public dns and worse publishing something in the parent zone about child zones, which would be next to impossible for second level domains. >> know how common this new behaviour would be and how reasonable it is >> for a client to understand what is happening. I cannot answer how common >> this would be other than stating in the past this wasn't possible at >> all. And that client understanding could be presented cleanly and I gave >> an example. > > I think it will be very common for users to "click through" without > actually looking at the list, with fairly high confidence. I expect (but > at a lower level of confidence) that it will also be common for enterprises > to have lists of more than three domains in the internal view. If you do not make this option available at all, then the only option for the enterprise VPN's are: - Conveying this information hardcoded in installation profiles without any user visibility or negotiation/rejection posibility - Demanding to just get all DNS traffic despite being a split-tunnel VPN, at the expense of the user's privacy when doing DNS lookups for things that are not supposed to go into the VPN tunnel. Possibly requiring the user disables DNSSEC completely. Note also that the harm that can be done with realham.googleapps.com is basically the same as with any typosquat domain name, like me getting rhel.googleapps.co or realham-googleapps.com. I think that is not the real issue here. The issue is missing facebook.com, twitter.com or gmail.com in a long list of domains. And those would have a much higher chance of being seen as inappropriate. If it helps we could limit the number of INTERNAL_DNS_DOMAIN payloads or INTERNAL_DNSSEC_TA payloads allowed to put an artificial cap on these lists. I personally don't think we should, but I wouldn't object to one either if it is not too low. The reality is that using an Enterprise VPN means letting the enterprise control part of your machine. If the enterprise is malicious or incompetent, than there is nothing you can do as enduser. If anything, allowing this draft gives the VPN client a better chance to compartmentalize what it gives the Enterprise VPN. It is simply not different from the mandatory enterpise CA and/or anti-virus you have to install. If you think that risk is too high, you should not use the enterprise hardware for anything not related to the enterprise, and BYOD for personal matters. To greatly reduce any abuse, the draft disallows any of these CFG payloads for those VPNs that are not split and take all traffic. If the VPN client is using its own validating resolver, the remote VPN cannot falsify any TLSA records. This covers the use case of all commercial VPN providers out there, some of which are pretty malicious. Paul From nobody Wed Jun 20 13:20:46 2018 Return-Path: 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 3EC9D130E86; Wed, 20 Jun 2018 13:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 10pB5IpFBvSC; Wed, 20 Jun 2018 13:20:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2802F130E20; Wed, 20 Jun 2018 13:20:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w5KKKV3h006207 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jun 2018 23:20:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w5KKKVbl024517; Wed, 20 Jun 2018 23:20:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23338.46863.5452.257270@fireball.acr.fi> Date: Wed, 20 Jun 2018 23:20:31 +0300 From: Tero Kivinen To: Paul Wouters Cc: Eric Rescorla , Nico Williams , IPsecME WG , "draft-ietf-ipsecme-split-dns.all\@ietf.org" , "Waltermire\, David A. \(Fed\)" In-Reply-To: References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 35 min X-Total-Time: 35 min Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 20:20:44 -0000 Paul Wouters writes: > You almost certainly will need to install some local webpki trust anchor > to make use of your internal TLS servers reachable via the IPsec VPN. > > For example, to reach any of our internal redhat servers over HTTPS, I > need to install a redhat internal CA into my system/browser. I believe > this is extremely common (although I do hope it is less common to give > these internal CA's the CN="Certificate Authority") Reading this thread now, I have few comments. 1) The current practice (before this draft) for split-dns is as follows: Forward ALL traffic to SGW when VPN is up (includes all DNS, including traffic to 8.8.8.8 etc). Forbid sending any traffic out except through VPN. Mandate that clients will install Enterprise Root CA to the trust anchor list of the client (i.e., operating system global trust anchor list). The client will have that Enterprise Root CA configured always, i.e., regardless whether VPN is up or not. Those Enterprise Root CAs do not have name constrains (as they do not work) or anything else that will limit their use for creating certificates for any domain name in world (CT might help). I.e., to be able to access enterprise https protected sites you MUST install the Enterprise Root CA, and to do anything useful you need to do that. One reason they want to do this is to limit what client can send out, for example make sure it cannot send any email out directly but all emails must go through the enterprise SMTP server which will do virus checking, add stupid disclaimers to them. They also want to do virus and malvare verification on all web traffic, thus they will want to use that Enterprise Root CA for MitM of all web traffic, or they might mandate the use of proxy that does the checking. If you want to connect your bank etc, do not use your enterprise laptop for that... 2) With this protocol, we can have Split-dns setup where the server can say that my "internal.local" domain is served by 10.0.0.1 and which has TA of XXX. This will provide much better security, as now enterprise can get rid of the Enterprise Root CA which allows MitM of whole web, and instead they can provide local TA configured DNSSEC protected TLSA records for all internal services. I.e., after this there would no longer be need to require installing of the Enterprise Root CA just to get internal services working. I.e., we want to use TLSA which is protected by local TA to protect the internal servers. This is why we do not want to filter TLSA records out. Enterprise might still want to use Enterprise Root CA to do the MitM for virus etc checking, but this is outside the scope of this protocol. 3) Usually enterprises try to configure their internal domains to only include very limited number of domains, as the more you have those, the more issues you will have with configation. Quite often they use something that does not exists at all outside the enterprise. I.e., names like .internal, .local, .enterprise, .company-name. Sometimes they use names that do exists in outside world, but which are not owned by them (yes, this can and will happen, most commonly when they start using some foo.bar domain, and then someone decides to register .bar top level domain). If they are smart they use some domain owned by them which do have external visible name servers, and use some subdomain there which might not exist outside, i.e. internal.example.com. The reason why they end up with multiple internal domains is because every acquisition, merge etc usually adds some new names, and it takes years to get rid of them all. I think in my last employer we had about 5-8 different internal domain names in total during last 20 years, but only 1-2 were in use in the end. 4) If the enterprises have very complicated network they will usually have management system (or MDM) that will automatically configure the clients for them. I.e., the device is fully configured by the management system, and they will automatically apply configuration changes when needed. I think most of those system do allow completely take the device in their control, i.e., most likely they can silently install the Enterprise Root CA there if they want, or push device updates which include any code they want... In those cases the security of the device is in the hands of the enterprise anyways, and users might not even have permissions to change anything on the devices. So I think the feature that we can use TLSA records in the split-dns is very important. I agree that it would be VERY BAD for the client to just accept whatever domains server sends, and it SHOULD always verify it against its local configuration. As I said in complicated cases the configuration itself might come from the management system, so client does not need to silently accept what server says, it can always verify it against the list it has in configuration. But as the list comes from the enterprise this does not protect the client from the malicious enterprise, but it does protect it against case where attacker manages to hack in to the SGW, but was not able to gain access to the management system. It most likely will not protect against case where the attacker hacks in to the management system, as the SGW configuration might also come from there... -- kivinen@iki.fi From nobody Wed Jun 20 15:06:36 2018 Return-Path: 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 733C2130EC8; Wed, 20 Jun 2018 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 4u2CvcpUF1wF; Wed, 20 Jun 2018 15:06:29 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC4F130EC6; Wed, 20 Jun 2018 15:06:29 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 45E153000410F; Wed, 20 Jun 2018 15:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=whASGT9rJ8y2FM q28xnK9IDO+6k=; b=CmEQ725b8edH0fcMFEknTt0uxiQaJfO7+QrFvUhmymmduA 99l7UVSVVNXZgzXdmldVqUS/EHVWlkLe6/ga5zbG2TnQq1egB9+LiUCgDhFV+MtF /Kfc5Bu2hx0yMZtO0ugYOONM1z0wY1c2pkHMNtWlgNtcMwtat5VXq3LwaJ8Gg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 7CEFB3000410D; Wed, 20 Jun 2018 15:06:27 -0700 (PDT) Date: Wed, 20 Jun 2018 17:06:25 -0500 From: Nico Williams To: Tero Kivinen Cc: Paul Wouters , Eric Rescorla , IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" Message-ID: <20180620220624.GH4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> <23338.46863.5452.257270@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23338.46863.5452.257270@fireball.acr.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:06:33 -0000 On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote: > Reading this thread now, I have few comments. > > [...] > > So I think the feature that we can use TLSA records in the split-dns > is very important. I agree that it would be VERY BAD for the client to > just accept whatever domains server sends, and it SHOULD always verify > it against its local configuration. Agreed. But I also think that a REQUIREMENT that the client support and check local policy as to which domains to accept TAs for is sufficient to address the concern. Isn't it? Nico -- From nobody Wed Jun 20 16:57:09 2018 Return-Path: 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 B3377130E46; Wed, 20 Jun 2018 16:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=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 j4mLJG_p85Mf; Wed, 20 Jun 2018 16:57:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3D3130E3D; Wed, 20 Jun 2018 16:57:05 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w5KNuwFc022764 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jun 2018 02:56:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w5KNuwdx018121; Thu, 21 Jun 2018 02:56:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23338.59850.426646.482306@fireball.acr.fi> Date: Thu, 21 Jun 2018 02:56:58 +0300 From: Tero Kivinen To: Nico Williams Cc: IPsecME WG , Eric Rescorla , Paul Wouters , "draft-ietf-ipsecme-split-dns.all\@ietf.org" , "Waltermire\, David A. \(Fed\)" In-Reply-To: <20180620220624.GH4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> <23338.46863.5452.257270@fireball.acr.fi> <20180620220624.GH4218@localhost> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 38 min Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 23:57:08 -0000 Nico Williams writes: > On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote: > > Reading this thread now, I have few comments. > > > > [...] > > > > So I think the feature that we can use TLSA records in the split-dns > > is very important. I agree that it would be VERY BAD for the client to > > just accept whatever domains server sends, and it SHOULD always verify > > it against its local configuration. > > Agreed. > > But I also think that a REQUIREMENT that the client support and check > local policy as to which domains to accept TAs for is sufficient to > address the concern. Isn't it? Yes and no. Yes, I think that is best we can do. No, I do not think it will necessarely solve the problem, as there will be implementations where they might have the local policy checks, but there is no way to edit that list (or even see that list), because this list comes and is managed by the management system or profile. I.e., the feature might be there, but it is useless as it is filled up by the enterprise. Of course there is trust relationship between the VPN client and the enterprise. All this information is transmitted inside the IKEv2 SA which is authenticated, thus client is able to trust the information it gets from the SGW. Then client simply needs to decide whether it trusts the enterprise enough to allow it do the things it tries to do. Asking user does not really help, as if there is popups the users will simply click them away. Very often this already happened for some internal servers already for TLS. Some people did not install the Enterprise Root CA, or the certificate used for the service expired and nobody bothered to update it, or the service used actually self-signed certificates, or the service used different internal domain name than the user tried to use etc. More often than not the intranet sites gives all kind of certificate errors when you are connecting to them, thus in enterprise environments people ignore the warnings always... Hopefully with this we might actually be able to use TLSA records for those internal sites, and that might fix some issues (or at least break them in different ways :-) -- kivinen@iki.fi From nobody Wed Jun 20 17:26:49 2018 Return-Path: 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 AC3C6130EDB; Wed, 20 Jun 2018 17:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 4vQYOVbUVKmu; Wed, 20 Jun 2018 17:26:46 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AC9130E3D; Wed, 20 Jun 2018 17:26:46 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 08F6D30002BB2; Wed, 20 Jun 2018 17:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=C94vi0lLilJtxU +T+PtlE88PAm8=; b=vz8TepTIkQT2gHp8xOAQ2ifIDCkJLXeD9DkP92FzEXd4Rh vZS8mCsXhLOXHhWIEJCMOifn9LHI296iyk1uwdqHhxUY8nVYWbyF3nhaNvQdc/Nu 63BaNOc7z1Po1Z5iZnsrsckJaJyEP8on7dqIz/IW3qkKmchQzzjdGwh18ZpIU= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 61A6F30002BAF; Wed, 20 Jun 2018 17:26:45 -0700 (PDT) Date: Wed, 20 Jun 2018 19:26:43 -0500 From: Nico Williams To: Tero Kivinen Cc: IPsecME WG , Eric Rescorla , Paul Wouters , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" Message-ID: <20180621002642.GI4218@localhost> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> <23338.46863.5452.257270@fireball.acr.fi> <20180620220624.GH4218@localhost> <23338.59850.426646.482306@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23338.59850.426646.482306@fireball.acr.fi> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 00:26:48 -0000 On Thu, Jun 21, 2018 at 02:56:58AM +0300, Tero Kivinen wrote: > Nico Williams writes: > > On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote: > > > So I think the feature that we can use TLSA records in the split-dns > > > is very important. I agree that it would be VERY BAD for the client to > > > just accept whatever domains server sends, and it SHOULD always verify > > > it against its local configuration. > > > > Agreed. > > > > But I also think that a REQUIREMENT that the client support and check > > local policy as to which domains to accept TAs for is sufficient to > > address the concern. Isn't it? > > Yes and no. > > Yes, I think that is best we can do. > > [...] Agreed. Now, is the concern enough to reject this I-D? Nico -- From nobody Fri Jun 22 08:16:56 2018 Return-Path: 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 09829130E93 for ; Fri, 22 Jun 2018 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 rGSpkm3YCpXh for ; Fri, 22 Jun 2018 08:16:51 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9325130E90 for ; Fri, 22 Jun 2018 08:16:51 -0700 (PDT) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id B16D794A5AF for ; Fri, 22 Jun 2018 17:16:49 +0200 (CEST) From: "Tobias Guggemos" To: "IPsecME WG" References: In-Reply-To: Date: Fri, 22 Jun 2018 17:16:51 +0200 Message-ID: <000501d40a3c$0c03d400$240b7c00$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQHCOIZDeHfpv+0T/+/EAsCUK7hpQAFHLIQAMeqiLA= Content-Language: de Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:16:55 -0000 as a co-author, I believe that all comments received so far have been addressed and the resulting document is in good shape for the IESG.=20 Regards,=20 Tobias -----Urspr=FCngliche Nachricht----- Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Waltermire, = David A. (Fed) Gesendet: Montag, 18. Juni 2018 18:01 An: IPsecME WG Betreff: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 Please note, this is a follow-up to the previous WGLC. This is to = confirm WG consensus on the draft before sending it forward to the IESG. Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Monday, June 18, 2018 9:39 AM > To: IPsecME WG > Subject: WGLC on draft-ietf-ipsecme-implicit-iv-04 >=20 > This message starts a working group last call (WGLC) on=20 > draft-ietf-ipsecme- implicit-iv-04, which will conclude on June 29,=20 > 2018 at UTC 23:59. Please review and provide feedback on the -04=20 > version=20 > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/).=20 > Please indicate if you believe this draft is ready for publication or = if you have comments that must be addressed before the draft progresses. >=20 > Regards, > Dave _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jun 22 08:33:07 2018 Return-Path: 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 414CA130E9D for ; Fri, 22 Jun 2018 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 6UmkFsprHOsr for ; Fri, 22 Jun 2018 08:32:59 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C33130EC2 for ; Fri, 22 Jun 2018 08:32:59 -0700 (PDT) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 2F95194A582 for ; Fri, 22 Jun 2018 17:32:58 +0200 (CEST) From: "Tobias Guggemos" To: "IPsecME WG" References: <152767974423.27985.13257071150679475327.idtracker@ietfa.amsl.com> In-Reply-To: <152767974423.27985.13257071150679475327.idtracker@ietfa.amsl.com> Date: Fri, 22 Jun 2018 17:32:59 +0200 Message-ID: <001001d40a3e$4d449f60$e7cdde20$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHT+AltRjmCo7HUY0yreKjYXb9VsqRsieEw Content-Language: de Archived-At: Subject: [IPsec] WG: New Version Notification for draft-mglt-ipsecme-diet-esp-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:33:05 -0000 Hey all, we recently published a new version of the draft for ESP Header = Compression (EHC). We included the comments we received, including the proposal of new = IPsec modes "Compressed Transport" and "Compressed Tunnel", which are = used to indicate the usage of EHC on a per-SA-basis (see Section 5 of = the new version). We would like to negotiate this with a USE_COMPRESSED_MODE Notify = Payload in IKEv2, which works exactly the same as the USE_TRANSPORT_MODE = Notify Payload. If you have any opinion on that we would really looking forward the = receive them. Any other comments are of course very welcome as well! Regards Tobias -----Urspr=C3=BCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Gesendet: Mittwoch, 30. Mai 2018 13:29 An: Carsten Bormann ; Daniel Migault = ; Tobias Guggemos ; = David Schinazi Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-06.txt A new version of I-D, draft-mglt-ipsecme-diet-esp-06.txt has been successfully submitted by Tobias Guggemos and posted to the = IETF repository. Name: draft-mglt-ipsecme-diet-esp Revision: 06 Title: ESP Header Compression and Diet-ESP Document date: 2018-05-29 Group: Individual Submission Pages: 45 URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-06.txt Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 Htmlized: = https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-diet-esp-06 Abstract: ESP Header Compression (EHC) defines a flexible framework to compress communications protected with IPsec/ESP. Compression and decompression is defined by EHC Rules orchestrated by EHC Strategies. The document specifies the Diet-ESP EHC Strategy and associated EHC Rules. Diet-ESP compresses up to 32 bytes per packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent over a single TCP or UDP session. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Jun 26 06:20:35 2018 Return-Path: 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 1C9F813102A for ; Tue, 26 Jun 2018 06:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wpjJthzFci6o for ; Tue, 26 Jun 2018 06:20:29 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E123131036 for ; Tue, 26 Jun 2018 06:20:17 -0700 (PDT) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id AE69D94A8D2; Tue, 26 Jun 2018 15:20:15 +0200 (CEST) From: "Tobias Guggemos" To: "IPsecME WG" Cc: "'Daniel Migault'" , "Schmitz, David" References: <153001861044.916.11572066667279826441.idtracker@ietfa.amsl.com> In-Reply-To: <153001861044.916.11572066667279826441.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2018 15:20:15 +0200 Message-ID: <000a01d40d50$6bb006f0$431014d0$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHUDU8Fw6CqfBntPkCIakwQ8dtmdKRyhBug Content-Language: de Archived-At: Subject: [IPsec] WG: New Version Notification for draft-mglt-ipsecme-ikev2-diet-esp-extension-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 13:20:34 -0000 Hey all, we just published a new version of the IKEv2 extension for ESP Header = Compression. https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-0= 1=20 We included the comments we received, including the negotiation the new = IPsec modes "Compressed Transport" and "Compressed Tunnel", which are = used to indicate the usage of EHC on a per-SA-basis. We would like to know whether the WG prefers to negotiate this modes = explicitly with a new Notify Payload USE_COMPRESSED_MODE (as it is = currently in the draft in Section 5.1) or if the EHC_STRATEGY_SUPPORTED = Notify Payload (which we use to negotiate the compression context) is = significant enough to agree on the new modes (see Section 5.2 in the = draft). This would allow us to remove the explicit negotiation with the = USE_COMPRESSED_MODE Notify Payload. Any opinion on that is more than welcome. Any other comments on the draft are of course very appreciated as well! Regards Tobias -----Urspr=C3=BCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Gesendet: Dienstag, 26. Juni 2018 15:10 An: Daniel Migault ; Tobias Guggemos = ; David Schinazi Betreff: New Version Notification for = draft-mglt-ipsecme-ikev2-diet-esp-extension-01.txt A new version of I-D, draft-mglt-ipsecme-ikev2-diet-esp-extension-01.txt has been successfully submitted by Tobias Guggemos and posted to the = IETF repository. Name: draft-mglt-ipsecme-ikev2-diet-esp-extension Revision: 01 Title: Internet Key Exchange version 2 (IKEv2) extension for the ESP = Header Compression (EHC) Strategy Document date: 2018-06-25 Group: Individual Submission Pages: 13 URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-ikev2-diet-esp-ex= tension-01.txt Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extens= ion/ Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-0= 1 Htmlized: = https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-e= xtension Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-ikev2-diet-esp-ext= ension-01 Abstract: ESP Header Compression (EHC) reduces the ESP overhead by compressing ESP fields. Compression results from a coordination of various EHC Rules designed as EHC Strategies. An EHC Strategy may require to be configured with some configuration parameters. When a Security Association (SA) is enabling EHC, the two peers need to agree which EHC Strategy is applied as well as its associated configuration parameters. This document describes an extension of IKEv2 that enables two peers to agree on a specific EHC Strategy as well as its associated configuration parameters. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Jun 26 06:22:24 2018 Return-Path: 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 5D5ED131026 for ; Tue, 26 Jun 2018 06:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 oj_znEKFKnTW for ; Tue, 26 Jun 2018 06:22:21 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 3BD03130DDE for ; Tue, 26 Jun 2018 06:22:21 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id u6-v6so5599986lju.13 for ; Tue, 26 Jun 2018 06:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=OVubhKRLAcRgUEa38MmPfnTc2/kyAozBhqROd+CqZqk=; b=hs5+Uc5bNySxF8ByCEtK+PRaK+CgUBKDk990WBo3AKljeMDlBLS8oQDs3EI/v+GVGW LQvk8kYkKccMUPF90P3Pat4+jQESkwCcheAg2jrMf4ZP1GC1i9QvXXUOj4SaHCg/NHf3 ZOuHC4C9x4yvKmuxZTmtaFlIIZAfbp6MTY5Lej9gsHAQWutYx4Chs+KVyRgnb0AtsuJ8 yqapxPLJw6RJF2l6CWK43p0RjqGjWQXxftFb8cagowvT9gzVjgNB4u/HcAuEK7FMdcxv OtL4vfP1gi0C62YGIfoKV58g5A8O0zF3DCxuB+HWmsmEMzyFboHJR/a2f1LIRqLkLfD0 M4Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=OVubhKRLAcRgUEa38MmPfnTc2/kyAozBhqROd+CqZqk=; b=DE/R6yVv8Uw/c4u2Lp6jIY2FBj35RJb9XbfHzl+FDJmdd1G06jry4JByT8nj0iWW4f sfbK+ltC/czl7Ncmvj1bDdqb+oPBHwnhq93T7gir8RH0gYLK51J+r/iNnzmf6orhDfGD g9rkFsQ9K3yA8+dhWykYx60Xqjrdw+lftLHz4/n4ulsqzzdiNyvcsx0ue7IUoXYAsukK /5/Q75EFeqFzy1p4Icu5CUJThsBT9eIU0ktIyxenzBPsBzGfPyjLwMIPcNEu2BfKLHzC B6lKWBQ46TWNbY4zxQehILh13+MHNvxYfg4yzq+OlwUe3wTfdRp7p0+wwRscmiU3Ek9f LBww== X-Gm-Message-State: APt69E24DrgzA+9xfjYnQMDDi1u7puEUBgwSbj/Dhc6Bl20o/FhZsb3Q tK+AyXdaCkjOf8pH1kASAkI= X-Google-Smtp-Source: ADUXVKJAhsUer90UtzCKAVkEV1eZ/NRfQreonM40/pfiod3WCvCJddubbMGfXF9Jr0s3wv+8WYAavw== X-Received: by 2002:a2e:29cf:: with SMTP id p76-v6mr1261264ljp.12.1530019339502; Tue, 26 Jun 2018 06:22:19 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i67-v6sm254389lji.49.2018.06.26.06.22.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jun 2018 06:22:18 -0700 (PDT) From: "Valery Smyslov" To: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: In-Reply-To: Date: Tue, 26 Jun 2018 16:22:19 +0300 Message-ID: <08e101d40d50$b5db2610$21917230$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI32eI3Ki8TNvg7zzbr80V/2+Itv6Oq3FKw Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 13:22:24 -0000 Hi, I reviewed the draft and I believe it is almost ready. However, I think there still are few issues. 1. The last para of section 4 says: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. I have three problems with this para. First, I think that this para should be moved into the Security Considerations section. Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat") seems to be wrong here, since it is not an imperative, it's an explanation here (because the preposition "As" is used; note that the draft has already stated that the nonce MUST NOT repeat in the beginning of Section 4). And last (but not least), I have some trouble following this para, it seems to me that it is self-contradicting. First it says that IIV MUST NOT be used if there is a chance that SN repeats (which I fully agree with), then it says that multicast is a prominent example of this situation (i.e. the situation when SN may repeat, which I fully agree with too) and finally it concludes that for multicast IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). In other words it is allowed to use IIV for multicast in some circumstances, which in my opinion contradicts with earlier MUST NOT. Either remove the last sentence, or give more explanation when it is possible to use IIV for multicast. 2. The draft defines IIV for ESP only and forbids to use it for IKEv2. It was discussed and I believe it is right, but I'd like to see few words (presumably in the Security Considerations) why IIV in its current form cannot be used in IKEv2. Something along the lines: This document defines three new encryption transforms that use implicit IV. Unlike most encryption transforms defined to date, which can be used for both ESP and IKEv2, these transforms are defined for ESP only and cannot be used in IKEv2. The reason is that IKEv2 messages don't contain unique per-message value, that can be used for IV generation. The Message-ID field in IKEv2 header is somewhat counterpart of SN field in ESP header, but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is no an easy way to derive unique IV from IKEv2 header fields. Regards, Valery. > This message starts a working group last call (WGLC) on draft-ietf-ipsecme-implicit-iv-04, which will conclude > on June 29, 2018 at UTC 23:59. Please review and provide feedback on the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). Please indicate if you believe this draft is > ready for publication or if you have comments that must be addressed before the draft progresses. > > Regards, > Dave > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jun 26 11:11:06 2018 Return-Path: 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 52963131106 for ; Tue, 26 Jun 2018 11:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MhAVlLBmfQZL for ; Tue, 26 Jun 2018 11:10:54 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 CE4191310F7 for ; Tue, 26 Jun 2018 11:10:53 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id y127-v6so1627691lfc.8 for ; Tue, 26 Jun 2018 11:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e5m4xOPEW2Caahh3RMa/JVoLMcJ2Wwe5Gv1IsnXd40Y=; b=eM3FZ7kCai+Cjng2VopE9bpQAc073vJATm/BSusvGCFkSRJEBgCGaTc0oVVWdfPjaw 1ZVlc42VCMDLG6THqehFSI6ZiCI1AZ1/bLVVA4l+lzu8WwMpDjjqE+jY/ANEXI9T3ZGT SQiHcj2ECr99YRcuLOpaO4cjHFRMPicUJc9zHUWzhmfgQTEuR2+JwDiY+pQk7TFW8ShJ xpPmThW/EnxZPVrmwlWFt4SOrOnhiIGLv8M5uJ1bOIK99spg/zf8AnWlhrez5yl7OkBC ZUObI+Kp5c823rLti3OiNg2Gk1PRLXZOEhQemipX8nB0yfVkhb7IBXAzc0PiFmSc7+V9 G3XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e5m4xOPEW2Caahh3RMa/JVoLMcJ2Wwe5Gv1IsnXd40Y=; b=dWjLe5a2qhV/0yGIdQFAaKWW0fr2Z0wBrDZANTzajN+rPpt48hSHHm2R3hIgZlPEUN riJNuAyfnIv6Tzd/wWyXYnVYaPM5/FSPaBl2+3UIT29YLvFgGPtgJnQ0FXmpAfT44N7B Ir8KQRASMqnSg7hioeUcZ3PzgesaOULSt1qqzpMSISABwgGsEXE/OpCOuMPbhiqsXGKh NsJqnTLweGjYUUb3e6CuvylOW5aRpl/Cncoi6CzRMg2D2Dwc3FLj13WuDgcDJ2Oc0BKU Zgjnzzr/AmhGuwFNAWvmXK0ZUuU7Y6lElK/SANHcd72vwQFdq1JNdN5UtOXftDocqw3A rHxA== X-Gm-Message-State: APt69E3sRyYrOV4STgqA8DTXl9sjiBYnyBZ0wGBDy7v62xqS5RYxFBv7 YR0kkt3qG7e1BM2j4sfvDXBRV9tTjYZXG/AsKVs= X-Google-Smtp-Source: AAOMgpezhMLB4iY1NGin2svaq1/OH73ZBNoXLuCKCPLyjbjFzyjxsSpRZGX3qdwQvO/LekueRyqaxjAEgAWV616F6Jc= X-Received: by 2002:a19:910a:: with SMTP id t10-v6mr1973234lfd.24.1530036652108; Tue, 26 Jun 2018 11:10:52 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:4281:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 11:10:51 -0700 (PDT) In-Reply-To: <08e101d40d50$b5db2610$21917230$@gmail.com> References: <08e101d40d50$b5db2610$21917230$@gmail.com> From: Daniel Migault Date: Tue, 26 Jun 2018 14:10:51 -0400 X-Google-Sender-Auth: RJBlpnzsKuOurpmMCfhKE7mDT4Q Message-ID: To: Valery Smyslov Cc: "Waltermire, David A. (Fed)" , IPsecME WG Content-Type: multipart/alternative; boundary="000000000000246ebd056f8f6be6" Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:11:02 -0000 --000000000000246ebd056f8f6be6 Content-Type: text/plain; charset="UTF-8" Hi Valery, Thanks for the feedback. Here are the update I propose. If that is fine for everyone, I will update the current draft and publish a new version. Yours, Daniel On Tue, Jun 26, 2018 at 9:22 AM, Valery Smyslov wrote: > Hi, > > I reviewed the draft and I believe it is almost ready. However, > I think there still are few issues. > > 1. The last para of section 4 says: > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast. > > I have three problems with this para. First, I think that this para > should be moved into the Security Considerations section. > I am fine having it in the security consideration. Anyone opposed ? Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat") > seems to be wrong here, since it is not an imperative, it's an explanation > here > (because the preposition "As" is used; note that the draft has already > stated that the > nonce MUST NOT repeat in the beginning of Section 4). I think that this address your purpose: OLD: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. NEW As the IV must not repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. And last (but not least), > I have some trouble following this para, it seems to me that it is > self-contradicting. > First it says that IIV MUST NOT be used if there is a chance that SN > repeats > (which I fully agree with), then it says that multicast is a prominent > example of this situation (i.e. the situation when SN may repeat, which > I fully agree with too) and finally it concludes that for multicast > IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). > In other words it is allowed to use IIV for multicast in some > circumstances, > which in my opinion contradicts with earlier MUST NOT. > Either remove the last sentence, or give more explanation > when it is possible to use IIV for multicast. > OK I see your point. The reason is mostly that we had a quite long explanation we removed because we went to the details of a solution we do not standardize. I suggest we simply mention that some means are deployed. OLD: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. NEW: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast, unless deployment specific mechanisms prevent the IV to repeat are provided. > 2. The draft defines IIV for ESP only and forbids to use it for IKEv2. > It was discussed and I believe it is right, but I'd like to see few > words (presumably in the Security Considerations) why IIV > in its current form cannot be used in IKEv2. Something along the lines: > > This document defines three new encryption transforms that use implicit > IV. > Unlike most encryption transforms defined to date, which can be used > for both ESP and IKEv2, these transforms are defined for ESP only and > cannot > be used in IKEv2. The reason is that IKEv2 messages don't contain unique > per-message value, that can be used for IV generation. The Message-ID > field in IKEv2 header is somewhat counterpart of SN field in ESP header, > but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to > repeat, > so there is no an easy way to derive unique IV from IKEv2 header fields. > I am fine adding the text in the draft. > > Regards, > Valery. > > > This message starts a working group last call (WGLC) on > draft-ietf-ipsecme-implicit-iv-04, which will conclude > > on June 29, 2018 at UTC 23:59. Please review and provide feedback on the > -04 version > > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). > Please indicate if you believe this draft is > > ready for publication or if you have comments that must be addressed > before the draft progresses. > > > > Regards, > > Dave > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000246ebd056f8f6be6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Valery,

Thanks for t= he feedback. Here are the update I propose. If that is fine for everyone, I= will update the current draft and publish a new version.
Yours,
Daniel

On Tue, Jun 26, 2018 at 9:22 AM, Val= ery Smyslov <smyslov.ietf@gmail.com> wrote:
Hi,

I reviewed the draft and I believe it is almost ready. However,
I think there still are few issues.

1. The last para of section 4 says:

=C2=A0 =C2=A0As the IV MUST NOT repeat for one SA when Counter-Mode ciphers= are
=C2=A0 =C2=A0used, Implicit IV as described in this document MUST NOT be us= ed in
=C2=A0 =C2=A0setups with the chance that the Sequence Number overlaps for o= ne SA.
=C2=A0 =C2=A0Multicast as described in [RFC5374], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders= share
=C2=A0 =C2=A0one secret and thus one SA.=C2=A0 As such, it is NOT RECOMMEND= ED to use
=C2=A0 =C2=A0Implicit IV with Multicast.

I have three problems with this para. First, I think that this para
should be moved into the Security Considerations section.
<= div><mglt>
I am fine having it in the security consideratio= n. Anyone opposed ?
</mglt>

Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repe= at")
seems to be wrong here, since it is not an imperative, it's an explanat= ion here
(because the preposition "As" is used; note that the draft has al= ready stated that the
nonce MUST NOT repeat in the beginning of Section 4).
<mglt>
I think that this address your purpose:<= br>
OLD:
=C2=A0 =C2=A0As the IV MUST NOT repeat for one= SA when Counter-Mode ciphers are
=C2=A0 =C2=A0used, Implicit IV as described in this document MUST NOT be us= ed in
=C2=A0 =C2=A0setups with the chance that the Sequence Number overlaps for o= ne SA.
NEW
=C2=A0 =C2=A0As the IV must not repeat f= or one SA when Counter-Mode ciphers are
=C2=A0 =C2=A0used, Implicit IV as described in this document MUST NOT be us= ed in
=C2=A0 =C2=A0setups with the chance that the Sequence Number overlaps for o= ne SA.

And last (but= not least),
I have some trouble following this para, it seems to me that it is self-con= tradicting.
First it says that IIV MUST NOT be used if there is a chance that SN repeat= s
(which I fully agree with), then it says that multicast is a prominent
example of this situation (i.e. the situation when SN may repeat, which
I fully agree with too) and finally it concludes that for multicast
IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used).
In other words it is allowed to use IIV for multicast in some circumstances= ,
which in my opinion contradicts with earlier MUST NOT.
Either remove the last sentence, or give more explanation
when it is possible to use IIV for multicast.
<mglt= >
OK I see your point. The reason is mostly that we had a quit= e long explanation we removed because we went to the details of a solution = we do not standardize. I suggest we simply mention that some means are depl= oyed.

OLD:
=C2=A0 =C2=A0Multicast a= s described in [RFC5374], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders= share
=C2=A0 =C2=A0one secret and thus one SA.=C2=A0 As such, it is NOT RECOMMEND= ED to use
=C2=A0 =C2=A0Implicit IV with Multicast.

NEW:
=C2=A0 =C2=A0Multicast as described in [RFC53= 74], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders= share
=C2=A0 =C2=A0one secret and thus one SA.=C2=A0 As such, it is NOT RECOMMEND= ED to use
=C2=A0 =C2=A0Implicit IV with Multicast, unless deployment specific mechani= sms prevent the IV to repeat are provided.

</mglt>


2. The draft defines IIV for ESP only and forbids to use it for IKEv2.
It was discussed and I believe it is right, but I'd like to see few
words (presumably in the Security Considerations) why IIV
in its current form cannot be used in IKEv2. Something along the lines:

=C2=A0 This document defines three new encryption transforms that use impli= cit IV.
=C2=A0 Unlike most encryption transforms defined to date, which can be used=
=C2=A0 =C2=A0for both ESP and IKEv2, these transforms are defined for ESP o= nly and cannot
=C2=A0 =C2=A0be used in IKEv2. The reason is that IKEv2 messages don't = contain unique
=C2=A0 =C2=A0per-message value, that can be used for IV generation. The Mes= sage-ID
=C2=A0 =C2=A0field in IKEv2 header is somewhat counterpart of SN field in E= SP header,
=C2=A0 =C2=A0but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it= to repeat,
=C2=A0 =C2=A0so there is no an easy way to derive unique IV from IKEv2 head= er fields.

<mglt>
I am = fine adding the text in the draft.
</mglt>

Regards,
Valery.

> This message starts a working group last call (WGLC) on draft-ietf-ips= ecme-implicit-iv-04, which will conclude
> on June 29, 2018 at UTC 23:59. Please review and provide feedback on t= he -04 version
> (https://datatracker.ietf.org/<= wbr>doc/draft-ietf-ipsecme-implicit-iv/). Please indicate if you b= elieve this draft is
> ready for publication or if you have comments that must be addressed b= efore the draft progresses.
>
> Regards,
> Dave
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec=

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--000000000000246ebd056f8f6be6-- From nobody Wed Jun 27 00:26:58 2018 Return-Path: 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 BDCD2130E89 for ; Wed, 27 Jun 2018 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, 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 N8gkDPfX9T6a for ; Wed, 27 Jun 2018 00:26:54 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 87054130E87 for ; Wed, 27 Jun 2018 00:26:53 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id u202-v6so760135lff.9 for ; Wed, 27 Jun 2018 00:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=LLQZTOhwOrh9pvQg0+I8+exkWdFxdyHjqHacOScvOdg=; b=lHbhnyx2KKlpG3KSqwduoejfQyIY/6Nm0RqA+tzW6IbTrc3zJ0fKsvLGY1HXEeouru XhcCgg2NCVz8cMq1p29uoSTI2vXC8DuBhVOPFfbVdRziPrybSUH9mEdSsL9qbWPFmWGy 6ScpWyQ/upEa8ISkvz9og9BelhirG91nYKj+LzJhj1NOVyIVws78U2j/nUQc0k2uNZ1s GQwaabVXbicgB8ryb8PqA7t3Q5TPvQOxFECRrP6L40YginoSgELDEw37Xky5BxT1/r1T UbYBQOHAec7LkngOV0weBXMZhrN7XcVak6uv0AOgy6yGvt+hDYgNaOAcSi6EipyO2flu nNEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=LLQZTOhwOrh9pvQg0+I8+exkWdFxdyHjqHacOScvOdg=; b=XSXB415kwux0gojvjiDdHqeMuamDUZCWicirrN37Cy+lQW6ureMSpU/EzyEdK3l99S tyae88GxYjIkZqKR9N2KVQJ8Ac+yA9kl7EJ5LxLXHJ+WHSUM9vUPY67nQPX6/AIjlZw/ 1/tN02nPVpusym4IQ0IzhVirxIz9T2hxpB9ya+VFvPVUlo95DZkEghj0dxT9fbt9DtCz vLFr/qc4dee6NxdEzatc6NKzIDqDy49OFOm8tLvdqaib4+SOxCizweMAjBbZKKxoBXTx YXpEsQKWYfTD6sQhHU91VYQdUkhXu9BIdWwuH1ml/mcpvBoXQa63g0MTXMOOIcXrCEEZ +5pw== X-Gm-Message-State: APt69E0zb6BxG0qDddwdQSvTO24jfucc8pmK4K9Egl4Ds/5r/JxmMBK9 X+E3+2eZBrxO+nLAVW2hQuw= X-Google-Smtp-Source: AAOMgpe1f+b6o8yosChNUtpfhC2GBqAZKOIBD+0czxJSsqGHGHywVueWb9thQCNriCoBrRNmuxpobw== X-Received: by 2002:a19:7402:: with SMTP id v2-v6mr3217506lfe.97.1530084411807; Wed, 27 Jun 2018 00:26:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e22-v6sm553975ljj.95.2018.06.27.00.26.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jun 2018 00:26:51 -0700 (PDT) From: "Valery Smyslov" To: "'Daniel Migault'" Cc: "'Waltermire, David A. \(Fed\)'" , "'IPsecME WG'" References: <08e101d40d50$b5db2610$21917230$@gmail.com> In-Reply-To: Date: Wed, 27 Jun 2018 10:26:51 +0300 Message-ID: <097b01d40de8$37fdca20$a7f95e60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_097C_01D40E01.5D55B080" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI32eI3Ki8TNvg7zzbr80V/2+ItvwKAFQTSAdxlpdSjiTTOEA== Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 07:26:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_097C_01D40E01.5D55B080 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable HI Daniel, =20 I still think the =E2=80=9CNOT RECOMMENDED=E2=80=9D wording is a bit = confusing. I=E2=80=99d suggest to change this para to be more explicit: =20 As the IV must not repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, Implicit IV may only be used = with Multicast=20 if some mechanisms are employed that prevent Sequence Number to = overlap for one SA, otherwise Implicit IV MUST NOT be used with Multicast. =20 Regards, Valery. =20 =20 From: mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault Sent: Tuesday, June 26, 2018 9:11 PM To: Valery Smyslov Cc: Waltermire, David A. (Fed); IPsecME WG Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 =20 Hi Valery,=20 =20 Thanks for the feedback. Here are the update I propose. If that is fine = for everyone, I will update the current draft and publish a new version. = =20 Yours,=20 Daniel =20 On Tue, Jun 26, 2018 at 9:22 AM, Valery Smyslov = wrote: Hi, I reviewed the draft and I believe it is almost ready. However,=20 I think there still are few issues. 1. The last para of section 4 says: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. I have three problems with this para. First, I think that this para should be moved into the Security Considerations section. I am fine having it in the security consideration. Anyone opposed ? =20 Second, using RFC 2119 word in the beginning ("As the IV MUST NOT = repeat")=20 seems to be wrong here, since it is not an imperative, it's an = explanation here (because the preposition "As" is used; note that the draft has already = stated that the=20 nonce MUST NOT repeat in the beginning of Section 4).=20 =20 I think that this address your purpose: OLD: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. NEW As the IV must not repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. =20 And last (but not least), I have some trouble following this para, it seems to me that it is = self-contradicting. First it says that IIV MUST NOT be used if there is a chance that SN = repeats (which I fully agree with), then it says that multicast is a prominent=20 example of this situation (i.e. the situation when SN may repeat, which I fully agree with too) and finally it concludes that for multicast IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). In other words it is allowed to use IIV for multicast in some = circumstances,=20 which in my opinion contradicts with earlier MUST NOT. Either remove the last sentence, or give more explanation=20 when it is possible to use IIV for multicast. OK I see your point. The reason is mostly that we had a quite long = explanation we removed because we went to the details of a solution we = do not standardize. I suggest we simply mention that some means are = deployed.=20 =20 OLD: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. NEW: Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast, unless deployment specific mechanisms = prevent the IV to repeat are provided. =20 2. The draft defines IIV for ESP only and forbids to use it for IKEv2.=20 It was discussed and I believe it is right, but I'd like to see few words (presumably in the Security Considerations) why IIV in its current form cannot be used in IKEv2. Something along the lines: This document defines three new encryption transforms that use = implicit IV. Unlike most encryption transforms defined to date, which can be used for both ESP and IKEv2, these transforms are defined for ESP only and = cannot=20 be used in IKEv2. The reason is that IKEv2 messages don't contain = unique per-message value, that can be used for IV generation. The Message-ID = field in IKEv2 header is somewhat counterpart of SN field in ESP = header, but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to = repeat, so there is no an easy way to derive unique IV from IKEv2 header = fields. =20 I am fine adding the text in the draft. Regards, Valery. > This message starts a working group last call (WGLC) on = draft-ietf-ipsecme-implicit-iv-04, which will conclude > on June 29, 2018 at UTC 23:59. Please review and provide feedback on = the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). = Please indicate if you believe this draft is > ready for publication or if you have comments that must be addressed = before the draft progresses. >=20 > Regards, > Dave >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_097C_01D40E01.5D55B080 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

HI Daniel,

 

I still think the =E2=80=9CNOT RECOMMENDED=E2=80=9D wording is a bit = confusing.

I=E2=80=99d suggest to change this para to be more = explicit:

 

=C2=A0=C2=A0 As the IV must not repeat for one SA when = Counter-Mode ciphers are

=C2=A0=C2=A0 used, Implicit IV = as described in this document MUST NOT be used = in

=C2=A0=C2=A0 setups with the chance that the Sequence = Number overlaps for one SA.

=C2=A0=C2=A0 Multicast as = described in [RFC5374], [RFC6407] and

=C2=A0=C2=A0 [I-D.yeung-g-ikev2] = is a prominent example, where many senders share

=C2=A0=C2=A0 one secret and thus = one SA.=C2=A0 As such, Implicit IV may only be used with Multicast =

=C2=A0=C2=A0=C2=A0if some mechanisms are employed that = prevent Sequence Number to overlap

=C2=A0=C2=A0 for one SA, = otherwise Implicit IV MUST NOT be used with = Multicast.

 

Regards,

Valery.

 

 

From:= = mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of = Daniel Migault
Sent: Tuesday, June 26, 2018 9:11 = PM
To: Valery Smyslov
Cc: Waltermire, David A. = (Fed); IPsecME WG
Subject: Re: [IPsec] WGLC on = draft-ietf-ipsecme-implicit-iv-04

 

Hi = Valery,

 

Thanks for the feedback. Here are the update I = propose. If that is fine for everyone, I will update the current draft = and publish a new version.

 

Yours,

Daniel

 

On Tue, = Jun 26, 2018 at 9:22 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi,

I reviewed the draft and I believe it is = almost ready. However,
I think there still are few issues.

1. = The last para of section 4 says:

   As the IV MUST NOT = repeat for one SA when Counter-Mode ciphers are
   used, = Implicit IV as described in this document MUST NOT be used in
  =  setups with the chance that the Sequence Number overlaps for one = SA.
   Multicast as described in [RFC5374], [RFC6407] = and
   [I-D.yeung-g-ikev2] is a prominent example, where = many senders share
   one secret and thus one SA.  As = such, it is NOT RECOMMENDED to use
   Implicit IV with = Multicast.

I have three problems with this para. First, I think = that this para
should be moved into the Security Considerations = section.

<mglt>

I am fine having it in the security consideration. = Anyone opposed ?

</mglt>

 

Second, = using RFC 2119 word in the beginning ("As the IV MUST NOT = repeat")
seems to be wrong here, since it is not an imperative, = it's an explanation here
(because the preposition "As" is = used; note that the draft has already stated that the
nonce MUST NOT = repeat in the beginning of Section 4). =

 

<mglt>

I think that this address your = purpose:

OLD:

   As the IV MUST NOT repeat for one SA when = Counter-Mode ciphers are
   used, Implicit IV as described = in this document MUST NOT be used in
   setups with the = chance that the Sequence Number overlaps for one = SA.

NEW

   As the IV must not repeat for one SA when = Counter-Mode ciphers are
   used, Implicit IV as described = in this document MUST NOT be used in
   setups with the = chance that the Sequence Number overlaps for one = SA.

 

And last = (but not least),
I have some trouble following this para, it seems to = me that it is self-contradicting.
First it says that IIV MUST NOT be = used if there is a chance that SN repeats
(which I fully agree with), = then it says that multicast is a prominent
example of this situation = (i.e. the situation when SN may repeat, which
I fully agree with too) = and finally it concludes that for multicast
IIV is NOT RECOMMENDED = (i.e. it SHOULD NOT be used).
In other words it is allowed to use IIV = for multicast in some circumstances,
which in my opinion contradicts = with earlier MUST NOT.
Either remove the last sentence, or give more = explanation
when it is possible to use IIV for = multicast.

<mglt>

OK I see your point. The reason is mostly that we had = a quite long explanation we removed because we went to the details of a = solution we do not standardize. I suggest we simply mention that some = means are deployed.

 

OLD:

   Multicast as described in = [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a = prominent example, where many senders share
   one secret = and thus one SA.  As such, it is NOT RECOMMENDED to use
  =  Implicit IV with Multicast.

NEW:

   Multicast as described in = [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a = prominent example, where many senders share
   one secret = and thus one SA.  As such, it is NOT RECOMMENDED to use
  =  Implicit IV with Multicast, unless deployment specific mechanisms = prevent the IV to repeat are provided.

</mglt>

 


2. = The draft defines IIV for ESP only and forbids to use it for IKEv2. =
It was discussed and I believe it is right, but I'd like to see = few
words (presumably in the Security Considerations) why IIV
in = its current form cannot be used in IKEv2. Something along the = lines:

  This document defines three new encryption = transforms that use implicit IV.
  Unlike most encryption = transforms defined to date, which can be used
   for both = ESP and IKEv2, these transforms are defined for ESP only and cannot =
   be used in IKEv2. The reason is that IKEv2 messages = don't contain unique
   per-message value, that can be used = for IV generation. The Message-ID
   field in IKEv2 header = is somewhat counterpart of SN field in ESP header,
   but = recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to = repeat,
   so there is no an easy way to derive unique IV = from IKEv2 header fields.

 

<mglt>

I am fine adding the text in the = draft.

</mglt>


Regards,
Valery.


> This message starts a working group last call = (WGLC) on draft-ietf-ipsecme-implicit-iv-04, which will conclude
> = on June 29, 2018 at UTC 23:59. Please review and provide feedback on the = -04 version
> (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-imp= licit-iv/). Please indicate if you believe this draft is
> = ready for publication or if you have comments that must be addressed = before the draft progresses.
>
> Regards,
> = Dave
>
> = _______________________________________________
> IPsec mailing = list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

= _______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 

------=_NextPart_000_097C_01D40E01.5D55B080-- From nobody Wed Jun 27 08:45:26 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B3130DF2; Wed, 27 Jun 2018 08:45:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153011432387.15378.12718504725148401770@ietfa.amsl.com> Date: Wed, 27 Jun 2018 08:45:23 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 15:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-05.txt Pages : 8 Date : 2018-06-27 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 27 08:46:53 2018 Return-Path: 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 12981130FC7 for ; Wed, 27 Jun 2018 08:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ua0iK9o4RTIQ for ; Wed, 27 Jun 2018 08:46:45 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 9C0B7130E93 for ; Wed, 27 Jun 2018 08:46:44 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t7-v6so2024030ljj.6 for ; Wed, 27 Jun 2018 08:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iGTAq/auIgO2kEXyUJfoculWC+UiFN9uC47HRdVnrNs=; b=EqZoQH1MQg8QTuLR72Zr5RBXrcJ0G51KES6q5O7J4AJYpgoCBPIFjAJ5IwiKmF2dQK JhhIIrbAMwEw6BffC95F0ESohHYXoq1VPTUkQl563+xN68aPrpzeOj9BRhYhHJImGGxp PW/+nAniuRdmLvt66lWOxtn1UCwL1euo7mRhpaBwpb7hLHYQHTu/FlMrskKcot1vFS1t LsNtfGfEm/aVRsClbo17GZXca/zNgIw8Q/zhnGCvXiziBFWiGxeGY4D/cny9lJvSC7uT fk4BYlyJQNVTWqwsBQdiuQAWxwlmBDzDvAtTRErup4SyhvRXLPTVosttSwPtHVL/67+p SVRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iGTAq/auIgO2kEXyUJfoculWC+UiFN9uC47HRdVnrNs=; b=AmAlR9zdgphQwxizfK4VQVPQVK04A4Vk1OmrmRERKGvsxVH1t8cgTADbzNfxtzSRFd LOuRkhac7F2AgN13ts/jo8GJlUSMpKAo6dkLXAxoXiVafEZITu2j1QTjkuhV0JCYTlOJ IcRXZKuyboJY5G03F2IiCDNucyX3a7LVNyrxAb343sbnOES9uDi/gD2sl/pl9e3gGGQv 3RpYwmEc3WErjn6uvd75tb1lSRNDUWVUS3JX/4VAvA47vCAWtp2Frq28Hj28xu2W/a5l GTttgULxcvW7C61XTceGkUoGUixariaJvZIWHyEJDY0cbPG5n/8xmoT9Mdzf2M75lkOQ N89g== X-Gm-Message-State: APt69E2+u39Z3BX8KHDmj7DepyzHNELa+hjhMltvhl5MvgJzRAiRE5p8 UBc5IAegi8nXk/MqIGnfiV9xGTj5ROM3DL/GkWA= X-Google-Smtp-Source: AAOMgpc5DPsneFTFUg58Khw4Dba2zdAPtfbqTRW+S+wwuzB5F3TJVwPQcCMDazFQzq4hOo1EJ7+bBqPsZC8pbtLjvEA= X-Received: by 2002:a2e:500d:: with SMTP id e13-v6mr4376873ljb.70.1530114402875; Wed, 27 Jun 2018 08:46:42 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:4281:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 08:46:42 -0700 (PDT) In-Reply-To: <097b01d40de8$37fdca20$a7f95e60$@gmail.com> References: <08e101d40d50$b5db2610$21917230$@gmail.com> <097b01d40de8$37fdca20$a7f95e60$@gmail.com> From: Daniel Migault Date: Wed, 27 Jun 2018 11:46:42 -0400 X-Google-Sender-Auth: m1Xm7h5_xFOifcZoqKz2YVzyfEY Message-ID: To: Valery Smyslov Cc: IPsecME WG , "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary="00000000000072fdd7056fa1851f" Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 15:46:52 -0000 --00000000000072fdd7056fa1851f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your comments Valery. The new version [1] has teh two paragraphs in the security consideration. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ On Wed, Jun 27, 2018 at 3:26 AM, Valery Smyslov wrote: > HI Daniel, > > > > I still think the =E2=80=9CNOT RECOMMENDED=E2=80=9D wording is a bit conf= using. > > I=E2=80=99d suggest to change this para to be more explicit: > > > > As the IV must not repeat for one SA when Counter-Mode ciphers are > > used, Implicit IV as described in this document MUST NOT be used in > > setups with the chance that the Sequence Number overlaps for one SA. > > Multicast as described in [RFC5374], [RFC6407] and > > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > > one secret and thus one SA. As such, Implicit IV may only be used wit= h > Multicast > > if some mechanisms are employed that prevent Sequence Number to overla= p > > for one SA, otherwise Implicit IV MUST NOT be used with Multicast. > > > > Regards, > > Valery. > > > > > > *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *D= aniel > Migault > *Sent:* Tuesday, June 26, 2018 9:11 PM > *To:* Valery Smyslov > *Cc:* Waltermire, David A. (Fed); IPsecME WG > *Subject:* Re: [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04 > > > > Hi Valery, > > > > Thanks for the feedback. Here are the update I propose. If that is fine > for everyone, I will update the current draft and publish a new version. > > > > Yours, > > Daniel > > > > On Tue, Jun 26, 2018 at 9:22 AM, Valery Smyslov > wrote: > > Hi, > > I reviewed the draft and I believe it is almost ready. However, > I think there still are few issues. > > 1. The last para of section 4 says: > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast. > > I have three problems with this para. First, I think that this para > should be moved into the Security Considerations section. > > > > I am fine having it in the security consideration. Anyone opposed ? > > > > > > Second, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat"= ) > seems to be wrong here, since it is not an imperative, it's an explanatio= n > here > (because the preposition "As" is used; note that the draft has already > stated that the > nonce MUST NOT repeat in the beginning of Section 4). > > > > > > I think that this address your purpose: > > OLD: > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > > NEW > > As the IV must not repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SA. > > > > And last (but not least), > I have some trouble following this para, it seems to me that it is > self-contradicting. > First it says that IIV MUST NOT be used if there is a chance that SN > repeats > (which I fully agree with), then it says that multicast is a prominent > example of this situation (i.e. the situation when SN may repeat, which > I fully agree with too) and finally it concludes that for multicast > IIV is NOT RECOMMENDED (i.e. it SHOULD NOT be used). > In other words it is allowed to use IIV for multicast in some > circumstances, > which in my opinion contradicts with earlier MUST NOT. > Either remove the last sentence, or give more explanation > when it is possible to use IIV for multicast. > > > > OK I see your point. The reason is mostly that we had a quite long > explanation we removed because we went to the details of a solution we do > not standardize. I suggest we simply mention that some means are deployed= . > > > > OLD: > > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast. > > NEW: > > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SA. As such, it is NOT RECOMMENDED to use > Implicit IV with Multicast, unless deployment specific mechanisms > prevent the IV to repeat are provided. > > > > > > > 2. The draft defines IIV for ESP only and forbids to use it for IKEv2. > It was discussed and I believe it is right, but I'd like to see few > words (presumably in the Security Considerations) why IIV > in its current form cannot be used in IKEv2. Something along the lines: > > This document defines three new encryption transforms that use implicit > IV. > Unlike most encryption transforms defined to date, which can be used > for both ESP and IKEv2, these transforms are defined for ESP only and > cannot > be used in IKEv2. The reason is that IKEv2 messages don't contain uniq= ue > per-message value, that can be used for IV generation. The Message-ID > field in IKEv2 header is somewhat counterpart of SN field in ESP heade= r, > but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to > repeat, > so there is no an easy way to derive unique IV from IKEv2 header field= s. > > > > > > I am fine adding the text in the draft. > > > > > Regards, > Valery. > > > > This message starts a working group last call (WGLC) on > draft-ietf-ipsecme-implicit-iv-04, which will conclude > > on June 29, 2018 at UTC 23:59. Please review and provide feedback on th= e > -04 version > > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/). > Please indicate if you believe this draft is > > ready for publication or if you have comments that must be addressed > before the draft progresses. > > > > Regards, > > Dave > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --00000000000072fdd7056fa1851f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments Valery. The new version [1] = has teh two paragraphs in the security consideration.
Yours,=
Daniel


On Wed, Jun 27, 2018 at 3= :26 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:<= br>

HI Daniel,

= =C2=A0

I still think the =E2=80=9CNOT RECOMMENDED=E2=80=9D wordi= ng is a bit confusing.

I=E2=80=99d suggest to change this par= a to be more explicit:

=C2=A0<= /span>

=C2=A0=C2=A0 As the IV must not repeat for one SA when Counter-Mode ciph= ers are

=C2=A0=C2=A0 used, Implicit IV as described in thi= s document MUST NOT be used in

=C2=A0=C2=A0 setups with th= e chance that the Sequence Number overlaps for one SA.=

=C2=A0=C2=A0 Multicast as described in [RFC5374], [RFC6407] and<= u>

=C2=A0=C2=A0 [I-D.yeung-g-ikev2] is a prominent = example, where many senders share

=C2=A0=C2=A0 on= e secret and thus one SA.=C2=A0 As such, Implicit IV may only be used with = Multicast

=C2=A0=C2=A0=C2=A0if some mechanisms are employ= ed that prevent Sequence Number to overlap

=C2=A0=C2=A0 fo= r one SA, otherwise Implicit IV MUST NOT be used with Multicast.<= /u>

=C2=A0

Regards,

Valery.

=C2=A0

=C2=A0

From: m= glt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] On Behalf Of Daniel MigaultSent: Tuesday, June 26, 2018 9:11 PM
To: Valery SmyslovCc: Waltermire, David A. (Fed); IPsecME WG
Subject: Re: = [IPsec] WGLC on draft-ietf-ipsecme-implicit-iv-04=

=C2=A0=

Hi Valery,

=C2=A0

Thanks for the feedback. Here are the update I propose. If t= hat is fine for everyone, I will update the current draft and publish a new= version.

=C2=A0=

Yours,

Daniel

=C2=A0

On Tue= , Jun 26, 2018 at 9:22 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:=

Hi,

I reviewed the draft and I bel= ieve it is almost ready. However,
I think there still are few issues.
1. The last para of section 4 says:

=C2=A0 =C2=A0As the IV MUS= T NOT repeat for one SA when Counter-Mode ciphers are
=C2=A0 =C2=A0used,= Implicit IV as described in this document MUST NOT be used in
=C2=A0 = =C2=A0setups with the chance that the Sequence Number overlaps for one SA.<= br>=C2=A0 =C2=A0Multicast as described in [RFC5374], [RFC6407] and
=C2= =A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders sh= are
=C2=A0 =C2=A0one secret and thus one SA.=C2=A0 As such, it is NOT RE= COMMENDED to use
=C2=A0 =C2=A0Implicit IV with Multicast.

I have = three problems with this para. First, I think that this para
should be m= oved into the Security Considerations section.

<mglt>

I am fine having it in the security consideration. Anyone opposed ?

</mglt>

=C2=A0

Secon= d, using RFC 2119 word in the beginning ("As the IV MUST NOT repeat&qu= ot;)
seems to be wrong here, since it is not an imperative, it's an= explanation here
(because the preposition "As" is used; note = that the draft has already stated that the
nonce MUST NOT repeat in the= beginning of Section 4).

=C2=A0

<mgl= t>

I think that this = address your purpose:

OL= D:

=C2=A0 =C2=A0As the I= V MUST NOT repeat for one SA when Counter-Mode ciphers are
=C2=A0 =C2=A0= used, Implicit IV as described in this document MUST NOT be used in
=C2= =A0 =C2=A0setups with the chance that the Sequence Number overlaps for one = SA.

NEW

=C2=A0 =C2=A0As the IV must not repeat f= or one SA when Counter-Mode ciphers are
=C2=A0 =C2=A0used, Implicit IV a= s described in this document MUST NOT be used in
=C2=A0 =C2=A0setups wit= h the chance that the Sequence Number overlaps for one SA.

=C2=A0

And last (= but not least),
I have some trouble following this para, it seems to me = that it is self-contradicting.
First it says that IIV MUST NOT be used i= f there is a chance that SN repeats
(which I fully agree with), then it = says that multicast is a prominent
example of this situation (i.e. the = situation when SN may repeat, which
I fully agree with too) and finally = it concludes that for multicast
IIV is NOT RECOMMENDED (i.e. it SHOULD N= OT be used).
In other words it is allowed to use IIV for multicast in so= me circumstances,
which in my opinion contradicts with earlier MUST NOT= .
Either remove the last sentence, or give more explanation
when it = is possible to use IIV for multicast.

<mglt>

OK I see your point. The reason is mostly that we had a quite lon= g explanation we removed because we went to the details of a solution we do= not standardize. I suggest we simply mention that some means are deployed.=

=C2=A0

OLD:

=C2=A0 =C2=A0Multicast as d= escribed in [RFC5374], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is= a prominent example, where many senders share
=C2=A0 =C2=A0one secret a= nd thus one SA.=C2=A0 As such, it is NOT RECOMMENDED to use
=C2=A0 =C2= =A0Implicit IV with Multicast.

NEW:

=C2=A0 =C2=A0Multicast as described in [RFC5374], [RFC64= 07] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where m= any senders share
=C2=A0 =C2=A0one secret and thus one SA.=C2=A0 As such= , it is NOT RECOMMENDED to use
=C2=A0 =C2=A0Implicit IV with Multicast, = unless deployment specific mechanisms prevent the IV to repeat are provided= .

</mglt>

=C2=A0

2. The draft defines IIV for ESP only and forbids to use it for IKEv2. It was discussed and I believe it is right, but I'd like to see fewwords (presumably in the Security Considerations) why IIV
in its curre= nt form cannot be used in IKEv2. Something along the lines:

=C2=A0 T= his document defines three new encryption transforms that use implicit IV.<= br>=C2=A0 Unlike most encryption transforms defined to date, which can be u= sed
=C2=A0 =C2=A0for both ESP and IKEv2, these transforms are defined fo= r ESP only and cannot
=C2=A0 =C2=A0be used in IKEv2. The reason is that= IKEv2 messages don't contain unique
=C2=A0 =C2=A0per-message value,= that can be used for IV generation. The Message-ID
=C2=A0 =C2=A0field = in IKEv2 header is somewhat counterpart of SN field in ESP header,
=C2= =A0 =C2=A0but recent IKEv2 extensions ([RFC6311], [RFC7383]) do allow it to= repeat,
=C2=A0 =C2=A0so there is no an easy way to derive unique IV fro= m IKEv2 header fields.

=C2=A0

<mglt>= ;

I am fine adding the t= ext in the draft.

</m= glt>


Regards,
Valery.


> This message starts a working group = last call (WGLC) on draft-ietf-ipsecme-implicit-iv-04, which will conc= lude
> on June 29, 2018 at UTC 23:59. Please review and provide feedb= ack on the -04 version
> (https://datatracker.iet= f.org/doc/draft-ietf-ipsecme-implicit-iv/). Please indicate i= f you believe this draft is
> ready for publication or if you have co= mments that must be addressed before the draft progresses.
>
>= Regards,
> Dave
>
> ______________________________= _________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.or= g/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

=C2=A0


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--00000000000072fdd7056fa1851f-- From nobody Wed Jun 27 12:36:53 2018 Return-Path: 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 75CE5130E9A for ; Wed, 27 Jun 2018 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 aBazNpXSW7dM for ; Wed, 27 Jun 2018 12:36:48 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914C71292F1 for ; Wed, 27 Jun 2018 12:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530128207; x=2394041807; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gk6GXd6EiKWzhF5IZnZGz8lEjY7rnvPC9q0WJ3VfQQs=; b=f+CsUgJGXGR74fH4gwqIg/IFzmrJcL+8+mzm8Lnwyp90tnSu+aGUehqtTxMExxKV 3dODnRU94CHc5uelU6hegrPPhcU+Nv6veRHuA69tcp5rtKSc9H0Hb0/Fg+G3z+V7 YEGuF9thb6y03KUU1PzvK+suWoXUYC/FG476/mVhGhCVof0WfsS6Jt0DrAh9JCY+ wW82lzBrEX04okHDJXbGg3ShyfivslIlyTffiegpDHbucgltWTgvM2u6VpL5CIAP VfyeIV1nZk8Uoespp8KSVz2e4m61mLGIrcxjQZumAXmX2W7di0oXym0rAPmv02g7 RdbpSITUDatEMg9e/m+D1A==; X-AuditID: 11ab0216-c7fff70000002f11-15-5b33e74e4df4 Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 12.41.12049.F47E33B5; Wed, 27 Jun 2018 12:36:47 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PAZ00CA3YHAGDA0@mr2-mtap-s02.rno.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00L00YB7JI00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT) X-Va-A: X-Va-T-CD: e31db92b8c8f5711a33b42a4393a80ac X-Va-E-CD: 2413bb9ef5d3dba75e59f2eb99558cea X-Va-R-CD: bdf41d4ac0defeb0bb05a5d9060bb309 X-Va-CD: 0 X-Va-ID: 80a722ce-8dbe-40aa-9d40-09ea748a3056 X-V-A: X-V-T-CD: d46b7fe6d2e0e85d372e19a774c4b542 X-V-E-CD: 2413bb9ef5d3dba75e59f2eb99558cea X-V-R-CD: bdf41d4ac0defeb0bb05a5d9060bb309 X-V-CD: 0 X-V-ID: 9f61749c-68c3-4b86-b331-48d44f13a131 Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00K00YAAVW00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_05:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAZ00IOQYHAFYB0@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 12:36:46 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <20180621002642.GI4218@localhost> Date: Wed, 27 Jun 2018 12:36:45 -0700 Cc: IPsecME WG , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "Waltermire, David A. (Fed)" Content-transfer-encoding: quoted-printable Message-id: <33D81E4D-2F1C-42F2-BB65-62C985140A2E@apple.com> References: <20180619183459.GC4218@localhost> <20180619224651.GD4218@localhost> <20180619230148.GE4218@localhost> <23338.46863.5452.257270@fireball.acr.fi> <20180620220624.GH4218@localhost> <23338.59850.426646.482306@fireball.acr.fi> <20180621002642.GI4218@localhost> To: Nico Williams , Tero Kivinen , Eric Rescorla , Paul Wouters X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR3PyoTdf/uXG0wanZ4hYbe/6xWRztd7ZY 8focu8X+LS+AvPPP2SxOXTvCZvH+1iUmB3aPl6fOMXosWfKTyePw14UsHtdO/mX1+D6PyWPy 4zbmALYoLpuU1JzMstQifbsErox737cxFazkqbiz7iNzA+Nlzi5GTg4JAROJ25tuMXcxcnEI CRxkknh2v5MJJMErICjxY/I9li5GDg5mAXWJKVNyIWrWMUk0d3xkg3C6mCRaXi1ngZjELvHn 1w4oW1ti/dF9bDD2tL2fGWHsSRcPQ8W5JBZsPc0KYetK/Dy5mB3CZpNYf2IJE4StJTFr5Vk2 GPvF8T3sMPbkPduhejklzn+ZCBXXkTh2aiELxHGdTBL3bm2GOihbYunbeYwg30gIBEvsf6sM UbOYSeLFlDnsIHFhAQmJzXsSQcqFBYwk3qz4AXYzm4CKxPFvG5hBbE4BPYklxxeC3cYioCrx +cRJdpA5zALbGCWe9h0HK2IGevLJuwuskFC0kZi2+T4TxLL5LBLr7h8Du05EoJ1RYvrPbywT GBVnIQX3LERwz0IyawEj8ypG4dzEzBzdzDwjI73EgoKcVL3k/NxNjKB0s5pJbAfjvdeGhxgF OBiVeHgDuoyjhVgTy4orcw8xSnOwKInzftwlFi0kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB cYaTtbv7CeZ/l7Ijy9s7j12v0NaujjjBurj1xsT1j9/aZ2ZYiWoty7vmEPNiuvi9cA+uxel6 TpnRtx8JbduVXi+8xWon8yszDk27Lcrt0qZ1U1e2qDVIxs/YIpvcuVvyi7E005mpysWK3U7X Vsyf5Cj9Y/8r60fZkoZsX/q+nXmmzxfwfl2HEktxRqKhFnNRcSIACkDaiBgDAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 19:36:51 -0000 It seems like the conversation here stalled out a bit. =46rom my perspective, the feeling in the working group is that the = functionality described in the document for dealing with Split-DNS and = DNSSEC is the best thing we can do given enterprise deployment models, = as long as it is clear that client must validate TAs against configured = local policy. I think the text that Paul added recently does aim at clarifying this = point. Are there specific nits or changes we want to see in the text = there? I=E2=80=99d like to see this document be able to progress soon in = a way that everyone is satisfied with. Thanks, Tommy > On Jun 20, 2018, at 5:26 PM, Nico Williams = wrote: >=20 > On Thu, Jun 21, 2018 at 02:56:58AM +0300, Tero Kivinen wrote: >> Nico Williams writes: >>> On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote: >>>> So I think the feature that we can use TLSA records in the = split-dns >>>> is very important. I agree that it would be VERY BAD for the client = to >>>> just accept whatever domains server sends, and it SHOULD always = verify >>>> it against its local configuration. >>>=20 >>> Agreed. >>>=20 >>> But I also think that a REQUIREMENT that the client support and = check >>> local policy as to which domains to accept TAs for is sufficient to >>> address the concern. Isn't it? >>=20 >> Yes and no. >>=20 >> Yes, I think that is best we can do. >>=20 >> [...] >=20 > Agreed. >=20 > Now, is the concern enough to reject this I-D? >=20 > Nico > --=20 From nobody Wed Jun 27 18:01:31 2018 Return-Path: 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 4E011130E69; Wed, 27 Jun 2018 18:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 91mfQliURThx; Wed, 27 Jun 2018 18:01:26 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45910130E63; Wed, 27 Jun 2018 18:01:26 -0700 (PDT) X-AuditID: 12074425-183ff70000000427-16-5b343364f897 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id BE.05.01063.563343B5; Wed, 27 Jun 2018 21:01:25 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w5S11NnL008668; Wed, 27 Jun 2018 21:01:23 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5S11Hk8006778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jun 2018 21:01:19 -0400 Date: Wed, 27 Jun 2018 20:01:16 -0500 From: Benjamin Kaduk To: Paul Wouters Cc: Eric Rescorla , "draft-ietf-ipsecme-split-dns.all@ietf.org" , Tero Kivinen , IPsecME WG , "Waltermire, David A. (Fed)" , Nico Williams Message-ID: <20180628010116.GA1173@kduck.kaduk.org> References: <20180619230148.GE4218@localhost> <20180620193225.GL4946@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixCmqrZtqbBJtMGk1r8XGnn9sFkf7nS1W vD7HbrF/ywsg7/xzNotT146wWby/dYnJgd3j5alzjB5Llvxk8jj8dSGLx7WTf1k9vs9j8pj8 uI05gC2KyyYlNSezLLVI3y6BK+P6xTPMBVftK6b8nsbSwPjUqIuRk0NCwERi/Y9HrCC2kMBi JomPe60g7I2MEtsWJHYxcgHZV5kkmnb1MIEkWARUJRau/sUCYrMJqEg0dF9mBrFFBBQlJp15 xALSwCywi0niyon5bCAJYQEjiTcrfjCC2LwCxhIz9pxigZh6jkXi+dZPTBAJQYmTM5+ATWUW 0JK48e8lUJwDyJaWWP6PAyTMKeAoceLmE7BLRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KU Tcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSndxAgKfnYX1R2Mc/56HWIU4GBU4uEN6DKO FmJNLCuuzD3EKMnBpCTKy/EYKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV+I+UI43JbGyKrUo HyYlzcGiJM6bs4gxWkggPbEkNTs1tSC1CCYrw8GhJMFrZ2QSLSRYlJqeWpGWmVOCkGbi4AQZ zgM0XA2khre4IDG3ODMdIn+K0ZhjxvbJk5g5/ryfOolZiCUvPy9VSpx3oSFQqQBIaUZpHtw0 UAKTyN5f84pRHOg5Yd49IFU8wOQHN+8V0ComoFWu7UYgq0oSEVJSDYw+r6+rcrRsu3KDz+iv Te9r3e1xAZfXrjw4uX1/z67C2K6uVK2Wl8W75v2ofiTQfnC7zVM7AZV7zkabkyMu9O3WCm4X u/v8rn6D4evJi375m3AbiUW8cP/8NcJWuLTu36dJJQ4SB3I8Eu4ySm3f5mWbdfrZyXlHa1db GKc/COzLtaw6pzX9fLYSS3FGoqEWc1FxIgA1gJbSOwMAAA== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:01:30 -0000 Sorry for the slow response; several things colluded to keep me unavailable. For bonus fun, mutt crashed trying to send this so I get to try to reconstruct from scrollback history. Hopefully nothing important gets garbled along the way... Do note that this is not really my area of expertise and is also not a WG I'm responsible for, but I'm trying to help brainstorm a way past this apparent impasse. On Wed, Jun 20, 2018 at 03:55:02PM -0400, Paul Wouters wrote: > On Wed, 20 Jun 2018, Benjamin Kaduk wrote: > > > This seems like the main fear, yes, but perhaps not exclusively so. > > It's kind of how users "always" click through certificate warnings in > > browsers, or "alway" grant a mobile app all the requested permissions. > > If, to expand unreasonably upon a previous example, connecting to the Red > > Hat VPN wanted to take over redhat.com, openstack.com, rhbz.com, > > rhmail.com, rh.zone, redhat.googleapps.com, rh.googleapps.com, > > realham.googleapps.com, freeipa.com, freeipa.org, and centos.org, is it > > reasonable to expect the user to look at the list and pick out > > "realham.googleapps.com" as not belonging? Maybe they think it's a > > codename for some Red Hat project, but maybe it's something totally > > unrelated and reflects overreach by the VPN provider. > > If you are thinking of such a large list, then this information could be > conveyed via the Enterprise VPN Profile that the user must install. Then > you could either not allow any changes from that profile without updating, > or you could decide as a client to present only new names to the user. > This is all local policy between enterprise server and client. Just like > the mandatory use of some algorithms can be (and are) set in those profiles. Sure ... and local policy between the enterprise server and client could also have the ability to actually show the list to the user. (There's not really a great reason for the enterprise to choose to do so, but if we're hiding behind "local policy matter", we can keep our options open.) > > It seems to border on unreasonable to have such a long list and expect user > > knowledge. On the one hand, the VPN provider "ought to know" what domains > > it's responsible for (and are on the internal view), but on the other hand > > this is essentially a self-certification and does not inherently have any > > level of trust. It would be great if there was some third party that could > > provide some certification that the list of controlled domains is valid, or > > at least not present in the public view > > Names might be present in the public view and private view. That is not > a valid criteria. It's not entirely clear that a true third party would be needed. Perhaps a cross-signed (by public and private keys) statement of joint ownership could be visible in the private DNS, for example. Yes, that's a logistical hassle to arrange, but we're still in the "is the crypto possible" stage for this question and can optimize eventually. > > and controlled by someone else > > If you solve the Public Suffix list problem, there are more people > interested in how they can use that information :) Although again, > draft-pwouters-powerbind comes close to offering that functionality. So, at some philosophical level, the public Internet is "more important" for IETF standards than private Intranets. Yes, it would be nice if our Internet protocols can be used elsewhere, but in lots of places we use as criteria "benefit the public Internet", "not harmful to the public Internet", etc.. It may seem that in a case where there is conflict between the public Internet and the private enterprise Intranet (e.g., when the same name is controlled by a different entity in the two locations) that we the IETF are obligated to prefer the public Internet. I'm not generally a huge fan of trying to use one IETF protocol as a forcing function for some other change we want to see, but sometimes it happens, and "if you want TLSA in the enterprise you can't have it for random namesquats that mean something else in public" may be a valid case. Does the public suffic list necessarily come into play? If I walk up the hierarchy looking for the same DNS key in both views, then force the first level of divergence to have some authorization for the private view, would that work? > > (since there will presumably be cases when internal names are not expected > > to be visible in the public view at all). I'm not coming up with a great > > technical solution off the top of my head, though. "Something in the public > > DNS" might work, if you can forgive the incredibly vague idea. > > That would mean publishing something about private domains in the public > dns and worse publishing something in the parent zone about child zones, > which would be next to impossible for second level domains. Sure. "Put it in the public DNS" is approximately the first easy thing that came to mind. What about my other proposal above? > >> know how common this new behaviour would be and how reasonable it is > >> for a client to understand what is happening. I cannot answer how common > >> this would be other than stating in the past this wasn't possible at > >> all. And that client understanding could be presented cleanly and I gave > >> an example. > > > > I think it will be very common for users to "click through" without > > actually looking at the list, with fairly high confidence. I expect (but > > at a lower level of confidence) that it will also be common for enterprises > > to have lists of more than three domains in the internal view. > > If you do not make this option available at all, then the only option > for the enterprise VPN's are: > > - Conveying this information hardcoded in installation profiles without > any user visibility or negotiation/rejection posibility See my previous note about "local policy", which has no technical reason to prohibit user visibility. > - Demanding to just get all DNS traffic despite being a split-tunnel > VPN, at the expense of the user's privacy when doing DNS lookups for > things that are not supposed to go into the VPN tunnel. Possibly > requiring the user disables DNSSEC completely. Yes, this is bad. > Note also that the harm that can be done with realham.googleapps.com is > basically the same as with any typosquat domain name, like me getting > rhel.googleapps.co or realham-googleapps.com. I think that is not the > real issue here. The issue is missing facebook.com, twitter.com or > gmail.com in a long list of domains. And those would have a much higher > chance of being seen as inappropriate. > > If it helps we could limit the number of INTERNAL_DNS_DOMAIN payloads > or INTERNAL_DNSSEC_TA payloads allowed to put an artificial cap on > these lists. I personally don't think we should, but I wouldn't object > to one either if it is not too low. That doesn't seem like a great plan to me, either, though I suppose I could live with it if it ends up being the consensus proposal. -Ben > > The reality is that using an Enterprise VPN means letting the > enterprise control part of your machine. If the enterprise is malicious > or incompetent, than there is nothing you can do as enduser. If > anything, allowing this draft gives the VPN client a better chance to > compartmentalize what it gives the Enterprise VPN. It is simply not > different from the mandatory enterpise CA and/or anti-virus you have > to install. If you think that risk is too high, you should not use the > enterprise hardware for anything not related to the enterprise, and BYOD > for personal matters. > > To greatly reduce any abuse, the draft disallows any of these CFG > payloads for those VPNs that are not split and take all traffic. If the > VPN client is using its own validating resolver, the remote VPN cannot > falsify any TLSA records. This covers the use case of all commercial VPN > providers out there, some of which are pretty malicious.