Update on Origin-Bound Certificates: Now called "Channel ID"

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Update on Origin-Bound Certificates: Now called "Channel ID"

Dirk Balfanz
Hello everybody, 

As you might have noticed, I have let the TLS-Origin-Bound Certificates (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft expire. The reason for this is that we (i.e., Google) had implemented TLS-OBC as described in the draft (in Chrome and server-side), and we weren't too happy with it. There were a few of problems:

(1) Client certificates are part of the session state. Not only does that mean that the session state is now considerably bigger than it used to be, it also means that anyone that can steal session secrets (malware on the client) can make it look to the server as if they were in possession of the client's private key, even if that private key sits in a TPM on the client. 

(2) The logic in the client and server that treated OBCs and normal client certs differently, even though they were delivered through the same kind of Certificate message, turned out to be a little more complex that we wanted it to be.

(3) To keep the public key of the client (which acts like a machine identifier) away from prying eyes, we had to entangle the TLS-OBC extension with another extension that reordered handshake messages (and sent the Certificate message after the ChangeCipherSpec message). That added further ugly complexity.

(4) The main use case for this was to be able to "channel-bind" cookies. Cookies, however, can be set across more than just a web origin. When the underlying transport uses different client keys for different origins inside the same TLD, then we can't bind a domain cookie to the underlying TLS channel.

(If you were at IETF 85 you might have seen Adam give a short talk about this.)

To fix all this, we wrote a new proposed spec: http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

This spec is silent on the scope of the keys (but in practice we expect browsers to use eTLD+1 now instead of more fine-grained origins), and addresses all the other issues explicitly: the Channel IDs are not part of the TLS session state, and are exchanged after encryption is turned on.

A comment on the new name: One of the ways the new spec is simpler than the old one is that there are no more X.509 certs involved in proving possession of the client key - so there goes the "C(ert)" in the "OBC" acronym. Because of the agnosticism of the new spec toward the scope of the client keys, there is also no "O(rigin)" anymore. Hence, we needed a new name.

You can play with this proposed mechanism by getting Chrome 24 (just released to the beta channel), and observing its connections to Google web properties.

Thoughts?

Cheers, 

Dirk.


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Nikos Mavrogiannopoulos
On 11/08/2012 10:22 PM, Dirk Balfanz wrote:

> Hello everybody,


Hello,
 Some comments/questions inline.

> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft

> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
>
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.


How is that? Do you mean by session resumption? Isn't it the same on the
current draft?

> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.
>
> A comment on the new name: One of the ways the new spec is simpler than the
> old one is that there are no more X.509 certs involved in proving
> possession of the client key - so there goes the "C(ert)" in the "OBC"
> acronym. Because of the agnosticism of the new spec toward the scope of the
> client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
> name.


The approach actually looks like a prime user of the
draft-ietf-tls-oob-pubkey extension that allows to send the
SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
allows any type of client public key, instead of sticking to a fixed
ECDSA curve? No additional extension would be required.

regards,
Nikos
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7

On Nov 8, 2012 5:04 PM, "Nikos Mavrogiannopoulos" <[hidden email]> wrote:
>
> On 11/08/2012 10:22 PM, Dirk Balfanz wrote:
>
> > Hello everybody,
>
>
> Hello,
>  Some comments/questions inline.
>
> > (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
>
> > expire. The reason for this is that we (i.e., Google) had implemented
> > TLS-OBC as described in the draft (in Chrome and server-side), and we
> > weren't too happy with it. There were a few of problems:
> >
> > (1) Client certificates are part of the session state. Not only does that
> > mean that the session state is now considerably bigger than it used to be,
> > it also means that anyone that can steal session secrets (malware on the
> > client) can make it look to the server as if they were in possession of the
> > client's private key, even if that private key sits in a TPM on the client.
>
>
> How is that? Do you mean by session resumption? Isn't it the same on the
> current draft

ChannelIDs are not part of the session state and need to be sent in an abbreviated handshake. (The draft may be unclear on that point.)

>
> > This spec is silent on the scope of the keys (but in practice we expect
> > browsers to use eTLD+1 now instead of more fine-grained origins), and
> > addresses all the other issues explicitly: the Channel IDs are not part of
> > the TLS session state, and are exchanged after encryption is turned on.
> >
> > A comment on the new name: One of the ways the new spec is simpler than the
> > old one is that there are no more X.509 certs involved in proving
> > possession of the client key - so there goes the "C(ert)" in the "OBC"
> > acronym. Because of the agnosticism of the new spec toward the scope of the
> > client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
> > name.
>
>
> The approach actually looks like a prime user of the
> draft-ietf-tls-oob-pubkey extension that allows to send the
> SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
> allows any type of client public key, instead of sticking to a fixed
> ECDSA curve? No additional extension would be required.

That was suggested in the meeting. The reasons why that wouldn't work without modification are that: it's part of the session state, it's unencrypted in the handshake and we cannot also have a client cert if we do that.

One of our reasons for doing something else rather than modifying client certs was our experience that doing so turned into a bit of a mess when we did it last time.

Cheers

AGL

>
> regards,
> Nikos
> _______________________________________________
> TLS mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Nikos Mavrogiannopoulos
On Thu, Nov 8, 2012 at 11:45 PM, Adam Langley <[hidden email]> wrote:

>> The approach actually looks like a prime user of the
>> draft-ietf-tls-oob-pubkey extension that allows to send the
>> SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
>> allows any type of client public key, instead of sticking to a fixed
>> ECDSA curve? No additional extension would be required.
> That was suggested in the meeting. The reasons why that wouldn't work
> without modification are that: it's part of the session state, it's
> unencrypted in the handshake and we cannot also have a client cert if we do
> that.

Hello,
 The part of the session state I think would be hard to overcome.
Everything used in a TLS handshake is part of the state. What do you
actually need there is that this key and signature need to be resent
even if the client is resuming a session?

The unencrypted in the handshake is an early design choice in TLS. I
think TLS should be updated to cope with that, rather than each
individual extension try to patch that issue. Having said that there
was Marsh's proposal but I don't know if it is still active. In any
case this could be combined with a generic mechanism to have data in
TLS send after encryption is enabled (so that other extensions that do
that wouldn't reinvent the wheel).

About having a client certificate wouldn't it be more useful if a
client could submit more than one certificates/public keys? I haven't
seen much protocols doing that, but that is what your approach is
actually doing.

> One of our reasons for doing something else rather than modifying client
> certs was our experience that doing so turned into a bit of a mess when we
> did it last time.

Was it due to client constraints or because of the required changes?

regards,
Nikos
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7
On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos <[hidden email]> wrote:
>  The part of the session state I think would be hard to overcome.
> Everything used in a TLS handshake is part of the state. What do you
> actually need there is that this key and signature need to be resent
> even if the client is resuming a session?

Yes. Since the aim is to eliminate barer tokens as a means of
authentication it's unfortunately, for our purposes, that session
resumption makes a barer token out of the key pair!

> The unencrypted in the handshake is an early design choice in TLS. I
> think TLS should be updated to cope with that, rather than each
> individual extension try to patch that issue. Having said that there
> was Marsh's proposal but I don't know if it is still active. In any
> case this could be combined with a generic mechanism to have data in
> TLS send after encryption is enabled (so that other extensions that do
> that wouldn't reinvent the wheel).

We do use the EncryptedExtensions mechanism which was suggested by
someone on this list (sorry, I forget who) for NPN. (And it part of
the NPN spec now.) So it does use a generic mechanism for sending
encrypted handshake data, but it doesn't solve the generic problem of
encrypting client-certificates any longer.

>> One of our reasons for doing something else rather than modifying client
>> certs was our experience that doing so turned into a bit of a mess when we
>> did it last time.
>
> Was it due to client constraints or because of the required changes?

It was because our use turns out to be substantially different from
client-side certificates that the code to support both in a single
mechanism turned into a lot of ugly exceptions.


Cheers

AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Chris Richardson-9
In reply to this post by Dirk Balfanz
Perhaps I'm being picky, section 4 requires an illegal_parameter alert
if the cipher suite is insufficiently strong.  Doesn't
handshake_failure make more sense here?


On Thu, Nov 8, 2012 at 4:22 PM, Dirk Balfanz <[hidden email]> wrote:

> Hello everybody,
>
> As you might have noticed, I have let the TLS-Origin-Bound Certificates
> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
>
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.
>
> (2) The logic in the client and server that treated OBCs and normal client
> certs differently, even though they were delivered through the same kind of
> Certificate message, turned out to be a little more complex that we wanted
> it to be.
>
> (3) To keep the public key of the client (which acts like a machine
> identifier) away from prying eyes, we had to entangle the TLS-OBC extension
> with another extension that reordered handshake messages (and sent the
> Certificate message after the ChangeCipherSpec message). That added further
> ugly complexity.
>
> (4) The main use case for this was to be able to "channel-bind" cookies.
> Cookies, however, can be set across more than just a web origin. When the
> underlying transport uses different client keys for different origins inside
> the same TLD, then we can't bind a domain cookie to the underlying TLS
> channel.
>
> (If you were at IETF 85 you might have seen Adam give a short talk about
> this.)
>
> To fix all this, we wrote a new proposed spec:
> http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
>
> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.
>
> A comment on the new name: One of the ways the new spec is simpler than the
> old one is that there are no more X.509 certs involved in proving possession
> of the client key - so there goes the "C(ert)" in the "OBC" acronym. Because
> of the agnosticism of the new spec toward the scope of the client keys,
> there is also no "O(rigin)" anymore. Hence, we needed a new name.
>
> You can play with this proposed mechanism by getting Chrome 24 (just
> released to the beta channel), and observing its connections to Google web
> properties.
>
> Thoughts?
>
> Cheers,
>
> Dirk.
>
>
> _______________________________________________
> TLS mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7
On Fri, Nov 9, 2012 at 3:30 PM, Chris Richardson <[hidden email]> wrote:
> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
> if the cipher suite is insufficiently strong.  Doesn't
> handshake_failure make more sense here?

Does it? From RFC 5246:

illegal_parameter
      A field in the handshake was out of range or inconsistent with
      other fields.  This message is always fatal.

Seems to make sense, no?


Cheers

AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Nikos Mavrogiannopoulos
In reply to this post by Adam Langley-7
On 11/09/2012 03:46 PM, Adam Langley wrote:

> On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos <[hidden email]> wrote:
>>  The part of the session state I think would be hard to overcome.
>> Everything used in a TLS handshake is part of the state. What do you
>> actually need there is that this key and signature need to be resent
>> even if the client is resuming a session?
> Yes. Since the aim is to eliminate barer tokens as a means of
> authentication it's unfortunately, for our purposes, that session
> resumption makes a barer token out of the key pair!


You cannot really avoid that since this is the purpose of the session
resumption. Authentication only occurs in full sessions, so by modifying
resumption and requiring a signature you convert it to some kind of
resumption with some authentication. Don't the time limitations of
resuming sessions compensate for your concerns? (which I suppose is
preventing someone to authenticate by stealing session data).

>>> That was suggested in the meeting. The reasons why that wouldn't work
>>> without modification are that: it's part of the session state, it's
>>> unencrypted in the handshake and we cannot also have a client cert if we do
>>> that.


Thinking it again, the draft is pretty much about using pseudonyms
(public keys) to authenticate to servers over TLS. Authenticating with
both the pseudonym and the named certificate doesn't look like the main
use-case but a server may want to associate them and that could follow a
mechanism similar to what you propose.

>> Was it due to client constraints or because of the required changes?

> It was because our use turns out to be substantially different from
> client-side certificates that the code to support both in a single
> mechanism turned into a lot of ugly exceptions.


What if the server indicates early whether he'd like an authentication
with a pseudonym or a named certificate (or both for association)?
Wouldn't that simplify the handling of the client provided certificate?

regards,
Nikos

_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Chris Richardson-9
In reply to this post by Adam Langley-7
If I was looking at a packet capture and wanted to figure out what
exactly went wrong and how to make the connection succeed,
illegal_parameter would lead me to incorrect conclusions.
handshake_failure ("unable to negotiate an acceptable set of security
parameters") would lead me in the right direction.
insufficient_security would be ideal, but it is only supposed to be
sent from server to client.

On Fri, Nov 9, 2012 at 4:51 PM, Adam Langley <[hidden email]> wrote:

> On Fri, Nov 9, 2012 at 3:30 PM, Chris Richardson <[hidden email]> wrote:
>> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
>> if the cipher suite is insufficiently strong.  Doesn't
>> handshake_failure make more sense here?
>
> Does it? From RFC 5246:
>
> illegal_parameter
>       A field in the handshake was out of range or inconsistent with
>       other fields.  This message is always fatal.
>
> Seems to make sense, no?
>
>
> Cheers
>
> AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Paul Hoffman-2
In reply to this post by Dirk Balfanz
Is is possible for you to do a separate Internet-Draft on EncryptedExtensions, and then point to it from draft-balfanz-tls-channelid? I ask because there are probably other future extensions that will want to use that extension, and if the RFC level of ChannelID doesn't permit it, we'll be in a similar situation as we are for RFC 6091.

FWIW, I think ChannelID is a fine idea and should be adopted here, but I'm not convinced it will be put on Standards Track.

--Paul Hoffman
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Ben Laurie-3
In reply to this post by Adam Langley-7
On 9 November 2012 14:46, Adam Langley <[hidden email]> wrote:
> On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos <[hidden email]> wrote:
>>  The part of the session state I think would be hard to overcome.
>> Everything used in a TLS handshake is part of the state. What do you
>> actually need there is that this key and signature need to be resent
>> even if the client is resuming a session?
>
> Yes. Since the aim is to eliminate barer tokens

"bearer" :-)

> as a means of
> authentication it's unfortunately, for our purposes, that session
> resumption makes a barer token out of the key pair!
>
>> The unencrypted in the handshake is an early design choice in TLS. I
>> think TLS should be updated to cope with that, rather than each
>> individual extension try to patch that issue. Having said that there
>> was Marsh's proposal but I don't know if it is still active. In any
>> case this could be combined with a generic mechanism to have data in
>> TLS send after encryption is enabled (so that other extensions that do
>> that wouldn't reinvent the wheel).
>
> We do use the EncryptedExtensions mechanism which was suggested by
> someone on this list (sorry, I forget who) for NPN. (And it part of
> the NPN spec now.) So it does use a generic mechanism for sending
> encrypted handshake data, but it doesn't solve the generic problem of
> encrypting client-certificates any longer.
>
>>> One of our reasons for doing something else rather than modifying client
>>> certs was our experience that doing so turned into a bit of a mess when we
>>> did it last time.
>>
>> Was it due to client constraints or because of the required changes?
>
> It was because our use turns out to be substantially different from
> client-side certificates that the code to support both in a single
> mechanism turned into a lot of ugly exceptions.
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Ben Laurie-3
In reply to this post by Dirk Balfanz
On 8 November 2012 21:22, Dirk Balfanz <[hidden email]> wrote:

> Hello everybody,
>
> As you might have noticed, I have let the TLS-Origin-Bound Certificates
> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
>
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.
>
> (2) The logic in the client and server that treated OBCs and normal client
> certs differently, even though they were delivered through the same kind of
> Certificate message, turned out to be a little more complex that we wanted
> it to be.
>
> (3) To keep the public key of the client (which acts like a machine
> identifier) away from prying eyes, we had to entangle the TLS-OBC extension
> with another extension that reordered handshake messages (and sent the
> Certificate message after the ChangeCipherSpec message). That added further
> ugly complexity.
>
> (4) The main use case for this was to be able to "channel-bind" cookies.
> Cookies, however, can be set across more than just a web origin. When the
> underlying transport uses different client keys for different origins inside
> the same TLD, then we can't bind a domain cookie to the underlying TLS
> channel.
>
> (If you were at IETF 85 you might have seen Adam give a short talk about
> this.)
>
> To fix all this, we wrote a new proposed spec:
> http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
>
> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.

a) How can this be usable unless it is specified what browsers do?

b) eTLD+1 ... how will you deal with, e.g, uk, which has just proposed
removing a level from the TLDs? Hasn't this kind of mechanism already
been shown to be impossible to maintain (cookies are supposed to be
banned from eTLDs but in practice aren't always, IIRC)?
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Daniel Kahn Gillmor-7
On 11/12/2012 08:24 AM, Ben Laurie wrote:

> b) eTLD+1 ... how will you deal with, e.g, uk, which has just proposed
> removing a level from the TLDs? Hasn't this kind of mechanism already
> been shown to be impossible to maintain (cookies are supposed to be
> banned from eTLDs but in practice aren't always, IIRC)?

fwiw, this actually is currently "maintained" by tracking a ton of
special cases; the usual place this work is coordinated publicly is at
http://publicsuffix.org/

It's not a particularly pretty solution, but people do use it.  I can't
tell if it's the intent to reuse this same list for channelID or not,
though.

        --dkg


_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7
In reply to this post by Nikos Mavrogiannopoulos
On Sat, Nov 10, 2012 at 5:21 AM, Nikos Mavrogiannopoulos
<[hidden email]> wrote:
> Don't the time limitations of
> resuming sessions compensate for your concerns? (which I suppose is
> preventing someone to authenticate by stealing session data).

Time limits would be better than no time limits, but any time limit
short enough to be acceptable in this case would make session
resumption completely ineffective.

> What if the server indicates early whether he'd like an authentication
> with a pseudonym or a named certificate (or both for association)?
> Wouldn't that simplify the handling of the client provided certificate?

All the special case handling basically made a mess of the code. I
don't think any small changes would have changed that. (This is not a
precise argument, and it may not apply in all code bases. I am
orientated towards OpenSSL and NSS for obvious reasons.)


Cheers

AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7
In reply to this post by Paul Hoffman-2
On Sun, Nov 11, 2012 at 8:30 PM, Paul Hoffman <[hidden email]> wrote:
> Is is possible for you to do a separate Internet-Draft on EncryptedExtensions, and then point to it from draft-balfanz-tls-channelid? I ask because there are probably other future extensions that will want to use that extension, and if the RFC level of ChannelID doesn't permit it, we'll be in a similar situation as we are for RFC 6091.
>
> FWIW, I think ChannelID is a fine idea and should be adopted here, but I'm not convinced it will be put on Standards Track.

EncryptedExtensions is also used in the NPN. I'd be happy to split it
off if the WG were to adopt something that required it.


Cheers

AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Adam Langley-7
In reply to this post by Ben Laurie-3
On Mon, Nov 12, 2012 at 8:24 AM, Ben Laurie <[hidden email]> wrote:
> a) How can this be usable unless it is specified what browsers do?

It seemed that the higher-level behaviour wasn't in-scope for a
document about TLS protocol changes. Although I agree that it should
be documented, I think it's a different document.

(Higher level behaviour pulls in messy hacks like the Public Suffix
List, as you note in (b))


Cheers

AGL
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: Update on Origin-Bound Certificates: Now called "Channel ID"

Martin Rex-2
In reply to this post by Chris Richardson-9
Chris Richardson wrote:

>
> Adam Langley <[hidden email]> wrote:
>>
>> Chris Richardson <[hidden email]> wrote:
>>>
>>> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
>>> if the cipher suite is insufficiently strong.  Doesn't
>>> handshake_failure make more sense here?
>>
>> Does it? From RFC 5246:
>>
>> illegal_parameter
>>       A field in the handshake was out of range or inconsistent with
>>       other fields.  This message is always fatal.
>>
>> Seems to make sense, no?
>
> If I was looking at a packet capture and wanted to figure out what
> exactly went wrong and how to make the connection succeed,
> illegal_parameter would lead me to incorrect conclusions.
> handshake_failure ("unable to negotiate an acceptable set of security
> parameters") would lead me in the right direction.
> insufficient_security would be ideal, but it is only supposed to be
> sent from server to client.
 
Are you refering to this (*) text:

  http://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-4

   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.


rfc5246 defines for the alert "insufficient security" like this.

  http://tools.ietf.org/html/rfc5246#page-33

   insufficient_security
      Returned instead of handshake_failure when a negotiation has
      failed specifically because the server requires ciphers more
      secure than those supported by the client.  This message is always
      fatal.

The second sentence "This message is always fatal" should to be interpreted
as a requirement.  The first sentence describes the purpose for which
rfc5246 uses this alert, it can not be interpreted to limit its usage
for server->client signaling.


However, in a TLS handshake, the client *MUST* include the list of
cipher suites acceptable to the client in ClientHello.  If a cipher
suite is not acceptable to the client, it should not appear in the
ClientHello in the first place.  If it appears, it MUST be acceptable
to the client if the server chooses it.

The suggexted "illegal_parameter" is probably meant for the situation
where the server chooses a cipher suite that the client never offered
(which _might_ be the result of an Man-in-the-Middle attacker).

To me, it is difficult to conceive a usage scenario where the alert
"insufficient_security" would be the appropriate response, rather than
an indication that the client is goofing the list of acceptable
cipher suites in ClientHello.


A client that did _not_ offer AES256_CBC-SHA1 (due to configuration)
should also abort with an illegal_parameter alert if the server chooses
that cipher suite, even though I'm not aware of any security concerns
about that cipher suite (pre-TLS1.1 IVs is a different issue).


-Martin
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

illegal alert [was: Update on Origin-Bound Certificates: Now called "Channel ID"]

Nikos Mavrogiannopoulos
On 11/20/2012 10:09 PM, Martin Rex wrote:


> The suggexted "illegal_parameter" is probably meant for the situation
> where the server chooses a cipher suite that the client never offered
> (which _might_ be the result of an Man-in-the-Middle attacker).
>
> To me, it is difficult to conceive a usage scenario where the alert
> "insufficient_security" would be the appropriate response, rather than
> an indication that the client is goofing the list of acceptable
> cipher suites in ClientHello.


There is a use-case for this alert (although not in its description).
Think of a server that uses a 256-bit DH key. In that case,
unfortunately, the client cannot do much except close the connection
with an alert.

regards,
Nikos
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls
Reply | Threaded
Open this post in threaded view
|

Re: illegal alert [was: Update on Origin-Bound Certificates: Now called "Channel ID"]

Martin Rex-2
Nikos Mavrogiannopoulos wrote:

>
> Martin Rex wrote:
>>
>> The suggexted "illegal_parameter" is probably meant for the situation
>> where the server chooses a cipher suite that the client never offered
>> (which _might_ be the result of an Man-in-the-Middle attacker).
>>
>> To me, it is difficult to conceive a usage scenario where the alert
>> "insufficient_security" would be the appropriate response, rather than
>> an indication that the client is goofing the list of acceptable
>> cipher suites in ClientHello.
>
> There is a use-case for this alert (although not in its description).
> Think of a server that uses a 256-bit DH key. In that case,
> unfortunately, the client cannot do much except close the connection
> with an alert.


Thanks!  

Yes, that looks like a perfectly valid client-side use case for the
"insufficient_security" alert.


-Martin
_______________________________________________
TLS mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/tls