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

[Andrei Popov <[e-mail]>]

Will rename, to help avoid confusion.

Thanks,

Andrei

From: Eric Rescorla [mailto:[e-mail]]
Sent: Monday, October 9, 2017 12:23 PM
To: Andrei Popov <[e-mail]>
Cc: IETF Tokbind WG <[e-mail]>; [e-mail]
Subject: Re: AD Review: draft-ietf-tokbind-protocol-15.txt



On Mon, Oct 9, 2017 at 10:49 AM, Andrei Popov <[e-mail]<mailto:[e-mail]>> wrote:
Hi Eric,

Thanks for the review.


  *   Specifically can you verify that you intended to deviate from the TLS data structures?
Yes, TB specs reuse the “TLS Presentation Language”, but we define our own data structures. Where the WG was not satisfied with the TLS-style formatting of values, we changed them. The formats we use are the result of prolonged discussions and represent the current WG consensus.

OK, I've got no problem with that as long as it's intentional


TLS WG RFCs define a lot of generic names such as “ECPoint”. I felt at liberty to redefine them in a different protocol spec produced by a different WG. If you think this is a bad idea, I don’t mind renaming, e.g., “TB_ECPoint”. Should I go ahead and rename?

I think that would be better, but I could live without if you think it's really bad. Minimally I think you need to call it out in the text, though.

-Ekr


Cheers,

Andrei

From: Eric Rescorla [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Saturday, October 7, 2017 12:45 PM
To: IETF Tokbind WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: AD Review: draft-ietf-tokbind-protocol-15.txt


A rich version of this review can be found at:

https://mozphab-ietf.devsvcdev.mozaws.net/D48<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=W856D6FDlIXeYngiYusDRBDzFzkZ3KoCpYqfyojmtqo%3D&reserved=0>
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.
2.       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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-307&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=hVf1650fx3r7Lnbgh32L25JUwx4FnlwQUMEswd0gFGk%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-306&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=lKU4dIN5S4JiWFHTBjw2wHIzB%2BdFeFjQbGB0fuh3Zj0%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-308&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=ctlvGcCUAo4MxrWonLJPyiI6%2FU1g%2FVhWSkpBfG23QXY%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-309&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=PUHGJWU4gXOlvRhShnXDtP6VMgcJ%2FOd7RoTOb3gepik%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-310&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=WuHbRliA%2FMT7fDeLF9PANvQSipnX%2B8HHosNHynuX%2Fcw%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-311&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=44FpSI29Z2%2FOvrzotVZsS4KuD%2FUTbjnehNoEW2Dgzq8%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-317&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=yQiqrG9E9kg9ysxZxb021uA1BvVWn%2Bz5rdBezYsPYbk%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-313&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=Aiu9X1ySApS6NLsMh%2BjUeaqq3TFHrxKZ6bl2h%2B2aSX8%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-324&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=m4gKe%2FdyEYA3ojgkU5Xn%2BxUWw2lPrQhsVGIA%2Bm95VUo%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-314&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=P%2FHkbEIHSyrFl5hhw5T3XkvJhZphC1emZOfMm0ICqk4%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-315&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=TzjkrJWQIH44w9HVNk5efwsNgRbCJdKgyMnTyUVIUuI%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-316&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249789390&sdata=QOLWnvph%2BZvVLXBubWOChrBEZGC3ZxUhyApYg9P%2B7NQ%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-318&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=4i%2BpvrB7mEjtfvTPXtcxCBUJplqS2stDLTEnJ5o%2BJQg%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-319&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=fmKe9GW%2Fk2O9yIMmDzGrqHRDtT7VpxBtD3cfW2gBSI8%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-320&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=VcQfStUVKadYgd4ejNEQCgM9XTlb0vA5dpxhUY5F0rU%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-321&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=k0jq%2BZuyjs%2BCBMDVhpiccoysluaHGrQWFZUG4zmvQjA%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-322&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=sSVc%2FMe8FiUVAgqTUcW9Curq%2FN7q1y2EamFpUCdJVIg%3D&reserved=0>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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48%23inline-323&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=OEhVCzPI%2BunT0vcn6szxljRHSUmn0nXR17xVjQ5MIYg%3D&reserved=0>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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD48&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=IiVTCIVdUTRA2kZaWBlXbc2iEvdDpjPa7DQQp7O2szg%3D&reserved=0>

EMAIL PREFERENCES
https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2Fsettings%2Fpanel%2Femailpreferences%2F&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C37e312945a6b4933d22608d50dbbf2e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636430023249799398&sdata=funLgRZntFDjz%2FQT%2Bg5YC%2Bm%2Br8y1IXOQ2RiSPd4lX0M%3D&reserved=0>

To: ekr-moz, ekr