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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 8 May 2013 03:11:33 +0000

Most of these look reasonable to me, a few comments inline at the end. 

Thanks,

Joe
On Apr 16, 2013, at 7:06 AM, Sean Turner <[email-masked]> wrote:

> 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?
> 

[Joe]   I think this should probably say something like:

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

> 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?
> 

[Joe]  I'm not sure binding a key to a name is exactly authentication.  I'd probably reword it something like:

"Without a secure binding between identity and key the protocol will be vulnerable to masquerade and man-in-the-middle attacks. "

> 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.
> 
[Joe] Or maybe 
"In order to address these vulnerabilities, specifications that make use of the extension MUST specify how the identity and public key are bound." 

> 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.
> 

[Joe] I think we need to state this is done out of band as well.  

> 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?
> 

[Joe] At least the multi-ocsp extension could be extended to support other Status mechanisms. 

> 15) In s7, ask IANA to point the Certificate's Type Registry to this draft.
> 
> spt
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 09 May 2013 15:53:47 -0400

> "In order to address these vulnerabilities, specifications that make use of the extension MUST specify how the identity and public key are bound." 

Why is this a MUST?  What would be wrong with a specification that makes
use of the extension and declines to mandate a specific OOB mechanism
(e.g. leaves that choice of selection up to the service administrator or
local configuration or something else)?

Being deliberately agnostic about corners of a protocol that you don't
want to constrain is pretty healthy.  If a spec for some new service
comes out that uses OOB keys, and then later someone publishes a novel
(and useful) mechanism for verifying the binding between those keys and
identities, do we want that spec to be considered invalid when used in
combination with the new verification mechanism?

> [Joe] At least the multi-ocsp extension could be extended to support other Status mechanisms. 

I'm not convinced that this extension of an extension should be coupled
into the same draft as oob-pubkey itself.  It seems likely to make it
harder to reach consensus on oob-pubkey without providing a significant
benefit.

	--dkg

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 10 May 2013 03:19:34 +0000

> combination with the new verification mechanism?

[Joe]  In order for this specification to be used securely this binding must be done.  A document using this specification could possibly leave this up to administrative configuration if that was OK for their environment.  They could also specify a separate interoperable mechanism for achieving the binding.    If a new mechanism is develop then that new mechanism would have to be specified somewhere and documents would need to be updated to describe how to use that mechanism in an interoperable way.   

In any case I would be OK with removing the normative MUST and saying something like:

"Specifications that make use of this extension need to describe how the identity and the public key are bound.
Without this binding, authentication is not possible. " 

> harder to reach consensus on oob-pubkey without providing a significant

[Joe]  I agree, but to your point above would you want to restrict the use of an extension that could easily be extended to use a different mechanism in the future?   I think here we would probably want to add text to the document to say that this document does not cover how revocation either. 

"Revocation of keys is not covered by this document.  Specifications that make use of this extension need to describe if and how revocation of keys is performed.  At the time of this document's publication, OCSP does not support the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP]  do not apply. "

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 14 May 2013 03:30:57 +0000

[Bert] I wonder if it would make sense to add some kind of a meta field as follows:

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

This could then be used to provide meta information about the public key, e.g. information that may be needed by an out of band authentication method. The field could be ignored by default, unless the particular trust model requires differently.

I guess DER encoding also allows addition of unspecified fields, but I am not sure if they will be ignored or lead to exceptions.

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 May 2013 19:48:13 +0100

> I guess DER encoding also allows addition of unspecified fields, but I am not sure if they will be ignored or lead to exceptions.

Please don't add the meta field there.  The idea was that the 
SubjectPublciKey might just be grabbed from a certificate and that 
field's not there in a certificate.  Further, I think the DANE 
structures require that SubjectPublicKeyInfo be as specified in RFC 5280 
(i.e., sans meta).

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 May 2013 20:20:44 +0100

> Without this binding, authentication is not possible. "

Joe you read my mind.  I'm also okay without the MUST.

> "Revocation of keys is not covered by this document.  Specifications that make use of this extension need to describe if and how revocation of keys is performed.  At the time of this document's pub…

Not thrilled with this answer but I could live with it.

How about adding a new section that groups these two issues together and 
call it "What specifications that use this document must specify" or 
something like that.

spt

---

From: Sean Turner <[email-masked]>
Date: Fri, 24 May 2013 13:14:02 -0400

I think I didn't yet respond to some of these.

> MUST place the SubjectPublicKeyInfo structure into the Certificate

Yep that's what I was thinking.

> "Without a secure binding between identity and key the protocol will be vulnerable to masquerade and man-in-the-middle attacks."

I could live with that.

> [Joe] I think we need to state this is done out of band as well.

Yeah all I'm looking for here is a warning that there's currently no 
mechanism to support this.  I was going to go and say that the 
application needs to define who this might be done, but after talking it 
over with a couple of folks what it's going to come down to is asking 
those applications when we see them calling out use of this document if 
they really want status checking.

spt