Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi Paul, > The draft lists the following trasforms based on AES cipher: > > AES-GCM > AES-CCM > AES-CTR > AES-128-CBC > AES-GMAC > AES-XCBC-MAC-96 > > All these transforms, except for AES-XCBC-MAC-96, > allows to be used with different key lengths - 128, 192 and 256 bits. > It looks strange to me that, unlike the others, AES-128-CBC > has key length explicitely specified in the draft. Why it differs in > this respect from the others? What about AES-192-CBC and > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) > > I think the draft should either: > - remove explicit key length from AES-128-CBC and make it just AES-CBC > - add explicit key length to all other AES-based transforms (except for > AES-XCBC-MAC-96) > - leave things as is, but explain why AES-CBC differs in this respect > from the others The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. And please, add the same words for 256-bit AES as for 192-bits AES. Regards, Valery. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mar 3, 2014, at 3:04 PM, RJ Atkinson wrote: >> Perhaps some text along the line of: >> >> ESP-NULL offers the same protection as AH, ... > > This sentence above is not true. ESP-NULL and AH provide > different security properties to the IP-layer. The next draft has more careful wording about AH and ESP; we'll ask the WG to check it before passing the draft to Kathleen for IETF Last call. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mar 3, 2014, at 12:02 PM, Valery Smyslov wrote: > The draft lists the following trasforms based on AES cipher: > > AES-GCM > AES-CCM > AES-CTR > AES-128-CBC > AES-GMAC > AES-XCBC-MAC-96 > > All these transforms, except for AES-XCBC-MAC-96, > allows to be used with different key lengths - 128, 192 and 256 bits. > It looks strange to me that, unlike the others, AES-128-CBC > has key length explicitely specified in the draft. Why it differs in > this respect from the others? What about AES-192-CBC and > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) > > I think the draft should either: > - remove explicit key length from AES-128-CBC and make it just AES-CBC > - add explicit key length to all other AES-based transforms (except for > AES-XCBC-MAC-96) > - leave things as is, but explain why AES-CBC differs in this respect from > the others The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit AES MAY be supported for those modes, but the requirements here are for 128-bit AES. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Tue, 4 Mar 2014, RJ Atkinson wrote: What meaning has "protecting" those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not "protected" but the router can't verify the crypto anyway. At least some deployed routers in the middle in some deployments ARE able to validate and therefore trust the AH values (and trust that the IP options present were placed there by the sender). This was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). Some other kinds of middleboxes (e.g. some firewalls) also can do this. I was not aware of such deployments. Thanks for the information. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On 03 Mar 2014, at 17:53 , Paul Wouters wrote: > On Mon, 3 Mar 2014, RJ Atkinson wrote: > >>> ESP-NULL offers the same protection as AH, ... >> >> This sentence above is not true. ESP-NULL and AH provide >> different security properties to the IP-layer. >> >> AH protects all IP options, whereas ESP cannot protect any >> IP options that appear prior to the ESP header -- the location >> in the packet where those IP options are seen *and acted upon* >> by routers/firewalls/etc. > > What meaning has "protecting" those bits? Endpoint A and B protect > something by cryptography, but any router in the middle can't trust > those signatures anyway. So I don't see how AH is different from > ESPinUDP where you set those options in the UDP header. These are > not "protected" but the router can't verify the crypto anyway. At least some deployed routers in the middle in some deployments ARE able to validate and therefore trust the AH values (and trust that the IP options present were placed there by the sender). This was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). Some other kinds of middleboxes (e.g. some firewalls) also can do this. Some AH implementations that support asymmetric keying go back at least 15 years, although those were not standardised back in 1995 -- primarily due to IPR considerations on intermediate authentication (which IPR I believe either has expired or expires very soon). >> Similarly, AH protects many IP header fields from in-transit >> modification, whereas ESP encapsulation provides no protection >> for the 1st (outer) IP header (i.e., that appears before the ESP header). > > So I don't buy that. The IP header is not protecting the packet from > a router, which cannot confirm the crypto of that protection. Some deployed IPv4 routers can confirm the AH authentication information in some deployments. This has been true for years. Note that RFC-1826, Section 1.1, contains explicit discussion of the applicability of AH with asymmetric algorithms to enable intermediate authentication. > What this > is really about is exposing things like QoS bits, No. IETF standards say that the IP ToS/DiffServ bits are allowed to be modified in-transit. For example see Section 7.2 of RFC-2474 & also page 10 of RFC-2402. > but those devices > acting on those are not verifying any "protection". They are blindly > using the exposed options. So ESPinUDP works equally well here. No. >> As a prior discussion has noted, AH can and is used to provide >> cryptographic protection to some security-critical IP options >> (e.g. sensitivity labels). ESP-NULL is not capable of protecting >> those options. > > I'm not sure what you are referring to here. Not labeled IPsec I > take it? And again, how does this "protection" work? How do the > routers verify this "protection" when only the endpoints know > the crypto keys used to protect the header and payload? As an example, one can have (and real deployments exist) where an IPv4 sensitivity label (e.g. FIPS-188) in an IPv4 packet is protected by AH, using asymmetric cryptography, where both end systems and also intermediate label-policing IP routers can validate the digital signatures carried by AH to validate that the sensitivity label has not been tampered with since it was placed in the packet by the sender. Not all deployments where FIPS-188 is in use also use/deploy AH for protection, but some FIPS-188 deployments definitely do. - ESP-in-UDP can NOT do this. - ESP-NULL can NOT do this in any other way either. > Can you explain how this protection works? If an AH packet flies by, > and I change the QoS option from off to on to give my packet preference > in the network, how will the next router notice this and ignore > this QoS option? As noted above, the IP ToS/DiffServ byte explicitly is excluded from AH protection, originally because some deployed routers were known to change the field in-transit (RFC-2402) and later (after RFC-2474) because IETF standards explicitly say that modifying that field in-transit is allowed. >> Some deployments definitely do care. Other deployments do not. > > By understanding was always that people didn't like options getting > "lost" or "hidde" within the ESP payload, and not getting set on > the outer packet. While some people might have that view, that never has been a universal view. Broadly speaking, the primary case against using any IP option is that *historically* the presence of an IP option in an IP packet caused that packet to be forwarded on the "slow path" of many commercial IP routers. That is not necessarily the case today, although it reportedly still is the case for some products. A commercial router vendor that I worked a decade ago for shipped silicon that could fast-path, at wire-speed, for then high-speed interfaces (i.e., 10 Gbps) packets containing options -- simply because the silicon included logic to parse around the option to
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
HI Tero, Hmm... actually we should most like use the same names we use in the IANA registry. Agree, this would make things more clear. I think the best is to say that in general with AES encryption (GCM, CBC, CCM etc) we assume the key length is 128-bits. (i.e. the And don't forget about GMAC. MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is also for 128-bit keys with x octect ICV). I also think this is the best way. I listed the other two just for completeness. Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mon, 3 Mar 2014, RJ Atkinson wrote: ESP-NULL offers the same protection as AH, ... This sentence above is not true. ESP-NULL and AH provide different security properties to the IP-layer. AH protects all IP options, whereas ESP cannot protect any IP options that appear prior to the ESP header -- the location in the packet where those IP options are seen *and acted upon* by routers/firewalls/etc. What meaning has "protecting" those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not "protected" but the router can't verify the crypto anyway. Similarly, AH protects many IP header fields from in-transit modification, whereas ESP encapsulation provides no protection for the 1st (outer) IP header (i.e., that appears before the ESP header). So I don't buy that. The IP header is not protecting the packet from a router, which cannot confirm the crypto of that protection. What this is really about is exposing things like QoS bits, but those devices acting on those are not verifying any "protection". They are blindly using the exposed options. So ESPinUDP works equally well here. As a prior discussion has noted, AH can and is used to provide cryptographic protection to some security-critical IP options (e.g. sensitivity labels). ESP-NULL is not capable of protecting those options. I'm not sure what you are referring to here. Not labeled IPsec I take it? And again, how does this "protection" work? How do the routers verify this "protection" when only the endpoints know the crypto keys used to protect the header and payload? The reason AH is MAY is that not all deployments care about protecting the (outer) IP header and (visible to the forwarding plane) IP options. Can you explain how this protection works? If an AH packet flies by, and I change the QoS option from off to on to give my packet preference in the network, how will the next router notice this and ignore this QoS option? Some deployments definitely do care. Other deployments do not. By understanding was always that people didn't like options getting "lost" or "hidde" within the ESP payload, and not getting set on the outer packet. In fact, with KLIPS we had an option that could copy some of the header bits into the outer IP header. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Mon, 3 Mar 2014, Tero Kivinen wrote: Hmm... actually we should most like use the same names we use in the IANA registry. For example we have 3 different types of AES-GCM: 18 AES-GCM with a 8 octet ICV[RFC4106] [RFC5282] 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] Which one of those is the one that is moved to SHOULD+? Should we just pick one of them, and say that it is the one we prefer, or should all implementations implement all of them? AES-CCM has similar thing, but as they are moving to MAY it does not really matter. Actually yes. I talked to one of the authors of RFC 4106, John Viega, a while ago and he said: "Some people seemed to think embedded devices would want to use truncated tags. in this day in age, I would recommend AGAINST tag truncation" So I would be happy to only move ID 20 to SHOULD+ and actually demote 18 and 19. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Valery Smyslov writes: > The draft lists the following trasforms based on AES cipher: > > AES-GCM > AES-CCM > AES-CTR > AES-128-CBC > AES-GMAC > AES-XCBC-MAC-96 > > All these transforms, except for AES-XCBC-MAC-96, > allows to be used with different key lengths - 128, 192 and 256 bits. > It looks strange to me that, unlike the others, AES-128-CBC > has key length explicitely specified in the draft. Why it differs in > this respect from the others? What about AES-192-CBC and > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) Hmm... actually we should most like use the same names we use in the IANA registry. For example we have 3 different types of AES-GCM: 18 AES-GCM with a 8 octet ICV[RFC4106] [RFC5282] 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] Which one of those is the one that is moved to SHOULD+? Should we just pick one of them, and say that it is the one we prefer, or should all implementations implement all of them? AES-CCM has similar thing, but as they are moving to MAY it does not really matter. And yes, I agree the AES-128-CBC should be changed to AES-CBC. In the RFC4305 and RFC4835 we had text like "AES-CBC with 128-bit keys", but as we now have more AES modes, we should probably just add text saying that for 128-bit keys for AES is MUST. Also for AES-GMAC we need to decide which of the ones we are saying is SHOULD+: 9 AUTH_AES_128_GMAC [RFC4543] 10 AUTH_AES_192_GMAC [RFC4543] 11 AUTH_AES_256_GMAC [RFC4543] > I think the draft should either: > - remove explicit key length from AES-128-CBC and make it just > AES-CBC > - add explicit key length to all other AES-based transforms (except for > AES-XCBC-MAC-96) AES-XCBC-MAC-96 is always defined to be have 128-bit key. The key length cannot be negotiated when using the authentication algorithm, it can only be negotiated for the encryption keys. Thats why the AUTH_AES_*_GMAC authentication algorithms are defined as 3 different algorithms. > - leave things as is, but explain why AES-CBC differs in this respect from > the others I think that is bad idea. I think the best is to say that in general with AES encryption (GCM, CBC, CCM etc) we assume the key length is 128-bits. (i.e. the MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is also for 128-bit keys with x octect ICV). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
> Perhaps some text along the line of: > > ESP-NULL offers the same protection as AH, ... This sentence above is not true. ESP-NULL and AH provide different security properties to the IP-layer. AH protects all IP options, whereas ESP cannot protect any IP options that appear prior to the ESP header -- the location in the packet where those IP options are seen *and acted upon* by routers/firewalls/etc. Similarly, AH protects many IP header fields from in-transit modification, whereas ESP encapsulation provides no protection for the 1st (outer) IP header (i.e., that appears before the ESP header). As a prior discussion has noted, AH can and is used to provide cryptographic protection to some security-critical IP options (e.g. sensitivity labels). ESP-NULL is not capable of protecting those options. The reason AH is MAY is that not all deployments care about protecting the (outer) IP header and (visible to the forwarding plane) IP options. Some deployments definitely do care. Other deployments do not. Yours, Ran ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi, I have mostly no problem with the document. However I have one small concern. The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) - leave things as is, but explain why AES-CBC differs in this respect from the others Regards, Valery Smyslov. - Original Message - From: "Yaron Sheffer" To: "ipsec" Sent: Tuesday, February 25, 2014 10:48 PM Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels. Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Yaron Sheffer writes: > +1 on making single-DES CBC a MUST NOT. Agree on that. (And I still need to read the whole document, I am way too much behind with my IPsecME WG draft reading). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Paul, On Wed, 26 Feb 2014, Valery Smyslov wrote: It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Why did we not kill AH all together when Schneier and Ferguson told us so? :P But you are right. Perhaps some text along the line of: perhaps because they were wrong. ESP-NULL offers better performance than AH and so it is desirable in most cases. But, AH has been specified by some protocols and we don't want to undermine their choice by killing it. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Paul, On Feb 25, 2014, at 8:48 PM, Yaron Sheffer wrote: Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) I think we do want folks to migrate from AH to ESP/NULL. That's why we made support for AH a MAY a while ago. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Wed, 26 Feb 2014, Valery Smyslov wrote: It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Why did we not kill AH all together when Schneier and Ferguson told us so? :P But you are right. Perhaps some text along the line of: ESP-NULL offers the same protection as AH, but is more widely accepted and functional compared to AH. AH does not work through NATs and is not implemented in every IPsec stack. AH requires firewall rules different from ESP causing it to get accidentally filtered. ESP-NULL is also used in performance testing as a benchmark against ESP encryption algorithms. ESP-NULL should never be automatically selected as part of IKE unless explicitely configured as the only ESP encryption algorithm. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
(Hats off) +1 on making single-DES CBC a MUST NOT. Yaron Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi Paul, It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this explicitly in section 3. I don't think it is limited for those systems only. You may implement AH, but yon cannot use it everywhere, as it is not compatible with NATs. And ESP-NULL with Auth is the only substitute there. So, it must be MUST for any system. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Feb 25, 2014, at 4:50 PM, Paul Wouters wrote: >>> Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can >>> think of for this is when we use a combined mode algorithm like AES-GCM. >>> But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be >>> SHOULD+ as well? >> >> That's covered in Section 3. The tables are the raw list of requirements; >> their use is covered in Section 3. > > That still does not address my point. If AES-GCM is rated FOO, then per > definition since it uses ESP auth NULL, that ESP auth NULL should also > be rated FOO. Right now AES-GCM is SHOULD+ and ESP auth NULL is MAY. This seems to be calling for a relational table that I think is beyond where we want to go. If someone implements AES-GCM and doesn't implement ESP-NULL, Section 3 covers that. >>> I'm also confused >>> why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. >> >> I just checked, and I think the table of changes is correct. Which do you >> think is missing? > > AES-CCM, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ? AES-CCM is MAY in both documents AES-128-CBC is MUST in both documents DES-CBC is now under discussion HMAC-SHA1-96 is MUST in both documents NULL is MAY in both documents So, I'm still confused. >>> Section 3 states: >>> >>> If authentication on the IP header is needed in conjunction with >>> confidentiality of higher-layer data, then AH SHOULD be used in >>> addition to the transforms recommended above. >>> >>> How does AH protect the confidentiality of "higher-layer data" ? >> >> It does not, of course. I think this sentence was trying to be about "if the >> higher-layer data already has its own confidentiality, then you can add AH". >> I think the sentence should be removed because it assumes that the device >> adding authentication knows whether or not the higher-layer service is using >> confidentiality correctly, and it can't know this. > > To me it seemed that "AH" needed to be "ESP"? Even then, the sentence is about "the higher-layer data already has its own confidentiality", which I think is unknowable by an ESP or AH implementation. I think the sentence can safely be removed. > >>> Seciont 4: >>> >>> The text about "The Triple Data Encryption Standard (TDES) is obsolete" >>> appears twice and could be consolidated? >> >> The second one is about DES. :-) > > No higher up :) > > Section 3: > > Triple-DES SHOULD NOT be used in any scenario in which multiple > gigabytes of data will be encrypted with a single key. As a 64-bit > block cipher, it leaks information about plaintexts above that > "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement > for the sake of backwards compatibility, but its use is discouraged. > > Seciont 4.2: > > The Triple Data Encryption Standard (TDES) is obsolete because of its > small block size; as with all 64-bit block ciphers, it SHOULD NOT be > used to encrypt more than one gigabyte of data with a single key > [M13]. Its key size is smaller than that of the Advanced Encryption > Standard (AES), while at the same time its performance and efficiency > is worse. Thus, its use in new implementations is discouraged. I admit that "usage guidance" and "rationale" overlap, but I think having the "please rethink 3DES" discussion twice is a positive. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Tue, 25 Feb 2014, Paul Hoffman wrote: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this explicitly in section 3. Ahh, I'm okay with that if we can make that clarification. Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. Good. Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can think of for this is when we use a combined mode algorithm like AES-GCM. But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be SHOULD+ as well? That's covered in Section 3. The tables are the raw list of requirements; their use is covered in Section 3. That still does not address my point. If AES-GCM is rated FOO, then per definition since it uses ESP auth NULL, that ESP auth NULL should also be rated FOO. Right now AES-GCM is SHOULD+ and ESP auth NULL is MAY. Section 2.5: I would put 2.5 as the introduction paragraph to 2.1. Bike shed. Sure :) It just seems that the 2.5 listing is the essential core of the document. I'm fine if you prefer green. I'm also confused why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. I just checked, and I think the table of changes is correct. Which do you think is missing? AES-CCM, AES-128-CBC, DES-CBC, HMAC-SHA1-96, NULL ? Section 3 states: If authentication on the IP header is needed in conjunction with confidentiality of higher-layer data, then AH SHOULD be used in addition to the transforms recommended above. How does AH protect the confidentiality of "higher-layer data" ? It does not, of course. I think this sentence was trying to be about "if the higher-layer data already has its own confidentiality, then you can add AH". I think the sentence should be removed because it assumes that the device adding authentication knows whether or not the higher-layer service is using confidentiality correctly, and it can't know this. To me it seemed that "AH" needed to be "ESP"? Seciont 4: The text about "The Triple Data Encryption Standard (TDES) is obsolete" appears twice and could be consolidated? The second one is about DES. :-) No higher up :) Section 3: Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key. As a 64-bit block cipher, it leaks information about plaintexts above that "birthday bound" [M13]. Triple-DES CBC is listed as a MAY implement for the sake of backwards compatibility, but its use is discouraged. Seciont 4.2: The Triple Data Encryption Standard (TDES) is obsolete because of its small block size; as with all 64-bit block ciphers, it SHOULD NOT be used to encrypt more than one gigabyte of data with a single key [M13]. Its key size is smaller than that of the Advanced Encryption Standard (AES), while at the same time its performance and efficiency is worse. Thus, its use in new implementations is discouraged. Section 4.3: This section is the only section that mentions MD5 and SHA1. Perhaps it should summarize or refer to RFC 4835? I think it is better to make this document obsolete 4835 and keep the negative text. Fine with me, Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Feb 25, 2014, at 3:09 PM, Paul Wouters wrote: >> On Feb 25, 2014, at 8:48 PM, Yaron Sheffer wrote: >> >> Hi, this is to start a 2-week working group last call on the revised >> Algorithm Implementation Requirements >> document, ending March 11. The draft is at: >> http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We >> should have last called the draft a while ago, and I apologize for the >> delay. > > Section 2.2: > > It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old > crypto export restrictions? While I think NULL ESP is a good debugging > tool, and a good replacement for AH in general, I don't think this is > really a MUST item (unless you would actually advise people to migrate > from AH to ESP NULL, in which case I'll cheer on this MUST) It is for systems that don't implement AH. We should probably say this explicitly in section 3. > Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane > modern IKE daemon that allows 1DES (or modp768) The WG has never voiced a MUST NOT for this before. I'm fine with making that change if no one objects. > Section 2.3: > > This does not list anything with md5. Is there another RFC that already > discourages this use for IPsec? If so, can it be references in this > document. If not, shouldn't we talk about an HMAC-MD5 downgrade to > SHOULD NOT+ ? HMAC-MD5 still gives 128 bits of strength, which in fact is more than the MUST-level HMAC-SHA1-96. It was a MAY in 4835; by not listing it here, it is still "MAY". > [ Turns out that document is RFC 4835, but only mentioned at the > end. Should this document not Obsolete: 4835? ] This document should indeed obsolete 4835. Good catch. > Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can > think of for this is when we use a combined mode algorithm like AES-GCM. > But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be > SHOULD+ as well? That's covered in Section 3. The tables are the raw list of requirements; their use is covered in Section 3. > Section 2.5: > > I would put 2.5 as the introduction paragraph to 2.1. Bike shed. > I'm also confused > why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. I just checked, and I think the table of changes is correct. Which do you think is missing? > Should > they be added with "-" in the Old Requirement, and their listing in the > New Requirement? No, this is a table of differences. > Section 3 states: > > If authentication on the IP header is needed in conjunction with > confidentiality of higher-layer data, then AH SHOULD be used in > addition to the transforms recommended above. > > How does AH protect the confidentiality of "higher-layer data" ? It does not, of course. I think this sentence was trying to be about "if the higher-layer data already has its own confidentiality, then you can add AH". I think the sentence should be removed because it assumes that the device adding authentication knows whether or not the higher-layer service is using confidentiality correctly, and it can't know this. > Seciont 4: > > The text about "The Triple Data Encryption Standard (TDES) is obsolete" > appears twice and could be consolidated? The second one is about DES. :-) > Section 4.3: > > This section is the only section that mentions MD5 and SHA1. Perhaps it > should summarize or refer to RFC 4835? I think it is better to make this document obsolete 4835 and keep the negative text. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer wrote: Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. Section 2.2: It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old crypto export restrictions? While I think NULL ESP is a good debugging tool, and a good replacement for AH in general, I don't think this is really a MUST item (unless you would actually advise people to migrate from AH to ESP NULL, in which case I'll cheer on this MUST) Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane modern IKE daemon that allows 1DES (or modp768) Section 2.3: This does not list anything with md5. Is there another RFC that already discourages this use for IPsec? If so, can it be references in this document. If not, shouldn't we talk about an HMAC-MD5 downgrade to SHOULD NOT+ ? [ Turns out that document is RFC 4835, but only mentioned at the end. Should this document not Obsolete: 4835? ] Why is ESP auth NULL a MAY instead of a MUST NOT? The only reason I can think of for this is when we use a combined mode algorithm like AES-GCM. But in that case if AES-GCM is SHOULD+ it requires ESP auth null to be SHOULD+ as well? Section 2.5: I would put 2.5 as the introduction paragraph to 2.1. I'm also confused why the entries in 2.2 and 2.3 do not appear in the 2.5 summary. Should they be added with "-" in the Old Requirement, and their listing in the New Requirement? Section 3 states: If authentication on the IP header is needed in conjunction with confidentiality of higher-layer data, then AH SHOULD be used in addition to the transforms recommended above. How does AH protect the confidentiality of "higher-layer data" ? Seciont 4: The text about "The Triple Data Encryption Standard (TDES) is obsolete" appears twice and could be consolidated? Section 4.3: This section is the only section that mentions MD5 and SHA1. Perhaps it should summarize or refer to RFC 4835? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi I think this document is ready. A quick glance at the tables in section two lead me to ask some questions: Why is DES singled out, while things like HMAC-MD5 are not discouraged? Why is there no algorithm diversity? Why is HMAC-SHA-256 not there? However, reading section 4 answered all of those questions, so I think it’s clear. The only nit I can find is that “+” means “in the future this will be more encouraged”, and “-“ means “in the future this will be less encouraged, except for “SHOULD NOT+”. It might be more consistent if that was called “SHOULD NOT-“. But that is nit-picking, as the text does explain what that means. Yoav On Feb 25, 2014, at 8:48 PM, Yaron Sheffer wrote: > Hi, this is to start a 2-week working group last call on the revised > Algorithm Implementation Requirements document, ending March 11. The draft is > at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should > have last called the draft a while ago, and I apologize for the delay. > > The changes from the existing requirements are listed in Sec. 2.5 of the > draft, but most of this (rather short) document is new and describes the > rationale for the choice of algorithms and requirement levels. > > Please read this draft and send any comments to the WG mailing list, even if > the comments are "I see no problems". Comments such as "I do not understand > this part" or "this part could be explained better in this way" are > particularly useful at this point. > > Thanks, >Yaron > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi, this is to start a 2-week working group last call on the revised Algorithm Implementation Requirements document, ending March 11. The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should have last called the draft a while ago, and I apologize for the delay. The changes from the existing requirements are listed in Sec. 2.5 of the draft, but most of this (rather short) document is new and describes the rationale for the choice of algorithms and requirement levels. Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
