Live data from Hacker News

Rustls: new, modern TLS library written in Rust

github.com

71–80 of 112 posts

Re: Rustls: new, modern TLS library written in Rust

#71
post #68
post #63

Earlier quoted context omitted.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

Another interpretation of Modernist Development is team size: A modern SW project consists typically of 1-2, max. 3 devs, a typical post-modern project of 20-200. With such member sizes consensus is rarely practical, political correctness and CoC discussions are taking over development, ABI and API's are driven by design and not by functionality and longevity. I.e. modern development is small, functional and not desi…

a typical post-modern project of 20-200. With such member sizes consensus is rarely practical, political correctness and CoC discussions are taking over development, ABI and API's are driven by design and not by functionality and longevity.

Is this something you feel to be true, or do you have any evidence to back up that claim?

Re: Rustls: new, modern TLS library written in Rust

#72
post #67
post #63

Earlier quoted context omitted.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

You've given a while bunch of definitions for what you interpret modern to mean but none of those are inherent in the word which is what (I think) the op meant when complaining about its over usage. So while I appreciate your attempt to redefine "modern" with all the above I'd rather people just used the more verbose explanation instead of using the meaningless term.

Nothing is inherent in a word other than what people understand it to mean, and the worlds where 'modern' is a term of jargon are larger overall than computing. It has fairly specific meanings in art, architecture, literature, and music.

Grandparent referred to the meaning of the jargon term in architecture. It's not his personal redefinition; it's an interpretation of a widespread understanding of the word mapped analogously to software.

Jargon is important. We'd have a hard time communicating if we could never create new words or imbue existing ones with new meanings by analogy. The more verbose explanation is mostly useful for laymen and beginners.

Re: Rustls: new, modern TLS library written in Rust

#73

Can anyone comment on how this implementation of TLS compares to the recent ocaml/mirageOS version? How much does formal verification matter/increase confidence? Is the rust version easier to integrate with other stacks? https://mirage.io/blog/why-ocaml-tls

Neither ocaml-tls nor this new one do formal verification. The only TLS library that does so is miTLS.

Re: Rustls: new, modern TLS library written in Rust

#74
post #63
post #4

I'm developing a twitch whenever I see the word "modern" in a software description. It doesn't actually say anything about what you're doing.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

Why are you conflating building architecture and software architecture. I'm pretty sure no software developer has every thought of their project in terms of "post-modern."

New Jersey style? The PERL style? I've never heard of "New Jersey style." Are you joking? I'm almost positive that Perl didn't influence openssl development at all.

"Modern is more old Stanford-style development." I think you've read way to much into this. And sorry citing the "The UNIX Hater's Handbook" doesn't do much for the credibility of your odd argument.

Re: Rustls: new, modern TLS library written in Rust

#75
post #21

My application needs RFC 6091, i.e. using OpenPGP keys instead of the usual X.509 certificates. (Why not X.509? Ask Peter Gutmann¹). This feature is not listed as something they don’t support, nor as something they won’t support, which is odd. Likewise for DTLS (RFC 6347). These omissions are strange. ① Everything you Never Wanted to Know about PKI but were Forced to Find Out ( https://www.cs.auckland.ac.nz/~pgut001/…

① looks very interesting, but is clearly showing age. Is there anything newer on this topic in similar spirit?

Re: Rustls: new, modern TLS library written in Rust

#76
post #57

Earlier quoted context omitted.

I'd love to see an explanation for not supporting client authentication. Also, completely ruling out discrete-log DH and requiring PFS is not feasible unless you want to rule out a lot of clients and servers, on top of not supporting TLS 1.1.

There's a few problems with it. 1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unlike the server identity usually identifies a user; see sibling comment which confirms this) is sent in the clear. That's a big privacy failure. 2. to work around (1), some implementations do an initial server-auth handshake, then immediately renegotiate up to mut…

Thank you, this is a very good explanation and now I'm convinced that this is the right thing to do.

But I do need mutual authentication, and want to avoid rolling my own crypto for it--so does Rustls expect to support client auth in TLS 1.3 when that spec is finalized and implemented?

Re: Rustls: new, modern TLS library written in Rust

#77
post #54

Earlier quoted context omitted.

I hate so much this logic - it stops evolution. Humanity have enough programmers to write new libraries and patch existing code. Competition is better than stagnation.

It's also an argument against disruption in general. Great progress happens when people stop iterating and start rethinking stuff that hasn't been rethought for decades (and the "stuff" has seen only tiny improvements over the years following this strategy, too).

Don't get me wrong, I'm not against disruption at all. It's just there're cases where doing this doesn't make sense. Write a new text editor, invent a new programming language, sure. But writing a new cryptography library? You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small.

Making things even worse is that you can't really write a crypto library without using C/assembly. So why write a new crypto library?

Re: Rustls: new, modern TLS library written in Rust

#78

Earlier quoted context omitted.

This is good. However, I mentioned downgrade attacks as an example of the kind of bug Rust can't solve. Most likely new TLS stacks will not be prone to downgrade attacks. They might be prone to other logic errors. So will established TLS stacks, but those are more battle tested. The rust ones will be too, but eventually, not now. It's a tradeoff.

Out of curiousity, what sort of evidence of safety is the Servo team using to evaluate crypto libraries? I'd love to see the criteria.

As we mentioned in the recent Security meetings notes (https://github.com/servo/servo/wiki/London-Security ), there will be a blog post on blog.servo.org in the coming weeks from the folks on the team who are making these decisions.

Re: Rustls: new, modern TLS library written in Rust

#79
post #63

Earlier quoted context omitted.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

Why are you conflating building architecture and software architecture. I'm pretty sure no software developer has every thought of their project in terms of "post-modern." New Jersey style? The PERL style? I've never heard of "New Jersey style." Are you joking? I'm almost positive that Perl didn't influence openssl development at all. "Modern is more old Stanford-style development." I think you've read way to much in…

New Jersey style is a reference to Richard Gabriel's "Worse is better" essay.

[1] https://en.m.wikipedia.org/wiki/Worse_is_better

[2] http://dreamsongs.com/WorseIsBetter.html

Re: Rustls: new, modern TLS library written in Rust

#80
post #63

Earlier quoted context omitted.

It does. There are distinct properties attached to Modernism and Modern. (I'm architect, hence I'm very much attached to these terms. Unlike SW people who didn't grow up with that). First of all, it's the opposite of Post-Modern, to the perl style do it all in myriads of ways, everything is allowed, OpenSSL style. With Modern, only the best API and implementation is allowed. API's are Stanford style well-planned ahea…

Why are you conflating building architecture and software architecture. I'm pretty sure no software developer has every thought of their project in terms of "post-modern." New Jersey style? The PERL style? I've never heard of "New Jersey style." Are you joking? I'm almost positive that Perl didn't influence openssl development at all. "Modern is more old Stanford-style development." I think you've read way to much in…

Look into "New Jersey vs. MIT" and "worse is better". The idea more or less is that AT&T (in Jersey) cared more about software that shipped whereas MIT cared about more about good design. MIT produced Lisp and Lisp machines, Bell Labs produced C and Unix. Who won?
Post reply on HN