Re: [Unbearable] Artart telechat review of draft-ietf-tokbind-negotiation-12

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 09 May 2018 00:17 UTC

Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E628C12D80F; Tue, 8 May 2018 17:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 4xEt6mS23RJK; Tue, 8 May 2018 17:17:57 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DC212426E; Tue, 8 May 2018 17:17:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TcoI/DyCvi9fUS0f04k6wojPgqgrfLq45DZrqYmH2PM=; b=P8XD0ymDlPXcRQCuPiuC3+WK2TC8ZLsX6hSWtXSgh83Z562V9nV5ktSHq+TSD+wKE+oiQRDvtfXVHPwsnvIbLUtlkWyy+DjLnQhUtXOKxBTX0HIAXV6UHRv+mpXSnj52ndLjSy5WZI8wuhJt7JWdF51oCCEDcfIJAfGi08cSxVY=
Received: from DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) by DM5PR21MB0859.namprd21.prod.outlook.com (10.173.172.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.1; Wed, 9 May 2018 00:17:55 +0000
Received: from DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f]) by DM5PR21MB0507.namprd21.prod.outlook.com ([fe80::49e8:420f:baa2:a62f%6]) with mapi id 15.20.0776.004; Wed, 9 May 2018 00:17:55 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "Matthew A. Miller" <linuxwolf+ietf@outer-planes.net>, "art@ietf.org" <art@ietf.org>
CC: "unbearable@ietf.org" <unbearable@ietf.org>, "draft-ietf-tokbind-negotiation.all@ietf.org" <draft-ietf-tokbind-negotiation.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Artart telechat review of draft-ietf-tokbind-negotiation-12
Thread-Index: AQHT5wwOxO+s6Ar+80uyR+J4oo2PoKQmW7iggAAaaoCAAAsWsA==
Date: Wed, 9 May 2018 00:17:55 +0000
Message-ID: <DM5PR21MB050751117AF4365D48EC88A28C990@DM5PR21MB0507.namprd21.prod.outlook.com>
References: <152581170538.16247.326421324193541615@ietfa.amsl.com> <DM5PR21MB05073538E86E74EE3373B6268C9A0@DM5PR21MB0507.namprd21.prod.outlook.com> <e76c1d2a-6d90-e62b-341e-5af12c493a0f@outer-planes.net>
In-Reply-To: <e76c1d2a-6d90-e62b-341e-5af12c493a0f@outer-planes.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:c::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR21MB0859; 7:k2f+tYemCd0rHs2OTOxEogTwmUFvDcLntaJXT1bsJdQfuFISj/HT/QwnrChFdpUAxyGEm+yCOxuCI7DUMFgElfrqITkBK9Z+Q6jdBopuuf7jatraWIPS7xD910WW4fByg2Zivz1NS21zICRRWgrCMcthCtevSngHuWx6LNFJ8UnuXKcQfb05Oeon1KxUolQUjxkzLHDeZJQIqlux6B6xZNQWqVvvtalFKTHQ1SM6/Al4wLEyXmRgZFwP2wBFHLaE; 20:Rwn+Qz074j0GzIT/5NGvElsQGKGQW1ktfHALBLlScDghTeIYRDM36OTnHDjAtsYrwS+mkRwn0qmS/giprVSdj/vax8It2u/0gGpIZtejEes/XaqU9Apbue/Z7hSzdfs/9K84pnwa22wIQSh7GUrtHWwSIPlwxUnVjv8XBWgJQlw=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7193020); SRVR:DM5PR21MB0859;
x-ms-traffictypediagnostic: DM5PR21MB0859:
x-microsoft-antispam-prvs: <DM5PR21MB08592F0D90CDA913106AA1528C990@DM5PR21MB0859.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(2018427008)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR21MB0859; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0859;
x-forefront-prvs: 0667289FF8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39380400002)(346002)(39860400002)(51914003)(199004)(189003)(13464003)(377424004)(486006)(59450400001)(53936002)(9686003)(11346002)(2906002)(476003)(8676002)(478600001)(6246003)(446003)(86362001)(4326008)(229853002)(81166006)(3280700002)(33656002)(8990500004)(6436002)(72206003)(55016002)(81156014)(5660300001)(68736007)(6506007)(7696005)(76176011)(3660700001)(53546011)(2900100001)(5250100002)(106356001)(86612001)(110136005)(22452003)(46003)(186003)(316002)(99286004)(14454004)(105586002)(7736002)(6346003)(97736004)(305945005)(54906003)(10090500001)(10290500003)(102836004)(6116002)(8936002)(74316002)(2501003)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0859; H:DM5PR21MB0507.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-microsoft-antispam-message-info: pw/qT4hwPeJj9y/ZWRgknSlBRSZ0qk5w4kTKK3xsEGIhRBf4jYob+frctjxk1ugYSVnx25g/NoawrcHLIOA9n+lohixUzJZlaY7LZM1CoRMBFVfH+fzYCm2tviJJiphCZN7uqIdTGs+cMI4K8WwosVFoKnllxzENH26yFiefuelWwGDzC7TFvvmn2q6RS89k
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 79eaba94-190c-4812-0776-08d5b5424fd4
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79eaba94-190c-4812-0776-08d5b5424fd4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2018 00:17:55.4047 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0859
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/o7bC99wJm6nIKg0UTizlNYvP1hU>
Subject: Re: [Unbearable] Artart telechat review of draft-ietf-tokbind-negotiation-12
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 00:18:00 -0000

> Does that mean clients can never require TB, or that such a requirement is enforced somehow at the application layer, or something else?

TB has cryptographic costs associated with it, so a server would only enable TB when there is a benefit (e.g. a server that does not produce or consume tokens would not benefit from TB).
Therefore, it would not make sense for a general-purpose client (such as a Web browser) to require TB on every connection.

Application-specific clients and servers (custom apps) can reject connections without TB, or they can implement a variety of other measures when TB is not negotiated (e.g., issue shorter-lived tokens, require stronger authentication, ...)

I don't think it would be beneficial to specify what different kinds of apps should do when TB cannot be negotiated with a server (except for the protocol error cases, such as the server returning a higher TB version than the one the client advertised).

Cheers,

Andrei

-----Original Message-----
From: Matthew Miller <linuxwolf@outer-planes.net> On Behalf Of Matthew A. Miller
Sent: Tuesday, May 8, 2018 4:13 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>om>; art@ietf.org
Cc: unbearable@ietf.org; draft-ietf-tokbind-negotiation.all@ietf.org; ietf@ietf.org
Subject: Re: Artart telechat review of draft-ietf-tokbind-negotiation-12


On 18/05/08 15:49, Andrei Popov wrote:
> Hi Matthew,
> 
> Thanks for the review and feedback.
> 
> The idea is that:
> - It is an error for the server to respond with a TB protocol version higher than the one advertised by the client. Since the client advertises its highest supported version, it makes no sense for the server to offer a higher version. If this happens, the client MUST terminate the TLS handshake.
> - On the other hand, the server is allowed to offer a lower TB protocol version; if the client happens to support this lower TB version, the connection proceeds with TB. Otherwise, the connection proceeds without TB.
> 

Does that mean clients can never require TB, or that such a requirement is enforced somehow at the application layer, or something else?

From my experience, clients will do what clients will do -- with no guidance on what to do when the client really needs TB but the negotiated support leads to "no TB", there will be several ways clients will implement TB enforcement, which can lead to interoperability problems.  I think we'd rather have some up-front guidance if at all possible.

I'm happy to suggest some text, but it may take me a bit.


- m&m

Matthew A. Miller

> 
> -----Original Message-----
> From: Matthew Miller <linuxwolf+ietf@outer-planes.net>
> Sent: Tuesday, May 8, 2018 1:35 PM
> To: art@ietf.org
> Cc: unbearable@ietf.org; draft-ietf-tokbind-negotiation.all@ietf.org; 
> ietf@ietf.org
> Subject: Artart telechat review of draft-ietf-tokbind-negotiation-12
> 
> Reviewer: Matthew Miller
> Review result: Ready with Issues
> 
> IETF LC End Date: N/A
> IESG Telechat date: 2018-05-10
> 
> Summary:  Ready with a potential issue.
> 
> 
> Major issues:  N/A
> 
> Minor issues:
> 
> In reading the client's processing of the server's "token_binding"
> extension, there seems to be the potential for falling through the cracks with regards to version:
> 
> * client MUST terminate the TLS handshake if the server's
>   TB_version is greater than the client's highest supported
> * client (MUST? SHOULD? MAY?) continue the TLS handshake **without
>   Token Binding** if the server's TB_version is not one the client
>   is willing to use (e.g., lower than the client's minimum
>   acceptable version)
>   
> As written, it seems that a client that requires token binding has to finish TLS negotiation, then reject further interactions at the application level, but it's not clear this is the expected or best approach.  I think it's worth adding at least some language about this scenario.
> 
> Nits/editorial comments:  N/A
> 
>