Re: [TLS] channel id and oob

Dirk Balfanz <balfanz@google.com> Mon, 21 October 2013 23:13 UTC

Return-Path: <balfanz@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD011E867B for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 16:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.311
X-Spam-Level:
X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zycYg4XFZl for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 16:13:03 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 808BC11E86F3 for <tls@ietf.org>; Mon, 21 Oct 2013 16:12:58 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id to1so461855ieb.23 for <tls@ietf.org>; Mon, 21 Oct 2013 16:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4DhMS2g+YZafkX3eCGMIfkjW+6l4pjWmMpZOheM5wkQ=; b=DfSQBq1adbWts+H3NHQRby2tYrfytAyh64y5NYiK4N5BDsth5tVp26fVtJAFZ42qCG DWHCibSugmPpa+kAQpEg7wMO9/WFGoKbwjFVUJONnyX/89nH715wXdT71EoBMDCrDeH2 vlC/ItWfsKyKTgBEQ6lE/V+XaI61ALveCyaQzFdTlldO1cPtXCNrrXHePDeYd1w4OSl7 nhiQQ+3d7xgrnnvvR2GtB9U5ui/I4oql6PQmAgke/vU3K80inHRX1/9LhWAhqDPadh0q qu0zDDODscip+TCNNvNnvD8eXTSJ3Dl+k8R13yBF6OR4akrvW3e96rBr6QRQ9lrGNzfa tuGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4DhMS2g+YZafkX3eCGMIfkjW+6l4pjWmMpZOheM5wkQ=; b=aiph9MehbRcUnoy/Y8s2pN/BbzQVO5mgKdkMkrAr5tCsPZImVVdA2YCNyPyQzHbI51 R5WkHK+yiqf5+Ja6MSoPOrEXO3fniakGymyhrXc+z2eWcl2MdY9YRpj9XyJuGT2dSvar wSbIji4hbgdp/HJttT0wnHQ6JD1Q01LUc1GuIZYPuVoS1Yyx4zN1CfmYSlBotQk1zT0Y DZer0mjWxeEk3skRaKvSyQ8G4BWwRapQnM9mrsJg3UIwdV2fMzjxAi34aPfHbKPq2kS1 VP2kxKQ+93Tnfa7rHXJUle+t+y6edH5z4Qnl5n25EAHa2ublu5k+lFNMqcpGeK42DbvW 5aqQ==
X-Gm-Message-State: ALoCoQkrXunmbMeYN8/QhTimoIt0qdAcobGWTW8ASgLjuTc+oWtaX0LGvKq4W6YRLSxAp6o+yHb/GqV/oevz2ksVD05GQq9dxlAtwtXl1DxPyD3eVak+f/JcZ8Hxhd0SMswHXuffQJ698/3qLIkqNtWhObFMIaMQoK4VhvA8cHnXw7t3pkbH0dEnoeLn+K5f7kJsqJhw5cXf
MIME-Version: 1.0
X-Received: by 10.43.158.10 with SMTP id ls10mr395422icc.20.1382397177840; Mon, 21 Oct 2013 16:12:57 -0700 (PDT)
Received: by 10.64.61.166 with HTTP; Mon, 21 Oct 2013 16:12:57 -0700 (PDT)
In-Reply-To: <526123A7.5050305@gmx.net>
References: <CADHfa2A7jERE=UTudOLcWnH7KppYH+7hcbRJg4aGZuwFeLBqnw@mail.gmail.com> <526123A7.5050305@gmx.net>
Date: Mon, 21 Oct 2013 16:12:57 -0700
Message-ID: <CADHfa2AV31gs=WVrNQJ39NaenD2j4_0_nmE-vDzYGD2qu+E18A@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=001a11c1ead6b9843304e9486c30
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] channel id and oob
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 23:13:05 -0000

On Fri, Oct 18, 2013 at 5:03 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net>; wrote:

> Hi Dirk,
>
> thanks for looking at the two specifications. A few remarks below:
>
>
> On 08/02/2013 12:10 PM, Dirk Balfanz wrote:
>
>> Hi guys,
>>
>> I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and
>> whether it can be applied to the use cases we have in mind for Channel ID.
>>
>> My conclusion is that it can not, or that the necessary modifications to
>> the OOB draft would be too substantial to be considered during Last Call.
>>
>> First, the similarities: both proposals allow the client to prove
>> possession of a key pair. The fact that this proof-of-possession is
>> forthcoming is negotiated using the TLS extension mechanism (during
>> ClientHello/ServerHello).
>>
>> Now for the differences:
>>
>>   * We don't want the client public key to be sent in the clear. It's a
>>
>>     client identifier, and shouldn't be known to anyone but the client
>>     and the server.
>>
>
> This is an aspect the group agreed to solve via a separate extension, if I
> remember it correctly since it has wider applicability than just for these
> documents.
>
> Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting he
> mentioned that this would be one of the features of the new version.


Right. Which is why my take-away was that ChannelID won't be seriously
considered until TLS 1.3.


> Whether it is useful to define an extension that can be used with TLS
> 1.1/1.2 is a decision the ADs and chairs need to make.
>
>
>
>>   * We don't want the proof-of-keypair-possession to be part of the
>>     session state,
>>
>
>
> I am not entirely sure what you mean by "proof-of-keypair-possession to be
> part of the session state".
>

When your TLS terminators resume a session with a client - what do those
terminators tell their backends about the session? If the client proved
possession of a private key/certificate during the original handshake, so
terminators not tell their backends about that key on a resumed session?
For ChannelID, we explicitly _don't_ want them to do that.


>
>  for two reasons:
>
>>       o It blows up the session state, with ramifications on the size of
>>
>>         the fleet of servers that cache this information.
>> Remember that
>>         in our use case, we don't intend this to be used for the
>>         occasional client that wants to use non-password authentication
>>         with the server; it's designed to be used by _every_ client
>>         talking to big service providers like Google. Raw public keys
>>         are of course smaller than full certificates, but they still
>>         represent a significant increase in the size of session state.
>>
>
>
> The document does not require servers to store the received raw public key.
>
>
>        o We don't want someone who is not actually wielding the private
>>
>>         key of the keypair to make it appear to the server as if they
>>         were in control of that private key. Session resumption,
>>         however, gives you that power: Let's assume that the private key
>>         of the keypair sits in a hardware-protected secure element, and
>>         is therefore out of reach of malware. Master secrets and other
>>         session information, however, is very likely kept in RAM and
>>         therefore available to thieves. If such a thief extracts the
>>         session data from the client and resumes the session, the server
>>         will treat the thief as the holder of the original private key.
>>         If the proof-of-keypair possession is explicitly declared not
>>         part of the session, then a client has to re-prove possession of
>>         the keypair even during abbreviated handshakes. Thus, a thief of
>>         session secrets (but not of the private key) won't be able to
>>         convince a server that it is in control of that private key.
>>
>
> You don't have to use session resumption if you do not want.
>

But I do want to use session resumption! It's saves bits during the
handshake. :-)


> I also consider the threat a bit unrealistic. If you assume that the end
> device is compromised then what prevents the malware from obtaining the
> private key before it gets into the hardware-protected secure element.


The key could have been created inside the secure element to begin with.


> I believe in your scenario you are not talking about a long-term ephemeral
> key pair but rather something that is dynamically created on the end device
> or dynamically provisioned.
>
>
>>     The oob-draft keeps the raw key in the session state, thus
>>     inheriting this problem with session state and session resumption.
>>
>
> We actually don't say anything about keeping the key in session state nor
> about session resumption. I consider those aspects implementation and
> configuration issues.
>

That's interesting. I was looking for the part in the TLS spec that says
"thou shall make client certs part of the session state", and indeed
couldn't find it. But in practice, of course that is what people are doing,
right? If your TLS terminators didn't make a client cert part of the
session state, how could you ever resume a session with them and still be
considered authenticated with that client cert?



>
>
>
>>   * Channel ID keys are different from key material sent in the
>>
>>     Certificate message, and the certificate message shouldn't be
>>     overloaded with this new semantics: Key material presented in the
>>     Certificate message (even if it's a raw key) presumably carries some
>>     semantics for the application: "this is a certain user", "this is an
>>     enterprise-issued machine", etc., while the Channel-ID keys are
>>     always self-generated and their semantics include (among other
>>     things) "this is the key that will be nuked when the user presses
>>     the 'reset my browsing state' button". It makes for tricky
>>     implementations when those two different semantics get mapped to the
>>     same protocol message. More importantly, applications may want to do
>>     both: authenticate a user with a client cert, and then set a
>>     channel-bound cookie as a result of the authentication. You can't do
>>     that if you only have one proof-of-possession available in the
>>     handshake.
>>
>
> With the raw public key we actually do not say what identity the key
> refers to.
>

Right - of course not; that kind of stuff doesn't belong in the spec. But
in practice these keys are used for something, and if I want to keep doing
that something, while at the same time do something else (provide key
material to which upper-layer credentials such as cookies can be bound),
then using the same message for those two somethings won't work.


> You are correct that there is an issue if we want to provide two layers of
> authentication within TLS and I am not sure whether that is even in scope
> of your document either since it is not discussed.
>
>
>
>
>> As mentioned above, I don't really see how this issues could possibly be
>> addressed within the draft-ietf-tls-oob-pubkey draft, especially since
>> it's in last-call. Just the first point above alone seemed to be
>> something that folks didn't want to touch until TLS 1.3.
>>
>> Thoughts?
>>
>
> What we could do is the following:
>
>
> a) Brainstorm whether we see the two layers of authentication as a valid
> use case. I don't think we both do but maybe someone else does.
>

Let me address this by starting at the application layer: Let's say we want
a feature in which browsers authenticate themselves to servers. This should
happen transparently so that users aren't bothered by it, but it shouldn't
be so transparent that the user can't change the key material if/when they
want to. So we build this feature into the browser, including all the UI,
and now we're looking for a message in the TLS layer to put that proof of
key possession. The ClientCertificate message immediately comes to mind. So
we'll build our network stack so that the keys (that can be reset by the
user, but will be generated and selected transparently) will be used by the
ClientCertificate message.

Now someone else wants a different application-layer feature: they want CAs
to be able to issue user certificates, users to be able to install them,
explicitly select among them when connecting to a server. Again, the
ClientCertificate message seems like a natural vessel for the proof-of-key
possession that comes with this feature. So now, when we build the network
stack, it looks like the keys used in the ClientCertificate message should
be those installed by user when the receive a certificate from a CA, etc.

It's not so much that I want to do ChannelID and TLS Client Auth _at the
same time_, it's that the ClientCertificate message, and the logic around
it, becomes quite messy if it needs to serve these two different user cases
- perhaps not at the TLS layer itself (maybe that one is just given a key
pair), but someone somewhere will have to decide which keys we're using -
the self-generated transparent ones or the CA-certified ones.

The same is true at the server side. You guys may remember that the first
iteration of this ("TLS-OBC") in fact re-used the ClientCertificate
message. When we realized that we were about to turn on essentially TLS
Client Auth for a substantial fraction of the clients out there, we had to
go inside the network stack on the server and put some logic in there that
said: "if the ClientCertificate message carries one of those transparent
keys that the user can reset whenever they want, do one thing; and if it
carries one of those keys that are certified by a CA, do something else",
which started to become quite messy. We think it's easier to have two
different messages for these.


>
> b) We work on a specification that provides the confidentiality protection
> of information exchanged by the client. This could be useful in a number of
> cases, even work that is currently ongoing in the TLS working group right
> now.
>

I think there have been a couple of attempts in this direction, and the
consensus seems to be that we'll do this in TLS 1.3.


> c) We clarify the issues regarding the session state. I did not occur to
> me that this would be something to write about in the document but maybe it
> is worthwhile to have a discussion about it.
>

Yeah, I'm a bit confused about this. I was a bit surprised to not find more
explicit mention of what it means to resume a session in the TLS spec.
Clearly, a resumed session (from the server's point of view) means "the guy
on the other end knows the same master secret as I do". But in practice it
also means "the guy on the other side wields the private key corresponding
to this certain public key", if that's what was proven during the initial
handshake. If that's something that implementations simply assume without
it being called out in the spec, maybe that's something that we should
think about some more.

Dirk.


>
>
> Ciao
> Hannes
>
>
>> Dirk.
>>
>>
>>
>> ______________________________**_________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>>
>>
>