Re: [Unbearable] New version of Attested TLS Token Binding

[Andrei Popov <[e-mail]>]

In addition to the more fundamental issues we discussed:
- What are we attesting? 
- Should EKM be involved? 
- Should the extension be signed? 
- What needs to be negotiated and how?

here are some editorial issues I found while reading the spec:

> ...whereby servers can leverage cryptographically-
>	   bound authentication tokens to verify TLS connections.

I'm not sure we can say that TB or bound tokens help verify TLS connections. TB relies on TLS for negotiation and nonce.

>	This is useful for prevention of man-in-the-middle attacks on TLS sessions,...

TB does not prevent MITM attacks on TLS, because a MITM can either prevent parties from negotiating TB or mint bound tokens of its own.

>	2.1.  Token Binding Attestation Registry

This belongs in the IANA section, so that it can be easily found.

Cheers,

Andrei

-----Original Message-----
From: Unbearable <[e-mail]> On Behalf Of Giridhar Mandyam
Sent: Tuesday, July 17, 2018 5:02 PM
To: [e-mail]
Subject: [Unbearable] New version of Attested TLS Token Binding

Hello All,

I hope to discuss this during Friday's meeting.  Some of the major changes since ver. 0.4 and ver. 0.3:

a) Proposal of new TLS extensions codepoint for tokbind sessions that will involve tokbind.extensions
b) Proposal for negotiating use of extensions  as part of TLS handshake
c) Addition of two base attestation types:  Android Keystore and TPMv2, along with verification procedures (heavily leveraged from Webauthn).
d) Proposal of establishment of tokbind attestation registry.

There are some other issues that I would like to get guidance from the group on the topic of tokbind.extensions, including:

a) Should clients advertise supported extensions? 
b) Should servers select extensions that they are interested in, and have the client suppress other extensions?  
c) Should clients just send all extensions that they support?  If so, can servers just ignore extensions in which they have no interest?

And specific to the attestation extension,

d) Should clients advertise the attestation types they support (which may expose some fingerprinting surface)?  Should servers communicate the attestation roots that they support?

-Giri Mandyam

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Tuesday, July 17, 2018 12:52 PM
To: Giridhar Mandyam <[e-mail]>; Jon Azen <[e-mail]>; Laurence Lundblade <[e-mail]>
Subject: New Version Notification for draft-mandyam-tokbind-attest-05.txt


A new version of I-D, draft-mandyam-tokbind-attest-05.txt
has been successfully submitted by Giridhar Mandyam and posted to the IETF repository.

Name:		draft-mandyam-tokbind-attest
Revision:	05
Title:		Attested TLS Token Binding
Document date:	2018-07-17
Group:		Individual Submission
Pages:		10
URL:            https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-mandyam-tokbind-attest-05.txt&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=7iVbWDGYoGe7LqpC9IdqMl0hEtoBHjB97frVvHEX2Bk%3D&amp;reserved=0
Status:         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mandyam-tokbind-attest%2F&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=hWksFyxxMjGhq%2Fe57IEGyiiHpFKmUOxLGzm02eewpXU%3D&amp;reserved=0
Htmlized:       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mandyam-tokbind-attest-05&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=iR6RZq8MUwiyePBEgNhQi0MF3BQF92TKns8Ip255Gsc%3D&amp;reserved=0
Htmlized:       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mandyam-tokbind-attest&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=pr0ccS%2FMllsV5Cvrixl3oFJidNs%2BXs0ekRkoNFE0kBY%3D&amp;reserved=0
Diff:           https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-mandyam-tokbind-attest-05&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=CSRP9cMlllw1Xfn%2BAJI%2B9tfzm02hbvDctRNve3lb9Bs%3D&amp;reserved=0

Abstract:
   Token binding allows HTTP servers to bind bearer tokens to TLS
   connections.  In order to do this, clients or user agents must prove
   possession of a private key.  However, proof-of-possession of a
   private key becomes truly meaningful to a server when accompanied by
   an attestation statement.  This specification describes extensions to
   the existing token binding protocol to allow for attestation
   statements to be sent along with the related token binding messages.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Unbearable mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665040447&amp;sdata=oZPtCiwLy%2FctRkV4PmG6cS7SaiCG5PYWAnLFjTU5fVs%3D&amp;reserved=0