IETF Logo Mail Archive

Re: [TLS] Should we require implementations to send alerts?

Benjamin Kaduk <bkaduk@akamai.com> Fri, 18 September 2015 20:34 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DE41B34C4 for <tls@ietfa.amsl.com>; Fri, 18 Sep 2015 13:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.797
X-Spam-Level:
X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 reqJwn9pRV0u for <tls@ietfa.amsl.com>; Fri, 18 Sep 2015 13:34:15 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (unknown [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16F1B34C3 for <tls@ietf.org>; Fri, 18 Sep 2015 13:34:15 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE3934E229; Fri, 18 Sep 2015 20:34:14 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 928C24CD39; Fri, 18 Sep 2015 20:34:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1442608454; bh=2tuJVTQ3QzwwdIbg8aPoXwqr/P1oCnoWRDHYum7LkiM=; l=3720; h=Date:From:To:CC:References:In-Reply-To:From; b=BHdXGEy1sL5xI1ZmAtNYMYMLvaC1R6ivNrJzqcp5+suFZ84eAtyXxYzxOIbP4vbRo UqWjE6UjIi7mbFkvGIxz2p85I0VMT+a/EccnamsRmq1GRN8PaZtCK0fYm4Y07gqvXi 7bSjFE/a0tXx+5zmut3hikfExV+/uhhfhoOUQMxs=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 5FF842026; Fri, 18 Sep 2015 20:34:14 +0000 (GMT)
Message-ID: <55FC7546.9080905@akamai.com>
Date: Fri, 18 Sep 2015 15:34:14 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>
References: <20150917225819.725411A293@ld9781.wdf.sap.corp> <4233694.SipH1XZ6JK@pintsize.usersys.redhat.com> <CAFewVt605ApqUe+X0pX=hECTPy7rVwRV6JmL+xkRHmpEBpoC_g@mail.gmail.com>
In-Reply-To: <CAFewVt605ApqUe+X0pX=hECTPy7rVwRV6JmL+xkRHmpEBpoC_g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090501050007050007080208"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gyxdOLavdocq8MDLVxw3tAClA2o>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Should we require implementations to send alerts?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 18 Sep 2015 20:34:17 -0000

On 09/18/2015 03:24 PM, Brian Smith wrote:
> On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario <hkario@redhat.com
> <mailto:hkario@redhat.com>> wrote:
>
>     On Friday 18 September 2015 00:58:19 Martin Rex wrote:
>
>     So yes, it's no a direct interoperability issue, but it will
>     become one
>     in the future.
>
>
> Given a *conformant* TLS 1.3 implementation, that kind of
> interoperability problem could only happen if the TLS working group
> specifically designed it to happen. In particular, a conformant TLS
> 1.3 implementation must accept larger values of
> ClientHello.client_version.
>

It seems like the unstated point was that writing a conformant TLS 1.3
implementation from scratch is hard, and the only approximation to a
conformance test that we have is interoperability with different TLS 1.3
implementations.  We should be prepared to encounter things that are
almost conformant TLS 1.3 implementations and interoperate fully, but
have subtle bugs that could cause forward-incompatibilities due to
undetected non-conformities.  The paper shield of "but they're not
conformant" does not provide much cover for us to completely ignore this
possibility.

-Ben

v2.23.0 | Report a Bug | By Email