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

Benjamin Kaduk <kaduk@mit.edu> Mon, 09 September 2019 14:42 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4327C120033; Mon, 9 Sep 2019 07:42:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR1VA_nlnKvi; Mon, 9 Sep 2019 07:42:39 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684A0120801; Mon, 9 Sep 2019 07:42:39 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x89EgXoA007972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Sep 2019 10:42:37 -0400
Date: Mon, 9 Sep 2019 09:42:33 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org
Message-ID: <20190909144232.GH18198@kduck.mit.edu>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com> <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl> <20190901204340.GG27269@kduck.mit.edu> <6b482aaed0ce510c503984dfbac7286c@bbhmail.nl> <7cd78133c263214be535ec36734f7ec1@bbhmail.nl> <30070.1568030052@dooku.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <30070.1568030052@dooku.sandelman.ca>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1IMtCa_aG5jc0UJtp4EP8gCbuFA>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 14:42:42 -0000

On Mon, Sep 09, 2019 at 12:54:12PM +0100, Michael Richardson wrote:
> 
> Peter van der Stok <stokcons@bbhmail.nl>; wrote:
>     > ..... if the SignedData is not the outermost container, then we don't
>     > care what the relevant Content-Format for it is; we only care about the
>     > Content-Format for the EnvelopedData.
> 
>     > <pvds>
> 
>     > s/ SignedData is signed/SignedData, placed in the outermost container,
>     > is signed/
> 
>     > s/ The SignedData is further protected by placing it inside of a CMS
>     > EnvelopedData/
> 
>     > SignedData placed within the Enveloped Data does not need additional
>     > signing/
> 
>     > </pvds>
> 
>     > Also, did we explicitly consider and reject AuthEnvelopedData?
> 
>     > <pvds>
> 
>     > Not sure about this
> 
> Jim Schaad <ietf@augustcellars.com>; wrote:
>     > [JLS] As a CMS person, I would consider the use of EnvelopedData and
>     > AuthEnvelopedData to be equivalent.  Which of these is used is totally
>     > dependent on what algorithm is used for encryption.  If one requires
>     > the use of AES-GCM or AES-CCM then one has no choice but to use
>     > AuthEnvelopedData.  If one wants to use AES-CCM ten one has no choice
>     > but to use EnvelopedData.  Everybody is slowly moving from
>     > EnvelopedData to AuthEnvelopedData just because everybody is changing
>     > algorithms.  I do not remember any discussions about this, but
>     > AuthEnvelopeData is generally going to be the more correct value here.
>     > I will also note that there is a space between Enveloped and Data which
>     > is not CMS.
>     > </pvds>
> 
> So, on a constrained device, I'd like to know what to expect (what to code
> for).  While I do'nt particularly care for server-generated keys, it should
> probably be specified correctly.  I see that the complexity of sorting this
> means that I think that Content-Format 284 (unprotected) will get used most
> often.

Your constrained device is probably only going to implement one cipher
[mode], too, right?  If it's an AEAD mode, you use AuthEnvelopedData;
otherwise, classic EnvelopedData.

> Is there a good reference that would let us rip out more of this paragraph?

We seem to have dropped enough quoting that there's not any paragraph here
that's in the current document :)

>     > 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.
> 
> Server-side key generation is optional, but when used, I agree that the
> question of which mechanism the server should use to return the key is
> completely open.   The client can indicate what it supports via CoAP Accept
> "header".  https://datatracker.ietf.org/doc/draft-amsuess-core-accept-any/
> might be useful here.

That seems like a good point.

>     > <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.
> 
>     > </pvds>
> 
>     > Why OPTIONAL?  (Also, nit: OPTIONALLY isn't a 2119 keyword; only
>     > OPTIONAL.)
> 
>     >    client.  For example, it could be configured to accept POP linking
>     > information that does not match the current TLS session because the
>     > authenticated EST client Registrar has verified this information when
>     > acting as an EST server.
> 
>     > This is close enough to a literal quote that we might think about
>     > actually quoting and using quotation marks.  nit: s/POP/PoP/ if we
>     > don't do the literal quote.
> 
>     > <pvds>
> 
>     > Hope my co-authors will react to this
> 
>     > [JLS] I would disagree with the nit.
> 
>     > [JLS] I would agree with the nit on OPTIONALLY being wrong, but I think
>     > that it ought to be at least a SHOULD if not a MUST for the use of
>     > COAPS as it is terminating the connection.  The only exception would be
>     > in there is internal authentication for the EST request.
> 
>     > </pvds>
> 
> 
> Okay, I'm seeing three things here.
> 1) tls-unique can't be used across the proxy, and we need additional
>    configuration.  I don't think we should quote literally, I think the
>    point is to hammer the point home.
> 
> 2) You are saying that we should replace tls-unique (RFC5929) with a TLS
>    Exporter. But RFC7030 didn't reference RFC5705.
>    You are suggesting that we update ourselves to use RFC5705.
>    That would seem to require that we change some PKIX things in CSR.

>From a crypto perspective, we should do that.  From a
protocol-specification perspective, we should retain parity with classic
EST and only update when it does.  So we should probably mostly ignore this
other than trying to kick off work on classic EST, and mandating
extended-master-secret.

> 3) I'm wondering if we need to have a clear response/error code for the case
>    where the tls-unique does not match.  At least, from the HTTPS-EST
>    server to the COAPS-EST "proxy" that might be valuable, even if the
>    code it not sent back to the client.

[I didn't think much about whether this would give an attacker leverage
from which to execute new attacks]

>     > Section 9.1
> 
>     > I think we probably need this document as a reference for all the
>     > allocations; as the document effectuating the registration, we are
>     > still of interest even if most details of content encoding lie
>     > elsewhere.
> 
>     > [JLS] No response from Peter?
> 
> Is Ben suggesting that the table should say:
> 
>    +------------------------------+-------+----------------------------+
>    | HTTP Media-Type              |    ID | Reference                  |
>    +------------------------------+-------+----------------------------+
>    | application/pkcs7-mime;      |   280 | [THISDOCUMENT]             |
>    | smime-type=server-generated- |       |                            |
>    | key                          |       |                            |
>    | application/pkcs7-mime;      |   281 | [THISDOCUMENT]             |
>    | smime-type=certs-only        |       |                            |
>    | application/pkcs8            |   284 | [THISDOCUMENT]           - |
>    |                              |       |                            |
>    | application/csrattrs         |   285 | [THISDOCUMENT]             |
>    | application/pkcs10           |   286 | [THISDOCUMENT]             |
>    |                              |       |                            |
>    | application/pkix-cert        | TBD28 | [THISDOCUMENT]             |
>    |                              |     7 |                            |
>    +------------------------------+-------+----------------------------+

No, I was thinking we should add "[THISDOCUMENT]" to the existing entries,
not replace them.

> And I guess rfc5751-bis is now RFC8551.
> 
>     > So I have to wonder if I'm messing something up, somewhere.
> 
> I see that Peter has posted new examples.
> 
>     > In the key-agreement case, the symmetric key-encryption key is the
>     > result of the key-agreement operation, no?  In which case it is not
>     > itself encrypted, but rather the server's ephemeral public value is
>     > sent.
> 
>     > <pvds>
> 
>     > In RFC7030 the text says: the EnvelopedData content is encrypted using
>     > a randomly
> 
>     > generated symmetric encryption key (that means ephemeral I assume). The
>     > cryptographic strength of
> 
>     > the symmetric encryption key SHOULD be equivalent to the
>     > clientspecified
>     > asymmetric key.
> 
>     > However, I see no explicit relation with the ephemeral public value.
> 
>     pvds> I don't know what to do here; probably insert the 7030 text.
> 
> I not understand the question here.

I think this was about relating the strength of the symmetric encryption
key to the strength of the ephemeral asymmetric share; 7030 has some text
here (quoted above, I think) but we currently do not.  So Peter is
proposing to just crib the text from 7030.

>     >    What's more, POP linking uses tls-unique as it is defined in
>     > [RFC5929].  The 3SHAKE attack [tripleshake] poses a risk by allowing
> 
>     > nit: "such POP linking" or "the CMC POP linking"
> 
>     > <pvds>CMC POP </pvds>
> 
>     >    a man-in-the-middle to leverage session resumption and renegotiation
>     > to inject himself between a client and server even when channel binding
>     > is in use.  The attack was possible because of certain (D)TLS
>     > implementation imperfections.  In the context of this specification,
> 
>     > I don't think we can solely blame the attacks on implementation
>     > imperfections (though they were certainly compounding factors).  Does
>     > this sentence really add any value to the current document?
> 
>     > <pvds>
> 
>     > Leave this to my co-authors
> 
>     > </pvds>
> 
> I think that 3SHAKE requires session resumption to be supported.
> I'm not sure that using session resumption is the best thing in a constrained
> client system.  I think that whenever we get to doing a new operation, that
> we actually need a new session setup at that point anyway.

Hmm, but we perhaps cannot guarantee that this will hold universally for
all devices implementing coap-est.
I do think that we can mandate other aspects that make 3SHAKE impossible
(like extended-master-secret), though.

>     >    binding mechanism.  Such a mechanism could include an updated tls-
>     > unique value generation like the tls-unique-prf defined in
>     > [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS
>     > 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]).  Such
>     > mechanism has not been standardized yet.  Adopting a channel binding
> 
>     > We probably should be explicit about "using a TLS Exporter value in
>     > place of the tls-unique value in the CSR", just from a writing clarity
>     > perspective.
> 
>     > <pvds>
> 
>     > Leave to my co-authors from here to section 10.2
> 
>     > </pvds>
> 
> I think that we could go to TLS Exporter right now, but it would take some work.

I'd rather have both classic-EST and coap-EST benefit than just coap-EST.

-Ben

> 
>     > 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?
> 
>     > Actually openssl was used extensively for generating the examples.
> 
>     > Will be happy to learn about otherName
> 
>     > </pvds>
> 
> there is a whole bunch of othername not supported.
> asn1parse isn't terribly informative here, in my opinion.
> 

> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
>