Re: [POSH] Comments/questions on draft-miller-posh-00

Philipp Hancke <fippo@goodadvice.pages.de> Sun, 28 July 2013 19:10 UTC

Return-Path: <fippo@goodadvice.pages.de>
X-Original-To: posh@ietfa.amsl.com
Delivered-To: posh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6443C21F9E13 for <posh@ietfa.amsl.com>; Sun, 28 Jul 2013 12:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.014
X-Spam-Level:
X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599]
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 dbwcinlaE7I7 for <posh@ietfa.amsl.com>; Sun, 28 Jul 2013 12:09:54 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7D21F9E46 for <posh@ietf.org>; Sun, 28 Jul 2013 12:09:53 -0700 (PDT)
Received: from [10.0.0.23] (f052136037.adsl.alicedsl.de [78.52.136.37]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6SJ9jmO025244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 21:09:47 +0200
Message-ID: <51F56C79.3020503@goodadvice.pages.de>
Date: Sun, 28 Jul 2013 21:09:45 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: posh@ietf.org
References: <CAPms+wRR_ZtLq94mRCDVXEW9WyZeDmYx+1hU+zCXV1fT0GSZ+g@mail.gmail.com> <51F401CE.9080803@stpeter.im>
In-Reply-To: <51F401CE.9080803@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [POSH] Comments/questions on draft-miller-posh-00
X-BeenThere: posh@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion about PKIX Over Secure HTTP <posh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/posh>, <mailto:posh-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/posh>
List-Post: <mailto:posh@ietf.org>
List-Help: <mailto:posh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/posh>, <mailto:posh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 19:10:00 -0000

Am 27.07.2013 19:22, schrieb Peter Saint-Andre:
>> Similarly, I can't see anything obviously wrong with letting the
>> application handshake complete, then performing the POSH
>> operations before deciding the application connection is not
>> suitable and should be terminated before being used.  Is the MUST
>> in this section mandating the order of operations necessary for
>> some other reason?
>
> As mentioned above, the MUST here is perhaps a bit silly because it's
> so obvious. I think there is a better way to word it...

It isn't. In server-to-server XMPP what is typically done is to let the 
tls handshake succeed and only offer sasl external if the peer 
certificate is "valid". The same could be done for POSH... after the 
handshake is complete, look at the verification result. If it is valid, 
send stream features including external; if not, do the POSH dance.

That would typically be done in the application, not the TLS lib. Doing 
an asynchronous https request inside the verification is not something I 
would expect to be trivial.