IETF Logo Mail Archive

Re: [TLS] Separate APIs for 0-RTT

Brian Sniffen <bsniffen@akamai.com> Wed, 14 June 2017 21:38 UTC

Return-Path: <bsniffen@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 1544312922E for <tls@ietfa.amsl.com>; Wed, 14 Jun 2017 14:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 4wX_zrYvbGOv for <tls@ietfa.amsl.com>; Wed, 14 Jun 2017 14:38:49 -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 4A5B91243F3 for <tls@ietf.org>; Wed, 14 Jun 2017 14:38:49 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5ELRbqX027861; Wed, 14 Jun 2017 22:38:44 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=tHqZWC52PbPBPnHDCBK/IQPQfIS93wUBx1vjwqe2O5o=; b=CSi7i8R1/ZGIv6sXlRSdmgo2WspGmkIGEZlluXJOw9ZzmwogBtLVz1nHQlYYUEfY7tty vf5wn4SF2LpESnDgLaKS6YLVyqV60nQpk2i2QYHzKId/9QCbceSOF0OwanmBvFSnCa9p p77AwvgFNqDBshinGdnKqhVeXNaO+ywyz6TTDfOPwb1FAZFwttT/iB2RXghua257EHy5 Wn4q4EuQU12BJvFw2ahU5/m3yjo++TnwDjUGmzFE/a+6HOa3uULe2TAzODZA0Sd2AO1g zl60wZEfPbUByygj/o8TC4QKmd4MMeiKWoZHL0Apkzl/e9x3hgYZepGaE84wPs+8eoYW Aw==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndvfneb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 22:38:44 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5ELaNV5000885; Wed, 14 Jun 2017 17:38:42 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vufbb-1; Wed, 14 Jun 2017 17:38:42 -0400
Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.19.33.3]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 5B5D880052; Wed, 14 Jun 2017 15:38:42 -0600 (MDT)
From: Brian Sniffen <bsniffen@akamai.com>
To: Steven Valdez <svaldez@google.com>, Eric Rescorla <ekr@rtfm.com>, "Salz, Rich" <rsalz@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
In-Reply-To: <CANduzxD4b6eDSG+es3mq1iB9dQ4PM6jXdroiXHFUTyODiP86og@mail.gmail.com>
References: <CABcZeBPkRhjLNT2QKO+DgfjE8-e-KrJ5XOLbA9bR24R1Fd96MQ@mail.gmail.com> <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <CABcZeBMpeBhcKoJYuMwLyER0VBh+RtVr6amWMPos3CJipXYHcA@mail.gmail.com> <CANduzxD4b6eDSG+es3mq1iB9dQ4PM6jXdroiXHFUTyODiP86og@mail.gmail.com>
Date: Wed, 14 Jun 2017 17:38:42 -0400
Message-ID: <m2d1a62qsd.fsf@bos-mpeve.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140356
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140354
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ou5hHQYIiAAGR67JUQPzhNdMLNA>
Subject: Re: [TLS] Separate APIs for 0-RTT
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: Wed, 14 Jun 2017 21:38:51 -0000

Steven Valdez <svaldez@google.com> writes:

> Confirming that BoringSSL is using a single API for early/regular data,
> since we ran into issues/complications with our implementation of dual APIs
> with our use cases.

I predict that those are exactly the places you're going to have later
security incidents.  In particular, the use case of fusing the early and
regular data into a single stream is going to lead to problems like
Triple Handshake.

The history of APIs where some bits have different secrecy, freshness,
or authentication than the rest says they all end up with bugs related
to user assumptions that blur away the difference.

-Brian

-- 
Brian Sniffen <bsniffen@akamai.com>
/(* Akamai - Faster Forward

v2.23.0 | Report a Bug | By Email