Subject: [TLS] AD review of draft-ietf-tls-oob-pubkey

From: Sean Turner <[email-masked]>
Date: Tue, 16 Apr 2013 10:06:22 -0400

I'd like to discuss some of these before issuing an IETF LC.  There's no 
implied importance based on the order.

0) abstract: I'd delete the 2nd paragraph it really sounds like 
marketing.  The third paragraph is also a repeat of what's in the 1st 
paragraph - I'd just delete it.  Finally, need to be clear that you're 
also defining two new TLS extensions:

  This document specifies a new certificate type and two TLS extensions,
  one for the client and one for the server, 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.

1) s1 does a good job of motivating the need for server side keys but 
falls a little short on client keys.  Why does the intro to the bullet 
list mention how the client can get the server's certificate with the 
last bullet also talking about the client's key?  Also, is the paragraph 
after the bullets just an explicit example of the last bullet?

Seems like the first sentence should be:

   Traditionally, TLS client and server public keys ...

and then maybe:

  Alternative methods are available that allow a TLS clients/servers
  to obtain the TLS servers/client public key:

    o  TLS clients can obtain the TLS server public key from a
       DNSSEC secured resource records using DANE [RFC6698].

    o  The TLS client or server public key is obtained from a
       [PKIX] certificate chain from an Lightweight Directory
       Access Protocol (LDAP) [LDAP] server or web page.

    o  The TLS client and server public key is provisioned into
       the operating system firmware image, and updated via
       software updates. For example:

       * Some smart objects use the UDP-based Constrained
         Application Protocol (CoAP) [I-D.ietf-core-coap] to
         interact with a Web server to upload sensor data at
         a regular intervals, such as temperature readings.
         CoAP [I-D.ietf-core-coap] can utilize DTLS for securing
         the client-to-server communication.  As part of the
         manufacturing process, the embeded device may be
         configured with the address and the public key of
         a dedicated CoAP server, as well as a public key for
         the client itself.

2) s1: The last paragraph needs to indicate that this document defines 
two new certificate extensions:

  This document registers a new value to the IANA certificate
  types registry for the support of raw public keys.  It also
  defines two new TLS extensions, "client_certificate_type" and
  "server_certificate_type".

3) I think the introduction needs to make it very clear that without the 
out-of-band binding between the public key and the entity that no 
authentication is actually being performed.  Add something like the 
following to the end of s1:

   The mechanism defined herein only provides authentication when
   an out-of-band mechanism is also used to bind the public key
   to the entity presenting the key.

4) s3: r/raw public key certificates/raw public keys

5) wrt Figure 3 maybe we can just list the ones we know about? And, RFC 
5480 updated 3279 wrt ECDSA public keys so it needs to point there:

   [RFC3279] and [RFC5480] define the following OIDs:

Key Type             | Document                   | OID
---------------------+----------------------------+-------------------
RSA                  | Section 2.3.1 of RFC 3279  | 1.2.840.113549.1.1
.....................|............................|...................
Digital Signature    |                            |
Algorithm (DSS)      | Section 2.3.2 of RFC 3279  | 1.2.840.10040.4.1
.....................|............................|...................
Elliptic Curve       |                            |
Digital Signature    |                            |
Algorithm (ECDSA)    | Section 2.1.1 of RFC 5480  | 1.2.840.10045.2.1
---------------------+----------------------------+-------------------

                  Figure 3: Example Algorithm Identifiers.

and add 5480 as reference.

Grumble: would have listed RSASSA-PSS but it's not supported.

6) And on those references, I think the references for 3279 and 5480 end 
up normative.  All are standards track so no downref issues.

7) s3: I think it's not just an algorithm it sometimes includes 
additional parameters.  Also need to include the AlgorithmIdentifier 
syntax. I think that means some slight tweaking:

  The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC
  5280 [PKIX] and does not only contain the raw keys, such as the
  public exponent and the modulus of an RSA public key, but also an
  algorithm identifier.  The algorithm identifier can also include
  parameters.  The structure, as shown in Figure 2, is
  encoded in an ASN.1 format and therefore contains length information
  as well.  An example is provided in Appendix A.

    SubjectPublicKeyInfo  ::=  SEQUENCE  {
      algorithm            AlgorithmIdentifier,
      subjectPublicKey     BIT STRING  }

    AlgorithmIdentifier  ::=  SEQUENCE  {
      algorithm               OBJECT IDENTIFIER,
      parameters              ANY DEFINED BY algorithm OPTIONAL  }

               Figure 2: SubjectPublicKeyInfo ASN.1 Structure.

ref:

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

8) I'm thinking we need to say DER encoded in the above as well:

   an DER encoded ASN.1 [X.690] format

here's the reference:

    [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
               Information technology - ASN.1 encoding rules:
               Specification of Basic Encoding Rules (BER), Canonical
               Encoding Rules (CER) and Distinguished Encoding Rules
               (DER).

9) s4.1: Are some words missing from the following:

  In order to indicate the support of out-of-band raw public keys,
  clients MUST include the 'client_certificate_type' and
  'server_certificate_type' extensions extended client hello message.

extensions "in an" extended client hello message?

10) s4.2:  Maybe reword this slightly:

OLD:

  If the client indicated the support of raw public keys in the
  'client_certificate_type' extension in the client hello and the
  server is able to provide such raw public key then the TLS server
  MUST place the SubjectPublicKeyInfo structure into the Certificate
  payload.

NEW:

  If the client hello indicates support of raw public keys in the
  'client_certificate_type' extension and the
  server also supports raw public keys then the TLS server
  MUST place the SubjectPublicKeyInfo structure into the Certificate
  payload.

But, a more important question is the meaning of that paragraph above. 
Doesn't that override the "sorted by client preference" from s3?

11) s6: Got some questions about the following:

   This information will be needed to make
   authorization decisions.  Without a secure binding,
   man-in-the-middle attacks may be the consequence.

1st isn't that authentication.  2nd isn't it masquerade attacks?  3rd 
it's not really a may it's more an is likely to be?

12) In s6, it indicates:

   This document assumes that such
   binding can be made out-of-band and we list a few examples in
   Section 1.

This statement begs the question as to whether there needs to be a 
requirement on protocols that use this extension to specify the method 
used to provide the out-of-band binding.  In other words something like:

   Specifications that make use of the extension MUST specify the
   mechanism by which the identity and the public key are bound.
   Otherwise, authentication is not possible.

13) How are we supposed to check whether key is still considered "good"? 
  If you can't that might be okay, but you need to mention that there's 
no mechanism to support this yet or that that also needs to be done 
out-of-band.

14) Are there any other extensions that don't make sense to negotiate if 
raw keys are chosen?  For example, if the the client and server settle 
on raw keys do either of the ocsp stapling extensions make sense anymore?

15) In s7, ask IANA to point the Certificate's Type Registry to this draft.

spt

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 22 Apr 2013 01:23:25 +0000

Hi Sean, all,

<quote>
</quote>

That indeed is a problem. I have made a first attempt at solving this through the following draft:
http://datatracker.ietf.org/doc/draft-greevenbosch-tls-ocsp-lite/

The draft should not be confused with the Lightweight OCSP Profile from RFC 5019. I guess a new name is needed.

Also the draft is quite simple, it just asks a server about the revocation status of the public key. The current solution has scalability issues, so it would certainly need some work to get that right.

The raw public key was designed to remove the processing burden of a full X.509 certificate, making it easy to use in constrained environments. (CoAP refers to it.) I think revocation status checking should be similarly simple for the receiving entity.

Best regards,
Bert

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Apr 2013 10:15:05 -0500

Yes, O*CS*P light is a bad name. :)

Have you looked at what SSH is doing for key management issues?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 23 Apr 2013 08:23:02 +0000

Hello Rich,

Thank you for your feedback. Please find my response below.

> Yes, O*CS*P light is a bad name. :)

Right, that should be changed.

> Have you looked at what SSH is doing for key management issues?

Thanks for your hint. Indeed SSH specifies something quite similar to a raw public key in RFC 4716.

I understand that SSH relies on the following methods for authentication:

(1) Pre-shared knowledge of public key. For example, after first registration the client knows the server public key, so if the public key changes in a later session it is suspect.
(2) Manual verification of the hash of the public key, which is delivered through a separate channel.
(3) Password verification -> after session setup the client sends a password to ensure the server it is legitimate.

The SSH specifications (e.g. RFC 4251) explicitly point out that for the sake of easy deployment, authentication of name-to-key association may be omitted, accepting the risk of a man-in-the-middle attack.

RFC 4251 also mentions the possibility to use a trusted certificate authority (CA) for the name-to-key association. It notes that this can be done through Kerberos or a secure DNS lookup.

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.

How do you envision using SSH for raw public keys?

Thanks and best regards,
Bert

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: 2013年4月22日 23:15
To: Bert Greevenbosch; Sean Turner; [email-masked]; [email-masked]
Subject: RE: [TLS] AD review of draft-ietf-tls-oob-pubkey

	/r$

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Apr 2013 09:27:59 -0400 (EDT)

> 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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Apr 2013 10:05:48 -0600

I thought Peter Gutman had an I-D on SSH key management, but I can't find it now (it could have been years since I looked).

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 25 Apr 2013 08:19:11 +0000

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>

...

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>

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:[email-masked]] 
Sent: 2013年4月23日 21:28
To: Bert Greevenbosch
Cc: Salz, Rich; Sean Turner; [email-masked]
Subject: Re: [TLS] Revocation and authentication of raw public key (was: AD review of draft-ietf-tls-oob-pubkey)

Paul

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 25 Apr 2013 18:59:25 -0700

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 <
[email-masked]> wrote:

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