From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.etorok.net (mx.etorok.net [IPv6:2a00:f48:1029::1:1a2:82ea]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.etorok.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 61B4821F1DB for ; Wed, 26 Mar 2014 05:20:14 -0700 (PDT) Received: by mx.etorok.net (OpenSMTPD) with ESMTP id e98f2cff; for ; Wed, 26 Mar 2014 14:20:08 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=etorok.net; h= message-id:date:from:mime-version:to:references:in-reply-to :content-type:content-transfer-encoding; s=ml; l=1151; bh=AN/ei4 bCwCo9qjt5HShiR5ZRd68=; b=kMtvyvr0egaExRVAkuDyH5XCmomnjhmcLS6795 Ck6tD+RU8U9stimLLQpBRJ97y0sNQ7Hoazno5PeGVphBbpXtiVzodjw9iIsZ24uD M9CMBb0W7RpVvsUe/CDnpcCXdyLLxM1pj1yOOTo7Ng8NJHYZemNsL3uLKvKccLhD 9P2pk= Received: by mx.etorok.net (OpenSMTPD) with ESMTPSA id 830fdba5; TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO; for ; Wed, 26 Mar 2014 14:20:08 +0200 (EET) Message-ID: <5332C5F8.9050806@etorok.net> Date: Wed, 26 Mar 2014 14:20:08 +0200 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: cerowrt-devel@lists.bufferbloat.net References: <20140201132948.GU15505@angus.ind.WPI.EDU> <20140326024008.GU7867@angus.ind.WPI.EDU> <9250.1395808974@turing-police.cc.vt.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Cerowrt-devel] odhcp6c went crazy flooding Comcast with DHCPv6 SOLICITs X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:20:15 -0000 On 03/26/2014 12:36 PM, Aaron Wood wrote: > I also don't consider the ntp/dnssec issue a blocker, not at the moment. It's a larger problem to solve, and one that needs solving in a wider context than just CeroWRT, and so we should keep working on a solution, but not make it a "release blocking" issue. It's a known issue, a known bit of research to continue chiseling away it, but not a major blocker. > > Especially since we can always switch to raw-ip addresses for the ntp servers, as a workaround. > > But I like some of the workarounds suggested such as starting secure, and then slowly ratching down the security as things fail. So long as we don't expose a way to cripple the unit, or otherwise coerce it into misbehavior, I think we'll find a solution along those routes. This suggests using 'tlsdate', or the dhcp time option (if provided by another DHCP server): http://tools.ietf.org/id/draft-mglt-homenet-dnssec-validator-dhc-options-01.txt tlsdate looks interesting, as you'd still have *some* protection from the TLS certificate check, even if you patch it to fallback to an insecure DNS lookup. Best regards, --Edwin