Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 01 October 2018 15:51 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A216C130EB7; Mon, 1 Oct 2018 08:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 osOjUpV8vIfd; Mon, 1 Oct 2018 08:51:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35A2130EC9; Mon, 1 Oct 2018 08:51:09 -0700 (PDT)
X-AuditID: 12074422-78dff700000033b4-b5-5bb2426ae1d8
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A2.B5.13236.B6242BB5; Mon, 1 Oct 2018 11:51:07 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w91Fp40M003666; Mon, 1 Oct 2018 11:51:05 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w91Fovqa023502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Oct 2018 11:51:02 -0400
Date: Mon, 01 Oct 2018 10:50:57 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ted Lemon <mellon@fugue.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, dnsop@ietf.org
Message-ID: <20181001155057.GB24695@kduck.kaduk.org>
References: <153722313579.24693.3934580046706676407.idtracker@ietfa.amsl.com> <D11FA275-9CC3-470D-B8EC-3EE5ED38C20E@fugue.com> <82F4E1E2-2672-4C3A-B51F-67BFB2E4EEFC@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <82F4E1E2-2672-4C3A-B51F-67BFB2E4EEFC@fugue.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixCmqrZvttCna4NJrE4s32yexWNx9c5nF Yt76NUwWM/5MZLZ4s+YIk8W0ts3MDmweTReWsXvsnHWX3WPJkp9MAcxRXDYpqTmZZalF+nYJ XBm7jl9gLdgoWHHlx3HmBsYLvF2MnBwSAiYSC98sYAOxhQQWM0ls+qHfxcgFZG9glPhy7T4b hHOFSWLCij7GLkYODhYBFYld39xAGtiAzIbuy8wgtoiAgsTcM2uYQOqZBRYxStxZcZMJJCEs kCnR1LWQHcTmBdp25vciRoihmxklNp47yAqREJQ4OfMJC4jNLKAu8WfeJWaQZcwC0hLL/3FA hOUlmrfOBlvGKWAr8WTfbrCZogLKEnv7DrFPYBSchWTSLCSTZiFMmoVk0gJGllWMsim5Vbq5 iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxhBkcDuorSDceI/r0OMAhyMSjy8DPKbooVYE8uK K3MPMUpyMCmJ8uqJAYX4kvJTKjMSizPii0pzUosPMUpwMCuJ8O4EKedNSaysSi3Kh0lJc7Ao ifNObFkcLSSQnliSmp2aWpBaBJOV4eBQkuCtcARqFCxKTU+tSMvMKUFIM3FwggznARqeBVLD W1yQmFucmQ6RP8VozNH29PoMZo4OECnEkpeflyolzmsAUioAUppRmgc3DZTMJLL317xiFAd6 TpjXF6SKB5gI4ea9AlrFBLSqsXQDyKqSRISUVAOj2lnd10FKi31/hexflDKR26FArfaf6J1g hsWqVhPUb4VafcxyFPh/floh/5/dWq8XV+aLNe0Mkmm1bK/n6F5UsZ5R+gUP00Ov+ye0ruzf s2ln8VSXyI09X1NM7p++cVssSGaPFttc/QV32hsebml2+T91putSoZ/Fp8Q+ySzpWFRksdtA bgGbEktxRqKhFnNRcSIAf2gr1UEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BpEllnwFtP-M_yA5AIhialjmhrY>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-15: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Oct 2018 15:51:22 -0000

Hi Ted,

On Thu, Sep 27, 2018 at 01:03:21AM -0400, Ted Lemon wrote:
> On Sep 27, 2018, at 12:55 AM, Ted Lemon <mellon@fugue.com> wrote:
> > Yup.   Sorry about that.   I just submitted a new version that I hope addresses this request.
> 
> There's a mistake in the update—while I was working on the new text, I added a caveat about implicit sessions, but didn't notice that that had weakened the requirements on the client.   I've addressed this with the following change, but will wait on your and Mirja's responses before resubmitting:
> 
> -   If a server receives a Fast Open message containing a DSO message
> -   whose primary TLV is not permitted to appear in a Fast Open message,
> -   the server MUST forcible abort the connection.  If a client receives
> -   a Fast Open message containing any DSO message, and there is no
> -   implicit DSO session, the client MUST forcibly abort the connection.
> -   If a server or client receives a Fast Open message that is not a TLS
> -   1.3 message, it MUST forcibly abort the connection.
> +   If a client or server receives a Fast Open message containing a DSO
> +   message whose primary TLV is not permitted to appear in a Fast Open
> +   message, the server MUST forcible abort the connection.  If a client
> +   receives a Fast Open message containing any DSO message, and there is
> +   no implicit DSO session, the client MUST forcibly abort the
> +   connection.  If a server or client receives a Fast Open message that
> +   is not a TLS 1.3 message, it MUST forcibly abort the connection.

The -16 (plus this) look great; exactly what I was looking for.  I'll go
clear my Discuss in the datatracker.

But just to double-check my understanding: the idea is that the TCP Fast
Open payloads will only be used when TLS 1.3 is in use, and some be
something like (client's first handshake flight + early data) and (server's
first handshake flight + 0.5-RTT data), with the DSO operations being in
the early data and 0.5-RTT data records' payloads?

Also, I don't remember if IANA likes to keep columns like our "Fast Open"
one blank for unassigned/reserved ranges.  But presumably they will tell
you :)

Thanks again,

Benjamin