Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk <[e-mail]>]

[trimming]
On Tue, Sep 03, 2019 at 02:18:22PM +0200, Peter van der Stok wrote:
> 
>    [RFC7030] recommends the use of additional encryption of the returned
>    private key.  For the context of this specification, clients and
>    servers that choose to support server-side key generation MUST
>    support unprotected (PKCS#8) private keys (Content-Format 284).
>    Symmetric or asymmetric encryption of the private key (CMS
>    EnvelopedData, Content-Format 280) SHOULD be supported for
>    deployments where end-to-end encryption needs to be provided between
>    the client and a server.  Such cases could include architectures
>    where an entity between the client and the CA terminates the DTLS
>    connection (Registrar in Figure 4).
> 
> This carefully says nothing about recommendations for use, only for
> software support.  Are we letting 7030's recommendation for use of
> encryption stand?  It's probably worth being explicit, either way. 
> 
> <pvds> I did not find any recommendation for use in RFC7030 apart the
> responsibility of the server for generating random numbers. The
> recommendations at the top of section 5.8 of the draft seem adequate in
> my opinion. The alternative is classifying the applications; unless you
> see a better way to do this. 

I think the 7030 text I was thinking of is this:

   It is strongly RECOMMENDED that the clients request that the returned
   private key be afforded the additional security of the Cryptographic
   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
   security to protect against unauthorized disclosure.

> 
> </pvds>
> 
[...]
> 
>    It is recommended, based on experiments, to follow the default CoAP
>    configuration parameters ([RFC7252]).  However, depending on the
>    implementation scenario, retransmissions and timeouts can also occur
>    on other networking layers, governed by other configuration
>    parameters.  A change in a server parameter MUST ensure the adjusted
>    value is also available to all the endpoints with which these
>    adjusted values are to be used to communicate.
> 
> I don't understand who this is a normative requirement upon.  Is it the
> network operator's, to propagate configuration changes?  Or is there
> supposed to be some automated protocol that makes adjusted values
> available? 
> 
> <pvds> 
> 
> It is meant as reminder to anyone doing the configuration of a given
> installation; you want to suppress the text? 

I don't want to suppress it, no.

Maybe "A configuration change in a server parameter MUST be coordinated
with all the endpoints with which these adjusted values are to be used to
communicate"?  Though I guess "coordinate" does not necessarily force the
other endpoint to be using the identical value, just to know about it.

> </pvds>
> 
[...]
> 
> Appendix A.1
> 
>      Option (Uri-Port)
>         Option Delta = 0x4  (option# 3+4=7)
>         Option Length = 0x4
>         Option Value = 9085
>       Option (Uri-Path)
>         Option Delta = 0x4   (option# 7+4=11)
>         Option Length = 0x5
>         Option Value = "est"
> 
> This is more for my own edification than the document's sake, so thank
> you for your time, but what accounts for the "extra" length here?  The
> "est" is three bytes, and what makes up for the other two?  Also, I
> assume that the port value of 9805 is the decimal value, which gets
> CBOR encoded into two bytes  of integer encoding plus the byte with
> additional information 25 to indicate the two-byte integer, and another
> byte that I need help accounting for. 
> 
> <pvds> 
> 
> Many thanks; an old misreading of an example in 7252. 
> 
> For the option length of URI-Path we included the quotations as well;
> That is WRONG. 
> 
> Repaired it everywhere. 
> 
> Options are not CBOR encoded. 

Well, now I'm glad I asked -- thanks!

> </pvds>
> 
> Appendix A.2
> 
> Do we want to say anything about the IDevID in the CSR/cert?
> I note that the breakdown in Appendix C.2 (looks like openssl output)
> does not decode the otherName (though asn1parse can be convinced to do
> so). 
> 
> <pvds> 
> 
> What do you suggest for IDevID? 

If we were going to add something (which remains unclear to me), it could
be after the sentence "[...] the CSR contains a ChallengePassword which is
used for POP linking (Section 4).", and be something like "This CSR also
contains an RFC 7299 id-on-hardwareModuleName hardware identifier to
customize the returned certificate to the requesting device."
(The actual identifier here is the same one mentioned in
https://www.mail-archive.com/[e-mail]/msg00938.html, from Bob
Moskowitz's OID arc.)

> Actually openssl was used extensively for generating the examples. 
> 
> Will be happy to learn about otherName 

otherName is an OID-indexed generic name container for the cert; it's a
form of subjectAltName.  What I did here was:

~$ unhex|openssl asn1parse -inform der
   3082018b30820131020100305c310b3009060355040613025553310b3009
   06035504080c024341310b300906035504070c024c413114301206035504
   0a0c0b6578616d706c6520496e63310c300a060355040b0c03496f54310f
   300d060355040513065774313233343059301306072a8648ce3d02010608
   2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f
   028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75
   f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109
   0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e
   7634332323403d204e787e60303b06092a864886f70d01090e312e302c30
   2a0603551d1104233021a01f06082b06010505070804a013301106092b06
   010401b43b0a01040401020304300a06082a8648ce3d0403020348003045
   02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab
   ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc
   1135a1e84eed754377
    0:d=0  hl=4 l= 395 cons: SEQUENCE          
  [...]
  271:d=7  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Alternative
Name
  276:d=7  hl=2 l=  35 prim: OCTET STRING      [HEX
DUMP]:3021A01F06082B06010505070804A013301106092B06010401B43B0A01040401020304
  313:d=1  hl=2 l=  10 cons: SEQUENCE          
  315:d=2  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
  325:d=1  hl=2 l=  72 prim: BIT STRING        

to note that there's a SAN that's not decoded automatically, and then

~$ unhex|openssl asn1parse -inform der -strparse 276
   3082018b30820131020100305c310b3009060355040613025553310b3009
   [...]
   1135a1e84eed754377
    0:d=0  hl=2 l=  33 cons: SEQUENCE          
    2:d=1  hl=2 l=  31 cons: cont [ 0 ]        
    4:d=2  hl=2 l=   8 prim: OBJECT            :1.3.6.1.5.5.7.8.4
   14:d=2  hl=2 l=  19 cons: cont [ 0 ]        
   16:d=3  hl=2 l=  17 cons: SEQUENCE          
   18:d=4  hl=2 l=   9 prim: OBJECT            :1.3.6.1.4.1.6715.10.1
   29:d=4  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:01020304

to look at the contents.  1.3.6.1.5.5.7.8.4 (with the symbolic name in my
suggested text) is the type of the otherName, here.

I'm pretty sure there's not a more-"automatic" way to get openssl to peek
inside otherName.

> </pvds>
> 
[...]
> 
> Section A.4
> 
> I'm not sure how useful repeating the RFC 7030 csrattrs is: do we expect
> (e.g.) brainpoolP384r1 to be relevant for our readers? 
> 
> <pvds> 
> 
> It was added for completeness sake; nothing more. 
> 
> Suppressing it may provoke other questions like: Why is it not there? 

Okay.

> </pvds>
> 
[...]
> 
>    tenth packet of 63 bytes.  The client sends an IPv6 packet containing
>    the UDP datagram with the DTLS record that encapsulates the CoAP
>    request 10 times.  The server returns an IPv6 packet containing the
>    UDP datagram with the DTLS record that encapsulates the CoAP
>    response.  The CoAP request-response exchange with block option is
> 
> The definite vs. indefinite articles here don't seem quite right, and
> each of the 10 datagrams do not encapsulate the entire CoAP request. 
> 
> <pvds> 
> 
> I don't understand your meaning. 

I'm complaining that the "an"s and "the"s don't match up.
I think I also misunderstood the sense of what was happening, so my "do not
encapsualte the entire CoAP request" is not quite right.

NEW:

   tenth packet of 63 bytes.  The client sends an IPv6 packet containing
   a UDP datagram with DTLS record protection that encapsulates a block
   of the CoAP request 10 times (one packet per block).  The server returns
   an IPv6 packet containing the UDP datagram with the DTLS record that
   encapsulates the CoAP response.  The CoAP request-response exchange
   with block option is [...]


> </pvds>
> 
[...]
> Appendix C.2
> 
> [I mentioned otherName's non-decoding earlier]

Specifically, in crypto/x509/v3_alt.c:

STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
                                       GENERAL_NAME *gen,
                                       STACK_OF(CONF_VALUE) *ret)
{
    [...]
    switch (gen->type) {
    case GEN_OTHERNAME:
        if (!X509V3_add_value("othername", "<unsupported>", &ret))
            return NULL;

So openssl is explicitly just punting on all otherNames.

> 
> Appendix C.3
> 
> I find it kind of amusing that we have a "Netscape Comment" in the
> generated cert :) 
> 
> <pvds> 
> 
> This was the result of a lengthy openssl struggle. 
> 
> Any suggestions for improvement are very welcome indeed. 

Do you have a line with a "nsComment" in any config file (e.g., openssl.cfg)
floating around (i.e., the -config <filename> argument to openssl req)?  It
*sounds* from the documentation like this is not supposed to be added by
default (though many of the apps/ and demos/ config files in the tree do
include it).

-Ben

> </pvds>
> 
> _