Re: [TLS] Imported Keys/PR #22

Mohit Sethi M <> Thu, 21 November 2019 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 551D7120926 for <>; Wed, 20 Nov 2019 19:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LLoWY3oy7xZ9 for <>; Wed, 20 Nov 2019 19:06:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEAD5120840 for <>; Wed, 20 Nov 2019 19:06:56 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=HoU8kZNboz/JmftcOYLbkBXE2kFBGN8EfSf6QcAFTMN5cd12Dp4Dk5g5ody344MJq1n2Cn/35PW1X7lDfdgjWWM9Bol6z8qeRtyV3nrJ18EFwUFneYNC9lmH5ASN66hd8MHgWXoaG40PpPEBkN7WQljV/sf0vmahntjqFSQdjDk+T3NVkSGdd0Rxj1xnGh758AWKjHgCHKOFViD9Qs8NVU1AYtNqDehE11Wj5QXx1V6rxuwoH7MSIbeiTnpTIbZJHdXPDGb6BU51IFQjHZ1qXYY3JZ4ZJaSb/j+fOUaVS9H4abHSZPrpdsYsNlz96svTlI159R7HsYbMuPk8rgnryA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z43G92napiBDXx2SrwQssffYL6/skpTZcHrxRhMOwwU=; b=gNZFoh/6IWDi9A57k9keUIz83zbTRz6bj9wcBd4pg5r+gdangRwmYbly4nGDOtLvV40mbrVwoDFLC1PUJeT5fFdEAM/rEIhj/pKsb1tn0hH6Lm9GL/iPCAf2yOwLaUuD9mf5MSAAYCOHDSIGesfWCebcfzBcMQuabw7wpBlWMHy9037RSqS1N96so1UX/yJLSd9KiTc1sYBNQ/u8z0hTQ5Dxpcna+4bViIlggEyl1Iu041Zr/TBFuNUZDtTSC0h/Ft4qVkmzaxAl21uNeOd6gnIFQZl2W84iRvLjrePCzbFqcvIJRVikarUfSmo0UQ7sHVcd3Tu6PrwWaYyZ5evj4Q==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z43G92napiBDXx2SrwQssffYL6/skpTZcHrxRhMOwwU=; b=S9umOv9O+Cy+lgnEt6svTj9JAJ3+gHQUsO0yZUR2ptautEXkddIzbx+493BdIRXT3L/hfUxBPY/rwiAWK/5KPzlHsdIhti0NHozGCLAzAuZR1MAZ9CBbLAw5itjj/SChoW7iyYvLXQu0VDrBD1S60rEziWS6YTe8OFC0BN0+gDo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Thu, 21 Nov 2019 03:06:53 +0000
Received: from ([fe80::88e5:d23a:73a5:b78e]) by ([fe80::88e5:d23a:73a5:b78e%6]) with mapi id 15.20.2474.015; Thu, 21 Nov 2019 03:06:53 +0000
From: Mohit Sethi M <>
To: Eric Rescorla <>, "<>" <>
Thread-Topic: [TLS] Imported Keys/PR #22
Thread-Index: AQHVoBi3NTPXllLVeUmiLUeHaTJXdw==
Date: Thu, 21 Nov 2019 03:06:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a5fd9368-4a91-4dd4-abda-08d76e2fdc70
x-ms-traffictypediagnostic: HE1PR0701MB2956:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(199004)(81166006)(316002)(81156014)(14444005)(66066001)(606006)(65806001)(65956001)(99286004)(110136005)(58126008)(186003)(7736002)(478600001)(36756003)(6246003)(26005)(236005)(6512007)(486006)(6306002)(54896002)(31696002)(86362001)(25786009)(2616005)(476003)(11346002)(446003)(14454004)(8936002)(66946007)(76116006)(2906002)(31686004)(966005)(229853002)(8676002)(91956017)(256004)(66556008)(6116002)(64756008)(5660300002)(6506007)(53546011)(6436002)(71200400001)(71190400001)(76176011)(66476007)(66446008)(6486002)(102836004)(3846002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2956;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: V767AI3kG7V/qOPt6DkcOF+JUE2KtIgjqjiu0NW+iRumldYOkYfcjIpdQ+TZsTa8HrJs6KInpvmZgbIUu2sOo+2euGm703Ko49Leg87nKS/SpRG2j9D4bGx18heMnl/lw2XZyfHpjrVbkVEwjMWYVJ3ipGGDmVb+zZIri9pfXP70xWRSANTBTP+NxDOwy5vsb/8nafgxGS/jlpIyrwVYE6NGREtQ3kL27k0HtvGeYZhxtW87x0Ed3eC0tH8+ApiX5mCWLG4zfbv8f50+/LG5byMsfGTTkK2FmSwpT+RJGlettDOetRk43njbzfJU0kVM+Etl+86pZ8qmJablF9LmlTlHMQPywyfgyRV6oxxOww37MQPtZCbVlgvgVhit9CTCJIy1r76F52jtR6VoWFTRcyGJg+l+KGv/vR0w3oirzbX3SjyFy9ASGgjGfocWJlyDhbRhmD8aBahKE3msxkFf8aX3qcp6usYR3lqjC7srVAk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ac62664d0b488384dfd2e90d40a9033bericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a5fd9368-4a91-4dd4-abda-08d76e2fdc70
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 03:06:53.4775 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bFoRikU0lNOlgWUciGO6aPRljv2jnK+rlRL9GIMLCbM9qmS+cbKgAOrbgiSLSVH6/bfpT79pgg5K4nRsagnAFgzt3POqlxv/DD1Rrnp6WqY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2956
Archived-At: <>
Subject: Re: [TLS] Imported Keys/PR #22
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Nov 2019 03:07:00 -0000

I believe that my pull request was indeed covering the different cases you talk about. See in-line pieces of text from my pull request:

On 11/21/19 10:48 AM, Eric Rescorla wrote:
To recap what I was saying at the microphone earlier today about
selfie/reroute issues, there are actually three separate issues.

- A reflection attack where an outside attacker makes the client also
  act as a server.

- A reroute attack where an outside attacker makes the client talk to
  another server with the same PSK as the intended server.

- An attack where an inside attacker impersonates another attacker
  who also has the PSK.

The reflection attack is a special case of the reroute attack.  The
general solution to the reroute attack is to carry the identities of
the communicating endpoints in the handshake [0]; AFAIK it's not
necessary to have separate keys, though the current text actually
generates distinct keys for each pair as well.  It's not a problem to
have distinct keys, but it's important to know what piece does what.

Selfie attack {{Selfie}} is a special case of the rerouting attack against a group member that can act both as TLS server and client. In the selfie attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint.

Rerouting and selfie attacks can be detected by binding the TLS handshake to globally unique node identifiers using the following context string:
struct {
       opaque client_id<0..2^16-1>;
       opaque server_id<0..2^16-1>;
  } Context;

However, that doesn't generally solve the third class of attack if the
inside attacker is configured with the input key rather than the
fanned out pairwise keys.

When the PSK is a group key: To prevent malicious rerouting in groups, each endpoint needs to know the identifier of the other endpoint with which they want to connect and compare it with the other endpoint’s identifier in context. Of course, this only prevents attacks by non-members; the endpoints that share the group key can always impersonate each other.

The last part was explicitly referring to the case that you can't do much about insider attacks in group PSK scenarios.


[0] As John Mattson has pointed out, you can fix just the reflection
attack by comparing the random values you have outstanding in each

I find the current text in draft-ietf-tls-external-psk-importer inadequate (although I understand that I am in the rough). For example, it doesn't explicitly say that client_mac should never be the same as the server_mac. If the WG wants to address this in a separate document, then so be it. I am happy to help.


TLS mailing list<>