IETF Logo Mail Archive

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 13 March 2018 08:13 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298512D7E8 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 01:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRP4NQ39nfCE for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 01:13:40 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B859312D7E4 for <tls@ietf.org>; Tue, 13 Mar 2018 01:13:39 -0700 (PDT)
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;
Received: (qmail 4040 invoked from network); 13 Mar 2018 09:06:56 +0100
Received: from 178-83-155-34.dynamic.hispeed.ch (HELO ?192.168.220.145?) (178.83.155.34) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Mar 2018 09:06:55 +0100
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>
X-Mailer: Apple Mail (2.3445.5.20)
X-PPP-Message-ID: <20180313080656.4031.81706@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3QUTjav6emlGqJWxD13WZ57cReE>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2018 08:13:41 -0000

Hi Ekr,

just one more comment on this part

> Am 07.03.2018 um 20:03 schrieb Eric Rescorla <ekr@rtfm.com>:
> 
> > > 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.
> 
> If that is the only requirement, it would still be good to spell that out.
> 
> 
> 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

v2.23.0 | Report a Bug | By Email