[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, 07 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
- [Unbearable] AD Review: draft-ietf-tokbind-protoc… Eric Rescorla
- Re: [Unbearable] AD Review: draft-ietf-tokbind-pr… John Bradley
- Re: [Unbearable] AD Review: draft-ietf-tokbind-pr… Andrei Popov
- Re: [Unbearable] AD Review: draft-ietf-tokbind-pr… Eric Rescorla
- Re: [Unbearable] AD Review: draft-ietf-tokbind-pr… Andrei Popov