Re: [keyassure] Bare keys again

[Matt McCutchen <[e-mail]>]

For completeness (I think the main points have been also made
elsewhere):

On Sun, 2011-03-20 at 22:18 -0400, Paul Wouters wrote:
> On Sun, 20 Mar 2011, Matt McCutchen wrote:
> 
> >> The client sends its hello message saying "I have all the CA root trust
> >> anchors I need from pre-agreement".  Whether that means it got information
> >> from DNSSEC/DANE or elsewhere does not matter. What matters is, is that
> >> the client can start the TLS handshake without the server sending any
> >> PKIX certs.
> >
> > How does this look at the message level?  The server sends a Certificate
> > message containing a zero-length sequence of certificates?
> 
> No, it sends an Hello TLS extension of type "trusted_ca_keys" containing
> in its "extension_data" a 'struct' TrustedAuthorities containing one
> "TrustedAuthority" that has an "IdentifierType" of "agreed" which is
> 'struct {}'

I understand that part.  I was asking about the "without the server
sending any PKIX certs" part.

> >  This is not
> > at all what is envisioned by RFC 6066.  To say that your scheme involves
> > no TLS protocol changes is a little misleading: you are using existing
> > messages but dramatically repurposing them.
> 
> Not at all! According to 6066:
> 
> 6. Trusted CA Indication
> 
> 
>     Constrained clients that, due to memory limitations, possess only a
>     small number of CA root keys may wish to indicate to servers which
>     root keys they possess, in order to avoid repeated handshake
>     failures.
> 
>     In order to indicate which CA root keys they possess, clients MAY
>     include an extension of type "trusted_ca_keys" in the (extended)
>     client hello.  The "extension_data" field of this extension SHALL
>     contain "TrustedAuthorities" where:
> 
>        struct {
>            TrustedAuthority trusted_authorities_list<0..2^16-1>;
>        } TrustedAuthorities;
> 
>        struct {
>            IdentifierType identifier_type;
>            select (identifier_type) {
>                case pre_agreed: struct {};
>                case key_sha1_hash: SHA1Hash;
>                case x509_name: DistinguishedName;
>                case cert_sha1_hash: SHA1Hash;
>            } identifier;
>        } TrustedAuthority;
> 
>        enum {
>            pre_agreed(0), key_sha1_hash(1), x509_name(2),
>            cert_sha1_hash(3), (255)
>        } IdentifierType;
> 
>        opaque DistinguishedName<1..2^16-1>;
> 
>     Here, "TrustedAuthorities" provides a list of CA root key identifiers
>     that the client possesses.  Each CA root key is identified via
>     either:
> 
>     -  "pre_agreed": no CA root key identity supplied.

"pre_agreed" stands for a set of one or more trust anchors that is
already known to the other side in the context of a particular
deployment.  Hence, bandwidth is saved by not sending identifiers for
the trust anchors.  Using "pre_agreed" to tell the server it can skip
sending a certificate chain is not envisioned by RFC 6066.

> > IMO, this scheme should be
> > standardized and subjected to the attendant level of scrutiny before we
> > consider supporting it in DANE.
> 
> The only thing that is different here is that I am using a client contraint
> that is different from the examples listed at the start of section 6.

What is different is that the server does not send a certificate chain.

-- 
Matt