Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey)

[Bert Greevenbosch <[e-mail]>]

Hi Paul,

Thank you for your feedback.

Indeed an OSCP-lite responder would be similar to a Trust Authority (TA) in that it is a third party that can confirm or invalidate a raw public key.

My concern is, that when omitting the certificate and especially the TA, anyone can generate a raw public key. Now indeed there are multiple ways to tackle this problem though out-of-band mechanisms; an example in CoAP is given by a barcode scanner that is used to physically scan the public key. In that case the trust lies in the fact that the barcode is considered authentic.

Nevertheless, when you do automatic exchange as defined in draft-ietf-tls-oob-pubkey, you need something that authenticates the key. This holds even more as a Certification Authority signature that authenticates the certificate is not available.

<quote>
For instance, using DNS(SEC) with raw keys there is only B and C. When
B loses trust in their key, they simple remove it from DNS(SEC) to
communicate this to A. The same applies to SSHFP records in DNS(SEC)
or ActiveDirectory.

...

Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can
tune the behaviour of when TLS raw keys are valid or not. No OCSP variant
is neccessary. The same is true for content based on ActiveDirectory/LDAP
or Radius/Diameter where there is already a central control mechanism
for relaying this information.
</quote>

I understand that you mean B loses its trust in its own key? Then yes, as a good citizen B could communicate this through these means. And if B is bad and it is found out, then the DNS(SEC) can remove B's key. If B never was to be trusted, the DNS(SEC) would not be able to provide its key. In all these cases the DNS(SEC) is the third party providing authentication and revocation.

Also, in a client/server model, I am not sure if the client's raw public key can be verified with DNS(SEC). Does a client normally have a DNS entry, e.g. a name that can be looked up through DNS? In TLS, the client provides its complete certificate chain, which is for the server to verify. Part of this verification normally is revocation checking, e.g. through OCSP or CRL lists. Does that mean that when using DNS(SEC) as the out-of-band authentication mechanism of the raw public key, each client needs to be registered with the DNS(SEC)?

<quote>
OCSP was only needed before because there were three parties. While it
is still possible an out of band method to validate TLS keys to require
three parties, any revocation list mechanism should be part of the out
of band method specification. I am not sure what out of band method this
OCSP-lite case covers. If there is a specification of that out of band
method, then that specification should perhaps include this OCSP-lite
specification as part of it.
</quote>

Indeed that is the idea. The OCSP-lite is an out-of-band method for authentication of the raw public key in itself. The advantage of the OCSP-lite approach is that it does not need DNS(SEC) to establish secure communication. This may especially be useful for endpoints that do not have a domain name, and are directly identified by their IP address. Goal of OCSP-lite is to keep verification for the client as easy as possible, i.e. put most of the burden on the OCSP-lite responder.

What do you think?
 
Best regards,
Bert


-----Original Message-----
From: Paul Wouters [mailto:[e-mail]] 
Sent: 2013年4月23日 21:28
To: Bert Greevenbosch
Cc: Salz, Rich; Sean Turner; [e-mail]
Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey)

On Tue, 23 Apr 2013, Bert Greevenbosch wrote:

> I think name-to-key association is half of the problem, whereas revocation is the second half. SSH seems to focus on the first half, whereas OCSP-lite focuses mainly on the second half.

Revocation is only required in the indirect path. That is, supplier A
signs something for consumer B, and enduser C needs to verify B. Now A
needs a method to tell C about revocation of B.

When you use raw public keys, the authentication happens out of band. If
there are no three players, with two of them talking only indirectly,
no OCSP-like mechanism is required.

For instance, using DNS(SEC) with raw keys there is only B and C. When
B loses trust in their key, they simple remove it from DNS(SEC) to
communicate this to A. The same applies to SSHFP records in DNS(SEC)
or ActiveDirectory.

OCSP was only needed before because there were three parties. While it
is still possible an out of band method to validate TLS keys to require
three parties, any revocation list mechanism should be part of the out
of band method specification. I am not sure what out of band method this
OCSP-lite case covers. If there is a specification of that out of band
method, then that specification should perhaps include this OCSP-lite
specification as part of it.

I don't see a value of specifying a generic revocation method. I see
danger in such a specification if it _introduces_ a third player where
there should not be one for a specific out of band authentication
method.

Using TLS raw keys from DNSSEC, The RRSIG/TTL and DNS trust anchors can
tune the behaviour of when TLS raw keys are valid or not. No OCSP variant
is neccessary. The same is true for content based on ActiveDirectory/LDAP
or Radius/Diameter where there is already a central control mechanism
for relaying this information.

Paul