Subject: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jun 2017 17:32:11 +1000

FYI,

Mark, Willy, and I have put together a draft that describes how HTTP
works with early data (or 0-RTT).

The main thing of interest is the technique we recommend for avoiding
exposure to replays, particularly given that HTTP is often
intermediated.

If you have specific comments about the draft, I'd appreciate it if
you could take those to the HTTP working group
<mailto:[email-masked]>.  Of course, you should feel free to
start another massive thread about the various ways in which you think
early data represents the beginning of the end for modern
civilization.  That seems to be the usual reaction to this sort of
email.

--Martin

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 22 June 2017 at 16:50
Subject: New Version Notification for draft-thomson-http-replay-00.txt

Name:           draft-thomson-http-replay
Revision:       00
Title:          Using Early Data in HTTP
Document date:  2017-06-22
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-thomson-http-replay-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-http-replay/
Htmlized:       https://tools.ietf.org/html/draft-thomson-http-replay-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomson-http-replay-00

Abstract:
   This document explains the risks of using early data for HTTP and
   describes techniques for reducing them.  In particular, it defines a
   mechanism that enables clients to communicate with servers about
   early data, to assure correct operation.

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 26 Jun 2017 16:03:24 +0900

Hi,

Thank you for working on the I-D.

This is a must-have and I am looking forward to seeing it
standardized. H2O will implement this specification.

One question: is the name `early-data` a good choice?

The reason I raise the concern is because what the header suggest is
if the endpoint has not yet seen a proof (i.e. ClientFinished). The
name "early-data" might be confusing since it may seem to imply _when_
the request has been received rather than the current state of the
connection.

Other than that I the draft looks good to me.

2017-06-22 16:32 GMT+09:00 Martin Thomson <[email-masked]>:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Jun 2017 10:01:31 +0200

Hi Kazuho,

> the request has been received rather than the current state of the

You mean that you'd prefer something indicating that there were unsafe
(ie not yet validated) early data in fact, that's it ?

Willy

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 27 Jun 2017 07:26:10 +0900

Hi Willy,

> (ie not yet validated) early data in fact, that's it ?

Yes. That was my intention.

-- 
Kazuho Oku