Re: Genart last call review of draft-ietf-tls-exported-authenticator-09
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 19 September 2019 08:55 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2536B120125; Thu, 19 Sep 2019 01:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 xtxyisGYYb04; Thu, 19 Sep 2019 01:55:48 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140043.outbound.protection.outlook.com [40.107.14.43]) (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 A9293120048; Thu, 19 Sep 2019 01:55:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G03eub7TIOeqb9VdNzJ9qvM8bfXH1U2B+HqsISf6SENVJlku3mJic9BfDdTlf6L7br8oE3drrFdShL9eDaZ1Xu5pDIR0jSh1Rx5KJJJqX5sz3l4jj4C6WeoUqUiSVU+O1zBr0TEMU51PAw7tAAVBXBjKsQFyZQJdl8ySgLb1BAQi89CHBwvxZh9/MqOkps87oMrRF/Bi/UQbDVyAshe4EEX+k1rD762zaGdFlNNQhRhfPK6bA3XZL5PNloixFsJera2j9DZGDOJXN4MTja1s68wumrRvs3MCQ4VHEDBjfjMnh41KVg70Mi2mFOcky1klHiFEXr0VaAyuZkU8LBNcGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G5CM5sYaIwOLZvNon5nEPVdfyDqVMEqQfVixbtgAtuM=; b=F9nLXkOqqgBCj9DaAnrSFmD2/1olJnh319mS35LArYxKvX2FBkozecVYWtfATasRMs+TyiaGMgHd8FCLZdmhZHBB2h64c9mR2QRHOFuoBBarj+DBU4cdIgY81js87ha79LGmqoGnzDh2rxbZd0eYMFPtk0ymXgvnvwbeGlsO78SJKj2zgxvAOQ3X7l5aNNHpOhoCN30yIJmPROmrn534wrKBw2fhRMarjhfYNz8hDKOHlFFYXXvZFq0bH0wG0HGBHweV3DU+GNY7MPVruNJqleL6VZ+Q/6TEL8qxBqTrtR59ttOJyf5qL5Vh09fpQeJblLICgVhuX6CWrr5Nxr+4jA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G5CM5sYaIwOLZvNon5nEPVdfyDqVMEqQfVixbtgAtuM=; b=BqxGzriY5eSTZGtKDDj8bzAzWV3QqJ44etEudD4bUekI6AXuXssHAAJo/MrjpYmV6YEk7cQEvUnv/gNgTNwNJfkQjzRh0R+TD2UxpsUexMAKVivdvnFJYxyY9TyV7jC/66StngZga0VNoaF0joaYQOF7sej0tXyLIQkd4OmnJYg=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3305.eurprd07.prod.outlook.com (10.170.248.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.10; Thu, 19 Sep 2019 08:55:24 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::f0a1:2199:7816:ff8d%6]) with mapi id 15.20.2284.009; Thu, 19 Sep 2019 08:55:24 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Nick Sullivan <nick@cloudflare.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-tls-exported-authenticator.all@ietf.org" <draft-ietf-tls-exported-authenticator.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: Genart last call review of draft-ietf-tls-exported-authenticator-09
Thread-Topic: Genart last call review of draft-ietf-tls-exported-authenticator-09
Thread-Index: AQHVbmsQQiMh+1FWRUS8h+cw2bI1hKcy5WaA
Date: Thu, 19 Sep 2019 08:55:24 +0000
Message-ID: <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com>
References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <CAFDDyk8iG0R2rT7x-t7fHkFxcYBBkf8j1-mg1xbexoh8gXts6A@mail.gmail.com>
In-Reply-To: <CAFDDyk8iG0R2rT7x-t7fHkFxcYBBkf8j1-mg1xbexoh8gXts6A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7469a0b1-bb84-4fc7-a653-08d73cdf1c25
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3305;
x-ms-traffictypediagnostic: HE1PR07MB3305:
x-microsoft-antispam-prvs: <HE1PR07MB3305E1CDF4B9BBF615258DB293890@HE1PR07MB3305.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016572D96D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(136003)(396003)(39860400002)(54094003)(199004)(189003)(81156014)(99286004)(6116002)(4326008)(76116006)(66446008)(66476007)(66556008)(64756008)(14454004)(66946007)(8936002)(478600001)(6486002)(33656002)(6916009)(81166006)(7736002)(8676002)(71190400001)(25786009)(476003)(486006)(229853002)(44832011)(186003)(446003)(66066001)(26005)(102836004)(36756003)(11346002)(2616005)(316002)(3846002)(86362001)(54906003)(71200400001)(305945005)(256004)(6512007)(5660300002)(14444005)(2906002)(6436002)(6506007)(76176011)(6246003)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3305; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: h5z6yYVvcmvEf6hYilnzsrrHuvXYkrYeqFAMxV7WxsGimlTuK/FhNWkay4kIpGzee8GbroXbqI33aFY2pkT1+2sTol15Djp2Yn44k6/Hak2nyPx2jkEotFIFF+dXJOFTv5kUZ5MoAr33tK0BxehAtwIM4j3zF+2CXxQV/q0ZBSR4EdFQHsNFu+X4iy+fkUTOnAwuJYFlapft5XvO/9/CtPAroKL2kkdGZcQPIDXCtiOF9RZ9rjvr9gkQ9MmFY68O2OjxOdeMkCym/nSVAj2ZDS/BLksXC+vBRSjSsuOqUwnEoiGhwoXtHpp7kwBHIdfjXMgJKb/nsV0++GKazFmPgvAKjY5nXTNage4JgYLhHmLQ42Mwh/3jf08kLYqAEf1ajn84C3seSbkQnjazMvSEm8lY3a7RORc7T3BPtn5csFg=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A2FF3D52D236F649A4A26F0D55816A43@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7469a0b1-bb84-4fc7-a653-08d73cdf1c25
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 08:55:24.2568 (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: TLAMzD/qLtrN9CjkWZey9wCsecwFn525mDc7ux4KBKCzjjPrlm6hU7S/b7Z4qirRav+MUlR6P2xi9hG+iwObj2OLfuCVXMEICeSMWz+4ABw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3305
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ZwTkQnIzHz750vSafzfP8iqK0Mg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 08:55:51 -0000
Hi Nick, Thanks for your reply! Please see inline. >>MIN_1: >>The last sentence of Section 1 says that the mechanism requires TLS version 1.2 >>or later. Would it be useful to state that in a dedicated Applicability section? > > I'm disinclined to include an applicability section considering how short it would be. > I'm open to being convinced otherwise with examples. If others think it's clear enough (or, that it doesn't need to be that clear, because earlier versions will anyway disappear), I am fine to keep in in Section 1. --- >> MIN_2: >> Can the mechanism be used also for DTLS? > > I think the answer is yes. I don't see any reason to disallow the use of Exported Authenticators in DTLS. Would it be useful to clarify that? --- >> MIN_3: >> The documents talk about additional certificates. If I only have one additional >> certificate, can I use that for multiple authenticators throughout the TLS >> session? > > Yes, there is nothing disallowing the creation of multiple exported authenticators with the same certificate. Would it be useful to clarify that? --- >> MIN_4: >> Section 3 and 4 say that the authenticator request and authenticator SHOULD be >> sent using TLS, and Section 1 says that the proof of authentication can be sent >>out-of-band. I think it would be useful to clarify whether both the >>authenticator request and authenticator can be sent out-of-band ( i.e., not >>using the TLS connection that the additional authentication is associated >>with), and also to state whether it IS allowed to send the authenticator >>request and authenticator on the TLS connection they are associated with. > > Good point. I can clarify this a bit. Both the authenticator and authenticator request can be sent > through either the TLS connection they were derived from or another TLS connection altogether. > The important part is that they are sent over an encrypted and authenticated connection. Thanks! --- >> MIN_5: >> Section 5 talks about an endpoint sending an empty authenticator. But, what if >> the sender of the authenticator request does not receive anything? Does it >> simply move on? Does it terminate the TLS session? Is the action based on local >> policy? > > The TLS layer is stateless. The decision to time out or fail the connection if an authenticator request > is not responded to is left to higher-level protocols that leverage EAs. > >> MIN_6: >> Related to MIN_5, I can't find text about how endpoints inform each other about >> the support of the mechanism, so maybe a few words about that would be useful. >> And some words about backward compatibility with endpoints that don't support >> the mechanism. > > Adding an extension to signal support for exported authenticators was discussed at some point, > but it was decided that the higher-layer application should handle the signaling. > >> MIN_7: >> What happens if the validation of an authenticator fails? Does the requester >> simply move on? Does it terminate the TLS session? Is the action based on local >> policy? > > This is also up to the application-layer protocol. I'll add text covering MIN_5, MIN_6 and MIN_7. Thanks! --- >> ED_1: >> The document uses "session", "TLS connection" and "TLS communication" >> terminology. Is that intentional, or wouuld it be possible to use consistent >> terminology? > Good note. I'll standardize on "connection". Thanks! --- >> ED_2: >> Section 3 says: "The authenticator request is a structured message that can be >> created..." Section 4 says: "The authenticator is a structured message that can >> be exported..." >> >> In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent >> based on an "authenticator request". I wonder if that could be stated already >> in the beginning of Section 4, to further clarify the difference between them. >> E.g., >> >> "The authenticator is a structured message, triggered by an authenticator >> request, that can be exported from either party of a TLS connection." > > The issue is that servers can generate spontaneous exported authenticators without > an authenticator request. Where is this written? Did I miss it? > Given this, the updated sentence would be: > > "The authenticator is a structured message, sometimes triggered by an authenticator > request, that can be exported from either party of a TLS connection." > Which I'm not sure is an improvement to readability. I agree that "sometimes triggered" does not improve readability, but doesn't there still always have to be at least one authenticator request before any authenticator is sent? Regards, Christer
- Genart last call review of draft-ietf-tls-exporte… Christer Holmberg via Datatracker
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg
- Re: Genart last call review of draft-ietf-tls-exp… Nick Sullivan
- Re: Genart last call review of draft-ietf-tls-exp… Christer Holmberg