Subject: [TLS] Fwd: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt

From: Vlad Krasnov <[email-masked]>
Date: Thu, 14 May 2015 10:24:03 +0100

Hello all,

This is yet another TLS handshake acceleration method we devised in CloudFlare. 
It parallelizes the TLS handshake with the TCP handshake, by sending part of the data over UDP.

It is extremely easy to implement in software, legacy compatible, does not require any prior communication with the server, and will work with any current or future version of TLS.
The real world savings are a whole RTT in both directions, although over unreliable channels a fallback to legacy protocol may take place, without notable performance penalty.
For session resumption the protocol has essentially 0-RTT (completely absorbed in TCP latency).

Please review and provide your comments.

Thanks,
Vlad

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-vkrasnov-tls-jumpstart-00.txt
> Date: 13 May 2015 20:38:48 BST
> To: "Vlad Krasnov" <[email-masked]>, "Vlad Krasnov" <[email-masked]>
> 
> 
> A new version of I-D, draft-vkrasnov-tls-jumpstart-00.txt
> has been successfully submitted by Vlad Krasnov and posted to the
> IETF repository.
> 
> Name:		draft-vkrasnov-tls-jumpstart
> Revision:	00
> Title:		Transport Layer Security (TLS) Jump Start
> Document date:	2015-05-13
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-vkrasnov-tls-jumpstart-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vkrasnov-tls-jumpstart/
> Htmlized:       https://tools.ietf.org/html/draft-vkrasnov-tls-jumpstart-00
> 
> 
> Abstract:
>   This document specifies an optional behavior of TLS implementation
>   called Jump Start.  It alters the way the initial Client and Server
>   handshake messages reach their destination, but not the protocol
>   data, and can be implemented unilaterally.  The TLS Jump Start
>   feature leads to a latency reduction of one round trip for all
>   handshakes (on average).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 May 2015 01:55:08 +0000

If an adversary just wants to DoS your server, they don't care if you respond or not, and can trivially send thousands of clientHello messages with spoofed IP address.  Or am I missing something obvious?  It's like DNS flooding, but with extra CPU cost, isn't it?

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Vlad Krasnov <[email-masked]>
Date: Fri, 15 May 2015 07:14:26 +0100

The idea is that the server does not have to respond at all. If there is an oncoming attack, the server can operate in legacy mode and the client does not need to know.
It also does not have to respond to every single request. 
Moreover the server can choose the amount of history it wants to keep under normal operation, and to not increase it further, until some are completed or timed out.
Also for ECDHE and regular RSA connection the cost of a ServerHello is negligible.

> On 15 May 2015, at 02:55, Salz, Rich <[email-masked]> wrote:
> 
> If an adversary just wants to DoS your server, they don’t care if you respond or not, and can trivially send thousands of clientHello messages with spoofed IP address.  Or am I missing something obvious?  It’s like DNS flooding, but with extra CPU cost, isn’t it?
>  
> -- 
> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz