DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; 
 b=pfEA/eCyXdleFHZwDBzNihrIgn/HwFMYVPmvWchnhHZjhl7deLTITxxHNuuvlQexULgU6MpOXcY4iemzmbFh9OpZUqJdUnKemdtxLKsqTtBjz6N0VPGJKAQ2CJDnkYzYST4cEy4rLhkWep4XVFnMNeVYESEFZWpyOiPpXssypps=;
 h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CABcZeBPHvWF-4RUFqX0cDdaW6dpjt+0fNYyjY1j+vjSVSLuo7Q@mail.gmail.com>
Date: Tue, 13 Mar 2018 09:06:54 +0100
Cc: "<tls@ietf.org>" <tls@ietf.org>, draft-ietf-tls-tls13@ietf.org,
 The IESG <iesg@ietf.org>, Sean Turner <sean@sn3rd.com>,
 tls-chairs <tls-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4D34FDE-76C8-4562-A6F3-6C044CF70DDC@kuehlewind.net>
References: <152044072045.17779.18123788753031746068.idtracker@ietfa.amsl.com>
 <CABcZeBML9yhXvzA53QxVNk0-3pis=8pF9LYzYXqTmUvCaVRisQ@mail.gmail.com>
 <7556C17C-A6F5-4FCD-8FB6-DFC85D1C1E92@kuehlewind.net>
 <CABcZeBPHvWF-4RUFqX0cDdaW6dpjt+0fNYyjY1j+vjSVSLuo7Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3QUTjav6emlGqJWxD13WZ57cReE>
Subject: Re: [TLS] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?=
 =?utf-8?q?etf-tls-tls13-26=3A_=28with_COMMENT=29?=
Precedence: list

Hi Ekr,

just one more comment on this part

> Am 07.03.2018 um 20:03 schrieb Eric Rescorla <ekr@rtfm.com>:
>=20
> > > 3) I know previous versions of TLS didn't say that much either, =
but I
> > > find it a bit wired that there are NO requirements for the =
underlaying
> > > transport in this document. Previous version this at least said in =
the
> > > intro that a reliable transport (like TCP) is assumed, but even =
this
> > > minimal information seems to have gotten lost in this
> > > document. However, I would usually also expect to seen some =
minimal
> > > text about connection handling, e.g. is it okay to transparently =
try
> > > to reestablish the connection by the underlying transport protocol =
if
> > > it broke for some reason? Or it is okay to use the same TCP =
connection
> > > to first send other data and then start the TLS handshake?
> >
> > This is pretty explicitly outside the scope of TLS. It's just the =
job
> > of the underlying transport to simulate a reliable stream. I can add
> > some text that that's expected.
>=20
> If that is the only requirement, it would still be good to spell that =
out.
>=20
>=20
> Sure, I can add something.

Just to double-check, there is also no requirement or maybe recommend to =
not send cleartext and 0-RTT data in the same packet?

Mirja