From nobody Sun Apr 3 11:39:33 2016 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 DBD9912D1E2 for ; Sun, 3 Apr 2016 11:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 WOhr6HB5Uk1v for ; Sun, 3 Apr 2016 11:39:30 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79DC12D642 for ; Sun, 3 Apr 2016 11:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1459708770; x=2323622370; 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=l4UHurYq6/ZSPFh16sRFCU/YOszT4hVhspkfzolClkY=; b=BOmv/EUYmH0YmwtXnGxCoENTPTIP3btGPTzH1V6a5IkUG9Q4hsrNNBcI9djJh4Ve EGgriVu4Cu+xek79qzrA5UzKDUzqgPHqJiQmP2ioCWC65w1Iw2IaCqc4DhA+I1/c bgF1JYSUgeK3PkxukzotKkJENbbhU5BmaMz+20ow2VOfVbOwWvV45H7XSmWxoWh7 q2vlVclpsZNW9ZZToRMT4awqbKQVqieeE2tAA93Z8FTBUTvY52aj0OPm73JfKqXN ziolXXR7AUiskCQRq4hXywkJ8T8LgMCgzbyShQTObJuwMmi/8ThtAZhJFe/FBJFw mrLsmosiPiDPI5Jvq5DmvA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 0E.43.27179.26361075; Sun, 3 Apr 2016 11:39:30 -0700 (PDT) X-AuditID: 11973e15-f79686d000006a2b-66-570163624139 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id AD.FA.23128.26361075; Sun, 3 Apr 2016 11:39:30 -0700 (PDT) Received: from [17.168.173.28] (unknown [17.168.173.28]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O520099EMHLTA30@nwk-mmpp-sz12.apple.com> for IPsec@ietf.org; Sun, 03 Apr 2016 11:39:30 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_A069B5EF-DD83-454B-B0CE-688BC8902D96" MIME-version: 1.0 (Mac OS X Mail 9.3 \(3117\)) From: Tommy Pauly In-reply-to: <2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0@eusaamb107.ericsson.se> Date: Sun, 03 Apr 2016 15:39:20 -0300 Message-id: <45C85A6B-0816-411F-9183-73309F7D6A08@apple.com> References: <2D1BA3CFD799FD44A1F3650A84C4000F1233D4F0@eusaamb107.ericsson.se> To: Khanh Tran , Daniel Migault X-Mailer: Apple Mail (2.3117) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FDorJuUzBhu8OeGisX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVced+L3PB+kuMFcdvr2NsYJyylbGLkZNDQsBE4sKd6ewQtpjE hXvr2boYuTiEBPYySmz52QhUxAFW1H4hD6RGSGA5k8SFH+UQNfOYJL50LgarERaQkNi8JxGk hlkgSeLYk6WsIDavgJ7E3LsnwWxhgQiJowcvMIHYbAIqEse/bWAGsTkF/CQ2XnoBdg+LgKrE m869bBBzVCXmH/sBNcdGomPNBXaIG3wl7j5/DDZHRCBK4uDlKcwQZ8pK9H7LATlNQmALm8Sh KbNZJzAKz0Jy0iwkJ0HEtSWWLXzNDGFrSuzvXs6CKa4h0fltIusCRrZVjEK5iZk5upl5ZnqJ BQU5qXrJ+bmbGEHxMN1OdAfjmVVWhxgFOBiVeHhfuDOEC7EmlhVX5h5ilOZgURLn/fbzX5iQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxhh3jrbTAU9Cs61beV7eE90WV9d8a+O11wc1F+y3 ePQ6uvR3WABTgFGdddGNTv7P/ypLuH+LJGjlLtD3/in14BzLvgr3KMezslfqHNIbPdbs9VtY mBfBwuxTut1FY/+xOZMkF0WtmO6Y92Pb9JN2E95qrOC4m6a9L9HTL9xlV//+d7IGvY/alFiK MxINtZiLihMBcM0gX2gCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUi2FB8RjcpmTHcYPsnOYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4879XuaC9ZcYK47fXsfYwDhlK2MXIweHhICJRPuFvC5GTiBT TOLCvfVsILaQwHImiQs/yrsYuYDseUwSXzoXg9ULC0hIbN6TCFLDLJAkcezJUlYQm1dAT2Lu 3ZNgtrBAhMTRgxeYQGw2ARWJ4982MIPYnAJ+EhsvvWAEsVkEVCXedO5lg5ijKjH/2A+oOTYS HWsusEPc4Ctx9/ljsDkiAlESBy9PYYY4WVai91vOBEaBWUiumIXkCoi4tsSyha+ZIWxNif3d y1kwxTUkOr9NZF3AyLaKUaAoNSex0kgvsaAgJ1UvOT93EyM4fAuddzAeW2Z1iFGAg1GJh/eF O0O4EGtiWXFl7iFGCQ5mJRHe9fGM4UK8KYmVValF+fFFpTmpxYcYJzICPTmRWUo0OR8YXXkl 8YYmJgYmxsZmxsbmJua0FFYS51UNAbpIID2xJDU7NbUgtQjmKCYOTqkGRhVXP41JN2KOCa3x krHkU+K+c/xCFeeMjl1HpNe1ySsm+sqeWlXCGNnzTGxTvqTM2syThj/WyYmzdARorPWVOCbc +/Zx/MGjXGGCa0WXpazOPNLWqvzlgPJDpwYnn7SwHdFm52M9uPmuFIdF/Hio8UbkZ/HRqZIy AgsylzRtyZm7PvUow0cOJZbijERDLeai4kQAjn8c2NICAAA= Archived-At: Cc: "IPsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 18:39:33 -0000 --Apple-Mail=_A069B5EF-DD83-454B-B0CE-688BC8902D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, Thanks for working on this YANG model! I=E2=80=99m including some = general points of feedback of typos and missing topics in the IKEv2 YANG = document. Section 3.1 has typos. This should be request/response pairs, not = request/request: . Peer Request MESSAGE ID stores the Message ID of the last request received by the peer. . Peer Request MESSAGE ID stores the Message ID of the last response received by the peer. . Local Request MESSAGE ID stores the Message ID of the last request received by the local host. . Local Request MESSAGE ID stores the Message ID of the last response received by the local host. In Section 3.2, you refer to =E2=80=9CAuthorized DH=E2=80=9D. This term = seems confusing, since it sounds like it should be some official term in = IKEv2. It seems that you are just referring to a list of selected DH = groups that the peer is willing to negotiate. The comment you have = regarding the relationship of the DH group to the KEi payload, "RFC7296 = this MUST be the DH Transform used in the KEi=E2=80=9D, should also be = more clear. The KEi payload will be based on the predicted/preferred DH = group; however, the proposals may include other DH groups that will be = used after an INVALID_KE_PAYLOAD exchange. Section 3.4 capitalization error: "Note that The definition=E2=80=9D=E2=80= =A6 Your coverage of IKE_AUTH (Section 3.4) mentions CERT for = authentication, but not Shared Secret or EAP. EAP particularly is a very = important part of how credentials need to be configured, and how the = exchange will ultimately work. The coverage of Configuration Request and Reply also seems to be = missing. I see this mentioned: | | +--rw config-request | | | +--rw (ip-address)? | | | +--:(ipv4-address) | | | | +--rw ipv4-address? inet:ipv4-address | | | +--:(ipv6-address) | | | +--rw ipv6-address? inet:ipv6-address However, this only includes two of many types of configuration = attributes. Please include all of them, and make sure to specify the = address encoding correctly. For example, while IPv4 addresses are just 4 = octets, IPv6 configured addresses use 17 octets (address + prefix len). Thanks, Tommy > On Mar 29, 2016, at 5:22 PM, Khanh Tran = wrote: >=20 > Hi Paul, > =20 > Below are my comments to your questions that are relating to = draft-tran-ipsecme-ikev2-yang-00.txt. > =20 > Q1: What does all right reserved means? I think the question beyond = that is how the YANG model can be used, and who owns it? Can you respond = to this? > A1: Yes, we will remove the following description: > " Copyright (c) 2016 Ericsson AB."+ > " All rights reserved."; > =20 > =20 > Q2: leaf initial-retransmission-timeout I think that the question is = how do we specify units in the YANG model. Is that something that is = part of the YANG model? I think we should also ask if the WG would like = us to add different ways to express there transmission time out? =E2=80=93= I can respond to this question if you prefer. > A2: yes, we can specify the unit for this attribute (I assume the unit = will be =E2=80=9Cmiliseconds=E2=80=9D) =20 > Ex: > leaf initial-retransmission-timeout { > type uint32; > units "miliseconds"; > default 100; > description > "initial retransmission timeout value"; > } > =20 > leaf nat-keepalive-interval { > type uint16 { > range "5..300"; > } > units "Seconds"; > default 20; > description "NAT detected and keepalive interval"; > } > =20 > =20 > Q3: How YANG can be updated when IANA registries are updated. I think = also some text could be added into the draft for that. =E2=80=93 Can you = respond to this? > A3: yes, we can add the text in the draft for reference to IANA. When = IANA registries are updated, the YANG module should be notified for = changes and update accordingly. > =20 > =20 > Best regards, > Khanh Tran > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_A069B5EF-DD83-454B-B0CE-688BC8902D96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
Hello,

Thanks =
for working on this YANG model! I=E2=80=99=
m including some general points of feedback of typos and missing topics =
in the IKEv2 YANG document.

Section 3.1 has typos. This should be request/response pairs, =
not request/request:

     . Peer Request MESSAGE ID stores the =
Message ID of the last
        request received by the peer.
     . Peer Request MESSAGE ID stores the Message ID of the last
        response received by the peer.
     . Local Request MESSAGE ID stores the Message ID of the last
        request received by the local host.
     . Local Request MESSAGE ID stores the Message ID of the last
        response received by the local host.

In Section 3.2, you refer to =E2=80=9CAuthorized =
DH=E2=80=9D. This term seems confusing, since it sounds like it should =
be some official term in IKEv2. It seems that you are just referring to =
a list of selected DH groups that the peer is willing to negotiate. =
The comment you have regarding the relationship of the DH group to the =
KEi payload, "RFC7296 this MUST be the DH Transform used in the =
KEi=E2=80=9D, should also be more clear. The KEi payload will be based =
on the predicted/preferred DH group; however, the proposals may include =
other DH groups that will be used after an INVALID_KE_PAYLOAD =
exchange.

Section 3.4 capitalization error: "Note that The =
definition=E2=80=9D=E2=80=A6

Your coverage of IKE_AUTH =
(Section 3.4) mentions CERT for authentication, but not Shared Secret or =
EAP. EAP particularly is a very important part of how credentials =
need to be configured, and how the exchange will ultimately =
work.

The coverage of Configuration Request and Reply also =
seems to be missing. I see this mentioned:

      |  |  +--rw =
config-request
      |  |  |  +--rw (ip-address)?
      |  |  |     +--:(ipv4-address)
      |  |  |     |  +--rw ipv4-address?   inet:ipv4-address
      |  |  |     +--:(ipv6-address)
      |  |  |        +--rw ipv6-address?   inet:ipv6-address

However, this only includes two of many types =
of configuration attributes. Please include all of them, and make =
sure to specify the address encoding correctly. For example, while =
IPv4 addresses are just 4 octets, IPv6 configured addresses use 17 =
octets (address + prefix len).

Thanks,
Tommy




On Mar 29, 2016, at 5:22 PM, Khanh Tran = <khanh.x.tran@ericsson.com> wrote:

Hi Paul,
 
Below are = my comments to your questions that = are relating to draft-tran-ipsecme-ikev2-yang-00.txt.
 
Q1: What = does all right reserved = means? I think the question beyond that is how the YANG model can be = used, and who owns it? Can you respond to this?
A1: Yes, we will remove = the following description:
       " Copyright (c) 2016 Ericsson AB."+
       " All rights = reserved.";
 
 
Q2: =   leaf initial-retransmission-timeout I think that the = question is how do we specify units in the YANG model. Is that something = that is part of the YANG model? I think we should also ask if the WG = would like us to add different ways to express there transmission time = out? =E2=80=93 I can respond to this question if you prefer.
A2: yes, we can specify = the unit for this attribute (I assume the unit will be = =E2=80=9Cmiliseconds=E2=80=9D)  
Ex:
         leaf = initial-retransmission-timeout {
           = type uint32;
           units = "miliseconds";
           default = 100;
         =   description
          &nb= sp;  "initial retransmission timeout value";
         }
 
         leaf = nat-keepalive-interval {
          &nb= sp;  type uint16 {
          &nb= sp;    range "5..300";
          &nb= sp;  }
          &nb= sp;  units "Seconds";
          &nb= sp;  default 20;
          &nb= sp;  description "NAT detected and keepalive interval";
         }
 
 
Q3: How YANG can be updated when IANA = registries are updated. I think also some text could be added into the = draft for that. =E2=80=93 Can you respond to this?
A3: yes, we can add the = text in the draft for reference to IANA.  When IANA registries are = updated, the YANG module should be notified for changes and update = accordingly.
 
 
Best = regards,
Khanh = Tran
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_A069B5EF-DD83-454B-B0CE-688BC8902D96-- From nobody Mon Apr 4 11:04:18 2016 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 0CF1D12D0B0 for ; Mon, 4 Apr 2016 11:04:16 -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 RAWSjdI1tbIK for ; Mon, 4 Apr 2016 11:04:13 -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 BAFBD12D146 for ; Mon, 4 Apr 2016 11:04:12 -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 u34I48Im000091 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Apr 2016 21:04:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u34I48p7029485; Mon, 4 Apr 2016 21:04:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22274.44184.910555.330242@fireball.acr.fi> Date: Mon, 4 Apr 2016 21:04:08 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] 3gpp Firewall Travelsal Tunnel (FTT) Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:04:16 -0000 We have already allocated FTT_KAT configuration parameter for IKEv2 for the 3GPP FTT protocol, and it is described in the TS 24.302 12.6.0 "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3". That document can be found from: http://www.3gpp.org/DynaReport/24302.htm -- kivinen@iki.fi From nobody Mon Apr 4 12:26:08 2016 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 9D02A12D0C1 for ; Mon, 4 Apr 2016 12:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OP-JH39WVPKD for ; Mon, 4 Apr 2016 12:26:06 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 CC5BB12D13A for ; Mon, 4 Apr 2016 12:26:05 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id p188so159084873lfd.0 for ; Mon, 04 Apr 2016 12:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=CkNMvzzd/2g5qN/Js/99ZhNzSkFRieIP3dJBcxdFkXk=; b=FBilwr84r6VCq/BY9/JfT0pjM0PRPffQId2rl2k7diCOUh6XjQ44aqIatuCKLEtZdx foYuCs09fGfPzozB2F1DhkTuBfXGyFdGxqiUQfg73lUKqGtD2qBuRVcI4751KExU/ttX p8Kwl+4ddXz91Tnl0kqRflHoo+DzKdgS77H6H1ay6814c6yWDIZ85V/1FOlB9t9WB37b WA+bIIHp8E+hJfQs4ih88BkxBgHUdkKTmsRwwwlPzSbqheQ18rnNCEH3QIP+rYTNvuYG vucjRsoEf7rAGHlNSwuLSSTvMu+/QND+tCN73GkWvOrtFhC5Qp6UHBRwikykDe9K7+KM jUvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=CkNMvzzd/2g5qN/Js/99ZhNzSkFRieIP3dJBcxdFkXk=; b=FUkb8Bs2onRSq0vv4c7HeZPLig/mziVufgIGzkkiykgOWOt1x0D039bbRvnsUGeizL LtO1hJDlDW2oW2NwMZIqlYsz0ZB6zYrd327PBBj64sE7NuGWTjgezVtm7AnRIBqvrdHh tbvTArkFA2WlT9S6WxBThdCmSO2Vsrc8Z/uUYrgAvBjfbTJCim8/f/ycGOF5VWF8DbHA lcg7QdqkAMxUqo1QtB/mx2G4CoQzes7xglou693qGixLRlnDkO4HbG+BMU+NRaf9uogP QtL0psijzNlmOJzZLRcSgdQiU4v+5+TK+2YVYhFNvojF1mKuZlIiwyc2iPpUb/VIyjMd agbg== X-Gm-Message-State: AD7BkJI95ru3w02lqyujhUoF2NQ5R+X6rdz0ml9XMMGC2Zvj6i0sAcaBEpyI6JMROgsRBrps434DfSdJIjWhnA== MIME-Version: 1.0 X-Received: by 10.194.184.234 with SMTP id ex10mr19098002wjc.8.1459797963709; Mon, 04 Apr 2016 12:26:03 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.171 with HTTP; Mon, 4 Apr 2016 12:26:03 -0700 (PDT) Date: Mon, 4 Apr 2016 16:26:03 -0300 X-Google-Sender-Auth: drOmAz3MgpBy67N_OeVV4BtdSdM Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86cc1e12244c052fadb33c Archived-At: Subject: [IPsec] Phone found in the ipsecme meeting room X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:26:07 -0000 --047d7b86cc1e12244c052fadb33c Content-Type: text/plain; charset=UTF-8 --047d7b86cc1e12244c052fadb33c Content-Type: text/html; charset=UTF-8

--047d7b86cc1e12244c052fadb33c-- From nobody Mon Apr 4 12:43:29 2016 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 A1F4F12D82A for ; Mon, 4 Apr 2016 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 3EUQaqdGwapm for ; Mon, 4 Apr 2016 12:43:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 E151012D821 for ; Mon, 4 Apr 2016 12:43:25 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id c6so32571620qga.1 for ; Mon, 04 Apr 2016 12:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=LHs2Mxi7oQj8L1bjoYtb2g01lPvxnKjuX6ORCZb+Q54=; b=RAKosodsHy9JiHWX4zTj+LRag08Xk5q9WKlXvxxs+dKoWL96KgR+qR79p1JrGmZOMP xA79WK+ls+ROJYvsvNgUDPTuft/SMJZ5VnMo7KNNBWZfkd5F5rXee/tD8xV5I0rl4GEN c8kRJwdlNGXEUf7aqI3+5Ar0Kdr0u1nFS+1Gx8tKBtTHy1koS9OtageFVAf/ow8Wpp5s ej5ivQnVOScm0mgBz9d6DFfvnFeo7WWTqZMtqX5+zcVK3oNJfvcC4X2nbsVAXJUXXS/X sTMMnmsNa8hcmXMSQTjccZ3ZSJc0nVVwMYkAcv8v6TIpLXYKcIwjr2AsLeRkJCm0Ayji 7Fdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=LHs2Mxi7oQj8L1bjoYtb2g01lPvxnKjuX6ORCZb+Q54=; b=RSSIsWtswYtpdqMWWM0JpVx2b5/QzRTzvWB7ZBvPLMkJ28PiaF3BAXDuldbi3Urb+H wUmfJGjNU6QDSi1cX17MsLwWck8fvFyclhjdUyHXAN0jmyeIkeTNnSUmXUjGifap8tNG jjgI2P8UfuuLNHnDzVz5zyOGnQq0DNx965W/NdjzWRHb6i5zVb3ZvV0VyM90XuS7WBX8 ksBaSbYBvsZVXjw5MYWKV0vAWCBzTPTYBiFrqOIHXPsUozpHqYzJAprvnmb1SqE+hfNB RVsbKV6tWgqvXGKhR074vjmiROsqXL3T4B4Yf4oBTzyDQDdNP+Feij3+Rlkwzx98kMc+ pryA== X-Gm-Message-State: AD7BkJL0AqJcVSj5khPKFd663jDmCaZe2AS8+2ehH3ixVv2YuDBNfeB/sa5Tgn7lChYY6w== X-Received: by 10.141.6.9 with SMTP id i9mr14328590qhd.21.1459799005109; Mon, 04 Apr 2016 12:43:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:51ff:def7:6959:c079? ([2001:67c:370:160:51ff:def7:6959:c079]) by smtp.gmail.com with ESMTPSA id 64sm12981626qgy.34.2016.04.04.12.43.24 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 04 Apr 2016 12:43:24 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> Date: Mon, 4 Apr 2016 16:43:22 -0300 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:43:27 -0000 Hi At the meeting today, I presented the SafeCurves draft status and asked = the room whether we wanted to wait for CFRG and Curdle to settle their = respective RFCs. The room was unanimously in favor of not having = anything in the current draft, instead using RFC 7427 digital = signatures. To be certain if we *did* wait, we=E2=80=99d just list the = two OIDs from Curdle that we like (the non-prehashed ones). Quoting from the Curdle draft, they have this: id-Curve25519 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.1 = } id-Curve448 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.2 = } id-Curve25519ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.3 = } id-Curve448ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.4 = } In other news, it turns out that we still have some discussion to go = with 4307bis. So I suggest that we add these to table 9 of section 4.2 = there as follows: +------------------------------------+------------+---------+ | Description | Status | Comment | +------------------------------------+------------+---------+ | RSASSA-PSS with SHA-256 | SHOULD | | | ecdsa-with-sha256 | SHOULD | | | sha1WithRSAEncryption | SHOULD NOT | | | dsa-with-sha1 | SHOULD NOT | | | ecdsa-with-sha1 | SHOULD NOT | | | RSASSA-PSS with Empty Parameters | SHOULD NOT | | | RSASSA-PSS with Default Parameters | SHOULD NOT | | | sha256WithRSAEncryption | MAY | | | sha384WithRSAEncryption | MAY | | | sha512WithRSAEncryption | MAY | | | sha512WithRSAEncryption | MAY | | | dsa-with-sha256 | MAY | | | ecdsa-with-sha384 | MAY | | | ecdsa-with-sha512 | MAY | ?SHOULD | | id-Curve25519 | MAY | | | id-Curve448 | MAY | | | id-Curve25519ph | MUST NOT | | | id-Curve448ph | MUST NOT | | +------------------------------------+------------+---------+ What do others think? Yoav= From nobody Tue Apr 5 07:10:01 2016 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 C38AC12D587 for ; Tue, 5 Apr 2016 07:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 9bRhv2zt9bJv for ; Tue, 5 Apr 2016 07:09:59 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 BABA712D59A for ; Tue, 5 Apr 2016 07:09:54 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id c6so11044584qga.1 for ; Tue, 05 Apr 2016 07:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WwY3Ak6cyvCp1saJgVGjkMvRKzGxzLRud7fTF1qk02I=; b=BSEyR7RYpi88S2czF2taiu8cBqMyhS9C9pas6mOjuehyWtPkw18GF+LemLoEa8Xogi F/jXkHdUCoCN4qM0Jx8dNhs3hMxlMB6R/ExNW/YaCKDCQyDhStoli2+W3UQwvRIKJt8n VNNyN8FYGXKfi+eqKm1s+i6UFUNL4f3iRCsF1RFeqrptDOFzYUMVUJvQRHuVGZ5uABgF Nswz7DZ2k9GmsmjPBMPi19j5wAWG4KIa+Afd8ciAlrBbjHJ02vrXxi6602qdrkc7rkWi BraXUQmTEMjVtOHdZuHj3//qnEW7Xgof5JERmMTrVzCUytkID/r5ea1DN0AG+3iRMPLa zcow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WwY3Ak6cyvCp1saJgVGjkMvRKzGxzLRud7fTF1qk02I=; b=NcHObTZBlSCp75UkuJLinLjxQf265mxoWMOLFKrG94jyZOxYbXXaX1l5YN0MNH28UX GLXDAKqOKiO1NFvDl50LjqekVhbnGqQ6zlSSsnMiRtTe98l+uXr8Sv3MkP2++Crt/eNl 92bftfazWS6Gnr8AvyGlwpO+B5WdeFOBsYPdPRMeBsmcJyfNeCCK1pQM9aVXEvMFUgJx BVkDNfrc53nMs/qjZU4lt/fGAxSbe4l3bN3e/Rjhj1IRp4+J+s+Vq5/++6Mx8kx1j3RE saqcphMRTeDhSXe14HJk94Z73+UFb4Wq/kymlF4O0oKKANTeSPIXPdv9DHXJU9aJfogx Dxmw== X-Gm-Message-State: AD7BkJJ8np/+Kf+woPXC21jBMGYT629hsItPvbE1XgPQalQ93x1GqJZ3nBbnmZAIH0ECnA== X-Received: by 10.140.153.135 with SMTP id 129mr30987313qhz.38.1459865393801; Tue, 05 Apr 2016 07:09:53 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:f15a:d8f5:a3a8:e9e? ([2001:67c:370:160:f15a:d8f5:a3a8:e9e]) by smtp.gmail.com with ESMTPSA id c90sm14620366qkj.47.2016.04.05.07.09.52 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 07:09:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> Date: Tue, 5 Apr 2016 11:09:51 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> To: IPsecME WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:10:01 -0000 Replying to myself... I=E2=80=99ve been told off-list that it didn=E2=80=99t make sense to = introduce the hot, new algorithm as a MAY. The only reason I=E2=80=99m = suggesting this is that there are currently no implementations to = interop with, and no EdDSA certificates where the public keys might come = from. My main motivation is to MUST NOT the pre-hashed versions because = we don=E2=80=99t need them and again there=E2=80=99s no install base to = interop with. Thinking it over, the new EdDSA signature algorithm defined in the CFRG = draft[1] can sign arbitrary-sized messages. We traditionally fed the = signature functions hashes of the message because these signature = functions only accepted a limited-size input. That is why the =E2=80=9Cdig= ital signature=E2=80=9D document (RFC 7427) has a negotiation and field = for hash algorithm. Since we don=E2=80=99t need that with this = particular algorithm, I suggest we don=E2=80=99t. IOW I=E2=80=99m = suggesting that we allocate a new entry in the =E2=80=9CIKEv2 Hash = Algorithms=E2=80=9D registry called =E2=80=9Cidentity=E2=80=9D that will = be used only with EdDSA signatures (or any future signature with the = same property). Yoav [1] See for example = https://tools.ietf.org/id/draft-irtf-cfrg-eddsa-05.html#rfc.section.5.1.6 > On 4 Apr 2016, at 4:43 PM, Yoav Nir wrote: >=20 > Hi >=20 > At the meeting today, I presented the SafeCurves draft status and = asked the room whether we wanted to wait for CFRG and Curdle to settle = their respective RFCs. The room was unanimously in favor of not having = anything in the current draft, instead using RFC 7427 digital = signatures. To be certain if we *did* wait, we=E2=80=99d just list the = two OIDs from Curdle that we like (the non-prehashed ones). >=20 > Quoting from the Curdle draft, they have this: >=20 > id-Curve25519 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.1 = } > id-Curve448 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.2 = } > id-Curve25519ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.3 = } > id-Curve448ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.4 = } >=20 > In other news, it turns out that we still have some discussion to go = with 4307bis. So I suggest that we add these to table 9 of section 4.2 = there as follows: >=20 > +------------------------------------+------------+---------+ > | Description | Status | Comment | > +------------------------------------+------------+---------+ > | RSASSA-PSS with SHA-256 | SHOULD | | > | ecdsa-with-sha256 | SHOULD | | > | sha1WithRSAEncryption | SHOULD NOT | | > | dsa-with-sha1 | SHOULD NOT | | > | ecdsa-with-sha1 | SHOULD NOT | | > | RSASSA-PSS with Empty Parameters | SHOULD NOT | | > | RSASSA-PSS with Default Parameters | SHOULD NOT | | > | sha256WithRSAEncryption | MAY | | > | sha384WithRSAEncryption | MAY | | > | sha512WithRSAEncryption | MAY | | > | sha512WithRSAEncryption | MAY | | > | dsa-with-sha256 | MAY | | > | ecdsa-with-sha384 | MAY | | > | ecdsa-with-sha512 | MAY | ?SHOULD | > | id-Curve25519 | MAY | | > | id-Curve448 | MAY | | > | id-Curve25519ph | MUST NOT | | > | id-Curve448ph | MUST NOT | | > +------------------------------------+------------+---------+ >=20 > What do others think? >=20 > Yoav From nobody Tue Apr 5 08:27:11 2016 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 2D69412D5E2 for ; Tue, 5 Apr 2016 08:27:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 i_EDlPeMT0TW for ; Tue, 5 Apr 2016 08:27:07 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B6412D5E3 for ; Tue, 5 Apr 2016 08:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1459870025; x=2323783625; 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=VApj8ZLYc6TE57AngOM0SXlfI4lYkz8B3MrUOnPO7TQ=; b=BapmoA6zSqTha+WAZMqpqNxWUp5IUGM+FqTcQFcL7d828q4E+2LyToAsfjGGk1Yt 8hVzWbIzHWuaeCyu52DvpAZ6U211M7tAyVR/qKNbVg0DFOdLNlscnUS9dJCn1T2B CZENptmtwY7DE52xAcng8WKaJdVJKvUTZNxfNGemkmRnU/dFH7UxPnQaJKqJr8cD WqfM+OFbbhF7nH4cvWIhSmV1Hd52xQWqYlPuUj/eRbaVx2LSsImlbJv4Gw+vJJDS eFKLY1DgJTjw00RvMVbNH2QtTjlb98ycho+98ucLf+yDzU4crn4j2Yz0ITEq5DmM LzLv7MYVXunnZFUCJQHsSw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 56.8F.03030.949D3075; Tue, 5 Apr 2016 08:27:05 -0700 (PDT) X-AuditID: 11973e13-f798e6d000000bd6-62-5703d949e0b2 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id E6.4C.23128.949D3075; Tue, 5 Apr 2016 08:27:05 -0700 (PDT) Received: from [17.153.60.153] (unknown [17.153.60.153]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O560002T2WZBI00@nwk-mmpp-sz12.apple.com> for ipsec@ietf.org; Tue, 05 Apr 2016 08:27:05 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_5E2395FC-2AD0-4B98-8A65-783EB8A9BC0F" Message-id: <4A4C3422-C890-401A-AAA4-4BE3B07DC83A@apple.com> Date: Tue, 05 Apr 2016 12:27:01 -0300 To: IPsecME WG MIME-version: 1.0 (Mac OS X Mail 9.3 \(3117\)) X-Mailer: Apple Mail (2.3117) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FDorOt5kznc4MI3KYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+3ZTpaCpcoV0w7NZW1gPCbbxcjJISFgIrHkXz87hC0mceHe erYuRi4OIYG9jBLTuxaxwRStb//CDpFYziRx5NNXRghnHpBz6yNLFyMHh7CAhMTmPYkgDWwC KhLHv21gBrGZBZIk2p40skOUGEk82wQW5hWwkTj36C2YzSKgKjHj1gNmkBIRAXmJmTcyIUr0 JObePckKEpYQkJXo/ZYDslRC4CGrxL3WyWwTGAVmIVkwC0kLRFxbYtnC18wQtqbE/u7lLJji GhKd3yayLmBkW8UolJuYmaObmWeql1hQkJOql5yfu4kRFMLT7YR3MJ5eZXWIUYCDUYmHd8Z7 pnAh1sSy4srcQ4zSHCxK4rzHnwOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME5YoCewZPek YnNLdle2HZzTeb6uEkvLXHvZd9HiAwc3iGRsO/uPtaT8qPiMXTqmyfpVv/ZG33zMF29pPvHq 5ruBK4+vr/V+a+9/LGd7YcDtyj7lu7lVlwKSTyyvP8gRkfL2yfG3wRcfftU9l2x2fHLW+Ym/ v09OSooVmfOyR+iO3abjzyTs9x9XYinOSDTUYi4qTgQAm3ikpEICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FB8RtfzJnO4wfXl4hb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtuznSwFS5Urph2ay9rAeEy2i5GTQ0LARGJ9+xd2CFtM4sK9 9WxdjFwcQgLLmSSOfPrKCOHMA3JufWTpYuTgEBaQkNi8JxGkgU1AReL4tw3MIDazQJJE25NG dogSI4lnm8DCvAI2EucevQWzWQRUJWbcesAMUiIiIC8x80YmRImexNy7J1lBwhICshK933Im MPLOQjJzFpIqiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRoCg1J7HSSC+xoCAnVS85 P3cTIzjkCp13MB5bZnWIUYCDUYmH1+EtU7gQa2JZcWXuIUYJDmYlEd60G8zhQrwpiZVVqUX5 8UWlOanFhxilOViUxHkvuAKlBNITS1KzU1MLUotgskwcnFINjAdXqSqnTpt//P07/tu60crZ fq7OiTyX2691uBqLrbO4HeG1PO3lw+WpH5t02SrfeCzZm+fCFb8lcw3j971TSz5cCu8UV57n J+pwVEn69owp+9kSr31U22rppl1mabjG/UWOBqfk66lGNxVjii/flon78GnX89RY65vuzy8q 8i8Ue8r7TFuuUYmlOCPRUIu5qDgRAB1q0Qc1AgAA Archived-At: Subject: [IPsec] Next steps on TCP Encapsulation for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:27:09 -0000 --Apple-Mail=_5E2395FC-2AD0-4B98-8A65-783EB8A9BC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, At our meeting yesterday, we agreed that we want one more revision of = draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group = adoption to clear up a few concerns. Here are the changes we=E2=80=99re planning: 1. Reconcile the length field size with 3GPP=E2=80=99s recommendation = (sent out by Tero) to promote interoperability if any devices have = already implemented 3GPP=E2=80=99s suggestions. This would mean changing = the length field from 32 bits to 16 bits. 2. Address the concerns around including too many direct references to = use of TLS and port 443 in the body of the standards track document. The = current plan here would be to make all direct references to TLS in the = body of the document be more generic regarding any protocols over TCP = that are added to encapsulate the IKE session, and point to an appendix = that explains the caveats regarding TLS. The main point to communicate = is that TLS should not influence the framing of IKE or ESP packets on = the stream, and that the encryption and authentication properties of TLS = do not influence the IKE session at all. Valery, I believe this should = address your concerns. Please reply with your feedback if you think these changes are good = ideas, and if there are any other remaining points that should be = changed before we move ahead. After this, the plan would be to ask for working group adoption of the = document if there are no other objections, and to in parallel start an = informational document (perhaps a draft, perhaps outside of IETF) to = describe the practical strategies for using TLS to encapsulate the = tunnel, and more detail on proxy interactions. Thanks, Tommy Pauly= --Apple-Mail=_5E2395FC-2AD0-4B98-8A65-783EB8A9BC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

At = our meeting yesterday, we agreed that we want one more revision = of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for = working group adoption to clear up a few concerns.

Here are the changes = we=E2=80=99re planning:

1. Reconcile the length field size with 3GPP=E2=80=99s = recommendation (sent out by Tero) to promote interoperability if any = devices have already implemented 3GPP=E2=80=99s suggestions. This would = mean changing the length field from 32 bits to 16 bits.

2. Address the concerns = around including too many direct references to use of TLS and port 443 = in the body of the standards track document. The current plan here would = be to make all direct references to TLS in the body of the document be = more generic regarding any protocols over TCP that are added to = encapsulate the IKE session, and point to an appendix that explains the = caveats regarding TLS. The main point to communicate is that TLS should = not influence the framing of IKE or ESP packets on the stream, and that = the encryption and authentication properties of TLS do not influence the = IKE session at all. Valery, I believe this should address your = concerns.

Please reply with your feedback if you think these = changes are good ideas, and if there are any other remaining points that = should be changed before we move ahead.

After this, the plan would be to ask = for working group adoption of the document if there are no other = objections, and to in parallel start an informational document (perhaps = a draft, perhaps outside of IETF) to describe the practical strategies = for using TLS to encapsulate the tunnel, and more detail on proxy = interactions.

Thanks,
Tommy Pauly
= --Apple-Mail=_5E2395FC-2AD0-4B98-8A65-783EB8A9BC0F-- From nobody Tue Apr 5 09:14:15 2016 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 279FE12D6FF for ; Tue, 5 Apr 2016 09:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZtQyc5BQy-yf for ; Tue, 5 Apr 2016 09:14:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 9054512D6EE for ; Tue, 5 Apr 2016 09:14:11 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k135so3063581qke.0 for ; Tue, 05 Apr 2016 09:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=/VsWEvb3Dv7+IF2eDfHd5OTO/xmElpnQWT/rjWKnXKc=; b=Jvc9gtF/5bbEySNPWuMZtmvvh8MH8pUTM2JIWflLT9r1it/y6xPoWIMKp18WetPVYU aP7VdnhysuPafQVqVI7fpNWn453Pai8MTk/Bsz43x4IestyWzlEcygctPkJ3x+KbL+Kd pRyT0n8YEEOnj1JaLjq3wNXmIlVRuj2AKuGWHj+qbiyDj5pdNYwogqR0ATkJ7aw4gb0k sT9SbrCNfFobS4b9dCgjqFy7vLHFWE36NduhXnreOC3COtUNBHcke+O5X5p18iM94q6/ uUNlnQNN0YRkioWRsGZ3vVE1gv7PKO/x09A8/gEPnfLDdyk9+uS2fHmbSu+Ilz+DTytz NgPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/VsWEvb3Dv7+IF2eDfHd5OTO/xmElpnQWT/rjWKnXKc=; b=UL20hGa3u3xwzV3HsE2mYbvtm1IiREk4/KgMkr9wr4F4VvgBA62bL1kJiqBLFvnL23 2nV4ofQfewVkx7JEiYehl3BNzUYdEGDqIX9jeeyLJGwwC9l1PoBSnAebKevptBDTsXbD +qPIfeV+No+q7EYimX+s4aCJYFpPiK9pYY2hIcaO49H260IkrzE6uIZSsxJD1HQEyxHf VdkChQnl88NOeEDhhKyxx7kW5kztJrbII5TwwJu5a2P92wPv905PpQb6YLIG74X/f6Pl 9pDHcHNtwQxqu4TaPnTPnW/Xv64nCjVAAaFWdyozCdfqGAcr426QftpCBuq91uCPJigD qedA== X-Gm-Message-State: AD7BkJL094cMprvE3SdbpZbR3guS759SQvugi9FGhRYZUUvsS4bAu1cEnI84R+hZC1qB7g== X-Received: by 10.55.79.207 with SMTP id d198mr40418006qkb.49.1459872850656; Tue, 05 Apr 2016 09:14:10 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:8144:811c:2d37:188b? ([2001:67c:370:160:8144:811c:2d37:188b]) by smtp.gmail.com with ESMTPSA id j68sm14835132qge.41.2016.04.05.09.14.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 09:14:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7DFF30D0-88E5-4ED7-849C-40F205218F61" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <4A4C3422-C890-401A-AAA4-4BE3B07DC83A@apple.com> Date: Tue, 5 Apr 2016 13:14:08 -0300 Message-Id: <9D3BF102-ACD7-41D1-B922-BBB178238D8F@gmail.com> References: <4A4C3422-C890-401A-AAA4-4BE3B07DC83A@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Next steps on TCP Encapsulation for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:14:14 -0000 --Apple-Mail=_7DFF30D0-88E5-4ED7-849C-40F205218F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Tommy. The changes look fine, although I=E2=80=99m still not convinced we even = need the TLS. But that=E2=80=99s for another thread. We foresee that most TCP encapsulation is likely to be in on port 443. I = think TCP encapsulation of IKEv2/IPsec should be easily distinguishable = from other types of traffic on the same port. I propose we add a magic value at the start of a non-TLS TCP stream, = something very different from (0x16, 0x03, 0x01, 0x00). Yoav > On 5 Apr 2016, at 12:27 PM, Tommy Pauly wrote: >=20 > Hello, >=20 > At our meeting yesterday, we agreed that we want one more revision of = draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group = adoption to clear up a few concerns. >=20 > Here are the changes we=E2=80=99re planning: >=20 > 1. Reconcile the length field size with 3GPP=E2=80=99s recommendation = (sent out by Tero) to promote interoperability if any devices have = already implemented 3GPP=E2=80=99s suggestions. This would mean changing = the length field from 32 bits to 16 bits. >=20 > 2. Address the concerns around including too many direct references to = use of TLS and port 443 in the body of the standards track document. The = current plan here would be to make all direct references to TLS in the = body of the document be more generic regarding any protocols over TCP = that are added to encapsulate the IKE session, and point to an appendix = that explains the caveats regarding TLS. The main point to communicate = is that TLS should not influence the framing of IKE or ESP packets on = the stream, and that the encryption and authentication properties of TLS = do not influence the IKE session at all. Valery, I believe this should = address your concerns. >=20 > Please reply with your feedback if you think these changes are good = ideas, and if there are any other remaining points that should be = changed before we move ahead. >=20 > After this, the plan would be to ask for working group adoption of the = document if there are no other objections, and to in parallel start an = informational document (perhaps a draft, perhaps outside of IETF) to = describe the practical strategies for using TLS to encapsulate the = tunnel, and more detail on proxy interactions. >=20 > Thanks, > Tommy Pauly > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_7DFF30D0-88E5-4ED7-849C-40F205218F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Tommy.

The changes look fine, although I=E2=80=99m still not = convinced we even need the TLS. But that=E2=80=99s for another = thread.

We = foresee that most TCP encapsulation is likely to be in on port 443. I = think TCP encapsulation of IKEv2/IPsec should be easily distinguishable = from other types of traffic on the same port.

I propose we add a magic value at the = start of a non-TLS TCP stream, something very different from (0x16, = 0x03, 0x01, 0x00).

Yoav


On 5 Apr 2016, at 12:27 PM, Tommy Pauly <tpauly@apple.com> = wrote:

Hello,

At our meeting = yesterday, we agreed that we want one more revision = of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for = working group adoption to clear up a few concerns.

Here are the changes = we=E2=80=99re planning:

1. Reconcile the length field size with 3GPP=E2=80=99s = recommendation (sent out by Tero) to promote interoperability if any = devices have already implemented 3GPP=E2=80=99s suggestions. This would = mean changing the length field from 32 bits to 16 bits.

2. Address the concerns = around including too many direct references to use of TLS and port 443 = in the body of the standards track document. The current plan here would = be to make all direct references to TLS in the body of the document be = more generic regarding any protocols over TCP that are added to = encapsulate the IKE session, and point to an appendix that explains the = caveats regarding TLS. The main point to communicate is that TLS should = not influence the framing of IKE or ESP packets on the stream, and that = the encryption and authentication properties of TLS do not influence the = IKE session at all. Valery, I believe this should address your = concerns.

Please reply with your feedback if you think these = changes are good ideas, and if there are any other remaining points that = should be changed before we move ahead.

After this, the plan would be to ask = for working group adoption of the document if there are no other = objections, and to in parallel start an informational document (perhaps = a draft, perhaps outside of IETF) to describe the practical strategies = for using TLS to encapsulate the tunnel, and more detail on proxy = interactions.

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

= --Apple-Mail=_7DFF30D0-88E5-4ED7-849C-40F205218F61-- From nobody Tue Apr 5 11:40:07 2016 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 42E4A12D162; Tue, 5 Apr 2016 11:40:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405184003.7325.69935.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 11:40:03 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:40:03 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-05.txt Pages : 16 Date : 2016-04-05 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-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 Tue Apr 5 11:46:35 2016 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 BF03512D12C for ; Tue, 5 Apr 2016 11:46:33 -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 rSjPxfS1mNSc for ; Tue, 5 Apr 2016 11:46:32 -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 B1FF812D5BB for ; Tue, 5 Apr 2016 11:46:31 -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 u35IkSuj020274 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Apr 2016 21:46:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35IkS7v010622; Tue, 5 Apr 2016 21:46:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22276.2052.186968.639938@fireball.acr.fi> Date: Tue, 5 Apr 2016 21:46:28 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> References: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: Subject: [IPsec] New Version Notification for draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:46:34 -0000 Here is new version of the RFC4307bis. This includes changes from Valery (http://www.ietf.org/mail-archive/web/ipsec/current/msg10410.html) except I did not change the AEAD/non-AEAD text in the section 3.2. The current document still says that PRF and AUTH algorithms SHOULD be same if non-AEAD encryption algorithm is used. Also I did not add anything extra for the AUTH_AES_XCBC_96 for section 3.3. Otherwise it should contain all changes. This also now includes new section 5 explaining the situatin with IoT, i.e. why there is not exactly one option for them, but the algorithms used there is specified by the environment, and for the 802.15.4 / 802.15.9 the algorithm is ENCR_AES_CCM_8. For others it might be different. Check it out and with this I think it might be ready for the WGLC. ---------------------------------------------------------------------- internet-drafts@ietf.org writes: A new version of I-D, draft-ietf-ipsecme-rfc4307bis-05.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Name: draft-ietf-ipsecme-rfc4307bis Revision: 05 Title: Algorithm Implementation Requirements and Usage Guidance for IKEv2 Document date: 2016-04-05 Group: ipsecme Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-rfc4307bis-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ Htmlized: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-05 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). 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 -- kivinen@iki.fi From nobody Tue Apr 5 11:54:08 2016 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 316C412D78F for ; Tue, 5 Apr 2016 11:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] 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 fM7_89-hACWn for ; Tue, 5 Apr 2016 11:54:05 -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 701CA12D72B for ; Tue, 5 Apr 2016 11:54:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qfdLL1WRhz3dh; Tue, 5 Apr 2016 20:54:02 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 Fi4NViYm-lya; Tue, 5 Apr 2016 20:54:00 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Apr 2016 20:54:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AC1A3600BAE6; Tue, 5 Apr 2016 14:53:58 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca AC1A3600BAE6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA44B875BEA; Tue, 5 Apr 2016 14:53:58 -0400 (EDT) Date: Tue, 5 Apr 2016 14:53:58 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22276.2052.186968.639938@fireball.acr.fi> Message-ID: References: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> <22276.2052.186968.639938@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 18:54:07 -0000 On Tue, 5 Apr 2016, Tero Kivinen wrote: > Here is new version of the RFC4307bis. This includes changes from > Valery > (http://www.ietf.org/mail-archive/web/ipsec/current/msg10410.html) > except I did not change the AEAD/non-AEAD text in the section 3.2. The > current document still says that PRF and AUTH algorithms SHOULD be > same if non-AEAD encryption algorithm is used. Also I did not add > anything extra for the AUTH_AES_XCBC_96 for section 3.3. > > Otherwise it should contain all changes. > > This also now includes new section 5 explaining the situatin with IoT, > i.e. why there is not exactly one option for them, but the algorithms > used there is specified by the environment, and for the 802.15.4 / > 802.15.9 the algorithm is ENCR_AES_CCM_8. For others it might be > different. Looks good except the new iot block needs some english nits fixups. Paul From nobody Tue Apr 5 12:42:25 2016 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 E17CE12D639 for ; Tue, 5 Apr 2016 12:42:23 -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 g4w9qt-jt5cW for ; Tue, 5 Apr 2016 12:42:22 -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 110D912D63B for ; Tue, 5 Apr 2016 12:42: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 u35JgIwW026076 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Apr 2016 22:42:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35JgIdC027950; Tue, 5 Apr 2016 22:42:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22276.5402.290934.375641@fireball.acr.fi> Date: Tue, 5 Apr 2016 22:42:18 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <22276.2052.186968.639938@fireball.acr.fi> References: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> <22276.2052.186968.639938@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: [IPsec] New Version Notification for draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 19:42:24 -0000 Tero Kivinen writes: > Check it out and with this I think it might be ready for the WGLC. One thing I noticed, that in the section 4.1 we do not mention "2 - Shared Key Message Integrity Code" at all. This is actually mandated in the RFC7296 section 4, so we should most likely add it as MUST. Anybody objecting that change. If not I will submit new version tomorrow with just that fix (and perhaps with other fixes if there are other things that needs to be changed). -- kivinen@iki.fi From nobody Tue Apr 5 13:05:53 2016 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 ABAFE12D162 for ; Tue, 5 Apr 2016 13:05:52 -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 53tFFyEXt65h for ; Tue, 5 Apr 2016 13:05:51 -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 1F61012D7FC for ; Tue, 5 Apr 2016 13:05:50 -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 u35K5mSa018971 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2016 23:05:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u35K5mXe008669; Tue, 5 Apr 2016 23:05:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22276.6811.978488.600261@fireball.acr.fi> Date: Tue, 5 Apr 2016 23:05:47 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> <22276.2052.186968.639938@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:05:52 -0000 Paul Wouters writes: > Looks good except the new iot block needs some english nits fixups. Provide text, or hunt me down, and make me do the fixes :-) -- kivinen@iki.fi From nobody Tue Apr 5 16:19:07 2016 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 631BE12D527 for ; Tue, 5 Apr 2016 16:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] 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 6m242LYF226f for ; Tue, 5 Apr 2016 16:19:05 -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 60B0112D180 for ; Tue, 5 Apr 2016 16:19:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qflD572Lhz41f; Wed, 6 Apr 2016 01:19:01 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 fwWRNzY-gST0; Wed, 6 Apr 2016 01:19:00 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 6 Apr 2016 01:19:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D69C7600BAE6; Tue, 5 Apr 2016 19:18:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D69C7600BAE6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D23C818D6E; Tue, 5 Apr 2016 19:18:59 -0400 (EDT) Date: Tue, 5 Apr 2016 19:18:59 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22276.5402.290934.375641@fireball.acr.fi> Message-ID: References: <20160405184003.7325.64068.idtracker@ietfa.amsl.com> <22276.2052.186968.639938@fireball.acr.fi> <22276.5402.290934.375641@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-rfc4307bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:19:06 -0000 On Tue, 5 Apr 2016, Tero Kivinen wrote: > One thing I noticed, that in the section 4.1 we do not mention "2 - > Shared Key Message Integrity Code" at all. This is actually mandated > in the RFC7296 section 4, so we should most likely add it as MUST. > > Anybody objecting that change. If not I will submit new version > tomorrow with just that fix (and perhaps with other fixes if there are > other things that needs to be changed). You are right. We want to avoid people accidentally thinking that PSK is a may or should not. Paul From nobody Wed Apr 6 07:20:19 2016 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 40EAE12D62F for ; Wed, 6 Apr 2016 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 mXMpBU-N0Mjo for ; Wed, 6 Apr 2016 07:20:16 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3A312D5D5 for ; Wed, 6 Apr 2016 07:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1459952416; x=2323866016; 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=AY8gnZ0QG+tsLzw/WxosJ1k0PSRvIvexZTeTAub6Xh8=; b=i1avzJws+oQLXiyzKUgBFi5Vd+drYuiMFx+38OWBsI15eUqM1N4uVCMKiAA0N2+R X8KS/Ns638ZGP9tkGKBXiVR4DKhqS+W83EFQpvG13vlRq55lC9iD3RKyCcXcmDJx JvUZbEfNTGibJLaqOobMhk2YGRL6SDQ1Og3ujkmUOgJYrLbfBkLy1IILM95PRqbF NtWucQ5t2K7IHbsY7ApdjAvnVSUdbPtTETZcJj9RK77EZVbTx+qvGOIwJISuWQAe 3g5CspmiG9QbQZp054Pv54Z9oEuiG7aKP5cLu419JWWJBNw/YS6nXFQ8hMcacHBs GQQHzlv+vKmvw4ZUFxl0SA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 38.5D.27179.02B15075; Wed, 6 Apr 2016 07:20:16 -0700 (PDT) X-AuditID: 11973e15-f79686d000006a2b-4c-57051b20a3e8 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id E5.20.28643.F1B15075; Wed, 6 Apr 2016 07:20:16 -0700 (PDT) Received: from [17.153.74.15] (unknown [17.153.74.15]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O5700MFYUHL2140@orrisroot.apple.com> for ipsec@ietf.org; Wed, 06 Apr 2016 07:20:15 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_5F5E1E72-A54D-4B7F-892D-275C7FE2F271" MIME-version: 1.0 (Mac OS X Mail 9.3 \(3117\)) From: Tommy Pauly In-reply-to: <9D3BF102-ACD7-41D1-B922-BBB178238D8F@gmail.com> Date: Wed, 06 Apr 2016 11:20:08 -0300 Message-id: <2B63F6DE-5743-49E6-91FF-A8F5981B0B2F@apple.com> References: <4A4C3422-C890-401A-AAA4-4BE3B07DC83A@apple.com> <9D3BF102-ACD7-41D1-B922-BBB178238D8F@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3117) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAYpasgzRpusOuZqsX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfDGLuaCQ54VLQf+szcw7rXrYuTkkBAwkZi+8iYLhC0mceHe erYuRi4OIYG9jBJdn6exwhQ9+rmfFSIxn0ni3s3XzBDOFCaJ3ft2ATkcHMICEhKb9ySCNDAL JEnM/NzHBmLzCuhJzL17EmyQsICdxIM9e9hBbDYBFYnj3zYwg9icArYSBz92gdksAqoSS75M ZIaYIy/R+38jI8QcG4mZX/8wgdhCAvkSn55PBrNFBJQkDl/5CnaChICsRO+3HJDTJAS2sEkc er+abQKj8CwkJ81CchJEXFti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSiUm5iZo5uZZ6aX WFCQk6qXnJ+7iREUD9PtRHcwnllldYhRgINRiYdXwIolXIg1say4MvcQozQHi5I47/HnTOFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNeJh/Pu9LuZez/GS0tNNfqHhm0vw5fytpD7O8T9 wm1fHH3l/jw2awJPyez3W5e87XPz77QOnn48bN7f9QaBkTpRk2K3ZxsXbk1a4WvmOeWvheK8 KSuFH13Obrs0K7dSbnW5/aXTX7T+HmFazpvCr3c08khIpYv03oQp9T8Wn/ItvuclmLPbWoml OCPRUIu5qDgRAJ6p7fxoAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUi2FCcpasgzRpuMOucgMX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfDGLuaCQ54VLQf+szcw7rXrYuTkkBAwkXj0cz8rhC0mceHe erYuRi4OIYH5TBL3br5mhnCmMEns3rcLyOHgEBaQkNi8JxGkgVkgSWLm5z42EJtXQE9i7t2T YIOEBewkHuzZww5iswmoSBz/toEZxOYUsJU4+LELzGYRUJVY8mUiM8QceYne/xsZIebYSMz8 +ocJxBYSyJf49HwymC0ioCRx+MpXsBMkBGQler/lTGAUmIXkillIroCIa0ssW/iaGcLWlNjf vZwFU1xDovPbRNYFjGyrGAWKUnMSK830EgsKclL1kvNzNzGCw7cwagdjw3KrQ4wCHIxKPLw7 zFnChVgTy4orcw8xSnAwK4nwzhJjDRfiTUmsrEotyo8vKs1JLT7EOJER6MmJzFKiyfnA6Mor iTc0MTEwMTY2MzY2NzGnpbCSOG/GI6AjBdITS1KzU1MLUotgjmLi4JRqYLRu0+1g04i54PXl gcQxD6sqW00937z8ufor7lk8Nwr6Uu8hcPHi3cppN85uvLHmjM5OfasZJnc7O57o+RQGzKkw N6/fduFFnciaIOWMyAPMuxKmM19++eprSMESw7cur1nZ37xJ+Pvu0JdzpiZxwZmO0dvvxGon BG0XqzZKlM4RObnVK/I5gxJLcUaioRZzUXEiAKr+tT/SAgAA Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Next steps on TCP Encapsulation for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:20:18 -0000 --Apple-Mail=_5F5E1E72-A54D-4B7F-892D-275C7FE2F271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yoav, Thanks for the feedback. While I see the advantage of adding the magic = value at the start of the non-TLS TCP stream, especially over port 443, = this seems to require the document to even more explicitly discuss TLS. = If implementations do end up using TLS, as I believe many will in = practice, then presumably they would not include this magic byte at the = beginning of their stream over TLS. This means that the inner protocol = diverges depending on which set of protocols are being used for the = stream. I would prefer that these be consistent if possible. Thoughts? Tommy > On Apr 5, 2016, at 1:14 PM, Yoav Nir wrote: >=20 > Hi, Tommy. >=20 > The changes look fine, although I=E2=80=99m still not convinced we = even need the TLS. But that=E2=80=99s for another thread. >=20 > We foresee that most TCP encapsulation is likely to be in on port 443. = I think TCP encapsulation of IKEv2/IPsec should be easily = distinguishable from other types of traffic on the same port. >=20 > I propose we add a magic value at the start of a non-TLS TCP stream, = something very different from (0x16, 0x03, 0x01, 0x00). >=20 > Yoav >=20 >=20 >> On 5 Apr 2016, at 12:27 PM, Tommy Pauly > wrote: >>=20 >> Hello, >>=20 >> At our meeting yesterday, we agreed that we want one more revision of = draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group = adoption to clear up a few concerns. >>=20 >> Here are the changes we=E2=80=99re planning: >>=20 >> 1. Reconcile the length field size with 3GPP=E2=80=99s recommendation = (sent out by Tero) to promote interoperability if any devices have = already implemented 3GPP=E2=80=99s suggestions. This would mean changing = the length field from 32 bits to 16 bits. >>=20 >> 2. Address the concerns around including too many direct references = to use of TLS and port 443 in the body of the standards track document. = The current plan here would be to make all direct references to TLS in = the body of the document be more generic regarding any protocols over = TCP that are added to encapsulate the IKE session, and point to an = appendix that explains the caveats regarding TLS. The main point to = communicate is that TLS should not influence the framing of IKE or ESP = packets on the stream, and that the encryption and authentication = properties of TLS do not influence the IKE session at all. Valery, I = believe this should address your concerns. >>=20 >> Please reply with your feedback if you think these changes are good = ideas, and if there are any other remaining points that should be = changed before we move ahead. >>=20 >> After this, the plan would be to ask for working group adoption of = the document if there are no other objections, and to in parallel start = an informational document (perhaps a draft, perhaps outside of IETF) to = describe the practical strategies for using TLS to encapsulate the = tunnel, and more detail on proxy interactions. >>=20 >> Thanks, >> Tommy Pauly >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_5F5E1E72-A54D-4B7F-892D-275C7FE2F271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Yoav,

Thanks for the feedback. While I see = the advantage of adding the magic value at the start of the non-TLS TCP = stream, especially over port 443, this seems to require the document to = even more explicitly discuss TLS. If implementations do end up using = TLS, as I believe many will in practice, then presumably they would not = include this magic byte at the beginning of their stream over TLS. This = means that the inner protocol diverges depending on which set of = protocols are being used for the stream. I would prefer that these be = consistent if possible.

Thoughts?

Tommy

On Apr 5, 2016, at 1:14 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi, Tommy.

The changes look fine, = although I=E2=80=99m still not convinced we even need the TLS. But = that=E2=80=99s for another thread.

We foresee that most TCP encapsulation = is likely to be in on port 443. I think TCP encapsulation of IKEv2/IPsec = should be easily distinguishable from other types of traffic on the same = port.

I = propose we add a magic value at the start of a non-TLS TCP stream, = something very different from (0x16, 0x03, 0x01, 0x00).

Yoav


On 5 Apr = 2016, at 12:27 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hello,

At our meeting = yesterday, we agreed that we want one more revision = of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for = working group adoption to clear up a few concerns.

Here are the changes = we=E2=80=99re planning:

1. Reconcile the length field size with 3GPP=E2=80=99s = recommendation (sent out by Tero) to promote interoperability if any = devices have already implemented 3GPP=E2=80=99s suggestions. This would = mean changing the length field from 32 bits to 16 bits.

2. Address the concerns = around including too many direct references to use of TLS and port 443 = in the body of the standards track document. The current plan here would = be to make all direct references to TLS in the body of the document be = more generic regarding any protocols over TCP that are added to = encapsulate the IKE session, and point to an appendix that explains the = caveats regarding TLS. The main point to communicate is that TLS should = not influence the framing of IKE or ESP packets on the stream, and that = the encryption and authentication properties of TLS do not influence the = IKE session at all. Valery, I believe this should address your = concerns.

Please reply with your feedback if you think these = changes are good ideas, and if there are any other remaining points that = should be changed before we move ahead.

After this, the plan would be to ask = for working group adoption of the document if there are no other = objections, and to in parallel start an informational document (perhaps = a draft, perhaps outside of IETF) to describe the practical strategies = for using TLS to encapsulate the tunnel, and more detail on proxy = interactions.

Thanks,
Tommy = Pauly
_______________________________________________
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

= --Apple-Mail=_5F5E1E72-A54D-4B7F-892D-275C7FE2F271-- From nobody Wed Apr 6 09:59:49 2016 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 5E5A012D699; Wed, 6 Apr 2016 09:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 09:59:45 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:59:45 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-06.txt Pages : 16 Date : 2016-04-06 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06 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 Apr 6 11:06:42 2016 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 B6E9F12D746; Wed, 6 Apr 2016 11:06:39 -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 kTVrw3vQKyns; Wed, 6 Apr 2016 11:06:37 -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 E9CF012D1BF; Wed, 6 Apr 2016 11:06:36 -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 u36I6WiJ000155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Apr 2016 21:06:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u36I6WaW015612; Wed, 6 Apr 2016 21:06:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22277.20520.264319.773683@fireball.acr.fi> Date: Wed, 6 Apr 2016 21:06:32 +0300 From: Tero Kivinen To: internet-drafts@ietf.org In-Reply-To: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: ipsec@ietf.org, i-d-announce@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:06:39 -0000 internet-drafts@ietf.org writes: > 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 of the IETF. This version includes the pre-shared keys (or "Shared Key Message Integrity Code") in the authentication method table, as it specified in the RFC7296 as mandatory to implement, so we want to say it MUST here too. While I was doing that change, I noticed that we actually update the RFC7296, as the 7296 section 4 has text saying that RSA with key lengths of 1024 or 2048 are mandatory. In our section 4.1.1 we actually say that RSA key lengths with less than 2048 bits are SHOULD NOT, so our recommendation are different than what is in the RFC7296. After quick verify from our WG chair, I marked this document as updating the RFC7296 (and added the missing fact that is obsoletes rfc4307). The fact that this updates RFC7296 was also added in the introduction. In addition to those changes, this contains some fixes for some typos etc (especially in the section 5 algoritms for IoT). With these changes, I think this document is ready for the WGLC. > Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 > Authors : Yoav Nir > Tero Kivinen > Paul Wouters > Daniel Migault > Filename : draft-ietf-ipsecme-rfc4307bis-06.txt > Pages : 16 > Date : 2016-04-06 > > Abstract: > The IPsec series of protocols makes use of various cryptographic > algorithms in order to provide security services. The Internet Key > Exchange (IKE) protocol is used to negotiate the IPsec Security > Association (IPsec SA) parameters, such as which algorithms should be > used. To ensure interoperability between different implementations, > it is necessary to specify a set of algorithm implementation > requirements and usage guidance to ensure that there is at least one > algorithm that all implementations support. This document defines > the current algorithm implementation requirements and usage guidance > for IKEv2. This document does not update the algorithms used for > packet encryption using IPsec Encapsulated Security Payload (ESP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06 > > > 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/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- kivinen@iki.fi From nobody Wed Apr 6 12:13:59 2016 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 4116012D539 for ; Wed, 6 Apr 2016 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7P6JAUey3CYG for ; Wed, 6 Apr 2016 12:13:55 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 45D7F12D52F for ; Wed, 6 Apr 2016 12:13:55 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id f52so44414587qga.3 for ; Wed, 06 Apr 2016 12:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Q5vt21FDi0fa3XSxqcFllif3zkfin5WwlF8A/0seuzI=; b=EjC29FZF8k29agDaraT4UHg0vwHqNRE7JoOmKjPiFBFKyUEF5g+qeCBWs/MtwIYlZw u6aposs/0QLZSuDKU0W1N4oD5nov5HDMWjE9FlwEJYAjELBIMDBnOzbPDZXSRPM1Pr8x AHbmTHFLgGTqvbtMea6DKqRPsO5XKLXr21Jd2f/thU1b8x/pxe8iJXlBFHmcSSP0TMn8 C9UNtCL4tzZIA8IDXK6PxKl8tPnPzEJLL6+X8ojUEvIfihZC4yFccljuYId/maMOJh5y o06Y21+xMjcB6yVDzZqkk6X6BeMjWvRJaXvFWddHQvvJc+03hFGRN12XlVnkh+Rk3/6G c5TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q5vt21FDi0fa3XSxqcFllif3zkfin5WwlF8A/0seuzI=; b=GUWjUbysXnpn7/SILxtiMAKXJzRWkzLYe7IbMWzEvq0kYtQ7MoSEewu8heATgVst6V 5BrbEPHWjw0WiojI1dQ2+dsocqz8HQTfhTtBS6PIQfttJ2g53aFis5WauJeNeRLBVxPe rW7r1pNKgBz5hAnwMZ+41EhW/IhNqmVuBzzh1lHpS3Ulw4wUBhvzQgiDSrwEMbJ88VrL A4bq9jGd4qoePiaGNRDQsWxCizDxjaAL9suzKKpFNYnPP5OESR08YDd1OOyCn6Fdbc7D 4sMHe+zxwUbXKRABzPUbHyJT323tsldIsj5Rd8txMSCitrmlW6QcZs6tHmK4nkPZIyfB uQyw== X-Gm-Message-State: AD7BkJJjPBcH5eEoKqk9ixChMZ7kjgnhSHmdBevFUny21E7F6nEt5MmVSmZ3lnPmXE0sbg== X-Received: by 10.140.28.52 with SMTP id 49mr37777785qgy.66.1459970034428; Wed, 06 Apr 2016 12:13:54 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:c03b:bb0f:7fd8:7eff? ([2001:67c:370:160:c03b:bb0f:7fd8:7eff]) by smtp.gmail.com with ESMTPSA id t85sm1893783qki.10.2016.04.06.12.13.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 12:13:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_851292BC-8703-46A2-813D-547A841202EE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <2B63F6DE-5743-49E6-91FF-A8F5981B0B2F@apple.com> Date: Wed, 6 Apr 2016 16:13:51 -0300 Message-Id: References: <4A4C3422-C890-401A-AAA4-4BE3B07DC83A@apple.com> <9D3BF102-ACD7-41D1-B922-BBB178238D8F@gmail.com> <2B63F6DE-5743-49E6-91FF-A8F5981B0B2F@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Next steps on TCP Encapsulation for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:13:58 -0000 --Apple-Mail=_851292BC-8703-46A2-813D-547A841202EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My opinion is colored by my implementation. Our gateway listens in on = port 443, and has to distinguish between several kinds of connections: - IKE-over-TCP (it=E2=80=99s the old IKEv1 think, but still=E2=80=A6) - TLS handshake, and that splits further into: - SSL-VPN - with your draft: IKE - HTTPS to some kind of portal served by the gateway. So the first thing is to distinguish between TLS and non-TLS, and the = question is =E2=80=9Cdoes it look like ClientHello=E2=80=9D. ClientHello = looks like 16 03 00/01/02/03 00/01/02.=20 In version -03 of the draft you are proposing to begin the a 4-byte = length field, so assuming a 1000-bye Initial request, that=E2=80=99s = going to be 00 00 03 E8. This looks different enough. There is a = proposal to make this field 2-byte, so this would start with 03 E8 00 = 00. Is this OK? Yes, but what if we happened to have an Initial = request with size 5635? Then we get 16 03 00 00. That looks too much = like ClientHello. Of course I can argue that a 5635-byte Initial = request is ludicrously large, but I still think this is worth it. For the second kind of distinguishing we=E2=80=99d need to tell apart = whatever SSL-VPN protocol we support from IKE. I think the magic number = would help here as well. HTTP/2 has this really big magic described in = section 3.5, but HTTP/1 does not. So I think a magic will be needed = there as well. Yoav > On 6 Apr 2016, at 11:20 AM, Tommy Pauly wrote: >=20 > Hi Yoav, >=20 > Thanks for the feedback. While I see the advantage of adding the magic = value at the start of the non-TLS TCP stream, especially over port 443, = this seems to require the document to even more explicitly discuss TLS. = If implementations do end up using TLS, as I believe many will in = practice, then presumably they would not include this magic byte at the = beginning of their stream over TLS. This means that the inner protocol = diverges depending on which set of protocols are being used for the = stream. I would prefer that these be consistent if possible. >=20 > Thoughts? >=20 > Tommy >=20 >> On Apr 5, 2016, at 1:14 PM, Yoav Nir > wrote: >>=20 >> Hi, Tommy. >>=20 >> The changes look fine, although I=E2=80=99m still not convinced we = even need the TLS. But that=E2=80=99s for another thread. >>=20 >> We foresee that most TCP encapsulation is likely to be in on port = 443. I think TCP encapsulation of IKEv2/IPsec should be easily = distinguishable from other types of traffic on the same port. >>=20 >> I propose we add a magic value at the start of a non-TLS TCP stream, = something very different from (0x16, 0x03, 0x01, 0x00). >>=20 >> Yoav >>=20 >>=20 >>> On 5 Apr 2016, at 12:27 PM, Tommy Pauly > wrote: >>>=20 >>> Hello, >>>=20 >>> At our meeting yesterday, we agreed that we want one more revision = of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working = group adoption to clear up a few concerns. >>>=20 >>> Here are the changes we=E2=80=99re planning: >>>=20 >>> 1. Reconcile the length field size with 3GPP=E2=80=99s = recommendation (sent out by Tero) to promote interoperability if any = devices have already implemented 3GPP=E2=80=99s suggestions. This would = mean changing the length field from 32 bits to 16 bits. >>>=20 >>> 2. Address the concerns around including too many direct references = to use of TLS and port 443 in the body of the standards track document. = The current plan here would be to make all direct references to TLS in = the body of the document be more generic regarding any protocols over = TCP that are added to encapsulate the IKE session, and point to an = appendix that explains the caveats regarding TLS. The main point to = communicate is that TLS should not influence the framing of IKE or ESP = packets on the stream, and that the encryption and authentication = properties of TLS do not influence the IKE session at all. Valery, I = believe this should address your concerns. >>>=20 >>> Please reply with your feedback if you think these changes are good = ideas, and if there are any other remaining points that should be = changed before we move ahead. >>>=20 >>> After this, the plan would be to ask for working group adoption of = the document if there are no other objections, and to in parallel start = an informational document (perhaps a draft, perhaps outside of IETF) to = describe the practical strategies for using TLS to encapsulate the = tunnel, and more detail on proxy interactions. >>>=20 >>> Thanks, >>> Tommy Pauly >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec = >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_851292BC-8703-46A2-813D-547A841202EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My opinion is colored by my implementation. Our gateway = listens in on port 443, and has to distinguish between several kinds of = connections:
 - IKE-over-TCP (it=E2=80=99s the old = IKEv1 think, but still=E2=80=A6)
 - TLS = handshake, and that splits further into:
  =  - SSL-VPN
   - with your draft: = IKE
   - HTTPS to some kind of portal = served by the gateway.

So the first thing is to distinguish between TLS and non-TLS, = and the question is =E2=80=9Cdoes it look like ClientHello=E2=80=9D. = ClientHello looks like 16 03 00/01/02/03 00/01/02. 
In version -03 of the draft you are proposing to begin the a = 4-byte length field, so assuming a 1000-bye Initial request, that=E2=80=99= s going to be 00 00 03 E8. This looks different enough. There is a = proposal to make this field 2-byte, so this would start with 03 E8 00 = 00.  Is this OK?  Yes, but what if we happened to have an = Initial request with size 5635?  Then we get 16 03 00 00. =  That looks too much like ClientHello.  Of course I can argue = that a 5635-byte Initial request is ludicrously large, but I still think = this is worth it.

For the second kind of distinguishing we=E2=80=99d need to = tell apart whatever SSL-VPN protocol we support from IKE. I think the = magic number would help here as well. HTTP/2 has this really big magic = described in section 3.5, but HTTP/1 does not.  So I think a magic = will be needed there as well.

Yoav

On = 6 Apr 2016, at 11:20 AM, Tommy Pauly <tpauly@apple.com> = wrote:

Hi Yoav,

Thanks for the feedback. While I see the advantage of adding = the magic value at the start of the non-TLS TCP stream, especially over = port 443, this seems to require the document to even more explicitly = discuss TLS. If implementations do end up using TLS, as I believe many = will in practice, then presumably they would not include this magic byte = at the beginning of their stream over TLS. This means that the inner = protocol diverges depending on which set of protocols are being used for = the stream. I would prefer that these be consistent if = possible.

Thoughts?

Tommy

On Apr 5, 2016, at 1:14 PM, = Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi, Tommy.

The changes look fine, = although I=E2=80=99m still not convinced we even need the TLS. But = that=E2=80=99s for another thread.

We foresee that most TCP encapsulation = is likely to be in on port 443. I think TCP encapsulation of IKEv2/IPsec = should be easily distinguishable from other types of traffic on the same = port.

I = propose we add a magic value at the start of a non-TLS TCP stream, = something very different from (0x16, 0x03, 0x01, 0x00).

Yoav


On 5 Apr = 2016, at 12:27 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hello,

At our meeting = yesterday, we agreed that we want one more revision = of draft-pauly-ipsecme-tcp-encaps-03 before putting it up for = working group adoption to clear up a few concerns.

Here are the changes = we=E2=80=99re planning:

1. Reconcile the length field size with 3GPP=E2=80=99s = recommendation (sent out by Tero) to promote interoperability if any = devices have already implemented 3GPP=E2=80=99s suggestions. This would = mean changing the length field from 32 bits to 16 bits.

2. Address the concerns = around including too many direct references to use of TLS and port 443 = in the body of the standards track document. The current plan here would = be to make all direct references to TLS in the body of the document be = more generic regarding any protocols over TCP that are added to = encapsulate the IKE session, and point to an appendix that explains the = caveats regarding TLS. The main point to communicate is that TLS should = not influence the framing of IKE or ESP packets on the stream, and that = the encryption and authentication properties of TLS do not influence the = IKE session at all. Valery, I believe this should address your = concerns.

Please reply with your feedback if you think these = changes are good ideas, and if there are any other remaining points that = should be changed before we move ahead.

After this, the plan would be to ask = for working group adoption of the document if there are no other = objections, and to in parallel start an informational document (perhaps = a draft, perhaps outside of IETF) to describe the practical strategies = for using TLS to encapsulate the tunnel, and more detail on proxy = interactions.

Thanks,
Tommy = Pauly
_______________________________________________
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


= --Apple-Mail=_851292BC-8703-46A2-813D-547A841202EE-- From nobody Wed Apr 6 12:48:16 2016 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 7B46412D7BF for ; Wed, 6 Apr 2016 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 172JILQgT9iW for ; Wed, 6 Apr 2016 12:48:13 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 EEE9B12D7BE for ; Wed, 6 Apr 2016 12:48:11 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id i4so22097620qkc.3 for ; Wed, 06 Apr 2016 12:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=Q33JaODYXPRhWzOWtJPuxmsBIVgworx3vUfsWWthqs4=; b=QFuGXRz6SYWeOSGlOa02DZa3IweclSJXtTteYNcD1FhS9VlrSDG5EMwmjNZK7OFpUx 1egG7kjDA018jGmqNw053OXl7RZwscsQO6yz4NroqJ/TUjQA3juUciv5OpfMx9GLEgDR z0eO8NCdIYbj54OImv6ZrBRcTXrqxBKSop9W+EDxY8c9P/DptrKFE/5NFB4RTYoKUkx+ 9t8TYooMBK3VNdO40wVKjAxJHB+O7LIUTn+3GRivDD7mIfJGzBo0JHGrenFaHC7D89SG OKFDPLtNY3ZFJNeKU+o/oDRZvIfaShnAA7ABIJEg8oIMoDgtu1bqLXmTa6WJTH3K08dr cu9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=Q33JaODYXPRhWzOWtJPuxmsBIVgworx3vUfsWWthqs4=; b=miT+1J2C5pkuy03yqeyugtUs8VwgHHH7vqmK2h2hp5iw/AmMwctR40iurbFPgGz418 vwm97GtpBXaFXvXb0gtR5NioXkJvEVSo4ssqObYtfa8CgRzi3S7I91yzlC16EUcmJz1p xaJwebECGCeYPSjwIQU2RipgvKJtZtP0y9b3jgq2X/poyRUhFY2/dqsfxTR5IIef+gmP D+QxL8ZA9yiNwjnsA22SMw1HMC22YoQB3S8UTDnC1L3RH6mV3ai0Z6cF/5R2WxROBtMK Va3ysuV9DU6MvTyrYN2WumePH6athYELcO0f/XV7GS1Myml9+mWwS4gx603MKz1y/4P9 D8KQ== X-Gm-Message-State: AD7BkJIYhuyyzyH/a5ta+hLhXjSqffULaJJuDnSdarv2ajkMAmo7xEo8SAu8uHdZY72Wzw== X-Received: by 10.55.54.14 with SMTP id d14mr32101557qka.64.1459972091063; Wed, 06 Apr 2016 12:48:11 -0700 (PDT) Received: from notebook ([2001:67c:370:168:d0a3:6f0d:3372:a13c]) by smtp.gmail.com with ESMTPSA id g184sm1954296qkb.7.2016.04.06.12.48.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 12:48:10 -0700 (PDT) Message-ID: <27E13094E90E4AC8BAE9DFF017324AE0@notebook> From: "Valery Smyslov" To: "Tero Kivinen" References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> <22277.20520.264319.773683@fireball.acr.fi> In-Reply-To: <22277.20520.264319.773683@fireball.acr.fi> Date: Wed, 6 Apr 2016 16:47:49 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:48:15 -0000 Hi, my comments mostly are addressed, thanks. The one still unaddressed is a strange comment "?SHOULD" in the last table (Section 4.2). What does it mean? Regards, Valery. -----Original Message----- From: Tero Kivinen Sent: Wednesday, April 6, 2016 3:06 PM To: internet-drafts@ietf.org Cc: ipsec@ietf.org ; i-d-announce@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt internet-drafts@ietf.org writes: > 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 of the IETF. This version includes the pre-shared keys (or "Shared Key Message Integrity Code") in the authentication method table, as it specified in the RFC7296 as mandatory to implement, so we want to say it MUST here too. While I was doing that change, I noticed that we actually update the RFC7296, as the 7296 section 4 has text saying that RSA with key lengths of 1024 or 2048 are mandatory. In our section 4.1.1 we actually say that RSA key lengths with less than 2048 bits are SHOULD NOT, so our recommendation are different than what is in the RFC7296. After quick verify from our WG chair, I marked this document as updating the RFC7296 (and added the missing fact that is obsoletes rfc4307). The fact that this updates RFC7296 was also added in the introduction. In addition to those changes, this contains some fixes for some typos etc (especially in the section 5 algoritms for IoT). With these changes, I think this document is ready for the WGLC. > Title : Algorithm Implementation Requirements and Usage > Guidance for IKEv2 > Authors : Yoav Nir > Tero Kivinen > Paul Wouters > Daniel Migault > Filename : draft-ietf-ipsecme-rfc4307bis-06.txt > Pages : 16 > Date : 2016-04-06 > > Abstract: > The IPsec series of protocols makes use of various cryptographic > algorithms in order to provide security services. The Internet Key > Exchange (IKE) protocol is used to negotiate the IPsec Security > Association (IPsec SA) parameters, such as which algorithms should be > used. To ensure interoperability between different implementations, > it is necessary to specify a set of algorithm implementation > requirements and usage guidance to ensure that there is at least one > algorithm that all implementations support. This document defines > the current algorithm implementation requirements and usage guidance > for IKEv2. This document does not update the algorithms used for > packet encryption using IPsec Encapsulated Security Payload (ESP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-06 > > > 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/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Apr 6 15:18:10 2016 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 DE69612D15D for ; Wed, 6 Apr 2016 15:18:08 -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 LghR3oXFv6g7 for ; Wed, 6 Apr 2016 15:18: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 282F012D101 for ; Wed, 6 Apr 2016 15:18:04 -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 u36MI0Gv007781 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Apr 2016 01:18:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u36MHx0V027073; Thu, 7 Apr 2016 01:17:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22277.35607.896237.279372@fireball.acr.fi> Date: Thu, 7 Apr 2016 01:17:59 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <27E13094E90E4AC8BAE9DFF017324AE0@notebook> References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> <22277.20520.264319.773683@fireball.acr.fi> <27E13094E90E4AC8BAE9DFF017324AE0@notebook> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:18:09 -0000 Valery Smyslov writes: > my comments mostly are addressed, thanks. > The one still unaddressed is a strange comment "?SHOULD" in the last table > (Section 4.2). What does it mean? I think that is leftover from our internal discussions, i.e. whether we should mark that ecdsa-with-sha512 as SHOULD instead of MAY. I think MAY is fine, so unless people think we should pick that too with SHOULD, I will remove that in next version. I do not think we need to do it now, we can do the WGLC with the draft we have now, and remove it after that. Other thing I want people to think is whether we should say something else about the AES key sizes, i.e. we now say MUST for 128-bit, MAY for 256-bit and "192-bit keys can safely be ignored." One proposal that was done was to change that MUST for 128-bit, SHOULD for 256-bit, and perhaps even SHOULD NOT for 192-bit. -- kivinen@iki.fi From nobody Thu Apr 7 06:17:13 2016 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 04C1712D954 for ; Thu, 7 Apr 2016 06:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 GxUEs2GCw8Mx for ; Thu, 7 Apr 2016 06:17:08 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (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 8719B12D92A for ; Thu, 7 Apr 2016 06:17:08 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id f105so38623188qge.2 for ; Thu, 07 Apr 2016 06:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=/0BdEsa0nWCDnFGqBMHOwLPyRngJy96gD7X+/kAfMl0=; b=B7RrEfcm6Uo7dbwWwPoAPOsNNqmQmkekIv4q5bNrUkY/Yuq+X6cnXu7i5cbc/8oLYA X7HR8wHXEVrK9UTD0pMiNAuwRfsDHiDI2H1n/oExP/yGxko937ETHG2u+YZYsEVvJmXV h9Tx5554WlcVMW1owwQbGxO/ceQHdmYMapHdJzXRuXE6qYme/wjHcsWuiucE0AV84HXr MGT/QKSrmSor0WZVs5xj8ylPFGnZl3SEoZIvZfnGvfqjrSrKT7tO2ziXEo18szoJe0wW EfPoz6VowfA+1rmn08aTACkFkbXGAOptrWVKfoHp0ll1od+VwLvF9K5Wh+bYlheNoLgG 5bgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=/0BdEsa0nWCDnFGqBMHOwLPyRngJy96gD7X+/kAfMl0=; b=ZLIclcYCAPD7jSWdXNanVw2rqcTm0VwX0xcDBj4LZB+Ft5NnVjvLq/JpqOVandlJNN GUkgGO9ix/oH9mfy4+x2tcSKz4mWa/Ddnt4rvaqGsIujm3j8CegiKPqa6JRd2W1IfuQ9 M6gUE9jOpNx7tMfGopkJU+JgcJUc0Q78mmbHB6dzR9xA8fmWqdeqs2hXyWWElXsa1l5T CJNThyJn5crgmQZuDeRvbP9GixDKN/kPhIVL3NRyPFUqpvy0Isdrnv1hfHSX/ZhC2H8Q DcTMLEa5T8n4FPvuH2xEaQiwbrSATjNv/6sf9GkqbkMLvEboHJ/HBBghTd7LvdsvJ9Yc EKWg== X-Gm-Message-State: AD7BkJLKIzm1Js3M8G9rWaovD+KT/s7pKB9wr1lAldJ3ewC2jZfi4SnNMtefyOJwWMZrcQ== X-Received: by 10.140.87.98 with SMTP id q89mr3550382qgd.8.1460035027465; Thu, 07 Apr 2016 06:17:07 -0700 (PDT) Received: from notebook ([2001:67c:370:168:4042:b869:58fd:1fcc]) by smtp.gmail.com with ESMTPSA id s67sm3352685qgs.48.2016.04.07.06.17.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 06:17:06 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com><22277.20520.264319.773683@fireball.acr.fi><27E13094E90E4AC8BAE9DFF017324AE0@notebook> <22277.35607.896237.279372@fireball.acr.fi> In-Reply-To: <22277.35607.896237.279372@fireball.acr.fi> Date: Thu, 7 Apr 2016 10:17:01 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:17:11 -0000 After re-reading the draft I think that I'm also a bit unhappy with the way the last table (Section 4.2) is introduced. The draft says that this table is: Recommendation of Authentication Method described in [RFC7427] notation. However, the values from this table are just examples in RFC7427. Why exactly these algorithms were selected for recommendation? What about others (EdDSA, GOST etc)? I understand that the algorithms listed were probably most popular (at least some of them) at the time RFC 7427 ws written. But why continue to maintain this list, when it is just a list of examples in RFC7427? Well, I understand that some recommendations should be given. But probably only those signing algorithms that have non-MAY status should be listed and a note should be added that all others are MAY (that will refer to any unlisted signature algorithm)? What others think? Regards, Valery. -----Original Message----- From: Tero Kivinen Sent: Wednesday, April 6, 2016 7:17 PM To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt Valery Smyslov writes: > my comments mostly are addressed, thanks. > The one still unaddressed is a strange comment "?SHOULD" in the last table > (Section 4.2). What does it mean? I think that is leftover from our internal discussions, i.e. whether we should mark that ecdsa-with-sha512 as SHOULD instead of MAY. I think MAY is fine, so unless people think we should pick that too with SHOULD, I will remove that in next version. I do not think we need to do it now, we can do the WGLC with the draft we have now, and remove it after that. Other thing I want people to think is whether we should say something else about the AES key sizes, i.e. we now say MUST for 128-bit, MAY for 256-bit and "192-bit keys can safely be ignored." One proposal that was done was to change that MUST for 128-bit, SHOULD for 256-bit, and perhaps even SHOULD NOT for 192-bit. -- kivinen@iki.fi From nobody Thu Apr 7 07:09:19 2016 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 2B24812D0E3 for ; Thu, 7 Apr 2016 07:09:18 -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 FjBsrAnzXc-T for ; Thu, 7 Apr 2016 07:09:11 -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 7213612D0B9 for ; Thu, 7 Apr 2016 07:09:10 -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 u37E95oM003251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Apr 2016 17:09:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u37E95HT002363; Thu, 7 Apr 2016 17:09:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22278.27137.445934.901390@fireball.acr.fi> Date: Thu, 7 Apr 2016 17:09:05 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> <22277.20520.264319.773683@fireball.acr.fi> <27E13094E90E4AC8BAE9DFF017324AE0@notebook> <22277.35607.896237.279372@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:09:18 -0000 Valery Smyslov writes: > After re-reading the draft I think that I'm also a bit unhappy with > the way the last table (Section 4.2) is introduced. The draft says > that this table is: > > Recommendation of Authentication Method described in [RFC7427] > notation. > > However, the values from this table are just examples in RFC7427. > Why exactly these algorithms were selected for recommendation? Note, that most of them are MAY, so we should really remove them from this draft. And they are the algorithms we expect people to use. > What about others (EdDSA, GOST etc)? EdDSA is just about getting oid, so we cannot really list it here. For GOST I have no idea what the oid would be. Both of them would be in the same level as sha256WithRSAEncryption, sha384WithRSAEncryption, sha512WithRSAEncryption, sha512WithRSAEncryption, dsa-with-sha256, ecdsa-with-sha384, and ecdsa-with-sha512. > I understand that the algorithms listed were probably most popular > (at least some of them) at the time RFC 7427 ws written. But why > continue to maintain this list, when it is just a list of examples > in RFC7427? One of the reason RF7427 lists that many oids, is that there is no centralized registry for them. I.e. you cannot go somewhere and get list of OIDs you can use for signatures, so RF7427 tried to collect all signature algortihms people might use. Anyways I think we need to remove all that is not SHOULD or SHOULD NOT from the list, i.e., everything we have MAY recommendation in the list. > Well, I understand that some recommendations should be given. > But probably only those signing algorithms that have non-MAY > status should be listed and a note should be added that > all others are MAY (that will refer to any unlisted signature > algorithm)? I agree on removing all MAY algorithms, we do not need note, as that is already said in the section 1.2. -- kivinen@iki.fi From nobody Thu Apr 7 07:40:58 2016 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 AC6E012D103 for ; Thu, 7 Apr 2016 07:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 84vrq_Jy5h3s for ; Thu, 7 Apr 2016 07:40:56 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 EE82E12D89F for ; Thu, 7 Apr 2016 07:26:29 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f52so64337602qga.3 for ; Thu, 07 Apr 2016 07:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=AabECLZlNp/XMnJxdAd3qe8gUlZNCl5psxDboXdNwYQ=; b=UihKnRQ5rlAUUtMv5m5gaLX60d1v0P8TSswRTP/NkWZpiN3BA53lf6ISSRCQ/l7M8O qoEvmmPa3KfX/cM0/CqlZNeIhBYS3tKh0G3qaqhmIcPNWOsQjFaHUogoP5vMZC232TlD VhcqZA3CtBfnYpE7xV1tMcH796TjEr1Sq9vNqcPGkuLLtRf4KHWEsXgZZjzvVIFy1AcS BsrF1eaQbtw7PR4U5p6ojKAnKE6EGqxHkckV3tONpx4ZWVrN0HdQV8vCBnfjcw8mHo4a EHoFqqL1HVqplWL++Y/WdNqvdjBDQktHos8aS0SeNbli78k2IbJfbugKq0LY7t1L7fjO /KMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=AabECLZlNp/XMnJxdAd3qe8gUlZNCl5psxDboXdNwYQ=; b=jxwv9mkEMzJxGr+77vcF9/ftEulW1pRfu6fUjNJk+jM0x60Qk6KS9GC6CWZd7aiy6Y l7hmeHDLrwvAxX5Hsc+gmgBSlxh013Ey+0G4/zmnMqp1vr0SsuWGy9RvlHKwnklGwkEE zEWwoM6r1YLCVeexu7E5Js9sk/5VN+9+Y0AO/fpH9UvpV8MjYwA9JNbuuo64X/E0TINx Zd77AcA51UIUYRPXWUA0LevcmVExMJa/dlyya/Qe2vhzClnaE1antOGxPC9vpUVslANn F2BSfjp+x6QARelNcPjbLrtZs7LL9PjayxZk5E4GZ6ipvaaCew0uhSE9v0jfRSJQEFnQ x+fA== X-Gm-Message-State: AD7BkJLP41ONAAAjhfnPS62N6xXtBTensWaucoGRKyyUFkcOqQNM138Har5PBZd/soJslQ== X-Received: by 10.140.91.34 with SMTP id y31mr4069279qgd.84.1460039188875; Thu, 07 Apr 2016 07:26:28 -0700 (PDT) Received: from notebook ([2001:67c:370:168:3083:2b51:b5a8:6909]) by smtp.gmail.com with ESMTPSA id a207sm3499893qkb.28.2016.04.07.07.26.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 07:26:27 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com><22277.20520.264319.773683@fireball.acr.fi><27E13094E90E4AC8BAE9DFF017324AE0@notebook><22277.35607.896237.279372@fireball.acr.fi> <22278.27137.445934.901390@fireball.acr.fi> In-Reply-To: <22278.27137.445934.901390@fireball.acr.fi> Date: Thu, 7 Apr 2016 11:26:23 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:40:57 -0000 >> After re-reading the draft I think that I'm also a bit unhappy with >> the way the last table (Section 4.2) is introduced. The draft says >> that this table is: >> >> Recommendation of Authentication Method described in [RFC7427] >> notation. >> >> However, the values from this table are just examples in RFC7427. >> Why exactly these algorithms were selected for recommendation? > > Note, that most of them are MAY, so we should really remove them from > this draft. That's what I suggest. > Anyways I think we need to remove all that is not SHOULD or SHOULD NOT > from the list, i.e., everything we have MAY recommendation in the >list. Fine. That will resolve my concern. > I agree on removing all MAY algorithms, we do not need note, as that > is already said in the section 1.2. OK. From nobody Thu Apr 7 07:47:49 2016 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 6945F12D5B5 for ; Thu, 7 Apr 2016 07:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 yGo-Jd8G_TCO for ; Thu, 7 Apr 2016 07:47:46 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 1031A12D554 for ; Thu, 7 Apr 2016 07:34:49 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id f105so40788745qge.2 for ; Thu, 07 Apr 2016 07:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YxthWDr4IvmdqSrUpUZ3kM8uTrUQBorjJFlzYsCecb8=; b=lyu0yVwX03u2nCzLfeGZg7OqnjTlZiD056Q6Wkvcr5w+LXZ9QwUuonoxK/uZ9M3+BR lL9VbnnXB4p1JE3IJp0qVUqxZp8IjQdmKc0zaIelto1+T/qdJXjlblk7TuZdnqP2PWMB hEJ2n3opkRdxSakq1+jrc9fjnqOY3PK2Apu13tcb5kAX0yyTiPEt7Yba8TX6cyw1bNQA /ttt4PE/dw1bn5pUi329rn9/P7enIVEUomZKKbb/ova3v11aHd4OTmaWu/HgMk7fDpe5 6a5eXiB1TMxhqoHPxudD/ns6q/ObrnQsL3BcAU2s/7qaFZj4/83szfLWhvGEYh4cZ7kf /0Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YxthWDr4IvmdqSrUpUZ3kM8uTrUQBorjJFlzYsCecb8=; b=fQ2lF80JGRchs/cs9JP0n3lYPANsn4ZeW5pUtnLQJYwL6dWQGt/pIdQV5OW9ZQvYT5 g3snHGnUOfzfV3a5TBRpcoMu547+kbTZI0NijyN8YOCVTqzHl/hVzT6wVLIXXbq8GzjD pX0U7X8WEHAiuV2npEN+OYpKRyYv/jWyPh9TkzelxDR+uy9vBk5k2dF/MJGqtiBOSuRF FIBB4Eg/2ykLRyXR84QlnA76gnnFmL4DAAVCnkAcF8r9jpI5nW59vJmBggFZFl9+zHOk nGxi7+m/LoQLTagL41zwGXiQjlf/VTjo/F03IQ2Jw5floWr0u4+cYskjFYt4Rkc+nPYu kGRQ== X-Gm-Message-State: AD7BkJJCSQAhw4AIUhePnpgeq8PYPbsI1WHxYPKpGhI/huMZCkYN+FAa+TCPYHQdiZATYQ== X-Received: by 10.140.169.132 with SMTP id p126mr4333904qhp.71.1460039688132; Thu, 07 Apr 2016 07:34:48 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:d4b7:43e3:ff81:50ca? ([2001:67c:370:160:d4b7:43e3:ff81:50ca]) by smtp.gmail.com with ESMTPSA id m22sm3508700qki.30.2016.04.07.07.34.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 07:34:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> Date: Thu, 7 Apr 2016 11:34:45 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> To: IPsecME WG , Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:47:48 -0000 No responses yet... Tero: What would it take to register an =E2=80=9Cidentity=E2=80=9D hash = function for use with the EdDSA? Yoav > On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: >=20 > Replying to myself... >=20 > I=E2=80=99ve been told off-list that it didn=E2=80=99t make sense to = introduce the hot, new algorithm as a MAY. The only reason I=E2=80=99m = suggesting this is that there are currently no implementations to = interop with, and no EdDSA certificates where the public keys might come = from. My main motivation is to MUST NOT the pre-hashed versions because = we don=E2=80=99t need them and again there=E2=80=99s no install base to = interop with. >=20 > Thinking it over, the new EdDSA signature algorithm defined in the = CFRG draft[1] can sign arbitrary-sized messages. We traditionally fed = the signature functions hashes of the message because these signature = functions only accepted a limited-size input. That is why the =E2=80=9Cdig= ital signature=E2=80=9D document (RFC 7427) has a negotiation and field = for hash algorithm. Since we don=E2=80=99t need that with this = particular algorithm, I suggest we don=E2=80=99t. IOW I=E2=80=99m = suggesting that we allocate a new entry in the =E2=80=9CIKEv2 Hash = Algorithms=E2=80=9D registry called =E2=80=9Cidentity=E2=80=9D that will = be used only with EdDSA signatures (or any future signature with the = same property). >=20 > Yoav >=20 > [1] See for example = https://tools.ietf.org/id/draft-irtf-cfrg-eddsa-05.html#rfc.section.5.1.6 >=20 >> On 4 Apr 2016, at 4:43 PM, Yoav Nir wrote: >>=20 >> Hi >>=20 >> At the meeting today, I presented the SafeCurves draft status and = asked the room whether we wanted to wait for CFRG and Curdle to settle = their respective RFCs. The room was unanimously in favor of not having = anything in the current draft, instead using RFC 7427 digital = signatures. To be certain if we *did* wait, we=E2=80=99d just list the = two OIDs from Curdle that we like (the non-prehashed ones). >>=20 >> Quoting from the Curdle draft, they have this: >>=20 >> id-Curve25519 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.1 = } >> id-Curve448 OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.2 = } >> id-Curve25519ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.3 = } >> id-Curve448ph OBJECT IDENTIFIER ::=3D { 1.3.6.1.4.1.11591.15.4 = } >>=20 >> In other news, it turns out that we still have some discussion to go = with 4307bis. So I suggest that we add these to table 9 of section 4.2 = there as follows: >>=20 >> +------------------------------------+------------+---------+ >> | Description | Status | Comment | >> +------------------------------------+------------+---------+ >> | RSASSA-PSS with SHA-256 | SHOULD | | >> | ecdsa-with-sha256 | SHOULD | | >> | sha1WithRSAEncryption | SHOULD NOT | | >> | dsa-with-sha1 | SHOULD NOT | | >> | ecdsa-with-sha1 | SHOULD NOT | | >> | RSASSA-PSS with Empty Parameters | SHOULD NOT | | >> | RSASSA-PSS with Default Parameters | SHOULD NOT | | >> | sha256WithRSAEncryption | MAY | | >> | sha384WithRSAEncryption | MAY | | >> | sha512WithRSAEncryption | MAY | | >> | sha512WithRSAEncryption | MAY | | >> | dsa-with-sha256 | MAY | | >> | ecdsa-with-sha384 | MAY | | >> | ecdsa-with-sha512 | MAY | ?SHOULD | >> | id-Curve25519 | MAY | | >> | id-Curve448 | MAY | | >> | id-Curve25519ph | MUST NOT | | >> | id-Curve448ph | MUST NOT | | >> +------------------------------------+------------+---------+ >>=20 >> What do others think? >>=20 >> Yoav >=20 From nobody Thu Apr 7 08:09:21 2016 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 3EC7712D5BC for ; Thu, 7 Apr 2016 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] 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 MHiXfQmaMnLc for ; Thu, 7 Apr 2016 08:09:18 -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 6AAC312D7FC for ; Thu, 7 Apr 2016 07:56:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qglz30ZP0zDnR; Thu, 7 Apr 2016 16:56:15 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 qpdmmBZamgdz; Thu, 7 Apr 2016 16:56:13 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 7 Apr 2016 16:56:12 +0200 (CEST) Received: from [10.210.128.57] (unknown [186.141.131.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id CD8836019B72; Thu, 7 Apr 2016 10:56:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CD8836019B72 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20160406165945.24993.3487.idtracker@ietfa.amsl.com> <22277.20520.264319.773683@fireball.acr.fi> <27E13094E90E4AC8BAE9DFF017324AE0@notebook> <22277.35607.896237.279372@fireball.acr.fi> <22278.27137.445934.901390@fireball.acr.fi> From: Paul Wouters Mime-Version: 1.0 (1.0) In-Reply-To: <22278.27137.445934.901390@fireball.acr.fi> Message-Id: <0BB81899-1955-47DA-8A80-491F89C546B7@nohats.ca> Date: Thu, 7 Apr 2016 11:52:43 -0300 To: Tero Kivinen X-Mailer: iPhone Mail (13E238) Archived-At: Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:09:20 -0000 Fine with me Sent from my iPhone > On Apr 7, 2016, at 11:09, Tero Kivinen wrote: > > Valery Smyslov writes: >> After re-reading the draft I think that I'm also a bit unhappy with >> the way the last table (Section 4.2) is introduced. The draft says >> that this table is: >> >> Recommendation of Authentication Method described in [RFC7427] >> notation. >> >> However, the values from this table are just examples in RFC7427. >> Why exactly these algorithms were selected for recommendation? > > Note, that most of them are MAY, so we should really remove them from > this draft. And they are the algorithms we expect people to use. > >> What about others (EdDSA, GOST etc)? > > EdDSA is just about getting oid, so we cannot really list it here. For > GOST I have no idea what the oid would be. Both of them would be in > the same level as sha256WithRSAEncryption, sha384WithRSAEncryption, > sha512WithRSAEncryption, sha512WithRSAEncryption, dsa-with-sha256, > ecdsa-with-sha384, and ecdsa-with-sha512. > >> I understand that the algorithms listed were probably most popular >> (at least some of them) at the time RFC 7427 ws written. But why >> continue to maintain this list, when it is just a list of examples >> in RFC7427? > > One of the reason RF7427 lists that many oids, is that there is no > centralized registry for them. I.e. you cannot go somewhere and get > list of OIDs you can use for signatures, so RF7427 tried to collect > all signature algortihms people might use. > > Anyways I think we need to remove all that is not SHOULD or SHOULD NOT > from the list, i.e., everything we have MAY recommendation in the > list. > >> Well, I understand that some recommendations should be given. >> But probably only those signing algorithms that have non-MAY >> status should be listed and a note should be added that >> all others are MAY (that will refer to any unlisted signature >> algorithm)? > > I agree on removing all MAY algorithms, we do not need note, as that > is already said in the section 1.2. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 7 13:31:31 2016 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 A74CF12D55A; Thu, 7 Apr 2016 13:31:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407203127.10005.99130.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 13:31:27 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:31:27 -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 of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-07.txt Pages : 16 Date : 2016-04-07 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-07 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 Thu Apr 7 13:37:34 2016 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 971A512D6E9 for ; Thu, 7 Apr 2016 13:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] 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 O1yEh_adxBgf for ; Thu, 7 Apr 2016 13:37:32 -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 404A912D175 for ; Thu, 7 Apr 2016 13:37:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qgvXn58PQzDpD for ; Thu, 7 Apr 2016 22:37:29 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 5bmQGz5-W5LM for ; Thu, 7 Apr 2016 22:37:28 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 7 Apr 2016 22:37:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E84B76019B72; Thu, 7 Apr 2016 16:37:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E84B76019B72 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E6BF018D66 for ; Thu, 7 Apr 2016 16:37:27 -0400 (EDT) Date: Thu, 7 Apr 2016 16:37:27 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <20160407203127.10005.99130.idtracker@ietfa.amsl.com> Message-ID: References: <20160407203127.10005.99130.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:37:33 -0000 On Thu, 7 Apr 2016, internet-drafts@ietf.org wrote: > 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 of the IETF. > > Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-07 This update has two changes: - Remove the MAY entries from the Recommendation of Authentication Method table. - Change 256 bit key size for encryption from MAY to SHOULD. It also seems to have some style changes, like re-introducing numbered tables, which were lost on the previous run. Perhaps Tero needs to update his xml2rfc tool :) With these changes, I believe the document is ready for WGLC. Paul From nobody Thu Apr 7 14:12:44 2016 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 F177E12D6DE for ; Thu, 7 Apr 2016 14:12:42 -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 y3YN_SKxaqh1 for ; Thu, 7 Apr 2016 14:12:40 -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 3B30B12D10C for ; Thu, 7 Apr 2016 14:12:39 -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 u37LCUE8016162 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Apr 2016 00:12:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u37LCSLI016869; Fri, 8 Apr 2016 00:12:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22278.52540.662618.380257@fireball.acr.fi> Date: Fri, 8 Apr 2016 00:12:28 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 8 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:12:43 -0000 Yoav Nir writes: > Tero: What would it take to register an =E2=80=9Cidentity=E2=80=9D ha= sh function for > use with the EdDSA=3F I assume you mean new value for the RFC7427 Hash Algorithm registry=3F That registry is by expert review, but as "identity" is not necessarely clear enough for the implementors, I would suggest writing internet-draft doing the allocation, and also explaining how the "identity" hash function would be used and where it can be used. That same draft could also point references to the suitable cfrg document, and recommend not using the ph versions. I.e., if we could use existing hash and signature algorithms then there would not be need for document, but if we want to define new "hash" algorithm, then I think we do need document that specifies where it can be used and how it is "calculated". And that same document can then also explain the signature algorithms where it is to be used, and provide references. =20 > > On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: > >=20 > > Replying to myself... > >=20 > > I=E2=80=99ve been told off-list that it didn=E2=80=99t make sense t= o introduce the > > hot, new algorithm as a MAY. The only reason I=E2=80=99m suggesting= this > > is that there are currently no implementations to interop with, > > and no EdDSA certificates where the public keys might come from. > > My main motivation is to MUST NOT the pre-hashed versions because > > we don=E2=80=99t need them and again there=E2=80=99s no install bas= e to interop > > with. > >=20 > > Thinking it over, the new EdDSA signature algorithm defined in the > > CFRG draft[1] can sign arbitrary-sized messages. We traditionally > > fed the signature functions hashes of the message because these > > signature functions only accepted a limited-size input. That is > > why the =E2=80=9Cdigital signature=E2=80=9D document (RFC 7427) has= a negotiation > > and field for hash algorithm. Since we don=E2=80=99t need that with= this > > particular algorithm, I suggest we don=E2=80=99t. IOW I=E2=80=99m s= uggesting that > > we allocate a new entry in the =E2=80=9CIKEv2 Hash Algorithms=E2=80= =9D registry > > called =E2=80=9Cidentity=E2=80=9D that will be used only with EdDSA= signatures (or > > any future signature with the same property). --=20 kivinen@iki.fi From nobody Thu Apr 7 21:29:23 2016 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 EDB6112D54B for ; Thu, 7 Apr 2016 21:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 XtajhswMnKuP for ; Thu, 7 Apr 2016 21:29:19 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 4AD3312D0B3 for ; Thu, 7 Apr 2016 21:29:19 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id i4so39870500qkc.3 for ; Thu, 07 Apr 2016 21:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qGFmJiu755pgU9xvXxBICW1D7L1fAiB610FnzwSTbdo=; b=atD2zj2CF02xFIrw85U4s0pQS6ljKleZauQqqSamZBkbEHHqI+D5aByYK4Msc9Y4k1 YH5Jt3pdRtjLbIOEsgd8aczTaek9Sd3wNuZF6QdwhYQEKyzaTIA7XRUqOxyuJiQwYgh2 R3uIdmqGkX6ViDr9kp+jue6LROgcXrEIX+wbZF1e9yVxX/3Ad8C8DSVlW/vIWPVw/3uz jzFdn0tBGw1ivQ1Ud6QB2kIDhEQRE9ayr1HC+BpI9QEbDQuCH2ks8vZxRCpWgQgoIQjY cXuWWA62vyTZ4hAXvl+UNDFYa7N0GjjX1XA+P/W6Ak8uFHt0FGW/CWViO0h4LSMS/VyE srpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qGFmJiu755pgU9xvXxBICW1D7L1fAiB610FnzwSTbdo=; b=iyR5YVh0Mi0Wwy1sIxZWz1aQC2/YfkE1NWqpLFaz4QTRsOH340xRK5NP/PUgXpYbnQ N1bn9rLiN2i3F2Pf+49dYS3+YzxIo7q7+I5ebYeea/Px9JWKMkd8g7jtWYPdl34v69Bg ZhpZws05QPqmPrPL1HO6haqMsUvvRJw93RJUVgR3KuUavpHF3xuV7dnrtGPIj5ftDJcG Gq0gE2jncmfjdy0VUY7qU2XX6qt4vYTsXr7qy834LkeioLwVdWjW5p5RKmVi78m8+WSa cX+QiN0y9VOiCsqN7VKAAJD3fx/UEYX5Z6zQmlcNAKh0Cf55+6s+A51YGW6awNzV/39S QpWw== X-Gm-Message-State: AD7BkJI85GBVsQZFMz+EwUNCc+KPltUAW2sHSdDaN1cP+V9IX5Kiy4WCID0G48Dord/0Zg== X-Received: by 10.55.73.211 with SMTP id w202mr8522173qka.39.1460089758375; Thu, 07 Apr 2016 21:29:18 -0700 (PDT) Received: from [10.10.5.235] ([190.111.246.204]) by smtp.gmail.com with ESMTPSA id a11sm4802305qge.43.2016.04.07.21.29.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Apr 2016 21:29:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <22278.52540.662618.380257@fireball.acr.fi> Date: Fri, 8 Apr 2016 01:29:15 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> <22278.52540.662618.380257@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 04:29:22 -0000 > On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> Tero: What would it take to register an =E2=80=9Cidentity=E2=80=9D = hash function for >> use with the EdDSA? >=20 > I assume you mean new value for the RFC7427 Hash Algorithm registry? > That registry is by expert review, but as "identity" is not > necessarely clear enough for the implementors, I would suggest writing > internet-draft doing the allocation, and also explaining how the > "identity" hash function would be used and where it can be used. >=20 > That same draft could also point references to the suitable cfrg > document, and recommend not using the ph versions. Like this? https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 > I.e., if we could use existing hash and signature algorithms then > there would not be need for document, but if we want to define new > "hash" algorithm, then I think we do need document that specifies > where it can be used and how it is "calculated". And that same > document can then also explain the signature algorithms where it is to > be used, and provide references. >=20 >>> On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: >>>=20 >>> Replying to myself... >>>=20 >>> I=E2=80=99ve been told off-list that it didn=E2=80=99t make sense to = introduce the >>> hot, new algorithm as a MAY. The only reason I=E2=80=99m suggesting = this >>> is that there are currently no implementations to interop with, >>> and no EdDSA certificates where the public keys might come from. >>> My main motivation is to MUST NOT the pre-hashed versions because >>> we don=E2=80=99t need them and again there=E2=80=99s no install base = to interop >>> with. >>>=20 >>> Thinking it over, the new EdDSA signature algorithm defined in the >>> CFRG draft[1] can sign arbitrary-sized messages. We traditionally >>> fed the signature functions hashes of the message because these >>> signature functions only accepted a limited-size input. That is >>> why the =E2=80=9Cdigital signature=E2=80=9D document (RFC 7427) has = a negotiation >>> and field for hash algorithm. Since we don=E2=80=99t need that with = this >>> particular algorithm, I suggest we don=E2=80=99t. IOW I=E2=80=99m = suggesting that >>> we allocate a new entry in the =E2=80=9CIKEv2 Hash Algorithms=E2=80=9D= registry >>> called =E2=80=9Cidentity=E2=80=9D that will be used only with EdDSA = signatures (or >>> any future signature with the same property). > --=20 > kivinen@iki.fi From nobody Fri Apr 8 05:30:18 2016 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 1CBA312D7E5 for ; Fri, 8 Apr 2016 05:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 e6R17qf1CesK for ; Fri, 8 Apr 2016 05:30:10 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 71C9912D760 for ; Fri, 8 Apr 2016 05:30:10 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id j35so88651640qge.0 for ; Fri, 08 Apr 2016 05:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jXE4cmtLTFz2ykyLOcjkn+KjnCpFshVlkWbpYv08KAw=; b=UwSnkfI0rVgBqesiRZeKPtTeAy4PZXOFLnRiZyUOkfPqYkVgzHONcT8PF0z/3JSCPq jFgTyAidTAlKigW6X/AJfZJYwo1rkEEiTF2+MoWE4SfHRs0ObynB4zcsYQ78IyxSxIQ1 MmTyvlJi07axUxR6/gOnlVYRIYNblnhATDtrfO/AEJBe4NAT/0o3/7weu98normZQisF /pnfoX5eAsyNxfw3ynEWOGJggmcubfZJcchrTRzOUp5Em+UGdf7wmXczwT1FWQwykDqS L6xL9mlnivmNx9fmaEZco98xYzBERtlpTOjDL22qN/Tq4dIa6TfCeiDMavEX9GD+cn+H /9pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jXE4cmtLTFz2ykyLOcjkn+KjnCpFshVlkWbpYv08KAw=; b=dtvJDBwm8uel41Gu/JkaVu9SqHuArPuw2zmExnHzSljV+QxN2NowW5iugUxK/oOgvO wyFRGDRQiyUs/b8DQGHlgLPXO3L8UvXUo2d3YG/AdWLGlFPVLFjArR4bIPHdl9AMHEZU jzdC1T/Q6Oe/WSNyVhBzOaodLoT/3/TRGh+HU6IudTLeXNKqrnJSHWJWDt+MixUejLPt X0y62gfHFtH3X63/shEUQHVP5RyDhMYzh7dK7Jp6EqeRmydrdefhCi3ASfOFDkJsf1Fc 8Or6x2bwKuAHx3whGlho9HJpGmzhUblFHFF/MEArvbx9aOV3l87/HUz8p14JWdvhp8LO ZcyA== X-Gm-Message-State: AD7BkJI4chas6cr3HF2xUSAd8Q29pYgcG9E24MsNM9M4JPOmLYjj5kQWup6ai5Y3bv5Hzw== X-Received: by 10.140.29.7 with SMTP id a7mr10567827qga.98.1460118609555; Fri, 08 Apr 2016 05:30:09 -0700 (PDT) Received: from [192.168.1.62] ([190.172.1.145]) by smtp.gmail.com with ESMTPSA id 43sm5399568qgh.28.2016.04.08.05.30.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2016 05:30:08 -0700 (PDT) To: Yoav Nir , Tero Kivinen References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> <22278.52540.662618.380257@fireball.acr.fi> From: Yaron Sheffer Message-ID: <5707A448.6060003@gmail.com> Date: Fri, 8 Apr 2016 09:30:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:30:17 -0000 "Identity" is the formally correct term, but I think "null" is much clearer than "identity". Especially in the context of certificates, where "identity" can be mistaken for something else. Thanks, Yaron On 04/08/2016 01:29 AM, Yoav Nir wrote: > >> On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: >> >> Yoav Nir writes: >>> Tero: What would it take to register an “identity” hash function for >>> use with the EdDSA? >> >> I assume you mean new value for the RFC7427 Hash Algorithm registry? >> That registry is by expert review, but as "identity" is not >> necessarely clear enough for the implementors, I would suggest writing >> internet-draft doing the allocation, and also explaining how the >> "identity" hash function would be used and where it can be used. >> >> That same draft could also point references to the suitable cfrg >> document, and recommend not using the ph versions. > > Like this? > https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 > >> I.e., if we could use existing hash and signature algorithms then >> there would not be need for document, but if we want to define new >> "hash" algorithm, then I think we do need document that specifies >> where it can be used and how it is "calculated". And that same >> document can then also explain the signature algorithms where it is to >> be used, and provide references. >> >>>> On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: >>>> >>>> Replying to myself... >>>> >>>> I’ve been told off-list that it didn’t make sense to introduce the >>>> hot, new algorithm as a MAY. The only reason I’m suggesting this >>>> is that there are currently no implementations to interop with, >>>> and no EdDSA certificates where the public keys might come from. >>>> My main motivation is to MUST NOT the pre-hashed versions because >>>> we don’t need them and again there’s no install base to interop >>>> with. >>>> >>>> Thinking it over, the new EdDSA signature algorithm defined in the >>>> CFRG draft[1] can sign arbitrary-sized messages. We traditionally >>>> fed the signature functions hashes of the message because these >>>> signature functions only accepted a limited-size input. That is >>>> why the “digital signature” document (RFC 7427) has a negotiation >>>> and field for hash algorithm. Since we don’t need that with this >>>> particular algorithm, I suggest we don’t. IOW I’m suggesting that >>>> we allocate a new entry in the “IKEv2 Hash Algorithms” registry >>>> called “identity” that will be used only with EdDSA signatures (or >>>> any future signature with the same property). >> -- >> kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Apr 8 05:57:40 2016 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 64ED912D711 for ; Fri, 8 Apr 2016 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 aY10dJRrg5n5 for ; Fri, 8 Apr 2016 05:57:36 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 24CC912D7E7 for ; Fri, 8 Apr 2016 05:57:36 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id i4so43440590qkc.3 for ; Fri, 08 Apr 2016 05:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=IoqcsPjgqX3UlsDsJwGpkpmJpz2zZHqY/6Ec2yU8r3g=; b=BYi0iNgN69agWjE+j3obHE+cFOTxWMFuPX+sh6+UzL6XN/t62yTZ3mQsQlvEeYW5RM qmIrAE1k7Pmx/P5HsXONjDfDsoJkAyfXLHLr2YLFM3J5/0nGHqlo2Oo1HXj6wMK+Hv4T Ttia+8h8t7c748lptXB/Kzt+Zd/JHGhbpJr+ZN6WdZ565IdxswmEafoYvIv77GnFuB+x 3vWoI9Q6V2ypRz+48beogQY+TglC/VQK6yt9l8q6j/CXGU80EZFT9WZtuJsEhCQnkCkR SlkbVP9p8zWy2xaEO20l+fUZmF2m37dpAay1qUFt66GR2qE/+dkjg+QLJk5R9AVuIXv1 SFcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=IoqcsPjgqX3UlsDsJwGpkpmJpz2zZHqY/6Ec2yU8r3g=; b=ECnEZGdTGiIRxGK9lf6XkHsXWhdpXy/Rq5g8aVGV50VUcptFPEdtYdYhWqZLOivEgg 6Ylbsdo5nZ7kZf59bSoZJ42K90kTyZW/1vZxpAXDT+ansWg11exM1nwqfbiXA84gPqUJ ujM1DspyDTro6v8q3Lv77rubXgBraXO6YobtZdiyaJpQg5nrQMOlnUTZRu50cXyD1SU2 +GPcY84AEgFxK1pvBUvWOt6jzmZkorMiyLnOf9/b3yjFWA7+hLNVr7bOvT+D3c/YayJG NK9xAKxPxSmWG0pVP910xfkXueeFwqoN+T4bYiod6pHJl3KO4X3ciTgnAg2PINdkBGk8 zCVg== X-Gm-Message-State: AD7BkJLyAWXHyDFfZLlXdhfsjaVeocfwk8ZsJ6KBIQxEqSSDh+A0BKY0Z2+lBxKSFzVo9w== X-Received: by 10.55.178.198 with SMTP id b189mr4720543qkf.98.1460120252267; Fri, 08 Apr 2016 05:57:32 -0700 (PDT) Received: from notebook ([2001:67c:370:168:f03c:11f3:5d31:fd82]) by smtp.gmail.com with ESMTPSA id f24sm5490695qkf.6.2016.04.08.05.57.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Apr 2016 05:57:31 -0700 (PDT) Message-ID: <9F91CB57F73A4D7C952128FA72636F68@notebook> From: "Valery Smyslov" To: "Yoav Nir" , "Tero Kivinen" , "Yaron Sheffer" References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> <22278.52540.662618.380257@fireball.acr.fi> <5707A448.6060003@gmail.com> In-Reply-To: <5707A448.6060003@gmail.com> Date: Fri, 8 Apr 2016 09:57:25 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:57:38 -0000 I also think that "null" is less ambiguous here. Regards, Valery. -----Original Message----- From: Yaron Sheffer Sent: Friday, April 8, 2016 9:30 AM To: Yoav Nir ; Tero Kivinen Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE "Identity" is the formally correct term, but I think "null" is much clearer than "identity". Especially in the context of certificates, where "identity" can be mistaken for something else. Thanks, Yaron On 04/08/2016 01:29 AM, Yoav Nir wrote: > >> On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: >> >> Yoav Nir writes: >>> Tero: What would it take to register an “identity” hash function for >>> use with the EdDSA? >> >> I assume you mean new value for the RFC7427 Hash Algorithm registry? >> That registry is by expert review, but as "identity" is not >> necessarely clear enough for the implementors, I would suggest writing >> internet-draft doing the allocation, and also explaining how the >> "identity" hash function would be used and where it can be used. >> >> That same draft could also point references to the suitable cfrg >> document, and recommend not using the ph versions. > > Like this? > https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 > >> I.e., if we could use existing hash and signature algorithms then >> there would not be need for document, but if we want to define new >> "hash" algorithm, then I think we do need document that specifies >> where it can be used and how it is "calculated". And that same >> document can then also explain the signature algorithms where it is to >> be used, and provide references. >> >>>> On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: >>>> >>>> Replying to myself... >>>> >>>> I’ve been told off-list that it didn’t make sense to introduce the >>>> hot, new algorithm as a MAY. The only reason I’m suggesting this >>>> is that there are currently no implementations to interop with, >>>> and no EdDSA certificates where the public keys might come from. >>>> My main motivation is to MUST NOT the pre-hashed versions because >>>> we don’t need them and again there’s no install base to interop >>>> with. >>>> >>>> Thinking it over, the new EdDSA signature algorithm defined in the >>>> CFRG draft[1] can sign arbitrary-sized messages. We traditionally >>>> fed the signature functions hashes of the message because these >>>> signature functions only accepted a limited-size input. That is >>>> why the “digital signature” document (RFC 7427) has a negotiation >>>> and field for hash algorithm. Since we don’t need that with this >>>> particular algorithm, I suggest we don’t. IOW I’m suggesting that >>>> we allocate a new entry in the “IKEv2 Hash Algorithms” registry >>>> called “identity” that will be used only with EdDSA signatures (or >>>> any future signature with the same property). >> -- >> kivinen@iki.fi > > _______________________________________________ > 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 From nobody Fri Apr 8 06:11:34 2016 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 4730C12D7EA for ; Fri, 8 Apr 2016 06:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 NWKESobDbJPi for ; Fri, 8 Apr 2016 06:11:30 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 5620812D694 for ; Fri, 8 Apr 2016 06:11:30 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id f105so65830440qge.2 for ; Fri, 08 Apr 2016 06:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJVc6jDLAPEFqA5k8dBbIojzlfrMWqP9VRwu/9TMFY8=; b=trMbkiHQsgmtJ+WV61lrPN0Nn/9PlCDGn/iADZ2FpuGYxoE/3xjGZxljw+NQil72TM q32Zv2Xtr6QNH24BOMgmlN9jODGyrioQGs3y1m4QAAe2LWxJEqEPepWzAJObJzWbggJD HTsKx4HvA2MdnyxAbcY9UTImhscrv3yZaYgte48MjGxT+dQvBNzmunJ1cWbTV8+20oG/ aD/0SFb9uQ2hvyPmHNSIJY9hrUxGYJ1nw1pHWAap+olLSemMC6LOwzDhLn0b7z9zjK9C SGmKgzwsi/j+xz7ynUWlQu1pXiiEJ6X0+BY1ZQbbUvy3pqwsacovfQsTeQnXRwDiPghM xduQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJVc6jDLAPEFqA5k8dBbIojzlfrMWqP9VRwu/9TMFY8=; b=PJin7mJ2Bj6Dq9ii06OFfF5e5aDO22dsqtH3xwOKFczpeW5R1LMlACP8aI+ZgUs8G8 pryaTtGSzSR2CUkhgbCGxw5TAb4CUNePiKxn+a5VknS//P0X7ovwrBK/Zv051HbRT2tN qAQbDPUt6WG3WIvuLmCwXsRBQPEO5nDkdfqZSuHhR1swywXbMq0+fs6Ch9eU1964VE8n 5rpnr+3HFbX9ENfxThqzn/KekfD+i6tX9fqQClfUsuWyPw3mIsY8/tVdmJ/va/u0v/Qh n+1f0rsEtOycjUWQUCbWV9khhQtQzlJlFCW4DU3Vd8yFVegdChWp6zYwW7O8HXXkYBgz seEw== X-Gm-Message-State: AD7BkJKIa6XhqrqW1l3HhPfkRQrVuUC8Kski2znWSsPcv2zW0M/Igz2PbPelYUJ8r1xcRQ== X-Received: by 10.140.221.9 with SMTP id r9mr11539962qhb.77.1460121089461; Fri, 08 Apr 2016 06:11:29 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:5cbd:ddba:32ba:9ab5? ([2001:67c:370:160:5cbd:ddba:32ba:9ab5]) by smtp.gmail.com with ESMTPSA id w16sm5478425qka.35.2016.04.08.06.11.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 06:11:28 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <9F91CB57F73A4D7C952128FA72636F68@notebook> Date: Fri, 8 Apr 2016 10:11:25 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0AA3EA1A-2E28-43B2-876A-210076CBAD54@gmail.com> References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> <22278.52540.662618.380257@fireball.acr.fi> <5707A448.6060003@gmail.com> <9F91CB57F73A4D7C952128FA72636F68@notebook> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:11:33 -0000 I can change that. However, =E2=80=9CIdentity=E2=80=9D is the term used = in the CFRG draft. > On 8 Apr 2016, at 9:57 AM, Valery Smyslov wrote: >=20 > I also think that "null" is less ambiguous here. >=20 > Regards, > Valery. >=20 > -----Original Message----- From: Yaron Sheffer > Sent: Friday, April 8, 2016 9:30 AM > To: Yoav Nir ; Tero Kivinen > Cc: IPsecME WG > Subject: Re: [IPsec] EdDSA Signatures in IKE >=20 > "Identity" is the formally correct term, but I think "null" is much > clearer than "identity". Especially in the context of certificates, > where "identity" can be mistaken for something else. >=20 > Thanks, > Yaron >=20 > On 04/08/2016 01:29 AM, Yoav Nir wrote: >>=20 >>> On 7 Apr 2016, at 6:12 PM, Tero Kivinen wrote: >>>=20 >>> Yoav Nir writes: >>>> Tero: What would it take to register an =E2=80=9Cidentity=E2=80=9D = hash function for >>>> use with the EdDSA? >>>=20 >>> I assume you mean new value for the RFC7427 Hash Algorithm registry? >>> That registry is by expert review, but as "identity" is not >>> necessarely clear enough for the implementors, I would suggest = writing >>> internet-draft doing the allocation, and also explaining how the >>> "identity" hash function would be used and where it can be used. >>>=20 >>> That same draft could also point references to the suitable cfrg >>> document, and recommend not using the ph versions. >>=20 >> Like this? >> https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 >>=20 >>> I.e., if we could use existing hash and signature algorithms then >>> there would not be need for document, but if we want to define new >>> "hash" algorithm, then I think we do need document that specifies >>> where it can be used and how it is "calculated". And that same >>> document can then also explain the signature algorithms where it is = to >>> be used, and provide references. >>>=20 >>>>> On 5 Apr 2016, at 11:09 AM, Yoav Nir wrote: >>>>>=20 >>>>> Replying to myself... >>>>>=20 >>>>> I=E2=80=99ve been told off-list that it didn=E2=80=99t make sense = to introduce the >>>>> hot, new algorithm as a MAY. The only reason I=E2=80=99m = suggesting this >>>>> is that there are currently no implementations to interop with, >>>>> and no EdDSA certificates where the public keys might come from. >>>>> My main motivation is to MUST NOT the pre-hashed versions because >>>>> we don=E2=80=99t need them and again there=E2=80=99s no install = base to interop >>>>> with. >>>>>=20 >>>>> Thinking it over, the new EdDSA signature algorithm defined in the >>>>> CFRG draft[1] can sign arbitrary-sized messages. We traditionally >>>>> fed the signature functions hashes of the message because these >>>>> signature functions only accepted a limited-size input. That is >>>>> why the =E2=80=9Cdigital signature=E2=80=9D document (RFC 7427) = has a negotiation >>>>> and field for hash algorithm. Since we don=E2=80=99t need that = with this >>>>> particular algorithm, I suggest we don=E2=80=99t. IOW I=E2=80=99m = suggesting that >>>>> we allocate a new entry in the =E2=80=9CIKEv2 Hash Algorithms=E2=80=9D= registry >>>>> called =E2=80=9Cidentity=E2=80=9D that will be used only with = EdDSA signatures (or >>>>> any future signature with the same property). >>> -- >>> kivinen@iki.fi >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec=20 From nobody Fri Apr 8 06:24:39 2016 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 14B8A12D0FF for ; Fri, 8 Apr 2016 06:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 S1t6SNH1oHHH for ; Fri, 8 Apr 2016 06:24:36 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E66712D12D for ; Fri, 8 Apr 2016 06:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1460121876; x=2324035476; 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=Cg0yVzzDWF1jeNlkf+ZWZTSAxvzjNWnB6kGNfVbhTEY=; b=udEHNsdVKGhAzZJpzJ7l9+BG4MOH9rATSPIDxzKR60CEzDuqIHB+Ub4BrBGYoEaX 31yWYvXaQPl7IWOWUdXHIgCFGR9FNvL69L4yrl8QyC4HfUZVq0oJVYT1qGP0hvOd sMHOifKXUvqupNsAbXp1e7ohGTuKx59tKv7yFIlOIn0dHpfPByPnVkrzxpkDReGc Gq8GqepdjH3tq0011UP06M23/oFwYWQu3aejlKuQglRJ13OFcWEbXGSqseP8RT2G bkaiueC6EGH275FlTprfFgrEZ1SYuZKL0i+fa6CA14p1VaV2QQWJBhZDNTCjGNu3 hqSWEbL+/7mnLyX6rAUDtA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id BC.F1.27179.411B7075; Fri, 8 Apr 2016 06:24:36 -0700 (PDT) X-AuditID: 11973e15-f79686d000006a2b-8c-5707b114d321 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id D6.0A.03597.411B7075; Fri, 8 Apr 2016 06:24:36 -0700 (PDT) Received: from [17.153.33.166] (unknown [17.153.33.166]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O5B00BXCH8U9J30@nwk-mmpp-sz09.apple.com> for ipsec@ietf.org; Fri, 08 Apr 2016 06:24:36 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3117\)) From: Tommy Pauly In-reply-to: Date: Fri, 08 Apr 2016 10:24:30 -0300 Content-transfer-encoding: quoted-printable Message-id: <9BA03D72-A643-4DE3-96DA-6F7D22BE7625@apple.com> References: <20160407203127.10005.99130.idtracker@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.3117) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FAYoSuykT3c4Osrbov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr492Ng4wFVzgrJv4PaGB8yN7FyMkhIWAicW3zVEYIW0ziwr31 bF2MXBxCAnsZJRbufMoEUzR513NWiMQyJomG5jYoZx6TxPdrD4BaODiEBSQkNu9JBDGZBdQl pkzJBenlFdCTmHv3JCuILSzgKrHrwESwxWwCKhLHv21gBrE5BRwlHt4/BFbDIqAqceDWBBYQ m1lAQ+Lik5PsELa2xJN3F1ghZtpI7HrzBMwWEqiQeP57H9idIgKKEpPOPGIBOUFCQFai91sO yJUSAkvYJD7N+cA0gVFkFsJ1s5BcNwvJhgWMzKsYhXITM3N0M/PM9BILCnJS9ZLzczcxggJ7 up3oDsYzq6wOMQpwMCrx8F54zxYuxJpYVlyZe4hRmoNFSZy3m5E9XEggPbEkNTs1tSC1KL6o NCe1+BAjEwenVANj2g/vjQsmzlRwXna2o6fGIvDdPpv00i1rxF3KDLRSRU7ovZjELbb0S2Pr xXz3b0JXj+XUvpJ/cWjJ6i3vf1z661XhdrZu+0GDsKs59rWlG6x3uad2q15nuzbTJj3zczfj C17P780N3c459buur6771X7du/2xpJdfnFPHp1VabEUCh/6z7ApRYinOSDTUYi4qTgQAT9Rp g00CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUi2FAcoCuykT3c4MEydov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr492Ng4wFVzgrJv4PaGB8yN7FyMkhIWAiMXnXc1YIW0ziwr31 bF2MXBxCAsuYJBqa21ghnHlMEt+vPQDKcHAIC0hIbN6TCGIyC6hLTJmSC9LLK6AnMffuSbA5 wgKuErsOTASbzyagInH82wZmEJtTwFHi4f1DYDUsAqoSB25NYAGxmQU0JC4+OckOYWtLPHl3 gRVipo3ErjdPwGwhgQqJ57/3MYHYIgKKEpPOPGIBOUFCQFai91vOBEbBWQgHzUJy0CwkQxcw Mq9iFChKzUmsNNVLLCjISdVLzs/dxAgOxMKIHYz/l1kdYhTgYFTi4b34ni1ciDWxrLgy9xCj BAezkgiv/Dr2cCHelMTKqtSi/Pii0pzU4kOMyUCvTGSWEk3OB0ZJXkm8oYmJgYmxsZmxsbmJ OWnCSuK8aY9YwoUE0hNLUrNTUwtSi2C2MHFwSjUwJtvsNF08Z6EXb5fS69kTV8cvkk1SYj53 oCK2dw2/N5NpXIBjUrtZ9eEUl81aBd4H8kPDS2RedVQ8KeG9F3N+ypRm9sr8iz+r9vofWZjB P010yiTtkmU23vM9a+LrbP0bRNkSzyjF/woJW/Dl18/9Kix6wbMnfOCcmN0p/p7h1XGZfx/e L5mgxFKckWioxVxUnAgAluqOpIgCAAA= Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:24:38 -0000 This version looks good to me! Seems ready for WGLC. =E2=80=94Tommy > On Apr 7, 2016, at 5:37 PM, Paul Wouters wrote: >=20 > On Thu, 7 Apr 2016, internet-drafts@ietf.org wrote: >=20 >> 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 of the IETF. >>=20 >> Title : Algorithm Implementation Requirements and = Usage Guidance for IKEv2 >=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-rfc4307bis-07 >=20 > This update has two changes: >=20 > - Remove the MAY entries from the Recommendation of Authentication = Method > table. > - Change 256 bit key size for encryption from MAY to SHOULD. >=20 > It also seems to have some style changes, like re-introducing numbered > tables, which were lost on the previous run. Perhaps Tero needs to > update his xml2rfc tool :) >=20 > With these changes, I believe the document is ready for WGLC. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 8 07:31:00 2016 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 D133512D774 for ; Fri, 8 Apr 2016 07:30:58 -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 Jtgtplv1rHQN for ; Fri, 8 Apr 2016 07:30:56 -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 843AD12D8BF for ; Fri, 8 Apr 2016 07:30:55 -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 u38EUoUY019256 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Apr 2016 17:30:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u38EUoMG017218; Fri, 8 Apr 2016 17:30:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22279.49306.488475.545859@fireball.acr.fi> Date: Fri, 8 Apr 2016 17:30:50 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <0DDFFD34-1114-470B-AD6F-4F7C38D7AECF@gmail.com> <9FE89ED3-4DE9-4FA2-882C-11C157BDE09E@gmail.com> <22278.52540.662618.380257@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] EdDSA Signatures in IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:30:59 -0000 Yoav Nir writes: > > That same draft could also point references to the suitable cfrg > > document, and recommend not using the ph versions. > > Like this? > https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00 Yep. One nit: OLD To signal within IKE that no hashing needs to be done. A new value has to be signalled in the SIGNATURE_HASH_ALGORITHMS notification, one that indicates that no hashing is performed. NEW To signal within IKE that no hashing needs to be done, we need a new value in the SIGNATURE_HASH_ALGORITHMS notification to signal that. Why only SHOULD NOT for pre-hashed version? Would it not be better to just say MUST NOT? -- kivinen@iki.fi From nobody Fri Apr 8 12:09:23 2016 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 0341712D191 for ; Fri, 8 Apr 2016 12:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 iDtqS3IhfRCS for ; Fri, 8 Apr 2016 12:09:19 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 94AF312D0B0 for ; Fri, 8 Apr 2016 12:09:19 -0700 (PDT) Received: from [10.47.60.78] (190-174-163-31.speedy.com.ar [190.174.163.31] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u38J999k090208 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Apr 2016 12:09:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 190-174-163-31.speedy.com.ar [190.174.163.31] (may be forged) claimed to be [10.47.60.78] From: "Paul Hoffman" To: "IPsecME WG" Date: Fri, 08 Apr 2016 16:09:07 -0300 Message-ID: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:09:21 -0000 Greetings. As discussed on the list for the past few weeks, and in the face-to-face meeting in Buenos Aires (which, for many of us, seems to translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready for WG Last Call. We would like everyone to review it carefully, given that there have been some significant changes over the past few months. This WG Last Call will end on April 22. It would be grand if everyone on this list would read the draft as if it was brand new and respond on the list with any problems, any questions, or even just "it is ready to progress as-is". Extra points are given for reviewers who don't wait until the last minute. --Paul Hoffman and Dave Waltermire From nobody Sun Apr 10 16:29:00 2016 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 61B2C12D660 for ; Sun, 10 Apr 2016 16:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 oXISpNYxzclC for ; Sun, 10 Apr 2016 16:28:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 5B48F12D65E for ; Sun, 10 Apr 2016 16:28:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id v188so67022100wme.1 for ; Sun, 10 Apr 2016 16:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lZm+n3QCIB59DV1hhb0tkNSfb/g8uFXBlnY8GKOkhAI=; b=XAqqIC750BrqumhPFCHAidaahzBY4yp1optz6jeRbZfN9oVohPaxBMX/gHPQ9Nk91r i25KyOCwfokEI8lRJxiOY1b+ufcoRkde9jgW5SDJ3gXtcXwAvsDiiXwf9b6RfdeshLv8 IgGAlnfSRTCOtEiJTdGtcmLznc3XXSYiA9zUrqmofendWc+4VfYD9/74sf1ma3GZL+ZI AXN0SttrcCWdehfhxNnkX4fNOrs/bGa4UUleqbfvhXMr2lmSPlVyuaLQMU5I/Qb82u1K cYrOXYDHufMQMlwKYOMAJlCTmLBm2x0an6GGqW3yBsD6iKRlWNka1dYw+aiW4fCr1Dmw bKcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lZm+n3QCIB59DV1hhb0tkNSfb/g8uFXBlnY8GKOkhAI=; b=Be6/+bMzP2GGrqXQ41eLzhpIj8UGj2XMPFlyOkvjMcRbDV+t0rg1X2gDzxMiGwJnEJ PJKtopB28iWzCpTWtmROR/WkLowhtEM3hRXYOMociNTOuHR1XftKNPVHzxOLOeBdmAd/ xxJGKSFs/aLgedMsvuc9Tt81AXacmvZVyj+rUTwAUL1Ey2gCDzzZrLDbZB6mmrTQkIEo vSHLocCLCZ6BhXPGmv8DAYcV+0CMa+DdJmXbjS9taTDDviPWiofULoJ/UjXUB4TM7jjx hztwG0akjtoUSNBsvUGMAskr+hnpGNdHbNUc6emaR0L80KLKIzq/bfOEz/r1yfywKMl5 AY1w== X-Gm-Message-State: AOPr4FUkYVoNCL9DEo2O43pGQPbXlQHmGyZY4Vs1irRyWk5DUfRe9rGsN3xrOM8h+8ph0w== X-Received: by 10.194.223.70 with SMTP id qs6mr7114293wjc.119.1460330936729; Sun, 10 Apr 2016 16:28:56 -0700 (PDT) Received: from [172.19.249.191] ([88.128.81.255]) by smtp.gmail.com with ESMTPSA id f186sm7252878wmf.24.2016.04.10.16.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 16:28:55 -0700 (PDT) To: Paul Hoffman , IPsecME WG References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> From: Yaron Sheffer Message-ID: <570AE1AD.3060001@gmail.com> Date: Mon, 11 Apr 2016 01:28:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 23:29:00 -0000 I think this document is in very good shape, and almost ready. The two areas where I think some more discussion may be needed are interoperability between IoT and "real" VPNs, and the migration to the RFC 7427 Digital Signature solution. See detailed comments below. 1.2: "an algorithm will be set to MAY", replace by "an algorithm will be denoted here as MAY". 1.2, last paragraph: I suggest to clarify what we mean by interop with IoT, so that we do not fragment IKE2 between the IoT and non-IoT worlds. Something like: "Requirement levels that are marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general-purpose VPN gateways." Maybe we should clarify it more by defining an IoT Context and adding separate lines to some of the tables for IoT vs. non-IoT Context. 3.3: AUTH_DES_MAC - the last sentence doesn't apply to it, so the paragraph needs to be rearranged. 4.1: have we considered making "Digital Signature" (#14) a SHOULD+ instead of a SHOULD? 4.2: aren't we trying to move the world to the generic "Digital Signature", even if they're still using old certs? If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD. And the table should mention sha256WithRSAEncryption. Thanks, Yaron On 04/08/2016 09:09 PM, Paul Hoffman wrote: > Greetings. As discussed on the list for the past few weeks, and in the > face-to-face meeting in Buenos Aires (which, for many of us, seems to > translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready > for WG Last Call. We would like everyone to review it carefully, given > that there have been some significant changes over the past few months. > > This WG Last Call will end on April 22. It would be grand if everyone on > this list would read the draft as if it was brand new and respond on the > list with any problems, any questions, or even just "it is ready to > progress as-is". Extra points are given for reviewers who don't wait > until the last minute. > > --Paul Hoffman and Dave Waltermire > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 11 05:47:23 2016 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 4CB6612EB54 for ; Mon, 11 Apr 2016 05:47:22 -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 dKylI7JZEl4U for ; Mon, 11 Apr 2016 05:47:18 -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 F03D912EC6B for ; Mon, 11 Apr 2016 05:47:17 -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 u3BClChS026679 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Apr 2016 15:47:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3BClBlO022435; Mon, 11 Apr 2016 15:47:11 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22283.40143.898294.982675@fireball.acr.fi> Date: Mon, 11 Apr 2016 15:47:11 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <570AE1AD.3060001@gmail.com> References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 17 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:47:22 -0000 Yaron Sheffer writes: > 4.1: have we considered making "Digital Signature" (#14) a SHOULD+ > instead of a SHOULD? Yes, I think we discussed it, but I think we should really see at least one implementation before we pick it as SHOULD+ level... Has anybody implemented this yet? This is still quite new, i.e., about year old, and as product cycles tend to be quite slow in the VPN gateways, I have not yet seen any implementations. > 4.2: aren't we trying to move the world to the generic "Digital > Signature", even if they're still using old certs? Yes. > If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD. Why? There is no relationship between the RSASSA-PSS and RSASSA-PKCS1-v1.5 signatures in the certificates and in the AUTH payload. I.e., you can have RSASSA-PKCS1-v1.5 signature in the certificate, and use the RSASSA-PSS with SHA-256 to generate the AUTH payload. Also as we do say that RSASSA-PSS MUST be implemented, that means that every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and conforms to this document, must support RSASSA-PSS, thus implementations can always use it when using RSA keys. Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427 implementations which are made before this 4307bis document came out, and which do not support RSASSA-PSS required here. > And the table should mention sha256WithRSAEncryption. Which by defination is then MAY. And it is MAY because it is not using SHA1 (which would make it SHOULD NOT), and it is using old RSASSA-PKCS1-v1.5 which is only MAY. We did remove all MAY lines from the table in last round. -- kivinen@iki.fi From nobody Mon Apr 11 08:05:47 2016 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 C778D12EBC1 for ; Mon, 11 Apr 2016 08:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 gDYo8bXwgxU8 for ; Mon, 11 Apr 2016 08:05:44 -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 CF01212EBFB for ; Mon, 11 Apr 2016 08:05:43 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a140so16920801wma.0 for ; Mon, 11 Apr 2016 08:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8DIfNe4gpxsDphR6rlwdcb9s6YTnCR+/KPKfU9vymU0=; b=ZdZ4+7ZBnjuKnumOZPKai4hSTPiVteoWrslOLpYjmcdaFCgayRcaLVnDCy7ov/n2H5 rMnTfay5THrq42eexh5tThkXSS7lg/hA0ENYrTOgpBTJL2YjtH1e+HPYZXkNwxnIelWA s1EKGpk0M7dKZvXB5uPCDj1SE5J+y70Ntl0lwx7w11ZExR9PyQymFJoM7CAzo9Vsucl1 trkEQGqRj+SbPal13qK5BODFzBOkn3M4hzlGJhZFJI9bGBl668JnnXFtgNYdptNCfeVa 9Wwr6xJOCkMnURpEZAS5kzWd2abCwXD+7BA5vIhPuF7Tn0eSXHqgW82iw2j0idiKTmB4 Fpew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8DIfNe4gpxsDphR6rlwdcb9s6YTnCR+/KPKfU9vymU0=; b=f92B+o7iAz3l4EkHUOGiJ40SIAXHOOxktcU3DsabYfzjrCkTq6ZVpz7qGFCRyXVFxW k3TGNwB85cxA0KqHJhoTx49zM0b6O3iaxzFsMKBCSrkKxm7M/fxtpS7YEsden0jtQQQo uMV3rZxABSDwVc+H5j3bojCfLQt4bGERCcekEJUUPeTNE7JE5yO5Se5zH7C7mK0nXbdq /6AFqIlRErciSgKkYj9GSNDI1swuZQ4hKnTJBAeCfY0zTiYO6S0N5AO4iT1yUB/Q8dGT SAPU0D7sOTd3WoiPo0VOlZb5lWGj7jbto9c225h7OasWkKCca57C19ULtzx7pAjj0Eip dwtA== X-Gm-Message-State: AD7BkJKUyKPxUFiHlPztowlIIgqqpP7osNie/jxZfJ9tF1OU7H/e3D1rO5uc0D3K2KNoIA== X-Received: by 10.28.213.142 with SMTP id m136mr19435297wmg.24.1460387142375; Mon, 11 Apr 2016 08:05:42 -0700 (PDT) Received: from [10.53.148.108] ([88.128.80.225]) by smtp.gmail.com with ESMTPSA id c125sm17939333wme.6.2016.04.11.08.05.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 08:05:41 -0700 (PDT) To: Tero Kivinen References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> From: Yaron Sheffer Message-ID: <570BBD44.4010104@gmail.com> Date: Mon, 11 Apr 2016 17:05:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <22283.40143.898294.982675@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:05:46 -0000 Hi Tero, Thanks for your response, I am fine with your comments but I have a question: in Sec. 4.2, we have: "With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented." And then the table has SHOULD for RSA (as well as ECDSA). How come? Coming to think of it, if we want to ensure interoperability between peers that use RSA certs and peers that use ECDSA certs, then at least one (probably RSA) needs to be a MUST, even if people are using RFC7427. Thanks, Yaron On 04/11/2016 02:47 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> 4.1: have we considered making "Digital Signature" (#14) a SHOULD+ >> instead of a SHOULD? > > Yes, I think we discussed it, but I think we should really see at > least one implementation before we pick it as SHOULD+ level... > > Has anybody implemented this yet? > > This is still quite new, i.e., about year old, and as product cycles > tend to be quite slow in the VPN gateways, I have not yet seen any > implementations. > >> 4.2: aren't we trying to move the world to the generic "Digital >> Signature", even if they're still using old certs? > > Yes. > >> If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD. > > Why? There is no relationship between the RSASSA-PSS and > RSASSA-PKCS1-v1.5 signatures in the certificates and in the AUTH > payload. > > I.e., you can have RSASSA-PKCS1-v1.5 signature in the certificate, and > use the RSASSA-PSS with SHA-256 to generate the AUTH payload. > > Also as we do say that RSASSA-PSS MUST be implemented, that means that > every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and > conforms to this document, must support RSASSA-PSS, thus > implementations can always use it when using RSA keys. > > Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427 > implementations which are made before this 4307bis document came out, > and which do not support RSASSA-PSS required here. > >> And the table should mention sha256WithRSAEncryption. > > Which by defination is then MAY. And it is MAY because it is not using > SHA1 (which would make it SHOULD NOT), and it is using old > RSASSA-PKCS1-v1.5 which is only MAY. > > We did remove all MAY lines from the table in last round. > From nobody Tue Apr 12 02:16:38 2016 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 974B512D8FE for ; Tue, 12 Apr 2016 02:16:37 -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 1j0Ej7gggQDF for ; Tue, 12 Apr 2016 02:16:36 -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 9865412E932 for ; Tue, 12 Apr 2016 02:16:35 -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 u3C9GTDK001198 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Apr 2016 12:16:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3C9GSqs026710; Tue, 12 Apr 2016 12:16:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22284.48364.866135.876826@fireball.acr.fi> Date: Tue, 12 Apr 2016 12:16:28 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <570BBD44.4010104@gmail.com> References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 17 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 09:16:37 -0000 Yaron Sheffer writes: > Thanks for your response, I am fine with your comments but I have a > question: in Sec. 4.2, we have: "With the use of Digital Signature, > RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented." > And then the table has SHOULD for RSA (as well as ECDSA). How come? RSASSA-PSS MUST be implemented if Digital Signature authentication method is implemented, but it can be implemented with multiple hash algorithms. On the other hand in hash algorithms part we have just one MUST and that is for SHA2-256. The reason why RSASSA-PSS with SHA-256 is listed only as SHOULD, is mostly caused by the fact that Digital Signature authentication method is still onl SHOULD and we do not have implementations for it, so we do not have implementor comments for it yet. So Digital Signature in general is SHOULD. SHA2-256 as hash algorithm is MUST when implementing Digital Signature authentication method. RSASSA-PSS is MUST when implementing Digital Signature. That would actually make RSASSA-PSS with SHA-256 a effective MUST, if Digital Signature is in general supported, but we do not label it as MUST as complient implementation can still decide not to implement digital signatures at all. > Coming to think of it, if we want to ensure interoperability between > peers that use RSA certs and peers that use ECDSA certs, then at least > one (probably RSA) needs to be a MUST, even if people are using RFC7427. Usually this is not a problem, i.e., in normal use the configuration has just one private key (either rsa or ECDSA) and that is what is used. If you have ECDSA private key and they implementation does not support ECDSA, you cannot use that implementation, you need to pick another implementation. The other end of the configuration is also configured to trust your private key (either by config, or through CA), and if it cannot support your private key type you cannot really configure it that way. I.e., the implementation requirements do not come from this document, they came from the pre-existing authentication infrastructure and private keys users have. Anyways when we make Digital Signature authentication method a MUST, we can also make RSASSA-PSS with SHA-256 a MUST. The question there is should we already mark this fact by making it now SHOULD+, as we do expect it to be next mandatory to implement algorithm if Digital Signature authentication method really gets deployed? -- kivinen@iki.fi From nobody Wed Apr 13 07:37:59 2016 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 5C11112E17B for ; Wed, 13 Apr 2016 07:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_DNSWL_LOW=-0.7, 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 yt511gaifS1F for ; Wed, 13 Apr 2016 07:37:56 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 0400512E104 for ; Wed, 13 Apr 2016 07:37:56 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id tz8so34440828obc.0 for ; Wed, 13 Apr 2016 07:37:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=j+t7EzFAI8i7sK9yp/Q4utMrfkrOcEPaexx8Ip8Atgk=; b=GDy4fbL1G7N8oRlAWoi/zZUtKZ4Rpch+7yCw7sIEn7BgtEzbnNtJfZCTFV/D5rXUr6 /eGrzhNeXjCrlcUrIlNWdlYwrixbL50ejmenxPx2n/UEgir7Elil3CfiCm9yg1uf7vED 7fwhOIkyidzpsjsFhCaHp+R0skgHddE2yvSSD3XcHST+2r5XYyxfaXA4UlF/zXcv7J+a +7vF4RmMbwgOTnQ4qPdlhdSjWReuzBLMyRSRcti0kHaSZ4mSeBQkwFEJ6znQWu8EUiMZ kLDEVmWgZOudVgZpsrj/qCn9uy8ZhxPYb7RYrVIEtfX3yFCtcfmEJxbfKV8wSWk5MN6P 6dBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=j+t7EzFAI8i7sK9yp/Q4utMrfkrOcEPaexx8Ip8Atgk=; b=Cpv1LGYrJ7+6iWSx2UG6en+wxZyZ7+TyS881Utmgsr5zb28otG1cST8MR15fep/kGN ikvwOo+aJHmn2fOzyqB6zMrNIy9OdW8QGTuwVSGXDrr3Nea9R3SE6PcDKUbg+ImeSDfU 3ypNQzsq3O8Y/snCL9vFe4rFuUnjTDnKwwE+ktzt6T2FlU8UwZOdgY6b6YG1+5yvOsXa w0lxDCLqaNXO3e3nIPT057MZ7XZ9o6AR7o+xOU8wk20leteycOB0Rq6nlqX0XTyGcD8Y pipmwQHmtBbtejb0kL3R22JM3BpDooDCd4bscrvHPhOk7iy9UYpMRDoi0jqlT2uEcsNC za+g== X-Gm-Message-State: AOPr4FWFbiu+b+Fs4o84ZUAFoVoD/m0MhyciFcZe1d1wGdHQ5ybRu5otqqKpSTFLyYS4ug== X-Received: by 10.182.110.198 with SMTP id ic6mr4807946obb.15.1460558275374; Wed, 13 Apr 2016 07:37:55 -0700 (PDT) Received: from [172.18.133.40] (cowboy.intuit.com. [65.204.229.11]) by smtp.gmail.com with ESMTPSA id l13sm1860913oei.13.2016.04.13.07.37.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 07:37:54 -0700 (PDT) To: Tero Kivinen References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> <22284.48364.866135.876826@fireball.acr.fi> From: Yaron Sheffer Message-ID: <570E59BD.8050606@gmail.com> Date: Wed, 13 Apr 2016 17:37:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <22284.48364.866135.876826@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:37:57 -0000 On 04/12/2016 12:16 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Thanks for your response, I am fine with your comments but I have a >> question: in Sec. 4.2, we have: "With the use of Digital Signature, >> RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented." >> And then the table has SHOULD for RSA (as well as ECDSA). How come? > > RSASSA-PSS MUST be implemented if Digital Signature authentication > method is implemented, but it can be implemented with multiple hash > algorithms. On the other hand in hash algorithms part we have just one > MUST and that is for SHA2-256. > > The reason why RSASSA-PSS with SHA-256 is listed only as SHOULD, is > mostly caused by the fact that Digital Signature authentication method > is still onl SHOULD and we do not have implementations for it, so we > do not have implementor comments for it yet. > > So Digital Signature in general is SHOULD. > > SHA2-256 as hash algorithm is MUST when implementing Digital Signature > authentication method. > > RSASSA-PSS is MUST when implementing Digital Signature. > > That would actually make RSASSA-PSS with SHA-256 a effective MUST, if > Digital Signature is in general supported, but we do not label it as > MUST as complient implementation can still decide not to implement > digital signatures at all. > >> Coming to think of it, if we want to ensure interoperability between >> peers that use RSA certs and peers that use ECDSA certs, then at least >> one (probably RSA) needs to be a MUST, even if people are using RFC7427. > > Usually this is not a problem, i.e., in normal use the configuration > has just one private key (either rsa or ECDSA) and that is what is > used. If you have ECDSA private key and they implementation does not > support ECDSA, you cannot use that implementation, you need to pick > another implementation. The other end of the configuration is also > configured to trust your private key (either by config, or through > CA), and if it cannot support your private key type you cannot really > configure it that way. I.e., the implementation requirements do not > come from this document, they came from the pre-existing > authentication infrastructure and private keys users have. > > Anyways when we make Digital Signature authentication method a MUST, > we can also make RSASSA-PSS with SHA-256 a MUST. > > The question there is should we already mark this fact by making it > now SHOULD+, as we do expect it to be next mandatory to implement > algorithm if Digital Signature authentication method really gets > deployed? > IMHO, yes. From nobody Wed Apr 13 07:40:49 2016 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 D76A212DE0A for ; Wed, 13 Apr 2016 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] 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 jxw5ooKpPC41 for ; Wed, 13 Apr 2016 07:40:47 -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 1FDDB12D551 for ; Wed, 13 Apr 2016 07:40:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qlRLP3pWPzpB; Wed, 13 Apr 2016 16:40:45 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 u9KaqWqw90Pp; Wed, 13 Apr 2016 16:40:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 13 Apr 2016 16:40:44 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 80F6B614AFE7; Wed, 13 Apr 2016 10:40:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 80F6B614AFE7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7CA44D5100; Wed, 13 Apr 2016 10:40:43 -0400 (EDT) Date: Wed, 13 Apr 2016 10:40:43 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <570E59BD.8050606@gmail.com> Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> <22284.48364.866135.876826@fireball.acr.fi> <570E59BD.8050606@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:40:48 -0000 On Wed, 13 Apr 2016, Yaron Sheffer wrote: >> Anyways when we make Digital Signature authentication method a MUST, >> we can also make RSASSA-PSS with SHA-256 a MUST. >> >> The question there is should we already mark this fact by making it >> now SHOULD+, as we do expect it to be next mandatory to implement >> algorithm if Digital Signature authentication method really gets >> deployed? >> > > IMHO, yes. I dont think we should make anything a SHOULD+ that we have not seen interoperate in the wild. In fact, even a SHOULD is pushing it already, but we really do want to push it in this case. Paul From nobody Thu Apr 14 07:22:17 2016 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 C882A12DAFD for ; Thu, 14 Apr 2016 07:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 1CBaHx4GCXsO for ; Thu, 14 Apr 2016 07:22:14 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 4F42D12DC27 for ; Thu, 14 Apr 2016 07:22:14 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id e190so110819430lfe.0 for ; Thu, 14 Apr 2016 07:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=2vpePqLXZUlCg+1bFq5mUyQqrosY6OTsXk9WzhD5Jm8=; b=mLYGqm0WiPIgZymOV6UwJz9cMzNLLRCwxqD6Dipl/dWyzExJQzfxg/bEdy4gLZMkMN cX6f8FKRiqWzldg8z+yub86aWC0iT+tzcwCqhnAEjO1DK3XU5fcZwzQkGUXqPZvIAcjf 2HJNTrtK4WMGqeOmBqOXVQHwbICtdD/Jij2qH0fX8cPrGjSGzcUu4kh5RI4hC66NUg3C qmi20bp4hp0OpXpzk6NfQ418Ta1CGd9lpbhkFSnpkrMj5zkiSSJO5tbakF3BnQT28lGw oXzEYzAILTVpkmk9rQiSeg09uQqAFLEzZGvyYEwsSuIHIk66EJ/xs/Vm8LpthUwHTEep kcrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=2vpePqLXZUlCg+1bFq5mUyQqrosY6OTsXk9WzhD5Jm8=; b=DI5y9oD5e4nxgbXFMcryB/zJZby33zyo1t6BPpUHHveSm3aO06dJISzLEHNqJAB2ZC GqQNlQpyRLGNn13T/GFiJCTNyyw46a7qoZTdNFJtUiGG4b63jGo5G6WXElBofq9DKB7O SGN7APw5vs8yMyZxaOgezRukYrWpAbpDy82ijx/W1G1FrSfk8MiaQGoDPgJAKKBJtC98 1fAk82OQ2PCppFjQzrsnJrDibH6laBdLNS9wqU/hcqxPL23Isoxm0Jzp0Jp2oAq1sUI3 x7VXZ2HqMkHb1+UDTz9H/1qE8BpHw8kW526OqIlkFY2aae2NOd6bAGm2ZZeww08oCNKM qcDw== X-Gm-Message-State: AOPr4FW9rVmP4Uh0EZQ32/wawDnFqFqQPjTPnM4XU57jxokXpFXQOWhJDEn1ZQoQ0jEq2Q== X-Received: by 10.112.51.8 with SMTP id g8mr5447280lbo.109.1460643732388; Thu, 14 Apr 2016 07:22:12 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id zw6sm6831227lbb.14.2016.04.14.07.22.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 07:22:11 -0700 (PDT) Message-ID: <1A58AF23AD5745489DD523298658A0D5@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Yaron Sheffer" References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> Date: Thu, 14 Apr 2016 17:22:01 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:22:16 -0000 Hi, > Yes, I think we discussed it, but I think we should really see at > least one implementation before we pick it as SHOULD+ level... > > Has anybody implemented this yet? Yes. > Also as we do say that RSASSA-PSS MUST be implemented, that means that > every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and > conforms to this document, must support RSASSA-PSS, thus > implementations can always use it when using RSA keys. > > Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427 > implementations which are made before this 4307bis document came out, > and which do not support RSASSA-PSS required here. I don't think it is a good idea in general to link support for RSASSA-PSS with support for RFC7427. However, I don't know a better solution for now. I think it is a deficiency of RFC7427 that it only allows to indicate the list of supported hash functions and doesn't allow to indicate supported signature formats. Regards, Valery. From nobody Thu Apr 14 07:30:34 2016 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 8B06412E250 for ; Thu, 14 Apr 2016 07:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 f_xL5yinYV7x for ; Thu, 14 Apr 2016 07:30:31 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 EBD0C12E237 for ; Thu, 14 Apr 2016 07:30:30 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id g184so110990993lfb.3 for ; Thu, 14 Apr 2016 07:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=X8ECEruqAxc2ov7lLjRlg2GkOprKMg0vBF6Ru+gbAo0=; b=pBJIJYaWmDnOn4Jukx6xKPeaK0iVx5EAOweaytcoDOF3zVfz/EUMu3D0kig/rWXgzl KpbD4G8xOQCgHC4OGVffUZ+WsCzTcYuIODverBdju4K78tZbY6s1LWxbC3pgCkHCWH8r 8oC5xBMZIqvoZQ3BpTpRFmqycm8pQ8d/KOXxUQCWiIQygnexOBPcTo13kWujC67rdlV0 xBdeKZ+uU5G8FqiYxWMBmj8Gv93kjlYe5xuudI/cvQbsShk84MZjwGlDxfeTLA3ycD+f TyQovDpSaYSZTx5qmmUvjlOrl92KXHmhJEKvoUEYNlhXTxU9URpwIWkq9ftLO7sb0hyO 1QfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=X8ECEruqAxc2ov7lLjRlg2GkOprKMg0vBF6Ru+gbAo0=; b=A1/QCShGSPU35/3JiIqfhzuU6sCyoWFrMdFZv+cFxrLgyOieSIJ8Z8cne+Yy17TqUh f7VaiSn8FBnq7On3rnipPHgnxxUwtVt/LBkEDXRJfy1XOtSAGGU3r54Ex8ClZmLfrffl cQIPMzMJ2866ztERGq4Bc5qJ0LorwPRQyZ2+nl14n5Nt4e6ewbk/uezfKadwV6RHeG0e YxS/cVVveB1D5KMhxyXBHkbQraqkzdS5aYY4sClcnjTyeLzIridvdH7gyO01RDRQPDX3 50blOzGkRH/0mv1xyH4TW7LTkDjujIvKqtIgRrN3+HFupLZFzsQ8O8x07zFswIcU3FdJ Aj6Q== X-Gm-Message-State: AOPr4FU6fQqHlU4X9OzsH+Zi9mJnhV1BL3MDIbIDibWiYvei/qhKLMA7ASqFAFSW2PsxrQ== X-Received: by 10.25.41.140 with SMTP id p134mr7079457lfp.15.1460644229180; Thu, 14 Apr 2016 07:30:29 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id lw1sm6808669lbc.15.2016.04.14.07.30.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 07:30:28 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , "Yaron Sheffer" References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> <22284.48364.866135.876826@fireball.acr.fi> Date: Thu, 14 Apr 2016 17:30:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:30:32 -0000 Hi, >> Thanks for your response, I am fine with your comments but I have a >> question: in Sec. 4.2, we have: "With the use of Digital Signature, >> RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented." >> And then the table has SHOULD for RSA (as well as ECDSA). How come? > > RSASSA-PSS MUST be implemented if Digital Signature authentication > method is implemented, but it can be implemented with multiple hash > algorithms. On the other hand in hash algorithms part we have just one > MUST and that is for SHA2-256. > > The reason why RSASSA-PSS with SHA-256 is listed only as SHOULD, is > mostly caused by the fact that Digital Signature authentication method > is still onl SHOULD and we do not have implementations for it, so we > do not have implementor comments for it yet. > > So Digital Signature in general is SHOULD. > > SHA2-256 as hash algorithm is MUST when implementing Digital Signature > authentication method. > > RSASSA-PSS is MUST when implementing Digital Signature. All these thing are not clear from the current text of the draft. I was also confused as well as Yaron. As I've said in previous message, I'm not a fan of idea to tie support for RSASSA-PSS with support for Digital Signature auth. Nevertheless if this link is imposed by the draft, it must be spelled out more clearly. Regards, Valery. From nobody Thu Apr 14 07:54:02 2016 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 3106812D8A5 for ; Thu, 14 Apr 2016 07:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 pdaeuX3ZvQ1r for ; Thu, 14 Apr 2016 07:53:58 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0104.outbound.protection.outlook.com [23.103.200.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A396612D70D for ; Thu, 14 Apr 2016 07:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gc0SkB4yJezHPkmv+G1qvvmT0LzFP0N8f5csYGXfu1Y=; b=yo9hkzGPEWrGz/FWunUKn32GKikGim9aAdyBfwX4vnt0H0qU1MMbW+75iWJRSs61QX3mGo06fSOjLHkDuNiF62HIHddktIaJH/uOgbKRHfzCoHv9gRVIQD0BeH87QTdB2onqatNEZLjqAzI11RE2NBOT6B38kGpP+qvqsGMeluo= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BLUPR09MB0881.namprd09.prod.outlook.com (10.162.89.15) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 14:53:56 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0453.029; Thu, 14 Apr 2016 14:53:56 +0000 From: "Dang, Quynh (Fed)" To: Paul Hoffman , IPsecME WG Thread-Topic: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis Thread-Index: AQHRkcovbsJyFXKE70eisU5dbT9l/p+Jka20 Date: Thu, 14 Apr 2016 14:53:55 +0000 Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> In-Reply-To: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 984d8a3e-9cb7-4d84-9101-08d364749a9b x-microsoft-exchange-diagnostics: 1; BLUPR09MB0881; 5:MUBJnmJHRQpDPl/6cIVRJEDJ3f7B2RSbUeBwD9BKTwueR7wM8EQxz2r5rTaeyvybBhkQZHVOL5esm4LYjH1Y0oIEBjMs99txa/ySsZH9y5iXvH6hg7Nd/Rvyu1a+tYySoA1Pf7tKXc9mej/NNrH2DQ==; 24:LMDDTmhVZzC/CWv/ek5jVSR9T4JKZxLdIGgRR4U9hQBTwyqPmaIFngd/7c7Z11VMh+gubA2oXBKToTkG1Rnq3oNmAYUzWnSv4rhFjoVBysI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0881; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR09MB0881; BCL:0; PCL:0; RULEID:; SRVR:BLUPR09MB0881; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(2906002)(5001770100001)(189998001)(50986999)(76176999)(54356999)(33656002)(230783001)(5003600100002)(3280700002)(1096002)(11100500001)(66066001)(3660700001)(1220700001)(5002640100001)(9686002)(6116002)(3846002)(102836003)(586003)(4001430100002)(19580405001)(19580395003)(4326007)(81166005)(99286002)(5004730100002)(2950100001)(2900100001)(10400500002)(122556002)(106116001)(77096005)(74316001)(86362001)(15975445007)(107886002)(5008740100001)(87936001)(76576001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB0881; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 14:53:55.7710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR09MB0881 Archived-At: Cc: "Frankel, Sheila E. \(Fed\)" Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:54:01 -0000 Hi Paul and all, 1) All of the DH-groups smaller than 2K in the table 3.4 must not be used b= ecause they are not strong enough. Right now, groups 5, 2 and 22 are being = listed as "should not" which means that "must not use unless a user has a = strong reason". The problem is that a user can always have a strong reason = because there is no definition of "a strong reason". The group 2 (1K DH group) is currently mandatory-to-implement; therefore, i= mplementers must implement it for interop. reason. But, the problem is that= the draft is also for users. So, there are two problems. The first one is = that the working group should update the standard to mandate a stronger DH = group (or a ECC group) (which is hard to get done soon). And, the second (w= hich is urgent) is that the draft should explicitly say that "users must no= t use those weak groups". The fact that many existing devices are still using the group 2 ( 1K DH gro= up) does not make the group secure. The document should provide sound techn= ical guidelines for users. If a user still chooses to use a weak group, tha= t would be his/her own fault. 2) Similarly for RSA sizes smaller than 2K and digital signatures using SHA= 1, "should not" should become "must not". Regards, Quynh. ________________________________________ From: IPsec on behalf of Paul Hoffman Sent: Friday, April 8, 2016 3:09:07 PM To: IPsecME WG Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis Greetings. As discussed on the list for the past few weeks, and in the face-to-face meeting in Buenos Aires (which, for many of us, seems to translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready for WG Last Call. We would like everyone to review it carefully, given that there have been some significant changes over the past few months. This WG Last Call will end on April 22. It would be grand if everyone on this list would read the draft as if it was brand new and respond on the list with any problems, any questions, or even just "it is ready to progress as-is". Extra points are given for reviewers who don't wait until the last minute. --Paul Hoffman and Dave Waltermire _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 14 08:22:35 2016 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 BF29412E5DB for ; Thu, 14 Apr 2016 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] 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 sh_oenVc1OZ8 for ; Thu, 14 Apr 2016 08:22:23 -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 1A00A12E579 for ; Thu, 14 Apr 2016 08:22:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qm4Cf5T1bz1cV; Thu, 14 Apr 2016 17:22:06 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 6bViVY03AGMt; Thu, 14 Apr 2016 17:22:05 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 14 Apr 2016 17:22:05 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id 964004278C; Thu, 14 Apr 2016 11:22:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 94E2D412D1; Thu, 14 Apr 2016 11:22:05 -0400 (EDT) Date: Thu, 14 Apr 2016 11:22:05 -0400 (EDT) From: paul@nohats.ca To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Paul Hoffman , "Frankel, Sheila E. \(Fed\)" Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:22:35 -0000 On Thu, 14 Apr 2016, Dang, Quynh (Fed) wrote: > 1) All of the DH-groups smaller than 2K in the table 3.4 must not be used because they are not strong enough. Right now, groups 5, 2 and 22 are being listed as "should not" which means that "must not use unless a user has a strong reason". The problem is that a user can always have a strong reason because there is no definition of "a strong reason". > > The group 2 (1K DH group) is currently mandatory-to-implement; therefore, implementers must implement it for interop. reason. But, the problem is that the draft is also for users. So, there are two problems. The first one is that the working group should update the standard to mandate a stronger DH group (or a ECC group) (which is hard to get done soon). And, the second (which is urgent) is that the draft should explicitly say that "users must not use those weak groups". The draft is not for users. It is also not for default values. This is explained at https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3 The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments and recommendations from this document are also expected to be useful for such users. Removing group 2 an 5 is expected to cause interoperability issues because not everyone switch to group 14 for IKEv2 and not everyone properly implements INVALID_KE and restarting with a different DH group. I would also not call group 5 (1536) "weak". > The fact that many existing devices are still using the group 2 ( 1K DH group) does not make the group secure. The document should provide sound technical guidelines for users. If a user still chooses to use a weak group, that would be his/her own fault. The user can only make that fault if the implementations still support those DH groups. > 2) Similarly for RSA sizes smaller than 2K and digital signatures using SHA1, "should not" should become "must not". And what percentage of certificate based VPN connections would break? I suspect more than 75% Many deployments actually kept away from 2048 bit RSA because it causes IKE fragmentation (RFC-7383) was only added to IKEv2 in November 2014. Give implementors 1 year, then add a year for just missing fresh 1024 bit certificates, and you are at the start of 2017. So I don't think we can say MUST NOT for RSA 1024 bit keys. Paul From nobody Thu Apr 14 10:22:00 2016 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 1986512E43F for ; Thu, 14 Apr 2016 10:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 CI-wN0CX2pcv for ; Thu, 14 Apr 2016 10:21:56 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0117.outbound.protection.outlook.com [23.103.201.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197EE12DE39 for ; Thu, 14 Apr 2016 10:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RF72ApYSpCYDrDWFp1cXjnmtHVa2lF8yax7KxCAQeJY=; b=dOeeFTeLhIrlpFZCVTuAm+ff9UkMu8gatSrDMtPcNPnxZPzJlIKcN4DUrRAvrpf0/pFdS9zfGXcNMaaW47M0/eRyROCj2fnYwGuiyToWJ67R17ME2VpAzbI5tiB3r4vSuCvFMpEvL8v5gqvcGJQYbWm9f07jqIDh+TZFkh76dKc= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 17:21:53 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0453.029; Thu, 14 Apr 2016 17:21:53 +0000 From: "Dang, Quynh (Fed)" To: "paul@nohats.ca" , IPsecME WG Thread-Topic: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis Thread-Index: AQHRkcovbsJyFXKE70eisU5dbT9l/p+Jka20gAANjICAAB8jWg== Date: Thu, 14 Apr 2016 17:21:53 +0000 Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: dc1ccc4e-c504-4fd5-5419-08d36489461c x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:/hWbKOrKpHG2Bwn1cOmu/j0B0C1NO2t5zZHIij2R/MzvtYnRJIC7BNaqA3mPyTB42lsnCuX2EUdhnsGEmmv8QLDSmokdDxY0ZJSbE79VW0uGVsWhgPsl0/nwyEklZYXxU5yizUopbq31vinooAGEGw==; 24:xJkM12ZDZEjrKAxWTCr/GsFYdFn+fo8OnfFbJz7gOnsMf9hqvD2Ua+YGuuBs3JpRYKDrPnXA8iGNGswlqmLQWKi7/eiQ3QGtK4CvLHKtJHw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(74316001)(50986999)(54356999)(76176999)(86362001)(19580405001)(19580395003)(33656002)(76576001)(87936001)(106116001)(99286002)(122556002)(66066001)(586003)(6116002)(3846002)(9686002)(5008740100001)(1220700001)(1096002)(92566002)(5001770100001)(189998001)(81166005)(107886002)(5004730100002)(2906002)(230783001)(10400500002)(2501003)(102836003)(3280700002)(3660700001)(5003600100002)(5002640100001)(2950100001)(2900100001)(77096005)(15975445007)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 17:21:53.2993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: [IPsec] Fw: WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 17:21:59 -0000 Paul, I just copied from your quote in section 1.3 here: "This may differ from a = user point of view that may deploy and configure IKEv2 with only the safest= cipher suite. On the other hand, comments and recommendations from this d= ocument are also expected to be useful for such users." We should be clear about recommendation for interoperability reason and rec= ommendation for security reason: they are different. Quynh.=20 ________________________________________ From: IPsec on behalf of paul@nohats.ca Sent: Thursday, April 14, 2016 11:22 AM To: Dang, Quynh (Fed) Cc: IPsecME WG; Paul Hoffman; Frankel, Sheila E. (Fed) Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis On Thu, 14 Apr 2016, Dang, Quynh (Fed) wrote: > 1) All of the DH-groups smaller than 2K in the table 3.4 must not be used= because they are not strong enough. Right now, groups 5, 2 and 22 are bein= g listed as "should not" which means that "must not use unless a user has = a strong reason". The problem is that a user can always have a strong reaso= n because there is no definition of "a strong reason". > > The group 2 (1K DH group) is currently mandatory-to-implement; therefore,= implementers must implement it for interop. reason. But, the problem is th= at the draft is also for users. So, there are two problems. The first one i= s that the working group should update the standard to mandate a stronger D= H group (or a ECC group) (which is hard to get done soon). And, the second = (which is urgent) is that the draft should explicitly say that "users must = not use those weak groups". The draft is not for users. It is also not for default values. This is explained at https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3 The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. Interoperability requires a smooth move to more secure cipher suites. This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite. On the other hand, comments and recommendations from this document are also expected to be useful for such users. Removing group 2 an 5 is expected to cause interoperability issues because not everyone switch to group 14 for IKEv2 and not everyone properly implements INVALID_KE and restarting with a different DH group. I would also not call group 5 (1536) "weak". > The fact that many existing devices are still using the group 2 ( 1K DH g= roup) does not make the group secure. The document should provide sound tec= hnical guidelines for users. If a user still chooses to use a weak group, t= hat would be his/her own fault. The user can only make that fault if the implementations still support those DH groups. > 2) Similarly for RSA sizes smaller than 2K and digital signatures using S= HA1, "should not" should become "must not". And what percentage of certificate based VPN connections would break? I suspect more than 75% Many deployments actually kept away from 2048 bit RSA because it causes IKE fragmentation (RFC-7383) was only added to IKEv2 in November 2014. Give implementors 1 year, then add a year for just missing fresh 1024 bit certificates, and you are at the start of 2017. So I don't think we can say MUST NOT for RSA 1024 bit keys. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec= From nobody Fri Apr 15 12:23:18 2016 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 A987E12DD31; Fri, 15 Apr 2016 12:23:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415192315.17538.48595.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 12:23:15 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 19:23:15 -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 of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-06.txt Pages : 29 Date : 2016-04-15 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-06 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 Fri Apr 15 12:24:06 2016 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 2D20012D84A for ; Fri, 15 Apr 2016 12:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 ZE2XqBKOGvXA for ; Fri, 15 Apr 2016 12:24:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC6F12D71F for ; Fri, 15 Apr 2016 12:24:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 971A42002A for ; Fri, 15 Apr 2016 15:28:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 688BE6375A for ; Fri, 15 Apr 2016 15:24:00 -0400 (EDT) From: Michael Richardson To: IPsecme WG X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 19:24:05 -0000 --=-=-= Content-Type: text/plain Assume a responder which currently *implements* IKEv1 and IKEv2. Consider the cases: A) it has a global policy set to reject all IKEv1 connections. B) it has a global policy set to reject all IKEv2 connections. C) a specific policy (for a specific peer, identified by IP address) has a policy to use IKEv1 only. D) a specific policy (for a specific peer, identified by IP address) has a policy to use IKEv2 only. E) a specific policy (for a generic peer, identified by ID) has a policy to use IKEv1 only. F) a specific policy (for a generic peer, identified by ID) has a policy to use IKEv2 only. Perhaps cases B,D and F seem silly today, but assume "IKEv3" came along, except that likely we would retain the packet format, so it would be less weird. (Or perhaps the people who worry about Quantum Cryptography are suddenly proven right, and IKEv1's perverted main-mode with PSK *is* stronger) I think that there is a significant tension between providing some useful diagnostics to the other end vs telling too much about our policy. I also consider that given code is already present, that it may be better to proceed to parent SA established, and send a private message about wrong version number. A1) Upon receipt of an IKEv1 message, such a peer should reply with an IKEv1 format notify INVALID-MAJOR-VERSION. Seems perverse to use IKEv1 to say, "I do not speak IKEv1" {"En puhuto sumalainen"} A2) Upon receipt of an IKEv1 message, such a peer should reply with an IKEv2 format notify INVALID_MAJOR_VERSION (n=m=2). This is what a pure IKEv2 implementation would respond with, but which an IKEv1 initiator would not understand. B1) Upon receipt of an IKEv2 message, such a peer should reply with an IKEv2 format notify INVALID-MAJOR-VERSION (n=m=1). B2) Upon receipt of an IKEv2 message, such a peer should reply with an IKEv1 format notify INVALID-MAJOR-VERSION. This is what a pure IKEv1 implementation would respond with. C) since we can identify the policy by IP address, we can respond, but do we respond with A1 or A2? For other IP addresses we may well support the requested version. D) ditto for C. E) upon receipt of IKEv2 message, we have to proceed until we can process the ID in the I1. Having done, we notice the PAD says not to do IKEv2, so reply in IKEv2, saying... INVALID_MAJOR_VERSION? Or NO_PROPOSOL_CHOSEN? F1) upon receipt of an IKEv1 MAIN MODE message, we have to proceed until we can see the ID, which means getting the I3 message. And then INVALID-MAJOR-VERSION? We may well be able to authenticate the peer! F2) upon receipt of an IKEv1 AGGRESSIVE MODE message, we process until we can see the ID, and then INVALID-MAJOR-VERSION? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVxE/yICLcPvd0N1lAQI1NQgAhDvZgqB9EoBNw0/9Shjj9bBKqqL5Mhfa oLswAq2hQC2PAi4DjrOp7CXsREvmJkxpXn8g+HPQgjMBul5yDPWv282PiGYVTHnL Tx/LeYi7PU4/GXqt+vmEOsJauOC0OrHAkyQdancIVTiTV5Vda9R4hOXcwDWNTrcu km68rVm7ikwKuX5v9Hcwe2rtmMqUysbO59FjEFfkDV0gxQl9HQ9NcfKxjTZpJdhC zmkaHb74xrccMXKD6MmV1229NaVXotOFiZjIJEKj3+4t34p1ICUrNhy4O9mrVph6 A2gsXHo++kGi7fXbEww77bZwFZIdALB6/0V+vU5De2HReN28bWf8Ww== =rU04 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 15 12:36:52 2016 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 68B2612D87E for ; Fri, 15 Apr 2016 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=Paul_Koning@Dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.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 CtoEArmaQvnj for ; Fri, 15 Apr 2016 12:36:49 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (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 1961012D764 for ; Fri, 15 Apr 2016 12:36:48 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=xqC/VJyFkKtlrN+9g53nkeBSuG0WF7a1vYlQuhDkP6sxi2J/RWt5Go6S NavHivWE0d1X7HPUlR2crEpe3E5+hwJIEadgcvJwkNo9AZrA892RdSjOn 4d4cB/hhUKjhZ+Wd935CAfCFiWKOJbrkfELDb5YPL3ozlwNkmbLnsKb0W Y=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1460749009; x=1492285009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ngW4+AJlW8XtVaZ+1MTXdfD1HMTK2Yud/0x/Sd+Xo1I=; b=hGSnhp1LtoUrw561LK1SqEPIKDRMgPKLDfdyKb/7Sp3NceSJMWKPhy6I 16y/D6P/WiHHxddikIfqjcbff8xtXXpEj8SijzA0XWVRSXV3OKlPs4zu+ PcgIt2Wxc4E2UrmZ6FoQdL4oCB1SW3kn+d6k3RP7cv+2Z2njNZk3+Craw 0=; X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.24,488,1454997600"; d="scan'208";a="811015571" From: To: Thread-Topic: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy Thread-Index: AQHRl0xooPF/SoGyPkqlThzH8ojYWZ+LwWWA Date: Fri, 15 Apr 2016 19:36:45 +0000 Message-ID: <3237192E-266D-407B-ABD6-8956265A18C1@dell.com> References: <17505.1460748240@obiwan.sandelman.ca> In-Reply-To: <17505.1460748240@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 19:36:50 -0000 > On Apr 15, 2016, at 3:24 PM, Michael Richardson w= rote: >=20 > ... > I think that there is a significant tension between providing some useful > diagnostics to the other end vs telling too much about our policy. One approach would be: say nothing meaningful in the reply, but log informa= tion locally. Then, if the other end is legitimate, the local end admin ca= n examine the log and find what went wrong. On the other hand, if the remo= te end is not legitimate, it learns nothing. paul From nobody Fri Apr 15 13:52:04 2016 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 51D2E12DD9C for ; Fri, 15 Apr 2016 13:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] 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 SFmngLkCRQHL for ; Fri, 15 Apr 2016 13:52:02 -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 6947312DE47 for ; Fri, 15 Apr 2016 13:52:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qmqTq1vFNz1c3 for ; Fri, 15 Apr 2016 22:51:59 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 EcU6lFZsQLTp for ; Fri, 15 Apr 2016 22:51:58 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP for ; Fri, 15 Apr 2016 22:51:58 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id 5A0C241277; Fri, 15 Apr 2016 16:51:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 53BFA40B74 for ; Fri, 15 Apr 2016 16:51:58 -0400 (EDT) Date: Fri, 15 Apr 2016 16:51:58 -0400 (EDT) From: paul@nohats.ca To: ipsec@ietf.org In-Reply-To: <17505.1460748240@obiwan.sandelman.ca> Message-ID: References: <17505.1460748240@obiwan.sandelman.ca> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 20:52:03 -0000 On Fri, 15 Apr 2016, Michael Richardson wrote: > A1) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv1 format notify INVALID-MAJOR-VERSION. Seems perverse to use IKEv1 > to say, "I do not speak IKEv1" > {"En puhuto sumalainen"} > A2) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv2 format notify INVALID_MAJOR_VERSION (n=m=2). This is what a pure IKEv2 > implementation would respond with, but which an IKEv1 initiator would > not understand. I dont see the problem? There is no incompatibility with the IKE haeder between v1 and v2? And INVALID_MAJOR_VERSION has the same number (5) in IKEv1 and IKEv2. Anyy IKE daemon (v1, v2 or both) receiving an IKEv2 reply with INVALID_MAJOR_VERSION should be able to read/log the error and understand it means "invalid ike version, abort". The same is true if the reply came as an IKEv1 message. Perhaps you need to ignore msgid, but that's about it. The IKEv2 RFC states: If an endpoint receives a message with a higher major version number, it MUST drop the message and SHOULD send an unauthenticated notification message containing the highest version number it supports. So yes, your IKEv2 packet might receive a reply from a MAJOR ikev1 packet. But your initiator SPI should allow you to look this packet up regardless of major ike version. > E) upon receipt of IKEv2 message, we have to proceed until we can > process the ID in the I1. Having done, we notice the PAD says not to do > IKEv2, so reply in IKEv2, saying... INVALID_MAJOR_VERSION? Or NO_PROPOSOL_CHOSEN? If it receives a message with a major version that it supports, it MUST respond with that version number. So NO_PROPOSOL_CHOSEN. > F1) upon receipt of an IKEv1 MAIN MODE message, we have to proceed until we > can see the ID, which means getting the I3 message. > And then INVALID-MAJOR-VERSION? We may well be able to authenticate the > peer! Same. Paul From nobody Fri Apr 15 23:03:10 2016 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 F405B12DFD4 for ; Fri, 15 Apr 2016 23:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 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_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 EhxvQS27LUjQ for ; Fri, 15 Apr 2016 23:03:08 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 0658612DFD3 for ; Fri, 15 Apr 2016 23:03:08 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id o124so19248480lfb.2 for ; Fri, 15 Apr 2016 23:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=9FJcrFyx04PyMpzRIMTCY4r4HMa2NwZnQyOWlrVSpqs=; b=Qr7NEQ4ix0aQMl3FsPhN/YkIwZiqEmde24DrB3smNH+7cmrKcoadAj1skMIC9RHbD1 JunkFlfguF5dDJQ4T2ZM5RU/BN9/2e+vzAckXLHKuxit3wGMu996N+HWSCh8DqiJfLKh I8H9o4f7f5ZHVyTcmxpXuYi3XEbebkTYHWF9APdga71+y1Jvi+iXpVMLbdIPh8IA8y3T 6ImVMBCx5TGHqfDH1kJU1SWQSQtdqhQ9rS0EtvHZRz+lV5HjKkazXfJSiLoDkswVntSD 8Omc7l3eKhGhjEpQkvvYJ+pkadWLMh3JragAFUR2OMz3QksmhFfEsoo8HjCyfO8iqOL9 2xXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=9FJcrFyx04PyMpzRIMTCY4r4HMa2NwZnQyOWlrVSpqs=; b=F9CU35JPty3zga+nFDFoYg6BOE5/PtRqzVAmN0UWjUyCkPqCo1Gu4/mrBDZ0MyETMK ChOPnYgwK7JtbXG3XES6z5fvjxwZyQHLbiV3l/eVvOyj3DpxS8KpLuQEHjTm+rI8YlkG WA07p5bFjteJRL32jnGRSR67LBqTuT+kbGA2BJATCgcwi7J388X9EfTSWPpRZy2s6a5w dpOFei98GKCYv0dWvSHC5Q4R9HYWgCvR8OHFh64MJu3l5ct1qNbtLsjxCeICD5Pe8Dg8 6WXA5HMJzVBl5GyC+MhfPWHI1116GQHB36bnwasDgeU7J0ZhUp7q4TzUqLQrQtFpbcFT dwiw== X-Gm-Message-State: AOPr4FWOqVFcxoksXIHfmpaWkeP975atRR7339YMlWASUY8XIQEaVISwNM5sYAo7l6K7Lw== X-Received: by 10.112.254.164 with SMTP id aj4mr10557134lbd.104.1460786586264; Fri, 15 Apr 2016 23:03:06 -0700 (PDT) Received: from chichi (ppp83-237-47-234.pppoe.mtu-net.ru. [83.237.47.234]) by smtp.gmail.com with ESMTPSA id um4sm8096221lbb.1.2016.04.15.23.03.04 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 23:03:05 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "IPsecme WG" References: <20160415192315.17538.48595.idtracker@ietfa.amsl.com> In-Reply-To: <20160415192315.17538.48595.idtracker@ietfa.amsl.com> Date: Sat, 16 Apr 2016 09:03:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 06:03:10 -0000 Hi, the new version of the draft addresses comments received during WGLC. Those who commented (Paul, Graham, Michael and others), please verify that your concerns are resolved. Regards, Yoav and Valery. -----Original Message----- From: internet-drafts@ietf.org Date: 15 апреля 2016 г. 22:23 To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-06.txt 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 of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-06.txt Pages : 29 Date : 2016-04-15 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-06 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/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 18 03:36:56 2016 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 AB55312DE60 for ; Mon, 18 Apr 2016 03:36:54 -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 9jTad6X5qweB for ; Mon, 18 Apr 2016 03:36:51 -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 6EA0912DE57 for ; Mon, 18 Apr 2016 03:36:49 -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 u3IAahlh003955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 13:36:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3IAahBq002390; Mon, 18 Apr 2016 13:36:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22292.47291.268074.134003@fireball.acr.fi> Date: Mon, 18 Apr 2016 13:36:43 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <17505.1460748240@obiwan.sandelman.ca> References: <17505.1460748240@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 15 min Archived-At: Cc: IPsecme WG Subject: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 10:36:54 -0000 Michael Richardson writes: > A1) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv1 format notify INVALID-MAJOR-VERSION. Seems perverse to use IKEv1 > to say, "I do not speak IKEv1" > {"En puhuto sumalainen"} ^^^^^^^^^^^^^^^^^^^^ En puhu suomea. > A2) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv2 format notify INVALID_MAJOR_VERSION (n=m=2). This is what a pure IKEv2 > implementation would respond with, but which an IKEv1 initiator would > not understand. > > B1) Upon receipt of an IKEv2 message, such a peer should reply with an > IKEv2 format notify INVALID-MAJOR-VERSION (n=m=1). > > B2) Upon receipt of an IKEv2 message, such a peer should reply with an > IKEv1 format notify INVALID-MAJOR-VERSION. This is what a pure IKEv1 > implementation would respond with. In all of these cases I think it is best to sent a INVALID-MAJOR-VERSION notify back with same level than the incoming packet was. If the implementation really supports both versions this is what will most likely happen, as when you receive the packet you will parse it as IKEv1 or IKEv2 message depending on the version number in the packet, and the code sending error message back is IKEv1 or IKEv2 specific. I.e., if the packet is for IKEv1 then you process it using IKEv1 library and send errors based on that. If the packet is for IKEv2 you use your IKEv2 library etc... On the other hand as other end will ignore the message as it is unauthenticated, this will simply act as debugging help. Other option is simply silently drop the message and log the reason to the log. > C) since we can identify the policy by IP address, we can respond, but > do we respond with A1 or A2? For other IP addresses we may well support > the requested version. > > D) ditto for C. Same here. > E) upon receipt of IKEv2 message, we have to proceed until we can > process the ID in the I1. Having done, we notice the PAD says not to do > IKEv2, so reply in IKEv2, saying... INVALID_MAJOR_VERSION? Or NO_PROPOSOL_CHOSEN? In that case you need to reply with AUTHENTICATION_FAILED not NO_PROPOSOL_CHOSEN. NO_PROPOSOL_CHOSEN in to the IKE_AUTH would mean that the Child SA exchange failed, and the IKEv2 SA would still be created. Returning AUTHENTICATION_FAILED means that the whole IKEv2 exchange failed, and IKEv2 SA is removed also. I.e., the authentication failed because the ID did not allow using IKEv2, thus no proper credentials was found for the IKEv2 SA to authenticate it. Using INVALID_MAJOR_VERSION is wrong, as you do know how to process the packet, your policy simply do not allow you to accept the incoming connection using that combination of protocol version, ID and algorithms. > F1) upon receipt of an IKEv1 MAIN MODE message, we have to proceed until we > can see the ID, which means getting the I3 message. > And then INVALID-MAJOR-VERSION? We may well be able to authenticate the > peer! > > F2) upon receipt of an IKEv1 AGGRESSIVE MODE message, we process until we > can see the ID, and then INVALID-MAJOR-VERSION? In IKEv1 returning NO_PROPOSOL_CHOSEN is most likely proper answer. On the other hand, the other end will most likely ignore it and simply time out after some time. -- kivinen@iki.fi From nobody Mon Apr 18 07:02:04 2016 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 DFC8612DBFC for ; Mon, 18 Apr 2016 07:02:03 -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 EbLvWIvzaRbh for ; Mon, 18 Apr 2016 07:02:02 -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 BCDA212DBA2 for ; Mon, 18 Apr 2016 07:02:01 -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 u3IE1vSF006415 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 17:01:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3IE1u1h017890; Mon, 18 Apr 2016 17:01:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22292.59604.428309.798578@fireball.acr.fi> Date: Mon, 18 Apr 2016 17:01:56 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <1A58AF23AD5745489DD523298658A0D5@buildpc> References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <1A58AF23AD5745489DD523298658A0D5@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:02:04 -0000 Valery Smyslov writes: > > Yes, I think we discussed it, but I think we should really see at > > least one implementation before we pick it as SHOULD+ level... > > > > Has anybody implemented this yet? > > Yes. Good to know. Do you know if there has been any interoperability tests with it? > > Also as we do say that RSASSA-PSS MUST be implemented, that means > > that every implementation which sends out the > > SIGNATURE_HASH_ALGORITHMS and conforms to this document, must > > support RSASSA-PSS, thus implementations can always use it when > > using RSA keys. > > > > Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427 > > implementations which are made before this 4307bis document came out, > > and which do not support RSASSA-PSS required here. > > I don't think it is a good idea in general to link support for > RSASSA-PSS with support for RFC7427. However, I don't know a better > solution for now. To provide interoperability we need to pick some signature methods as mandatory to implement for the RFC7427 in the future, and my guess is that it will be RSASSA-PSS. > I think it is a deficiency of RFC7427 that it only allows to > indicate the list of supported hash functions and doesn't allow to > indicate supported signature formats. The RFC7427 explains why this is not needed in section 5, and we had discussion about this when the RFC was being written. In general this is not usually a problem, as quite often the initiator has one private key configured, and this is what he will be using for the specific server. I.e., the public key type is known from the configuration. The responder will simply pick the same type of key than the initiator used. I.e., it is not normally question whether the other end implements certain public key method, it is more or less question whther the private / public key will be accepted by the other end in the configuration. -- kivinen@iki.fi From nobody Mon Apr 18 07:05:24 2016 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 A81C012D677 for ; Mon, 18 Apr 2016 07:05:22 -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 0LHwgQMpY7kO for ; Mon, 18 Apr 2016 07:05:22 -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 D46E412D173 for ; Mon, 18 Apr 2016 07:05:21 -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 u3IE5ISb023993 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2016 17:05:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3IE5IvY007361; Mon, 18 Apr 2016 17:05:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22292.59806.970787.291836@fireball.acr.fi> Date: Mon, 18 Apr 2016 17:05:18 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> <22284.48364.866135.876826@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 14:05:22 -0000 Valery Smyslov writes: > > RSASSA-PSS is MUST when implementing Digital Signature. > > All these thing are not clear from the current text of the draft. > I was also confused as well as Yaron. Why the following text is not clear enough: With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented. I think it very clearly says that RSASSA-PSS MUST be implemented when Digital Signature authentication method is implemented. > As I've said in previous message, I'm not a fan of idea to tie > support for RSASSA-PSS with support for Digital Signature auth. > Nevertheless if this link is imposed by the draft, it must be > spelled out more clearly. And you think the paragraph above is not clear enough? If not then provide text that will say it even more clearly. -- kivinen@iki.fi From nobody Tue Apr 19 00:13:56 2016 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 B06B112E2BB for ; Tue, 19 Apr 2016 00:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 EzXD8zpTUC85 for ; Tue, 19 Apr 2016 00:13:53 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 1EF5812D598 for ; Tue, 19 Apr 2016 00:13:53 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id c126so8158766lfb.2 for ; Tue, 19 Apr 2016 00:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=tXs4Jvj6cBj/eQyFrg254B1IuV5cyMZGhbCR3XAjMRk=; b=OGvxVot8OohOjiaVmwmGz/1sRfqN7872Y1+0YEawWzR70ImpvBtCaBtRu8T1BxHXBu hnhf9UVqEItAy0oBLp4cH8KWGt9gcXxltpW8EOwwbVHkgu39oNLGrxDSlCe42uldIS4F 9i7eXWrQndTs1bSmmyMhdouYsOZNHPXmXVJZI9epk/bLc7vj/OYbNA+WW3Z3kDTaF3OV 94Jte0DUHPzlczJhGMj2F4HEl26S4VxWCZeFQ86c2AdSzw6/7N0svQl5uHXQD6wwZ3DZ 96r8Ue2b5prss6PifiUxqybLn0dOhKXzqbTJKRMUpdQCIiRm82+crIIXotpMHTW5+8L6 mSNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=tXs4Jvj6cBj/eQyFrg254B1IuV5cyMZGhbCR3XAjMRk=; b=gCIDtU/r1fIl3LL0PwrTrRFqdmXfcN56d4+c6Ti/TdjFApkV5XmuxjdCGa5S7hfEQy ixCqRcpgH34X4cA8H43BnlFv9t6ksTpr6zCe8s0CCcQLirDnhxNV9SrGycaFPm/cwRxv Kut3k1pNAKEAxwD4yQsI4/jsuyICS1u2mgpJ+0nu1sJ9G40RitcFAyJAFz6q/6Mq6uOX 8uKf2S0uuHatZ/Lmwoy6v0lmcoITxqWbLg35wsLrs+AvLiIk+VvOs/g8omunM0Vdt3FX GFEElQK/FMi4I0iJPUmqxOg0Sx8PUSVE0aM8xbyW8SArN9DgkdoCETns9FXI7M8GSbx/ Bceg== X-Gm-Message-State: AOPr4FUztIoIIVrcfUgXFsZUiQPE2HR0CdM9jUYs+MTeNBg6++AfwsZbjcUN2XnUlBDMcw== X-Received: by 10.25.159.194 with SMTP id i185mr689880lfe.50.1461050031346; Tue, 19 Apr 2016 00:13:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id wy8sm10874807lbb.23.2016.04.19.00.13.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2016 00:13:50 -0700 (PDT) Message-ID: <88702B818DAB4F24995239539731EFC1@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org><570AE1AD.3060001@gmail.com><22283.40143.898294.982675@fireball.acr.fi><570BBD44.4010104@gmail.com><22284.48364.866135.876826@fireball.acr.fi> <22292.59806.970787.291836@fireball.acr.fi> Date: Tue, 19 Apr 2016 10:13:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:13:54 -0000 >> > RSASSA-PSS is MUST when implementing Digital Signature. >> >> All these thing are not clear from the current text of the draft. >> I was also confused as well as Yaron. > > Why the following text is not clear enough: > > With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be > implemented. RSASSA-PSS MUST be implemented. > > I think it very clearly says that RSASSA-PSS MUST be implemented when > Digital Signature authentication method is implemented. > >> As I've said in previous message, I'm not a fan of idea to tie >> support for RSASSA-PSS with support for Digital Signature auth. >> Nevertheless if this link is imposed by the draft, it must be >> spelled out more clearly. > > And you think the paragraph above is not clear enough? If not then > provide text that will say it even more clearly. Section 4.2: Old: Recommendations for when a hash function is involved in a signature: New: When Digital Signature authentication method is implemented, then the following recommendations are applied for hash functions: (stress that this table is concerned only with Digital Signature Authentication method). Old: With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be implemented. RSASSA-PSS MUST be implemented. New: When Digital Signature authentication method is used with RSA signature algorithm, then RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 MAY be supported. (stress that this requirement is applied to RSA only, not to ECDSA etc.) Old: Recommendation of Authentication Method described in [RFC7427] notation: +------------------------------------+------------+---------+ | Description | Status | Comment | +------------------------------------+------------+---------+ | RSASSA-PSS with SHA-256 | SHOULD | | | ecdsa-with-sha256 | SHOULD | | | sha1WithRSAEncryption | SHOULD NOT | | | dsa-with-sha1 | SHOULD NOT | | | ecdsa-with-sha1 | SHOULD NOT | | | RSASSA-PSS with Empty Parameters | SHOULD NOT | | | RSASSA-PSS with Default Parameters | SHOULD NOT | | +------------------------------------+------------+---------+ New: The following table lists recommendations for authentication methods in [RFC7427] notation. These recommendations are applied only if Digital Signature authentication method is implemented. +------------------------------------+------------+---------+ | Description | Status | Comment | +------------------------------------+------------+---------+ | RSASSA-PSS with SHA-256 | MUST | | | ecdsa-with-sha256 | SHOULD | | | sha1WithRSAEncryption | SHOULD NOT | | | dsa-with-sha1 | SHOULD NOT | | | ecdsa-with-sha1 | SHOULD NOT | | | RSASSA-PSS with Empty Parameters | SHOULD NOT | | | RSASSA-PSS with Default Parameters | SHOULD NOT | | +------------------------------------+------------+---------+ (RSASSA-PSS with SHA-256 changed to MUST, so that there is no confusion with the above statements, but at the same time the text added clarifying that these recommendations are only applicable if Digital Signature auth is implemented, which is SHOULD according to the table 6). Regards, Valery. From nobody Tue Apr 19 00:38:27 2016 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 44AB812D75C for ; Tue, 19 Apr 2016 00:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 I40jrJwAueP0 for ; Tue, 19 Apr 2016 00:38:23 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 125DE12D8C0 for ; Tue, 19 Apr 2016 00:38:23 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id e190so8845607lfe.0 for ; Tue, 19 Apr 2016 00:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=dQmdEgCDWVmlRCZ1ma8sTr9iDA50CvxYB3n8icy4Jik=; b=sZDE79Omc9cx82CfSedczoGzz4TzW4g4IiVnUBAb+ZdjFvXhTxPwtMIxHWweW5/DTL yGk5WaoWjaFg+Yp+fpnKtq4iyvdCHaRp7Ep4couHO8IXyrDlZRniWs+zJRXEFDX744H3 fBOrvLx2N4wnF7tXySQFoo28FYLt62AkmoPFBZJZpg+96GymvnMeIg9hjPI9SvNoStLW KdxhLAJ1rgPJad+KIZ+GyGZGmbuaoQvzhrt7V8T/OE5edbkicirKdS/CTXNrPmJo//sS mEYr+Rjkw5oKGSwNEOhHVBHz6h8atXsKG+Rq87l4dAT90+pZzP3k3YFtO5u9+su/D9MH qTeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=dQmdEgCDWVmlRCZ1ma8sTr9iDA50CvxYB3n8icy4Jik=; b=JnbwHKDdgjzH9k76NEMB5zWlJB2GI1ZdXobRktOj1NymBsxypT8369pBf6Ivp9DcVG v3La8gH4Vj9QCNh+Qhi925pdkR3Vo2TlpWJYmV8RyLVlccEy8OoXkArV/BX/pSZsCmRR 5r35oJU8eMI7AT40mmDrA3O4p23Cy/4UY+8VsxpSOSxhtlW6jvZr3eemXNDun9nrV0Ix utUqw9KHbdLPwD7nH4UE3gW0mZJbqoOCmEyzqNEbGf/1Wr7CIdGCN9EuW+1FA+bUSL7B fIeoJxTkBmuQ1k6UKWvEKgiUvYDxceq77DS7CyyCF1Q5vuJ71tlJ0BBu/2O4h4Cplygn VZmg== X-Gm-Message-State: AOPr4FV1KCFgBbrvcldR3bUVaHmGhyqp7lKiJcjrvHONlEAG4eFXUjGtcqqg4Z3IZJvj0Q== X-Received: by 10.112.125.9 with SMTP id mm9mr699677lbb.45.1461051501250; Tue, 19 Apr 2016 00:38:21 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u131sm891509lfd.18.2016.04.19.00.38.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2016 00:38:20 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org><570AE1AD.3060001@gmail.com><22283.40143.898294.982675@fireball.acr.fi><1A58AF23AD5745489DD523298658A0D5@buildpc> <22292.59604.428309.798578@fireball.acr.fi> Date: Tue, 19 Apr 2016 10:38:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 07:38:26 -0000 Hi, >> > Has anybody implemented this yet? >> >> Yes. > > Good to know. Do you know if there has been any interoperability tests > with it? We are interoperable with ourselves (not a surprise) and with strongSwan (no RSASSA-PSS was tested yet though). >> I think it is a deficiency of RFC7427 that it only allows to >> indicate the list of supported hash functions and doesn't allow to >> indicate supported signature formats. > > The RFC7427 explains why this is not needed in section 5, and we had > discussion about this when the RFC was being written. No. it was different discussion. We discussed the situation when peers have several private keys for different algorithms (say RSA and ECDSA) and the way they select the proper one. Now consider the situation when a host has a single key pair for RSA. However, it can either prepare RSASSA-PKCS1-v1.5 signature or RSASSA-PSS signature. The problem is that the host doesn't know if its peer supports RSASSA-PSS or not and RFC7427 doen't allow peers to indicate what formats are supported - only hashes are exchanged. In your draft you artificially link Digital Signature auth with support for RSASSA-PSS, so if you support Digital Signature authentication them you MUST support RSASSA-PSS. I understand that this is probably the only possible solution for now, but in general this linkage is not a good thing. If tomorrow RSASSA-PSS is updated and a new uncompatible RSASSA-PSSv2 is adopted, then how will the peers indicate that this new format is supported? We'll have a lot of interoperability issues... Regards, Valery. From nobody Tue Apr 19 04:21:44 2016 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 D37EC12ED88 for ; Tue, 19 Apr 2016 04:21:42 -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 6FYbGfvhqLZT for ; Tue, 19 Apr 2016 04:21:41 -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 D6EB912DF80 for ; Tue, 19 Apr 2016 04:21:37 -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 u3JBLWRW021829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Apr 2016 14:21:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3JBLWCt011371; Tue, 19 Apr 2016 14:21:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22294.5308.241410.700031@fireball.acr.fi> Date: Tue, 19 Apr 2016 14:21:32 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <88702B818DAB4F24995239539731EFC1@buildpc> References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <570BBD44.4010104@gmail.com> <22284.48364.866135.876826@fireball.acr.fi> <22292.59806.970787.291836@fireball.acr.fi> <88702B818DAB4F24995239539731EFC1@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:21:43 -0000 Valery Smyslov writes: > > And you think the paragraph above is not clear enough? If not then > > provide text that will say it even more clearly. > > Section 4.2: These changes looked good. And I think we should do those (unless someone objects). The WGLC ends by the end of this week, so we will make new version after it finishes (so we can do all WGLC changes at the same time). -- kivinen@iki.fi From nobody Tue Apr 19 04:51:32 2016 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 D200B12DA50 for ; Tue, 19 Apr 2016 04:51:30 -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 v6YDsqyUCTj7 for ; Tue, 19 Apr 2016 04:51:30 -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 B004712DA0F for ; Tue, 19 Apr 2016 04:51:29 -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 u3JBpQbi025742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Apr 2016 14:51:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u3JBpQGZ005951; Tue, 19 Apr 2016 14:51:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22294.7102.668482.719553@fireball.acr.fi> Date: Tue, 19 Apr 2016 14:51:26 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <1A58AF23AD5745489DD523298658A0D5@buildpc> <22292.59604.428309.798578@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 28 min Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 11:51:31 -0000 Valery Smyslov writes: > No. it was different discussion. We discussed the situation > when peers have several private keys for different algorithms > (say RSA and ECDSA) and the way they select the proper one. > > Now consider the situation when a host has a single key pair for RSA. > However, it can either prepare RSASSA-PKCS1-v1.5 signature > or RSASSA-PSS signature. The problem is that the host > doesn't know if its peer supports RSASSA-PSS or not and RFC7427 > doen't allow peers to indicate what formats are supported - only hashes > are exchanged. My original idea was that while changing to the RFC7427 everybody would also move to the RSASSA-PSS and PKCS1-v1.5 would be obsoleted at that point. I.e., if you implement RFC7427 you should also get the RSA updated to the safer version. I mean if you are using RSASSA-PKCS1-v1.5 you can use old authentication method, the RFC7427 support is needed for RSASSA-PSS. And RSASSA-PKCS1-v1.5 has some issues. This is described in the RFC7427 Introduction and Security Considerations sections. > In your draft you artificially link Digital Signature auth with > support for RSASSA-PSS, so if you support Digital Signature > authentication them you MUST support RSASSA-PSS. I understand that > this is probably the only possible solution for now, but in general > this linkage is not a good thing. If tomorrow RSASSA-PSS is updated > and a new uncompatible RSASSA-PSSv2 is adopted, then how will the > peers indicate that this new format is supported? We'll have a lot > of interoperability issues... If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we just mark RSASSA-PSS as MUST NOT, and move to the new version. Anyways the reason why there is no negotiation for the private key type or signature algorithm other than hash is that the IKE_SA_INIT exchange needs to be kept short so adding too my negotiation stuff there is bad idea. This was discussed when the RFC7427 was being written. The original idea was to support ECDSA, and RSASSA-PSS was more or less a side-product from the final design. But it was still side-product that people wanted to keep. We also did not allow negotiating other parameters in the RSASSA-PSS [1]. You did propose making negotiation more complex [2] during the WGLC of RFC7427, but as you can see from my reply [3] it would get really complicated then. Then in the end of that discussion we didn't make any changes to the document. [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08027.html [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html [3] https://www.ietf.org/mail-archive/web/ipsec/current/msg08673.html -- kivinen@iki.fi From nobody Tue Apr 19 06:23:37 2016 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 334C312DD1F for ; Tue, 19 Apr 2016 06:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] 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 aATycu4TwNTJ for ; Tue, 19 Apr 2016 06:23:35 -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 C53C212DCA5 for ; Tue, 19 Apr 2016 06:23:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qq5LX23Wqz363; Tue, 19 Apr 2016 15:23:32 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified 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 ZJ4-cmbv7AFy; Tue, 19 Apr 2016 15:23:29 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 19 Apr 2016 15:23:29 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id 8D7B04274A; Tue, 19 Apr 2016 09:23:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 87C9E3F69C; Tue, 19 Apr 2016 09:23:29 -0400 (EDT) Date: Tue, 19 Apr 2016 09:23:29 -0400 (EDT) From: paul@nohats.ca To: Valery Smyslov In-Reply-To: <88702B818DAB4F24995239539731EFC1@buildpc> Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org><570AE1AD.3060001@gmail.com><22283.40143.898294.982675@fireball.acr.fi><570BBD44.4010104@gmail.com><22284.48364.866135.876826@fireball.acr.fi> <22292.59806.970787.291836@fireball.acr.fi> <88702B818DAB4F24995239539731EFC1@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 13:23:36 -0000 On Tue, 19 Apr 2016, Valery Smyslov wrote: >> And you think the paragraph above is not clear enough? If not then >> provide text that will say it even more clearly. I think all these changes are good. If I don't hear any objections in the next day or so of the co-authors, I'll push them through. Paul > Section 4.2: > > Old: > Recommendations for when a hash function is involved in a signature: > > New: > When Digital Signature authentication method is implemented, then > the following recommendations are applied for hash functions: > > (stress that this table is concerned only with Digital Signature > Authentication method). > > > Old: > With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be > implemented. RSASSA-PSS MUST be implemented. > > New: > When Digital Signature authentication method is used with RSA signature > algorithm, then RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 MAY be > supported. > > (stress that this requirement is applied to RSA only, not to ECDSA etc.) > > > Old: > Recommendation of Authentication Method described in [RFC7427] > notation: > > +------------------------------------+------------+---------+ > | Description | Status | Comment | > +------------------------------------+------------+---------+ > | RSASSA-PSS with SHA-256 | SHOULD | | > | ecdsa-with-sha256 | SHOULD | | > | sha1WithRSAEncryption | SHOULD NOT | | > | dsa-with-sha1 | SHOULD NOT | | > | ecdsa-with-sha1 | SHOULD NOT | | > | RSASSA-PSS with Empty Parameters | SHOULD NOT | | > | RSASSA-PSS with Default Parameters | SHOULD NOT | | > +------------------------------------+------------+---------+ > > New: > The following table lists recommendations for authentication methods in > [RFC7427] notation. These recommendations are applied only if Digital > Signature authentication method is implemented. > > +------------------------------------+------------+---------+ > | Description | Status | Comment | > +------------------------------------+------------+---------+ > | RSASSA-PSS with SHA-256 | MUST | | > | ecdsa-with-sha256 | SHOULD | | > | sha1WithRSAEncryption | SHOULD NOT | | > | dsa-with-sha1 | SHOULD NOT | | > | ecdsa-with-sha1 | SHOULD NOT | | > | RSASSA-PSS with Empty Parameters | SHOULD NOT | | > | RSASSA-PSS with Default Parameters | SHOULD NOT | | > +------------------------------------+------------+---------+ > > (RSASSA-PSS with SHA-256 changed to MUST, so that there is no confusion > with the above statements, but at the same time the text added clarifying > that these recommendations are only applicable if Digital Signature auth is > implemented, > which is SHOULD according to the table 6). > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From nobody Tue Apr 19 07:06:14 2016 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 5806012DC74 for ; Tue, 19 Apr 2016 07:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 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_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 ByoHLTyZ-jBK for ; Tue, 19 Apr 2016 07:06:10 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 01A1112DC18 for ; Tue, 19 Apr 2016 07:06:10 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id e190so20281485lfe.0 for ; Tue, 19 Apr 2016 07:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=I23m/lPlVVyjCO/3CQNmclumJCgp/dyjCuanX78vNEM=; b=C97rfJ0VfPFA68ODZkjZA8nPaGpVEI1U0q/AxNyccznLADfgOApPbVSyzz0Xv2FG9+ +7IHG4Wpnb9akGDryUASjEryho7IPmpq5Ai4E4bvcdU0cz5lFUKrefnp77JaC9nbyvzL tj76ww3HJrqAPyg7PzgctCYHzwm91FeuS7ek8aXAyw51Rv5xgkId0pZwhb/HZAtyvtSD tgVnQtVnS4aDdKUeuiBSRBKKnFvU24OtmbrEHsFczqiYwmOpGrDLsrd3pXSzRsvymYjz 7qxeuj1m4fmNcqyWnx3SLrqpsN3BkcojDYh1uvfmoNqzyMSTLQD1PvmFosjPoZs/hvJX Zrkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=I23m/lPlVVyjCO/3CQNmclumJCgp/dyjCuanX78vNEM=; b=hRl1Z8z/Y4v9RDBWzuLRu9Ctb2sNSXbXsCrhZiyUMl6OwSR2ux8HHyCoSJZNcq6kk4 R6ll9R/m7fkcxyCbij+bg1L7BHKpKbwKy7vd9ci2M9qeRC3VIAThl2YOd39kH3MbPvfX qKB7xpc2YgOBeOmlNogUXWxNqUI0niioE+hGOySHt2dcNnS8HQvusvaZpg7DLOUiEgcQ AxuXsk+80puehMAPHNFxPXy0sO9KGxd78f8G10WJ1Bfb0Dxl6I5L2lBNct9Gdy83U2eM q6MOZJpftOAmyQAhnDrZgDn4V5k8FThAozsEY/FsEoIte9JHxmcerLY9CW8Rl40ueAcy pBnw== X-Gm-Message-State: AOPr4FV08HhHxq6lWq6cVYi6QVEFdss3BwUkzLc94hweYFg7B39oN+2eXT8XdixWmfmtPA== X-Received: by 10.112.143.40 with SMTP id sb8mr1433390lbb.83.1461074768125; Tue, 19 Apr 2016 07:06:08 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 28sm81399lfx.43.2016.04.19.07.06.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Apr 2016 07:06:07 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org><570AE1AD.3060001@gmail.com><22283.40143.898294.982675@fireball.acr.fi><1A58AF23AD5745489DD523298658A0D5@buildpc><22292.59604.428309.798578@fireball.acr.fi> <22294.7102.668482.719553@fireball.acr.fi> Date: Tue, 19 Apr 2016 17:05:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 14:06:12 -0000 > If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we > just mark RSASSA-PSS as MUST NOT, and move to the new version. And this will cause interoperability problems since there is no way for the peers to indicate each other that they support particular signature encoding. "MUST NOT" in RFC is insufficient: in real life you cannot update all implementations overnight. Well, this is just a grunt... From nobody Wed Apr 27 11:38:55 2016 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 5C80012D542 for ; Wed, 27 Apr 2016 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 mUZo9g7qiL_p for ; Wed, 27 Apr 2016 11:38:53 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DE512D53F for ; Wed, 27 Apr 2016 11:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1461782332; x=2325695932; 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=9CpPULL3rzYqJr09+MitnkoH32miZWTl2vDme1gD9X8=; b=pBzdvoFj68qyvMNxFW3ApCA/hxAvQMs517rxelYR7LIXfKZYLYWczi1kdoYZG09V fJWCb61HSChOVDeWxcFZEDiK+54HFbcfkjsAP1fe//llRMhqhOP84GQZF3CHOZJp 6j6Idim5uV50fnk3Pb+ZV4qXkpCVh6YufSgVMKw6QAAX9L9aUZJ7pUe2YCWTuIw2 /5KW0p9hS40yU/UZeVsDvQNs5C9jhz2EJePXWFuFwMZV6mh/X3Ro5JI7oFhbrsHr c2XpFnBqbR4haG9ab2LdfRpH57PFQb1WwX96khUZl1iNFavTOViu/trqrNC3jFZF 8/a8aQ24AbXe1b6ZWDPzkw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 95.00.06427.C3701275; Wed, 27 Apr 2016 11:38:52 -0700 (PDT) X-AuditID: 11973e11-f79646d00000191b-3e-5721073cc3f3 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 92.95.09064.83701275; Wed, 27 Apr 2016 11:38:48 -0700 (PDT) Received: from [17.226.23.55] by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O6B000AY2GNX330@sesame.apple.com> for ipsec@ietf.org; Wed, 27 Apr 2016 11:38:48 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_1FC3C5BF-A6E5-45B2-9C93-1244F24BF136" Message-id: Date: Wed, 27 Apr 2016 11:38:47 -0700 To: IPsecME WG MIME-version: 1.0 (Mac OS X Mail 10.0 \(3183\)) X-Mailer: Apple Mail (2.3183) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoWvDrhhu0LrHyGL/lhdsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmPzkKHvBW4mK49N/sjUwLhTtYuTkkBAwkbjceYYZwhaTuHBv PVsXIxeHkMBeRokNrR+ZYYrePZzFDJGYySTRO/MvO4TzmVHi6/w2oAwHh7CAhMTmPYkgDWwC KhLHv20Aa2YWSJKY9/ozG4gtLOAq0brqLguIzStgI9H47wkLSCuLgKrE9Z0FIKaIgLzEzBuZ EBX6Eu/3TWWBOEFW4sfhzWC3SQhMYJPoenuHbQKjwCwkG2Yh6YGIa0ssW/iaGcLWlNjfvRyL uIZE57eJrAsY2VYxCuUmZuboZuYZ6SUWFOSk6iXn525iBAXxdDvBHYzHV1kdYhTgYFTi4S2Q UAgXYk0sK67MPcQozcGiJM777ZV0uJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGSx/cVcUy Am6Hhb4+Urz20IpVpUG/uawKWnqPSb99f3G3VvikyG9WIW8vqjdYxYskVneGus0y92B7wP7p V86y6LM18iuCJqq73I93/601882HOu0o60PKJ22/xljN8v6x8HOnxuvlk1/qr3AqX2vzVz/K 9exOOSt2ZU91//z/zYHPRGwOPv2sxFKckWioxVxUnAgAMdvVBEMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUi2FDcoGvDrhhucP+rtsX+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMfnJUfaCtxIVx6f/ZGtgXCjaxcjJISFgIvHu4SxmCFtM4sK9 9WxdjFwcQgIzmSR6Z/5lh3A+M0p8nd8GVMXBISwgIbF5TyJIA5uAisTxbxvAmpkFkiTmvf7M BmILC7hKtK66ywJi8wrYSDT+e8IC0soioCpxfWcBiCkiIC8x80YmRIW+xPt9U1kgTpCV+HF4 M9sERt5ZSIbOQlIGEdeWWLbwNTOErSmxv3s5FnENic5vE1kXMLKtYhQoSs1JrDTVSywoyEnV S87P3cQIDrrCiB2M/5dZHWIU4GBU4uEtkFAIF2JNLCuuzD3EKMHBrCTCq8iiGC7Em5JYWZVa lB9fVJqTWnyIcSIj0C8TmaVEk/OBMZFXEm9oYmJgYmxsZmxsbmJOS2Elcd7/G4GOFEhPLEnN Tk0tSC2COYqJg1OqgdGezfHNmfk7z/yd+afh3LPO3S/usEb8D/3+48jFG3nCGxoVGVWehzzc bZ5qp560uSD49Y2HnRx/FrMaLV3Qc9Oo3uG4anHvJdat66aVOOoWPr0b5zvZX/O/Qol+++vf P/7W6L7O8RDbuX1esnjtwf+cJ0MObDzHdXZfg52rmH2zE/utiltW93crsRRnJBpqMRcVJwIA 5BEhu60CAAA= Archived-At: Subject: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:38:54 -0000 --Apple-Mail=_1FC3C5BF-A6E5-45B2-9C93-1244F24BF136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, Based on our discussions at IETF 95 and on the list, I=E2=80=99ve posted = a new revision of the TCP Encapsulation draft = (draft-pauly-ipsecme-tcp-encaps-04): https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-04 = The highlights of the new version are: - Moved all references to TLS to an appendix, so it is not part of the = standard directly (Valery, I think this should address your concerns) - Changed the length field to 16 bits to match 3GPP implementations = (thanks to Tero for this suggestion) - Added a magic value to put once at the beginning of any TCP stream to = indicate that it is being used for IKEv2, to allow differentiation from = other streams if we re-use well-known ports (thanks to Yoav for this = suggestions) I believe this addresses all of the concerns brought up previously, so = I=E2=80=99d like to see if we could get adoption from the working group = to move this draft forward. Please reply with your thoughts on this! Thanks, Tommy Pauly= --Apple-Mail=_1FC3C5BF-A6E5-45B2-9C93-1244F24BF136 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

Based on our discussions at IETF 95 and on the list, I=E2=80=99= ve posted a new revision of the TCP Encapsulation draft (draft-pauly-ipsecme-tcp-encaps-04):
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-04

The = highlights of the new version are:
- Moved all = references to TLS to an appendix, so it is not part of the standard = directly (Valery, I think this should address your concerns)
- Changed the length field to 16 bits to match 3GPP = implementations (thanks to Tero for this suggestion)
- Added a magic value to put once at the beginning of any TCP = stream to indicate that it is being used for IKEv2, to allow = differentiation from other streams if we re-use well-known ports (thanks = to Yoav for this suggestions)

I believe this addresses all of the = concerns brought up previously, so I=E2=80=99d like to see if we could = get adoption from the working group to move this draft forward. Please = reply with your thoughts on this!

Thanks,
Tommy = Pauly
= --Apple-Mail=_1FC3C5BF-A6E5-45B2-9C93-1244F24BF136-- From nobody Wed Apr 27 12:24:32 2016 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 9C60612DBC6 for ; Wed, 27 Apr 2016 12:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 I1lvl358H7UZ for ; Wed, 27 Apr 2016 12:24:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B738C12D575 for ; Wed, 27 Apr 2016 12:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6307; q=dns/txt; s=iport; t=1461785069; x=1462994669; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6Ug8bS5txpQ/hZzwtRHZeyq2auITeAihNR67ILSScMc=; b=WUrG8WyMMiux449GMmKS4Oz+/qb1POa7mYSYsI2hvv3QVoLF+2QyqT6+ wJrlz4lMYwSuT7rGTbk1E8bHv4ykuMGN0nZufCfXIfaOKLiiJmLXRY/0r leb2n6+4r9urukWzR3zZrdtilzxhhAcc6vFR82Ourg8vf2GEGAJsp48Hs A=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAgAMESFX/4sNJK1egzhTfQauCYtdD?= =?us-ascii?q?oF2FwuFbQKBNDgUAQEBAQEBAWUnhEIBAQMBAQEBawsQAgEIDjgCHwYLJQIEAQ0?= =?us-ascii?q?FDguHfAMKCA6+Kw2EYQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0EBIYhhEuCQYITh?= =?us-ascii?q?T8FjgyJUzEBgyeBZ4cSgXaBZ40qhiSBLYdeAR4BQ4NrbIg3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="p7s'?scan'208";a="98561715" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2016 19:24:28 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3RJOSNf023390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 19:24:28 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 14:24:27 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 14:24:27 -0500 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Tero Kivinen Thread-Topic: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis Thread-Index: AQHRkcoupII+WeHtrke+TfYRlOGyvJ+EMbCAgADfFICABH3PUYAGl2YAgADTaveAAJp1AP//0fJ6gA1QBgA= Date: Wed, 27 Apr 2016 19:24:27 +0000 Message-ID: References: <325E33E7-8F06-414A-B0BB-FCBEEA8CC6C6@vpnc.org> <570AE1AD.3060001@gmail.com> <22283.40143.898294.982675@fireball.acr.fi> <1A58AF23AD5745489DD523298658A0D5@buildpc> <22292.59604.428309.798578@fireball.acr.fi> <22294.7102.668482.719553@fireball.acr.fi> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.102] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3544633464_13361894" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 19:24:31 -0000 --B_3544633464_13361894 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Valery Sorry for the late reply. To answer your Q - sort of.. But I=B9ve a few new ideas since on minimising the impact for the small devices. I=B9ll be in touch with these.. cheers On 19/04/2016 15:05, "IPsec on behalf of Valery Smyslov" wrote: >> If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we >> just mark RSASSA-PSS as MUST NOT, and move to the new version. > >And this will cause interoperability problems since there is no way for >the peers=20 >to indicate each other that they support particular signature encoding. >"MUST NOT" in RFC is insufficient: in real life you cannot update >all implementations overnight. Well, this is just a grunt... > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3544633464_13361894 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgfSqG pNyP5Rryn66gLKu/61jtnDu6PO/ZCioAXe3bR9YwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTYwNDI3MTkyNDI0WjANBgkqhkiG9w0BAQEFAASCAQB/g7lW CnVFeWrrpfr0OvSSOURJ0+pdbAYn/yycFvhDhDsPq1jitzOJpItG7TOQNnzm2BsohhX6SBla MnUV4sgYXkscIE3fmK21CpZikBITBL8nktv+8Jj1TLY/rJ3Jg1FXweIqfMdMkNz27ziEc2Iy /Sy2Mu48h3NRoiDr1w9zBXE7ek6De4ZNQEp0hc97S3gXnsPJcf1qjB9kUlKfdFu4s/ibkwgg 6ZB2Qdytj7eidk/AJZ48IDie+WoJmbyxfj6skhvCZ/8QkQQX2d0A9QWpLp17ME3n+JOlWdPN xx94+tpcz8wr93v22Vfl/UetaHTuv5M8FdzhDBXhMinKE+pi --B_3544633464_13361894--