Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Sten Carlsen <> Thu, 30 March 2017 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3F88127419 for <>; Thu, 30 Mar 2017 08:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Vw81eudKu1Sw for <>; Thu, 30 Mar 2017 08:21:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E0EBA1242EA for <>; Thu, 30 Mar 2017 08:21:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 30CC4400BC for <>; Thu, 30 Mar 2017 17:20:57 +0200 (CEST)
Received: from silver4.local (unknown []) by (Postfix) with ESMTPA id 042CBC1FE097 for <>; Thu, 30 Mar 2017 17:21:07 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 042CBC1FE097
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20170103-s-dk; t=1490887268; bh=Rmvermdvahf8wVvDB1gzTfifmWcODuovshyco4lyYyQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ktOvDIwQM024RkGhYMORmpRxrNUniSeauK5zn384FyTtDmJRnZw3W+zRpibzD0xKA WnuprbO4u9eFIfa+p1cEd1P40ZlddHAYFqXzxwblCsbFJPm+j3c18zRGiPL0SVDLf0 e8As/FzXK+yI4FA9yolOfDPVMKUaTcSbUa5oeEYQ=
References: <> <> <> <> <> <>
From: Sten Carlsen <>
Message-ID: <>
Date: Thu, 30 Mar 2017 17:21:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------357134120EE4D8B32128C965"
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Mar 2017 15:21:14 -0000

Sorry for late comment but this just caught my attention.

>>     BV> Re Security Considerations - A new comment from a
>>     conversation with Tomek (Tomek will hopefully comment more). I
>>     mentioned that I was concerned with the possibility of clients
>>     and servers getting “junk” is a security concern as someone could
>>     generate bad packets with encrypted data and send them to clients
>>     and servers in the hope to crash the either when they try to
>>     decrypt and then process junk. Tomek suggested we might want to
>>     think about whether to add some magic value to the first few
>>     bytes of a message before encrypting it and then the decrypter
>>     can check those first few bytes to see if they are value and
>>     discard the message if not. Perhaps the encoding from RFC5652
>>     would accomplish this if we are using more than just the
>>     encryptedContent? Anyway, something to think about.
>> [LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. 
>> I think that it may be a general problem for all encryption protocol. 
If someone deliberately wants to make bad packets with the purpose of
causing problems, they would be smart enough to add the same magic
number? Knowing the encryption algorithms would allow more deliberate
attempts to cause overflow etc.

I don't see any other method than careful programming and careful
testing with deliberate intent to find weak spots.

If we talk about noise or other non-intentional bad/random packet, then
a magic number will help.

Best regards

Sten Carlsen

No improvements come from shouting: