I don't think this should live in the standard library yet.

See: https://golang.org/doc/faq#x_in_std

It could live in golang.org/x/crypto if there are people willing to write and review an idiomatic implementation.

Good point.

The only thing I see is that DTLS shares a lot with TLS which is already implemented in the standard library. I'm currently having a look how much could be reused by a package in x/crypto I hope not too much code needs to be duplicated.

@bradfitz What would be the best way to reuse most of the TLS code without copying everything?
Many of the things are private and not accessible to use in a DTLS module.

If code reuse is considered important (and I'm not sure it is; at least there are some proponents against the idea in many cases), the we could move the to-be-shared code into a new public package like golang.org/x/crypto/innards/tlscommon' and thengolang.org/x/crypto/dtlscan use it, andcrypto/tls` can vendor it privately into the standard library to use.

Is there anybody working on this? I could really need this and after looking at cypto/tls I don't think I'm able to implement this myself.

Just in case anyone is interested, I started a DTLS implementation from scratch. It does currently nothing but sending ClientHello and receiving server handshake messages. I'm not sure whether I'll have enough time to get it into a working state.

A DTLS implementation in Go will be super-useful for libp2p.

really hope there is a go dtls

Any updates on this? Extremely needed for CoAP implementations in Go.

I stopped working on my implementation because I currently try to implement the project I want DTLS for in Rust. Furthermore I discovered that the handshake is full of complex corner cases and I'm uncertain wether I would be able to write a robust implementation.

There is this other one from @bocajim : https://github.com/bocajim/dtls. I would like to know what are the plans of official Go team, though.

Does @bocajim even want to move it into x/net?

I think @bocajim has a new github account @jimwert, what's the status on your dtls library? There seems to be some activity.

@rumpelsepp I am continuing to harden my DTLS implementation, but I don't have much interest in porting it into x/net, I did this out of desperation for a pure go DTLS library for a LWM2M implementation.

If someone wants to take the lead ill help any way I can, but I can't be the owner.

Thank you for clarifying this!

Sounds like we should wait on this and leave it to 3rd-party packages for now.

@rsc
there is good work on ti happenign here for DTLS, webrtc and makng the webrtc transport and standard dialer !
The crew there is very open and if the golang team want to help it would kick it faster...

https://github.com/pions/dtls

https://github.com/pions/dcnet

Hey @gedw99 thanks for mentioning us :)

I have a working DTLS 1.2 implementation with support for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 I built it for github.com/pions/webrtc

Currently only works as a client, but approximately 2 weeks I should have all my TODOs done (server support and a few extensions for better security + srtp)

I would really like to get this into x/net, get further review and just generally involve the community more. I thinking having it under pions will hurt the adoption, people are much more cautious when it comes to security software.

@lgierth I still would really like to get ipfs + WebRTC working. Using Electron leaves a lot to be desired, I would love to do anything I can to make that happen!

hey @Sean-Der Well its really the other way around if you ask me - thank you for doing the DTLS !!! Its going to help me and a ton of other projects that have been stopped by not having a pure golang DTLS.

I agree that having it under Pions will pigeon hole it. Best to get the client and server example working to have a base showing its the real deal and then hopefully the go team (hint hint @bradfitz ! ) will help nurture it. I really hope so !

@lgierth Me too about webrtc and IPFS. Seems like a marriage made in heaven !

As an update the DTLS implementation mentioned above now can act as both a Client+Server and can export keying material (so it supports SRTP)

I really want to get this out to the greater community, so would love any/all feedback! I posted to the mailing list but didn't get any response. If anyone has suggestions for good next steps I would love to hear them :)

Also if you are looking for a DTLS implementation please try it out! I would love to fix anything that comes up.

Given HTTP/3 QUIC is approaching and it uses UDP, shouldn't a DTLS package be headed to the standard library in time for Go 1.14?

Does QUIC make use of DTLS or is it a different TLS over UDP protocol?

Hmm, good catch. Looks like they're carrying TLS over QUIC itself. The information is spread out between the QUIC-TLS and QUIC-TRANSPORT RFCs which makes it a bit hard to distill what's going on.

You were faster than me, for the sake of completeness: https://tools.ietf.org/html/draft-ietf-quic-tls-20#section-3

@FiloSottile @agl (sorry for the out of the blue ping, but hopefully you can help!)

Pion DTLS supports a fair amount of features, and is being used pretty extensively. One user of Pion WebRTC tells me they reach ~500 thousand sessions daily! So I feel pretty good about its tolerance to out of order/packet loss/working with things beyond just OpenSSL.

I don't really care if it goes into x/net (or anywhere else) I really just want Go to have a mature DTLS implementation. I don't mind maintaining etc...

I talk to a lot of people that want to use OpenSSL via cgo because they don't trust pion/dtls. I really think Go is going to be THE place for WebRTC/IoT, but this is probably the biggest block I have seen at the moment.

thanks

There is no reason Go can't have a mature DTLS implementation outside of the golang.org/x/ repositories. The large decision involved in bringing it into x/crypto is for the Go team to commit to maintaining it and auditing it in the long term.

I appreciate the offer to maintain it, but if there are already people outside the Go team willing to maintain such a project, it can thrive outside of x/crypto. I understand it might be a matter of reassuring users about its security, but then we are going back to the necessity of Go team resources for it to be meaningful.

Thanks for the response @FiloSottile totally understand where you are coming from.

Do you have any suggestions for reassuring users about security? Are there any groups/companies that can audit Go code? I am not making any money, but I could try to convince the companies that are worried about security to pay for it.

I won't recommend specific companies while wearing my Go team hat, but with some research you'll find some high profile security consultancies that previously audited Go code, including Go TLS code.

Thanks for understanding and for improving the Go ecosystem.