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

["Joseph Salowey (jsalowey)" <[e-mail]>]

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