IETF Logo Mail Archive

Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 07 November 2014 16:03 UTC

Return-Path: <peter@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD21A01A8 for <xmpp@ietfa.amsl.com>; Fri, 7 Nov 2014 08:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 baqONs-rY3yc for <xmpp@ietfa.amsl.com>; Fri, 7 Nov 2014 08:03:34 -0800 (PST)
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C84D1A3BA0 for <xmpp@ietf.org>; Fri, 7 Nov 2014 08:03:34 -0800 (PST)
Received: by mail-ig0-f175.google.com with SMTP id h3so13021317igd.14 for <xmpp@ietf.org>; Fri, 07 Nov 2014 08:03:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j4hlmqxA/Dx5f6pOesZPBypFAuIqkGzHlkYsHsAKTGg=; b=j+kle7rY2UWripbNCVr8/C0ndagBq2ZF0evFle0N/76daQU0WL4AaHQHZa++ncMyUf 1Su8MGRejezBzxq6mw8+YWdkX+Ebvz6P4awdLU1lhfz2XmF+7hMXOHE6SDbdDUA27X2t BGGm9qjaC3ImsUWgUL6zvFHDuM50tyjBc+lCGXJXXA3pjeH7uww7IxGS0r04Rt5Ss+7U 2dIMHW0KLRDsC4NVinvDpEXn25iskIbLu1fu/jRDnWtYemuPI7vexTggqJNeibtRQXOk D2AdtzMdteaQz7tOnTinnVNgg1S3vC3I5l/aX07imARJ+VYvnZzFG7WlRvHkMjG1EVyL viSA==
X-Gm-Message-State: ALoCoQndhMfWL1LINToDnzCbTiu2CNnILf68NodQvLMNov/GOj7OhSR0xvcFR5kEgYtHKR13sICG
X-Received: by 10.107.154.144 with SMTP id c138mr13981768ioe.11.1415376213498; Fri, 07 Nov 2014 08:03:33 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id kb7sm819740igb.16.2014.11.07.08.03.32 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 08:03:32 -0800 (PST)
Message-ID: <545CED53.2060807@andyet.net>
Date: Fri, 07 Nov 2014 09:03:31 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, XMPP Working Group <xmpp@ietf.org>
References: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com> <544B622A.9050807@goodadvice.pages.de> <545C4159.6000404@stpeter.im>
In-Reply-To: <545C4159.6000404@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/06Y-r5IkaGt57z-8JQepDcHwD50
Cc: draft-ietf-xmpp-posh.all@tools.ietf.org
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-posh-02
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Nov 2014 16:03:37 -0000

On 11/6/14, 8:49 PM, Peter Saint-Andre wrote:
> On 10/25/14, 2:41 AM, Philipp Hancke wrote:
>
>> section 5:
>>      The TLS client SHOULD perform all POSH retrievals
>>      before opening any socket connections to the application
>>      protocol server.
>> (ed: extra whitespace before that sentence)
>>
>> SHOULD is too strong here. I see it as a fallback rather and would only
>> do POSH when not finding a proper identity. This would mean that
>> sometimes, POSH is used without need.
>> I suspect this makes it easier to use POSH as part of the TLS handshake
>> rather than as an application layer check.
>>
>> This is also not possible for the s2s scenario where POSH may be
>> triggered by an incoming
>> <db:result>somekeywhichwouldnotbeused</db:result>
>> which would happen after <starttls/> and after the TLS handshake itself
>> is done.
>>
>> Should be easy to fix though.
>
> Yes, Matt and I will do some wordsmithing.

I propose the following:

    In cases where the POSH client initiates an
    application-layer connection, the client SHOULD perform all POSH
    retrievals before initiating a connection (naturally this is not
    possible in cases where the POSH client receives an application-layer
    connection).

Peter

-- 
Peter Saint-Andre
https://andyet.com/

v2.23.0 | Report a Bug | By Email