IETF Logo Mail Archive

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 12 September 2013 06:05 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5B21E8128 for <ietf@ietfa.amsl.com>; Wed, 11 Sep 2013 23:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 c3ck4Bz+3c8N for <ietf@ietfa.amsl.com>; Wed, 11 Sep 2013 23:05:07 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 1FA0511E8118 for <ietf@ietf.org>; Wed, 11 Sep 2013 23:05:04 -0700 (PDT)
Received: (qmail 66342 invoked from network); 12 Sep 2013 05:59:53 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 12 Sep 2013 05:59:53 -0000
Message-ID: <523158E5.2060808@necom830.hpcl.titech.ac.jp>
Date: Thu, 12 Sep 2013 15:02:13 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.
References: <CAGhGL2APj-XfuMUHgLsELnZRbRNCLrjMBxFBtcg4zx+5SG7Bag@mail.gmail.com> <3C96E4A9-7E78-421F-A437-7091AEBEB5AA@ogud.com> <20130910224518.GA99190@isc.org> <91AFF488-A3F6-4E30-B542-B5C107DB6114@ogud.com> <CAMm+LwjkOEO6t5v6qMjc036JGaoFi=3jFPNDp=xM=zK5R8_k7A@mail.gmail.com>
In-Reply-To: <CAMm+LwjkOEO6t5v6qMjc036JGaoFi=3jFPNDp=xM=zK5R8_k7A@mail.gmail.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2013 06:05:12 -0000

Phillip Hallam-Baker wrote:

> 3) A relying party thus requires a demonstration that is secure against a
> replay attack from one or more trusted parties to be assured that the time
> assertion presented is current but this need not necessarily be the same as
> the source of the signed time assertion itself.

> The real design decision is who you decide you are going to rely on for
> (3). TLS is proof against replay attack due to the exchange of nonces.

How can you get secure time to securely confirm that a certificate
of TLS has not expired?

Use yet another PKI?

						Masataka Ohta

v2.23.0 | Report a Bug | By Email