
TLS 1.3 approved - Shoothe
https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html
======
_wmd
0-RTT sounds nice, until you get to appendix E.5. Everyone should read this:

    
    
        E.5.  Replay Attacks on 0-RTT
    
        Replayable 0-RTT data presents a number of security threats to TLS-
        using applications, unless those applications are specifically
        engineered to be safe under replay (minimally, this means idempotent,
        but in many cases may also require other stronger conditions, such as
        constant-time response).  Potential attacks include:
    
        -  Duplication of actions which cause side effects (e.g., purchasing
           an item or transferring money) to be duplicated, thus harming the
           site or the user.
    
        -  Attackers can store and replay 0-RTT messages in order to re-order
           them with respect to other messages (e.g., moving a delete to
           after a create).
    
        -  Exploiting cache timing behavior to discover the content of 0-RTT
           messages by replaying a 0-RTT message to a different cache node
           and then using a separate connection to measure request latency,
           to see if the two requests address the same resource.
    
        Ultimately, servers have the responsibility to protect themselves
        against attacks employing 0-RTT data replication.  The mechanisms
        described in Section 8 are intended to prevent replay at the TLS
        layer but do not provide complete protection against receiving
        multiple copies of client data.  
    

It seems practically guaranteed a lot of devs will enable it without
understanding the ramifications.. I hope embeddings like Nginx add a nice
configuration interface like "enable_0rtt
YES_I_UNDERSTAND_THIS_MIGHT_BE_INSANE;" or similar. Meanwhile I wonder if
concentrators like Cloudflare will ever be able to support it, without knowing
lots more about the apps they are fronting

I guess e.g. Nginx could also insert an artificial header to mark requests
received as 0-RTT, and frameworks like Django could use that header to require
views be explicitly marked with a decorator to indicate support, or something
like that

~~~
mtgx
Which is why it should have never been implemented in TLS 1.3.

I believe the argument against not doing it was that some companies will just
implement their own protocols instead. Eh, I think the chances of that
happening were pretty slim. Now most of the problems we'll see with TLS 1.3
will likely be related to 0-RTT.

Also, wasn't that basically the same argument for implementing MITM in TLS
1.3? That if they don't do it the banks and middlebox guys will just stick to
TLS 1.2 or whatever?

And who cares about a little bit of an extra HTTPS delay, when just adding
Google analytics and Facebook Pixel to your site can increase the delay by
over 400 ms? Some poor performance tracking tracking scripts add 800 ms on
their own.

~~~
wereHamster
0rtt is still useful for static assets, and generally everything that is
public. I have a handful of static websites (literally static, as in
consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no
longer used to only protect private pages (eg. access to your private emails,
the admin section of a CMS). It's also used for privacy reasons on completely
public websites.

~~~
jensvdh
The content of your page may be encrypted but the DNS lookup isn't

~~~
zackbloom
There's work now with DNS-over-HTTPS to prevent that.

------
namelost
Does someone know what the differences are between the final version and the
draft that Chrome and Firefox enabled in Feb 2017? How much did they have to
change for the middleboxes?

~~~
cesarb
The final version is going to be basically the last draft (draft-ietf-tls-
tls13-28) with a few editorial changes. There's a changelog in the draft:
[https://tools.ietf.org/html/draft-ietf-tls-
tls13-28#section-...](https://tools.ietf.org/html/draft-ietf-tls-
tls13-28#section-1.2)

The question is just which draft Chrome and Firefox were using back then. The
changes for the middleboxes were according to the changelog in draft-22, and
IIRC consisted basically in adding back a few unnecessary fields, and allowing
an useless handshake message (which is ignored by the receiver). The main
trick was IIRC to make all TLS 1.3 connections (resume or not) appear
identical to a TLS 1.2 resume connection.

A more detailed history of all changes to the spec can be found at its git
repository:
[https://github.com/tlswg/tls13-spec/](https://github.com/tlswg/tls13-spec/)

------
swherdman
No banking backdoor either, Sanity won out!

See below if you haven't come across this
[https://www.thesslstore.com/blog/tls-1-3-banking-industry-
wo...](https://www.thesslstore.com/blog/tls-1-3-banking-industry-working-
undermine-encryption/) [https://tools.ietf.org/html/draft-rhrd-tls-
tls13-visibility-...](https://tools.ietf.org/html/draft-rhrd-tls-
tls13-visibility-00)

------
CodeMichael
If I'm not mistaken this means no "authorized" MITM

    
    
      - Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.

~~~
agl
It does not. There are some passive decryption tools that will no longer work
because they functioned by having non-forward-secure connections and the
server's private key installed in the decrypter. (But one can just not support
TLS 1.3 at the server to keep them working.)

MITM proxies, which are trusted by the client and which terminate and recreate
the TLS connection, will continue to function. (Assuming they implemented TLS
1.2 correctly, which some didn't.)

~~~
CodeMichael
Does that assume that all of the components (browser and server) support 1.2
as well? In a theoretical future state if I disable 1.2 on my browser doesn't
that mean I won't trust a MITM box.

~~~
agl
> Does that assume that all of the components (browser and server) support 1.2
> as well?

No: a client, server, and MITM proxy can all be exclusively TLS 1.3 and
everything will still work(+).

(+) as much as it did with TLS 1.2, anyway.

------
lappet
Anyone know what TLS 1.3 offers (or fixes) that TLS 1.2 does not?

~~~
Choco31415
WolfSSL has a short write up on the changes:
[https://www.wolfssl.com/differences-between-tls-1-2-and-
tls-...](https://www.wolfssl.com/differences-between-tls-1-2-and-tls-1-3/)

------
ohnoesjmr
SNI is still in plain text :( They could just hash the SNI and do matching
based on hashes.

~~~
cesarb
That gains nothing, since the attacker can simple connect to the service,
replaying your hash, and see which certificate comes back. Take a look at
[https://tools.ietf.org/html/draft-ietf-tls-sni-
encryption-02](https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02)
which on its section 2 has a long list of requirements a solution should meet;
hashing the SNI fails at least the first two (Mitigate Replay Attacks and
Avoid Widely Shared Secrets).

~~~
xorcist
There's also a limited amount of domains registered, so even if you did
something to prevent hash replays you could just try them all and see which
matches.

------
edwinyzh
I have a dumb question - Can existing clients with the old TLS versions
connect to a server with TLS 1.3?

~~~
mcpherrinm
A TLS server and client can both support multiple versions. Clients which
don't support 1.3 will continue to use 1.2 (or 1.1 or 1.0, if the server still
supports them)

------
rurban
So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be
implemented into the commercial variants, whilst the open source variants will
turn it off by default. Or use it like Cloudflare, in HTTPS without GET params
only.

~~~
geofft
Can you explain how 0-RTT might be used as a back door?

(... edit, actually, I recognize this username from previous nonsensical
discussions about crypto and backdoors:
[https://news.ycombinator.com/item?id=13364173](https://news.ycombinator.com/item?id=13364173)
)

~~~
rurban
Thanksfully those folks easily expose themselves. Calling the Siphash security
theatre senseless explains it also.

