IIRC there is a draft RFC for securing QUIC with TLS, although it wasn't
necessarily "QUIC over TLS" in the traditional sense.
Anyway, I don't disagree it may well be unlikely. Just food for thought.
On Nov 27, 2017 04:14, "Garrett D'Amore" <garrett@xxxxxxxxxx> wrote:
The RFC can change since there is only a draft implementation.
I think however that it is incredibly unlikely that anyone will ever use
TLS over another transport. Much more likely is that a new transport would
include crypto natively - like QUIC or KCP or CurveCP.
And we can always use an extended name in the future if any such need were
to arise. At this point I am not going to hold my breath.
On Sun, Nov 26, 2017 at 5:02 PM Jukka Reitmaa <jukka.reitmaa@xxxxxxxxx>
wrote:
Sure, I agree with that; I don't know what the status or adoption of the
nanomsg RFCs in the wild currently is.
On Nov 27, 2017 00:01, "Dmitri Toubelis" <dmitri.toubelis@xxxxxxxxxxx>
wrote:
#5 would be ideal if no change to RFC is involved. Having two versions of
RFC can do way more harm then the alternative (of course it depends on the
current status of RFC). The example of what can go wrong is RFC 2307 when
half of the world adopts one revision and the rest the other crippling LDAP
implementations for decades.
------ Original Message ------
From: "Jukka Reitmaa" <jukka.reitmaa@xxxxxxxxx>
To: nanomsg@xxxxxxxxxxxxx
Sent: 2017-11-26 2:17:20 PM
Subject: [nanomsg] Re: mangos and TLS
I'll prefix my opinion by saying I haven't used nanomsg/mangos in
production, just been following the current progress with interest. (And
this my first post here.)
IMO, being infrastructure software, nanomsg/nng would benefit from an
unopinionated/future-proof approach, and therefore wouldn't assume that TLS
will necessarily remain almost-exclusively over TCP, say after ten years
(even though it well may). I personally wouldn't mind "ugliness", but I
would probably mind having to remember a few years from now that e.g.
'sctp+tls:' or some novel protocol over TLS is called something else. So
I'd go for #5: it's welcoming to extensions and explicit, which I feel
would be much more important for nanomsg over the long term.
On Nov 26, 2017 19:20, "Dmitri Toubelis" <dmitri.toubelis@xxxxxxxxxxx>
wrote:
I think #2 is a reasonable compromise. And when DTLS gets some adoption
we could have new `dtls://` transport. The reason is that indeed TLS is 99%
of times used with TCP and DTLS will have same strong coupling with UDP, so
there is very little chance that one will ever want to use in any differer
context. This is multiplied by the fact that these are security protocols,
so no one in the right mind would want to mess with them for production use.
-Dmitri
------ Original Message ------
From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
Sent: 2017-11-25 3:04:21 PM
Subject: [nanomsg] mangos and TLS
I changed the TLS RFC when I was developing nng’s TLS layer to specify
that the URL scheme used be “tls://“. In mangos, the scheme is
“tls+tcp://“ I used the longer form because in theory you can run TLS over
any stream transport. In practice, nobody runs it over anything except
TCP, so a shorter name makes sense. (For UDP, there is DTLS, but we aren’t
supporting that at this stage.)
So, the question I have for the community is, are you using the TLS
transport with mangos today? How disruptive would it be to change the
scheme from “tls+tcp” to just “tls”?
For context, here are some options open to me:
1) Just rename the tls+tcp scheme to tls. This would make it compliant
with the RFC, but disrupt any current users — most likely they would only
need to change their URLs. (There could be users who are looking at the
URLs or schemes using lower level APIs, but I suspect such use cases are
either rare or nonexistent.)
2) Do the rename, but leave a thin “conversion” layer in place, that
redirects tls+tcp:// URLs to the tls:// scheme. This would probably solve
99+% of the users of the existing scheme.
3) Clone the entire scheme — so both schemes work (identically) and
wholly. This is almost the easiest thing for me to do, but it wastes a lot
of duplicate code. This would let you use either scheme however you like.
The two schemes are wire compatible, so you can mix and match them.
4) Do nothing — leaving mangos with a different scheme than the RFC or
nng.
5) Convert nng and the RFC to tls+tcp. This is easy, minimally
disruptive (nobody is using the nng in production), but leaves us with kind
of an uglier URL scheme.
I am thinking that I’d really like to do just #1, but its disruptive
enough that if folks are using mangos and TLS, I’d like them to have some
clue that this is happening. Probably I’ll do #2.
- Garrett
