Re: [TLS] comments on draft-balfanz-tls-channelid

[Dirk Balfanz <[e-mail]>]

Jeff, thanks so much for your comments. I'll address all the typos/wording
changes etc. in a new draft. Below my answers to your high-level comments.

On Tue, Apr 30, 2013 at 5:11 PM, =JeffH <[e-mail]>wrote:

> [ for best results use a fixed-pitch font ]
>
> Here's some comments on draft-balfanz-tls-channelid, I hope they're
> helpful.
>
> =JeffH
> ------
>
> High-level comments:
>
> 1. EncryptedExtensions modification to the TLS handshake ought to be split
> out into a separate spec.
>
> 2. What are the ramifications if the TLS WG does not adopt an
> EncryptedExtensions mechanism?  I.e., what are the downsides to the
> "channel id" being publicly exposed, i.e., the security ones as well as the
> privacy implications?
>

I don't believe there should be security implications, but I feel fairly
strongly - for privacy reasons - that the channel id message belongs in the
encrypted part of the handshake. Whether or not that's riding on top of the
EncryptedExtension mechanism (which indeed has been discussed separately)
is something that I'm happy to discuss. I'm planning to go to IETF 87 in
Berlin. Maybe we can discuss there?


> 3. In my view, this spec defines how a TLS client generates and
> subsequently wields a unique client identifier/key with a particular TLS
> server over multiple TLS connections (in parallel and serially). Thus it is
> more about creating a "security association" between the client and server
> (eg, see definitions for the latter, as well as "channel", in RFC4949).
> Thus I would not use the term "channel" for this mechanism. Also, TLS unto
> itself is creating a cryptographic channel between client and server and
> thus using the channel term for this mech seems ripe for confusion.  This
> comment implies some re-writing of the introduction (I've made some modest
> suggestions below).  Perhaps "TLS Security Association ID" (TLS-SAIDs) ?
>

I'm using "channel" in the sense of formal access control logics, for
example as it's used here:
http://homepages.inf.ed.ac.uk/gdp/publications/Calculus_for_Access_Control.pdf(I
don't know what newfangled nomenclature people have introduced in
RFC4949 - can I cite historical precedence? :-)

A channel is something through with a principal can send messages. When you
receive a message, you can tell which channel it has come through. In this
sense, a cryptographic key (that signs messages) becomes a "channel". Yes,
a TLS connection is a channel, but so is the client key we're using here.
The former is a more short-lived channel, the latter is longer-lived. I
think RFC5929 uses "channel" in this sense, too, since it views the
server's keys as a channel (at least for the tls-server-end-point binding
type).


> 4. The lifecycle for the unique client identifier (aka "channel id") ought
> to be more fully discussed/specified in main portion of the spec. Presently
> it's sprinkled in the introduction and the privacy considerations.
>

Ok - I see how it currently reads and will try to make improvements. We
have actually moved in Chrome to not expiring the keys automatically
(although the user can still rotate them through the UI).


>
> 5. There would seem to be considerations for applications in terms of
> reliance on the persistence of a given "channel id" and provisions for the
> "channel id" changing or disappearing, e.g. if an app leverages "channel
> id" to bind long-lived app-layer objects (eg cookies) to the TLS client,
> and these implications/issues should be discussed.
>

Ok - I'll try and add something for that.


> 6. This mechanism should be compared/contrasted with TLS Channel Binding
> RFC5929. They don't appear to be mutually exclusive on first thought. What
> are the semantics if they are both employed by an application?  For what
> might one employ one or the other or both concurrently?
>

In my view this is simply another binding type that could be added to
RFC5929. In RFC5929, there is already a tls-server-end-point binding type
that is simply the hash of the server cert. A channel-id-binding-type could
be defined as the dual of that for the client side. But just as the TLS
spec - not RFC5929 - explains how a server cert is "glued" to a TLS
connection (i.e., only someone possessing the corresponding private key can
"wield" the server cert), we need a different spec - this one, not RFC 5929
- that explains how the channel id keys are "glued" to a TLS connection.
These can all co-exist.

7. This is a "trust on first use (TOFU)" mechanism. This should be
> mentioned/discussed explicitly.
>

It doesn't have to be a TOFU mechanism. I can imagine other protocols that
introduce the channel id in a secure manner to the server. See, e.g.,
http://homes.cs.washington.edu/~aczeskis/research/pubs/czeskis-phoneauth-ccs12.pdf

Dirk.


>
>
> Detailed comments/questions:
>
> > Network Working Group                                         D. Balfanz
> > Internet-Draft                                               R. Hamilton
> > Expires: May 12, 2013                                         Google Inc
> >                                                         November 8, 2012
> >
> >
> >                Transport Layer Security (TLS) Channel IDs
> >                      draft-balfanz-tls-channelid-00
> >
> > Abstract
> >
> >    This document describes a Transport Layer Security (TLS) extension
> >    for identifying client machines at the TLS layer without using bearer
> >    tokens.
> >
> snip
> >
> > Table of Contents
> >
> >    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
> >    2.  Why not client certificates  . . . . . . . . . . . . . . . . .  4
> >    3.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  5
> >    4.  Channel ID Extension . . . . . . . . . . . . . . . . . . . . .  6
> >    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
> >    6.  Privacy Considerations . . . . . . . . . . . . . . . . . . . .  9
> >    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
> >    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
> >      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
> >      8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
> >    Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12
> >    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
> >
> snip
> >
> > 1.  Introduction
> >
> >    Many applications on the Internet use _bearer tokens_ to authenticate
> >    clients to servers.  The most prominent example is the HTTP-based
> >    World Wide Web, which overwhelmingly uses HTTP cookies to
> >    authenticate client requests.  Other examples include OpenID or SAML
> >    assertions, and OAuth tokens.  All these have in common that the
> >    _bearer_ of the HTTP cookie or authentication token is granted access
> >    to a protected resource, regardless of the channel over which the
> >    token is presented, or who presented it.
> >
> >    As a result, an adversary that manages to steal a bearer token from a
> >    client can impersonate that client to services that require the
> >    token.
> >
> >    This document describes a light-weight mechanism for establishing a
> >    _cryptographic channel_ between client and server.
>                     ^^^^^^^                           ^
>                security association        , denoted by an ECC public key.
>
>
> >                                                        A server can
>                                                          ^
>                                                    For example,
>
>
> >    choose to bind authentication tokens to this channel, thus rendering
>                                                   ^^^^^^^
>                                                 association
>
> >    the theft of authentication tokens fruitless - tokens must be sent
> >    over the channel to which they are bound (i.e., by the client to
> >    which they were issued) or else they will be ignored.
>
> suggest..
>
>   ..tokens bound to the security association will be ignored by the
>   if they are not sent by the legitimate client.
>
> >
> >    This document does not prescribe _how_ authentication tokens are
> >    bound to the underlying channel.  Rather, it prescribes how a client
> >    can establish a long-lived channel with a server.
>                                 ^^^^^^^
>                            security association
>
> >                                                         Such a channel
>                                                                ^^^^^^^^^
>                                                           an association
>
> >    persists across HTTP requests, TLS connections, and even multiple TLS
> >    sessions, as long as the same client communicates with the same
> >    server.
> >
> >    The basic idea is that the client proves, during the TLS handshake,
> >    possession of a private key.  The corresponding public key becomes
> >    the "Channel ID" that identifies this TLS connection.  Clients should
> >    re-use the same private/public key pair across subsequent TLS
> >    connections to the same server, thus creating TLS connections that
> >    share the same Channel ID.
> >
> >    Using private/public key pairs to define a channel (as opposed to,
> >    say, an HTTP session cookie) has several advantages: One, the
> >    credential establishing the channel (the private key) is never sent
> >    from client to server, thus removing it from the reach of
> >    eavesdroppers in the network.  Two, clients can choose to implement
> >    cryptographic operations in a secure hardware module, which further
> >    removes the private key from the reach of eavesdroppers residing on
> >    the client itself.
> >
> snip
> >
> > 2.  Why not client certificates
> >
> >    TLS already supports a means of identifying clients without using
> >    bearer tokens: client certificates.  However, a number of problems
> >    with using client certificates motivated the development of an
> >    alternative.
> >
> >    Most importantly, it's not acceptable for a client identifier to be
>
> what are the threats if a long-term, asymmetric-key-based client
> identifier is sent in the clear during TLS handshake?  Is it mostly a
> privacy concern?  Or is it because of anticipated use cases of binding
> app-layer info to the TLS layer?
>
>
>
> >    transmitted in the clear and client certificates in TLS are sent
> >    unencrypted.  Although we could also define a change to the TLS state
> >    machine to move the client certificates under encryption, such
> >    changes eliminate most of the benefits of reusing something that's
> >    already defined.
> >
> >    TLS client certificates are also defined to be part of the session
> >    state.  This turns session resumption secrets into equivalent barer
>                                                                    ^^^^^
>                                                                   bearer
> >    tokens; completely defeating our objectives.
>
> I'm curious here...  RFC5246 Appendix F.1.4. indicates..
>
>    When a connection is established by resuming a session, new
>    ClientHello.random and ServerHello.random values are hashed with the
>    session's master_secret.  Provided that the master_secret has not
>    been compromised and that the secure hash operations used to produce
>    the encryption keys and MAC keys are secure, the connection should be
>    secure and effectively independent from previous connections.
>
> ..so I'm not sure how "session resumption secrets" are "equivalent bearer
> tokens" ?
>
>
>
> >
> >    Client-certificates typically identify a user, while we seek to
> >    identify machines.  Since they are not, conceptually, mutually
> >    exclusive and as only a single client certificate can be provided in
> >    TLS, we don't want to consume that single slot and eliminate the
> >    possibility of also using existing client certificates.
> >
> >    Client certificates are implemented in TLS as X.509 certificates and
> >    we don't wish to require servers to parse arbitrary ASN.1.  ASN.1 is
> >    a complex encoding that has been the source of several security
> >    vulnerabilities in the past and typical TLS servers can currently
> >    avoid doing ASN.1 parsing.
> >
> >    X.509 certificates always include a signature, which would be a self-
> >    signature in this case.  Calculating and transmitting the self-
> >    signature is a waste of computation and network traffic in our use.
> >    Although we could define a null signature algorithm with an empty
> >    signature, such deviations from X.509 eliminate many of the benefits
> >    of reusing something that is already implemented.
> >
> >    Finally, client certificates trigger significant server-side
> >    processing by default and often need to be stored in their entirety
> >    for the duration of the connection.  Since this design is intended to
> >    be widely used, it allows servers to retain only a cryptographic hash
> >    of the client's public key after the handshake completes.
> >
> snip
> >
> > 4.  Channel ID Extension
> >
> >    A new extension type ("channel_id(TBD)") is defined and MAY be
> >    included by the client in its "ClientHello" message.  If, and only
> >    if, the server sees this extension in the "ClientHello", it MAY
> >    choose to echo the extension in its "ServerHello".  In both cases,
> >    the "extension_data" field MUST be empty.
> >
> >    enum {
> >      channel_id(TBD), (65535)
> >    } ExtensionType;
> >
> >    A new handshake message type ("encrypted_extensions(TBD)") is
> >    defined.  If the server included a "channel_id" extension in its
> >    "ServerHello" message, the client MUST verify that the selected
> >    cipher suite is sufficiently strong.  If the cipher suite provides <
> >    80-bits of security, the client MUST abort the handshake with a fatal
> >    "illegal_parameter" alert.  Otherwise, the client MUST send an
> >    "EncryptedExtensions" message after its "ChangeCipherSpec" and before
> >    its "Finished" message.
> >
> >    enum {
> >      encrypted_extensions(TBD), (65535)
> >    } HandshakeType;
> >
> >    Therefore a full handshake with "EncryptedExtensions" has the
> >    following flow (contrast with section 7.3 of RFC 5246 [RFC5246]):
> >
> >    Client                                               Server
> >
> >    ClientHello (ChannelID extension)   -------->
> >                                                    ServerHello
> >                                          (ChannelID extension)
> >                                                   Certificate*
> >                                             ServerKeyExchange*
> >                                            CertificateRequest*
> >                                 <--------      ServerHelloDone
> >    Certificate*
> >    ClientKeyExchange
> >    CertificateVerify*
> >    [ChangeCipherSpec]
> >    EncryptedExtensions
> >    Finished                     -------->
> >                                             [ChangeCipherSpec]
> >                                 <--------             Finished
> >    Application Data             <------->     Application Data
> >
> >    An abbreviated handshake with "EncryptedExtensions" has the following
> >
> >
> >
> > Balfanz & Hamilton        Expires May 12, 2013                  [Page 6]
> >
> > Internet-Draft               TLS Channel ID                November 2012
> >
> >
> >    flow:
> >
> >    Client                                                Server
> >
> >    ClientHello (ChannelID extension)    -------->
> >                                                    ServerHello
> >                                          (ChannelID extension)
> >                                             [ChangeCipherSpec]
> >                                  <--------            Finished
> >    [ChangeCipherSpec]
> >    EncryptedExtensions
> >    Finished                      -------->
> >    Application Data              <------->    Application Data
> >
> >    The "EncryptedExtensions" message contains a series of "Extension"
> >    structures (see section 7.4.1.4 of RFC 5246 [RFC5246]
>
> the below should be separate section...
>
>
> >    If the server included a "channel_id" extension in its "ServerHello"
> >    message, the client MUST include an "Extension" with "extension_type"
>
> suggest..
>
> ..the client MUST include, within the EncryptedExtensions message, an
> "Extension" with "extension_type"...
>
>
>
>
> >    equal to "channel_id(TBD)".  The "extension_data" of which has the
> >    following format:
> >
> >    struct {
> >      opaque x[32];
> >      opaque y[32];
> >      opaque r[32];
> >      opaque s[32];
> >    } ChannelIDExtension;
> >
> >    The contents of each of "x", "y", "r" and "s" is a 32-byte, big-
> >    endian number.  The "x" and "y" fields contain the affine coordinates
> >    of a P-256 [DSS] curve point.
>
> you mean that the "x" and "y" fields (of the ChannelIDExtension struct)
> contain the  affine coordinates of a P-256 [DSS] curve point comprising an
> ECC public key "Q" ?
>
> [ where Q = dG, d = ECC private key, G is the curve base point, and other
> elliptic curve "domain parameters" are as given in [DSS] for curve P-256,
> and the key pair is generated according to appendix B.4 in [DSS] aka
> FIPS-186-3 ? ]
>
> So Q = (x,y) is the "channel id" per se ?  It should be made explicit.
>
>
> What's the lifecycle management of this identifier (ie "Q")?  Is the TLS
> server (or the server-side app running on top of it) to remember this
> identifier?  Is it to be mapped to other client-side identifying
> information eg IP address, user data (eg account name), etc ?   Even though
> this I-D is just specifying the identifier and proof-of-possession
> mechanism (aka "holder of key"), some modest discussion of example use
> cases (beyond the mention of binding to "authentication tokens" that
> appears in the Introduction) would be helpful.
>
> Presumably the TLS client stores this identifier keyed by TLS server
> domain name and re-uses it in future TLS connections to that server (the
> "storage model" needs to be discussed/specified)?  When might a TLS client
> change an established identifier?
>
>
> (Some mention of these lifecycle items is given in the PrivCons section
> below)
>
> Is it to be remembered on first use?  Is it to be updated in the
> server-side store upon it changing?  What are this identifier's overall
> semantics?
>
>
>
> >    The "r" and "s" fields contain an
> >    ECDSA [DSS] signature by the corresponding private key of "TLS
> >    Channel ID signature\x00"
>
> suggest..
>
>
>   The "r" and "s" fields contain an ECDSA [DSS] signature by the
>   corresponding private key over this US-ASCII string (not including
>   quotes, and where "\x00" represents an octet containing all zero bits):
>
>       "TLS Channel ID signature\x00"
>
>
> ..although we should probably use ABNF (or the RFC5246 notation) to define
> this string and its concatenation with the handshake message hashes.
>
>
> >                            followed by the handshake hash(es) prior to
> >    the "EncryptedExtensions" message.
>
> hashes of both the client-sent and server-sent handshake messages, as seen
> by the client?
>
>
>
> >
> >    Unlike many other TLS extensions, this extension does not establish
> >    properties of the session, only of the connection.  When session
> >    resumption or session tickets [RFC5077] are used, the previous
> >    contents of this extension are irrelevant and only the values in the
> >    new handshake messages are considered.
>
> but presumably the same (long-lived?) TLS client identifier Q = (x,y)
>  used and only (r,s) are different ?
>
> Or are new values for all of {x,y,r,s} calculated?  [ "no" is implied by
> the Introduction and Priv. Cons. ]
>
>
>
>
> > 5.  Security Considerations
> >
> >    There are four classes of attackers against which we consider our
> >    security guarantees: passive network attackers, active network
> >    attackers, active network attackers with misissued certificates and
> >    attackers in possession of the legitimate server's private key.
> >
> >    First, we wish to guarantee that we don't disclose the Channel ID to
> >    passive or active network attackers.
>
> why?  simply for privacy reasons?
>
> Or is the main concern that the "channel id" will be used by app layers,
> eg in HTTP cookies, in order to bind objects to a particular TLS
> client-server pair, and thus the "channel id" should be protected as a
> secret?
>
> If the "channel id" is simply included in cookies, and those cookies are
> leaked in the clear (which is not uncommon for a variety of reasons), then
> the "channel id" will potentially be divulged in any case.
>
> Since the channel id is a public key, the server could include some nonce,
> encrypted by the channel id key, in messages to the client, the client
> could decrypt it, then encrypt the nonce with its private key, and include
> that on messages back to the server, which the server could decrypt with
> the client's public key and verify. doing something like that could help
> keep the channel id itself out of these messages and their potentially
> leaky components (such as cookies)
>
> if servers who rely upon the Channel ID always do so with a corresponding
> proof-of-possession of the private key on the part of the TLS client (and
> they perform the requisite checks), then what are the security (as opposed
> to privacy) issues if the Channel ID is observable by others?  I suppose it
> depends on the app-layer use cases employing the "channel id".
>
>
> >    We do this by sending a
> >    constant-length Channel ID under encryption.  However, since the
> >    Channel ID may be transmitted before the server's Finished message is
> >    received, it's possible that the server isn't in possession of the
> >    certificate that it presented.
>
> do you mean in possession of the corresponding private key (to the cert it
> presented) ?
>
>
>
> >                                In this situation, an active attacker
> >    could cause a Channel ID to be transmitted under a random key in a
> >    cipher suite of their choosing.  Therefore we limit the permissible
> >    cipher suites to those where decrypting the message is infeasible.
>
> these TLS cipher suites should be explicitly listed.
>
>
> >
> >    Even with this limit, an active attacker can cause the Channel ID to
> >    be transmitted in a non-forward-secure manner.  Subsequent disclosure
> >    of the server's private key would allow previously recorded Channel
>            ^
>        legitimate
>
>
> >    IDs to be decrypted.
> >
> >    Second, we wish to guarantee that none of the first three attackers
> >    can terminate/hijack a TLS connection and impersonate a Channel ID
> >    from that connection when connecting to the legitimate server.  We
> >    assume that TLS provides sufficient security to prevent a connection
> >    from being hijacked once established by these attackers.
>
> did you mean to say..
>
> We assume that TLS provides sufficient security to prevent these attackers
> from being able to hijack the TLS connection.
>
> ..?
>
>
>
>
> >                                                              An active
> >    attacker with a misissued certificate can successfully terminate the
> >    TLS connection and decrypt the Channel ID.
>
> need a definition and perhaps reference for "mis-issued" cert.
>
>
> >                                              However, as the signature
> >    covers the handshake hashes, and therefore the server's certificate,
> >    it wouldn't be accepted by the true server.
>
> this essentially means that a attacker server with a mis-issued
> certificate cannot act as a real-time TLS proxy between the TLS client and
> legit server, yes?
>
> But otherwise such an attacker could potentially mount an impersonation of
> the legitimate server, yes?
>
> >
> >    Against an attacker with the legitimate server's private key we can
> >    provide the second guarantee only if the legitimate server uses a
> >    forward-secret cipher suite, otherwise the attacker can hijack the
> >    connection.
>
>
> here "connection" means the long-lived "security association" between TLS
> client and legit server, yes?
>
> the known forward-secret TLS cipher suites should perhaps be listed in an
> appendix.
>
>
> >
> snip
> >
> > 6.  Privacy Considerations
> >
> >    The TLS layer does its part in protecting user privacy by
> >    transmitting the Channel ID public key under encryption.  Higher
> >    levels of the stack must ensure that the same Channel ID is not used
> >    with different servers in such a way as to provide a linkable
> >    identifier.  For example, a user-agent must use different Channel IDs
> >    for communicating with different servers.
>
> There's ostensibly privacy implications worth mentioning in that each
> distinct TLS client stack one wields with a particular TLS server will
> generate a distinct "channel id" (TLS-SAID), even if they are "behind" one
> IP address from the server's perspective.
>
> >                                                   User-agents must also
> >    ensure that Channel ID state can be reset by the user in the same way
> >    as other identifiers, i.e. cookies.
>
> Yes, because otherwise this becomes a "super cookie" mech.
>
> This implies dependent app-layers will need to be able to handle
> dynamically changing "channel id" (TLS-SAID)s.
>
>
> >
> >    However, there are some security concerns that could result in the
> >    disclosure of a client's Channel ID to a network attacker.  This is
> >    covered in the Security Considerations section.
> >
> snip
> >
> > 7.  IANA Considerations
> >
> >    This document requires IANA to update its registry of TLS extensions
> >    to assign an entry referred to here as "channel_id".
> >
> >    This document also requires IANA to update its registry of TLS
> >    handshake types to assign an entry referred to here as
> >    "encrypted_extensions".
> >
> snip
> >
> > 8.  References
> >
> > 8.1.  Normative References
> >
> >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> >               Requirement Levels", BCP 14, RFC 2119, March 1997.
> >
> >    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
> >               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
> >
> >    [DSS]      National Institute of Standards and Technology, "FIPS
> >               186-3: Digital Signature Standard".
>                                                   ^
>                                           Issued June, 2009
>
>
> >
> > 8.2.  Informative References
> >
> >    [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
> >               "Transport Layer Security (TLS) Session Resumption without
> >               Server-Side State", RFC 5077, January 2008.
> >
> >
> <snip/>
>
> ---
> end
>
>
>
>