
The Transport Layer Security (TLS) Protocol Version 1.3 - dochtman
https://tools.ietf.org/html/rfc8446
======
vladd
New features introduced in TLS 1.3 include:

    
    
      * smaller latency (0-RTT: zero round-trips support).
      * removes insecure encryption primitives (SHA1, MD5, RC4).
      * elliptic curve support.
      * downgrade protection.
    

Some interesting reads:
[https://blog.cloudflare.com/introducing-0-rtt/](https://blog.cloudflare.com/introducing-0-rtt/)
and [https://www.cloudflare.com/learning-
resources/tls-1-3/](https://www.cloudflare.com/learning-resources/tls-1-3/) .

~~~
bcaa7f3a8bbc
* removes insecure encryption primitives (SHA1, MD5, RC4).

=> also removes all key exchange algos without forward secrecy.

* elliptic curve support.

=> and new X25519/Ed25519 elliptic curve support.

I think most security people are aware of these features for a while. The
final accepted standardization is what matters now, after 28 drafts, and the
epic success of overcoming the middlebox disaster...

~~~
snvzz
>and the epic success of overcoming the middlebox disaster...

This is one of these cases in which it would be (have been) better to just
break them. It isn't TLS's job to explicitly support evil.

These middleboxes are cancer. There's no way to morally defend their presence.
Breaking them (and thus effectively forcing them out of the way) would have
been the better approach.

~~~
willglynn
BRB, telling the compliance team that SSL inspection is morally indefensible.
I'm sure they'll be happy to turn it off.

~~~
geofft
"We should continue doing immoral things because there's no way we'll ever
convince corporate and governmental power to let us stop doing immoral things"
is ... probably not an incorrect argument, but a very sad one.

~~~
tptacek
SSL inspection isn't immoral. That's an uncharacteristically silly argument.

~~~
geofft
It's a tool, but it is (in a small way) a normalization of mass surveillance.

(I guess I should clarify that my argument is not "SSL inspection is bad _and
therefore TLS 1.3 is bad_ " \- my employer monitors all my SSL traffic from
work-owned machines, and could do so very easily with a browser extension or
something instead of SSL inspection if the protocol somehow made middleboxes
difficult. The proxies are currently designed to permit a few websites through
without interception, which is the specific thing that there was debate about
doing, but I don't think there's any real reason why my employer wouldn't just
monitor everything if they had to. So I don't think there's anything the TLS
spec could have done to make my employer more or less likely to monitor
traffic, and I don't think that this affects the argument about whether the
monitoring itself is immoral.)

~~~
unethical_ban
A company monitoring its assets for proper use and the SECURITY and PRIVACY of
its customers is not immoral.

A browser extension would not do nearly what a proper web proxy can do.

I am a critic of the surveillance state and a donating member of the EFF, but
web proxies are not evil in themselves, anymore than a camera is evil because
it can be used to build a panopticon, or cookies are evil because they can be
used for cross site tracking.

~~~
tptacek
This is approximately where I land on this. The privacy of employees takes a
back seat, way in the back, behind the luggage, to the privacy of the
information customers vouchsafe with the company. So, I'm always a bit itchy
about moralizing against employee surveillance (in technology I mean, not,
like, whether Walmart shift workers take too many breaks!).

~~~
dwheeler
The "middlebox problem" being discussed isn't the ability to install CAs on
clients - the problem is that middleboxes don't implement the spec properly
and prevent upgrading the protocol in the obvious way.

I'm not a big fan of transparent proxies, but in the case of employers there's
at least a reasonable argument that the "computers are not the user's, they
are the company's". There is NO good argument for middleboxes that don't
implement the specification correctly and thus make it very hard to upgrade
protocols.

~~~
tptacek
Whoah, sorry, don't get me wrong: TLS 1.3 and the eradication of RSA is an
unalloyed good thing, and broken middleboxes are bad.

~~~
tialaramex
TLS 1.3 doesn't eradicate RSA it just says you mustn't use it for key
agreement. I'm guessing you knew that but just to be clear for anyone else
reading. If your focus is getting rid of RSA entirely actually TLS 1.3 may
even allow it to stick around a bit longer by reducing how nervous we are
about it. If you care primarily about Forward Secrecy then sure, problem
fixed.

~~~
wolf550e
'tptacek meant "RSA ciphersuites", not "RSA trapdoor function". The cipher
suites that begin with TLS_RSA_* and used RSA encryption to pass key material
from client to server, encrypted with the server's long term key (the key from
the certificate).

------
pas
Any news on encrypted SNI? ( eg [https://tools.ietf.org/html/draft-rescorla-
tls-esni-00](https://tools.ietf.org/html/draft-rescorla-tls-esni-00) [
[https://datatracker.ietf.org/doc/draft-rescorla-tls-
esni/his...](https://datatracker.ietf.org/doc/draft-rescorla-tls-
esni/history/) ] )

~~~
hacknat
Encrypted SNI probably can’t make this version, as it requires a fair bit of
new protocol infrastructure to support. The handshake would have to start with
a generalized untrusted assymetric exchange exchange to transfer the SNI field
then “upgrade” the connection to be trusted and then retroactively tell the
client what the initial “untrusted” key was so that the client can confirm it
didn’t suffer a man in the middle attack during the SNI transfer phase.

All of this is possible and should be done, but I doubt it will make protocol
3.

~~~
rocqua
As far as I know, the SNI field is only used by the server to select what cert
to use and site to serve. So if someone were to MitM the SNI exchange,
presuming they don't have a valid cert, they could only cause the client to
receive a different site (if served with a cert valid for both sites). We can
presume the MitM doesn't have a valid cert, otherwise they could fully MitM
the connection.

To ensure your keys are indeed set up by the trusted party, you need to get
that signed by the server cert, but that is already part of the TLS protocol.
It seems I'm missing something.

~~~
stanleydrew
The danger is not that unencrypted SNI exposes clients to additional MitM
attacks. It just exposes the client's intended domain to everyone on the
connection route. It's an information leak, that's all.

~~~
rocqua
I think OP I replied to stated that encrypting SNI requires MitM mitigations.

~~~
hacknat
Everyone on the connection route would be “in the middle”. The actors to watch
out for are ISPs and CDNs.

------
anonymousiam
Attended this talk yesterday:
[https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Ga...](https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Garc%C3%ADa)

TLS 1.3 is the new secure communication protocol that should be already with
us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that
could potentially allow replay attacks. This is a known issue acknowledged by
the TLS 1.3 specification, as the protocol does not provide replay protections
for 0-RTT data, but proposed countermeasures that would need to be implemented
on other layers, not at the protocol level. Therefore, the applications
deployed with TLS 1.3 support could end up exposed to replay attacks depending
on the implementation of those protections.

This talk will describe the technical details regarding the TLS 1.3 0-RTT
feature and its associated risks. It will include Proof of Concepts (PoC)
showing real-world replay attacks against TLS 1.3 libraries and browsers.
Finally, potential solutions or mitigation controls would be discussed that
will help to prevent those attacks when deploying software using a library
with TLS 1.3 support.

------
tialaramex
Notably the RFC by making this a standard rather than merely the draft we all
expect to become standard (which had been solid for months) removes all the
overrides in the drafts that switch off e.g. downgrade detection. These
overrides were needed in drafts so as to prevent craziness where a draft
changes the protocol in an incompatible way and the anti-downgrade forbids
using TLS 1.2 so then you're screwed.

So even though popular clients, services and libraries had the last draft for
months this will, as I understand it, require a patch to do actual bona fide
TLS 1.3

~~~
ctz
Yep. [https://rustls.jbp.io/](https://rustls.jbp.io/) now supports final
TLS1.3 but you'll be hard-pressed to find a library which negotiates TLS1.3
with it. Give it a few weeks.

------
westurner
Is PKI still an optional feature of TLS? Can one still use self-signed x.509
certificates and have key-signing parties?

