iked curve25519

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

iked curve25519

Stuart Henderson
curve25519 had a proper ID (31) assigned in 2016 but we still have
the draft private-use ID in iked. Any thoughts on whether we can just
cut across to the proper ID, or whether that will be too painful?
Are many people using this already?

Reply | Threaded
Open this post in threaded view
|

Re: iked curve25519

Reyk Floeter-2
I like the idea of switching it to the proper ID.

Reyk

> Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
>
> curve25519 had a proper ID (31) assigned in 2016 but we still have
> the draft private-use ID in iked. Any thoughts on whether we can just
> cut across to the proper ID, or whether that will be too painful?
> Are many people using this already?
>

Reply | Threaded
Open this post in threaded view
|

Re: iked curve25519

Theo de Raadt-2
I think we should switch, waiting doesn't help.

Reyk Floeter <[hidden email]> wrote:

> I like the idea of switching it to the proper ID.
>
> Reyk
>
> > Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
> >
> > curve25519 had a proper ID (31) assigned in 2016 but we still have
> > the draft private-use ID in iked. Any thoughts on whether we can just
> > cut across to the proper ID, or whether that will be too painful?
> > Are many people using this already?
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: iked curve25519

Tobias Heider-2
In reply to this post by Reyk Floeter-2
+1 for adding ID 31

Maybe add the proper one but also keep the old to give people some time
to update their stuff if this is a problem.
There should be more than enough reserved IDs.

On 3/30/19 8:35 PM, Reyk Floeter wrote:

> I like the idea of switching it to the proper ID.
>
> Reyk
>
>> Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
>>
>> curve25519 had a proper ID (31) assigned in 2016 but we still have
>> the draft private-use ID in iked. Any thoughts on whether we can just
>> cut across to the proper ID, or whether that will be too painful?
>> Are many people using this already?
>>
>

Reply | Threaded
Open this post in threaded view
|

CPU stress/health test

Ozgur Kara
In reply to this post by Theo de Raadt-2
Hello all,

I say that just new joined OpenBSD family. I have used different operating systems for a long time. Now, I have a new notebook on this notebook hand to i7-2630QM Intel processor.
I've tested it with many different distributions and I've observed overheating problems in all of them. In some other distributions I also received errors like ACPI bug.

Today, I tried OpenBSD and I can't believe I'm surprised!  I did run stress testing with OpenBSD and I have great results and yes that's what I was looking!
The notebook didn't restart and passed the test in a perfect way. I technically want to know "what we owe it to result?"

I wanted to share and wanted to learn technically. So, here the technical details:

# sysctl hw.model hw.machine hw.ncpu
hw.model=Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
hw.machine=amd64
hw.ncpu=8

# uname -ar                    
OpenBSD openbsd.goosey.org 6.4 GENERIC.MP#364 amd64

Run test:

# stress -c 3                                                                                                                                                                                              
stress: info: [82273] dispatching hogs: 3 cpu, 0 io, 0 vm, 0 hdd

Result:

# sysctl hw.sensors
hw.sensors.cpu0.temp0=72.00 degC
hw.sensors.acpitz0.temp0=86.00 degC (zone temperature)
hw.sensors.acpitz1.temp0=86.00 degC (zone temperature)
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.20 VDC (current voltage)
hw.sensors.acpibat0.current0=0.00 A (rate)
hw.sensors.acpibat0.amphour0=2.90 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.00 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.09 Ah (low capacity)
hw.sensors.acpibat0.amphour3=2.90 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=5.20 Ah (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK
hw.sensors.acpibtn0.indicator0=On (lid open)

Note: Hyper-threading is ON

In other os distributions device even rebooted in the use "-c 2" parameter.
Explain this result to me, I'm overly satisfied.

Best Regards

Ozgur

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: iked curve25519

Eichert, Diana
In reply to this post by Tobias Heider-2
You didn't ask for an enduser opinion but you should go ahead but I suggest a hard change.

I can tell you people will continue to use the old method until it no longer works.

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Tobias Heider
Sent: Saturday, March 30, 2019 1:53 PM
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: [EXTERNAL] Re: iked curve25519

+1 for adding ID 31

Maybe add the proper one but also keep the old to give people some time to update their stuff if this is a problem.
There should be more than enough reserved IDs.

On 3/30/19 8:35 PM, Reyk Floeter wrote:

> I like the idea of switching it to the proper ID.
>
> Reyk
>
>> Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
>>
>> curve25519 had a proper ID (31) assigned in 2016 but we still have
>> the draft private-use ID in iked. Any thoughts on whether we can just
>> cut across to the proper ID, or whether that will be too painful?
>> Are many people using this already?
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: iked curve25519

Stuart Henderson
In reply to this post by Theo de Raadt-2
On 2019/03/30 13:43, Theo de Raadt wrote:

> I think we should switch, waiting doesn't help.
>
> Reyk Floeter <[hidden email]> wrote:
>
> > I like the idea of switching it to the proper ID.
> >
> > Reyk
> >
> > > Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
> > >
> > > curve25519 had a proper ID (31) assigned in 2016 but we still have
> > > the draft private-use ID in iked. Any thoughts on whether we can just
> > > cut across to the proper ID, or whether that will be too painful?
> > > Are many people using this already?
> > >
> >
>

Here's the cut-across diff. OK?

To transition, before updating, configure the responder to allow both
curve25519 and another PFS group e.g.

...
  ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group curve25519 \
  ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group brainpool512 \
...

Then switch the initiators to the other group, then upgrade and switch
back as wanted.

This doesn't affect the default iked configuration, and is unlikely to
affect non-OpenBSD devices as curve25519 with the draft ID does not seem
widely used elsewhere, so shouldn't trouble too many people.

Index: dh.c
===================================================================
RCS file: /cvs/src/sbin/iked/dh.c,v
retrieving revision 1.21
diff -u -p -r1.21 dh.c
--- dh.c 27 Oct 2017 14:26:35 -0000 1.21
+++ dh.c 1 Apr 2019 19:06:18 -0000
@@ -244,9 +244,7 @@ const struct group_id ike_groups[] = {
  { GROUP_ECP, 28, 256, NULL, NULL, NID_brainpoolP256r1 },
  { GROUP_ECP, 29, 384, NULL, NULL, NID_brainpoolP384r1 },
  { GROUP_ECP, 30, 512, NULL, NULL, NID_brainpoolP512r1 },
-
- /* "Private use" extensions */
- { GROUP_CURVE25519, 1034, CURVE25519_SIZE * 8 }
+ { GROUP_CURVE25519, 31, CURVE25519_SIZE * 8 }
 };
 
 void
Index: iked.conf.5
===================================================================
RCS file: /cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.53
diff -u -p -r1.53 iked.conf.5
--- iked.conf.5 31 Jan 2018 13:25:55 -0000 1.53
+++ iked.conf.5 1 Apr 2019 19:06:18 -0000
@@ -883,7 +883,7 @@ The currently supported group types are
 MODP (exponentiation groups modulo a prime),
 EC2N (elliptic curve groups over GF[2^N]),
 ECP (elliptic curve groups modulo a prime),
-or the non-standard Curve25519.
+or Curve25519.
 Please note that the EC2N groups are considered as insecure and only
 provided for backwards compatibility.
 .Sh EXAMPLES
Index: ikev2.h
===================================================================
RCS file: /cvs/src/sbin/iked/ikev2.h,v
retrieving revision 1.28
diff -u -p -r1.28 ikev2.h
--- ikev2.h 27 Feb 2019 06:33:57 -0000 1.28
+++ ikev2.h 1 Apr 2019 19:06:18 -0000
@@ -231,16 +231,16 @@ extern struct iked_constmap ikev2_xforma
 #define IKEV2_XFORMDH_MODP_4096 16 /* DH Group 16 */
 #define IKEV2_XFORMDH_MODP_6144 17 /* DH Group 17 */
 #define IKEV2_XFORMDH_MODP_8192 18 /* DH Group 18 */
-#define IKEV2_XFORMDH_ECP_256 19 /* DH Group 19 */
-#define IKEV2_XFORMDH_ECP_384 20 /* DH Group 20 */
-#define IKEV2_XFORMDH_ECP_521 21 /* DH Group 21 */
-#define IKEV2_XFORMDH_ECP_192 25 /* DH Group 25 */
-#define IKEV2_XFORMDH_ECP_224 26 /* DH Group 26 */
-#define IKEV2_XFORMDH_BRAINPOOL_P224R1 27 /* DH Group 27 */
-#define IKEV2_XFORMDH_BRAINPOOL_P256R1 28 /* DH Group 28 */
-#define IKEV2_XFORMDH_BRAINPOOL_P384R1 29 /* DH Group 29 */
-#define IKEV2_XFORMDH_BRAINPOOL_P512R1 30 /* DH Group 30 */
-#define IKEV2_XFORMDH_X_CURVE25519 1034 /* draft-ietf-ipsecme-safecurves-00 */
+#define IKEV2_XFORMDH_ECP_256 19 /* RFC5114 */
+#define IKEV2_XFORMDH_ECP_384 20 /* RFC5114 */
+#define IKEV2_XFORMDH_ECP_521 21 /* RFC5114 */
+#define IKEV2_XFORMDH_ECP_192 25 /* RFC5114 */
+#define IKEV2_XFORMDH_ECP_224 26 /* RFC5114 */
+#define IKEV2_XFORMDH_BRAINPOOL_P224R1 27 /* RFC6954 */
+#define IKEV2_XFORMDH_BRAINPOOL_P256R1 28 /* RFC6954 */
+#define IKEV2_XFORMDH_BRAINPOOL_P384R1 29 /* RFC6954 */
+#define IKEV2_XFORMDH_BRAINPOOL_P512R1 30 /* RFC6954 */
+#define IKEV2_XFORMDH_CURVE25519 31 /* RFC8031 */
 
 extern struct iked_constmap ikev2_xformdh_map[];
 
Index: parse.y
===================================================================
RCS file: /cvs/src/sbin/iked/parse.y,v
retrieving revision 1.78
diff -u -p -r1.78 parse.y
--- parse.y 13 Feb 2019 22:57:07 -0000 1.78
+++ parse.y 1 Apr 2019 19:06:18 -0000
@@ -253,7 +253,7 @@ const struct ipsec_xf groupxfs[] = {
  { "grp29", IKEV2_XFORMDH_BRAINPOOL_P384R1 },
  { "brainpool512", IKEV2_XFORMDH_BRAINPOOL_P512R1 },
  { "grp30", IKEV2_XFORMDH_BRAINPOOL_P512R1 },
- { "curve25519", IKEV2_XFORMDH_X_CURVE25519 },
+ { "curve25519", IKEV2_XFORMDH_CURVE25519 },
  { NULL }
 };
 

Reply | Threaded
Open this post in threaded view
|

Re: iked curve25519

Theo de Raadt-2
I think this is the right time to do this.

Stuart Henderson <[hidden email]> wrote:

> On 2019/03/30 13:43, Theo de Raadt wrote:
> > I think we should switch, waiting doesn't help.
> >
> > Reyk Floeter <[hidden email]> wrote:
> >
> > > I like the idea of switching it to the proper ID.
> > >
> > > Reyk
> > >
> > > > Am 30.03.2019 um 20:31 schrieb Stuart Henderson <[hidden email]>:
> > > >
> > > > curve25519 had a proper ID (31) assigned in 2016 but we still have
> > > > the draft private-use ID in iked. Any thoughts on whether we can just
> > > > cut across to the proper ID, or whether that will be too painful?
> > > > Are many people using this already?
> > > >
> > >
> >
>
> Here's the cut-across diff. OK?
>
> To transition, before updating, configure the responder to allow both
> curve25519 and another PFS group e.g.
>
> ...
>   ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group curve25519 \
>   ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group brainpool512 \
> ...
>
> Then switch the initiators to the other group, then upgrade and switch
> back as wanted.
>
> This doesn't affect the default iked configuration, and is unlikely to
> affect non-OpenBSD devices as curve25519 with the draft ID does not seem
> widely used elsewhere, so shouldn't trouble too many people.
>
> Index: dh.c
> ===================================================================
> RCS file: /cvs/src/sbin/iked/dh.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 dh.c
> --- dh.c 27 Oct 2017 14:26:35 -0000 1.21
> +++ dh.c 1 Apr 2019 19:06:18 -0000
> @@ -244,9 +244,7 @@ const struct group_id ike_groups[] = {
>   { GROUP_ECP, 28, 256, NULL, NULL, NID_brainpoolP256r1 },
>   { GROUP_ECP, 29, 384, NULL, NULL, NID_brainpoolP384r1 },
>   { GROUP_ECP, 30, 512, NULL, NULL, NID_brainpoolP512r1 },
> -
> - /* "Private use" extensions */
> - { GROUP_CURVE25519, 1034, CURVE25519_SIZE * 8 }
> + { GROUP_CURVE25519, 31, CURVE25519_SIZE * 8 }
>  };
>  
>  void
> Index: iked.conf.5
> ===================================================================
> RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> retrieving revision 1.53
> diff -u -p -r1.53 iked.conf.5
> --- iked.conf.5 31 Jan 2018 13:25:55 -0000 1.53
> +++ iked.conf.5 1 Apr 2019 19:06:18 -0000
> @@ -883,7 +883,7 @@ The currently supported group types are
>  MODP (exponentiation groups modulo a prime),
>  EC2N (elliptic curve groups over GF[2^N]),
>  ECP (elliptic curve groups modulo a prime),
> -or the non-standard Curve25519.
> +or Curve25519.
>  Please note that the EC2N groups are considered as insecure and only
>  provided for backwards compatibility.
>  .Sh EXAMPLES
> Index: ikev2.h
> ===================================================================
> RCS file: /cvs/src/sbin/iked/ikev2.h,v
> retrieving revision 1.28
> diff -u -p -r1.28 ikev2.h
> --- ikev2.h 27 Feb 2019 06:33:57 -0000 1.28
> +++ ikev2.h 1 Apr 2019 19:06:18 -0000
> @@ -231,16 +231,16 @@ extern struct iked_constmap ikev2_xforma
>  #define IKEV2_XFORMDH_MODP_4096 16 /* DH Group 16 */
>  #define IKEV2_XFORMDH_MODP_6144 17 /* DH Group 17 */
>  #define IKEV2_XFORMDH_MODP_8192 18 /* DH Group 18 */
> -#define IKEV2_XFORMDH_ECP_256 19 /* DH Group 19 */
> -#define IKEV2_XFORMDH_ECP_384 20 /* DH Group 20 */
> -#define IKEV2_XFORMDH_ECP_521 21 /* DH Group 21 */
> -#define IKEV2_XFORMDH_ECP_192 25 /* DH Group 25 */
> -#define IKEV2_XFORMDH_ECP_224 26 /* DH Group 26 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P224R1 27 /* DH Group 27 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P256R1 28 /* DH Group 28 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P384R1 29 /* DH Group 29 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P512R1 30 /* DH Group 30 */
> -#define IKEV2_XFORMDH_X_CURVE25519 1034 /* draft-ietf-ipsecme-safecurves-00 */
> +#define IKEV2_XFORMDH_ECP_256 19 /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_384 20 /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_521 21 /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_192 25 /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_224 26 /* RFC5114 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P224R1 27 /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P256R1 28 /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P384R1 29 /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P512R1 30 /* RFC6954 */
> +#define IKEV2_XFORMDH_CURVE25519 31 /* RFC8031 */
>  
>  extern struct iked_constmap ikev2_xformdh_map[];
>  
> Index: parse.y
> ===================================================================
> RCS file: /cvs/src/sbin/iked/parse.y,v
> retrieving revision 1.78
> diff -u -p -r1.78 parse.y
> --- parse.y 13 Feb 2019 22:57:07 -0000 1.78
> +++ parse.y 1 Apr 2019 19:06:18 -0000
> @@ -253,7 +253,7 @@ const struct ipsec_xf groupxfs[] = {
>   { "grp29", IKEV2_XFORMDH_BRAINPOOL_P384R1 },
>   { "brainpool512", IKEV2_XFORMDH_BRAINPOOL_P512R1 },
>   { "grp30", IKEV2_XFORMDH_BRAINPOOL_P512R1 },
> - { "curve25519", IKEV2_XFORMDH_X_CURVE25519 },
> + { "curve25519", IKEV2_XFORMDH_CURVE25519 },
>   { NULL }
>  };
>  
>