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

Benjamin Kaduk <bkaduk@akamai.com> Wed, 14 August 2019 01:36 UTC

Return-Path: <bkaduk@akamai.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 E8A04120045 for <tls@ietfa.amsl.com>; Tue, 13 Aug 2019 18:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 kwMCs2MlXXNR for <tls@ietfa.amsl.com>; Tue, 13 Aug 2019 18:36:18 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 EC1BD1201EA for <tls@ietf.org>; Tue, 13 Aug 2019 18:36:17 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7E1WEND031166; Wed, 14 Aug 2019 02:36:15 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=Pc0MtQv8T8465zAjzj2PJ0r2oPrVrS8PzH8mZUb9s7s=; b=DL4GQQTfZWhlJbVOGaWWu+rOsQ36c9pYwsylj12UC7QET2GuYPa+qNzOLBNPmps9xwzr ssW/FjVPb178ZWqCymOd6F/Kyr3pXQNDj/2dJ8B7KO8vzlZytKgFpQCUKir+WxLt96ja vJ1oQmrqiVWj+4pMTGb6CRwUZ7pVJXpVGW0aa6yYlpBnWthu/51s+d0ZLA/LjzSZahv/ 0bqcGW++R3NuUdyv7yxu3ytCtNstHACtuakTOuqx8t/cFJCCK07sS4K/8WT3Z7ckPkRs s54a/qeQx8ZbyjArnO9ehuuQlS79Fb5ea3WWC/RQbOA7kDG8PBjvSiQIvctOAVLnzeA0 9g==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ubf8jeht1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 02:36:15 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x7E1WB8a014990; Tue, 13 Aug 2019 21:36:14 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint7.akamai.com with ESMTP id 2u9s8w0nj6-1; Tue, 13 Aug 2019 21:36:14 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 81D392006C; Wed, 14 Aug 2019 01:36:14 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hxiCy-0006ay-Vm; Tue, 13 Aug 2019 20:36:13 -0500
Date: Tue, 13 Aug 2019 20:36:12 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, TLS List <tls@ietf.org>
Message-ID: <20190814013612.GG30400@akamai.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACsn0ckih_0mf28cJ-jB=KT8uZ0JarAN8-Cj2E7SXOj7xnyapA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=966 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140014
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-13_07:2019-08-13,2019-08-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 mlxscore=0 mlxlogscore=952 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908140014
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RtW07-45huYFAUl6b2i0lZJkn-0>
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 01:36:29 -0000

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.

-Ben