Re: [TLS] Universal PSKs

Benjamin Kaduk <bkaduk@akamai.com> Fri, 15 June 2018 16:14 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 56527130E85 for <tls@ietfa.amsl.com>; Fri, 15 Jun 2018 09:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 LebqCw3kN0bx for <tls@ietfa.amsl.com>; Fri, 15 Jun 2018 09:13:57 -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 5291B130F37 for <tls@ietf.org>; Fri, 15 Jun 2018 09:13:56 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5FGCI6S002197; Fri, 15 Jun 2018 17:13:54 +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=RXG6Blk3lGANYxyO9Da6bKf2Rm9Xjh+ng4yIZFLRCwA=; b=Wp1iD9SS6gXS86hO4XNE1aue5QIv5fXJ2VMZwB3VWv/obVlAcMx7mGkgoUvxiFxkq3ir bLolKrk499VXizrjAGUS/KNjImZ69XpMVqBtZP900IxCDkKOKbhl0Z2dwiFWaz6cd2iL Rj2WAYMtbGaiyoXXxE8simzSD5rB9yQNhT/hPwLntvW3zi7EuppTy6K0PgXLVMfk3fHP MQ/5/P0/V5HpBy88OUv6qbxUju2uexs0Q43NhP/ctH22BXIlz8lxDX5fzpsGqLaExMzZ R04XdzHe0dt7+NEs3erdV/8ajQN1xBTY22ZeRjh9rAn90nRwdKq2kQI87NEPN8Vnu/RV Jg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2jmfpu05ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 17:13:54 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5FGBSUE021593; Fri, 15 Jun 2018 12:13:53 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jmdfm0v4a-1; Fri, 15 Jun 2018 12:13:53 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2F6BD1FC72; Fri, 15 Jun 2018 16:13:53 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1fTrMG-0007QW-I8; Fri, 15 Jun 2018 11:13:52 -0500
Date: Fri, 15 Jun 2018 11:13:52 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20180615161352.GJ13834@akamai.com>
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> <CAF8qwaDnU20_c4Sdg2GXwoFFk4DN9O72+K6J4FhThJoBtcr-Dg@mail.gmail.com> <CACykbs203X=whe-XcsLbh-ufwQcuJSDMyA7To_h45ok7e5jEBw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACykbs203X=whe-XcsLbh-ufwQcuJSDMyA7To_h45ok7e5jEBw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , 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=459 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150173
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=435 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150173
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PBuYokhC1xVxa8uJ74gBUhAYRJw>
Subject: Re: [TLS] Universal PSKs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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, 15 Jun 2018 16:14:08 -0000

On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote:
> Agreement on a channel binding in the identity would prove, amongst other
> things, agreement on the KDF used to derive the PSK, whereas the TLS
> handshake proves agreement on the PSK itself, but says nothing about the
> derivation of it.
> This way means you don't have to worry about collisions between hash
> functions, as long as the channel binding is correctly constructed.

While this is an interesting way to think about things, it's unclear to me
how general it is for framing the problem.  That is to say, there is not
necessarily a "channel" used to provision what TLS 1.3 calls "external PSKs".
My model for them includes an administrator typing a hex string into a configuration
file on both ends of the connection, or a manufacturer burning a key into ROM
for an IoT device -- what would the "channel" be those cases?  (Or do I completely
misunderstand what you're trying to do?)

-Ben