Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt
> On Apr 28, 2015, at 2:49 AM, Paul Wouters wrote: > > On Tue, 28 Apr 2015, Yoav Nir wrote: > >> This is actually quite unfortunate text. Fields must be aligned to block >> size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 >> bytes would be totally arbitrary, yet that is what the MUST requirement in >> the first bullet seems to be saying. I don’t even know what “proper >> alignment” means for a cipher such as this. If anything is proper alignment, >> then the value that fulfills the SHOULD requirement is zero (with no padding >> bytes). For section 3, I could add a text that echoes the second bullet: >> >> The sender SHOULD include no padding and set the Pad Length field to zero. >> The receiver MUST accept any length of padding. >> >> Sounds good? > > Not really? > > Choices like that make me nervous that an attacker can tweak the padding > option. Who knows what oracle that can become in the future. There MUST > only be one way to do things. So I would rather see: > > The sender MUST NOT include padding and set the Pad Length field to > zero. The receiver MUST reject a non-zero Pad Length field. I’m OK with that as well, (though I would phrase it in the positive “The sender MUST include no padding and set …”), but that goes against RFC 7296. Specifically your second sentence turns a “MUST accept” into a “MUST reject”. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt
On Tue, 28 Apr 2015, Yoav Nir wrote: This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is what the MUST requirement in the first bullet seems to be saying. I don’t even know what “proper alignment” means for a cipher such as this. If anything is proper alignment, then the value that fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, I could add a text that echoes the second bullet: The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding. Sounds good? Not really? Choices like that make me nervous that an attacker can tweak the padding option. Who knows what oracle that can become in the future. There MUST only be one way to do things. So I would rather see: The sender MUST NOT include padding and set the Pad Length field to zero. The receiver MUST reject a non-zero Pad Length field. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305
> On Apr 27, 2015, at 6:25 PM, Michael Richardson wrote:
>
>
> I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then found
> that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to better
> understand the questions in para 2 of the security considerations, the
> question about the uniqueness the nonce, so my initial reading, being
> mostly ignorant about ChaCha and Poly1305 was very confusing.
>
> (In preparing this email, I was also using the -05 document, which I see is
> new. I think that I read -03 on Friday. -04 seems to have been skipped?)
>
> I had not yet read any of the discussion on the list (intentionally) so as
> to judge whether I understood the document on it's own.
>
> {in preparing this email, I read the thread afterwards, and I now see that
> some discussion was previously about IV being derived from replay counter, a
> notion which I think has been removed from the ID. I don't think that I have
> any new questions; I think that after having read the document well, that
> I can implement from the documents as they are}
>
> I don't understand:
>> As the ChaCha20 block function is not applied directly to the
>> plaintext, no padding should be necessary. However, in keeping with
>
> could this be a typo ChaCha20 vs Poly1305?
> If the encryption algorithm is now applied directly, then what is?
> Or is meant that the block function for ChaCha20 used only to generate
> bits for a stream cipher, and the XOR is what is "applied directly”?
Yeah, perhaps I didn’t phrase it the best way. If you’re using AES and you have
a 19-byte plaintext and you’re using ECB (or CBC) you can encrypt the first
16-byte block of the plaintext, but for the second block you only have 3 bytes,
whereas AES requires 16. So you need to pad. With CTR, CCM, GCM you encrypt a
counter, which is always 16 bytes, Since you’re not applying AES to the
plaintext (but to a counter) you don’t need to pad the plaintext - you just
throw away the extra bytes of XOR mask that you created.
ChaCha20 is the same: you generate a 64-byte block from a key, a nonce and a
counter, and you XOR as much of it as you need with the plaintext - so no pad
is needed.
>> The same key and nonce, along with a block counter of zero are passed
>> to the ChaCha20 block function, and the top 256 bits of the result
>> are used as the Poly1305 key. The nonce passed to the block
>> function here is the same nonce that is used in ChaCha20, including the
>> 32-bit
>> Salt, and the key passed is the same as the encryption key.
>
> I think that if I have a block encryption function, that I need to encrypt
> something to get an output. I don't know what that is here
> Later I understood from reading cfrg-chacha20 that the ChaCha20 block
> function acts as a prng, and that's why this is a stream ciper, not a block
> cipher. The use of the term "block function" here was confusing to me.
It’s not that different from AES-GCM. With AES-GCM (or just CTR) you have a
128-bit counter (actually it’s just a 32-bit counter as 96-bits are the
per-packet nonce). You encrypt the counter and get a 16-byte block that you XOR
with the plaintext.
With ChaCha20-Poly1305 you also have a 128-bit counter with 96 fixed bits. You
run the ChaCha20 block function to generate a 64-byte block that you XOR with
the plaintext.
The only difference is that the size of the counter is not the same as the size
of the output block.
This is different from a real stream cipher where a single key with no nonce
can generate an arbitrary length byte stream. ChaCha20 can only produce 64
bytes from a single value of the nonce.
> At first, I understand the nonce, was going to be the IV. Was there some
> discussion/options in a previous version of the draft?
> I initially understood that the the 32-bit block counter would be taken from
> the replay counter, but now I see that this is incorrect, that it's unrelated
> to the replay counter, and that I misunderstood at first.
>
> So the Salt is really part of the key material. We have a 36-byte key. It
> matters to people debugging things with a tool like TCPDUMP, that they know
> they
> should expect 36-bytes.
>
> Is this diagram correct:
>
> keymat:iv: ctr:
> +---++ ++ ++
> |01234567890123456789012|0123| |abcdefgh| |0001|
> +---++ ++ ++
>| | | |
>| | | |
>| | | |
> key:Vnonce: V block V
> +---+ ++ ctr:++
> |01234567890123456789012| |0123abcdefgh| |00xx|
> +---+ ++ ++
>words: 4-11words: 13-15 word 12
>
> \-\ /\/-
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
OK. Make those changes. I’ll post a new version tomorrow. Yoav > On Apr 27, 2015, at 12:38 PM, Yaron Sheffer wrote: > > Clearly we need to mention that the IV is included, despite the text of RFC > 7296. > > You are right about SK_ei/er. The second bullet in Sec. 3 should not mention > KEYMAT, which is unrelated, and maybe should mention SK_ei/er. > > Thanks, > Yaron > > On 04/27/2015 11:38 AM, Yoav Nir wrote: >> >>> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer wrote: >>> >>> I am still a bit confused about Sec. 3 (use in IKEv2): >>> >>> - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that >>> the IV is included explicitly, and where exactly it should go? >> >> It says that the IV is 64-bit, same as in section 2, and RFC 7296 section >> 3.14 says that the IV is explicit. Although in honesty, it also says that >> the size of the IV is equal to block length, which would make it 512 bits >> here? Anyway, RFC 7296 does say that this is true only for CBC. >> >>> - In the bullet that describes the IV, I would add text that the IKE >>> Message ID is not an option, and why. >> >> The whole idea of using sequence number as IV is now gone from the draft. If >> we want to add some path-not-taken text, it should probably go in the >> Security Considerations or maybe another appendix. I don’t really think it >> is relevant. >> >>> - How do we make sure that the key/IV combination is unique between >>> Initiator and Responder? >> >> PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator >> and responder respectively. Each is 36 octets (288 bits). While we don’t >> explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs >> hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same >> SKEYID_e is used by both. >> >>> Thanks, >>> Yaron >>> >>> On 04/27/2015 01:44 AM, Paul Hoffman wrote: Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups: - Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery. - Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us. It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future. --Paul Hoffman >>> >>> ___ >>> 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] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt
Hi, Martin. See inline. > On Apr 27, 2015, at 2:02 PM, Martin Willi wrote: > > Yoav, > >> Oh, and one more thing: I’d really appreciate it if somebody checked my >> examples. All I can be sure of is that they work in my code. > > I've hit two issues when verifying the IKEv2 example in our code: > > > From appendix B: > >> Padding as required by RFC 7296 is 4 bytes long. > > Do we have such a padding requirement for IKEv2? For ChaCha20 we have no > requirement for input lengths, so no padding is needed. While we have 4 > byte padding in ESP, I don't think this is true for IKEv2 Encrypted > Payloads, is it? > > From RFC 7296 3.14: > >> o Padding MAY contain any value chosen by the sender, and MUST have >> a length that makes the combination of the payloads, the Padding, >> and the Pad Length to be a multiple of the encryption block size. >> This field is encrypted with the negotiated cipher. >> >> o Pad Length is the length of the Padding field. The sender SHOULD >> set the Pad Length to the minimum value that makes the combination >> of the payloads, the Padding, and the Pad Length a multiple of the >> block size, but the recipient MUST accept any length that results >> in proper alignment. This field is encrypted with the negotiated >> cipher. > > So while the used padding is not invalid, it is not what we SHOULD use, > and if so probably not a good example. Maybe we should also add a note > about IKEv2 padding to section 3? This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is what the MUST requirement in the first bullet seems to be saying. I don’t even know what “proper alignment” means for a cipher such as this. If anything is proper alignment, then the value that fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, I could add a text that echoes the second bullet: The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding. Sounds good? > > > > The other issue I've seen is about the Next Payload: > >> Encrypted Payload: >> 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 ...,a..p > > The Next Payload field in the Encrypted Payload is 0. However, RFC 7296 > defines: > >> Next Payload - The payload type of the first embedded payload. > > So I think Next Payload should be Notify (0x29). Yes, you’re right. I’ve fixed this in my working draft. I should publish again in a day or two. Thanks. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
Thanks. I’ve fixed this in my working draft of -06, which should be published soon. Yoav > On Apr 27, 2015, at 1:05 PM, Doyle, Stephen wrote: > > In the ESP Example in Appendix A, the 'Next Header' field is missing from the > ESP Trailer portion of the plaintext. > > Regards, > Steve > -- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > > > ___ > 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] Please review draft-ietf-ipsecme-chacha20-poly1305
I read draft-ietf-ipsecme-chacha20-poly1305 on Friday last, and then found
that I needed to further review draft-nir-cfrg-chacha20-poly1305-06 to better
understand the questions in para 2 of the security considerations, the
question about the uniqueness the nonce, so my initial reading, being
mostly ignorant about ChaCha and Poly1305 was very confusing.
(In preparing this email, I was also using the -05 document, which I see is
new. I think that I read -03 on Friday. -04 seems to have been skipped?)
I had not yet read any of the discussion on the list (intentionally) so as
to judge whether I understood the document on it's own.
{in preparing this email, I read the thread afterwards, and I now see that
some discussion was previously about IV being derived from replay counter, a
notion which I think has been removed from the ID. I don't think that I have
any new questions; I think that after having read the document well, that
I can implement from the documents as they are}
I don't understand:
> As the ChaCha20 block function is not applied directly to the
> plaintext, no padding should be necessary. However, in keeping with
could this be a typo ChaCha20 vs Poly1305?
If the encryption algorithm is now applied directly, then what is?
Or is meant that the block function for ChaCha20 used only to generate
bits for a stream cipher, and the XOR is what is "applied directly"?
> The same key and nonce, along with a block counter of zero are passed
> to the ChaCha20 block function, and the top 256 bits of the result
> are used as the Poly1305 key. The nonce passed to the block
> function here is the same nonce that is used in ChaCha20, including the
> 32-bit
> Salt, and the key passed is the same as the encryption key.
I think that if I have a block encryption function, that I need to encrypt
something to get an output. I don't know what that is here
Later I understood from reading cfrg-chacha20 that the ChaCha20 block
function acts as a prng, and that's why this is a stream ciper, not a block
cipher. The use of the term "block function" here was confusing to me.
At first, I understand the nonce, was going to be the IV. Was there some
discussion/options in a previous version of the draft?
I initially understood that the the 32-bit block counter would be taken from
the replay counter, but now I see that this is incorrect, that it's unrelated
to the replay counter, and that I misunderstood at first.
So the Salt is really part of the key material. We have a 36-byte key. It
matters to people debugging things with a tool like TCPDUMP, that they know they
should expect 36-bytes.
Is this diagram correct:
keymat:iv: ctr:
+---++ ++ ++
|01234567890123456789012|0123| |abcdefgh| |0001|
+---++ ++ ++
| | | |
| | | |
| | | |
key:Vnonce: V block V
+---+ ++ ctr:++
|01234567890123456789012| |0123abcdefgh| |00xx|
+---+ ++ ++
words: 4-11words: 13-15 word 12
\-\ /\/-/
\/ \ /
| ctr=0 \/ 64-byte chunks prng
|||
||^^xor^ --< plaintext+padding+NH
| replay# ||
| spi#+--+
| | | cipher |
| | /--<--| text |
| | | +--+
| | | |
| | | |
V V V |
/--\|
| Poly1305 ||
| algo ||
\--/|
V V
++
|MIC |
++
I am very very very happy that cfrg-chacha20 has so many examples in it.
That's really awesome.
It wasn't until I read all of cfrg-chacha20 that I understood that the
Poly1305 needs to seeded for *each* packet. I also think that the Poly1305
is not used in an HMAC construction.
I think that the IANA considerations of ipsecme-chacha20-poly1305 should say
something like,
"According to cfrg-chacha20, Poly-1305 is not suitable for
use as a PRF for IKEv2, and this specification explicitely
does not allocate a code point for that."
=
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00
Yoav Nir wrote: > Second issue is about UI advice. Some implementations (yes, mine is > included) allow the user to configure encryption algorithm, MAC > algorithm, and D-H group. There is no setting for PRF since such UIs > date back to IKEv1. The PRF is usually just taken from the setting for > MAC algorithm. This works fine as long as all supported MAC algorithms > are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC > 5282 makes no mention of this issue. I’m wondering if we should > recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256. So, in this case, if you wanted to not change your UI, maybe you would tell the user to configure encryption-algorithm=Chacha20-Poly1305 MAC=HMAC-SHA2 DH=whatever the MAC would not apply to IPsec at all? I guess if we are deploying this algorithm with the concern that HMAC-SHA2/AES might become weak, that it would seem odd to depend upon SHA2 as the PRF. At least, users might not understand. (noting that SHA2 != HMAC-SHA2, and also that the inputs to the PRF as not very easily manipulated...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305
Tero Kivinen wrote: > What I proposed earlier was that we define that chacha20 uses explicit > IV, but the IV is always generated as running counter incremented by > one. > In normal case the IV is sent inside the both IKEv2 and ESP packets. > In ESP the sequence number is used normally for replay protection. > Then we could create new "ESP Sequence number + IV compression" > protocol, that would negotiate the support for this in the IKEv2 for > ESP, and if enabled by both ends, then they would set the ESP sequence > number and chacha20 IV to be linked, i.e. they would always be same, > and then we could compress one of them away after the encryption, and > decompress them back in place before decryption. That's an interesting proposal. It seems excessively modular to me, but I'm willing to listen more to why it makes sense. Are there actually IKE daemons that use the IPsec code to do their decryption? I can see how this might happen in IoT space.. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305
Valery Smyslov wrote: > I agree that it is better to have a single mechanism for TLS and IPsec. > However I doubt if TLS WG would take into considerations our problems, > when making its own decision. On the other hand I think that implicit > IV is unacceptable for us (at least for IKE). Whatever problems we have with an implicit IV in ESP will also be felt by DTLS. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt
Yoav, > Oh, and one more thing: I’d really appreciate it if somebody checked my > examples. All I can be sure of is that they work in my code. I've hit two issues when verifying the IKEv2 example in our code: >From appendix B: > Padding as required by RFC 7296 is 4 bytes long. Do we have such a padding requirement for IKEv2? For ChaCha20 we have no requirement for input lengths, so no padding is needed. While we have 4 byte padding in ESP, I don't think this is true for IKEv2 Encrypted Payloads, is it? >From RFC 7296 3.14: >o Padding MAY contain any value chosen by the sender, and MUST have > a length that makes the combination of the payloads, the Padding, > and the Pad Length to be a multiple of the encryption block size. > This field is encrypted with the negotiated cipher. > >o Pad Length is the length of the Padding field. The sender SHOULD > set the Pad Length to the minimum value that makes the combination > of the payloads, the Padding, and the Pad Length a multiple of the > block size, but the recipient MUST accept any length that results > in proper alignment. This field is encrypted with the negotiated > cipher. So while the used padding is not invalid, it is not what we SHOULD use, and if so probably not a good example. Maybe we should also add a note about IKEv2 padding to section 3? The other issue I've seen is about the Next Payload: > Encrypted Payload: > 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 ...,a..p The Next Payload field in the Encrypted Payload is 0. However, RFC 7296 defines: > Next Payload - The payload type of the first embedded payload. So I think Next Payload should be Notify (0x29). Kind Regards Martin ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
In the ESP Example in Appendix A, the 'Next Header' field is missing from the ESP Trailer portion of the plaintext. Regards, Steve -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
Clearly we need to mention that the IV is included, despite the text of RFC 7296. You are right about SK_ei/er. The second bullet in Sec. 3 should not mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er. Thanks, Yaron On 04/27/2015 11:38 AM, Yoav Nir wrote: On Apr 27, 2015, at 10:46 AM, Yaron Sheffer wrote: I am still a bit confused about Sec. 3 (use in IKEv2): - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go? It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 says that the IV is explicit. Although in honesty, it also says that the size of the IV is equal to block length, which would make it 512 bits here? Anyway, RFC 7296 does say that this is true only for CBC. - In the bullet that describes the IV, I would add text that the IKE Message ID is not an option, and why. The whole idea of using sequence number as IV is now gone from the draft. If we want to add some path-not-taken text, it should probably go in the Security Considerations or maybe another appendix. I don’t really think it is relevant. - How do we make sure that the key/IV combination is unique between Initiator and Responder? PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and responder respectively. Each is 36 octets (288 bits). While we don’t explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used by both. Thanks, Yaron On 04/27/2015 01:44 AM, Paul Hoffman wrote: Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups: - Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery. - Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us. It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future. --Paul Hoffman ___ 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] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
> On Apr 27, 2015, at 10:46 AM, Yaron Sheffer wrote: > > I am still a bit confused about Sec. 3 (use in IKEv2): > > - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the > IV is included explicitly, and where exactly it should go? It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 says that the IV is explicit. Although in honesty, it also says that the size of the IV is equal to block length, which would make it 512 bits here? Anyway, RFC 7296 does say that this is true only for CBC. > - In the bullet that describes the IV, I would add text that the IKE Message > ID is not an option, and why. The whole idea of using sequence number as IV is now gone from the draft. If we want to add some path-not-taken text, it should probably go in the Security Considerations or maybe another appendix. I don’t really think it is relevant. > - How do we make sure that the key/IV combination is unique between Initiator > and Responder? PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and responder respectively. Each is 36 octets (288 bits). While we don’t explicitly prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used by both. > Thanks, > Yaron > > On 04/27/2015 01:44 AM, Paul Hoffman wrote: >> Greetings again. This begins the two-week WG Last Call on >> draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would >> love to hear from people in either of two groups: >> >> - Those who have already reviewed an earlier version of this draft. Please >> re-read the draft now, and let us know if it is perfect, or if there >> anything else you want added or changed. This includes Yaron, PaulW, Tero, >> ScottF, and Valery. >> >> - Those who have *not* yet reviewed this draft, but want to help the IETF >> create good standards in this area. If you are an IPsec implementer, or know >> one at your organization, reviewing this draft and sending any comments to >> the list (even just "seems fine" or "I liked it except this one thing") is >> useful to all of us. >> >> It seems very likely that this new algorithm combination will appear in >> IKEv2 and ESP soon, and having folks give a bit more review will help >> prevent whoopsies in the future. >> >> --Paul Hoffman >> > > ___ > 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] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11
I am still a bit confused about Sec. 3 (use in IKEv2): - Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the IV is included explicitly, and where exactly it should go? - In the bullet that describes the IV, I would add text that the IKE Message ID is not an option, and why. - How do we make sure that the key/IV combination is unique between Initiator and Responder? Thanks, Yaron On 04/27/2015 01:44 AM, Paul Hoffman wrote: Greetings again. This begins the two-week WG Last Call on draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love to hear from people in either of two groups: - Those who have already reviewed an earlier version of this draft. Please re-read the draft now, and let us know if it is perfect, or if there anything else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and Valery. - Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft and sending any comments to the list (even just "seems fine" or "I liked it except this one thing") is useful to all of us. It seems very likely that this new algorithm combination will appear in IKEv2 and ESP soon, and having folks give a bit more review will help prevent whoopsies in the future. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
