Re: [Gen-art] review of draft-ietf-hip-dex-06.txt

Miika Komu <miika.komu@ericsson.com> Tue, 09 April 2019 20:53 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE206120459; Tue, 9 Apr 2019 13:53:20 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCn4LPwSOxeM; Tue, 9 Apr 2019 13:53:18 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) (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 762E9120456; Tue, 9 Apr 2019 13:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2za4Zzh1Ds2E0JVOn+IBNIgdBYBvqmHCwlQDH0GMuDg=; b=QrHE9Wb925KYGHFVUAXDSO/gLTzhiufxITkA9IxJg00UyoGVky1aXgbUmQL7WyB1nKCArpFutyQu4/OyN8MQUHZnoqrYoJuZ5BS1V98lXeQ4cprQ/R4UHv4cF0ZYqhVtDMBKfxf3Lo65L7qbD40FEIx5bv3lamM+BR9CMvXfBas=
Received: from HE1PR0702MB3786.eurprd07.prod.outlook.com (52.133.7.16) by HE1PR0702MB3627.eurprd07.prod.outlook.com (52.133.6.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Tue, 9 Apr 2019 20:53:14 +0000
Received: from HE1PR0702MB3786.eurprd07.prod.outlook.com ([fe80::5c63:43a2:1c45:bbab]) by HE1PR0702MB3786.eurprd07.prod.outlook.com ([fe80::5c63:43a2:1c45:bbab%4]) with mapi id 15.20.1792.007; Tue, 9 Apr 2019 20:53:14 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "draft-ietf-hip-dex.all@ietf.org" <draft-ietf-hip-dex.all@ietf.org>
CC: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "evyncke@cisco.com" <evyncke@cisco.com>
Thread-Topic: [Gen-art] review of draft-ietf-hip-dex-06.txt
Thread-Index: AQHU7kbjaDoGd+MyDUCMmR97XvWJoaY0T/CA
Date: Tue, 9 Apr 2019 20:53:14 +0000
Message-ID: <a15486708c633c2acb3045a7004ee4f32fa253df.camel@ericsson.com>
References: <c0cdc1d75590599c0a77dd72d768460399c34666.camel@ericsson.com>
In-Reply-To: <c0cdc1d75590599c0a77dd72d768460399c34666.camel@ericsson.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 39857aae-4be8-4fa2-2e35-08d6bd2d62c4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0702MB3627;
x-ms-traffictypediagnostic: HE1PR0702MB3627:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR0702MB3627FC5F0438A69601B9CB43FC2D0@HE1PR0702MB3627.eurprd07.prod.outlook.com>
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(366004)(346002)(136003)(51444003)(189003)(199004)(476003)(81156014)(446003)(68736007)(2501003)(478600001)(118296001)(6916009)(2616005)(76176011)(11346002)(486006)(86362001)(6512007)(6306002)(53936002)(54906003)(5640700003)(305945005)(25786009)(316002)(53546011)(14444005)(256004)(229853002)(44832011)(106356001)(2351001)(66066001)(8676002)(2906002)(71200400001)(71190400001)(5660300002)(50226002)(97736004)(8936002)(7736002)(102836004)(14454004)(6246003)(6116002)(26005)(81166006)(6436002)(4326008)(186003)(6486002)(99286004)(105586002)(6506007)(36756003)(3846002)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3627; H:HE1PR0702MB3786.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Xr00tOALT2vDdANMtXgrCKFN/fqVLZoB3kdf1rPd6qXA+ET8C2PJzjICiYIu0kO6l917HINCSUlfbU3dFUoBDkIMzDcB90AdNWkhJX3bPXGKwTPXnllidPOUGKNqQITdmrLw0JpWQXYDsBTdQ01NNFteBsiDxAmfTvbYUSuHSZIcPWev005hUIP8TREG9X3vvto7zlDGyha1DgTCxZChP5sT3/aBT5f7P4GlCAZoOzUX3+lx/zzExKDY55YL7knu9Tw448HS6evXAhDLYESK6HhNHEmbqZFXCtTZHgzBIyyU+7S9BLjOzBaccR+zRroCQ+f0xgAekegvRzm/0iGgHrfGrzmAyrGXkn1C2Wp+jwMUqf5kJGMOGjZ2RhRFrVh5dL8RWIDjcgnyxdw1spFqnMapmSqP69fJNTrlF7amirM=
Content-Type: text/plain; charset="utf-8"
Content-ID: <183085792C4E1A4C9BA342F90180D4E6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 39857aae-4be8-4fa2-2e35-08d6bd2d62c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 20:53:14.6354 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3627
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vmk8OPIs5SQW5UHtk2PnpbSo1Xc>
Subject: Re: [Gen-art] review of draft-ietf-hip-dex-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 20:53:21 -0000

Hi Francis,

thanks for detailed comments! My comments below.

> Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Tue, 10 April 2018
> 11:39 UTCShow header
> 
> Bob, Rene, could you please get back to Francis (see below)?
> 
> Gonzalo
> 
> On 05/03/2018 1:14 PM, Gonzalo Camarillo wrote:
> > Bob, Rene,
> > 
> > could you please look into the review below and get back to
> > Francis?
> 
> Thanks!
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > On 26/02/2018 7:30 PM, Francis Dupont wrote:
> > > I am the assigned Gen-ART reviewer for this draft. The General
> > > Area
> > > Review Team (Gen-ART) reviews all IETF documents being processed
> > > by the IESG for the IETF Chair.  Please treat these comments just
> > > like any other last call comments.
> > > 
> > > For more information, please see the FAQ at
> > > 
> > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
> > > 
> > > Document: draft-ietf-hip-dex-06.txt
> > > Reviewer: Francis Dupont
> > > Review Date: 20180224
> > > IETF LC End Date: 20180226
> > > IESG Telechat date: unknown
> > > 
> > > Summary: Ready
> > > 
> > > Major issues: None
> > > 
> > > Minor issues: None
> > > 
> > > Nits/editorial comments: 
> > >  - ToC page 3: you use the US spelling of Acknowledgments in the
> > > ToC
> > >   and the English one (acknowledgements) in the technical body.
> > >   Even when it is not very consistent I believe this follows RFC
> 
> 7401
> > >   choice so I am fine with this.

changed to U.S. spelling.

> > >  - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119
> 
> fixing
> > >   the keyword case silly issue.

done

> > >  - 2.2 page 6: perhaps "sort" should be added here?

I replicated the "sort" defition that appears later in the text to here
as well

> > >  - 2.3 page 7 (twice): (c.f.  Section 3)  -> (see Section 3) or
> > >   simply (Section 3)

thanks, fixed using the first expression

> > >  - 4.1.3.2 page 16 (at end of line): e.g. -> e.g.,

fixed

> > >  - 5.3.3 page 25: I don't believe the critical property for
> > >   random value is to be "uniformly distributed" (for instance
> > >   I could have put "unpredictable"). I leave this to the security
> > >   directorate who should propose a better wording if they don't
> > > like
> > >   the current one...

I think this refers to that the probability of each output value from
the random value generator is the same, i.e., no value is "favored"
more than others, which should be a fair assumption for a randomly
generated values

> > >  - 5.3.4 page 26: same comment.

(see above)

> > >  - 6.1 page 27: this section does not really explain what is the
> 
> puzzle
> > >   (it only stands the equation to verify) but I remember the
> 
> explaination
> > >   was before with a reference to 6.1 so I have no concern.

(it was mentioned in section 1.1)

> > >  - 6.2.1 sender 3 page 27: hidden dependency on the sort
> > > definition
> > >   for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is
> 
> after.

Added extra sentence to the third sender step:

3.  Compute the CMAC using either HIP-gl or HIP-lg integrity key
retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers to host
with greater HIT value and HIP-lg refers to the host with smaller HIT
value.

> > >  - 6.3 pages and 30: sort is used page 29 and defined after page
> > > 30,
> > >   this is why IMHO the question to move the definition to 2.2
> 
> notation
> > >   is a good one...

I replicated to section 2.2.

> > >  - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is
> > > bad.
> > >   The text shows it must be ceil(L/(RHASH_len/8)) (vs
> 
> ceil((L/RHASH_len)/8))

good catch, now it is:

N       =  ceil(L/(RHASH_len/8))                                       
                                                                       
                                     

> > >  - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST

fixed as suggested

> > >  - 6.6 1. page 33: the system should process the R1 packet -> or
> 
> SHOULD
> > >   or (I prefer) the system processes the R1 packet

used the latter expression

> > >  - 6.6 8. page 34: The R1 packet may have the A-bit set -> can
> > >   (not better from a language point of view but clearer and BTW
> > >    used for instance in 6.10...)

fixed

> > >  - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf
> 
> 11.)

fixed as suggested

> > >  - 6.7 5. page 36: Otherwise, the system should process the
> > > received
> 
> I2 ->
> > >   or SHOULD or (better) processes (and drop -> drops)

used the latter expression

> > >  - 6.7 15. page 37:
> > >      If the A-bit is set, the Initiator's HIT is anonymous and
> 
> should
> > >      not be stored permanently. -> IMHO SHOULD NOT or directly
> > > MUST
> 
> NOT

used the latter wording

> > >  - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT,
> 
> this
> > >    packet may be an I2 reception acknowledgement of the optional
> > >    -> replace "may be" by "can be" or (better) "is"

used the latter

> > >  - 7 page 40: Please put "If a Responder is not under high load,
> > > #K
> > >    SHOULD be 0." in its own paragraph (i.e. add a break before
> 
> "If").
> > >    It makes clearer this sentence is a requirement when the text
> 
> before
> > >    is the rationale.

done

> > >  - 8 page 40: " either supports HIP DEX or HIPv2 must be able to
> 
> detect"
> > >   -> MUST or "has to"

used the latter

> > >  - 8 pages 40 and 41: I think that the first and last paragraphs
> > > of
> > >   section 8 say the same thing. Should you keep both?

deleted the last paragraph

> > >  - 9 page 41: I'd like to see a formal proof of the DEX protocol.
> > >   I believe you share this wish as you cite SIGMA.

hmm, I don't see the problem here. The text refers HIP BEX as SIGMA,
and tells why HIP DEX is *not* SIGMA compliant: "HIP DEX, however,
replaces the SIGMA-based authenticated Diffie-Hellman key exchange of
HIPv2 with an exchange of random keying material that is encrypted with
a Diffie-Hellman derived key."

> > >  - 9 page 42: I'd like to go further and recommend (lower case)
> > > the
> > >   use of a RNG (vs PRNG) when available (hopefully no longer an
> 
> exception).

I did not find "RNG" from the document

> > >  - 9 page 42: Hence, HIP DEX HITs should not be use -> SHOULD or
> > >   ought to?

I took the liberty to change this to MUST NOT be used