Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)
Hi Miika, Thanks for addressing these comments. Spencer is not serving in the AD role anymore, so I had a quick look at your feedback and believe this all looks good! Regarding the question about SHOULDs: I don’t think it is necessary to go back and compare to RFC7401, however, a less time consuming effort could be to grab for all SHOULDs and shoulds and double-check if a) normative or non normative language should be used and b) if any clarification can or should be added to why this is a SHOULD and not a MUST. However I leave it to you (and the responsible AD) to make the final decision here! Mirja > On 19. Jun 2019, at 14:14, Miika Komu wrote: > > Hi, > > ma, 2018-05-21 kello 17:52 -0700, Spencer Dawkins kirjoitti: >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-hip-dex-06: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ >> >> >> >> --- >> --- >> COMMENT: >> --- >> --- >> >> I'm not an expert on what people expect about security, but I'm >> wondering if >> there's a little too much distance between this text in the Abstract, >> >> This document specifies the Host Identity Protocol Diet EXchange >> (HIP >> DEX), a variant of the Host Identity Protocol Version 2 >> (HIPv2). The >> HIP DEX protocol design aims at reducing the overhead of the >> employed >> cryptographic primitives by omitting public-key signatures and >> hash >> functions. In doing so, the main goal is to still deliver similar >> security properties to HIPv2. >> >> and this text in the Introduction, >> >> The main differences between HIP BEX and HIP DEX are: >> >> (snip) >> >> 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of >> HIPv2 due to the removal of the ephemeral Diffie-Hellman key >> agreement. >> >> Would the average reader consider "no PFS" to be similar to PFS? >> (Please note that I'm not questioning the choice made in DIX, only >> the way that >> choice is described in the Abstract) > > I agree that "similar" is very ambiguous. I have removed the sentence > "In doing so, the main goal is to still deliver similar security > properties to HIPv2" from the abstract (as suggested offline by Eric > Vyncke). I hope this resolves your comment? > >> I'm curious about whether a couple of other differences named in the >> Introduction would also qualify as similar, but let's start with PFS. >> >> I'm also curious about whether >> >> 1.1. The HIP Diet EXchange (DEX) >> >> (snip) >> >> HIP DEX does not have the option to encrypt the Host Identity of >> the >> Initiator in the 3rd packet. The Responder's Host Identity also >> is >> not protected. Thus, contrary to HIPv2, HIP DEX does not provide >> for >> end-point anonymity and any signaling that indicates such >> anonymity >> should be ignored. >> >> qualifies as "similar", but I don't have a good sense of how much >> this matters >> in current and expected HIP deployments. > > the sentence has been removed from the abstract, I hope this point is > also moot now. > >> I'm hardly the smart one about this, but is >> >> o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of >> HIPv2. >> Consequently, if an HI is compromised, all HIP connections >> protected with that HI are compromised. >> >> correct? I was expecting to see something like "if an HI is >> compromised, all >> previous HIP connections protected with that HI are compromised". > > you are correct, fixed. > >> The version of this draft I'm reviewing has 57 occurrences of the >> word >> "should". I'm not seeing very many cases where the surrounding text >> explains >> why an implementation would not do what it SHOULD do, and I'm not >> seeing many >> cases where the surrounding text explains what the peer >> implementation should >> do, if the other endpoint doesn't do what it SHOULD do, although many >> of those >> cases might be captured in the state diagrams in the document. > > many of the SHOULDs are inherited from the text in RFC7401. If you > really want to, I can do a side by side comparison and check which ones > are really new, and then improve the new ones? With my current > priorities at work, this will unfortunately take a lot of time. Another > way to resolve your comment is to add some general statement about the > SHOULDs in the specification. > >> In this text, >> >> By eliminating the need for
Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-dex-06: (with COMMENT)
Hi, ma, 2018-05-21 kello 17:52 -0700, Spencer Dawkins kirjoitti: > Spencer Dawkins has entered the following ballot position for > draft-ietf-hip-dex-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-dex/ > > > > --- > --- > COMMENT: > --- > --- > > I'm not an expert on what people expect about security, but I'm > wondering if > there's a little too much distance between this text in the Abstract, > > This document specifies the Host Identity Protocol Diet EXchange > (HIP >DEX), a variant of the Host Identity Protocol Version 2 > (HIPv2). The >HIP DEX protocol design aims at reducing the overhead of the > employed >cryptographic primitives by omitting public-key signatures and > hash >functions. In doing so, the main goal is to still deliver similar >security properties to HIPv2. > > and this text in the Introduction, > > The main differences between HIP BEX and HIP DEX are: > > (snip) > > 2. HIP DEX forfeits the HIPv2 Perfect Forward Secrecy property of >HIPv2 due to the removal of the ephemeral Diffie-Hellman key >agreement. > > Would the average reader consider "no PFS" to be similar to PFS? > (Please note that I'm not questioning the choice made in DIX, only > the way that > choice is described in the Abstract) I agree that "similar" is very ambiguous. I have removed the sentence "In doing so, the main goal is to still deliver similar security properties to HIPv2" from the abstract (as suggested offline by Eric Vyncke). I hope this resolves your comment? > I'm curious about whether a couple of other differences named in the > Introduction would also qualify as similar, but let's start with PFS. > > I'm also curious about whether > > 1.1. The HIP Diet EXchange (DEX) > > (snip) > >HIP DEX does not have the option to encrypt the Host Identity of > the >Initiator in the 3rd packet. The Responder's Host Identity also > is >not protected. Thus, contrary to HIPv2, HIP DEX does not provide > for >end-point anonymity and any signaling that indicates such > anonymity >should be ignored. > > qualifies as "similar", but I don't have a good sense of how much > this matters > in current and expected HIP deployments. the sentence has been removed from the abstract, I hope this point is also moot now. > I'm hardly the smart one about this, but is > > o HIP DEX lacks the Perfect Forward Secrecy (PFS) property of > HIPv2. > Consequently, if an HI is compromised, all HIP connections > protected with that HI are compromised. > > correct? I was expecting to see something like "if an HI is > compromised, all > previous HIP connections protected with that HI are compromised". you are correct, fixed. > The version of this draft I'm reviewing has 57 occurrences of the > word > "should". I'm not seeing very many cases where the surrounding text > explains > why an implementation would not do what it SHOULD do, and I'm not > seeing many > cases where the surrounding text explains what the peer > implementation should > do, if the other endpoint doesn't do what it SHOULD do, although many > of those > cases might be captured in the state diagrams in the document. many of the SHOULDs are inherited from the text in RFC7401. If you really want to, I can do a side by side comparison and check which ones are really new, and then improve the new ones? With my current priorities at work, this will unfortunately take a lot of time. Another way to resolve your comment is to add some general statement about the SHOULDs in the specification. > In this text, > > By eliminating the need for public-key signatures and the ephemeral >DH key agreement, HIP DEX reduces the computation, energy, > >transmission, and memory requirements for public-key cryptography >^ >(see [LN08]) in the HIPv2 protocol design. Moreover, by dropping > the >cryptographic hash function, HIP DEX affords a more efficient > >protocol implementation than HIP BEX with respect to the >^^^ >corresponding computation and memory requirements. > > is "efficient" the right word, in the second sentence? This seems to > mirror > that "reducing requirements" effect from the first sentence - I'd > assume that > if
