Re: [stir] Canonicalization vs. Comparison

Anton Baskov <anton@ministry.int.ru> Wed, 12 March 2014 07:44 UTC

Return-Path: <anton@ministry.int.ru>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C721A0900 for <stir@ietfa.amsl.com>; Wed, 12 Mar 2014 00:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.97
X-Spam-Level:
X-Spam-Status: No, score=0.97 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64MdbtCiJ1t5 for <stir@ietfa.amsl.com>; Wed, 12 Mar 2014 00:44:38 -0700 (PDT)
Received: from leaf.named.informdeskmedia.ru (leaf.named.informdeskmedia.ru [85.17.236.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5109C1A08EB for <stir@ietf.org>; Wed, 12 Mar 2014 00:44:37 -0700 (PDT)
Received: from [2a02:578:5002:1a::2] (account postmaster@leaf.named.informdeskmedia.ru HELO firepaw) by leaf.named.informdeskmedia.ru (CommuniGate Pro SMTP 6.0.4 _community_) with ESMTPSA id 2313778; Wed, 12 Mar 2014 11:44:30 +0400
Date: Wed, 12 Mar 2014 09:44:25 +0200
From: Anton Baskov <anton@ministry.int.ru>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Message-Id: <20140312094425.726cab3e4df68f35eee23f5b@ministry.int.ru>
In-Reply-To: <CA69600C-422B-484F-9229-AC6068BE165A@oracle.com>
References: <CAL02cgQtoHm2w3EWOr_66TANOk3pRoaUDmYA5GdUk6=2-jV5OA@mail.gmail.com> <ED9758F5-947F-4CA3-8C42-382D7E31CC8B@brianrosen.net> <E42CCDDA6722744CB241677169E83656025CDFF2@MISOUT7MSGUSR9I.ITServices.sbc.com> <00C069FD01E0324C9FFCADF539701DB3BBF3AF02@sc9-ex2k10mb1.corp.yaanatech.com> <CA69600C-422B-484F-9229-AC6068BE165A@oracle.com>
X-Mailer: Sylpheed 3.3.1 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stir/F9apZooRABULKBV3o_4vZpo4zeg
Cc: "rlb@ipv.sx" <rlb@ipv.sx>, "stir@ietf.org" <stir@ietf.org>, Michael Hammer <michael.hammer@yaanatech.com>, "md3135@att.com" <md3135@att.com>, "br@brianrosen.net" <br@brianrosen.net>
Subject: Re: [stir] Canonicalization vs. Comparison
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 07:44:40 -0000

Agree with Hadriel,
inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From can appear in golden object in canonized or not canonized form).

Anton

On Mon, 3 Mar 2014 14:08:43 -0500
Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:

> 
> On Mar 3, 2014, at 9:50 AM, Michael Hammer <michael.hammer@yaanatech.com> wrote:
> 
> > Richard,
> > 
> > The inclusion of the golden object in the message is a waste, since the
> > receiver must re-generate it anyway.
> > The receiver cannot rely on just the golden object, since that could be
> > spoofed.
> > It can rely only on the one it generates itself, and can pretty much ignore
> > the one in the message.
> > So, this really devolves to just one case.
> 
> Actually there were three benefits to it, identified in draft-kaplan-stir-ikes-out-00:
> 
> 1) It lets the verifier perform a very quick fail check using just strcmp(). In other words, if the golden object it generates from the To/From don't string-match the one in the Identity-X header, then it can go ahead and fail the verification immediately without bothering to get the cert, do the crypto, etc.  IF the strings match, then it has to keep doing the rest of the work to verify it.
> 
> 2) It helps debug problems for the folks running the systems.
> 
> 3) It provides a way to do a "if-then-else" conditional, in case there are multiple potential golden objects. I raised that at the mic today, but kinda forgot when exactly that might happen; I just re-read the IKES draft and it points out that in call-forwarding scenarios the verifier may well have multiple To/From canonical numbers to choose from.Agree with Hadriel, inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From field can be canonized or not).
> 
> 
> > Also, there is a danger that someone takes a short cut and does not validate
> > the included golden object.
> 
> Yup.  The implementor has to follow the MUSTs.  Not much we can do about them not doing so. :(
> 
> -hadriel
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir


-- 
Anton Baskov <anton@ministry.int.ru>
+7 (911) 254-77-92, +7 (916) 716-89-46