Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue

[Eric Rescorla <[e-mail]>]

On Wed, Jul 11, 2012 at 3:56 AM, Hannes Tschofenig
<[e-mail]> wrote:
> Hi all,
>
> draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation.
>
> Here is the latest draft:
> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03
>
> I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those:

It might help if you desscribe the actual open issue.


> I) Server uses Raw Public Keys (client authentication happens at some other layer)
> (the DANE use case)
>
> client_hello,
> raw-public-key-indicator="Server, when you send me your raw public key?

Is your suggestion that this is indicating ":I would not support X.509?


> I support this out-of-band key validation using DANE." ->

Wait, who said anything about indicating DANE here? The agreed upon
indication was
"I would support a public key", nothing about DANE.



>                           <-  server_hello,
>                               raw-public-key="OK. The certificate structure below contains my raw public key.",
>                               certificate, // with raw public key inside
>                               server_key_exchange,
>                               server_hello_done
>
> client_key_exchange,
> change_cipher_spec,
> finished                  ->
>
>                           <- change_cipher_spec,
>                              finished
>
> Application Data        <------->     Application Data
>
>
> II) Client and Server use Raw Public Keys
> (the smart object use case - CORE working group)
>
> client_hello,
> raw-public-key="Server, please send me your raw public key and I will then send you mine. Are you OK processing my raw public key for client authentication?" ->

This is not a semantic associated with the client. In TLS the server
requests client auth. At most the client could say "I could
send you a raw public key for auth if you asked for it"


>                           <-  server_hello,
>                               raw-public-key="Below you find my raw public key and please send me your raw public key for client
>                                                            authentication",
>                               certificate, // raw public key
>                               server_key_exchange,
>                               certificate_request,
>                               server_hello_done
>
> certificate, // with client's raw public key
> client_key_exchange,
> certificate_verify,
> change_cipher_spec,
> finished                  ->
>
>                           <- change_cipher_spec,
>                              finished
>
> Application Data        <------->     Application Data
>
>
> II) Hybrid Scenario
> (the OAuth Holder-of-the-Key Use case)
>
> client_hello,
> raw-public-key="I would like to use my raw public key for client authentication with OAuth. I also process X.509 for server-side authentication." ->

As above.


>                           <-  server_hello,
>                               raw-public-key="Please send me your raw public key.

This is in certreq, no?


>  I use X.509 for server-side authentication",

Why would this need an indication?

>                               certificate,  // with X.509 cert.
>                               server_key_exchange,
>                               certificate_request,
>                               server_hello_done
>
> certificate, // with client's raw public key
> client_key_exchange,
> certificate_verify,
> change_cipher_spec,
> finished                  ->
>
>                           <- change_cipher_spec,
>                              finished
>
> Application Data        <------->     Application Data
> --------
>
> QUESTION: Are these all the message exchanges we need? Are there some problems with the exchanges?
>
> Ciao
> Hannes
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls