Re: [Ace] EST over CoAP

Hannes Tschofenig <> Mon, 14 May 2018 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 407D012DA13 for <>; Mon, 14 May 2018 04:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0DPWHhjf1C0 for <>; Mon, 14 May 2018 04:53:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11B6B126D45 for <>; Mon, 14 May 2018 04:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/YdGVBIq5MyJT3/sWf7BuDKM5MKs85+m4LYQcJgDN1o=; b=lBShftwrEfjJ7z003ZTc8Jd5ubPJrutiQNXdDpi+iJc9NH8pVR3W9Hn1OBWM3zk3a68va6xsdx96mlaba01y9x+FztsMJgvC4N//UxizSrtddXw/MURlhpjH8ntA3mUYOJvDYMkAlcMiRp+Ehh65YvAOrUWM3DKO+VkinuUPnHs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 11:53:35 +0000
Received: from ([fe80::7c43:c1a5:4f69:5365]) by ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 11:53:35 +0000
From: Hannes Tschofenig <>
To: Michael Richardson <>
CC: "" <>
Thread-Topic: [Ace] EST over CoAP
Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAFfjAAAABx6qA=
Date: Mon, 14 May 2018 11:53:35 +0000
Message-ID: <>
References: <> <13072.1526297934@localhost>
In-Reply-To: <13072.1526297934@localhost>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1869; 7:PrIAVz9YHCfzE6Agdy8BtlpGI8abeEfLIyxp/oQCueFoPzIYSTAMlFGFcTLUf3LsFdBEtQgS+MAanlYS/hD8uBg08WUIeFTExgJkOUFYSN45JjVixO2a0zvRzRELArwJ8A9v37FSW5kBQwgMQyBR3PGjYtNIUflTo3MMH365+ieFWuzVPhNkiBXPbBjGjOtKWbKis6z10T1EJv4ONmbXAWM7GDY1rMvxt5JE8oKaCuYdLbFcIN0X+RiJDf+SvLhH
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1869;
x-ms-traffictypediagnostic: VI1PR0801MB1869:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(180628864354917)(120809045254105);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB1869; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1869;
x-forefront-prvs: 067270ECAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(40434004)(13464003)(51914003)(189003)(199004)(476003)(25786009)(446003)(11346002)(229853002)(66066001)(6436002)(14454004)(305945005)(486006)(105586002)(106356001)(33656002)(74316002)(7696005)(7736002)(99286004)(8936002)(81156014)(59450400001)(81166006)(3280700002)(76176011)(8676002)(68736007)(3660700001)(316002)(6246003)(5660300001)(97736004)(2906002)(55016002)(53936002)(2900100001)(6306002)(9686003)(3846002)(966005)(5890100001)(72206003)(6116002)(86362001)(6506007)(186003)(4326008)(5250100002)(26005)(53546011)(102836004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1869;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DGNUxblgvm0V4PXw/YThN+h2edft21cme2ArlVc6bXczlu3we+cvfGNdQw1x/wG0BOyCsikwOZCnPjiq3NLR7ptEBWpRbRIK5UOs9C49OlgiHanugiK1V90YAEf0Ey1TC0YTi9JxLsScS363W47f7QbIGyimKnNG5e8nJwsqJLvxGabH2n5QlWYmasiqphay
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 84e9d6ed-09ab-4b85-a748-08d5b99152e3
X-MS-Exchange-CrossTenant-Network-Message-Id: 84e9d6ed-09ab-4b85-a748-08d5b99152e3
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 11:53:35.3903 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1869
Archived-At: <>
Subject: Re: [Ace] EST over CoAP
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 May 2018 11:53:41 -0000

Hi Michael,

Thanks for the feedback.

Why do you think it takes so long to get this document finished? In the end, you are just carrying EST over CoAP instead of conveying it over HTTP.


PS: Regarding the use of DTLS/TLS for the proxy. There are obviously ways to get this accomplished but the question for me is whether this functionality should go into this version of the spec or rather a companion document.

-----Original Message-----
From: Michael Richardson []
Sent: 14 May 2018 12:39
To: Hannes Tschofenig
Subject: Re: [Ace] EST over CoAP

Hannes Tschofenig <> wrote:
    > At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see

    > -          Operational parameter values
    > -          Server side key generation using simple multipart encoding
    > -          Explain trust relations for http/coap proxying

    > I have challenged the usefulness of the server-side key generation
    > during the meeting but in general I am curious where we are with the
    > document. It would be great to get it finalized. It appears that we are
    > adding new features and therefore will not be able to complete the work
    > in any reasonable timeframe.

Server side key generation is not the only way to use this, and I'm not interested in it myself.

I don't think we can do http/coap proxying in any meaningful way if we are using TLS/DTLS for the secure transport.  I have encouraged my co-authors to either take it out, or realize that they are confusing the EST link (over DTLS) with the Registration Authority<->Certificate Authority link (over HTTPS).

    > So, do we have a plan for how to complete the document?

I am implementing at this time, with CoAP over DTLS using OpenSSL today,
and mbedTLS for the pledge side in a week or two.   I believe that we can
finish this document by the end of the summer.  I don't think we'd get to WGLC before IETF102, and as August is a dead zone for IETF work, having a WGLC before September 1 would seem pointless.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.