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

Michael Procter <michael@voip.co.uk> Mon, 29 July 2013 10:35 UTC

Return-Path: <michael@voip.co.uk>
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 5AE2821F9DB2 for <posh@ietfa.amsl.com>; Mon, 29 Jul 2013 03:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level:
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 K9oZWpsfTzRy for <posh@ietfa.amsl.com>; Mon, 29 Jul 2013 03:35:00 -0700 (PDT)
Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with SMTP id BC9B121F9D7B for <posh@ietf.org>; Mon, 29 Jul 2013 03:34:59 -0700 (PDT)
Received: from mail-wi0-f178.google.com ([209.85.212.178]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUfZFU3Rhy8Gbfy5QsIc3+oR6gMjeX5J4@postini.com; Mon, 29 Jul 2013 03:34:59 PDT
Received: by mail-wi0-f178.google.com with SMTP id j17so2308525wiw.17 for <posh@ietf.org>; Mon, 29 Jul 2013 03:34:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YaiFohOZnXzxVWDL3moM4Ab9mpt+peLzZWKEBgq9TLk=; b=peBkj0wGhlUP4dGboCX8h6RGLf0BrrC4/JmIKFAzs11HI0RRnLU4Frv8ZUwn3EyWOg cxD4Dbgg4f1YrTrEWs34VeD9QYRnIOAm9Rn9SCDDfBnz6wJUqBHZR3u0wS3n9eAvcN9/ /4Di9OyWOOffFMhcGiyYSxzWsRN1/MTZQVm2XHadLh43MVoFgjTmv7zibwi2qHWHc7ji CZO4akS059pQFMgc0e4Qh5Vs111vNmcOLOSIKsPV4p5u+ria3eBKuJBj0azWdxjNRT5O rcmXxGMayk4I8pbpp3Q4CSa2nraJkmpnQfVs5VYI1eRZwIgmapiycIyezXsenXaIBjGi EkOw==
X-Received: by 10.180.38.45 with SMTP id d13mr6610615wik.62.1375094098208; Mon, 29 Jul 2013 03:34:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.38.45 with SMTP id d13mr6610554wik.62.1375094096951; Mon, 29 Jul 2013 03:34:56 -0700 (PDT)
Received: by 10.194.164.234 with HTTP; Mon, 29 Jul 2013 03:34:56 -0700 (PDT)
In-Reply-To: <51F56C79.3020503@goodadvice.pages.de>
References: <CAPms+wRR_ZtLq94mRCDVXEW9WyZeDmYx+1hU+zCXV1fT0GSZ+g@mail.gmail.com> <51F401CE.9080803@stpeter.im> <51F56C79.3020503@goodadvice.pages.de>
Date: Mon, 29 Jul 2013 11:34:56 +0100
Message-ID: <CAPms+wSx9mEGDijbB-odZkYZ6nTe-USqbpp5ow6kV6sJv2AHgA@mail.gmail.com>
From: Michael Procter <michael@voip.co.uk>
To: Philipp Hancke <fippo@goodadvice.pages.de>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQmnCcX0pmrKldRyl4v3RL4vuXnOoe5Vq6hMvo9z3oMrm5tUQRTBafm017rpNSZEHsmbPDO75JVKJl2G7fymXyLdpKaPR8ODWi0v8MXarwjQopd8wd5nus0awbzriBg7lvvKOYwB
Cc: posh@ietf.org
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: Mon, 29 Jul 2013 10:35:00 -0000

On 28 July 2013 20:09, Philipp Hancke <fippo@goodadvice.pages.de> wrote:
> 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.

Thanks, Philipp.  That is the sort of scenario I was thinking about,
which is why I questioned the MUST.  Doing the POSH lookup after the
TLS handshake seems fine, as long as the application doesn't try to
use the not-yet-verified connection until POSH completes.  I can't
think of a protocol reason why the TLS handshake must be held off
until POSH completes, unless you wish to withold a client cert until
the server is trusted.  That obviously doesn't apply if you aren't
doing mutual auth.

Regards,

Michael