IETF Logo Mail Archive

Re: [Dtls-iot] draft-hartke-dice-practical-issues-00.txt

Klaus Hartke <hartke@tzi.org> Mon, 07 October 2013 15:33 UTC

Return-Path: <hartke@tzi.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B021E8087 for <dtls-iot@ietfa.amsl.com>; Mon, 7 Oct 2013 08:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Level:
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS5ghhSJmAeE for <dtls-iot@ietfa.amsl.com>; Mon, 7 Oct 2013 08:33:42 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54221E8099 for <dtls-iot@ietf.org>; Mon, 7 Oct 2013 08:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r97FXbCc015405 for <dtls-iot@ietf.org>; Mon, 7 Oct 2013 17:33:37 +0200 (CEST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DB2703A3 for <dtls-iot@ietf.org>; Mon, 7 Oct 2013 17:33:36 +0200 (CEST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so3902607veb.12 for <dtls-iot@ietf.org>; Mon, 07 Oct 2013 08:33:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bQr4itI8qrpDy6q4XWWmPxj1+iLikW4SRvL/twfXXe0=; b=hZf05Teliuok/kJDkaIw6X9R5qRpFEQWo5owe6+X3WJN3Y4E8jj/DVXUAXX7Ixl7YH eBwF0n+l4Mu3+sor7VsjPuXFqnJXlAZXbNF0WX+LCJjVWS0l15C2As6ZqQXMhYGvdL4I ec2NB/TB2xYo85mUPn1JrT9Iii08o66Cef+pWvgi+LEBBI6yE0LYP5wXuO1aV8AJqo8Q fqMAkiKBYlPK1lw5udR7hb6ayk4eFrQhJBQaVsp8cW90RBSok6elCaK6l/7QDxp6TFfK PnaWZDMR2aVUVN4wHYSkBjQLOBreE4OgQTDaVsMElzZSPlouEnBiLMGPMxar+1rSC7Gc gDtA==
X-Received: by 10.58.218.225 with SMTP id pj1mr990244vec.24.1381160015526; Mon, 07 Oct 2013 08:33:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.24.83 with HTTP; Mon, 7 Oct 2013 08:32:55 -0700 (PDT)
In-Reply-To: <A3090F29-E9B4-46BB-9345-EA5975148659@tzi.org>
References: <20131007144053.16131.80399.idtracker@ietfa.amsl.com> <A3090F29-E9B4-46BB-9345-EA5975148659@tzi.org>
From: Klaus Hartke <hartke@tzi.org>
Date: Mon, 07 Oct 2013 18:32:55 +0300
Message-ID: <CAAzbHvbcAcT5sTKEq-2z3yMOpX8=EoDv_50vixg6CN_1tBL7og@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Subject: Re: [Dtls-iot] draft-hartke-dice-practical-issues-00.txt
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 15:33:48 -0000

Carsten Bormann wrote:
> Nice draft.
>
> A couple of quick comments:

Feedback before I had the chance to forward the announcement to the
mailing list -- *like*.

The draft is an update of draft-hartke-core-codtls-02 with a few small
additions and a new section that compares alternative strategies for
DTLS handshake reliability.

What I'd be interested in now is if other implementers share the
assessment or if it's just me.

> [DCOSS12] does *not* use GHC, instead they invent a header compression format not unlike the one in the draft (which fits into the RFC 6282 NHC scheme just like GHC does).

Fixed in the next revision, thanks.

> GHC happens to outperform the DCOSS12 scheme in many cases, because it looks at the whole packet, so it also compresses the cipher suite specific header.  Any attempt to get good compression should make use of this somewhat surprising result.

Do you have some numbers that I could add to the draft?

Best regards,
Klaus

v2.23.0 | Report a Bug | By Email