[Unbearable] AD Review: draft-ietf-tokbind-protocol-15.txt

Eric Rescorla <ekr@rtfm.com> Sat, 07 October 2017 19:45 UTC

Return-Path: <ekr@rtfm.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 B8B41134B59 for <unbearable@ietfa.amsl.com>; Sat, 7 Oct 2017 12:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 rI3DMmxIDWWw for <unbearable@ietfa.amsl.com>; Sat, 7 Oct 2017 12:45:19 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BA0134B57 for <unbearable@ietf.org>; Sat, 7 Oct 2017 12:45:17 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id a43so31073014qta.0 for <unbearable@ietf.org>; Sat, 07 Oct 2017 12:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=l1X5XVFq4bXmCHD2WjbJBRBt49Ov/Y6BBncIiUhCAQA=; b=poSP/vfF3XueADBb5/HlrlIyX2tvUesxaoK0fBnNdqoIZ+Eb85qWJ1BODMu7D2B4nR UKmEar/9/NYO02X1TwXxjRrA9hCrwKQLf2MbRPXWdFmzJoSvcWM/5XHe8xQC2wXgLCte x47s2Dw6Y0MvZL5fnWtSlGxnafsJuDcVFXBZkeEi5mAqXgpBtVCMRNaYbD4ZVeGkI51d qZ9lY23u9B6vTgdzaRlbtQ2TDPZeWByS3qW8IBC1/NlNdyMLGb0FzJO38P65LLoD/J3X DZKAa0TRw3cyCuigwvS7T7YvbeYk+TKfS3IaPwZaBaY+KjXYvW9ZfItSogDxXA8ZKKA5 hh/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l1X5XVFq4bXmCHD2WjbJBRBt49Ov/Y6BBncIiUhCAQA=; b=dpcWmajGxiDfxG+mryqUKoozJHQJ1clxyzEXy2VS9YLlrGbAPgWGtPwZVR9JgIyNGY /AqZTaaMb9MzFQE3DhhR32kTgchjY+q3gwY5knLDiGcomRlupOyw7wZkv7ISqBexj9if OrlFOnWi0PvxC5P36x+Ca3vfzUn/y6BlCULQ473MhY6IDj3pxeqY5BUNNY1h8Lx30LiU amLfJuPDtSBaaWrJ3vTu16oyS1MJ6pQ+5cVwMIPyRm6BlqDB7bm4r8KegKy/SjQnitLP FzDJG4j/1snDXduaWg/teXyNwDTwN1LvuhS28B0hdJOQXEIhK0Vyc9kDVfZrmKGwYBid iuUg==
X-Gm-Message-State: AMCzsaV/jlSuvo0eVrWhDMfBLXYQkRSa4yvo7ctvkn9IlHe/z/F1nTPq kSnGWks5m1Nu0yJkrTHuv35t15SDKun4tzGnAFWWHqiQ
X-Google-Smtp-Source: AOwi7QDGYsvCatgOJRx5/kNRX4CB9heZx2COVWeqL6rVYWBLDdiMLn/R3vgrOvnuWonvfShs9jad5twFJ4/mJMYv1Dg=
X-Received: by 10.37.1.7 with SMTP id 7mr4741964ybb.419.1507405516550; Sat, 07 Oct 2017 12:45:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.194 with HTTP; Sat, 7 Oct 2017 12:44:36 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 7 Oct 2017 12:44:36 -0700
Message-ID: <CABcZeBNUx5=WaFv1FdSpCrUR_Cud_y3Z914J40zTezLmaHuuzQ@mail.gmail.com>
To: IETF Tokbind WG <unbearable@ietf.org>, draft-ietf-tokbind-protocol@ietf.org
Content-Type: multipart/alternative; boundary="001a113cfcac58c748055afa32a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/gCWyW5J8GyjsLBVHHrMgaFGB9Ns>
Subject: [Unbearable] AD Review: draft-ietf-tokbind-protocol-15.txt
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: Sat, 07 Oct 2017 19:45:23 -0000

A rich version of this review can be found at:

https://mozphab-ietf.devsvcdev.mozaws.net/D48

   1. If you make an account and login, you can respond to the comments

and we can try to resolve them before you produce a new draft.

   1. When you're ready to produce a new draft, you can either upload

it to the draft repo or send me the pre-draft and either way I'll
take care of getting it uploaded here, so we can see diffs, etc.


This document seems like it is in fairly good shape. See below for
comments. Specifically can you verify that you intended to deviate from the
TLS data structures?

*INLINE COMMENTS*
View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-307>
draft-ietf-tokbind-protocol.txt:111
with the private key. The corresponding public key is included in
the Token Binding identifier structure (described in the Section 3.2
"TokenBinding.tokenbindingid"). Token Bindings are long-lived, i.e.,

the rest of this would be clear if you said "Token Binding ID" here.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-306>
draft-ietf-tokbind-protocol.txt:114
they encompass multiple TLS connections and TLS sessions between a
given client and server. To protect privacy, Token Binding IDs are
never conveyed over insecure connections and can be reset by the user

Can you clarify that while the TB is long-lived, the PoP needs to be
refreshed at least as often as you do a full TLS handshake.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-308>
draft-ietf-tokbind-protocol.txt:121
cryptographic hash) in the token. Later on, when a client presents a
security token containing a Token Binding ID, the server ensures the
ID in the token matches the ID of the Token Binding established with

I would say "verifies that"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-309>
draft-ietf-tokbind-protocol.txt:209
opaque point <1..2^8-1>;
} ECPoint;

ECPoint also exists in RFC 4492, but with different semantics. You should
rename.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-310>
draft-ietf-tokbind-protocol.txt:231
opaque extension_data<0..2^16-1>;
} Extension;
IMPORTANT: this definition conflicts with the RFC5246 Extension type, so
you should rename it, thus allowing a merged grammar.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-311>
draft-ietf-tokbind-protocol.txt:240
TokenBindingID tokenbindingid;
opaque signature<0..2^16-1>; /* Signature over the concatenation
of tokenbinding_type,

Does 0 bytes make sense here

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-317>
draft-ietf-tokbind-protocol.txt:249
TokenBinding tokenbindings<0..2^16-1>;
} TokenBindingMessage;

This zero seems wrong, as you require at least one TokenBinding structure
and those cannot be zero length.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-313>
draft-ietf-tokbind-protocol.txt:264
o referred_token_binding - used when requesting tokens that are
intended to be presented to a different server.

Requesting?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-324>
draft-ietf-tokbind-protocol.txt:275
referred_token_binding. Such a bound token enjoys the protections
discussed below in Section 7 "Security Considerations".
IMPORTANT: This does not appear to be the case. Did the text go missing? In
general, this referred case seems fairly confusing and needs more
explication in this document.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-314>
draft-ietf-tokbind-protocol.txt:282
parameters, the length (in bytes) of the Token Binding public key,
and the Token Binding public key itself. Token Binding ID can be
obtained from the TokenBinding structure by discarding the Token

Nit: "The Token Binding ID"

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-315>
draft-ietf-tokbind-protocol.txt:296
define Token Binding keys using other elliptic curves with their
corresponding signature and point formats.
IMPORTANT: As read, this is a different format than that in RFC 4492,
because it does not include the type field required by X9.62. I have two
comments about this:

   1. It seems unwise to use a different format than TLS. Was that
   intentional?
   2. If the WG has consensus to do so, that should be called out very
   clearly.


View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-316>
draft-ietf-tokbind-protocol.txt:319
[FIPS.186-4.2013]. R and S are encoded in big-endian format,
preserving any leading zero bytes.
IMPORTANT: This is also a different format than that specified in RFC 4492.
See the above comments.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-318>
draft-ietf-tokbind-protocol.txt:394
keys MUST NOT be broader than the scope of the tokens, as defined by
the application protocol.

I find this a little hard to read. I think what you're saying is that (for
instance) in HTTP you need to scope the key no more widely than the cookie?

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-319>
draft-ietf-tokbind-protocol.txt:455
be rejected by the server. The effect of this is application-
specific, e.g. failing requests, a requirement for the client to re-
authenticate and present a different token, or connection

Nit: "e.g." has a comma after it.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-320>
draft-ietf-tokbind-protocol.txt:462
Security tokens can be bound to the TLS layer in a variety of ways:
by embedding the Token Binding ID or its cryptographic hash in the
token, or by maintaining a database mapping tokens to Token Binding

This isn't a binding to the TLS layer but rather a binding to the Token ID,
I think.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-321>
draft-ietf-tokbind-protocol.txt:514
An initial set of registrations for this registry follows:

These registration lists would benefit from some judicious whitespace. E.g.,

Value: 0
Description: rsa2048_pkcs1.5
Specification: this document

Value: 1

Or alternately:

Value: 0

Description: rsa2048_pkcs1.5

Specification: this document


Value: 1


View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-322>
draft-ietf-tokbind-protocol.txt:615
The manner in which a token is bound to the TLS layer is application-
defined and beyond the scope of this document. However, the
resulting bound token needs to be integrity-protected, so that an

This doesn't seem right: the binding is provide by the EKM signature.

View Inline <https://mozphab-ietf.devsvcdev.mozaws.net/D48#inline-323>
draft-ietf-tokbind-protocol.txt:643
mode where they don't store or use tokens supplied by the server,
e.g. "in private" browsing. When operating in this special privacy
mode, applications SHOULD use newly generated Token Binding keys and

Nit: "e.g." has a comma after it.

*REPOSITORY*
rIETFREVIEW ietf-review

*REVISION DETAIL*
https://mozphab-ietf.devsvcdev.mozaws.net/D48

*EMAIL PREFERENCES*
https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/

*To: *ekr-moz, ekr