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

Peter Saint-Andre <stpeter@stpeter.im> Fri, 07 November 2014 03:49 UTC

Return-Path: <stpeter@stpeter.im>
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 A03841A0147 for <xmpp@ietfa.amsl.com>; Thu, 6 Nov 2014 19:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Level:
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, 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 Co28pgkl2dmG for <xmpp@ietfa.amsl.com>; Thu, 6 Nov 2014 19:49:50 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E52D31A013B for <xmpp@ietf.org>; Thu, 6 Nov 2014 19:49:49 -0800 (PST)
Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3074220701; Thu, 6 Nov 2014 20:55:40 -0700 (MST)
Message-ID: <545C4159.6000404@stpeter.im>
Date: Thu, 06 Nov 2014 20:49:45 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
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>
In-Reply-To: <544B622A.9050807@goodadvice.pages.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HgMjfSG8edWH6kPjcSaopfkCjbI
X-Mailman-Approved-At: Thu, 06 Nov 2014 20:43:22 -0800
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 03:49:51 -0000

On 10/25/14, 2:41 AM, Philipp Hancke wrote:
> Am 14.10.2014 01:17, schrieb Ben Campbell:
>> (Oops, messed up the authors' address the first time. Apologies for
>> the duplicate.)
>>
>> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The
>> draft is available at the following URL:
>>
>> http://tools.ietf.org/html/draft-ietf-xmpp-posh-02
>>
>> The WGLC will conclude on 27 October, 2014. Please send your comments
>> to the authors and the XMPP mailing list.
>
> In several places, "Server identity" and "TLS client" are used, e.g.
>  > Server identity checking (see [RFC6125]) involves three different
>  > aspects:
> [...]
>  > a TLS client SHOULD consider the delegation invalid.
>
> I think this is not the "TLS client" but the "POSH client" and the "Peer
> Identity". The main use case is when an xmpp s2s-server uses POSH to
> verify an incoming connection.

Initially I was resistant to your suggestion (preferring something like 
"POSH-aware TLS client"), but I see your point about incoming 
connections so it makes sense to me that we modify the terminology.

> 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.

Peter