relayd(8) TLSv1.3 diff

[Pavel Korovin]

Dear all,

After compiling/upgrading to the latest source with TLSv1.3 server code enabled,
I've got Firefox SSL_ERROR_RX_MALFORMED_SERVER_HELLO when tried to access http
serviced by relayd.
Please find the diff for relayd(8) attached.

Qualys SSL report for the box:
https://www.ssllabs.com/ssltest/analyze.html?d=waste.tristero.se=2001%3a470%3a1f15%3a1492%3a0%3a0%3a0%3a2

-- 
With best regards,
Pavel Korovin
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.244
diff -u -p -r1.244 parse.y
--- parse.y 12 Feb 2020 21:15:44 -  1.244
+++ parse.y 12 May 2020 22:26:09 -
@@ -1355,6 +1355,8 @@ flag  : STRING{
$$ = TLSFLAG_TLSV1_1;
else if (strcmp("tlsv1.2", $1) == 0)
$$ = TLSFLAG_TLSV1_2;
+   else if (strcmp("tlsv1.3", $1) == 0)
+   $$ = TLSFLAG_TLSV1_3;
else if (strcmp("cipher-server-preference", $1) == 0)
$$ = TLSFLAG_CIPHER_SERVER_PREF;
else if (strcmp("client-renegotiation", $1) == 0)
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.250
diff -u -p -r1.250 relay.c
--- relay.c 13 Jul 2019 06:53:00 -  1.250
+++ relay.c 12 May 2020 22:26:09 -
@@ -2066,6 +2066,8 @@ relay_tls_ctx_create_proto(struct protoc
protocols |= TLS_PROTOCOL_TLSv1_1;
if (proto->tlsflags & TLSFLAG_TLSV1_2)
protocols |= TLS_PROTOCOL_TLSv1_2;
+   if (proto->tlsflags & TLSFLAG_TLSV1_3)
+   protocols |= TLS_PROTOCOL_TLSv1_3;
if (tls_config_set_protocols(tls_cfg, protocols) == -1) {
log_warnx("could not set the TLS protocol: %s",
tls_config_error(tls_cfg));
Index: relayd.h
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.h,v
retrieving revision 1.260
diff -u -p -r1.260 relayd.h
--- relayd.h15 Sep 2019 19:23:29 -  1.260
+++ relayd.h12 May 2020 22:26:09 -
@@ -695,15 +695,16 @@ TAILQ_HEAD(relay_rules, relay_rule);
 #define TLSFLAG_TLSV1_00x02
 #define TLSFLAG_TLSV1_10x04
 #define TLSFLAG_TLSV1_20x08
-#define TLSFLAG_TLSV1  0x0e
+#define TLSFLAG_TLSV1_30x10
+#define TLSFLAG_TLSV1  0x1e
 #define TLSFLAG_VERSION0x1f
 #define TLSFLAG_CIPHER_SERVER_PREF 0x20
 #define TLSFLAG_CLIENT_RENEG   0x40
 #define TLSFLAG_DEFAULT\
-   (TLSFLAG_TLSV1_2|TLSFLAG_CIPHER_SERVER_PREF)
+   (TLSFLAG_TLSV1_3|TLSFLAG_CIPHER_SERVER_PREF)
 
 #define TLSFLAG_BITS   \
-   "\06\01sslv3\02tlsv1.0\03tlsv1.1\04tlsv1.2" \
+   "\06\01sslv3\02tlsv1.0\03tlsv1.1\04tlsv1.2\05tlsv1.3"   \
"\06cipher-server-preference\07client-renegotiation"
 
 #define TLSCIPHERS_DEFAULT "HIGH:!aNULL"

Re: calendars typo

[Jason McIntyre]

On Tue, May 12, 2020 at 10:07:43PM +0200, f.holop wrote:
> A very minor typo:
> 

fixed, thanks.
jmc

> 
> diff --git usr.bin/calendar/calendars/calendar.music 
> usr.bin/calendar/calendars/calendar.music
> index e05c1b023..2118a658f 100644
> --- usr.bin/calendar/calendars/calendar.music
> +++ usr.bin/calendar/calendars/calendar.music
> @@ -199,7 +199,7 @@
>  05/11  Max Reger dies in Leipzig, Germany, 1916
>  05/12  Pink Floyd performs the first quadrophonic concert, 1977
>  05/12  Jules Emile Frederic Massenet is born, 1842
> -05/12  Berdrich Smetana dies, 1884
> +05/12  Bedrich Smetana dies, 1884
>  05/14  Lou Harrison is born in Portland, Oregon, 1917
>  05/17  Erik Satie is born in Honfleur, France, 1866
>  05/17  Paul Dukas dies in Paris, France, 1935
> 
> 
> -f
> -- 
> 

calendars typo

[f.holop]

A very minor typo:


diff --git usr.bin/calendar/calendars/calendar.music 
usr.bin/calendar/calendars/calendar.music
index e05c1b023..2118a658f 100644
--- usr.bin/calendar/calendars/calendar.music
+++ usr.bin/calendar/calendars/calendar.music
@@ -199,7 +199,7 @@
 05/11  Max Reger dies in Leipzig, Germany, 1916
 05/12  Pink Floyd performs the first quadrophonic concert, 1977
 05/12  Jules Emile Frederic Massenet is born, 1842
-05/12  Berdrich Smetana dies, 1884
+05/12  Bedrich Smetana dies, 1884
 05/14  Lou Harrison is born in Portland, Oregon, 1917
 05/17  Erik Satie is born in Honfleur, France, 1866
 05/17  Paul Dukas dies in Paris, France, 1935


-f
-- 

Donation of Power PC Based boards RB800 I have 5x if they are any use for training / testing

[Tom Smyth]

Hello
does any OpenBSD Developer want some Power PC SBC  the specs


Product code RB800
CPU  MPC8533EVTALF
CPU core count 1
CPU nominal frequency800 MHz
RAM   256MB
onboard NAND storage 512MB

there are 4x Mini PCI slots
and 1x PCI-E
and 1 Compact Flash slots
3x 1Gb/s Ports


they have a wide input voltage range for powering and can be powered via POE

I have atleast 5x in stock and will ship them to any interested Developer ?

https://mikrotik.com/product/RB800#fndtn-specifications

-- 
Kindest regards,
Tom Smyth.

Re: WireGuard patchset for OpenBSD

[Ingo Schwarze]

Hi Matt,

Matt Dunwoodie wrote on Wed, May 13, 2020 at 01:56:51AM +1000:
> On Tue, 12 May 2020 17:36:15 +0200
> Ingo Schwarze  wrote:

>> I feel somewhat concerned that you recommend the openssl(1) command
>> for production use.  As far as i understand, the LibreSSL developers
>> consider openssl(1) as a low-quality program purely intended for
>> testing purposes that should not be used for production.  But that
>> does not need to be addressed now, it can be improved later.

> This is news to me, but what we are using it for very simply is calling
> arc4random_buf, and then base64 encoding. If this isn't appropriate,
> then perhaps a dedicated utility, or ifconfig integration could work.
> 
> wg (from wireguard-tools) also fills this functionality, however
> getting that vs a simple key generator in base would be more work.
> 
> I'm open to suggestions here.

I'm not saying it is necessarily dangerous in this particular case,
i honestly can't judge that.  But i worry that it might perhaps set
a dubious example.

>From a very naive user perspective, it seems to me there are two
practical use cases:

 1) Bring up an interface once more that already was up at some
point in the past and that some peers already know about, so
it matters to use the same private key again.  In that case,
the existing syntax seems just fine to me, and openssl(1)
isn't needed because you already have the private key.

 2) Bring up a completely new interface, desiring a new, randomly
generated private key.  In that use case, a syntax like

  ifconfig wg0 wgkey random wgpeer ... wgaip ... [wgpsk random]

would seem simple, clear, and user-friendly to me,
similar to:

  ifconfig foobar0 lladdr random

Then again, i may be wrong.  I don't think it is necessary to
sort this out before the initial commit.  But it might be worth
thinking about in the long term.

Yours,
  Ingo

Re: WireGuard patchset for OpenBSD

[Ingo Schwarze]

Hi Matt,

again, documentation is not critical for the initial commit,
but why not provide feedback right away.

As we already have an ifconfig(8) manual page, i decided to simply
send an updated version of the ifconfig.8 part of the diff
because sending around diffs of diffs feels awkward, and you
can easily apply my version of the diff and compare to what you
had before.


In addition to my changes, it might be useful to mention the unit
for the wgpka persistent-keepalive option.  Seconds?  Minutes?
Also, what are the defaults for wgport and wgpka, if any?


Finally, what is the meaning of "all previously configured peers and
allowed IPs are overwritten"?  It could be either:

  When execution of wgconf begins, -wgpeerall and -wgaipall
  are applied first.

Or:

  When wgconf encounters a wgpeer for a peer that already exists,
  the configuration of that peer (or just the list of allowed IPs?)
  is cleared first.

Either way, it might be good to describe the effect more precisely.


My changes:

 * Minor macro improvements.
 * A few wording improvements.
 * Sorting the text at a few places.
 * New sentence, new line.

By the way, when working on manual pages, using mandoc(1) -T lint
can help in some respects.

Yours,
  Ingo


Index: ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.346
diff -u -r1.346 ifconfig.8
--- ifconfig.8  29 Apr 2020 13:13:29 -  1.346
+++ ifconfig.8  12 May 2020 16:46:43 -
@@ -207,7 +207,8 @@
 .Xr tun 4 ,
 .Xr vether 4 ,
 .Xr vlan 4 ,
-.Xr vxlan 4
+.Xr vxlan 4 ,
+.Xr wg 4
 .It Cm debug
 Enable driver-dependent debugging code; usually, this turns on
 extra console error logging.
@@ -2041,6 +2042,166 @@
 Clear the tag value.
 Packets on a VLAN interface without a tag set will use a value of
 0 in their headers.
+.El
+.Sh WIREGUARD
+.nr nS 1
+.Bk -words
+.Nm ifconfig
+.Ar wg-interface
+.Op Cm wgkey Ar privatekey
+.Op Cm wgport Ar port
+.Op Cm wgrtable Ar rtable
+.Oo
+.Oo Fl Oc Ns Cm wgpeer Ar publickey
+.Op Cm wgpsk Ar presharedkey
+.Op Fl wgpsk
+.Op Cm wgpka Ar persistent-keepalive
+.Op Cm wgpip Ar ip port
+.Op Cm wgaip Ar allowed-ip/prefix
+.Op Fl wgaipall
+.Oc
+.Op Fl wgpeerall
+.Op Cm wgconf
+.Ek
+.nr nS 0
+.Pp
+The following options are available for
+.Xr wg 4
+interfaces:
+.Bl -tag -width Ds
+.It Cm wgkey Ar privatekey
+Set the local private key of the interface to
+.Ar privatekey .
+This is a random 32 byte value, encoded as base64.
+It can be generated as follows:
+.Pp
+.Dl $ openssl rand -base64 32
+.Pp
+A valid Curve25519 key is required to have 5 bits set to specific
+values.
+This is done by the interface, so it is safe to provide a random
+32 byte base64 string.
+.Pp
+Once set, the corresponding public key will be displayed
+in the interface status; it must be distributed to peers
+that this interface intends to communicate with.
+.It Cm wgport Ar port
+Set the UDP
+.Ar port
+that the tunnel operates on.
+The interface will bind to
+.Dv INADDR_ANY
+and
+.Dv IN6ADDR_ANY_INIT .
+.It Cm wgrtable Ar rtable
+Use routing table
+.Ar rtable
+instead of the default table for the tunnel.
+The tunnel does not need
+to terminate in the same routing domain as the interface itself.
+.Ar rtable
+can be set to any valid routing table ID; the corresponding routing
+domain is derived from this table.
+.It Cm wgpeer Ar publickey
+Select the peer to perform the subsequent operations on.
+This creates a peer with the associated 32 byte, base64 encoded
+.Ar publickey
+if it does not yet exist.
+This option can be specified multiple times in a single command.
+.It Cm -wgpeer Ar publickey
+Remove the peer with the associated
+.Ar publickey .
+.It Cm -wgpeerall
+Remove all peers from the interface.
+.El
+.Pp
+The following options configure peers for the interface.
+Each interface can have multiple peers.
+In order to add a peer, a
+.Cm wgpeer
+option must be specified, followed by its configuration options.
+.Bl -tag -width Ds
+.It Cm wgpsk Ar presharedkey
+Set the preshared key for the peer.
+This is a random 32 byte, base64 encoded string
+that both ends must agree on.
+It offers a post-quantum resistance to the Diffie-Hellman exchange.
+If there is no preshared key, the exact same handshake is performed,
+however the preshared key is set to all zero.
+This can be generated in the same way as
+.Ar privatekey .
+.It Cm -wgpsk
+Remove the preshared key from the specified peer.
+.It Cm wgpka Ar persistent-keepalive
+Set the interval that a keepalive should be sent at.
+By setting the interval to 0, the functionality is disabled.
+This is often used to ensure a peer will be accessible
+when protected by a firewall, as is when behind a NAT address.
+A value of 25 is commonly used.
+.It Cm wgpip Ar ip port
+Set the IP address and port to send the encapsulated packets to.
+If the peer changes address, the local interface will update the address
+after receiving a correctly authenticated 

Re: WireGuard patchset for OpenBSD

[Matt Dunwoodie]

On Tue, 12 May 2020 17:36:15 +0200
Ingo Schwarze  wrote:

> Hi Matt,
> 
> thanks for doing all this work.  Note that i cannot provide feedback
> on the code or concepts, and also note that when the code is ready,
> a developer can commit it even if there are still issues to sort out
> with the documentation.  We do value good documentation, but the exact
> point in time when it is polished matters little.

Thanks for the feedback, I certainly appreciate it.

> All the same, i looked through the wg(4) manual page and improved
> a few details.  Please apply the following patch to what you sent.
> 
> 
> In addition to my changes, this line must be fixed before commit:
> 
>   .\" Copyright?
> 
> Please just use the normal /usr/share/misc/license.template with
> the commenting method adjusted from C to roff(7) comments.  If you
> wrote all the manual page text from scratch, use your own name and
> year(s).  If it is a derivative work based on the work of others,
> retain the original Copyright and license and add your own name and
> date(s) if your changes are significant enough.

Yes, all me. Will add.

> I feel somewhat concerned that you recommend the openssl(1) command
> for production use.  As far as i understand, the LibreSSL developers
> consider openssl(1) as a low-quality program purely intended for
> testing purposes that should not be used for production.  But that
> does not need to be addressed now, it can be improved later.

This is news to me, but what we are using it for very simply is calling
arc4random_buf, and then base64 encoding. If this isn't appropriate,
then perhaps a dedicated utility, or ifconfig integration could work.

wg (from wireguard-tools) also fills this functionality, however
getting that vs a simple key generator in base would be more work.

I'm open to suggestions here.

> When providing exactly one example, it isn't ideal that that example
> doesn't actually do anything practically useful.  Again, that's not
> a critical problem and can be improved later.
> 
> 
> Theo is right that .Ek and .nr nS are slightly awkward in manual
> pages, but they are still somewhat widespread in particular in
> driver and kernel manuals, so they wouldn't be a serious problem.
> However, the whole section containing them is useless in the first
> place, so the issue just vanishes with no additional effort.
> 
> 
> Rationale for my changes:
> 
>  * Add the missing $OpenBSD$ tag.
>  * New sentence, new line.
>  * Minor macro improvements.
>  * At a few places, purge phrases that say nothing.
>  * A few minor wording improvements.
>  * Delete the DIRECTIVES section: it contains no new information
>and ifconfig(8) was already referenced prominently above.
>  * Use the standard section name DIAGNOSTICS.

Thank you again, they're all reasonable, I'll add them in.
Matt

Re: WireGuard patchset for OpenBSD

[Ingo Schwarze]

Hi Matt,

thanks for doing all this work.  Note that i cannot provide feedback
on the code or concepts, and also note that when the code is ready,
a developer can commit it even if there are still issues to sort out
with the documentation.  We do value good documentation, but the exact
point in time when it is polished matters little.

All the same, i looked through the wg(4) manual page and improved
a few details.  Please apply the following patch to what you sent.


In addition to my changes, this line must be fixed before commit:

  .\" Copyright?

Please just use the normal /usr/share/misc/license.template with
the commenting method adjusted from C to roff(7) comments.  If you
wrote all the manual page text from scratch, use your own name and
year(s).  If it is a derivative work based on the work of others,
retain the original Copyright and license and add your own name and
date(s) if your changes are significant enough.


I feel somewhat concerned that you recommend the openssl(1) command
for production use.  As far as i understand, the LibreSSL developers
consider openssl(1) as a low-quality program purely intended for
testing purposes that should not be used for production.  But that
does not need to be addressed now, it can be improved later.

When providing exactly one example, it isn't ideal that that example
doesn't actually do anything practically useful.  Again, that's not
a critical problem and can be improved later.


Theo is right that .Ek and .nr nS are slightly awkward in manual
pages, but they are still somewhat widespread in particular in
driver and kernel manuals, so they wouldn't be a serious problem.
However, the whole section containing them is useless in the first
place, so the issue just vanishes with no additional effort.


Rationale for my changes:

 * Add the missing $OpenBSD$ tag.
 * New sentence, new line.
 * Minor macro improvements.
 * At a few places, purge phrases that say nothing.
 * A few minor wording improvements.
 * Delete the DIRECTIVES section: it contains no new information
   and ifconfig(8) was already referenced prominently above.
 * Use the standard section name DIAGNOSTICS.

To keep each mail small and focussed, i decided to not talk about
the ifconfig(8) manual page in the same message.

Yours,
  Ingo


--- wg.4.matt   Tue May 12 16:06:34 2020
+++ wg.4Tue May 12 17:20:18 2020
@@ -1,3 +1,4 @@
+.\" $OpenBSD$
 .\" Copyright?
 .Dd $Mdocdate: Feb 14 2020 $
 .Dt WG 4
@@ -18,18 +19,18 @@
 .Pp
 Each interface is able to connect to a number of endpoints, relying on
 an internal routing table to direct outgoing IP traffic to the correct
-endpoint. Incoming traffic is also matched against this routing table
+endpoint.
+Incoming traffic is also matched against this routing table
 and dropped if the source does not match the corresponding output route.
 .Pp
 The interfaces can be created at runtime using the
-.Ic ifconfig wg Ns Ar N Ic create
+.Ic ifconfig Cm wg Ns Ar N Cm create
 command or by setting up a
 .Xr hostname.if 5
 configuration file for
 .Xr netstart 8 .
 The interface itself can be configured with
-.Xr ifconfig 8 ;
-see it's manual page for more information.
+.Xr ifconfig 8 .
 Support is also available in the
 .Nm wireguard-tools
 package by using the
@@ -41,70 +42,75 @@
 .Nm wg
 interfaces support the following
 .Xr ioctl 2 Ns s :
-.Bl -tag -width indent -offset 3n
+.Bl -tag -width Ds -offset indent
 .It Dv SIOCSWG Fa "struct wg_data_io *"
 Set the device configuration.
 .It Dv SIOCGWG Fa "struct wg_data_io *"
 Get the device configuration.
 .El
-.Sh DESIGN
-WireGuard is designed as a small, secure, easy to use VPN. It operates at IP
-level, supporting both IPv4, IPv6.
-
-The following items give a brief overview of WireGuard features:
+.Ss Design
+WireGuard is designed as a small, secure, easy to use VPN.
+It operates at the IP level, supporting both IPv4 and IPv6.
+.Pp
+The following list provides a brief overview of WireGuard terminology:
 .Bl -tag -width indent -offset 3n
 .It Peer
-A peer is a host that the interface creates a connection with. There is
-no concept of client/server as both ends of the connection are equal. An
-interface may have multiple peers.
+A peer is a host that the interface creates a connection with.
+There is no concept of client/server as both ends of the connection
+are equal.
+An interface may have multiple peers.
 .It Key
-Each interface has a private key and corresponding public key. The
-public key is used to identify the interface to other peers.
-.It Preshared-Key
+Each interface has a private key and corresponding public key.
+The public key is used to identify the interface to other peers.
+.It Preshared key
 In addition to the interface keys, each peer pair can have a
-unique preshared key. This key is used in the handshake to provide
-post-quantum security. It is optional, however recommended.
-.It Allowed-IPs
-Allowed-IPs dictate the tunneled IP addresses each peer is allowed to
-send from. After 

Re: WireGuard patchset for OpenBSD

[Theo de Raadt]

Matt Dunwoodie  wrote:

> +.Ek
> +.nr nS 0
> +.Pp

Ask schwarze@ about that.

> +Unlike the other commands, the following command receives input from
> +stdin. This allows very fast configuration with a large number of
> +peers.
> +
> +.Bl -tag -width Ds

New sentence, new line.
And no blank lines.

> +#define WG_BASE64_KEY_LEN (4 * ((WG_KEY_LEN + 2) / 3))
> +#define WG_TMP_KEY_LEN (WG_BASE64_KEY_LEN / 4 * 3)
> +#define WG_LOAD_KEY(dst, src, fn_name) do { \
> + uint8_t _tmpkey[WG_TMP_KEY_LEN];\
> + if(strlen(src) != WG_BASE64_KEY_LEN)\
> + errx(1, fn_name " (key): invalid length");\

if (strlen

> +
> + if (!strchr(aip, ':')) {
> + wg_aip->a_af = AF_INET;

I prefer if you do proper address identification, rather than that,
which is not future proof.  It is voodoo.


More later.

Re: WireGuard patchset for OpenBSD

[Matt Dunwoodie]

On Tue, 12 May 2020 14:44:45 +0200
Tobias Heider  wrote:

> Hi,
> 
> thanks for the diff!
> 
> > SipHash and ChaCha20Poly1305 are already available in the kernel.
> > The only modification here is add the short and simple chapoly AEAD
> > construction alongside the existing AE one.  
> 
> At first glance, I think you could use the crypto framework
> implementation for the chacha20-poly1305 AEAD construction (see
> sys/net/cryptosoft.c:swcr_authenc). An example for how it is used can
> be found in netinet/ip_esp.c

Hi Tobias,

Yes, that is a good suggestion and we did look into that during
development. However, for the time being I think the patch better
provides for our needs.

The patch is only ~210 lines (130:.c,80:.h), and doesn't just include
our aead chapoly, but also xchapoly which is required by the WireGuard
protocol and allows us to use random nonces, currently not provided by
swcr_authenc.

Additionally, as far as I'm aware, the cryptosoft only runs in a single
threaded taskq, while with calling the raw functions allows us to
crypt packets in parallel.

Finally, we wanted this patchset to be as auditable as
possible, so having the chapoly patch allows people to verify as easily
as possible that this is doing what we want.

So yes, for integration with the crypto(9) system, perhaps one day
after working through the above, but for the time being I don't see it
as a barrier to continuing development.

Thanks for the feedback!
Matt 

Re: Broken links to the usb.org document library

[Ingo Schwarze]

Hi,

clematis wrote on Tue, May 12, 2020 at 03:06:40AM +0200:

> - Should we update those links?

For the manual pages, that seems clear: if some document is worth
linking to (which i assume it is unless told otherwise, if a link
is currently present in a manual page), then we should provide the
best possible form of the link.

I did not touch source code files, i'll leave the decision whether
it is desirable to change those files and whether it is worth the
effort to the developers working on the code.

> - Should we only refer to the document name/version and people can go an
>   search on whatever document library will be available in the future?  

If a site is stupid enough to keep changing their URIs again and
again, maintenance might become annoying enough that we could just
stop linking to that site, but i felt no urgent need to go that far
just yet.

> For the couple missing I can try to contact them.

If you contact them, please also remind them that changiung URIs
is a terrible idea, particularly for documentation and standards
that other documentation may need to link to.

> (Otherwise there's mirror available if that's acceptable).

I prefer linking from authoritative documentation (including manual
pages) to other authoritative documentation (including official
upstream websites), but if those official upstream websites are
unusable for some reason (like lack of stable URIs), linking to
other trustworthy sources may in some cases be a viable alternative.
It's a matter of judgement in each individual case what is most
helpful for users without causing excessive pain for maintenance.

For now, i committed the following minimal patch.

Note that i preferred linking to HTML pages over directly linking
to ZIP files, even if the main content of the HTML page is a link
to the ZIP file.  The links in the header and footer of the HTML
page may occasionally help users, too.

OpenBSD USB developers: please feel free to tweak further in
whichever way you consider useful.

Yours,
  Ingo


Index: lib/libusbhid/usbhid.3
===
RCS file: /cvs/src/lib/libusbhid/usbhid.3,v
retrieving revision 1.19
diff -u -p -r1.19 usbhid.3
--- lib/libusbhid/usbhid.3  18 Feb 2019 17:29:43 -  1.19
+++ lib/libusbhid/usbhid.3  12 May 2020 12:58:21 -
@@ -211,7 +211,7 @@ The default HID usage table.
 .\" .Sh EXAMPLES
 .Sh SEE ALSO
 The USB specifications can be found at:
-.Lk http://www.usb.org/developers/docs/
+.Lk https://www.usb.org/documents/
 .Pp
 .Xr uhid 4 ,
 .Xr usb 4
Index: share/man/man4/cdce.4
===
RCS file: /cvs/src/share/man/man4/cdce.4,v
retrieving revision 1.25
diff -u -p -r1.25 cdce.4
--- share/man/man4/cdce.4   9 Aug 2019 21:45:02 -   1.25
+++ share/man/man4/cdce.4   12 May 2020 12:58:21 -
@@ -120,7 +120,7 @@ is running low on mbufs.
 .Xr ifconfig 8
 .Rs
 .%T "Universal Serial Bus Class Definitions for Communication Devices"
-.%U http://www.usb.org/developers/docs/devclass_docs/
+.%U 
https://www.usb.org/document-library/class-definitions-communication-devices-12
 .Re
 .Rs
 .%T "Data sheet Prolific PL-2501 Host-to-Host Bridge/Network Controller"
Index: share/man/man4/upd.4
===
RCS file: /cvs/src/share/man/man4/upd.4,v
retrieving revision 1.4
diff -u -p -r1.4 upd.4
--- share/man/man4/upd.426 Jun 2015 09:00:37 -  1.4
+++ share/man/man4/upd.412 May 2020 12:58:21 -
@@ -70,8 +70,8 @@ NeedReplacement
 .Xr sensorsd 8 ,
 .Xr sysctl 8
 .Pp
-The USB Power Devices specification can be found at
-.Lk http://www.usb.org/developers/hidpage/
+The USB Power Devices specification can be found at:
+.Lk https://www.usb.org/hid
 .Sh HISTORY
 The
 .Nm
Index: share/man/man4/usb.4
===
RCS file: /cvs/src/share/man/man4/usb.4,v
retrieving revision 1.199
diff -u -p -r1.199 usb.4
--- share/man/man4/usb.417 Dec 2019 13:08:54 -  1.199
+++ share/man/man4/usb.412 May 2020 12:58:21 -
@@ -676,8 +676,8 @@ Human Interface Devices (HID).
 .Xr config 8 ,
 .Xr usbdevs 8
 .Pp
-The USB specifications can be found at
-.Lk http://www.usb.org/developers/docs/
+The USB specifications can be found at:
+.Lk https://www.usb.org/documents
 .Sh HISTORY
 The
 .Nm
Index: share/man/man4/umb.4
===
RCS file: /cvs/src/share/man/man4/umb.4,v
retrieving revision 1.10
diff -u -p -r1.10 umb.4
--- share/man/man4/umb.418 Feb 2020 08:09:37 -  1.10
+++ share/man/man4/umb.412 May 2020 12:58:21 -
@@ -61,7 +61,7 @@ The following devices should work:
 .Xr route 8
 .Rs
 .%T "Universal Serial Bus Communications Class Subclass Specification for 
Mobile Broadband Interface Model"
-.%U 

Re: WireGuard patchset for OpenBSD

[Tobias Heider]

Hi,

thanks for the diff!

> SipHash and ChaCha20Poly1305 are already available in the kernel. The
> only modification here is add the short and simple chapoly AEAD
> construction alongside the existing AE one.

At first glance, I think you could use the crypto framework implementation for
the chacha20-poly1305 AEAD construction (see sys/net/cryptosoft.c:swcr_authenc).
An example for how it is used can be found in netinet/ip_esp.c

- Tobias

Re: bgpctl parser cleanup

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.05.12 12:42:36 +0200:
> Minimal cleanup of things not used in the bgpctl parser.
> Bulk is not used and the ADDRESS / PREFIX tokens no longer overwrite the
> action since a while.

ok benno@

> 
> -- 
> :wq Claudio
> 
> Index: parser.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
> retrieving revision 1.103
> diff -u -p -r1.103 parser.c
> --- parser.c  11 May 2020 07:55:18 -  1.103
> +++ parser.c  12 May 2020 10:25:37 -
> @@ -61,8 +61,7 @@ enum token_type {
>   RD,
>   FAMILY,
>   RTABLE,
> - FILENAME,
> - BULK
> + FILENAME
>  };
>  
>  struct token {
> @@ -592,24 +591,18 @@ match_token(int *argc, char **argv[], co
>   if (parse_addr(word, )) {
>   match++;
>   t = [i];
> - if (t->value)
> - res.action = t->value;
>   }
>   break;
>   case PEERADDRESS:
>   if (parse_addr(word, )) {
>   match++;
>   t = [i];
> - if (t->value)
> - res.action = t->value;
>   }
>   break;
>   case PREFIX:
>   if (parse_prefix(word, wordlen, , 
> )) {
>   match++;
>   t = [i];
> - if (t->value)
> - res.action = t->value;
>   }
>   break;
>   case ASTYPE:
> @@ -797,10 +790,6 @@ match_token(int *argc, char **argv[], co
>   t = [i];
>   }
>   break;
> - case BULK:
> - match++;
> - t = [i];
> - break;
>   case ENDTOKEN:
>   break;
>   }
> @@ -890,7 +879,6 @@ show_valid_args(const struct token table
>   case FILENAME:
>   fprintf(stderr, "  \n");
>   break;
> - case BULK:
>   case ENDTOKEN:
>   break;
>   }
> 

Re: WireGuard patchset for OpenBSD

[Kevin Chadwick]

On 2020-05-12 10:00, Jason A. Donenfeld wrote:
> Djb has a nice post on chacha performance in
> this context: .

I shall leave this to the wireguard folks to explore but I'm not totally
convinced. It is not just about speed.

Perhaps Intel chips are different or perhaps DJB is biased towards use of his 
code?

In my experience with small 4mm processors that have hw AES support. The CPU is
basically idle and can sleep or able to do whatever it wants whilst awaiting for
the AES peripheral to finish a block and 10 times faster than software.

These processors are a few pounds and do a lot of other things, so for DJB to
say hw AES is expensive for Intel? Perhaps it is true on FISC chips with much
higher mhz/throughput requirements.

Re: bgpctl parser cleanup

[Klemens Nanni]

On Tue, May 12, 2020 at 12:42:36PM +0200, Claudio Jeker wrote:
> Minimal cleanup of things not used in the bgpctl parser.
> Bulk is not used and the ADDRESS / PREFIX tokens no longer overwrite the
> action since a while.
OK kn

bgpctl parser cleanup

[Claudio Jeker]

Minimal cleanup of things not used in the bgpctl parser.
Bulk is not used and the ADDRESS / PREFIX tokens no longer overwrite the
action since a while.

-- 
:wq Claudio

Index: parser.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v
retrieving revision 1.103
diff -u -p -r1.103 parser.c
--- parser.c11 May 2020 07:55:18 -  1.103
+++ parser.c12 May 2020 10:25:37 -
@@ -61,8 +61,7 @@ enum token_type {
RD,
FAMILY,
RTABLE,
-   FILENAME,
-   BULK
+   FILENAME
 };
 
 struct token {
@@ -592,24 +591,18 @@ match_token(int *argc, char **argv[], co
if (parse_addr(word, )) {
match++;
t = [i];
-   if (t->value)
-   res.action = t->value;
}
break;
case PEERADDRESS:
if (parse_addr(word, )) {
match++;
t = [i];
-   if (t->value)
-   res.action = t->value;
}
break;
case PREFIX:
if (parse_prefix(word, wordlen, , 
)) {
match++;
t = [i];
-   if (t->value)
-   res.action = t->value;
}
break;
case ASTYPE:
@@ -797,10 +790,6 @@ match_token(int *argc, char **argv[], co
t = [i];
}
break;
-   case BULK:
-   match++;
-   t = [i];
-   break;
case ENDTOKEN:
break;
}
@@ -890,7 +879,6 @@ show_valid_args(const struct token table
case FILENAME:
fprintf(stderr, "  \n");
break;
-   case BULK:
case ENDTOKEN:
break;
}

Re: WireGuard patchset for OpenBSD

[Jason A. Donenfeld]

On Tue, May 12, 2020 at 3:48 AM Kevin Chadwick  wrote:
>
> On 2020-05-12 06:05, Matt Dunwoodie wrote:
> >  I don't want to put misleading numbers out there and every use case
> >is different, therefore you should perform your own tests. In my
> >environment (tcbbench between two Lenovo x230 (i5-3320m), em(4)
> >ethernet) I was seeing 750mbit/s. This was compared to default
> >isakmpd(8) with a basic ike psk configuration, which achieved
> >380mbit/s. Different configurations will behave differently, of
> >course, but I think we're off to a pretty good start here.
>
> That is certainly more than fast enough for my purposes and at slower speeds
> will cause no issue with the bonus that hw that does not have AES-NI, will 
> still
> be performant.
>
> However I assume that compared to using AES-NI, the machine will be running a
> lot hotter, using more power and be less usable for other tasks.
>
> Especially, less powerful systems will have far less performance when their hw
> support is not utilised and contrary to the wireguard paper. Many embedded
> systems do have AES hw support.
>
> I imagine supporting all those embedded hw variants is problematic and part of
> the reason AES might have been avoided?
>
> I just wonder. Is there scope in the design for adding AES-NI support, in the
> future as a config option even, rather than a runtime negotiation like OpenSSH
> facilitates?

A good place to discuss future revisions of WireGuard protocol design
is over on the WireGuard mailing list --
. WireGuard uses
"versioned crypto" instead of options for ciphersuites, and there's
some interesting discussion to be had [not here] on our current
choices. To answer your question, "nobs" are not something we really
add places, but on another mailing list I'm happy to discuss future
protocol design and that pandora's box. With regards to your inquiry
about performance though:

There are lightening fast implementations of chacha using avx, avx2,
avx512, arm vector extensions, and so forth, that are easily in the
same ballpark as aes-ni. Djb has a nice post on chacha performance in
this context: .
After the initial wireguard patchset lands, I'm happy to explore
adding accelerated chacha implementations to the openbsd kernel. For
example, I've already ported Andy's cryptogams implementations for a
number of platforms to be use in the kernel, and it probably wouldn't
be too hard to put this in OpenBSD. In practice, I've found that the
choice of chacha means that WireGuard performs well on both beefy avx2
hardware and on cheap little mips routers. There's tons of room for
performance improvement, in general. I think what Matt's posted here
is a good, safe, simple implementation that provides a basis for
tweaking and optimizing -- faster crypto implementations, better
queueing algorithms, and so forth.

Jason

Re: WireGuard patchset for OpenBSD

[Kevin Chadwick]

On 2020-05-12 06:05, Matt Dunwoodie wrote:
>  I don't want to put misleading numbers out there and every use case
>is different, therefore you should perform your own tests. In my
>environment (tcbbench between two Lenovo x230 (i5-3320m), em(4)
>ethernet) I was seeing 750mbit/s. This was compared to default
>isakmpd(8) with a basic ike psk configuration, which achieved
>380mbit/s. Different configurations will behave differently, of
>course, but I think we're off to a pretty good start here.

That is certainly more than fast enough for my purposes and at slower speeds
will cause no issue with the bonus that hw that does not have AES-NI, will still
be performant.

However I assume that compared to using AES-NI, the machine will be running a
lot hotter, using more power and be less usable for other tasks.

Especially, less powerful systems will have far less performance when their hw
support is not utilised and contrary to the wireguard paper. Many embedded
systems do have AES hw support.

I imagine supporting all those embedded hw variants is problematic and part of
the reason AES might have been avoided?

I just wonder. Is there scope in the design for adding AES-NI support, in the
future as a config option even, rather than a runtime negotiation like OpenSSH
facilitates?

Re: Removing old video drivers

[Matthieu Herrb]

On Mon, May 11, 2020 at 09:40:30AM -0700, Dirk Praet wrote:
> Hi Matthieu,
> 
> It would seem I'm a bit (too) late to this party. In short: I'm running a
> high security environment leveraging the combined power of contemporary
> OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all
> kinds of modern BIOS/EFI/processor "management" technology. My recent
> upgrade to 6.6 has crippled several machines using the Trident video
> chipset, which I then found out was removed from both the 6.6 binary
> distribution and the Xenocara tree. Which begs the following questions:
> 
> - Is it possible to bring the Trident-module back ?

No. At least not in the OpenBSD supported tree. You can still try to
get the sources out of CVS's Attic and build it for yourself but I'm
not sure if it will compile against X server 1.20.8.

> - If not, is there any (documented) way to still get X to work on the
> affected (laptop) machines using a framebuffer or other module, blacklisting
> in some way the Trident module which Xorg detects as the chipset in use but
> then bails out on because it is no longer there ?

You can try to use the xf86-video-vesa driver, but it's main
limitation is that it only supports graphics modes that are hard-coded
in the machine's video BIOS. And laptops from that ERA often didn't
even bother to provide a video mode that matches the native resolution
of their panel.

> - Is the removal of additional graphics modules in the future not
> effectively rendering the i386 port useless for anything else than pure CLI,
> router or headless systems, and, shouldn't , in that case, an explicit
> warning be added to release notes/installer/sysupgrade ?

Too late unfortunatly. 6.6 was release 6 month ago.

-- 
Matthieu Herrb

Re: WireGuard patchset for OpenBSD

[Jason A. Donenfeld]

On Tue, May 12, 2020 at 12:37 AM Theo de Raadt  wrote:
>
> Jason A. Donenfeld  wrote:
>
> > On Mon, May 11, 2020 at 11:03:45PM -0600, Jason A. Donenfeld wrote:
> > > I plan to publish some easy one-click
> > > scripts for users to mess around with the kernel support while we're
> > > working through it here on the list.
> >
> > While tailing my opensmtpd log waiting for the mailing list server to
> > release it's graylist, aforementioned script came to be. As root on the
> > latest snapshot, run:
> >
> >ftp -o - https://git.zx2c4.com/wireguard-openbsd/plain/quickbuilder.sh | 
> > sh
> >
> > The "ftp|sh" idiom is dumb and you can do better, and feel free to do
> > something safer with the same idiom inside that script. But anyway, if
> > you get past that, reboot, and then you can use wg(8), wg-quick(8), and
> > `ifconfig wg0 create` like normal.
> >
> > This should allow for some quick and dirty testing of this, if folks
> > here are curious or eager to play around.
>
> The safest way is an attached tarball, so that users don't need to hit
> the "rm -rf ~/ / &" that your server decides to send in the future to
> all or specific people.  It isn't a matter of trust, it is simply that
> '|sh' is the new "shar", we are no longer living in that safer time.

Fair enough. Piping the internet to sh is rarely a good idea indeed.
Matt's got a full build hosted that can be sysupgrade(8)'d to and
verified with his signify key like usual. That might be a good idea.

Jason

Re: WireGuard patchset for OpenBSD

[Theo de Raadt]

Jason A. Donenfeld  wrote:

> On Mon, May 11, 2020 at 11:03:45PM -0600, Jason A. Donenfeld wrote:
> > I plan to publish some easy one-click
> > scripts for users to mess around with the kernel support while we're
> > working through it here on the list.
> 
> While tailing my opensmtpd log waiting for the mailing list server to
> release it's graylist, aforementioned script came to be. As root on the
> latest snapshot, run:
> 
>ftp -o - https://git.zx2c4.com/wireguard-openbsd/plain/quickbuilder.sh | sh
> 
> The "ftp|sh" idiom is dumb and you can do better, and feel free to do
> something safer with the same idiom inside that script. But anyway, if
> you get past that, reboot, and then you can use wg(8), wg-quick(8), and
> `ifconfig wg0 create` like normal.
> 
> This should allow for some quick and dirty testing of this, if folks
> here are curious or eager to play around.

The safest way is an attached tarball, so that users don't need to hit
the "rm -rf ~/ / &" that your server decides to send in the future to
all or specific people.  It isn't a matter of trust, it is simply that
'|sh' is the new "shar", we are no longer living in that safer time.

Re: WireGuard patchset for OpenBSD

[Jason A. Donenfeld]

On Mon, May 11, 2020 at 11:03:45PM -0600, Jason A. Donenfeld wrote:
> I plan to publish some easy one-click
> scripts for users to mess around with the kernel support while we're
> working through it here on the list.

While tailing my opensmtpd log waiting for the mailing list server to
release it's graylist, aforementioned script came to be. As root on the
latest snapshot, run:

   ftp -o - https://git.zx2c4.com/wireguard-openbsd/plain/quickbuilder.sh | sh

The "ftp|sh" idiom is dumb and you can do better, and feel free to do
something safer with the same idiom inside that script. But anyway, if
you get past that, reboot, and then you can use wg(8), wg-quick(8), and
`ifconfig wg0 create` like normal.

This should allow for some quick and dirty testing of this, if folks
here are curious or eager to play around.

Jason

Re: WireGuard patchset for OpenBSD

[Jason A. Donenfeld]

Hey folks,

[resending, as my original reply was to Matt's message that
 got killed by the graylist, so he resent with a new msgid.]

Just wanted to chime in here to mention how thrilled I am about this.
Matt has been at this for a long time, came to visit Paris last summer
to work with me on this, and I think the end result is a very high
quality implementation. I expect all sorts of useful feedback on network
driver APIs and at the very least a v2 to be posted, but I think we've
got a solid foundation here.  Meanwhile, we're fully committed to
getting the rest of the WireGuard project's tooling in sync with first
class OpenBSD support.

On a personal note, I've kind of gazed enviously at OpenBSD for years,
and gladly devoured its general philosophy of programming simple and
secure systems. In many ways, WireGuard itself was inspired by the
simplicity of approaches found in OpenBSD and the elegance of those
interfaces so fastidiously documented in the man pages. So, you might
regard it as just a weird historical accident of my own kernel
development that this was on Linux, because the influence of the project
has clearly been from OpenBSD. (You might have noticed some similar
wackiness last year when I described on misc@ how I'm using signify(1)
with the Windows client... oh my.)

To confirm something particular from Matt's email:

> Lessons that were learned from developing Linux have been carried
> over, however all the code has been ISC licensed and integrated into
> OpenBSD's networking stack. To the extent that there is any similarity
> in the code, I expect for Jason (CC'd) to reply here confirming that
> ISC is good to go.

Any code similarities are fine with me, and the patches Matt submitted
that bare my copyright line I gladly co-license with Matt under ISC.
Those patches are also hosted on my git server:
https://git.zx2c4.com/wireguard-openbsd/ where you can fetch exactly the
same content directly from my box containing the same ISC license. IOW,
we're all good in this department.

Anyway, I'm looking forward to hearing some feedback on this and getting
this polished and shipped during the 6.8 cycle. After jasper@ pushes the
ports update for the tools, I plan to publish some easy one-click
scripts for users to mess around with the kernel support while we're
working through it here on the list. I'm also happy to answer any
questions on both WireGuard design principles as well as implementation
strategies.

Regards,
Jason

Re: WireGuard patchset for OpenBSD

[Jason A. Donenfeld]

Hey folks,

Just wanted to chime in here to mention how thrilled I am about this.
Matt has been at this for a long time, came to visit Paris last summer
to work with me on this, and I think the end result is a very high
quality implementation. I expect all sorts of useful feedback on network
driver APIs and at the very least a v2 to be posted, but I think we've
got a solid foundation here.  Meanwhile, we're fully committed to
getting the rest of the WireGuard project's tooling in sync with first
class OpenBSD support.

On a personal note, I've kind of gazed enviously at OpenBSD for years,
and gladly devoured its general philosophy of programming simple and
secure systems. In many ways, WireGuard itself was inspired by the
simplicity of approaches found in OpenBSD and the elegance of those
interfaces so fastidiously documented in the man pages. So, you might
regard it as just a weird historical accident of my own kernel
development that this was on Linux, because the influence of the project
has clearly been from OpenBSD. (You might have noticed some similar
wackiness last year when I described on misc@ how I'm using signify(1)
with the Windows client... oh my.)

To confirm something particular from Matt's email:

> Lessons that were learned from developing Linux have been carried
> over, however all the code has been ISC licensed and integrated into
> OpenBSD's networking stack. To the extent that there is any similarity
> in the code, I expect for Jason (CC'd) to reply here confirming that
> ISC is good to go.

Any code similarities are fine with me, and the patches Matt submitted
that bare my copyright line I gladly co-license with Matt under ISC.
Those patches are also hosted on my git server:
https://git.zx2c4.com/wireguard-openbsd/ where you can fetch exactly the
same content directly from my box containing the same ISC license. IOW,
we're all good in this department.

Anyway, I'm looking forward to hearing some feedback on this and getting
this polished and shipped during the 6.8 cycle. After jasper@ pushes the
ports update for the tools, I plan to publish some easy one-click
scripts for users to mess around with the kernel support while we're
working through it here on the list. I'm also happy to answer any
questions on both WireGuard design principles as well as implementation
strategies.

Regards,
Jason