I’ve been looking at the history of TLS interop issues. It seems that the one constant is that anything that doesn’t change all the time is surprising, and for anything surprising there are implementations that die on receiving it: - If the version field has always been 0x0300 or 0x0301 and somebody suddenly sends 0x0302 some implementation will close the connection even though the spec for 0301 was explicit on how to handle this. - If a 16-bit length field describes the ClientHello message that is always under 256 octets, the higher length octet is always zero. When it suddenly became 1 some implementation closed the connection.
So what can we take away from this to IKE? Perhaps the principle of “Don’t be surprising on the Internet”. Since the publication of RFC 4306 we’ve added one exchange type, but we negotiate its use so it’s not surprising. We’ve added two payload types, but their use is also negotiated. Same is true for ID types. A few other extensions assume support on both sides and happily fail otherwise. We’ve added no transform types and no transform attributes. The only things that we routinely surprise peers with are new notifications and new algorithms or transform IDs. So if our main goal is to reduce surprising interoperability failures, we should probably negotiate this with either notifications or transform IDs. The question is, of course, which is uglier: negotiation with notifications, or duplicating transform IDs. I tend to think the former is uglier, but it kind of resembles the way TFC is negotiated or non-first fragments. Yoav > On 10 Jun 2016, at 7:28 PM, Tommy Pauly <[email protected]> wrote: > > Here are my thoughts on the options for communicating the Implicit IV option > in the proposal: > > - A new transform type is problematic, as pointed out by Valery and Paul > already, because it adds complexity to the proposal structure for configuring > and parsing. This seems to be the least desirable option. > > - The new transform ID is easy to add to implementations because it is just > another value for an existing field. There is a slight downside in needing > new ID allocations for what will be essentially a duplicate algorithm, but > numbers are cheap. I think this is the easiest option to adopt and pass > between implementation layers (userspace, kernel, etc), but once the layer > doing encryption is using the value, it will probably want to flatten the > information out into the original algorithm value and a flag that the IV is > implicit. > > - A new transform attribute is attractive as a clean protocol design, since > it seems to be the type of information that transform attributes are meant to > hold. There aren't many uses of transform attributes currently, so this may > add work to protocol parsers. This may require passing the flag for implicit > IVs separately throughout the implementation, rather than as part of the > transform ID, but I would be willing to do this as an implementer for the > sake of a cleaner protocol. > > As such, I vote for either option 2 or 3: 2 for ease of implementation, 3 for > clean protocol design. > > Thanks, > Tommy > >> On Jun 9, 2016, at 9:19 AM, Daniel Migault <[email protected]> >> wrote: >> >> Hi, >> >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. >> >> We would be happy to have the WG opinion on which you think is the better >> way to negotiate the implicit IV between two peers. The different options >> are detailed in section 5 and copy paste here in the email: >> >> """ >> Negotiation of the use of implicit IV can be done in 3 different >> ways: >> >> o An IMPLICIT IV Transform Type. A proposal that contains this >> transform type requires (if accepted) that IPsec use the implicit >> IV and not include an explicit IV in the packets. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another proposal that does not include this >> transform type as well as cryptographic suite the Initiator does >> not support the implicit IV. >> >> o An IMPLICIT IV Transform ID. This doubles the number of ENCR >> transform IDs by creating an ENCR_AES_CCM_16_IIV for each >> ENCR_AES_CCM_16. >> >> o An IMPLICIT IV Transform Attribute, which would be associated to a >> Transform Type ID, specifying the use of an implicit IV. marks a >> particular ENCR transform as using implicit IVs. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another ENCR transform for each algorithm so >> marked. In other words, for each ENCR_AES_CCM_16 with >> keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16 >> with keylength=256 and no IIV attribute. >> >> """ >> >> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Thursday, June 09, 2016 12:12 PM >> To: Tobias Guggemos; Yoav Nir; Daniel Migault >> Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt >> >> >> A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt >> has been successfully submitted by Daniel Migault and posted to the IETF >> repository. >> >> Name: draft-mglt-ipsecme-implicit-iv >> Revision: 00 >> Title: Implicit IV for Counter-based Ciphers in IPsec >> Document date: 2016-06-09 >> Group: Individual Submission >> Pages: 7 >> URL: >> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 >> >> >> Abstract: >> IPsec ESP sends an initialization vector (IV) or nonce in each >> packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- >> CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not >> require an unpredictable nonce. When using such algorithms the >> packet counter value can be used to generate a nonce, saving 8 octets >> per packet. This document describes how to do this. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
