[IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

gt; > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > >Title : ChaCha20, Poly1305 and their use in IPsec >

Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

Seeing as none of the transform names begins with “ESP_” and that we’re specifying the algorithm for IKE as well as ESP, I’ve changed the identifier to ENCR_ChaCha20_Poly1305. Yoav > On Mar 31, 2015, at 12:15 PM, Yoav Nir wrote: > > One more thing. > > I would like to req

Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

> On Mar 31, 2015, at 5:03 PM, Paul Wouters wrote: > > On Tue, 31 Mar 2015, Yoav Nir wrote: > >> Seeing as none of the transform names begins with “ESP_” and that we’re >> specifying the algorithm for IKE as well as ESP, I’ve changed >> the identifier to E

Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt)

OK, so this thread kind of got side-tracked about the name of the algorithm. I think ENCR_CHACHA20_POLY1305 works for everybody. What about early code point assignment? Thanks Yoav > On Mar 31, 2015, at 12:15 PM, Yoav Nir wrote: > > One more thing. > > I would like to req

Re: [IPsec] ChaCha20/Poly1305 padding (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.txt)

> On Apr 1, 2015, at 3:37 PM, Martin Willi wrote: > > Hi, > > In Section 2, draft-ietf-ipsecme-chacha20-poly1305-01 has the following > text: > >> o Finally, the Poly1305 function is run on the data to be >> authenticated, which is, as specified in section 2.7 of >> [chacha_poly]

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

> On Mar 31, 2015, at 1:49 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> First is the nonce/IV question: In the current draft, there is a >> 64-bit IV with guidance not to repeat them (so use a counter or >> LFSR). The function itself accepts a 96-bit inpu

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

> On Mar 30, 2015, at 8:42 PM, Scott Fluhrer (sfluhrer) > wrote: > > > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir > Sent: Monday, March 30, 2015 10:40 AM > To: internet-dra...@ietf.org > Cc: ipsec@ietf.org; i-d-

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-02.txt

ernet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > >Title : ChaCha20, Poly1305 and their use in IKE & IPsec >Author : Yoav Nir > Filename: dr

Re: [IPsec] mot sure if this posted before, so resending

> On Apr 6, 2015, at 10:07 PM, Stephen Kent wrote: > > Yoav, > >> Hi, >> >> There is two questions I would like guidance from the group about. >> >> First is the nonce/IV question: In the current draft, there is a 64-bit IV >> with guidance not to repeat them (so use a counter or LFSR). The

Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

Hi, Valery. Thanks for the review. See my reply inline. > On Apr 21, 2015, at 7:19 PM, Valery Smyslov wrote: > > Hi, > > this is my review of draft-ietf-ipsecme-chacha20-poly1305-02. > > I think that the draft is in a good shape. A few issues need to be resolved. > > > > Technical issues.

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > >Title : ChaCha20, Poly1305 and their use in IKE & IPsec >Author : Yoav Nir > Filename: draft-ietf-ipsecme-chacha20-poly1305-03.txt >

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

Replying to myself to prevent others from sending messages to the internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir wrote: Hi This new version closes (I think) all the open issues. I have removed all references to GDOI as it has been pointed out that GDOI allocated

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

And adding the [1]… On Apr 25, 2015, at 12:27 PM, Yoav Nir wrote: Replying to myself to prevent others from sending messages to the internet-drafts and i-d-announce. On Apr 25, 2015, at 12:25 PM, Yoav Nir wrote: Hi This new version closes (I think) all the open issues. I have removed all

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-03.txt

Will do, although 4106 doesn’t have any either. Yoav > On Apr 25, 2015, at 5:54 PM, Paul Hoffman wrote: > > On Apr 25, 2015, at 2:27 AM, Yoav Nir wrote: >> With this I believe the document is ready for WGLC. I might want to add an >> appendix with an example. > >

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt

is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > >Title : ChaCha20, Poly1305 and their use in IKE & IPsec >Author : Yoav Nir &g

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-04.txt

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. Yoav > On Apr 26, 2015, at 11:50 PM, Yoav Nir wrote: > > Hi. > > At Paul’s request I have added examples in appendix A and appendix B. > &g

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

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 >

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 cod

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

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 abo

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 > qu

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 w

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-06.txt

t; This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > >Title : ChaCha20, Poly1305 and their use in IKE & IPsec >Author : Yoav Nir > Filename: draft-ietf-ipsecme-chacha20-poly130

Re: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305

> On Apr 28, 2015, at 4:09 PM, Michael Richardson wrote: > > > Yoav Nir wrote: >>> Is this diagram correct: > > some comment on the accuracy of my diagram would be appreciated :-) I’ll get to that later. > >>> I think that the IANA considerations

Re: [IPsec] My comments to draft-ietf-ipsecme-chacha20-poly1305-06

Thanks, Tero. Fixed in -07 Yoav > On May 4, 2015, at 6:19 PM, Tero Kivinen wrote: > > I have now read the latest draft-ietf-ipsecme-chacha20-poly1305-06 and > it seems to be ok. I have few nits that could be fixed, and and one > real mistake: > > -

[IPsec] Restarting the discussion about the puzzle

Hi. As a reminder, there were two concerns about the difficulty of puzzles: • That some clients are weaker than others and therefore are able to try less keys in a unit of time • That individual puzzles might prove more difficult than other puzzles, so some “unlucky” initiators m

Re: [IPsec] Restarting the discussion about the puzzle

> On May 9, 2015, at 7:32 PM, Yaron Sheffer wrote: > > Hi Yoav, > > First, I raised a third concern, which is that allowing the client to decide > on the difficulty of the puzzle it is willing to solve adds unneeded > complexity. Basically the client doesn't have enough information to make a

Re: [IPsec] New Version Notification - draft-ietf-ipsecme-chacha20-poly1305-08.txt

Hi I have just uploaded version -08. The only difference from version -07 is changing the reference for the algorithm document from draft-irtf- to RFC 7539. Yoav > On May 14, 2015, at 12:24 AM, internet-dra...@ietf.org wrote: > > > A new version (-08) has been submitted for > draft-ietf-ipse

Re: [IPsec] How to negotiate a new capability with parameters

Hi, Frederic That sounds mostly correct. In IKEv1 capabilities were usually declared in VendorIDs. In IKEv2 they are mostly declared in notifications within IKE_SA_INIT. Why the difference? No idea. It’s just the way other extensions were done, but with a private extension you can do either.

[IPsec] Question about PFS in IKEv2

Hi This may have been discussed before, but I haven’t found such discussion. Apologies in advance if this is a stupid question. Suppose we have to VPN peers configured to set up a tunnel between them. Suppose further that the IKE SAs are significantly longer-lived than the IPsec SAs. PFS is c

Re: [IPsec] Question about PFS in IKEv2

Hi, Vijay. Thanks for the response. > On May 28, 2015, at 12:38 PM, vijay kn wrote: > > The only problem I see is if the Gw-1 rekeyed with group19 but GW2 does not > support Group19 then it can result in traffic loss. For this, the > administrators of the two devices must ensure that the othe

Re: [IPsec] Question about PFS in IKEv2

> On May 28, 2015, at 1:40 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> When the tunnel is first set up, it is negotiated in the IKE_AUTH >> exchange. Diffie-Hellman is not performed, so the mismatched >> configuration is not detected - traffic flows through the tu

Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

Hi, Kathleen. Please see below > On Jun 6, 2015, at 1:19 AM, Kathleen Moriarty > wrote: > > Hi, > > Sorry this took me a bit of time to get to, I wanted to read through some of > the background materials first and have been a bit swamped lately (should > clear up soon). Anyway, I have a fe

[IPsec] Fwd: New Version Notification for draft-nir-ipsecme-curve25519-00.txt

e-curve25519-00.txt > Date: June 11, 2015 at 11:01:26 AM GMT+3 > To: "Yoav Nir" , "Simon Josefsson" > , "Yoav Nir" , "Simon Josefsson" > > > > A new version of I-D, draft-nir-ipsecme-curve25519-00.txt > has been successfully submitt

Re: [IPsec] AD review of draft-ietf-ipsecme-chacha20-poly1305-08

> On Jun 12, 2015, at 10:08 PM, Kathleen Moriarty > wrote: > > Hi Yoav, > > Once again, sorry for the delay! My schedule should start to get better in a > couple of weeks. > > On Sat, Jun 6, 2015 at 6:03 PM, Yoav Nir <mailto:ynir.i...@gmail.com>> wr

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

afts >> directories. >> This draft is a work item of the IP Security Maintenance and Extensions >> Working Group of the IETF. >> >> Title : ChaCha20, Poly1305 and their use in IKE & IPsec >> Author : Yoav Nir >> Filename

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

Done. > On Jun 14, 2015, at 8:57 PM, Yaron Sheffer wrote: > > Sure. > > On 06/14/2015 02:11 PM, Yoav Nir wrote: >> How about: >> >> OLD: >>The Pad Length field need not exceed 4 octets. However, RFC 4303 and this >> specification do

Re: [IPsec] nat traversal and transport mode

Hi. Transport mode works fine behind NAT devices. For example, L2TP clients connect to VPN gateways using transport mode and they work behind NAT devices. It is AH that cannot work behind NAT. HTH Yoav > On Jun 16, 2015, at 2:34 PM, Michał Zegan wrote: > > -BEGIN PGP SIGNED MESSAGE---

Re: [IPsec] nat traversal and transport mode

> On Jun 16, 2015, at 4:44 PM, Paul Wouters wrote: > > On Tue, 16 Jun 2015, Yoav Nir wrote: > >> Transport mode works fine behind NAT devices. For example, L2TP clients >> connect to VPN gateways using transport mode and they work behind NAT >> devices. &g

Re: [IPsec] draft-ietf-ipsecme-chacha20-poly1305

Hi, Kathleen. The sentences in question are the ones that get modified after IANA assignment. We’ve asked for early assignment. If we get it (hint, hint, Tero) I’ll update these sentences (“… MUST use 31, the identifier assigned by IANA to …”). If not, then the RFC editor makes these edits anyw

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-02.txt

uted Denial of Service Attacks > Authors : Yoav Nir > Valery Smyslov > Filename: draft-ietf-ipsecme-ddos-protection-02.txt > Pages : 25 > Date: 2015-07-04 > > Abstract: > This document recommends i

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

Hi, Stephen. See below. > On Jul 8, 2015, at 2:15 AM, Stephen Farrell wrote: > > > -- > COMMENT: > -- > > > intro: "gold standard" is being a bit too keen I

Re: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

Hi, Ben. See below > On Jul 8, 2015, at 5:51 AM, Ben Campbell wrote: > > -- > COMMENT: > -- > > This is easier than usual to read for this sort of draft :-)

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

So, how about replacing the first two paragraphs? OLD: The Advanced Encryption Standard (AES - [FIPS-197]) has become the gold standard in encryption. Its efficient design, wide implementation, and hardware support allow for high performance in many areas, including IPsec VPNs. On mo

Re: [IPsec] draft-ietf-ipsecme-chacha20-poly1305

> On Jul 1, 2015, at 10:31 AM, Martin Willi wrote: > > Kathleen, > >> I am getting the ballot ready for the next telechat (next week on >> Thursday). Are there any implementations? > > For the strongSwan open source project [1] I've implemented this draft, > supporting ChaCha20/Poly1305 both

Re: [IPsec] P-256 speed

Is this code available anywhere? If not, it makes it hard to reproduce their results. It’s too bad they don’t submit this to bench.cr.yp.to so we could have an apples-to-apples comparison with other implementations. Yoav > On Jul 21, 2015, at 11:57 AM, Stephen Kent wrote: > > I checked with

Re: [IPsec] DDoS draft next steps - CAPTCHA

> On Aug 14, 2015, at 7:08 PM, Valery Smyslov wrote: > With no hat on, I hate captchas. I sometimes don't see it well enough depending on the images selected and have not used applications as a result. It is a clever way to tackle the problem, so it would be up to the deplo

Re: [IPsec] My review of draft-nir-ipsecme-curve25519

> On Aug 25, 2015, at 3:19 PM, Tero Kivinen wrote: > > Firstly the name of the draft is bit misleading, as this defines both > curve25519 and Curve448 keys not only curve25519. Agree. Version -00 had only Curve25519 and the name remained. For the WG draft we can pick a different file name. T

Re: [IPsec] My review of draft-nir-ipsecme-curve25519

> On Aug 26, 2015, at 9:33 AM, Yaron Sheffer wrote: > >>> In the section 3.2 recipient tests there is discussion about checking >>> that the public key 32-octet string will have last byte in such way >>> that high-order bit of it is not set. >>> >>> If this is property of the func(d, G) for cur

Re: [IPsec] WG Interest in TCP Encapsulation

> On Sep 16, 2015, at 5:01 AM, Tero Kivinen wrote: > > Tommy Pauly writes: >> I wanted to get a sense of WG interest in working on a standard for running >> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that >> currently block UDP traffic. > > Before we made the UDP framen

Re: [IPsec] RFC4307 update

> On Sep 28, 2015, at 4:11 PM, Tero Kivinen wrote: > > We did update cryptographic algorithms for ESP and AH > (RFC4305->4835->7321), but we have never updated the RFC4307. > > I think there should be update for that document too, as it now > defines following madantory to implement algorithms:

Re: [IPsec] RFC4307 update

> On Sep 28, 2015, at 6:57 PM, Michael Richardson wrote: > > > Tero Kivinen wrote: >> We did update cryptographic algorithms for ESP and AH >> (RFC4305->4835->7321), but we have never updated the RFC4307. > >> I think there should be update for that document too, as it now defines >> followin

Re: [IPsec] RFC4307 update

> On Sep 28, 2015, at 10:39 PM, Michael Richardson > wrote: > > > Yoav Nir wrote: >> “Some point” has arrived, and I don’t think group #2 should even be >> SHOULD- at this point. > > MAY or SHOULD NOT? I’m thinking SHOULD NOT. Everyone phased out 1024-bi

Re: [IPsec] RFC4307 update

> On Sep 29, 2015, at 12:15 PM, Tero Kivinen wrote: > > Yoav Nir writes: >>> Does SHA1 go to MUST-? >>> >>> We hadn't listed SHA2 at all before. >>> We also have no GCM/CCM things specified. >>> >>> Are we obligted to list

Re: [IPsec] RFC4307 update

Hi. I’ll reply to Daniel’s and Paul’s comments. Note that this draft is a starting point to feed into discussion. Just like this kind of discussion. Re: ENCR_AES_CBC. If someone wanted to build an IKEv2 implementation with only one algorithm, the choice for maximum interoperability would be AES

[IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Hi, all Since we’ve had quite a bit of bikeshedding about this on the list, we’d like to gather and has it out face to face. So this Wednesday at 7:00 PM, right after the plenaries, we’ll meet at room 421 to hash this out. Everyone’s invited, obviously. Yoav P.S. Someone’s asked me off-list

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > >> P.S. Someone’s asked me off-list whether there is any IPsecME document that >> says not to trust SHA-1 in signatures, both AUTH payload and certificates, >> the way t

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: > > On Mon, 2 Nov 2015, Yoav Nir wrote: > >>>> P.S. Someone’s asked me off-list whether there is any IPsecME document >>>> that says not to trust SHA-1 in signatures, both AUTH payload and >>>>

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Forgot the link… > On 2 Nov 2015, at 12:38 PM, Yoav Nir wrote: > > >> On 2 Nov 2015, at 12:27 PM, Paul Wouters wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> >>>>> P.S. Someone’s asked me off-list whether there is any IPsecME document

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer wrote: > > If not here, where does this advice go? I see your point. But for instance for X509 certificates, I really would like to not make any statement and point to whatever equivalent of PKIX documents there are on that. Doe

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

> On 3 Nov 2015, at 9:42 AM, Tero Kivinen wrote: > > John Mattsson writes: >> - BTW, What does it mean that an algorithm like ENCR_RC5 is not >> listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”? > > It means this document does not specify whether they should be used or > not,

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 3 Nov 2015, at 10:48 AM, Dan Harkins wrote: > > > > On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: >> >>> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >>> >>> On Mon, 2 Nov 2015, Yoav Nir wrote: >>> >>>

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

> On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: > > Yoav Nir writes: >> There is 1 for “RSA Digital Signature” and you can encode any hash >> function the you would like, but for ECDSA there is: >> 9 - ECDSA with SHA-256 on the P-256 curve >> 10 - ECDSA with

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

Reminder. It’s tonight at 7:00 PM Japan time, 10:00 UTC. We won’t have Meetecho or audio streaming, but if a few remote people want to participate, we might be able to do something with Skype. Yoav > On 2 Nov 2015, at 10:28 AM, Yoav Nir wrote: > > Hi, all > > Since we’ve had

[IPsec] RFC 4307bis

Hi all. I’ve uploaded the XML source of this document to github and submitted the first pull request: https://github.com/ietf-ipsecme/drafts/pull/7/files We had a side meeting about the algorithms specified in this draft and came up with so

Re: [IPsec] RFC 4307bis

:39 PM, Yoav Nir wrote: > > Hi all. > > I’ve uploaded the XML source of this document to github and submitted the > first pull request: > https://github.com/ietf-ipsecme/drafts/pull/7/files > <https://github.com/ietf-ipsecme/drafts/pull/7/files> > > We had

Re: [IPsec] RFC 4307bis

c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis > > We added some text to recommend the status of each recommended algorithms. > > On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman <mailto:paul.hoff...@vpnc.org>> wrote: > On 9 Nov 2015, at 5:48, Yoav Nir wrote: >

Re: [IPsec] RFC 4307bis

er than GHash on all platforms, and (c) slower than HMAC-SHA1 on older platforms. > "and now it is known to be weak at least for a nation state" - suggest to > change to "and now it is known to be weak against a nation-state attacker". > > Thanks, > Yaron &g

Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification

Hi, Hema USE_TRANSPORT_MODE is a notification, so it is outside the structures in the SA payload. As a consequence, the protocol does not allow you to propose AES-GCM in transport mode or ChaCha20/Poly1305 in tunnel mode. Note also that USE_TRANSPORT_MODE does not force transport mode. It onl

Re: [IPsec] WGLC on draft-ietf-ipsecme-safecurves?

> On 12 Nov 2015, at 12:13 PM, Simon Josefsson wrote: > > There have been no additional comment on the list, and we have had one > positive review from an implementer [1]. Is there any reason to wait > further with WG last calling this document? Its dependency on > draft-irtf-cfrg-curves is in

Re: [IPsec] New revision of TCP Encapsulation draft

> On 21 Nov 2015, at 1:10 AM, Yaron Sheffer wrote: > > Hi Tommy, > > I also think this is very relevant work. Here are some comments to -01: > > I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited > under "prior work” That’s draft-ietf-ipsecme-ike-tcp-01. It was a workin

Re: [IPsec] FWD from Tero Kivinen: [IANA #879113] General Request for Assignment (ikev2-parameters)

Hi, Tero I realise you are not the one to ask about this, but why not use CFG_SET? This IMEI information is about as trustworthy as the “APPLICATION_VERSION” type. Yoav > On 15 Dec 2015, at 2:18 PM, Tero Kivinen wrote: > > FYI, I just rejected the DEVICE_IDENTITY configuration payload > att

[IPsec] Progressing on 4307bis

Hi Pretty much all of the discussion in the last month or so has been based on Daniel’s pull request. I think we might as well take that as a given. I propose to merge this CR and publish a new revision so that people can begin making changes on top of that. Of course, as always, everything i

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

Hi, Valery. Thank you for this draft. Having read it, I have some comments. First, the problem of IKE having too large packets in certain environments is a real problem. We’ve already addressed it with fragmentation, and the TCP encapsulation draft proposes yet another way. I think either of th

Re: [IPsec] meeting at IETF-95 ?

I believe around that time CFRG and TLS will be done with the signatures document and rfc4492bis respectively, so we could proceed and finish draft-ietf-ipsecme-safecurves. So count me as a +1 as well. > On 12 Jan 2016, at 4:56 PM, Paul Wouters wrote: > > > I hope we are scheduling a meeting

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 10:55 AM, Yaron Sheffer wrote: > > However, thank you for bringing in the SLOTH attack. >> As fas as I understand from the paper >> http://www.mitls.org/downloads/transcript-collisions.pdf it is based on the >> ability for an attacker to find collisions in a weak hashes (m

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 3:55 PM, Valery Smyslov wrote: > > Hi Yoav, > What does IPsec community think of it? Should we fix the protocol to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to achive that? Will this change

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 11:15 PM, Paul Wouters wrote: > > On Fri, 15 Jan 2016, Yoav Nir wrote: > >>> The initiator cannot validate the cookie - it is an opaque blob for him. >>> Should he reject >>> the cookie if its length is more than 64 bytes? Possibly.

Re: [IPsec] SLOTH & IKEv2

> On 15 Jan 2016, at 10:32 PM, Valery Smyslov wrote: > > >>> What about the responder - he doesn't see any cookie in this attack - the >>> attacker >>> sends the crafted cookie only to the initiator and sends a crafted >>> IKE_SA_INIT message w/o cookie to the responder (as far as I understand

Re: [IPsec] SLOTH & IKEv2

> On 16 Jan 2016, at 7:17 AM, HU, Jun (Jun) wrote: > > > >> -Original Message- >> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of EXT Yoav Nir >> Sent: Friday, January 15, 2016 8:15 PM >> To: Valery Smyslov >> Cc: ipsec@ietf.

Re: [IPsec] ESN question regarding wording in 4304

Hi, Paul At some point there was talk of allowing people to omit the ESN attribute from the SA payload, and that would mean “ESN yes only”. That was not in the final 4306, but apparently a trace of this remains in 4304. As for what my implementation does, we send only “ESN no” and accept only “

Re: [IPsec] RFC4307bis working version 3

> On 21 Jan 2016, at 7:25 AM, Paul Wouters wrote: > > > "high interoperability" does not really work for me. How about "wide > interoperability" or industry-wide or "a wide range of > interoperability". > > > a user -> an user Nope: http://gmatclub.com/forum/a-user-or-an-user-111564.html __

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-01.txt

ty Maintenance and Extensions > Working Group of the IETF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename: draft-ietf-ipsecme-safecurve

Re: [IPsec] RFC4307bis working version 3

On 10 Feb 2016, at 1:43 PM, Paul Wouters wrote: > >> And for the digital signature method, why should we require SHA-1? > > Because it is very common to use right now. We cannot go from MUST to > MUST NOT. No, but RFC 4307 says nothing about hashes in signatures (whether RSA(1) or digital sig

[IPsec] DDoS Protection - single vs multiple solutions

Hi As we’re nearing WGLC for the DDoS protection draft, there is a question we’ve left open in the past that should be resolved. The issue is with the variability of the time it takes to solve a puzzle. To demonstrate it, I ran a simulation of trying to solve a 20-bit puzzle 1000 times on some

Re: [IPsec] DDoS Protection - single vs multiple solutions

On 17 Feb 2016, at 6:09 PM, Yoav Nir wrote: > A while ago Scott Fluhrer suggested a way to make this more fair As it turns out, this was first suggested by Yaron: https://mailarchive.ietf.org/arch/msg/ipsec/_JUTE8p5H6bhFOA1HCuaYX1NCKQ Scott’s idea was a little different. Sorry for

Re: [IPsec] DDoS Protection - single vs multiple solutions

On 18 Feb 2016, at 2:58 PM, Valery Smyslov wrote: > > > I tend to support this idea, but I think in this case the sub-puzzles must be > chained to deal with parallel solving. > Something like the following: > > Puzzle_data[0] = cookie > Puzzle_data[1] = Puzzle_solution[0] | cookie > Puzzle_d

Re: [IPsec] DDoS Protection - single vs multiple solutions

> On 18 Feb 2016, at 4:20 PM, Valery Smyslov wrote: > >>> I tend to support this idea, but I think in this case the sub-puzzles must >>> be chained to deal with parallel solving. >>> Something like the following: >>> >>> Puzzle_data[0] = cookie >>> Puzzle_data[1] = Puzzle_solution[0] | cookie

[IPsec] Textual changes to the DDoS draft

Hi all Valery submitted a new PR with a couple of textual changes, mostly based on comments by Dave. https://github.com/ietf-ipsecme/drafts/pull/12 The changes (listed below) seem fine to me. If nobody objects, I will merge them in on Friday.

Re: [IPsec] Textual changes to the DDoS draft

> On 26 Feb 2016, at 2:03 AM, Waltermire, David A. > wrote: > > I haven’t seen any additional feedback on the DDoS draft this week based on > Yoav’s note about the PR [1]. It also looks like the discussion on chaining > puzzles has wrapped up with no changes needed to the draft [2]. Oh. My i

Re: [IPsec] Textual changes to the DDoS draft

curity and simplicity. > > Regards, > Valery. > >> - Original Message - >> From: Yaron Sheffer <mailto:yaronf.i...@gmail.com> >> To: Valery Smyslov <mailto:sva...@gmail.com> ; Yoav Nir >> <mailto:ynir.i...@gmail.com> ; Waltermire, Da

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 4 Mar 2016, at 7:02 PM, Tommy Pauly wrote: > > Hello Dave, > > I tend to agree with Paul that I find it unlikely, from an implementor’s > standpoint, that many Initiators will choose to implement the puzzle logic, > especially ones that are running on mobile devices. It is unlikely that

Re: [IPsec] Proposed wording for a revised charter

+1 Speaking as an implementer, we have done something similar for our IKEv1 clients, and would be happy to have something standards-based for IKEv2. I would be happy to see this work become an RFC. Yoav > On 4 Mar 2016, at 7:05 PM, Tommy Pauly wrote: > > I would also like to see the draft f

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 6 Mar 2016, at 5:28 PM, Graham Bartlett (grbartle) > wrote: > > Hi > > The only case I could imagine that this could occur is if the Initiators > Nonce and KE were purposely made very small and the Initiator did not > perform any validation on this, sending it¹s own reply where the KE and

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 4 Mar 2016, at 5:29 PM, Paul Wouters wrote: > >> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) >> wrote: >> All: >> >> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I >> believe the draft is shaping up nicely, >> but needs additional review.

Re: [IPsec] Proposed agenda for the upcoming meeting in Buenos Aires

Regarding draft-ietf-ipsecme-safecurves I think this is pretty much done. I don’t see why I’d need 15 minutes to say, “Version -00 had Curve25519; version -01 added Curve448; we don’t need to wait for CFRG’s signature draft, because we have RFC 7427; I think we’re ready for WGLC” Yoav > On 11

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

> On 16 Mar 2016, at 2:27 PM, Paul Wouters wrote: > > >> >> Or perhaps we need the IKEv1 considered harmful draft / >> ikev1-diediediediedie... > > I don't think that will help. I've seen how reluctant people are to change > their 10 year old working VPN. > > IKEv1 is dying pretty quickly

[IPsec] EdDSA Signatures in IKE

Hi At the meeting today, I presented the SafeCurves draft status and asked the room whether we wanted to wait for CFRG and Curdle to settle their respective RFCs. The room was unanimously in favor of not having anything in the current draft, instead using RFC 7427 digital signatures. To be cert

Re: [IPsec] EdDSA Signatures in IKE

:43 PM, Yoav Nir wrote: > > Hi > > At the meeting today, I presented the SafeCurves draft status and asked the > room whether we wanted to wait for CFRG and Curdle to settle their respective > RFCs. The room was unanimously in favor of not having anything in the current >

Re: [IPsec] Next steps on TCP Encapsulation for IKEv2

Hi, Tommy. The changes look fine, although I’m still not convinced we even need the TLS. But that’s for another thread. We foresee that most TCP encapsulation is likely to be in on port 443. I think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from other types of traffic o

<    1   2   3   4   5   6   7   8   9   >