From nobody Wed Jul 2 07:27:26 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4345A1A012D for ; Wed, 2 Jul 2014 07:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 K-fAYpT4_Hqw for ; Wed, 2 Jul 2014 07:27:21 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id E63041A0197 for ; Wed, 2 Jul 2014 07:27:02 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 623E2308664 for ; Wed, 2 Jul 2014 17:26:59 +0300 (EEST) Message-ID: <53B416B3.1030307@cs.hut.fi> Date: Wed, 02 Jul 2014 17:26:59 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> In-Reply-To: <53B1A282.2060907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/KGoAkmj24oVLp1DXpgWwLNoPHWs Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:27:25 -0000 Hi, On 06/30/2014 08:46 PM, Tom Taylor wrote: >> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >> initial >> plaintext for the Encrypted content (type and length of initial >> parameter) may be fairly easily guessed. This opens up the minor >> possibility of a known plaintext attack. [Comment to be reviewed after >> further examination.] [Upon review: I1 packets have fixed type but >> variable length due to varying lengths of DH-GROUP-LISTS. The set of >> such lengths is limited, however, so it is worth considering whether >> known plain-text attacks offer any real threat.] >> >> Discussion: I don't know how/whether to handle this, or whether other >> similar vulnerabilities in other security protocols are addressed. >> Changes to address this would likely complicate things or increase the >> packet sizes. > > [PTT] I have to leave it to people more knowledgeable in security to > judge whether this is a realistic attack. One point of approach is to > find out what sample size is needed for known plain-text attacks for > specific algorithms, compare that with the rate at which an attacker > could collect encrypted messages in specific scenarios, and decide > whether there is a real threat. Mitigation presumably might be through > adjustment of the rate of key rollover. do we actually need the encrypted parameter for something really critical (i.e. some extensions rely on it)? If not, we could just remove it. Usually the encrypted parameter just contains the HOST_ID of the Initiator which does not really offer any real privacy since the HIT is in plaintext and actually can interfere with middleboxes (as already mentioned in the draft). If the encrypted parameter is critical, here's a straw-man proposal that avoids increasing packet size: XOR the contents of the encrypted parameter by iterating through it block-by-block using the encryption key. Then, encrypt it with the same key. If packet size is not a problem, we could include an extra, fixed size key for XORing within the encrypted parameter. Or perhaps just encrypt the plaintext twice with the encryption key. (My solutions are presented in chronologically in the order of my personal preference) From nobody Wed Jul 2 08:32:44 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7761B295A for ; Wed, 2 Jul 2014 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 neeyL-w2LRnS for ; Wed, 2 Jul 2014 08:32:39 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 634A11B2955 for ; Wed, 2 Jul 2014 08:32:39 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 658D23086EF for ; Wed, 2 Jul 2014 18:32:38 +0300 (EEST) Message-ID: <53B42614.1070108@cs.hut.fi> Date: Wed, 02 Jul 2014 18:32:36 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B416B3.1030307@cs.hut.fi> In-Reply-To: <53B416B3.1030307@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/w6qLoZg7_hyCTolQqUx-_ZvDfiU Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 15:32:41 -0000 Hi, On 07/02/2014 05:26 PM, Miika Komu wrote: > Hi, > > On 06/30/2014 08:46 PM, Tom Taylor wrote: >>> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >>> initial >>> plaintext for the Encrypted content (type and length of initial >>> parameter) may be fairly easily guessed. This opens up the minor >>> possibility of a known plaintext attack. [Comment to be reviewed after >>> further examination.] [Upon review: I1 packets have fixed type but >>> variable length due to varying lengths of DH-GROUP-LISTS. The set of >>> such lengths is limited, however, so it is worth considering whether >>> known plain-text attacks offer any real threat.] >>> >>> Discussion: I don't know how/whether to handle this, or whether other >>> similar vulnerabilities in other security protocols are addressed. >>> Changes to address this would likely complicate things or increase the >>> packet sizes. >> >> [PTT] I have to leave it to people more knowledgeable in security to >> judge whether this is a realistic attack. One point of approach is to >> find out what sample size is needed for known plain-text attacks for >> specific algorithms, compare that with the rate at which an attacker >> could collect encrypted messages in specific scenarios, and decide >> whether there is a real threat. Mitigation presumably might be through >> adjustment of the rate of key rollover. > > do we actually need the encrypted parameter for something really > critical (i.e. some extensions rely on it)? If not, we could just remove > it. Usually the encrypted parameter just contains the HOST_ID of the > Initiator which does not really offer any real privacy since the HIT is > in plaintext and actually can interfere with middleboxes (as already > mentioned in the draft). > > If the encrypted parameter is critical, here's a straw-man proposal that > avoids increasing packet size: XOR the contents of the encrypted > parameter by iterating through it block-by-block using the encryption > key. Then, encrypt it with the same key. > > If packet size is not a problem, we could include an extra, fixed size > key for XORing within the encrypted parameter. Or perhaps just encrypt > the plaintext twice with the encryption key. > > (My solutions are presented in chronologically in the order of my > personal preference) on second thought, do we actually have a real problem here? Let us consider: * The encryption key is different for each base exchange, so the roll over is actually occurring every time, so that observing multiple base exchanges does not benefit the attacker * To derive the encryption key, you need a very expensive brute for search, and the award is (usually) just the public key of the initiator * If the parameter contains something else in addition to the public key, the brute force search is still very expensive (exponential) * The default algo (AES) is resistant against linear and differential cryptanalysis So, I am not convinced that the current mechanism should be changed. From nobody Sun Jul 6 03:29:11 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34481A03A7 for ; Sun, 6 Jul 2014 03:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 7a1pT8YDTDcK for ; Sun, 6 Jul 2014 03:29:08 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id C22AC1A03A6 for ; Sun, 6 Jul 2014 03:29:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5621362A70 for ; Sun, 6 Jul 2014 10:29:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQwbDT9BIEu9 for ; Sun, 6 Jul 2014 06:28:53 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 99FAA62A6F for ; Sun, 6 Jul 2014 06:28:53 -0400 (EDT) Message-ID: <53B924E3.70603@htt-consult.com> Date: Sun, 06 Jul 2014 06:28:51 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B416B3.1030307@cs.hut.fi> In-Reply-To: <53B416B3.1030307@cs.hut.fi> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/vCsl9HG5GhESNCeKHAvXEV86xxY Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 10:29:09 -0000 On 07/02/2014 10:26 AM, Miika Komu wrote: > Hi, > > On 06/30/2014 08:46 PM, Tom Taylor wrote: >>> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >>> initial >>> plaintext for the Encrypted content (type and length of initial >>> parameter) may be fairly easily guessed. This opens up the minor >>> possibility of a known plaintext attack. [Comment to be reviewed after >>> further examination.] [Upon review: I1 packets have fixed type but >>> variable length due to varying lengths of DH-GROUP-LISTS. The set of >>> such lengths is limited, however, so it is worth considering whether >>> known plain-text attacks offer any real threat.] >>> >>> Discussion: I don't know how/whether to handle this, or whether other >>> similar vulnerabilities in other security protocols are addressed. >>> Changes to address this would likely complicate things or increase the >>> packet sizes. >> >> [PTT] I have to leave it to people more knowledgeable in security to >> judge whether this is a realistic attack. One point of approach is to >> find out what sample size is needed for known plain-text attacks for >> specific algorithms, compare that with the rate at which an attacker >> could collect encrypted messages in specific scenarios, and decide >> whether there is a real threat. Mitigation presumably might be through >> adjustment of the rate of key rollover. > > do we actually need the encrypted parameter for something really > critical (i.e. some extensions rely on it)? If not, we could just > remove it. Usually the encrypted parameter just contains the HOST_ID > of the Initiator which does not really offer any real privacy since > the HIT is in plaintext and actually can interfere with middleboxes > (as already mentioned in the draft). There are other uses for the encrypted parameter. It should not be removed. > > If the encrypted parameter is critical, here's a straw-man proposal > that avoids increasing packet size: XOR the contents of the encrypted > parameter by iterating through it block-by-block using the encryption > key. Then, encrypt it with the same key. Sounds interesting. > > If packet size is not a problem, we could include an extra, fixed size > key for XORing within the encrypted parameter. Or perhaps just encrypt > the plaintext twice with the encryption key. > > (My solutions are presented in chronologically in the order of my > personal preference) From nobody Sun Jul 6 03:33:35 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8DC1A03A9 for ; Sun, 6 Jul 2014 03:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 j5EHZ2mATmh2 for ; Sun, 6 Jul 2014 03:33:31 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id A0E331A03A6 for ; Sun, 6 Jul 2014 03:33:30 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 36A3762A6F; Sun, 6 Jul 2014 10:33:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3sNZ5fATg1c; Sun, 6 Jul 2014 06:33:19 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 6656A62A7E; Sun, 6 Jul 2014 06:33:19 -0400 (EDT) Message-ID: <53B925EC.5020207@htt-consult.com> Date: Sun, 06 Jul 2014 06:33:16 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Miika Komu , hipsec@ietf.org References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B416B3.1030307@cs.hut.fi> <53B42614.1070108@cs.hut.fi> In-Reply-To: <53B42614.1070108@cs.hut.fi> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/9ErCGNDBESPM2s1ztNy3fEvfH64 Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 10:33:33 -0000 On 07/02/2014 11:32 AM, Miika Komu wrote: > Hi, > > On 07/02/2014 05:26 PM, Miika Komu wrote: >> Hi, >> >> On 06/30/2014 08:46 PM, Tom Taylor wrote: >>>> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >>>> initial >>>> plaintext for the Encrypted content (type and length of initial >>>> parameter) may be fairly easily guessed. This opens up the minor >>>> possibility of a known plaintext attack. [Comment to be reviewed after >>>> further examination.] [Upon review: I1 packets have fixed type but >>>> variable length due to varying lengths of DH-GROUP-LISTS. The set of >>>> such lengths is limited, however, so it is worth considering whether >>>> known plain-text attacks offer any real threat.] >>>> >>>> Discussion: I don't know how/whether to handle this, or whether other >>>> similar vulnerabilities in other security protocols are addressed. >>>> Changes to address this would likely complicate things or increase the >>>> packet sizes. >>> >>> [PTT] I have to leave it to people more knowledgeable in security to >>> judge whether this is a realistic attack. One point of approach is to >>> find out what sample size is needed for known plain-text attacks for >>> specific algorithms, compare that with the rate at which an attacker >>> could collect encrypted messages in specific scenarios, and decide >>> whether there is a real threat. Mitigation presumably might be through >>> adjustment of the rate of key rollover. >> >> do we actually need the encrypted parameter for something really >> critical (i.e. some extensions rely on it)? If not, we could just remove >> it. Usually the encrypted parameter just contains the HOST_ID of the >> Initiator which does not really offer any real privacy since the HIT is >> in plaintext and actually can interfere with middleboxes (as already >> mentioned in the draft). >> >> If the encrypted parameter is critical, here's a straw-man proposal that >> avoids increasing packet size: XOR the contents of the encrypted >> parameter by iterating through it block-by-block using the encryption >> key. Then, encrypt it with the same key. >> >> If packet size is not a problem, we could include an extra, fixed size >> key for XORing within the encrypted parameter. Or perhaps just encrypt >> the plaintext twice with the encryption key. >> >> (My solutions are presented in chronologically in the order of my >> personal preference) > > on second thought, do we actually have a real problem here? Let us > consider: > > * The encryption key is different for each base exchange, so the roll > over is actually occurring every time, so that observing multiple base > exchanges does not benefit the attacker > * To derive the encryption key, you need a very expensive brute for > search, and the award is (usually) just the public key of the initiator > * If the parameter contains something else in addition to the public > key, the brute force search is still very expensive (exponential) > * The default algo (AES) is resistant against linear and differential > cryptanalysis > > So, I am not convinced that the current mechanism should be changed. Also there is an assumption of what the first type value is? Other uses of it may not contain the Host_ID, but something else. And thus the length would be different according to that something else type. I might point out that HIP DEX uses ENCRYPT parameter. I am sure there are others. From nobody Mon Jul 7 21:54:57 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E111B2A30 for ; Mon, 7 Jul 2014 21:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable 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 WLdIWRG0ldoh for ; Mon, 7 Jul 2014 21:54:52 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 04AE61A0ADC for ; Mon, 7 Jul 2014 21:54:51 -0700 (PDT) Received: (qmail 3149 invoked by uid 0); 8 Jul 2014 04:54:50 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 8 Jul 2014 04:54:50 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw3 with id Pmub1o00X2molgS01mueUT; Tue, 08 Jul 2014 04:54:48 -0600 X-Authority-Analysis: v=2.1 cv=fudPOjIf c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=zOy1VSPGCM8A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=8DlgOUzT2xeDgoSnnPAA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=HHE21bycryu05SSOooMvTV2ewvqyHXjMVM/zhZ1cAUY=; b=WelnMfVFIHNCX5nkN0puFjUGcKgxzwyhStu3bi28+ou/hR+O3c9tTbxmr5blcOxsYlHluDJK8f0bwpVrxZocVNR38Znmq6LLpCCaMOzTaZhd/EzPpggTGfY1vM0tYM1k; Received: from [71.231.123.189] (port=58688 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4NQL-0008AQ-E4; Mon, 07 Jul 2014 22:54:37 -0600 Message-ID: <53BB798A.3080101@tomh.org> Date: Mon, 07 Jul 2014 21:54:34 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/6TiPWTvuS5BN_iR07ccID-Z6GT4 Cc: Stephen Farrell Subject: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 04:54:54 -0000 Hi all, Apologies for cross-posting, but Stephen Farrell raised a DISCUSS (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). Stephen asked me to raise this question for discussion on both the HIP and SAAG lists. Stephen's discuss questions the specification of "MUST to implement" for the NULL encryption option of the ESP_TRANSFORM parameter: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 Stephen asks why is this a MUST to implement? The history behind this that I'm aware of is that since HIP does not have an AH, only ESP, the ESP with NULL encryption mode can provide authentication. It was also stated in previous drafts that this mode supports debugging. Null encryption was also specified as a MUST to implement in RFC5202 and dates back to earlier versions of the HIP base draft (to 2003: http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). - Tom From nobody Tue Jul 8 03:04:45 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC11B27E5; Tue, 8 Jul 2014 03:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 5HJtwNEsK5rQ; Tue, 8 Jul 2014 03:04:41 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id ADAF41B27DE; Tue, 8 Jul 2014 03:04:41 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 1BF35308DEE; Tue, 8 Jul 2014 13:04:38 +0300 (EEST) Message-ID: <53BBC235.6030801@cs.hut.fi> Date: Tue, 08 Jul 2014 13:04:37 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> In-Reply-To: <53BB798A.3080101@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/AhUowqq518Pvi1TP6KdNsKUTFhQ Cc: Stephen Farrell Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:04:44 -0000 Hi, On 07/08/2014 07:54 AM, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. It was also > stated in previous drafts that this mode supports debugging. > > Null encryption was also specified as a MUST to implement in RFC5202 and > dates back to earlier versions of the HIP base draft (to 2003: > http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). maybe we should keep it as it is for easier, incremental interoperability testing. The same issue was discussed earlier in this thread: http://www.ietf.org/mail-archive/web/hipsec/current/msg01779.html If you think this is a big problem, I'd suggest replacing NULL with suite id 9. From nobody Tue Jul 8 03:33:23 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8D91B2A68; Tue, 8 Jul 2014 03:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 y-rlfakWGjrG; Tue, 8 Jul 2014 03:33:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EBDEE1B27E7; Tue, 8 Jul 2014 03:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BB1ABE10; Tue, 8 Jul 2014 11:33:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKIuCWuqcdXj; Tue, 8 Jul 2014 11:33:03 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.22.239]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2B65BE0F; Tue, 8 Jul 2014 11:33:02 +0100 (IST) Message-ID: <53BBC8DE.1010006@cs.tcd.ie> Date: Tue, 08 Jul 2014 11:33:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> In-Reply-To: <53BB798A.3080101@tomh.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/1-aP63e_x_ajjodIufF5YdunMkg Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:33:08 -0000 Thanks Tom, On 08/07/14 05:54, Tom Henderson wrote: > Hi all, > > Apologies for cross-posting, but Stephen Farrell raised a DISCUSS > (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: > Using the Encapsulating Security Payload (ESP) Transport Format with > the Host Identity Protocol (HIP). Stephen asked me to raise this > question for discussion on both the HIP and SAAG lists. > > Stephen's discuss questions the specification of "MUST to implement" for > the NULL encryption option of the ESP_TRANSFORM parameter: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 > > Stephen asks why is this a MUST to implement? The history behind this > that I'm aware of is that since HIP does not have an AH, only ESP, the > ESP with NULL encryption mode can provide authentication. It was also > stated in previous drafts that this mode supports debugging. > > Null encryption was also specified as a MUST to implement in RFC5202 and > dates back to earlier versions of the HIP base draft (to 2003: > http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). Right. I guess my discuss has a generic part and a hip specific part. Generic: is it still considered a good plan to have null confidentiality suites such as these? Or for those to be Mandatory-To-Implement (MTI)? That clearly was the generic consensus as we have these in a number of protocols. The new reasons to move from that I think are: 1) we no longer need this for debugging purposes really since libraries and dev tools have moved on and are better now, and we specifically no longer need these for protocols that are no longer new, 2) BCP188 could be considered to argue against having these as they could be misused. (All the old arguments of course do still apply, but I think the above are the ones that are new.) So is that enough to shift the consensus away from having these or having them be MTI? Specific: is there anything specific about hip that would trump the general point above? Note that there could be, regardless of where consensus lies on the generic question. FWIW, my own answers for these are that its probably a better plan today to not have (or make MTI) these null confidentiality ciphersuites, and I don't know that hip would have any specific reason to diverge from that. But I'd really like to see if there is a modified consensus on this or not. (To be clear, if there's not a new consensus then the current one would seem to still apply here and I'll clear my discuss.) Cheers, S. > > - Tom From nobody Tue Jul 8 05:39:27 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5141A03BA; Tue, 8 Jul 2014 05:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 E9JDKkOHMBE8; Tue, 8 Jul 2014 05:39:24 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96D1B2823; Tue, 8 Jul 2014 05:39:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 61E5862A64; Tue, 8 Jul 2014 12:39:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLI50DHFGLrf; Tue, 8 Jul 2014 08:39:12 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 906C6633A3; Tue, 8 Jul 2014 08:39:12 -0400 (EDT) Message-ID: <53BBE66D.2080807@htt-consult.com> Date: Tue, 08 Jul 2014 08:39:09 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Tom Henderson , hipsec@ietf.org, saag@ietf.org References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> In-Reply-To: <53BBC8DE.1010006@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/t_q3l-VdLwcwxa8NlC0qzBOsxww Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:39:26 -0000 On 07/08/2014 06:33 AM, Stephen Farrell wrote: > Thanks Tom, > > On 08/07/14 05:54, Tom Henderson wrote: >> Hi all, >> >> Apologies for cross-posting, but Stephen Farrell raised a DISCUSS >> (seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: >> Using the Encapsulating Security Payload (ESP) Transport Format with >> the Host Identity Protocol (HIP). Stephen asked me to raise this >> question for discussion on both the HIP and SAAG lists. >> >> Stephen's discuss questions the specification of "MUST to implement" for >> the NULL encryption option of the ESP_TRANSFORM parameter: >> >> http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2 >> >> Stephen asks why is this a MUST to implement? The history behind this >> that I'm aware of is that since HIP does not have an AH, only ESP, the >> ESP with NULL encryption mode can provide authentication. It was also >> stated in previous drafts that this mode supports debugging. >> >> Null encryption was also specified as a MUST to implement in RFC5202 and >> dates back to earlier versions of the HIP base draft (to 2003: >> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3). > Right. I guess my discuss has a generic part and a hip specific > part. > > Generic: is it still considered a good plan to have null > confidentiality suites such as these? Or for those to be > Mandatory-To-Implement (MTI)? That clearly was the generic > consensus as we have these in a number of protocols. The > new reasons to move from that I think are: 1) we no longer > need this for debugging purposes really since libraries > and dev tools have moved on and are better now, and we > specifically no longer need these for protocols that are > no longer new, 2) BCP188 could be considered to argue > against having these as they could be misused. (All the > old arguments of course do still apply, but I think the > above are the ones that are new.) So is that enough to > shift the consensus away from having these or having > them be MTI? I should point out that I lobbied hard for CMAC and GMAC added to 5202, as they are better constructs for doing auth only, or so I have been told. I seem to recall during this discussion not to add these options as we have NULL which we need anyway. I argued back that for systems that have AES-CCM or GCM in hardware, there would be a desire for CMAC or GMAC over HMAC. SO now we have 3 suites that provide auth only with selection based on what MACing works best for the system(s) in question. So given this, NULL is to balance the auth only suites or what? I should also point out that the code we have today may not be the only code we have tomorrow. That NULL does provide a valuable test tool. So finally, a best implementation practice may to caution parties to accepting NULL. Perhaps NULL when it is the only offered option. Or NULL when the list only contains NULL, CMAC, or GMAC. > > Specific: is there anything specific about hip that would > trump the general point above? Note that there could be, > regardless of where consensus lies on the generic question. > > FWIW, my own answers for these are that its probably a better > plan today to not have (or make MTI) these null confidentiality > ciphersuites, and I don't know that hip would have any specific > reason to diverge from that. But I'd really like to see if > there is a modified consensus on this or not. (To be clear, > if there's not a new consensus then the current one would > seem to still apply here and I'll clear my discuss.) > > Cheers, > S. > > > >> - Tom > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Jul 8 08:24:40 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4D1A01AC; Tue, 8 Jul 2014 08:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0i90uO_OF8OI; Tue, 8 Jul 2014 08:24:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 946571A007E; Tue, 8 Jul 2014 08:24:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86964BE07; Tue, 8 Jul 2014 16:24:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxgTZOa__BV5; Tue, 8 Jul 2014 16:24:32 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.57.103]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71D51BE02; Tue, 8 Jul 2014 16:24:32 +0100 (IST) Message-ID: <53BC0D30.2070507@cs.tcd.ie> Date: Tue, 08 Jul 2014 16:24:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: James Cloos , Tom Henderson References: <53BB798A.3080101@tomh.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/DhMNQF3TUXfz7gXM_3XcDUFoBLU Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:24:36 -0000 On 08/07/14 16:06, James Cloos wrote: > > If those doing IP over Amateur Radio are a use case, they require NULL. That'd be IPsec, not IP, I guess. How many people actually use IPsec that way? For corner cases like that (and it is utterly a corner case regardless of how laudable a corner case) I'd not have an issue with there being some other RFC to which they could conform, should there be sufficient interest in writing such. I don't myself see that can ever justify an MTI for all implementations though. S. From nobody Wed Jul 9 07:49:08 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70C1A05C3 for ; Wed, 9 Jul 2014 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 qQC7jh1HSM2A for ; Wed, 9 Jul 2014 07:49:05 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2E1A0AE8 for ; Wed, 9 Jul 2014 07:49:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id D0A9862A71; Wed, 9 Jul 2014 14:49:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyb3HshsHaLi; Wed, 9 Jul 2014 10:48:54 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0163063418; Wed, 9 Jul 2014 10:48:53 -0400 (EDT) Message-ID: <53BD5652.300@htt-consult.com> Date: Wed, 09 Jul 2014 10:48:50 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Tom Henderson , hipsec@ietf.org References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> In-Reply-To: <53BBE66D.2080807@htt-consult.com> Content-Type: multipart/alternative; boundary="------------080309080402040008010308" Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/HSXG3IfpO9rP5IuoutxWLp6mI-w Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:49:07 -0000 This is a multi-part message in MIME format. --------------080309080402040008010308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sent to the HIPSEC list from my HIPSEC user: The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed payload, and in many use cases, the Initiator has pre-deteremined the Responder's HI and HIT so it can check the SIG before processing the ESP TRANSFORM parameters. In sensornets where the Initiator cannot pre-determine the Responder's (typically some sensor controller) HI and HIT, then it is a concern. Further eventhough I1 is unsigned, the Initiator 'knows' what suites it wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC back, it MUST NOT complete the exchange. If in the R1 it gets NULL, CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC. If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST NOT complete the exchange. The HIP design team spent a long time working out downgrade attacks. I have to thank Tobias Heer and Miika Komu for a couple day design when I was visiting HIIT in Helsinki. NULL, CMAC, or GMAC should only be configured as allowable suites when they are needed for debug, or the situation requires auth-only. And I should point out there are devices and situations where auth-only is the case, so those suites are needed. IMNSHO. In the worst case scenario, we could cover with text that clearifies the privacy versus auth-only suites with requirements that these suites not be mixed in an exchange and if one is expected, the other not accepted. Of course 'servers' (I say that parenthetically, as HIP is a peer exchange) MIGHT need to support both classes of customers and thus need to respond based on the unprotectable I1 packet. Even there, the Initiator still can bid back if its I1 was altered by a MiTM. --------------080309080402040008010308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Sent to the HIPSEC list from my HIPSEC user:

The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed payload, and in many use cases, the Initiator has pre-deteremined the Responder's HI and HIT so it can check the SIG before processing the ESP TRANSFORM parameters. In sensornets where the Initiator cannot pre-determine the Responder's (typically some sensor controller) HI and HIT, then it is a concern.

Further eventhough I1 is unsigned, the Initiator 'knows' what suites it wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC back, it MUST NOT complete the exchange. If in the R1 it gets NULL, CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC.

If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST NOT complete the exchange.

The HIP design team spent a long time working out downgrade attacks. I have to thank Tobias Heer and Miika Komu for a couple day design when I was visiting HIIT in Helsinki.

NULL, CMAC, or GMAC should only be configured as allowable suites when they are needed for debug, or the situation requires auth-only. And I should point out there are devices and situations where auth-only is the case, so those suites are needed. IMNSHO.

In the worst case scenario, we could cover with text that clearifies the privacy versus auth-only suites with requirements that these suites not be mixed in an exchange and if one is expected, the other not accepted. Of course 'servers' (I say that parenthetically, as HIP is a peer exchange) MIGHT need to support both classes of customers and thus need to respond based on the unprotectable I1 packet. Even there, the Initiator still can bid back if its I1 was altered by a MiTM.


--------------080309080402040008010308-- From nobody Wed Jul 9 13:27:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1B1A0463 for ; Wed, 9 Jul 2014 13:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 FmNB54t5N1mB for ; Wed, 9 Jul 2014 13:27:25 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id B02711A0421 for ; Wed, 9 Jul 2014 13:27:25 -0700 (PDT) Received: (qmail 5719 invoked by uid 0); 9 Jul 2014 20:27:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 9 Jul 2014 20:27:20 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id QST91o00s2molgS01STCoc; Wed, 09 Jul 2014 20:27:19 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=gJ5Z7B3MS4cA:10 a=q7J0aIbBmN8A:10 a=IkcTkHD0fZMA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=JYugLowsNTKLHXIckQ0A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cugmGxYKbC2Z0oQ7WKO/+9EE/r+NzsjFPHWovV+HfE0=; b=Nxt4gpJBM2SuILh4VBzI5sys/vWJYAvTapT70upfgBsGg/tRNY/pMdO+GJGApvCf5r5pCMNKzrKceUfmzm9XxZAAe7MnjG4t3HRgD/8CIBh03nkPwpIzLsWAtFcMIAYg; Received: from [71.231.123.189] (port=47608 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4ySN-0006Oy-0J; Wed, 09 Jul 2014 14:27:11 -0600 Message-ID: <53BDA59C.4000004@tomh.org> Date: Wed, 09 Jul 2014 13:27:08 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Robert Moskowitz References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> <53BD5652.300@htt-consult.com> In-Reply-To: <53BD5652.300@htt-consult.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/zg5O0o5OJPodFwpbjoHtTkF4PHo Cc: hipsec@ietf.org, Stephen Farrell Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:27:27 -0000 On 07/09/2014 07:48 AM, Robert Moskowitz wrote: > Sent to the HIPSEC list from my HIPSEC user: > > The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed > payload, and in many use cases, the Initiator has pre-deteremined the > Responder's HI and HIT so it can check the SIG before processing the ESP > TRANSFORM parameters. In sensornets where the Initiator cannot > pre-determine the Responder's (typically some sensor controller) HI and > HIT, then it is a concern. > > Further eventhough I1 is unsigned, the Initiator 'knows' what suites it > wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC > back, it MUST NOT complete the exchange. If in the R1 it gets NULL, > CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC. > > If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST > NOT complete the exchange. > > The HIP design team spent a long time working out downgrade attacks. I > have to thank Tobias Heer and Miika Komu for a couple day design when I > was visiting HIIT in Helsinki. > > NULL, CMAC, or GMAC should only be configured as allowable suites when > they are needed for debug, or the situation requires auth-only. And I > should point out there are devices and situations where auth-only is the > case, so those suites are needed. IMNSHO. > > In the worst case scenario, we could cover with text that clearifies the > privacy versus auth-only suites with requirements that these suites not > be mixed in an exchange and if one is expected, the other not accepted. > Of course 'servers' (I say that parenthetically, as HIP is a peer > exchange) MIGHT need to support both classes of customers and thus need > to respond based on the unprotectable I1 packet. Even there, the > Initiator still can bid back if its I1 was altered by a MiTM. > I would be fine with lessening this MUST to SHOULD. We probably should do the same for RFC 5201 (the HIP CIPHER). Below are some suggested edits along the lines of your suggestions above; any comments or concerns? In Section 5.2.8 of RFC 5201-bis: OLD TEXT: Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is included for testing purposes. NEW TEXT: Mandatory implementation: AES-128-CBC. Implementors SHOULD support NULL for testing/debugging purposes, but MUST NOT offer or accept this value unless explicitly configured for testing/debugging of the HIP protocol. In Section 3.3.5 of RFC 5202-bis: OLD TEXT: In addition to AES-128-CBC, all implementations MUST implement the ESP NULL encryption algorithm. When the ESP NULL encryption is used, it MUST be used together with SHA-256 authentication as specified in Section 5.1.2 NEW TEXT: In addition to AES-128-CBC, all implementations SHOULD implement the ESP NULL encryption algorithm. When the ESP NULL encryption is used, it MUST be used together with SHA-256 authentication as specified in Section 5.1.2. When an authentication-only suite is used (NULL, AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT be accepted if offered by the peer unless the local policy configuration regarding the peer host is explicitly set to allow an authentication-only mode. This is to prevent sessions from being downgraded to an authentication-only mode when one side's policy requests privacy for the session. In Section 5.1.2 of RFC 5202-bis: OLD TEXT: Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL with HMAC-SHA-256. NEW TEXT: Mandatory implementation: AES-128-CBC with HMAC-SHA-256. NULL with HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). - Tom From nobody Wed Jul 9 13:40:10 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C741A0015 for ; Wed, 9 Jul 2014 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 GF3uzCi_f90w for ; Wed, 9 Jul 2014 13:40:07 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7A1A0011 for ; Wed, 9 Jul 2014 13:40:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5652163440; Wed, 9 Jul 2014 20:40:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydhlvaqeELD4; Wed, 9 Jul 2014 16:39:54 -0400 (EDT) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1E5B66343C; Wed, 9 Jul 2014 16:39:54 -0400 (EDT) Message-ID: <53BDA896.3080104@htt-consult.com> Date: Wed, 09 Jul 2014 16:39:50 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> <53BD5652.300@htt-consult.com> <53BDA59C.4000004@tomh.org> In-Reply-To: <53BDA59C.4000004@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/f7f0EsCd-wbyQF_mh63Ui-MHeuY Cc: hipsec@ietf.org, Stephen Farrell Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:40:09 -0000 I am comfortable with these changes. On 07/09/2014 04:27 PM, Tom Henderson wrote: > On 07/09/2014 07:48 AM, Robert Moskowitz wrote: >> Sent to the HIPSEC list from my HIPSEC user: >> >> The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed >> payload, and in many use cases, the Initiator has pre-deteremined the >> Responder's HI and HIT so it can check the SIG before processing the ESP >> TRANSFORM parameters. In sensornets where the Initiator cannot >> pre-determine the Responder's (typically some sensor controller) HI and >> HIT, then it is a concern. >> >> Further eventhough I1 is unsigned, the Initiator 'knows' what suites it >> wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC >> back, it MUST NOT complete the exchange. If in the R1 it gets NULL, >> CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC. >> >> If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST >> NOT complete the exchange. >> >> The HIP design team spent a long time working out downgrade attacks. I >> have to thank Tobias Heer and Miika Komu for a couple day design when I >> was visiting HIIT in Helsinki. >> >> NULL, CMAC, or GMAC should only be configured as allowable suites when >> they are needed for debug, or the situation requires auth-only. And I >> should point out there are devices and situations where auth-only is the >> case, so those suites are needed. IMNSHO. >> >> In the worst case scenario, we could cover with text that clearifies the >> privacy versus auth-only suites with requirements that these suites not >> be mixed in an exchange and if one is expected, the other not accepted. >> Of course 'servers' (I say that parenthetically, as HIP is a peer >> exchange) MIGHT need to support both classes of customers and thus need >> to respond based on the unprotectable I1 packet. Even there, the >> Initiator still can bid back if its I1 was altered by a MiTM. >> > > I would be fine with lessening this MUST to SHOULD. We probably > should do the same for RFC 5201 (the HIP CIPHER). > > Below are some suggested edits along the lines of your suggestions > above; any comments or concerns? > > In Section 5.2.8 of RFC 5201-bis: > > OLD TEXT: > > Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is > included for testing purposes. > > NEW TEXT: > > Mandatory implementation: AES-128-CBC. Implementors SHOULD support > NULL for testing/debugging purposes, but MUST NOT offer or accept this > value unless explicitly configured for testing/debugging of the HIP > protocol. > > In Section 3.3.5 of RFC 5202-bis: > > OLD TEXT: > > In addition to AES-128-CBC, all implementations MUST implement the > ESP NULL encryption algorithm. When the ESP NULL encryption is used, > it MUST be used together with SHA-256 authentication as specified in > Section 5.1.2 > > NEW TEXT: > > In addition to AES-128-CBC, all implementations SHOULD implement the > ESP NULL encryption algorithm. When the ESP NULL encryption is used, > it MUST be used together with SHA-256 authentication as specified in > Section 5.1.2. > > When an authentication-only suite is used (NULL, > AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT > be accepted if offered by the peer unless the local policy > configuration regarding the peer host is explicitly set to allow an > authentication-only mode. This is to prevent sessions from being > downgraded to an authentication-only mode when one side's policy > requests privacy for the session. > > In Section 5.1.2 of RFC 5202-bis: > > OLD TEXT: > > Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL > with HMAC-SHA-256. > > NEW TEXT: > > Mandatory implementation: AES-128-CBC with HMAC-SHA-256. NULL with > HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). > > > > - Tom > From nobody Wed Jul 9 13:43:15 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AEA1A0011 for ; Wed, 9 Jul 2014 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 dZBCZu_W0bWP for ; Wed, 9 Jul 2014 13:43:12 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F419F1A0015 for ; Wed, 9 Jul 2014 13:43:11 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s69Kh4OJ000551; Wed, 9 Jul 2014 13:43:04 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1n0s1y36f1-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 09 Jul 2014 13:43:04 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 9 Jul 2014 13:42:53 -0700 From: Paul Lambert To: Robert Moskowitz , Tom Henderson Date: Wed, 9 Jul 2014 13:42:51 -0700 Thread-Topic: [Hipsec] NULL encryption mode in RFC 5202-bis Thread-Index: Ac+btlshjkIDG7NcSiGLirSuiviRXQ== Message-ID: References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <53BBE66D.2080807@htt-consult.com> <53BD5652.300@htt-consult.com> <53BDA59C.4000004@tomh.org> <53BDA896.3080104@htt-consult.com> In-Reply-To: <53BDA896.3080104@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-09_05:2014-07-09,2014-07-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407090252 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/3APHBA1Ip46tlyjR9kUfOk8sj6o Cc: "hipsec@ietf.org" , Stephen Farrell Subject: Re: [Hipsec] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:43:13 -0000 =B3SHOULD=B2 is a good improvement for those of us that may not be as fond = of NULL encryption. On 7/9/14, 1:39 PM, "Robert Moskowitz" wrote: >I am comfortable with these changes. > >On 07/09/2014 04:27 PM, Tom Henderson wrote: >> On 07/09/2014 07:48 AM, Robert Moskowitz wrote: >>> Sent to the HIPSEC list from my HIPSEC user: >>> >>> The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed >>> payload, and in many use cases, the Initiator has pre-deteremined the >>> Responder's HI and HIT so it can check the SIG before processing the >>>ESP >>> TRANSFORM parameters. In sensornets where the Initiator cannot >>> pre-determine the Responder's (typically some sensor controller) HI and >>> HIT, then it is a concern. >>> >>> Further eventhough I1 is unsigned, the Initiator 'knows' what suites it >>> wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC >>> back, it MUST NOT complete the exchange. If in the R1 it gets NULL, >>> CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC. >>> >>> If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST >>> NOT complete the exchange. >>> >>> The HIP design team spent a long time working out downgrade attacks. I >>> have to thank Tobias Heer and Miika Komu for a couple day design when I >>> was visiting HIIT in Helsinki. >>> >>> NULL, CMAC, or GMAC should only be configured as allowable suites when >>> they are needed for debug, or the situation requires auth-only. And I >>> should point out there are devices and situations where auth-only is >>>the >>> case, so those suites are needed. IMNSHO. >>> >>> In the worst case scenario, we could cover with text that clearifies >>>the >>> privacy versus auth-only suites with requirements that these suites not >>> be mixed in an exchange and if one is expected, the other not accepted. >>> Of course 'servers' (I say that parenthetically, as HIP is a peer >>> exchange) MIGHT need to support both classes of customers and thus need >>> to respond based on the unprotectable I1 packet. Even there, the >>> Initiator still can bid back if its I1 was altered by a MiTM. >>> >> >> I would be fine with lessening this MUST to SHOULD. We probably >> should do the same for RFC 5201 (the HIP CIPHER). >> >> Below are some suggested edits along the lines of your suggestions >> above; any comments or concerns? >> >> In Section 5.2.8 of RFC 5201-bis: >> >> OLD TEXT: >> >> Mandatory implementation: AES-128-CBC. NULL-ENCRYPTION [RFC2410] is >> included for testing purposes. >> >> NEW TEXT: >> >> Mandatory implementation: AES-128-CBC. Implementors SHOULD support >> NULL for testing/debugging purposes, but MUST NOT offer or accept this >> value unless explicitly configured for testing/debugging of the HIP >> protocol. >> >> In Section 3.3.5 of RFC 5202-bis: >> >> OLD TEXT: >> >> In addition to AES-128-CBC, all implementations MUST implement the >> ESP NULL encryption algorithm. When the ESP NULL encryption is used, >> it MUST be used together with SHA-256 authentication as specified in >> Section 5.1.2 >> >> NEW TEXT: >> >> In addition to AES-128-CBC, all implementations SHOULD implement the >> ESP NULL encryption algorithm. When the ESP NULL encryption is used, >> it MUST be used together with SHA-256 authentication as specified in >> Section 5.1.2. >> >> When an authentication-only suite is used (NULL, >> AES-CMAC-96, and AES-GMAC are examples), the suite MUST NOT >> be accepted if offered by the peer unless the local policy >> configuration regarding the peer host is explicitly set to allow an >> authentication-only mode. This is to prevent sessions from being >> downgraded to an authentication-only mode when one side's policy >> requests privacy for the session. >> >> In Section 5.1.2 of RFC 5202-bis: >> >> OLD TEXT: >> >> Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL >> with HMAC-SHA-256. >> >> NEW TEXT: >> >> Mandatory implementation: AES-128-CBC with HMAC-SHA-256. NULL with >> HMAC-SHA-256 SHOULD also be supported (see also Section 3.3.5). >> >> >> >> - Tom >> > >_______________________________________________ >Hipsec mailing list >Hipsec@ietf.org >https://www.ietf.org/mailman/listinfo/hipsec From nobody Thu Jul 17 23:53:27 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0891B2912 for ; Thu, 17 Jul 2014 23:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 S7crOfjjuh4l for ; Thu, 17 Jul 2014 23:53:22 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 181FD1B2910 for ; Thu, 17 Jul 2014 23:53:21 -0700 (PDT) Received: (qmail 26192 invoked by uid 0); 18 Jul 2014 06:53:21 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 18 Jul 2014 06:53:21 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id TitF1o0112molgS01itJG7; Fri, 18 Jul 2014 00:53:21 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=6F27WYAPyu8A:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=I9HKqsYaXT3wm_zgL9sA:9 a=J-mj8lYE2GfJP3BG:21 a=Mluno_AUf-N5E_7C:21 a=wPNLvfGTeEIA:10 a=ez6fdfsfNokA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=F+Xf35CsVA5iCL2idAVLLfa2CVEy08pnvS47V/hY8KI=; b=gKmALYkIgneAhgLjV8V7GyqHrceBff6whPcue2dbU6kjGo61bLg7iwmdX9/CIYaS11gQUmEe40+MC7D8Nr/huyRjK+6Od+xd3SaXNVdIPrQCI8rh3RQV+YWI9PFXEZjJ; Received: from [71.231.123.189] (port=59844 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X822d-0001mF-Gk for hipsec@ietf.org; Fri, 18 Jul 2014 00:53:15 -0600 Message-ID: <53C8C458.8090903@tomh.org> Date: Thu, 17 Jul 2014 23:53:12 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/xDswX6nxfWYfXPPF4xxOuvWKwD4 Subject: [Hipsec] draft status for RFC5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:53:23 -0000 Hi all, I posted some initial issues back on June 28: http://www.ietf.org/mail-archive/web/hipsec/current/msg03873.html and we had some discussion on the list that I believe resolved (or nearly resolved) three of the four issues. One that I feel is still open without strong consensus expressed is the issue of whether HIP is subject to certain plaintext attacks. There was some discussion in the thread about it. I opened issue 42 to track it: http://trac.tools.ietf.org/wg/hip/trac/ticket/42 There are a few other comments that have been received during the IESG review. The questions are posted here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/ Barry Leiba pointed out a number of problems with how our IANA section is written, and I had some discussion with him and also with IANA about what is needed here, so I will take a stab at this in the next revision. Issue 44 in the tracker is open for this: http://trac.tools.ietf.org/wg/hip/trac/ticket/44 Brian Haberman raised some questions about changes to the R1_COUNTER; I will go back to the archives on this and try to answer them. Pete Resnick has asked us to provide more rationale/justification for use of the TCP Maximum Segment Lifetime (MSL) in the draft. Stephen Farrell has posted a number of questions that are probably best served by starting a separate thread or threads. IETF draft submission is closed until the 21st, but I plan to post an update shortly after it reopens. - Tom From nobody Thu Jul 17 23:56:51 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80FC1A0A86 for ; Thu, 17 Jul 2014 23:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 YsGHmYOkz52x for ; Thu, 17 Jul 2014 23:56:47 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id B15141B2906 for ; Thu, 17 Jul 2014 23:56:47 -0700 (PDT) Received: (qmail 31290 invoked by uid 0); 18 Jul 2014 06:56:43 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 18 Jul 2014 06:56:43 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id Towd1o00D2molgS01owgLj; Fri, 18 Jul 2014 06:56:42 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=vKEh8PXGzQoA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=_QRqnzaw5JXmlWU4c2MA:9 a=wPNLvfGTeEIA:10 a=HvMzZPUT1n4A:10 a=SZSsTm5PJI0A:10 a=65i-nI39n1wA:10 a=Ye1-85Zid-wA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=04GCZh/78QmcFDprstC6kMimwhYYQ+rr5xVz/Ylojb8=; b=cYlEDHsEfprtyPOPSJbqQVGQPjN2bTZk83J+O5nHSo48iNPVvE1fimfNQD22Wp9vclbl/sm8QBnQaVpJ4e5wVWHN1hsn8DCO4H0po2sWf1K62sVG7MZMtQipeIEglPwu; Received: from [71.231.123.189] (port=59859 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X825u-0005Nq-K8 for hipsec@ietf.org; Fri, 18 Jul 2014 00:56:38 -0600 Message-ID: <53C8C523.4090105@tomh.org> Date: Thu, 17 Jul 2014 23:56:35 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/VSvx-KBCsiHi02833qZIWtYmjhM Subject: [Hipsec] draft status for RFC5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:56:48 -0000 Regarding RFC5202-bis, the two main issues still alive are: 1) the question of NULL encryption as a MUST to implement (discussed here: http://www.ietf.org/mail-archive/web/hipsec/current/msg03888.html) and also on the saag list. (issue 43 in the tracker: http://trac.tools.ietf.org/wg/hip/trac/ticket/43) 2) cleanup of IANA issues (issue 44 in the tracker: http://trac.tools.ietf.org/wg/hip/trac/ticket/44) - Tom From nobody Thu Jul 17 23:57:42 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFED1B2910 for ; Thu, 17 Jul 2014 23:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 juJJti4bF_FG for ; Thu, 17 Jul 2014 23:57:39 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 2EBA11B290C for ; Thu, 17 Jul 2014 23:57:39 -0700 (PDT) Received: (qmail 871 invoked by uid 0); 18 Jul 2014 06:57:39 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 18 Jul 2014 06:57:39 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id ToxU1o00l2molgS01oxX00; Fri, 18 Jul 2014 06:57:37 -0600 X-Authority-Analysis: v=2.1 cv=OcELUHjY c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=JlLBb9Fn3sEA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=taXjemQLJ4_xxy049BsA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xe9IlZocI9UNCHBcZM2MWMlofb7U3LbwXXAEkWD13fk=; b=K3gEFS0SmrumE56La3VWk+Ag1cnroOEm8OMaeaI74xSreXk6q1/BJo1it/BgT9dojOMoKITBoqNK2NmvkkYXVKOx7aqZSccZwAmzIaRVN3VWaSRwExK5pzigIngQS23J; Received: from [71.231.123.189] (port=59860 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X826k-0006KG-9b; Fri, 18 Jul 2014 00:57:30 -0600 Message-ID: <53C8C557.3070202@tomh.org> Date: Thu, 17 Jul 2014 23:57:27 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/2v7ompvuUUJU8M5liR4T2vOyisw Cc: Stephen Farrell Subject: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:57:40 -0000 I'm reposting several questions and comments from Stephen Farrell regarding RFC5201-bis, so that we can have some list discussion. See below (quoted verbatim from: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/) The main issues below for discussion seem to be: - what safeguards exist to reduce tracking of users? - questions about the choices of certain algorithms and modes and whether they are still current I'll open some more issues in the tracker if we don't get to consensus quickly. ---------------------------------------------------------------- This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant? Comment (2014-06-26) - abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? - 1.1: Saying the HI is the identity of the host seems a little overstated to me, but I guess that's accepted as a description for HIP, so not objecting, but it'd seem more natural to me to say that a HI is an identifier that a host can use. (Presumably load-balancing and mobility scenarios could mean that a private key could be on more than one host or one "host" might have >1 private key.) - section 3: 3110 doesn't seem like a great reference for RSA. Isn't there better? From nobody Sun Jul 20 05:30:29 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3F1B2B0B; Tue, 8 Jul 2014 08:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 jdgropSepPlP; Tue, 8 Jul 2014 08:16:07 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 B26881B2811; Tue, 8 Jul 2014 08:16:07 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id C94701E512; Tue, 8 Jul 2014 15:16:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404832566; bh=gaX/6Wjya3yTpcfa0/Am3DODFs+M4n71RdtW18i3KTM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lwDVx2ecIMWDQxjFeXiKw7Bb0cSfDmN5vnvMuw97C1us75Jz9g1iLWs9hRtmR8LQY IaJWV1D6HgHh8mGMqPA8mkz852qgpQCdH9h8qSjHg54/fTRShDCb4Vx4oDyvjpTn+G CHt9kYLMgEdTjXhMf7LYXlYc+Cz5jmvF9IgolQV4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5D33660022; Tue, 8 Jul 2014 15:06:03 +0000 (UTC) From: James Cloos To: Tom Henderson In-Reply-To: <53BB798A.3080101@tomh.org> (Tom Henderson's message of "Mon, 07 Jul 2014 21:54:34 -0700") References: <53BB798A.3080101@tomh.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 08 Jul 2014 11:06:03 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140708:tomh@tomh.org::T0MNsVncLJB9cP2y:000cwtka X-Hashcash: 1:30:140708:hipsec@ietf.org::DfIEo4o9SvSteygn:07AmQT X-Hashcash: 1:30:140708:saag@ietf.org::Ib/LELvpe1kI9sTa:000tqHve Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/c2fOxLqM8mzPfaq_zsk3PC4_iGk X-Mailman-Approved-At: Sun, 20 Jul 2014 05:30:24 -0700 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:16:09 -0000 >>>>> "TH" == Tom Henderson writes: TH> Stephen's discuss questions the specification of "MUST to implement" TH> for the NULL encryption option of the ESP_TRANSFORM parameter: If those doing IP over Amateur Radio are a use case, they require NULL. Encryption is illegal for most of them (I hear Australia allows it in some cases; AFAIK no other country does) but authentication has value. And that restriction is enforced. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sun Jul 20 05:30:30 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F61A035E; Tue, 8 Jul 2014 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 YpwZBvw1Gwi3; Tue, 8 Jul 2014 10:59:57 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A981A02EF; Tue, 8 Jul 2014 10:59:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0FE5820028; Tue, 8 Jul 2014 14:00:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1D07E63B0E; Tue, 8 Jul 2014 13:59:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0908163B09; Tue, 8 Jul 2014 13:59:54 -0400 (EDT) From: Michael Richardson To: Stephen Farrell In-Reply-To: <53BBC8DE.1010006@cs.tcd.ie> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/khLs-rIarM1q7wvePnOE2r5VnhI X-Mailman-Approved-At: Sun, 20 Jul 2014 05:30:23 -0700 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 17:59:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Stephen Farrell wrote: > Generic: is it still considered a good plan to have null > confidentiality suites such as these? Or for those to be > Mandatory-To-Implement (MTI)? That clearly was the generic consensus = as > we have these in a number of protocols. The new reasons to move from > that I think are: 1) we no longer need this for debugging purposes > really since libraries and dev tools have moved on and are better now, > and we specifically no longer need these for protocols that are no > longer new, 2) BCP188 could be considered to argue against having the= se There are an incredible number of systems (Linux with stock-in-kernel NETKEY IPsec for instance), where it is impossible or very very difficult to get a packet capture of the traffic after decryption, but before it goes up the protocol stack.=20 On such systems, if you have a problem in the field with a protocol that ru= ns over ESP (whether HIP or IKEv2 keyed), and you can't figure out how it work= s, and it appears to with without ESP, then the lack of debugging means that y= ou turn off all security. ESP-authenticated-with-NULL-encryption is debuggable in the field. Not having it, means turning off ESP; and if the problem is in the link between the ESP layer and the upper layer, then...=20 =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU7wxl4CLcPvd0N1lAQJDYAf/UNaXFLaXOUjzXPQYc5DH9qYpqRHNB6Ca QkzqYeBgpcyB/uCNcNoI9/nkiF+3Q6wlonQd3xbt1lnp/OFWTX1ifb2Qcqt7u7VT uISTSpexLad1u/OPbuLcuHNzOIAJzd+it1WX0ngdKRcf98dn6jyYQcCzy1PlT8XB rKWd2I12F3FKezPeuo9LurkYBmwo3ytkadla/UwL291M5nQ+BDG5+Ds8nHvpNvCS hBOdzm1lo6h05X9KpZgwRj4Bb8q5I6piv+YD3BsKXFpnQ/1TTZA/x+s4mhAyuK8K NmCVmFRmVQ8NRS4G5yXo88e9zPjoUnExzbTCTn+f8Xxu9rvXgjUE9w== =9bZN -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 20 05:30:31 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5461B2BDB; Tue, 8 Jul 2014 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 XERkGx-4_e_B; Tue, 8 Jul 2014 09:45:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 71A2A1B2BD9; Tue, 8 Jul 2014 09:45:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 4F8B21E4FB; Tue, 8 Jul 2014 16:45:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404837950; bh=LyKNDrIC2MSZDnlTIUTVUl0gnsqu6lIGIsNx36ELOB4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hZal5QpXBJ2uz5mAd+tH4W6WPWCC4ClX8JvxgKJZwec0WVsbjZRvgW/OOQ2x3avmx MxDPtg0J8NrJ+8hziApcyYWI91ZqOFQmB+FCfQdrH62Zj/pzZF6cejfUvLcaPkfyMl lASD9nTRGhMsqXRv+MIGI0vPtkIQUi1tLLkwklfM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1AFA360022; Tue, 8 Jul 2014 16:37:29 +0000 (UTC) From: James Cloos To: Stephen Farrell In-Reply-To: <53BC0D30.2070507@cs.tcd.ie> (Stephen Farrell's message of "Tue, 08 Jul 2014 16:24:32 +0100") References: <53BB798A.3080101@tomh.org> <53BC0D30.2070507@cs.tcd.ie> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 08 Jul 2014 12:37:29 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140708:stephen.farrell@cs.tcd.ie::6rHADQ+2+3jnZE0d:00000000000000000000000000000000000ooP3q X-Hashcash: 1:30:140708:tomh@tomh.org::VNj3cMxYoYrYEJUS:000COA7M X-Hashcash: 1:30:140708:hipsec@ietf.org::2ftBm3dRcqFg2TKh:0oOyF7 X-Hashcash: 1:30:140708:saag@ietf.org::XWVrU0AADgxgZHQH:0009OEZW Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/C4I1NgFPtxeDyWZrXgtSM0PfNKY X-Mailman-Approved-At: Sun, 20 Jul 2014 05:30:24 -0700 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:45:54 -0000 >>>>> "SF" == Stephen Farrell writes: SF> That'd be IPsec, not IP, I guess. How many people actually SF> use IPsec that way? I don't know. AIUI, hams have been specified as a reason for NULL for most ietf work product. For this case, though, it seems Robert's suggestion of CMAC and GMAC may be better long term. Although there is stil the issue of compatibility with existing users, if there are any. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jul 21 07:17:10 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167BA1A0025 for ; Mon, 21 Jul 2014 07:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 tH8cL9hKLIXY for ; Mon, 21 Jul 2014 07:17:05 -0700 (PDT) Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF081A001D for ; Mon, 21 Jul 2014 07:17:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,701,1400018400"; d="p7s'?scan'208";a="340855516" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 21 Jul 2014 16:17:03 +0200 Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id 30C5913DAB9; Mon, 21 Jul 2014 16:17:03 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Mon, 21 Jul 2014 16:17:02 +0200 From: Rene Hummen To: HIP Thread-Topic: [Hipsec] processing review comments on RFC 5201-bis Thread-Index: AQHPkvnhfwLtqf32AUCGb60aDjBTvJuJzwYAgALs3ICAABJWAIAdxywA Date: Mon, 21 Jul 2014 14:17:01 +0000 Message-ID: <4FAC761D-1596-46B4-9F00-808E5C1B0E82@comsys.rwth-aachen.de> References: <53AF010A.70606@tomh.org> <53B1A282.2060907@gmail.com> <53B416B3.1030307@cs.hut.fi> <53B42614.1070108@cs.hut.fi> In-Reply-To: <53B42614.1070108@cs.hut.fi> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.226.12.29] Content-Type: multipart/signed; boundary="Apple-Mail=_3789F9BE-A8F9-46E8-8990-3CBB0101BB3B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/IrR7aeo_BID7vy9sL2MKoze4RkM Subject: Re: [Hipsec] processing review comments on RFC 5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:17:08 -0000 --Apple-Mail=_3789F9BE-A8F9-46E8-8990-3CBB0101BB3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 02 Jul 2014, at 17:32, Miika Komu wrote: > Hi, >=20 > On 07/02/2014 05:26 PM, Miika Komu wrote: >> Hi, >>=20 >> On 06/30/2014 08:46 PM, Tom Taylor wrote: >>>> 3) Section 5.2.18: given the strict ordering of HIP parameters, the >>>> initial >>>> plaintext for the Encrypted content (type and length of initial >>>> parameter) may be fairly easily guessed. This opens up the minor >>>> possibility of a known plaintext attack. [Comment to be reviewed = after >>>> further examination.] [Upon review: I1 packets have fixed type but >>>> variable length due to varying lengths of DH-GROUP-LISTS. The set = of >>>> such lengths is limited, however, so it is worth considering = whether >>>> known plain-text attacks offer any real threat.] >>>>=20 >>>> Discussion: I don't know how/whether to handle this, or whether = other >>>> similar vulnerabilities in other security protocols are addressed. >>>> Changes to address this would likely complicate things or increase = the >>>> packet sizes. >>>=20 >>> [PTT] I have to leave it to people more knowledgeable in security to >>> judge whether this is a realistic attack. One point of approach is = to >>> find out what sample size is needed for known plain-text attacks for >>> specific algorithms, compare that with the rate at which an attacker >>> could collect encrypted messages in specific scenarios, and decide >>> whether there is a real threat. Mitigation presumably might be = through >>> adjustment of the rate of key rollover. >>=20 >> do we actually need the encrypted parameter for something really >> critical (i.e. some extensions rely on it)? If not, we could just = remove >> it. Usually the encrypted parameter just contains the HOST_ID of the >> Initiator which does not really offer any real privacy since the HIT = is >> in plaintext and actually can interfere with middleboxes (as already >> mentioned in the draft). >>=20 >> If the encrypted parameter is critical, here's a straw-man proposal = that >> avoids increasing packet size: XOR the contents of the encrypted >> parameter by iterating through it block-by-block using the encryption >> key. Then, encrypt it with the same key. >>=20 >> If packet size is not a problem, we could include an extra, fixed = size >> key for XORing within the encrypted parameter. Or perhaps just = encrypt >> the plaintext twice with the encryption key. >>=20 >> (My solutions are presented in chronologically in the order of my >> personal preference) >=20 > on second thought, do we actually have a real problem here? Let us = consider: >=20 > * The encryption key is different for each base exchange, so the roll = over is actually occurring every time, so that observing multiple base = exchanges does not benefit the attacker Just for the sake of completeness: The ENCRYPTED parameter can also be = used in other messages such as UPDATE (currently not the case). Still, = this is a low volume control channel.=20 > * To derive the encryption key, you need a very expensive brute for = search, and the award is (usually) just the public key of the initiator > * If the parameter contains something else in addition to the public = key, the brute force search is still very expensive (exponential) The award of a known plaintext attack would be the encryption key not = just the the content of the ENCRYPTED parameter. HIP_MAC would not be = compromised though as it uses its own key. Nevertheless ... > * The default algo (AES) is resistant against linear and differential = cryptanalysis This would also be my conclusion. > So, I am not convinced that the current mechanism should be changed. +1 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_3789F9BE-A8F9-46E8-8990-3CBB0101BB3B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MjExNDE3MDFaMCMGCSqGSIb3DQEJBDEWBBQ6UVxBVBuy tURZ8qPUPqdzGk8c7TB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQBuBd8XFNe7 Q1qDLkoXAXPLt3THHbYHIyreAMUUzqlvPdFDh7PeRhPz001MKD73p8kbsZwD+GHzn0TiAnDV+MqX 8r5IuwxrTAIV6kL4PMlxVz34e/tTxr4BO+dFpNfeYXJre+sms806NPjVrE46LOBlB9gnkEz2FJ7n qKBO4U39XrAS0fgxW0rTCRtEqvEVe2iI3kDTH30329LbuKJDKWrxmct/gSjjrleBquNQ0i06++pz R3cdo4E1rbPVtMOWt0AegnOHZuPpUlgEwegI6stifK2vgVWlAVUkQsXa2kryfEq0DYIR6tFEHcg3 ZNOPWs6oOodXwGNV8mfby9s0vWavAAAAAAAA --Apple-Mail=_3789F9BE-A8F9-46E8-8990-3CBB0101BB3B-- From nobody Mon Jul 21 07:25:11 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC221A00DE; Mon, 21 Jul 2014 07:25:09 -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 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 dm_YOKw9RPrT; Mon, 21 Jul 2014 07:25:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0EE1A0103; Mon, 21 Jul 2014 07:24:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721142454.10961.86921.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 07:24:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/C1M8LoOPakCzj4D7Sa89c9Qe0bE Cc: hip mailing list , hip chair , RFC Editor Subject: [Hipsec] Protocol Action: 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)' to Proposed Standard (draft-ietf-hip-rfc4843-bis-08.txt) X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:25:09 -0000 The IESG has approved the following document: - 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)' (draft-ietf-hip-rfc4843-bis-08.txt) as Proposed Standard This document is the product of the Host Identity Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-hip-rfc4843-bis/ Technical Summary: This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes the earlier format defined in [RFC4843]. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. Working Group Summary: There is full consensus behind this document. In September 2012, the authors of the draft consulted with Brian Haberman, who was the HIP WG's responsible AD at that point, to make sure the purpose of the draft was clear. Document Quality: As discussed in RFC 6538, there are several implementations of the Experimental HIP specs. At least HIP for Linux and OpenHIP will be updated to comply with the standards-track specs. Personnel: Gonzalo Camarillo is the document shepherd. Ted Lemon is the responsible AD. From nobody Mon Jul 21 10:19:46 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B75A1A02DF for ; Mon, 21 Jul 2014 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 wV55vjouCisS for ; Mon, 21 Jul 2014 10:19:40 -0700 (PDT) Received: from mx-out-2.rwth-aachen.de (mx-out-2.rwth-aachen.de [134.130.5.187]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7C01A026A for ; Mon, 21 Jul 2014 10:19:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,702,1400018400"; d="p7s'?scan'208";a="252865566" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-2.rz.rwth-aachen.de with ESMTP; 21 Jul 2014 19:19:38 +0200 Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id 5AB5D13DAB9; Mon, 21 Jul 2014 19:19:38 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Mon, 21 Jul 2014 19:19:37 +0200 From: Rene Hummen To: HIP Thread-Topic: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions Thread-Index: AQHPolWUup3xhMcaI0a14JumkyI3kpuqqbEA Date: Mon, 21 Jul 2014 17:19:36 +0000 Message-ID: <98C8F7AB-D777-428D-B725-2F885EC3893F@comsys.rwth-aachen.de> References: <53C8C557.3070202@tomh.org> In-Reply-To: <53C8C557.3070202@tomh.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.226.12.29] Content-Type: multipart/signed; boundary="Apple-Mail=_F96B9A5B-93C3-49A2-953C-652BE159729B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/lc7GzldL89738vjptJV_EZKMy9c Cc: Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:19:44 -0000 --Apple-Mail=_F96B9A5B-93C3-49A2-953C-652BE159729B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Please, find my comments inline. On 18 Jul 2014, at 08:57, Tom Henderson wrote: > I'm reposting several questions and comments from Stephen Farrell = regarding RFC5201-bis, so that we can have some list discussion. See = below (quoted verbatim from: > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/) >=20 > The main issues below for discussion seem to be: >=20 > - what safeguards exist to reduce tracking of users? > - questions about the choices of certain algorithms and modes and = whether they are still current >=20 > I'll open some more issues in the tracker if we don't get to consensus = quickly. >=20 > ---------------------------------------------------------------- >=20 >=20 > This review is based on the diff from 5201 [1] >=20 > [1] >=20 > = https://tools.ietf.org/rfcdiff?url1=3Drfc5201&url2=3Ddraft-ietf-hip-rfc520= 1-bis-14.txt >=20 > Work started on this in 2009 it appears and the backwards > incompatible changes made to the BEX are roughly what I'd > expect to have seen for good work done around that time. > However, some things have changed since, that I don't see > reflected in the changes made to the BEX, so I'd like to > chat about those for a bit, in case they're still > malleable. If it is really the case that the boat has > sailed for such changes, then that's life, but I wonder > has it? (I really don't know for HIP.) >=20 > I think the features in the changes to the BEX that one > would consider noteworthy were that work done today are: >=20 > (1) Mandating some form of variability of, and > confidentiality for, the (non-routable?) HIT to enhance > privacy or at least mitigate trival passive tracking of > activity across time and different connections. (Or maybe > the "anonymous HI" mechanism achieves this, I wasn't > sure? If it does, then why have any other?) In my opinion, stable HITs are actually a desirable property for HIP. As = a fixed-length and _verifiable_ representation of the HI, they can be = used for access control purposes at end hosts as well as at middleboxes = (as part of HIP=92s middlebox friendliness). Moreover, HITs are used as = stable identifiers in the HIP Certificate extension [1]. In the end, user privacy with stable HITs/HIs appears to be as good or = bad as it currently is with mutual certificate-based authentication, = e.g., in case of TLS. As mentioned above, short-lived (anonymous) HIs can be used to prevent = tracking of users across HIP sessions. Then, however, user = authentication requires, e.g., application layer passwords much like = current user->service authentication of TLS-protected data transmissions = on the web. So, from my point of view, there is a case for stable as well as for = anonymous (i.e., variable) HITs/HIs. > (2) There is no support for newer elliptic curves or > representations like 25519. HIPv2 incorporates mechanisms to update the protocol with newer curves. = Is there really the need to revise the document now or should we rather = wait until the need for newer curves arises due to demand by certain = applications/implementors? As for the representation, HIPv2 appears to require =93Octet-string = format" [2]. Is there a need to add protocol agility regarding the = encoding (i.e., a new ECC parameter field)? > (3) Continuing to support the 1536 MODP DHE group but not > supporting the 2048 equivalent seems a bit odd, as does > not having a code point for the 4096 but group. > Similarly, making the 1536 bit group the MTI (in 5.2.7) > is odd as is the assertion that "web surfing" can use a > lower security level. I am not aware of the criteria that were used for choosing the DHE = groups. Can someone else comment on this? > (4) (5.2.8) Did the WG discuss deprecating the NULL > encryption option? (Haven't you finished testing yet:-) I think this has been addressed on the mailinglist. > Also - there are no counter modes, is that wise? HIP DEX defines AES-128-CTR for HIP_CIPHER [3]. However, I just realized = that it does not specify its use for the ENCRYPTED parameter. Instead, = the specification focuses on the special-purpose ENCRYPTED_KEY = parameter. So, some work would be needed to carry this over to HIPv2. > Finally, > HIPv1's encryption codepoint 1 was for a 3DES option, but > here you have 1 =3D=3D NULL, yet you deprecate codepoint 3, > which is confusing. Why is that? Is this maybe a specification hiccup? > (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If > HMAC-SHA-256 is supported, then why not just use that? > Is there are real benefit in the sha1 variant? SHA-1 is only defined for use with ECDSA_LOW. Currently, the only = defined curve for this profile is SECP160R1. Seeing that, e.g., CoAP, = recommends secp256r1 [4] even for constrained devices, we could probably = remove the ECDSA_LOW profile in HIPv2 altogether. > Comment (2014-06-26) >=20 > - abstract: SIGMA-compliant is a bit of a mouthful for an > abstract - how many readers do we really expect to get > that? I suggest to simply remove the =93SIGMA-compliant=94 in the abstract. = It=92s mentioned again (with a reference) later on in the introduction = [5]. > - 1.1: Saying the HI is the identity of the host seems a > little overstated to me, but I guess that's accepted as > a description for HIP, so not objecting, but it'd seem > more natural to me to say that a HI is an identifier that > a host can use. (Presumably load-balancing and mobility > scenarios could mean that a private key could be on more > than one host or one "host" might have >1 private key.) I think the current description of the HI is more intuitive if not = entirely precise. It doesn=92t cover the mentioned (corner-)cases, but I = personally prefer it the way it is right now. > - section 3: 3110 doesn't seem like a great reference > for RSA. Isn't there better? I am not sure what this is referring to. BR Ren=E9 [1] http://tools.ietf.org/html/rfc6253 [2] = http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-5.2.9 [3] http://tools.ietf.org/html/draft-moskowitz-hip-dex-01#section-5.2.4 [4] http://tools.ietf.org/html/rfc7252#section-9.1.3.2 [5] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-1.2 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_F96B9A5B-93C3-49A2-953C-652BE159729B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MjExNzE5MzZaMCMGCSqGSIb3DQEJBDEWBBQTYm7Q/xrc ltCVanR1AHHOs43crTB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQAAg8OmYZtb ezMwyNMiNzuh5TEPrFcb5zf6fJpL6cVglmKU/aClMFANtsNNDUtV/9QB8uyTR9eIkGmCTIz9t+cz V3bXY0tnwv82UO3qEWRhTXt9/tjJaQ34W+gi4UifZ0rPDgugPkSdzBrMS6oCXmAENlwLubOUZl8P 9tIAMh1n9aPCOfGrfpOA70zVE5MnsoI2/qhgRgHcz2da9b/4EfVXliwQpyUZDN4NRrhpz4jZd9jD MvkSLr56jgs06IlxXp2/jd76PCczHj5a2dkupgnDViNeQuzPGs6DPmhHxfpAlwpXNcojCl9CucuN oW6v42gy/LddruDsqr29aBzObQxDAAAAAAAA --Apple-Mail=_F96B9A5B-93C3-49A2-953C-652BE159729B-- From nobody Mon Jul 21 15:51:07 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545E51A0AAC for ; Mon, 21 Jul 2014 15:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 NCm9EpXzlhMN for ; Mon, 21 Jul 2014 15:51:05 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1B76A1A0AA9 for ; Mon, 21 Jul 2014 15:51:04 -0700 (PDT) Received: (qmail 3684 invoked by uid 0); 21 Jul 2014 22:51:00 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 21 Jul 2014 22:51:00 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id VAql1o00h2molgS01AqooZ; Mon, 21 Jul 2014 16:51:00 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=HvaABalQiiUA:10 a=q7J0aIbBmN8A:10 a=N659UExz7-8A:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=GkevJ1taCQ9oqFZXbagA:9 a=_UlVp8SAsUzCxsrD:21 a=YJ25PdBGDy3vB76o:21 a=pILNOxqGKmIA:10 a=YucXLVEyVCkA:10 a=uQ1u1nazGJsA:10 a=OuPSdZv8c7MA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5PyZhPBbNMudPcbUoQqx8zb9fSnWL7o7kz4mE4QPE0k=; b=rDpbk1FP0230c72gTiawJQVAEP9VCyPI+UlCoZ+Sda+FBzc2hToB0bzZiSsLuancEQdkFst3ZzggHXuzvnaPcuNm80r81r5aZLSOkfL0qWQmequFMoVH0Tv5rJ/juuIi; Received: from [71.231.123.189] (port=34629 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9MPt-0002xi-J5; Mon, 21 Jul 2014 16:50:45 -0600 Message-ID: <53CD9942.9040701@tomh.org> Date: Mon, 21 Jul 2014 15:50:42 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Hummen , HIP References: <53C8C557.3070202@tomh.org> <98C8F7AB-D777-428D-B725-2F885EC3893F@comsys.rwth-aachen.de> In-Reply-To: <98C8F7AB-D777-428D-B725-2F885EC3893F@comsys.rwth-aachen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/pfduYjsenpW6RqP7aN88oROGMvU Cc: Stephen Farrell Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:51:07 -0000 Some more comments inline below: On 07/21/2014 10:19 AM, Rene Hummen wrote: > Please, find my comments inline. > > On 18 Jul 2014, at 08:57, Tom Henderson wrote: >> I'm reposting several questions and comments from Stephen Farrell >> regarding RFC5201-bis, so that we can have some list discussion. >> See below (quoted verbatim from: >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/) >> >> >> >> The main issues below for discussion seem to be: >> >> - what safeguards exist to reduce tracking of users? - questions >> about the choices of certain algorithms and modes and whether they >> are still current >> >> I'll open some more issues in the tracker if we don't get to >> consensus quickly. >> >> ---------------------------------------------------------------- >> >> >> This review is based on the diff from 5201 [1] >> >> [1] >> >> https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt >> >> >> Work started on this in 2009 it appears and the backwards >> incompatible changes made to the BEX are roughly what I'd expect to >> have seen for good work done around that time. However, some things >> have changed since, that I don't see reflected in the changes made >> to the BEX, so I'd like to chat about those for a bit, in case >> they're still malleable. If it is really the case that the boat >> has sailed for such changes, then that's life, but I wonder has it? >> (I really don't know for HIP.) >> >> I think the features in the changes to the BEX that one would >> consider noteworthy were that work done today are: >> >> (1) Mandating some form of variability of, and confidentiality for, >> the (non-routable?) HIT to enhance privacy or at least mitigate >> trival passive tracking of activity across time and different >> connections. (Or maybe the "anonymous HI" mechanism achieves this, >> I wasn't sure? If it does, then why have any other?) > > In my opinion, stable HITs are actually a desirable property for HIP. > As a fixed-length and _verifiable_ representation of the HI, they can > be used for access control purposes at end hosts as well as at > middleboxes (as part of HIP’s middlebox friendliness). Moreover, HITs > are used as stable identifiers in the HIP Certificate extension [1]. > In the end, user privacy with stable HITs/HIs appears to be as good > or bad as it currently is with mutual certificate-based > authentication, e.g., in case of TLS. > > As mentioned above, short-lived (anonymous) HIs can be used to > prevent tracking of users across HIP sessions. Then, however, user > authentication requires, e.g., application layer passwords much like > current user->service authentication of TLS-protected data > transmissions on the web. I agree with Rene's comments above, except I might say that anonymous HIs should in theory provide no worse tracking exposure than current approaches that use semi-stable IP addresses, versus "preventing tracking of users" (HIP doesn't block tracking by other means). The question I have is whether a "tracking considerations" paragraph ought to be added to the security considerations section, along the lines of: - repeated use of stable HITs will likely increase tracking exposure, for better or worse (caveat emptor) - use of anonymous HITs might eliminate additional tracking exposure, at the cost of requiring authentication mechanisms at higher layers > > So, from my point of view, there is a case for stable as well as for > anonymous (i.e., variable) HITs/HIs. > >> (2) There is no support for newer elliptic curves or >> representations like 25519. > > HIPv2 incorporates mechanisms to update the protocol with newer > curves. Is there really the need to revise the document now or should > we rather wait until the need for newer curves arises due to demand > by certain applications/implementors? > > As for the representation, HIPv2 appears to require “Octet-string > format" [2]. Is there a need to add protocol agility regarding the > encoding (i.e., a new ECC parameter field)? > >> (3) Continuing to support the 1536 MODP DHE group but not >> supporting the 2048 equivalent seems a bit odd, as does not having >> a code point for the 4096 but group. Similarly, making the 1536 bit >> group the MTI (in 5.2.7) is odd as is the assertion that "web >> surfing" can use a lower security level. > > I am not aware of the criteria that were used for choosing the DHE > groups. Can someone else comment on this? I don't recall offhand, other than that we went through a round of review with CFRG back in 2012 and we ended up modifying our crypto selections based on the feedback received. Bob and Tobias have been the caretakers of the crypto selections in HIPv2 in general, so I defer to them. > >> (4) (5.2.8) Did the WG discuss deprecating the NULL encryption >> option? (Haven't you finished testing yet:-) > > I think this has been addressed on the mailinglist. Stephen, I wonder whether saag discussion has died down now and there are any comments on my proposed resolution posted here? http://www.ietf.org/mail-archive/web/hipsec/current/msg03894.html > >> Also - there are no counter modes, is that wise? > > HIP DEX defines AES-128-CTR for HIP_CIPHER [3]. However, I just > realized that it does not specify its use for the ENCRYPTED > parameter. Instead, the specification focuses on the special-purpose > ENCRYPTED_KEY parameter. So, some work would be needed to carry this > over to HIPv2. > >> Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but >> here you have 1 == NULL, yet you deprecate codepoint 3, which is >> confusing. Why is that? > > Is this maybe a specification hiccup? I introduced this "DEPRECATED" as part of comment resolutions back in 2012 (someone in CFRG suggested to drop it), in this post: http://www.ietf.org/mail-archive/web/hipsec/current/msg03557.html However, HIP_CIPHER is a new parameter, so nothing really needs to be deprecated. Perhaps "RESERVED" would have been better (or remap AES-256-CBC to value 3). Any concern if I change DEPRECTED to RESERVED and add the comment that it is unused, such as:? Reserved 3 (unused value) Or would it be better to just omit the line and skip from 2 to 4? > >> (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 >> is supported, then why not just use that? Is there are real benefit >> in the sha1 variant? > > SHA-1 is only defined for use with ECDSA_LOW. Currently, the only > defined curve for this profile is SECP160R1. Seeing that, e.g., CoAP, > recommends secp256r1 [4] even for constrained devices, we could > probably remove the ECDSA_LOW profile in HIPv2 altogether. > >> Comment (2014-06-26) >> >> - abstract: SIGMA-compliant is a bit of a mouthful for an abstract >> - how many readers do we really expect to get that? > > I suggest to simply remove the “SIGMA-compliant” in the abstract. > It’s mentioned again (with a reference) later on in the introduction > [5]. +1 > >> - 1.1: Saying the HI is the identity of the host seems a little >> overstated to me, but I guess that's accepted as a description for >> HIP, so not objecting, but it'd seem more natural to me to say that >> a HI is an identifier that a host can use. (Presumably >> load-balancing and mobility scenarios could mean that a private key >> could be on more than one host or one "host" might have >1 private >> key.) > > I think the current description of the HI is more intuitive if not > entirely precise. It doesn’t cover the mentioned (corner-)cases, but > I personally prefer it the way it is right now. I'm not sure what text you are referring to. Section 1.1 says that "The HI is a public key and directly represents the Identity of a host. " but it doesn't say that the HI "is" the identity. > >> - section 3: 3110 doesn't seem like a great reference for RSA. >> Isn't there better? > > I am not sure what this is referring to. I think this refers to the first reference to RSA as an algorithm in general (in Section 3). Later references use RFC3110 to refer to the specific encoding defined there, and I think that we need to preserve those references. So I think Stephen's comment is to replace this reference in Section 3: HIP implementations MUST support the Rivest Shamir Adelman (RSA) [RFC3110] public key algorithm with something else. Any ideas of what to put there? RFC3110 itself cites Schneier's Applied Cryptography book when referring to RSA. - Tom From nobody Mon Jul 21 16:57:21 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16EA1A02E9; Mon, 21 Jul 2014 16:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 smanxjZ8-9dR; Mon, 21 Jul 2014 16:57:17 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD971A0066; Mon, 21 Jul 2014 16:57:17 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6LNurFt012094; Mon, 21 Jul 2014 16:57:07 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1n8ud7k8dn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Jul 2014 16:57:07 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Mon, 21 Jul 2014 16:57:07 -0700 From: Paul Lambert To: Michael Richardson , Stephen Farrell Date: Mon, 21 Jul 2014 16:57:03 -0700 Thread-Topic: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis Thread-Index: Ac+kFmUEabbuV/jcQ7OvNK+uD17ktABKN8vA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> In-Reply-To: <8171.1404842394@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-20_03:2014-07-18,2014-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407210277 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/H-Zh__jQ3zI2f1cSaDqd4Noh1hE Cc: "hipsec@ietf.org" , "saag@ietf.org" Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:57:20 -0000 NULL may be useful to some, but should NOT be mandated (should rather than = must). It's another knob that could be set incorrectly and bypass the encryption. = Not all products will want or need NULL. Paul ]-----Original Message----- ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael ]Richardson ]Sent: Tuesday, July 08, 2014 11:00 AM ]To: Stephen Farrell ]Cc: hipsec@ietf.org; saag@ietf.org ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis ] ] ]Stephen Farrell wrote: ] > Generic: is it still considered a good plan to have null ] > confidentiality suites such as these? Or for those to be ] > Mandatory-To-Implement (MTI)? That clearly was the generic ]consensus as ] > we have these in a number of protocols. The new reasons to move ]from ] > that I think are: 1) we no longer need this for debugging purposes ] > really since libraries and dev tools have moved on and are better ]now, ] > and we specifically no longer need these for protocols that are no ] > longer new, 2) BCP188 could be considered to argue against having ]these ] ]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very ]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack. ] ]On such systems, if you have a problem in the field with a protocol that ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how ]it works, and it appears to with without ESP, then the lack of debugging ]means that you turn off all security. ] ]ESP-authenticated-with-NULL-encryption is debuggable in the field. ]Not having it, means turning off ESP; and if the problem is in the link ]between the ESP layer and the upper layer, then... ] ]-- ]Michael Richardson , Sandelman Software Works -=3D ]IPv6 IoT consulting =3D- ] ] From nobody Tue Jul 22 07:16:55 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1CF1A01E5; Mon, 21 Jul 2014 17:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=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 10mUoacmDUrB; Mon, 21 Jul 2014 17:51:20 -0700 (PDT) Received: from mailout4.easymail.ca (mailout.easymail.ca [64.68.200.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2407A1A0197; Mon, 21 Jul 2014 17:51:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout4.easymail.ca (Postfix) with ESMTP id AE082E7D0; Mon, 21 Jul 2014 20:51:17 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout4.easymail.ca Received: from mailout4.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout2.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYugvQ7mjF7k; Mon, 21 Jul 2014 20:51:13 -0400 (EDT) Received: from [192.168.3.137] (71-80-163-186.static.lsan.ca.charter.com [71.80.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailout4.easymail.ca (Postfix) with ESMTPSA id E0AFBE72B; Mon, 21 Jul 2014 20:51:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Henry B Hotz In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> Date: Mon, 21 Jul 2014 17:51:09 -0700 Message-Id: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/OvTI1gsr_7BIFgGW_-JfUcMwqZ4 X-Mailman-Approved-At: Tue, 22 Jul 2014 07:16:53 -0700 Cc: Michael Richardson , "hipsec@ietf.org" , "saag@ietf.org" , Stephen Farrell Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 00:51:21 -0000 --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The basic issue, as always, is interoperability. NULL should not be an = interoperable *operational* capability. Every implementation will have some kind of debugging capability so it = can be made operational. Do we require an interoperable debugging = capability? I believe the consensus is already leaning to "no". My own take is that we don't normally do that, and the likely debugging = benefit of mandating such a thing is insufficient to justify making it a = MUST. On Jul 21, 2014, at 4:57 PM, Paul Lambert wrote: > NULL may be useful to some, but should NOT be mandated (should rather = than must). > It's another knob that could be set incorrectly and bypass the = encryption. Not all products will want or need NULL. >=20 >=20 > Paul >=20 > ]-----Original Message----- > ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael > ]Richardson > ]Sent: Tuesday, July 08, 2014 11:00 AM > ]To: Stephen Farrell > ]Cc: hipsec@ietf.org; saag@ietf.org > ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis > ] > ] > ]Stephen Farrell wrote: > ] > Generic: is it still considered a good plan to have null > ] > confidentiality suites such as these? Or for those to be > ] > Mandatory-To-Implement (MTI)? That clearly was the generic > ]consensus as > ] > we have these in a number of protocols. The new reasons to move > ]from > ] > that I think are: 1) we no longer need this for debugging = purposes > ] > really since libraries and dev tools have moved on and are = better > ]now, > ] > and we specifically no longer need these for protocols that are = no > ] > longer new, 2) BCP188 could be considered to argue against = having > ]these > ] > ]There are an incredible number of systems (Linux with stock-in-kernel > ]NETKEY IPsec for instance), where it is impossible or very very > ]difficult to get a packet capture of the traffic after decryption, = but > ]before it goes up the protocol stack. > ] > ]On such systems, if you have a problem in the field with a protocol = that > ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out = how > ]it works, and it appears to with without ESP, then the lack of = debugging > ]means that you turn off all security. > ] > ]ESP-authenticated-with-NULL-encryption is debuggable in the field. > ]Not having it, means turning off ESP; and if the problem is in the = link > ]between the ESP layer and the upper layer, then... > ] > ]-- > ]Michael Richardson , Sandelman Software Works = -=3D > ]IPv6 IoT consulting =3D- > ] > ] >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = basic issue, as always, is interoperability. NULL should not be an = interoperable *operational* capability.

Every = implementation will have some kind of debugging capability so it can be = made operational. Do we require an interoperable debugging capability? I = believe the consensus is already leaning to = "no".

My own take is that we don't normally do = that, and the likely debugging benefit of mandating such a thing is = insufficient to justify making it a = MUST.


On Jul 21, 2014, = at 4:57 PM, Paul Lambert <paul@marvell.com> = wrote:

NULL may be useful to some, but should NOT be mandated = (should rather than must).
It's another knob that could be set = incorrectly and bypass the encryption.  Not all products will want = or need NULL.


Paul

]-----Original = Message-----
]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of = Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: = Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: = [Hipsec] [saag] NULL encryption mode in RFC = 5202-bis
]
]
]Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:
]    > Generic: is it still considered a = good plan to have null
]    > confidentiality = suites such as these? Or for those to be
]    > = Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus = as
]    > we have these in a number of protocols. = The new reasons to move
]from
]    > that I = think are: 1) we no longer need this for debugging purposes
] =    > really since libraries and dev tools have moved = on and are better
]now,
]    > and we = specifically no longer need these for protocols that are no
] =    > longer new, 2) BCP188 could be considered to = argue against having
]these
]
]There are an incredible number = of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), = where it is impossible or very very
]difficult to get a packet = capture of the traffic after decryption, but
]before it goes up the = protocol stack.
]
]On such systems, if you have a problem in the = field with a protocol that
]runs over ESP (whether HIP or IKEv2 = keyed), and you can't figure out how
]it works, and it appears to = with without ESP, then the lack of debugging
]means that you turn off = all security.
]
]ESP-authenticated-with-NULL-encryption is = debuggable in the field.
]Not having it, means turning off ESP; and = if the problem is in the link
]between the ESP layer and the upper = layer, then...
]
]--
]Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works  -=3D
]IPv6 IoT consulting = =3D-
]
]

_______________________________________________
s= aag mailing list
saag@ietf.org
https://www.ietf.org/ma= ilman/listinfo/saag

Personal = email.  hbhotz@oxy.edu



= --Apple-Mail=_C883EB27-03CB-443D-AA77-52057B2AB9BD-- From nobody Tue Jul 22 07:29:20 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69D01B292A; Tue, 22 Jul 2014 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 qhRrT6eYfy2J; Tue, 22 Jul 2014 07:29:05 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331421B28F4; Tue, 22 Jul 2014 07:29:05 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 00D331B873E; Tue, 22 Jul 2014 07:28:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E55CA190060; Tue, 22 Jul 2014 07:28:45 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.169) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 07:28:45 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Jul 2014 10:28:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> References: <53BB798A.3080101@tomh.org> To: James Cloos X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.169] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/deVWhvmWtWcrQZIcIOZMKmGkAQE Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:29:08 -0000 On Jul 8, 2014, at 11:06 AM, James Cloos wrote: > If those doing IP over Amateur Radio are a use case, they require = NULL. If Amateur Radio's prohibition on encryption is considered to be = important in making decisions about crypto in protocols, then I think we = are in a situation where we can't have crypto protocols that don't = disallow downgrade attacks, because implementations always have to be = willing to downgrade to no encryption if the other endpoint is an = Amateur Radio station. So, by reductio ad absurdum, I claim that this isn't something the = working group should consider as a deciding factor. I think the same = observation also applies to Michael's comment about debugging on stacks = with limited trace capability. If you need to disable encryption, you = should have to do something fairly extraordinary to make that happen. From nobody Tue Jul 22 07:29:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03751B291A; Tue, 22 Jul 2014 07:29:11 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 52hUvBdYxGpu; Tue, 22 Jul 2014 07:29:09 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB11B2929; Tue, 22 Jul 2014 07:29:08 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id E739262A80; Tue, 22 Jul 2014 14:29:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIq7LS6wKR1D; Tue, 22 Jul 2014 10:28:56 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 36FD462A5A; Tue, 22 Jul 2014 10:28:56 -0400 (EDT) Message-ID: <53CE7526.3020702@htt-consult.com> Date: Tue, 22 Jul 2014 10:28:54 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Henry B Hotz , Paul Lambert References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> In-Reply-To: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> Content-Type: multipart/alternative; boundary="------------080207070708030309000503" Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/kpaLIMae1IrjwJXsl_ylOfJny8U Cc: Michael Richardson , Stephen Farrell , "saag@ietf.org" , "hipsec@ietf.org" Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:29:12 -0000 This is a multi-part message in MIME format. --------------080207070708030309000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/21/2014 08:51 PM, Henry B Hotz wrote: > The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability. In this regard, I have a hard time distinguishing between NULL with HMAC-SHA256 and CMAC or GMAC. With this (secure communications) context NULL means no privacy but yes authenticity. > > Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no". > > My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST. > > > On Jul 21, 2014, at 4:57 PM, Paul Lambert wrote: > >> NULL may be useful to some, but should NOT be mandated (should rather than must). >> It's another knob that could be set incorrectly and bypass the encryption. Not all products will want or need NULL. >> >> >> Paul >> >> ]-----Original Message----- >> ]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael >> ]Richardson >> ]Sent: Tuesday, July 08, 2014 11:00 AM >> ]To: Stephen Farrell >> ]Cc: hipsec@ietf.org; saag@ietf.org >> ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis >> ] >> ] >> ]Stephen Farrell wrote: >> ] > Generic: is it still considered a good plan to have null >> ] > confidentiality suites such as these? Or for those to be >> ] > Mandatory-To-Implement (MTI)? That clearly was the generic >> ]consensus as >> ] > we have these in a number of protocols. The new reasons to move >> ]from >> ] > that I think are: 1) we no longer need this for debugging purposes >> ] > really since libraries and dev tools have moved on and are better >> ]now, >> ] > and we specifically no longer need these for protocols that are no >> ] > longer new, 2) BCP188 could be considered to argue against having >> ]these >> ] >> ]There are an incredible number of systems (Linux with stock-in-kernel >> ]NETKEY IPsec for instance), where it is impossible or very very >> ]difficult to get a packet capture of the traffic after decryption, but >> ]before it goes up the protocol stack. >> ] >> ]On such systems, if you have a problem in the field with a protocol that >> ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how >> ]it works, and it appears to with without ESP, then the lack of debugging >> ]means that you turn off all security. >> ] >> ]ESP-authenticated-with-NULL-encryption is debuggable in the field. >> ]Not having it, means turning off ESP; and if the problem is in the link >> ]between the ESP layer and the upper layer, then... >> ] >> ]-- >> ]Michael Richardson , Sandelman Software Works -= >> ]IPv6 IoT consulting =- >> ] >> ] >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > Personal email. hbhotz@oxy.edu > > > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------080207070708030309000503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/21/2014 08:51 PM, Henry B Hotz wrote:
The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

In this regard, I have a hard time distinguishing between NULL with HMAC-SHA256 and CMAC or GMAC.

With this (secure communications) context NULL means no privacy but yes authenticity.


Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.


On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:


NULL may be useful to some, but should NOT be mandated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.


Paul

]-----Original Message-----
]From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
]    > Generic: is it still considered a good plan to have null
]    > confidentiality suites such as these? Or for those to be
]    > Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus as
]    > we have these in a number of protocols. The new reasons to move
]from
]    > that I think are: 1) we no longer need this for debugging purposes
]    > really since libraries and dev tools have moved on and are better
]now,
]    > and we specifically no longer need these for protocols that are no
]    > longer new, 2) BCP188 could be considered to argue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but
]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
]it works, and it appears to with without ESP, then the lack of debugging
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link
]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

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

Personal email.  hbhotz@oxy.edu







_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

--------------080207070708030309000503-- From nobody Tue Jul 22 07:45:22 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49C11B2886; Tue, 22 Jul 2014 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 JpNoynHeKD0q; Tue, 22 Jul 2014 07:45:17 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 841321A02D0; Tue, 22 Jul 2014 07:45:17 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5538D62AB3; Tue, 22 Jul 2014 14:45:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VouAOnm--U9; Tue, 22 Jul 2014 10:45:04 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7194662C31; Tue, 22 Jul 2014 10:45:03 -0400 (EDT) Message-ID: <53CE78ED.1030602@htt-consult.com> Date: Tue, 22 Jul 2014 10:45:01 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon , James Cloos References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/VbXA_W1H9GZmxFtx5cFnkHoOkPc Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:45:21 -0000 On 07/22/2014 10:28 AM, Ted Lemon wrote: > On Jul 8, 2014, at 11:06 AM, James Cloos wrote: >> If those doing IP over Amateur Radio are a use case, they require NULL. > If Amateur Radio's prohibition on encryption is considered to be important in making decisions about crypto in protocols, then I think we are in a situation where we can't have crypto protocols that don't disallow downgrade attacks, because implementations always have to be willing to downgrade to no encryption if the other endpoint is an Amateur Radio station. > > So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor. I think the same observation also applies to Michael's comment about debugging on stacks with limited trace capability. If you need to disable encryption, you should have to do something fairly extraordinary to make that happen. It is a switch to request integrity only. Or to only allow integrity only. Either party MUST be able to reject an integrity only negotiation. From nobody Tue Jul 22 07:50:52 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877171B295B; Tue, 22 Jul 2014 07:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 mZ3m49ZCqXxy; Tue, 22 Jul 2014 07:50:43 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA701B2958; Tue, 22 Jul 2014 07:50:43 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 92EB81B83AB; Tue, 22 Jul 2014 07:49:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8C663190060; Tue, 22 Jul 2014 07:49:57 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.169) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 07:49:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <53CE78ED.1030602@htt-consult.com> Date: Tue, 22 Jul 2014 10:49:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.169] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/kkalZ2fbZYJxvvv-2mUwZG6asSg Cc: hipsec@ietf.org, saag@ietf.org, James Cloos Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:50:47 -0000 On Jul 22, 2014, at 10:45 AM, Robert Moskowitz = wrote: > It is a switch to request integrity only. Or to only allow integrity = only. Either party MUST be able to reject an integrity only negotiation. That's not good enough. It should be the case that integrity-only = negotiations are rejected by default, unless there's no protocol = requirement for confidentiality. If there is no need for = confidentiality, then the answer to the DISCUSS should be "there is no = need for confidentiality." From nobody Tue Jul 22 10:17:46 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1633A1B2996; Tue, 22 Jul 2014 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 SXWWg4buSY0a; Tue, 22 Jul 2014 08:25:49 -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 7290F1B297A; Tue, 22 Jul 2014 08:25:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E49552002D; Tue, 22 Jul 2014 11:27:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7A3A63B0E; Tue, 22 Jul 2014 11:25:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 936CC63B0A; Tue, 22 Jul 2014 11:25:48 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/QaCbx4zBJpJ8y6Yl8iV_KrxQWBs X-Mailman-Approved-At: Tue, 22 Jul 2014 10:17:43 -0700 Cc: hipsec@ietf.org, James Cloos , saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:25:58 -0000 --=-=-= Ted Lemon wrote: >> If those doing IP over Amateur Radio are a use case, they require >> NULL. > If Amateur Radio's prohibition on encryption is considered to be > important in making decisions about crypto in protocols, then I think > we are in a situation where we can't have crypto protocols that don't > disallow downgrade attacks, because implementations always have to be > willing to downgrade to no encryption if the other endpoint is an > Amateur Radio station. Ted, you are assuming that there are no policy knobs at all. We are talking about IPsec ESP, as required by HIP, not UTA/TLS here. I don't understand this fear that policy knobs will accidentally get unstuck and start accepting something weaker without administrator involvement. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU86CeoCLcPvd0N1lAQL97QgAupsbjHqEbSp96K8p/PU8HoqMdy1/sg4o CWtQI2Jn3k0yTqVhF7KQ+yO3GY8jFdD/AHig+VgPINk7U5FMECf1xanuHl22nRe3 6sd2awcMajE7pYPQKyUOJ5NfHWAC/CnOobGFcq6MAax8qW951qbwbx+v1KKg7aPb Ee2lm0yEnwve4me+YsyE087brTsPGwLovIqYbb3BtznmhiWwnxyGq8QdJTazvl8I Dv76nPshpKOYnfqg3/O43wV7lFUSFoeZB+EkQ/zPBx71HtXUV4fYopFgjrQeIQoB 8qo5hODdPB62p/TezARPs1AUAUlAUEqCNMKSq+47SzL+jNxoRbs0CA== =QzKA -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 22 10:17:47 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4E1B2980; Tue, 22 Jul 2014 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 qlQmhdtxqGIx; Tue, 22 Jul 2014 08:26:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEE41B2994; Tue, 22 Jul 2014 08:26:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BFFB72002D; Tue, 22 Jul 2014 11:28:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8877363B0E; Tue, 22 Jul 2014 11:26:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7863763B0A; Tue, 22 Jul 2014 11:26:48 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/3tBBfw-UgCfJszu4LhUNn8zBvE0 X-Mailman-Approved-At: Tue, 22 Jul 2014 10:17:43 -0700 Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:26:53 -0000 --=-=-= Ted Lemon wrote: >> It is a switch to request integrity only. Or to only allow integrity >> only. Either party MUST be able to reject an integrity only >> negotiation. > That's not good enough. It should be the case that integrity-only > negotiations are rejected by default, unless there's no protocol > requirement for confidentiality. If there is no need for > confidentiality, then the answer to the DISCUSS should be "there is no > need for confidentiality." All of those knobs, correctly labelled, are all there already. Really. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU86CtYCLcPvd0N1lAQL+gAf/Zp8G6ShHA+ISrVWRGG+k1nlNhSwEdNW8 zv0UtgBvb2VACaOPE6YurI0doR3qcElxafMCg8busY6KSugONzMDLh98asmTZhTM 4dQzmOwFI0Yw5SrKujYPh4J7eKJIafWoQzSQNTRXbGIwhGsxjpNbrlb7EqL4WIuG Hd0AZ0GEVyvuMnCfDtBw4FnwqExv/dqmNl0BLWvScM7YKl4yL+mPJjem7c6bJK3Y HmtPhHSWaP2ZrtPoN+tSApFts3ytbRXYH92jorBIScgIXLkrCMSmcjLobJEasA6l Od/6sgjDMgUTZTXi4mwWIdbpHD8p8SiSXBVqkP6WrdNzzBvwXbdXkg== =YxFv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 22 10:17:48 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8FB1B29A3; Tue, 22 Jul 2014 08:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 RthEHcEJDWuz; Tue, 22 Jul 2014 08:28:54 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F091B29AE; Tue, 22 Jul 2014 08:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=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:mime-version; bh=7VA32uHBSK3Lyt7BcuspCQD1H/xziBCBSZRp6txjSqM=; b=IlkE264z6U0FeKOY0T2Wk3JT45QidOkYuQbjCwv4DG2AmU4FSLSc9AMmqRuIyz9eajExFnCcB4ORvZoNcz0/fynTZlfosEseGNG/Vzi9HsGuq7fHwmYn8/VdLy7H0anmak5+Txtmj2MuMPkFCqkjy35CkCnxLiBUjNwJmjG/HUQKbqFbPxV4fYQEyEtkS3axcdVt3Ay5J19P0cNf5+/Fp4GLspg0TeET0c3mK/h4same3j6z5WnsiHFPBmS02Ml4Ry6jWK3PYMBQyg8KodmLHtjSlSxZBQxbYHL24iA7w7VLbeBxmA3W99Rz+zg1fXV7n7QLP5e7DZzlp+6qbsYVRg== From: Edward Lopez To: "saag@ietf.org" Thread-Topic: [saag] [Hipsec] NULL encryption mode in RFC 5202-bis Thread-Index: AQHPpT+FosFAE5Hfxk6vedbZfWESXpuruOeAgAD1fIA= Date: Tue, 22 Jul 2014 15:28:52 +0000 Message-ID: <3DF58EBF-7AFA-4174-9306-2F38427C0047@fortinet.com> References: <53BB798A.3080101@tomh.org> <53BBC8DE.1010006@cs.tcd.ie> <8171.1404842394@sandelman.ca> <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C4E@SC-VEXCH2.marvell.com> <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> In-Reply-To: <5AE7C4C6-CB51-44EF-A73C-279AC3BC3561@oxy.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.165.97] Content-Type: multipart/alternative; boundary="_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/xkFcRVlyp1l6CkzcbxiloSgCKN8 X-Mailman-Approved-At: Tue, 22 Jul 2014 10:17:43 -0700 Cc: Michael Richardson , Henry B Hotz , "hipsec@ietf.org" Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:28:56 -0000 --_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In my view, the underlying question is concerned with the value of a comm= on encryption algorithm across all implementations of ESP, NULL or otherw= ise. In my experience, the existence of mandatory common denominators in= standards results in improved interoperability between implementations. = In the particular case of ESP, I agree that virtually no one would imple= ment IPSec using NULL encryption, and we heavily rely on de-facto common = use of US NIST-approved protocols (DES, 3DES, AES) for interoperability t= oday. My point is that by removing the MUST requirement for NULL encryption, sh= ould be consider the idea that we are substituting a stated common encryp= tion protocol for a set of implied ones. We will also be eliminating imp= lementation choices over time for those requiring NULL encryption. I=92m not strongly advocating keeping the MUST, and would likely be ok to= replace it with SHOULD. But I did want to state that this surrendering = of an mandated algorithm, and its consequences relative to maintaining in= teroperability, is a factor that I considered. Ed On Jul 21, 2014, at 8:51 PM, Henry B Hotz > wrote: The basic issue, as always, is interoperability. NULL should not be an in= teroperable *operational* capability. Every implementation will have some kind of debugging capability so it ca= n be made operational. Do we require an interoperable debugging capabilit= y? I believe the consensus is already leaning to "no". My own take is that we don't normally do that, and the likely debugging b= enefit of mandating such a thing is insufficient to justify making it a M= UST. On Jul 21, 2014, at 4:57 PM, Paul Lambert > wrote: NULL may be useful to some, but should NOT be mandated (should rather tha= n must). It's another knob that could be set incorrectly and bypass the encryption= . Not all products will want or need NULL. Paul ]-----Original Message----- ]From: Hipsec [mailto:hipsec-bounces@ietf.org] O= n Behalf Of Michael ]Richardson ]Sent: Tuesday, July 08, 2014 11:00 AM ]To: Stephen Farrell ]Cc: hipsec@ietf.org; saag@ietf.org ]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis ] ] ]Stephen Farrell > wrote: ] > Generic: is it still considered a good plan to have null ] > confidentiality suites such as these? Or for those to be ] > Mandatory-To-Implement (MTI)? That clearly was the generic ]consensus as ] > we have these in a number of protocols. The new reasons to move ]from ] > that I think are: 1) we no longer need this for debugging purposes= ] > really since libraries and dev tools have moved on and are better ]now, ] > and we specifically no longer need these for protocols that are no= ] > longer new, 2) BCP188 could be considered to argue against having ]these ] ]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very ]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack. ] ]On such systems, if you have a problem in the field with a protocol that= ]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how= ]it works, and it appears to with without ESP, then the lack of debugging= ]means that you turn off all security. ] ]ESP-authenticated-with-NULL-encryption is debuggable in the field. ]Not having it, means turning off ESP; and if the problem is in the link ]between the ESP layer and the upper layer, then... ] ]-- ]Michael Richardson >= , Sandelman Software Works -=3D ]IPv6 IoT consulting =3D- ] ] _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag Personal email. hbhotz@oxy.edu _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1DF7020E1A0F384BB3E0E2ABF5975AB8@fortinet-us.com> Content-Transfer-Encoding: quoted-printable In my view, the underlying question is concerned with the value of a comm= on encryption algorithm across all implementations of ESP, NULL or otherw= ise.  In my experience, the existence of mandatory common denominato= rs in standards results in improved interoperability between implementations.  In the particular case of ESP, I agree th= at virtually no one would implement IPSec using NULL encryption, and we h= eavily rely on de-facto common use of US NIST-approved protocols (DES, 3D= ES, AES) for interoperability today.

My point is that by removing the MUST requirement for NULL encryptio= n, should be consider the idea that we are substituting a stated common e= ncryption protocol for a set of implied ones.  We will also be elimi= nating implementation choices over time for those requiring NULL encryption.

I=92m not strongly advocating keeping the MUST, and would likely be = ok to replace it with SHOULD.  But I did want to state that this sur= rendering of an mandated algorithm, and its consequences relative to main= taining interoperability, is a factor that I considered.

Ed



On Jul 21, 2014, at 8:51 PM, Henry B Hotz <hbhotz@oxy.edu> wrote:

The basic issue, as always, is interoperability. NULL should not be an in= teroperable *operational* capability.

Every implementation will have some kind of debugging capability so = it can be made operational. Do we require an interoperable debugging capa= bility? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugg= ing benefit of mandating such a thing is insufficient to justify making i= t a MUST.


On Jul 21, 2014, at 4:57 PM, Paul Lambert <paul@marvell.com> wrote:

NULL may be useful to some, but should NOT be m= andated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption= .  Not all products will want or need NULL.


Paul

]-----Original Message-----
]From: Hipsec [mailto:hipsec-bounces@= ietf.org] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: hipsec@ietf.org; saag@ietf.org
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <stephen= .farrell@cs.tcd.ie> wrote:
]    > Generic: is it still considered a good plan to h= ave null
]    > confidentiality suites such as these? Or for tho= se to be
]    > Mandatory-To-Implement (MTI)? That clearly was t= he generic
]consensus as
]    > we have these in a number of protocols. The new = reasons to move
]from
]    > that I think are: 1) we no longer need this for = debugging purposes
]    > really since libraries and dev tools have moved = on and are better
]now,
]    > and we specifically no longer need these for pro= tocols that are no
]    > longer new, 2) BCP188 could be considered to arg= ue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel ]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but ]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that=
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how=
]it works, and it appears to with without ESP, then the lack of debugging=
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link<= br> ]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <mcr&= #43;IETF@sandelman.ca>, Sandelman Software Works  -=3D
]IPv6 IoT consulting =3D-
]
]

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.o= rg/mailman/listinfo/saag

Personal email.  hbhotz@oxy.e= du



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


*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_3DF58EBF7AFA417493062F38427C0047fortinetcom_-- From nobody Tue Jul 22 10:34:46 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEE1B29AD; Tue, 22 Jul 2014 10:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 9IExcdB2Oyxf; Tue, 22 Jul 2014 10:34:40 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id B60441A0330; Tue, 22 Jul 2014 10:34:40 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 47F3062A8E; Tue, 22 Jul 2014 17:34:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcGHMW+zotAV; Tue, 22 Jul 2014 13:34:30 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-97b3.meeting.ietf.org [31.133.151.179]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 758DF62A71; Tue, 22 Jul 2014 13:34:29 -0400 (EDT) Message-ID: <53CEA0A4.7070605@htt-consult.com> Date: Tue, 22 Jul 2014 13:34:28 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Richardson , Ted Lemon References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <53CE78ED.1030602@htt-consult.com> <3737.1406042808@sandelman.ca> In-Reply-To: <3737.1406042808@sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/YQ6yJR2LfQUzqg1KzjHjoXN-vmI Cc: hipsec@ietf.org, saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:34:43 -0000 On 07/22/2014 11:26 AM, Michael Richardson wrote: > Ted Lemon wrote: > >> It is a switch to request integrity only. Or to only allow integrity > >> only. Either party MUST be able to reject an integrity only > >> negotiation. > > > That's not good enough. It should be the case that integrity-only > > negotiations are rejected by default, unless there's no protocol > > requirement for confidentiality. If there is no need for > > confidentiality, then the answer to the DISCUSS should be "there is no > > need for confidentiality." > > All of those knobs, correctly labelled, are all there already. Really. The code has the knobs, but Ted's question is does the spec have the knobs. Something like "default transform lists MUST NOT provide any of the integrity only suites. These MAY be offered only by explicit configuration." This discussion is about NULL which is quite a misnomer... But back in the days......... If you look at the HIP exchange, R1 contains the offered list, and I2 either contains the requested suite, or a counter list. Both are signed (in HIP-BEX) and thus can only be spoofed for anonymous HITs. From nobody Tue Jul 22 10:49:38 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FAF1B2B12; Tue, 22 Jul 2014 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 52-jSX3RlbKX; Tue, 22 Jul 2014 10:49:36 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31E11A00F2; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C584CF8009; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BF31E190060; Tue, 22 Jul 2014 10:49:35 -0700 (PDT) Received: from nat64.meeting.ietf.org (31.130.238.218) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 10:49:35 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <3510.1406042748@sandelman.ca> Date: Tue, 22 Jul 2014 13:49:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <56474639-2BF9-41C0-AC86-CEBB81316D64@nominum.com> References: <53BB798A.3080101@tomh.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com> <3510.1406042748@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.218] Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/UA1tCAmvNUxGZsS3ohYaRX4Oq6U Cc: hipsec@ietf.org, James Cloos , saag@ietf.org Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:49:37 -0000 On Jul 22, 2014, at 11:25 AM, Michael Richardson = wrote: > Ted, you are assuming that there are no policy knobs at all. No, I am assuming that there _are_ policy knobs, and saying what I think = their default values should be. But to be clear, I would expect surfing the web legally over a ham radio = link to be pretty unsatisfying, because you would get no encrypted = content, and lots of content is encrypted. I am saying that this = should not change. From nobody Tue Jul 22 11:51:22 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EB11B2BC5 for ; Tue, 22 Jul 2014 11:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 NenHrYbIbcGe for ; Tue, 22 Jul 2014 11:51:20 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 554AE1B2BC0 for ; Tue, 22 Jul 2014 11:51:16 -0700 (PDT) Received: (qmail 21196 invoked by uid 0); 22 Jul 2014 18:51:15 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Jul 2014 18:51:15 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id VWr41o01J2molgS01Wr7Tb; Tue, 22 Jul 2014 12:51:14 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=ukapeFeQaPAA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=JePZqkDgZHDLM-wJ_8UA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=LyX5C9ybu13/l2A41r/2zAsWOn5uANfI+xO5UFp5ZII=; b=NxKPglTLkrfgZDAW2GSkaFkLs3ABZgK7W+mL1FRy/34rV0nnpUEJi1kwauHwz6QBDTCPr5Lt23CErvJ3LDEFNABBIMTjZYco6ERyzL0/vFALEvoPrmNVpl79Tb4hodcv; Received: from [71.231.123.189] (port=41366 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9f9V-0002wk-Ni; Tue, 22 Jul 2014 12:51:05 -0600 Message-ID: <53CEB296.9050202@tomh.org> Date: Tue, 22 Jul 2014 11:51:02 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: bkhabs@cs.jhu.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/_QVl_OlP4qSE0GYGm3l1elu1s6M Cc: HIP Subject: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:51:21 -0000 Brian, You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis which I would like to address below: > I have no objection to the publication of this document, but I do > have two small points to discuss in section 5.2.3. > > 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but > made mandatory in this revision. However, the text says it SHOULD be > included in R1. If it is not included in R1 (violates the SHOULD), > where will it be included given it is mandatory? Support for it is mandatory (if the Responder sends it, the Initiator must echo it back), but the inclusion by the responder is optional. To try to clarify this, I edited it (for version -15) to read: Support for the R1_COUNTER parameter is mandatory although its inclusion in the R1 packet is optional. It SHOULD be included in the R1 ... > > 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is > that correct? Yes, by making its support mandatory, it is now deemed a "critical" parameter and the LSB of the type value must be 1. This necessitated the change from 128 to 129. Please let us know if you have concerns with the above. - Tom From nobody Tue Jul 22 11:56:51 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBC1A0B11; Tue, 22 Jul 2014 11:56:47 -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 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 YcDjCOs2agf7; Tue, 22 Jul 2014 11:56:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B531A01D6; Tue, 22 Jul 2014 11:56:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722185646.23301.63828.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 11:56:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/EugNWl85D9IYlByjJZJJF3geC2E Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5205-bis-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:56:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol (HIP) Domain Name System (DNS) Extension Author : Julien Laganier Filename : draft-ietf-hip-rfc5205-bis-05.txt Pages : 16 Date : 2014-07-22 Abstract: This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This document obsoletes RFC5205. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5205-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5205-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5205-bis-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 Jul 22 13:04:13 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B492F1A035A for ; Tue, 22 Jul 2014 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 t-wVpb7v2fmt for ; Tue, 22 Jul 2014 13:04:10 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BF21A023E for ; Tue, 22 Jul 2014 13:04:10 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so334982vcb.21 for ; Tue, 22 Jul 2014 13:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WHsNRDn7ntrnoWJtcoKNJcuc9BjkbreR0BZRCpEBBW4=; b=Yr5PidexMb0Ke4ufVmwYfYT80NLoHKY8I1Gn1+V+x2ZB13TuHFahEw36AG8ouZZ9BN j56i2PpsEq84GM6HXOQawJEPfGk/GeNlPKh749W3U+oX7MR2J81f1oG0NXqlC2eN3zHO hi9X6O6Vz8ZFZ1ckF5xX1+wYCTOeWa9vTqU/uuW+9+wFzG4uq4DAEZWHf1pTfIMJZFnV x9WWe3rCXC+NykgPpzNUILDWEmpMidevDrK+DbqPszsHQSR3ODGewVLEUdB2td3ABwrh QUxZyfnec6kaxL4dsMx6AgF3T7z4tEY7Domgh/HlKRvNY+m93+mAsIqQ/aQ+v6be49C2 rBGQ== MIME-Version: 1.0 X-Received: by 10.220.122.132 with SMTP id l4mr43475950vcr.41.1406059449769; Tue, 22 Jul 2014 13:04:09 -0700 (PDT) Received: by 10.52.72.80 with HTTP; Tue, 22 Jul 2014 13:04:09 -0700 (PDT) Date: Tue, 22 Jul 2014 13:04:09 -0700 Message-ID: From: Julien Laganier To: HIP Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/VjY3xovd5alw6KMODV3v1TYAeNE Subject: [Hipsec] FYI: ORCHIDv2 prefix is 2001:20::/28 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:04:11 -0000 Pls. see: http://www.iana.org/assignments/iana-ipv6-special-registry --julien From nobody Tue Jul 22 14:08:45 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4121B2A9F for ; Tue, 22 Jul 2014 14:08:44 -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 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 nk9BRbwysSUn for ; Tue, 22 Jul 2014 14:08:43 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C991B2831 for ; Tue, 22 Jul 2014 14:08:43 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2C20C8810D; Tue, 22 Jul 2014 14:08:43 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D1C5A13680EE; Tue, 22 Jul 2014 14:08:42 -0700 (PDT) Message-ID: <53CED2D3.4040603@innovationslab.net> Date: Tue, 22 Jul 2014 17:08:35 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson References: <53CEB296.9050202@tomh.org> In-Reply-To: <53CEB296.9050202@tomh.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PFcGV7kDKMNQQVTDkC4GueWaGkteKceLo" Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/YzAxhRRoiFZbhzNXAhaiIwiAyJo Cc: HIP Subject: Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:08:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PFcGV7kDKMNQQVTDkC4GueWaGkteKceLo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, On 7/22/14 2:51 PM, Tom Henderson wrote: > Brian, >=20 > You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis > which I would like to address below: >=20 >> I have no objection to the publication of this document, but I do >> have two small points to discuss in section 5.2.3. >> >> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but >> made mandatory in this revision. However, the text says it SHOULD be >> included in R1. If it is not included in R1 (violates the SHOULD), >> where will it be included given it is mandatory? >=20 > Support for it is mandatory (if the Responder sends it, the Initiator > must echo it back), but the inclusion by the responder is optional. >=20 > To try to clarify this, I edited it (for version -15) to read: >=20 > Support for the R1_COUNTER parameter is mandatory although > its inclusion in the R1 packet is optional. It SHOULD be > included in the R1 ... >=20 The above is fine. If this parameter is sent by the Responder, what packets could it be sent in (i.e., violate the SHOULD) and still be usefu= l? The above question is just something for you to think about. I will not hold a discuss on it. >> >> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is >> that correct? >=20 > Yes, by making its support mandatory, it is now deemed a "critical" > parameter and the LSB of the type value must be 1. This necessitated > the change from 128 to 129. >=20 Is there a need to discuss any backwards compatibility issues with this change? Brian --PFcGV7kDKMNQQVTDkC4GueWaGkteKceLo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTztLaAAoJEBOZRqCi7goqqwIH/1t2KrmonIltSoRl4aTHSxUl iPhv+H7ZKYy+fVSZw/F4sRcfVTZytW1KBBCFCiqBPcgo8ybPWrflcROJMUYGRDvZ M4mbnWDNngGOH6yY8F4grHfplqlJzhtcQJtgCzUv3fAmhlhpZh8aTbFFcErvdmYd aRsi3eU4JHyQ23N7DYcEzNUDH9z2npvNJXvsZWeUQKiWp4aYoeGVCjYxEZ2Z87je Jg0NeurJn+rIAS1KYawyuSaMEDxebpivSNjQfGj3XL0FA8mOK0YIhACBFQecdvf3 IRC/3PNfkcdyvbpVmuK/mx7TMac5H6bnAtm4gGdNcx+Uc+6lwXi1igJhvs6Dklw= =yrPI -----END PGP SIGNATURE----- --PFcGV7kDKMNQQVTDkC4GueWaGkteKceLo-- From nobody Tue Jul 22 15:01:31 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8B1A0658 for ; Tue, 22 Jul 2014 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 KbcWvPbuOwer for ; Tue, 22 Jul 2014 15:01:27 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 9F29E1B2CCC for ; Tue, 22 Jul 2014 15:01:27 -0700 (PDT) Received: (qmail 9476 invoked by uid 0); 22 Jul 2014 22:01:26 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Jul 2014 22:01:26 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id Va1L1o00F2molgS01a1PdG; Tue, 22 Jul 2014 16:01:26 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=DGUqPGHPs4YA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=fXNqK_bx-D4pRZfQGIQA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ZWyU8VukjE3qxfsMSa2m0AE52Ah/yBp36HGiMjdLZv4=; b=wzRHA7SjSDZjgLMW9Kt59IYkaWY8EZpZVoq8/oLk4kmpFpKI2TMCXXzA7hK5xUsCOqVd8CitXYcIYkESgtCF6SkVK+FHdPjVyw+3kBD/P1/kycP5FvrPu8VyjxJJ+jfP; Received: from [71.231.123.189] (port=42742 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9i7b-00050n-S4; Tue, 22 Jul 2014 16:01:19 -0600 Message-ID: <53CEDF2D.4000301@tomh.org> Date: Tue, 22 Jul 2014 15:01:17 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Haberman References: <53CEB296.9050202@tomh.org> <53CED2D3.4040603@innovationslab.net> In-Reply-To: <53CED2D3.4040603@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/UCaiw2QzcjiYXBSuYwnDR8B_ZAg Cc: HIP Subject: Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:01:29 -0000 On 07/22/2014 02:08 PM, Brian Haberman wrote: > Hi Tom, > > On 7/22/14 2:51 PM, Tom Henderson wrote: >> Brian, >> >> You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis >> which I would like to address below: >> >>> I have no objection to the publication of this document, but I do >>> have two small points to discuss in section 5.2.3. >>> >>> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but >>> made mandatory in this revision. However, the text says it SHOULD be >>> included in R1. If it is not included in R1 (violates the SHOULD), >>> where will it be included given it is mandatory? >> >> Support for it is mandatory (if the Responder sends it, the Initiator >> must echo it back), but the inclusion by the responder is optional. >> >> To try to clarify this, I edited it (for version -15) to read: >> >> Support for the R1_COUNTER parameter is mandatory although >> its inclusion in the R1 packet is optional. It SHOULD be >> included in the R1 ... >> > > The above is fine. If this parameter is sent by the Responder, what > packets could it be sent in (i.e., violate the SHOULD) and still be useful? > > The above question is just something for you to think about. I will not > hold a discuss on it. R1_COUNTER can be sent in the R1 and I2 packets (Sections 5.3.2 and 5.3.3) but is not found in any of the other packets. > >>> >>> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is >>> that correct? >> >> Yes, by making its support mandatory, it is now deemed a "critical" >> parameter and the LSB of the type value must be 1. This necessitated >> the change from 128 to 129. >> > > Is there a need to discuss any backwards compatibility issues with this > change? > I don't know whether any need exists. If a legacy implementation provides 128, it also likely provides HIP version 1, in which case an ICMP packet with Parameter Problem should be generated (section 5.4.2). If HIP version 2 is indicated but this parameter is encoded with 128, it will probably be covered by an implementation with the INVALID_SYNTAX notification (Section 5.2.19). - Tom From nobody Tue Jul 22 15:03:15 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535601A0658 for ; Tue, 22 Jul 2014 15:03:12 -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 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 ImgJ2b_AP9S1 for ; Tue, 22 Jul 2014 15:03:08 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A101A049F for ; Tue, 22 Jul 2014 15:02:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0347E88118; Tue, 22 Jul 2014 15:02:41 -0700 (PDT) Received: from dhcp-b444.meeting.ietf.org (dhcp-b444.meeting.ietf.org [31.133.180.68]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AE28513680AB; Tue, 22 Jul 2014 15:02:40 -0700 (PDT) Message-ID: <53CEDF80.6040300@innovationslab.net> Date: Tue, 22 Jul 2014 18:02:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tom Henderson References: <53CEB296.9050202@tomh.org> <53CED2D3.4040603@innovationslab.net> <53CEDF2D.4000301@tomh.org> In-Reply-To: <53CEDF2D.4000301@tomh.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LhaImUV07KlGTUCI9UBscNQQJSTlNx6RC" Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/TlZC5bR6oY_bgaZ7mc_lE2vPPZ4 Cc: HIP Subject: Re: [Hipsec] your DISCUSS comments on draft-ietf-hip-rfc5201-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:03:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LhaImUV07KlGTUCI9UBscNQQJSTlNx6RC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tom, The below is all fine with me. I will clear when the updated draft is posted. Regards, Brian On 7/22/14 6:01 PM, Tom Henderson wrote: > On 07/22/2014 02:08 PM, Brian Haberman wrote: >> Hi Tom, >> >> On 7/22/14 2:51 PM, Tom Henderson wrote: >>> Brian, >>> >>> You left the following DISCUSS comments on draft-ietf-hip-rfc5201-bis= >>> which I would like to address below: >>> >>>> I have no objection to the publication of this document, but I do >>>> have two small points to discuss in section 5.2.3. >>>> >>>> 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but= >>>> made mandatory in this revision. However, the text says it SHOULD b= e >>>> included in R1. If it is not included in R1 (violates the SHOULD), >>>> where will it be included given it is mandatory? >>> >>> Support for it is mandatory (if the Responder sends it, the Initiator= >>> must echo it back), but the inclusion by the responder is optional. >>> >>> To try to clarify this, I edited it (for version -15) to read: >>> >>> Support for the R1_COUNTER parameter is mandatory althoug= h >>> its inclusion in the R1 packet is optional. It SHOULD be= >>> included in the R1 ... >>> >> >> The above is fine. If this parameter is sent by the Responder, what >> packets could it be sent in (i.e., violate the SHOULD) and still be >> useful? >> >> The above question is just something for you to think about. I will n= ot >> hold a discuss on it. >=20 > R1_COUNTER can be sent in the R1 and I2 packets (Sections 5.3.2 and > 5.3.3) but is not found in any of the other packets. >=20 >> >>>> >>>> 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is >>>> that correct? >>> >>> Yes, by making its support mandatory, it is now deemed a "critical" >>> parameter and the LSB of the type value must be 1. This necessitated= >>> the change from 128 to 129. >>> >> >> Is there a need to discuss any backwards compatibility issues with thi= s >> change? >> >=20 > I don't know whether any need exists. If a legacy implementation > provides 128, it also likely provides HIP version 1, in which case an > ICMP packet with Parameter Problem should be generated (section 5.4.2).= > If HIP version 2 is indicated but this parameter is encoded with 128, > it will probably be covered by an implementation with the INVALID_SYNTA= X > notification (Section 5.2.19). >=20 > - Tom --LhaImUV07KlGTUCI9UBscNQQJSTlNx6RC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTzt+AAAoJEBOZRqCi7goqn20H/1IUJHUpxahpIb/0CvtROZRj CJoJ5hHUGZkHJ0Qp+nlVGjgCOdlEoUIC8BmUkBRYWwW0mCyXg2bs69Ry/hWJV9pA ZGrGkTgtp0NHO3wh7WpGJTf8/K0+mDemk4mu1wkM/kL8zbtRBQBmt7qwloAs5Jcp ++OVwednMCweDfXscFWEzUHVmgqJxzQlhE6qQWoBS2PmhOvy8laxFV+O5HX+MJBa fhDzkEVUkbjJzH+fKl8urRQaC32+HygjshjpeIFFT7FEt/z5mEArgoFJQUrSgTPJ q1gI1gAQj/KUP0/3ZFU+ah1IyjEyHtTjq+oXk8Mi7TqZXlqA134ixnwUTgbU99w= =Bm8H -----END PGP SIGNATURE----- --LhaImUV07KlGTUCI9UBscNQQJSTlNx6RC-- From nobody Thu Jul 24 08:22:19 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD4F1A040E for ; Thu, 24 Jul 2014 08:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 g80z9XOvDCAq for ; Thu, 24 Jul 2014 08:22:08 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id C4FCE1A0377 for ; Thu, 24 Jul 2014 08:18:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 67D6962A81; Thu, 24 Jul 2014 15:18:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtEjszY47r5k; Thu, 24 Jul 2014 11:18:14 -0400 (EDT) Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id D590C6344A; Thu, 24 Jul 2014 11:18:11 -0400 (EDT) Message-ID: <53D123B2.7000608@htt-consult.com> Date: Thu, 24 Jul 2014 11:18:10 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julien Laganier , HIP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/QMMfgNoO3Q7MAm9nhL-pvrjGGyg Subject: Re: [Hipsec] FYI: ORCHIDv2 prefix is 2001:20::/28 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:22:16 -0000 On 07/22/2014 04:04 PM, Julien Laganier wrote: > Pls. see: > > http://www.iana.org/assignments/iana-ipv6-special-registry I am assuming a different prefix will help interop between HIP and HIPv2. From nobody Thu Jul 24 11:24:32 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCB1B27B5 for ; Thu, 24 Jul 2014 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 XEYQeOYsAxf0 for ; Thu, 24 Jul 2014 11:24:20 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985721B27D8 for ; Thu, 24 Jul 2014 11:24:20 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so5619386vcb.37 for ; Thu, 24 Jul 2014 11:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Of5p3Ww6tklsPCOwT3oDFphOKW9/pZIO6zb2ZFGS7f4=; b=pWU82fAL5vYpRHVAAGGKojhardzbE4+/I+JKUxfJ0W7QeQezhmdwQTXVDjgPlKY2WX BRZzKnATkDVsEPprZtyLlr7okN9Y7EUlcbwHnzDJeH8COOIHF3cCpFn5IYfBPWJDDbtE UHqJXqF0GPYf/2k9cgETpBMqusTbWbrzpihuOPNWo/8d52kl7ZfQTY4lRJ4SzGr2pZfE im8HYe1fdUkBNXTgcyd1wSbu+xyjNwnTgTvM6SvDKD44TSPBHFHXZ2BzWbCXOzmwRb9h qq7uHdHfJjgLl6ESeHkhX1iDe9MIf5JelZ5B/T8Vp0yjwkIFSZTTIiZbaBOddX/RT7ee +wKw== MIME-Version: 1.0 X-Received: by 10.52.239.6 with SMTP id vo6mr12359356vdc.59.1406226258712; Thu, 24 Jul 2014 11:24:18 -0700 (PDT) Received: by 10.52.178.73 with HTTP; Thu, 24 Jul 2014 11:24:18 -0700 (PDT) In-Reply-To: <53D123B2.7000608@htt-consult.com> References: <53D123B2.7000608@htt-consult.com> Date: Thu, 24 Jul 2014 11:24:18 -0700 Message-ID: From: Julien Laganier To: Robert Moskowitz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/YjJIhHn1wQXqbdGLExrUSgrQCXo Cc: HIP Subject: Re: [Hipsec] FYI: ORCHIDv2 prefix is 2001:20::/28 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:24:24 -0000 On Thu, Jul 24, 2014 at 8:18 AM, Robert Moskowitz wrote: > > On 07/22/2014 04:04 PM, Julien Laganier wrote: >> >> Pls. see: >> >> http://www.iana.org/assignments/iana-ipv6-special-registry > > > I am assuming a different prefix will help interop between HIP and HIPv2. We had discussed and concluded on the list that the prefix for ORCHIDv2 had to be different from ORCHIDv1 to allow implementation to differentiate between the two and thus perform adequate calculation. That being said, at this point the prefix for ORCHIDv1 is deprecated - at least from the IANA registry point of view - so eventually we shouldn't see both on the wire anymore. --julien From nobody Mon Jul 28 04:15:26 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1D1A040C; Mon, 28 Jul 2014 04:15:22 -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 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 Q8DyozTdFF-W; Mon, 28 Jul 2014 04:15:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2CC1A014C; Mon, 28 Jul 2014 04:15:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140728111521.20762.32404.idtracker@ietfa.amsl.com> Date: Mon, 28 Jul 2014 04:15:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/Gly4Hy5qP0vvY0yW7Fs7d2_dFxE Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5201-bis-15.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 11:15:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Version 2 (HIPv2) Authors : Robert Moskowitz Tobias Heer Petri Jokela Thomas R. Henderson Filename : draft-ietf-hip-rfc5201-bis-15.txt Pages : 127 Date : 2014-07-23 Abstract: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5201-bis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 28 04:25:01 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508811A03FA; Mon, 28 Jul 2014 04:24:59 -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 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 cg7vb3DJArBG; Mon, 28 Jul 2014 04:24:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51C1A00D5; Mon, 28 Jul 2014 04:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140728112458.20648.66602.idtracker@ietfa.amsl.com> Date: Mon, 28 Jul 2014 04:24:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/tqUGr0rg7tHfbqcXyGZIsUUCz7M Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5202-bis-06.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 11:24:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) Authors : Petri Jokela Robert Moskowitz Jan Melen Filename : draft-ietf-hip-rfc5202-bis-06.txt Pages : 38 Date : 2014-07-28 Abstract: This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5202-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5202-bis-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 Mon Jul 28 15:09:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEAA1A00D7 for ; Mon, 28 Jul 2014 15:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 Y39NMSFunYK1 for ; Mon, 28 Jul 2014 15:09:24 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 3547B1A0080 for ; Mon, 28 Jul 2014 15:09:23 -0700 (PDT) Received: (qmail 19011 invoked by uid 0); 28 Jul 2014 22:09:17 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 28 Jul 2014 22:09:17 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id Xy9D1o00E2molgS01y9GQM; Mon, 28 Jul 2014 16:09:16 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=oPE9Lq-L4dSvQ9dhZUgA:9 a=wPNLvfGTeEIA:10 a=YucXLVEyVCkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=M0b62LaHXfQwmDB+OnsiCYIdzphH8EFacrumRtCK0mc=; b=uo02q+O9CCW5IOidPGGXKzpxUFizuefP/gD19QEHEvwJ0u4IMV1Q1Su64tYf+V+vfkaf3z96pZ66dEEuItuAOBBp5dzXHvN8Xd1dAN5xBLiJSYihUU5tWZQr7SaLhYde; Received: from [71.231.123.189] (port=35072 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XBt6Y-0001Kk-32; Mon, 28 Jul 2014 16:09:14 -0600 Message-ID: <53D6CA07.10604@tomh.org> Date: Mon, 28 Jul 2014 15:09:11 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/rCZJCtwB-gZAuBqOt-a4ki47PfE Cc: The IESG Subject: [Hipsec] HIP draft updates X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:09:26 -0000 (copying also the IESG since we are in IESG evaluation phase) Hi all, Here is an update of RFC5201bis/5202bis status. You may have noticed that RFC5201-bis-15 and RFC5202-bis-06 were published earlier today. For RFC5201-bis, I have tried to log all open issues in the tracker: http://tools.ietf.org/wg/hip/trac/query?component=rfc5201-bis Here is a current rundown: #42, whether to address a possible plaintext attack #44, IANA section updating (I expect to close this soon) #45, better reference needed for RSA algorithm #46, crypto selections for HIP #47, tracking considerations for HIP #48, state transition for CLOSING when new user data arrives to send. #49, resolve Francis Dupont's suggested clarification #50, update Appendix C example (ORCHID prefix and documentation prefix) #48 is a new small issue; I'll start a separate thread about it. #50 also hasn't been discussed on the list, but our example packet in Appendix C needs to be updated. Since -15 was prepared, we've received some more suggested fixes from Barry Leiba for the IANA considerations section, so I plan to publish a version -16 by the end of the week with those corrections and any other updates that we may be able to make by then. For RFC5202bis, the main issue is the recommendation of NULL encryption as a MUST to implement (issue 43). This has been discussed on the saag list and on this list, and I don't think it is yet resolved although I would like to again suggest my proposed resolution: http://www.ietf.org/mail-archive/web/hipsec/current/msg03894.html - Tom From nobody Mon Jul 28 15:14:33 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345401A028E for ; Mon, 28 Jul 2014 15:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 wK3t6WVFfiTI for ; Mon, 28 Jul 2014 15:14:29 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id AC38D1A0262 for ; Mon, 28 Jul 2014 15:14:29 -0700 (PDT) Received: (qmail 27073 invoked by uid 0); 28 Jul 2014 22:14:27 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy3.mail.unifiedlayer.com with SMTP; 28 Jul 2014 22:14:27 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id XyEQ1o00B2molgS01yETxv; Mon, 28 Jul 2014 16:14:27 -0600 X-Authority-Analysis: v=2.1 cv=C4B6l2/+ c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=RtXw21LRRXwA:10 a=q7J0aIbBmN8A:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=L14NvRiGBnYseV-SlMwA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Sl5wIq42e2nL/hfjMx1P+avw5KpgyS66wuTI8DvBZRQ=; b=yxkTbZAvvzNoBIwH4/4RXPMOBUHssSIX5dHn4puhUaVOZ0WRItp+Grb4TWmpvT6xpp0tqXH3OsvM969xowr0EtUoHkQ4bCwEw+TNK4jTTqT+VslM7PUGsJVLiFe9xE+A; Received: from [71.231.123.189] (port=35084 helo=[192.168.168.42]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XBtBX-0006W7-D1 for hipsec@ietf.org; Mon, 28 Jul 2014 16:14:23 -0600 Message-ID: <53D6CB3B.6000503@tomh.org> Date: Mon, 28 Jul 2014 15:14:19 -0700 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 71.231.123.189 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/tmbvYfTtTnX-tmzz0S3aTavaapQ Subject: [Hipsec] transition from CLOSING state to state I1-SENT X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:14:31 -0000 This issue with RFC5201-bis is being tracked as issue 48: http://trac.tools.ietf.org/wg/hip/trac/ticket/48 When a HIP association is in state CLOSING and new data arrives to send to the peer, Table 7 states to send another I1 but stay in CLOSING, while our state machine diagram implies that there is a transition to state I1-SENT. I propose to fix this by changing the Table 7 to read that the state machine transitions to state I1-SENT in this case. Any comments or objections? - Tom From nobody Wed Jul 30 02:39:12 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF81B2A25 for ; Wed, 30 Jul 2014 02:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Gw5lksb-7L68 for ; Wed, 30 Jul 2014 02:39:07 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 346511A0176 for ; Wed, 30 Jul 2014 02:39:06 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 19B5D308748 for ; Wed, 30 Jul 2014 12:39:03 +0300 (EEST) Message-ID: <53D8BD2B.5030100@cs.hut.fi> Date: Wed, 30 Jul 2014 12:38:51 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53D6CA07.10604@tomh.org> In-Reply-To: <53D6CA07.10604@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/EwaIM-scn_SAzXbHmcDXyHsb9ic Subject: Re: [Hipsec] HIP draft updates X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:39:09 -0000 Hi Tom, On 07/29/2014 01:09 AM, Tom Henderson wrote: > > For RFC5202bis, the main issue is the recommendation of NULL encryption > as a MUST to implement (issue 43). This has been discussed on the saag > list and on this list, and I don't think it is yet resolved although I > would like to again suggest my proposed resolution: > http://www.ietf.org/mail-archive/web/hipsec/current/msg03894.html your suggestion works for me. From nobody Wed Jul 30 02:40:21 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4B1B2A69 for ; Wed, 30 Jul 2014 02:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 YquUVRrdEE7z for ; Wed, 30 Jul 2014 02:40:19 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 349671A0176 for ; Wed, 30 Jul 2014 02:40:19 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 5E32130874C for ; Wed, 30 Jul 2014 12:40:18 +0300 (EEST) Message-ID: <53D8BD77.8010004@cs.hut.fi> Date: Wed, 30 Jul 2014 12:40:07 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53D6CB3B.6000503@tomh.org> In-Reply-To: <53D6CB3B.6000503@tomh.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/UW6f_9f1nhCVFFMMoJektV3t2Uw Subject: Re: [Hipsec] transition from CLOSING state to state I1-SENT X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:40:20 -0000 Hi, On 07/29/2014 01:14 AM, Tom Henderson wrote: > This issue with RFC5201-bis is being tracked as issue 48: > http://trac.tools.ietf.org/wg/hip/trac/ticket/48 > > When a HIP association is in state CLOSING and new data arrives to send > to the peer, Table 7 states to send another I1 but stay in CLOSING, > while our state machine diagram implies that there is a transition to > state I1-SENT. > > I propose to fix this by changing the Table 7 to read that the state > machine transitions to state I1-SENT in this case. > > Any comments or objections? seems ok to me. From nobody Wed Jul 30 02:59:33 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2CB1B2A68 for ; Wed, 30 Jul 2014 02:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 nbU3lyVq-SFb for ; Wed, 30 Jul 2014 02:59:30 -0700 (PDT) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBA51A00E7 for ; Wed, 30 Jul 2014 02:59:30 -0700 (PDT) Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id 9ED26308787 for ; Wed, 30 Jul 2014 12:59:29 +0300 (EEST) Message-ID: <53D8C1F7.9070609@cs.hut.fi> Date: Wed, 30 Jul 2014 12:59:19 +0300 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <53C8C557.3070202@tomh.org> <98C8F7AB-D777-428D-B725-2F885EC3893F@comsys.rwth-aachen.de> <53CD9942.9040701@tomh.org> In-Reply-To: <53CD9942.9040701@tomh.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/HGcBMdmBkBHHzsw4uNf3LjsMx08 Subject: Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 09:59:32 -0000 Hi, On 07/22/2014 01:50 AM, Tom Henderson wrote: >> >>> Also - there are no counter modes, is that wise? >> >> HIP DEX defines AES-128-CTR for HIP_CIPHER [3]. However, I just >> realized that it does not specify its use for the ENCRYPTED >> parameter. Instead, the specification focuses on the special-purpose >> ENCRYPTED_KEY parameter. So, some work would be needed to carry this >> over to HIPv2. >> >>> Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but >>> here you have 1 == NULL, yet you deprecate codepoint 3, which is >>> confusing. Why is that? >> >> Is this maybe a specification hiccup? > > I introduced this "DEPRECATED" as part of comment resolutions back in > 2012 (someone in CFRG suggested to drop it), in this post: > > http://www.ietf.org/mail-archive/web/hipsec/current/msg03557.html > > However, HIP_CIPHER is a new parameter, so nothing really needs to be > deprecated. Perhaps "RESERVED" would have been better (or remap > AES-256-CBC to value 3). > > Any concern if I change DEPRECTED to RESERVED and add the comment that > it is unused, such as:? > > Reserved 3 (unused value) > > Or would it be better to just omit the line and skip from 2 to 4? I think either way works. >>> - section 3: 3110 doesn't seem like a great reference for RSA. >>> Isn't there better? >> >> I am not sure what this is referring to. > > I think this refers to the first reference to RSA as an algorithm in > general (in Section 3). Later references use RFC3110 to refer to the > specific encoding defined there, and I think that we need to preserve > those references. So I think Stephen's comment is to replace this > reference in Section 3: > > HIP implementations MUST support the Rivest Shamir Adelman (RSA) > [RFC3110] public key algorithm > > with something else. Any ideas of what to put there? RFC3110 itself > cites Schneier's Applied Cryptography book when referring to RSA. IKEv2 refers to: [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978. [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.