Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 14 August 2019 05:41 UTC

Return-Path: <ilariliusvaara@welho.com>
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 4A3FE12004C for <tls@ietfa.amsl.com>; Tue, 13 Aug 2019 22:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 9Dpf87BP4MjI for <tls@ietfa.amsl.com>; Tue, 13 Aug 2019 22:41:25 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72032120046 for <tls@ietf.org>; Tue, 13 Aug 2019 22:41:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7A468C3F99; Wed, 14 Aug 2019 08:41:22 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 0qZ6_EhD7KY3; Wed, 14 Aug 2019 08:41:21 +0300 (EEST)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 29B4E285; Wed, 14 Aug 2019 08:41:17 +0300 (EEST)
Date: Wed, 14 Aug 2019 08:41:17 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, TLS List <tls@ietf.org>
Message-ID: <20190814054117.GA475347@LK-Perkele-VII>
References: <156563213549.17893.514258464688769886@ietfa.amsl.com> <20190812182519.GA455391@LK-Perkele-VII> <20190814005910.GC30400@akamai.com> <CACsn0cnV720QmDTjwvg+Kk4eH4s4ZPPDT0x2KdHTsdAV7SnVgQ@mail.gmail.com> <20190814011159.GE30400@akamai.com> <CACsn0ckih_0mf28cJ-jB=KT8uZ0JarAN8-Cj2E7SXOj7xnyapA@mail.gmail.com> <20190814013612.GG30400@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190814013612.GG30400@akamai.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HrXTJrJca09oG0YjvSiwzxdoUSY>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 14 Aug 2019 05:41:28 -0000

On Tue, Aug 13, 2019 at 08:36:12PM -0500, Benjamin Kaduk wrote:
> On Tue, Aug 13, 2019 at 06:23:54PM -0700, Watson Ladd wrote:
> > On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk <bkaduk@akamai.com>; wrote:
> > >
> > > On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote:
> > > > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk <bkaduk@akamai.com>; wrote:
> > > > >
> > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote:
> > > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-drafts@ietf.org wrote:
> > > > > I think you need to send it in at least one protocol "response", to
> > > > > confirm support for the extension, even if none of the flags offered
> > > > > require confirmation/echo individually.
> > > >
> > > > I'm not sure this is the case: if in the future we define flags, then
> > > > what is the difference between not understanding any flag and not
> > > > understanding the extension?
> > >
> > > Nothing -- the difference is between understanding the "please frobnitz
> > > my baddle" flag and not understanding it (or the extension, for that
> > > matter).  If "please frobnitz my baddle" is defined such that it appears
> > > in the ClientHello and if the server supports the extension, the server
> > > has the option to send a Thwarp handshake message to the client at any
> > > time post-handshake if the server detects its imminent demise, then the
> > > client that observes "I didn't get a Thwarp" cannot distinguish between
> > > "the server doesn't support the extension" and "the server supports the
> > > extension but is unaware of an imminent demise".
> > 
> > But then you would send the flag back in the Server Hello, no?
> 
> If you define the extension with those semantics, yes.  We've in the
> past wanted to reserve the option of having, well, the
> post_handshake_auth semantics, where the client indicates a capability
> and the server can optionally send a new protocol message.  Would it be
> a huge loss if we didn't have that ability for things that want to use
> the flags extension?  No.

Note that interpretation problems arise anyway if one has at least two
non-acknowledgeable flags:

- Client sends non-acknowledgeable flags X and Y.
- Server does not send flags / sends empty flags.

What do those mean? The case that come to mind are:

- Server does not support X nor Y.
- Server does not support X nor Y, but supports some other flags
  client did not send.
- Server supports X but not Y.
- Server supports Y but not X.
- Server supports both X and Y.


And server advertising some optional feature not releated to client
certificate or resumption is forbidden with regular extensions anyway.
But if one wanted such feature for flags, one would have to allow
"offer messages" (CH and CR) to contain empty flags, yes ("response
messages" (SH, EE, CT) do not need to be empty for that, and ST is
its own special case).


In general, if some extension only makes invalid into valid, one only
needs receiver acknowledgement of support (but may need sender
advertisment if protocol does not support recevier giving such
acknowledgement otherwise). If the extension alters meaning of valid,
one needs bidirectional negotiation anyway.


And there could be extensions that can alter what server sends before
server_hello (e.g., extended_alert that alters the alert format in
compatible way). Those are impossible to bidirectionally negotatiate,
but unidirectional capability advertisment is possible.



-Ilari