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

[Trevor Perrin <[e-mail]>]

Hi Bert,

You may be interested in TACK [1].

TACK allows a client to verify a server's identity based on client
knowledge of a "TACK signing key" which signs the server's TLS key(s).
 These signatures are presented in the TLS handshake along with an
expiration time and revocation info for earlier signatures.

This enables the server operator to use a "more-secure" offline signing key
to revoke and replace the "more-exposed" TLS keys, akin to your OCSP-lite
proposal.

TACK was designed to be compact and simple to verify, and requires no X.509
certs, so it would work well with draft-ietf-tls-oob-pubkey.


Trevor


[1] http://datatracker.ietf.org/doc/draft-perrin-tls-tack/



On Thu, Apr 25, 2013 at 1:19 AM, Bert Greevenbosch <
[e-mail]> wrote:

> 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
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>