From nobody Wed Oct  1 18:11:47 2014
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 3FB901A8875 for <xmpp@ietfa.amsl.com>; Wed,  1 Oct 2014 18:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.009
X-Spam-Level: 
X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 EMDbZM-gVn2q for <xmpp@ietfa.amsl.com>; Wed,  1 Oct 2014 18:11:43 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FA31A87F2 for <xmpp@ietf.org>; Wed,  1 Oct 2014 18:11:43 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id tr6so1529957ieb.5 for <xmpp@ietf.org>; Wed, 01 Oct 2014 18:11:43 -0700 (PDT)
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=em2gMV8uHUWu6rHETUiuptu800YSJ5bCrm3drOPsjkU=; b=kYENxWgxiwbbXFz4qbGSeAvgRbyzMO6MtJV6EB7wue0f9VVbCuo7F0Wtcr6xKVrnlD NUP7NhGD56r5bgRpOQvKnwhIsNevNDWTKPjEaHCyVg+kin2S4XcvBLBPLqTs/PZx4Qkv 0427kbAfTvCP6WlcaOKQPVSnUHwPDC4FMRdw2DjmlHWVwrYFd71Fws6EQSYRjcaQ63RC NHK6z8iLLGykxREmggCb+lUXOVxBDcfUzb0rA6ivUVMGPZhbeuF9VvhtD2PtVaoDibWz +RdXoL1X93mAM3QLH3vcVDGL0MSOK2JhhBTRXTJF0MOqaGN5Np2QFpi3BSWa3xgSyZbD +c3Q==
X-Gm-Message-State: ALoCoQkxyEtg9g0Mgoi1D3FdO5yF1qaK0KL5CZQYvdaEPbeE0z0/YvZi305mlgZ+HB2xe3+ZmC30
X-Received: by 10.43.0.133 with SMTP id nm5mr839293icb.55.1412212303084; Wed, 01 Oct 2014 18:11:43 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l4sm17055432igt.22.2014.10.01.18.11.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 18:11:42 -0700 (PDT)
Message-ID: <542C77F4.2070108@andyet.net>
Date: Wed, 01 Oct 2014 14:53:56 -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: Jonathan Lennox <jonathan@vidyo.com>
References: <20140911015217.14982.19406.idtracker@ietfa.amsl.com> <54110188.7070202@stpeter.im> <485F18B0-852F-473E-A6D0-940E1B5EBE97@vidyo.com>
In-Reply-To: <485F18B0-852F-473E-A6D0-940E1B5EBE97@vidyo.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/MEtgvfWegjohrPEb4NytoM8vKPE
Cc: "xmpp@ietf.org" <xmpp@ietf.org>
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt
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: Thu, 02 Oct 2014 01:11:45 -0000

Hi Jonathan, thank you for the review. Comments inline.

On 9/11/14, 9:04 AM, Jonathan Lennox wrote:
> On Sep 10, 2014, at 9:57 PM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
>
>> Changes to address feedback from Joe and Florian.
>>
>> Please review carefully, because some of the changes are subtle or
>> provisional - more feedback would be very helpful.
>
> I think the separation of preparation, enforcement, and comparison is
> very helpful, but I don’t think the description of enforcement is
> very clear yet — it seems to mix together normalization and validity
> checking, without a clear discussion of which rules are which.

I agree that we need to be clearer about what each action includes.

> For example: as far as I can tell, the intention from all discussions
> is that StPeter@example.com is a valid JID, which a server should
> normalize and process as stpeter@example.com, but
> “StPeter"@example.com is not, and should be rejected with
> <jid-malformed/>.

I'm not yet sure, but let's think this through.

In essence, we're trying to be nice to client developers by saying that 
you just need to do string preparation (as we've defined it, this means 
for example not transmitting in a localpart slot a string that includes 
Unicode characters outside the PRECIS IdentifierClass). So the strings 
<stpeter> and <StPeter> are acceptable as prepared strings, whereas the 
strings <St Peter> (with a SPACE) and <St—Peter> (with an EM DASH) are 
not. Note that, say, <StPeter's> with an APOSTROPHE is acceptable in a 
prepared string as we have defined it.

What is an enforcing entity supposed to do in these and other cases? 
Section 4.3.2 of 6122bis says that it needs to perform width mapping and 
case mapping and normalization, and that certain characters (e.g., ') 
are excluded/disallowed. So an enforcing entity (typically a server) 
would map <StPeter> to <stpeter>, would reject <St Peter> and 
<St—Peter>, and would very likely reject <StPeter's> (but would we say 
that it could map that to <StPeter\27s> in accordance with XEP-0106 and 
thus be liberal in what it accepts?).

> But I don’t see how you can deduce this from the
> document’s current description of “Enforcement” — both the case
> mapping and the list of invalid characters are specified as “MUST”
> requirements.

And I think that's right.

> The “Preparation” stage also doesn’t seem to require that JIDs that
> are transmitted actually be considered valid by the enforcement
> stage, which seems like a recipe for interop failure.

That might be fine, if the server behaves liberally by mapping whatever 
it can map.

> 6122’s language was "A localpart MUST be formatted such that the
> Nodeprep profile of [STRINGPREP] can be applied without failing” (and
> similarly for the other JID parts).

IIRC some folks considered that to be too weak, which why we now talk 
about enforcement.

> Can language something like this
> (mutis mutandis for Precis rather than Stringprep) be used, once
> Enforcement is clear about what is or isn’t considered failure?

I do think we need to be clear about what is or isn't considered to be 
failure, and specify what an enforcing entity needs to do if it treats a 
string as in violation the rules. My rough guidance would be:

1. If you can map it (by width mapping, case mapping, normalization, or 
JID Escaping), please do so and accept the mapped string. Postel's Law 
in action.

2. If you can't map it (because the character is disallowed by the base 
class definition or an exclusion rule, or because the string violates 
other rules such as length restrictions), refuse the string and return a 
<jid-malformed/> error.

Peter

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


From nobody Thu Oct  2 21:14:15 2014
Return-Path: <florob@babelmonkeys.de>
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 EEDC61ACFE3 for <xmpp@ietfa.amsl.com>; Thu,  2 Oct 2014 21:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 tRM_BepihZbT for <xmpp@ietfa.amsl.com>; Thu,  2 Oct 2014 21:13:54 -0700 (PDT)
Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2E61ACFE4 for <xmpp@ietf.org>; Thu,  2 Oct 2014 21:13:54 -0700 (PDT)
Received: from xdsl-78-34-99-244.netcologne.de ([78.34.99.244] helo=[192.168.0.140]) by babelmonkeys.de with esmtpsa (TLS1.1:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <florob@babelmonkeys.de>) id 1XZuFb-0003zW-EY; Fri, 03 Oct 2014 06:13:51 +0200
Message-ID: <542E2279.10608@babelmonkeys.de>
Date: Fri, 03 Oct 2014 06:13:45 +0200
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: xmpp@ietf.org
References: <20140911015217.14982.19406.idtracker@ietfa.amsl.com> <54110188.7070202@stpeter.im>
In-Reply-To: <54110188.7070202@stpeter.im>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/-lUM8Bs0AqQGONFs6hndp_CTcpw
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt
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, 03 Oct 2014 04:14:08 -0000

On 11.09.2014 03:57, Peter Saint-Andre wrote:
> Changes to address feedback from Joe and Florian.
> 
> Please review carefully, because some of the changes are subtle or
> provisional - more feedback would be very helpful.
> 
I've finally found some time (and remembered) to look over this.

I'd like to echo Jonathan Lennox concerns that preparation, enforcement,
and comparison seem a bit under-defined.
In particular enforcement needs some text specifying how invalid JIDs
should be handled by a server.

In section 3 the claim that a server needs to perform preparation in
some cases seems strange to me. From the detailed description in section
5 it always either enforces the rules, or treats the JID as an opaque
part of a c2c protocol.

In section 4.1 it seems a bit unfortunate to say that each code point
needs to conform to a string class. Conformance to such a class is a
property of the string as a whole, due to CONTEXTJ/CONTEXTO.

It is unclear to me how section 4.2.2 is consistent with RFC 5895 as it
claims.
Section 2 of RFC 5895 appears to specify that mappings are performed
before code points are checked for conformance (i.e. step 2 and 3 need
to be performed before step 1 here), and also specifies two more
preparation steps. In general I'm still uncomfortable with trying to
reproduce IDNA2008's algorithms instead of just referencing them.

The text in section 4.4.2 still doesn't seem to address Joe's and my
concerns. Making width and case mappings optional poses an
interoperability hazard. If a sending server performs these mappings,
while the receiving server doesn't, this will yield stanzas that can not
be routed. I would strongly suggest either dropping any text about these
mappings, or making this a MUST NOT.

Regards,
Florian

> Thanks!
> 
> Peter
> 
> On 9/10/14, 7:52 PM, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Extensible Messaging and Presence
>> Protocol Working Group of the IETF.
>>
>>          Title           : Extensible Messaging and Presence Protocol
>> (XMPP): Address Format
>>          Author          : Peter Saint-Andre
>>     Filename        : draft-ietf-xmpp-6122bis-13.txt
>>     Pages           : 29
>>     Date            : 2014-09-10
>>
>> Abstract:
>>     This document defines the address format for the Extensible Messaging
>>     and Presence Protocol (XMPP), including support for code points
>>     outside the ASCII range.  This document obsoletes RFC 6122.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-13
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-13
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>


From nobody Fri Oct 10 09:18:17 2014
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 6CC3A1A1B8A for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 09:18:15 -0700 (PDT)
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 uvqonviV613x for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 09:18:13 -0700 (PDT)
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92D11A8885 for <xmpp@ietf.org>; Fri, 10 Oct 2014 09:15:29 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hn15so3338603igb.3 for <xmpp@ietf.org>; Fri, 10 Oct 2014 09:15:29 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B28ttlqGiKPma3/BKbIZ1MYtq/Gj8RM7BcB1GM/DYG4=; b=BjM+7ZBq8B+RZr0SyDgGrKfcXiAxTv9BeTv+DIdO1RpH1CZIjr0um9TnPmCCe8h952 /ptGT7X+q6lWxxgZZo3y9MJgNLo4QZk7T8KBzZ8wpJt5OGNEWaa1BQfqnxjRztl9uQqT 6ccoFTv+ClBvVsO1kJhub3RZu7VsuW5np3WV54rlm4bLUx9KWDpNZ88cmfcqUP/quGi3 6/ERFj+Sj2AO9qKJ26CzTBR8mpm5SOUBMpS5A4wfR3Ym7P2tClHrqxWlMlNlrn9Bq/c8 10Wnki+dhb660t1erjRV7HpyKGWM2R3f8QhX1vmTXFnItBZidjs1duFBoolPY/9VI5gp 1SqA==
X-Gm-Message-State: ALoCoQlsZUvj2nt3s2fOhiGbtnf9vW2ArdptLyK/a86PndVhZTv23T0eJDgNloX2WVXAq4Po1bXO
X-Received: by 10.50.102.106 with SMTP id fn10mr8409873igb.14.1412957729186; Fri, 10 Oct 2014 09:15:29 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id z3sm2139819ign.22.2014.10.10.09.15.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 09:15:28 -0700 (PDT)
Message-ID: <5438061E.6000908@andyet.net>
Date: Fri, 10 Oct 2014 10:15:26 -0600
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: xmpp@ietf.org
References: <20140911015217.14982.19406.idtracker@ietfa.amsl.com> <54110188.7070202@stpeter.im> <542E2279.10608@babelmonkeys.de>
In-Reply-To: <542E2279.10608@babelmonkeys.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ujql6avqpw8tRUERZOEIR8OF8Lc
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt
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, 10 Oct 2014 16:18:15 -0000

On 10/2/14, 10:13 PM, Florian Zeitz wrote:
> On 11.09.2014 03:57, Peter Saint-Andre wrote:
>> Changes to address feedback from Joe and Florian.
>>
>> Please review carefully, because some of the changes are subtle or
>> provisional - more feedback would be very helpful.
>>
> I've finally found some time (and remembered) to look over this.

Hi Florian, thanks for the review.

> I'd like to echo Jonathan Lennox concerns that preparation, enforcement,
> and comparison seem a bit under-defined.
> In particular enforcement needs some text specifying how invalid JIDs
> should be handled by a server.

I have some text about this in a working copy, and I plan to publish a 
revised I-D soon (maybe even today or tonight).

> In section 3 the claim that a server needs to perform preparation in
> some cases seems strange to me. From the detailed description in section
> 5 it always either enforces the rules, or treats the JID as an opaque
> part of a c2c protocol.

I'm thinking about things like vCard storage. If I add someone else to 
my vCard, does the server need to perform enforcement or does it treat 
the person's JID as opaque or does it perform preparation? Hmm, I think 
you're right that it wouldn't do preparation only...

> In section 4.1 it seems a bit unfortunate to say that each code point
> needs to conform to a string class. Conformance to such a class is a
> property of the string as a whole, due to CONTEXTJ/CONTEXTO.

That's a very good point. I'll find a way to reword that text.

> It is unclear to me how section 4.2.2 is consistent with RFC 5895 as it
> claims.
> Section 2 of RFC 5895 appears to specify that mappings are performed
> before code points are checked for conformance (i.e. step 2 and 3 need
> to be performed before step 1 here), and also specifies two more
> preparation steps. In general I'm still uncomfortable with trying to
> reproduce IDNA2008's algorithms instead of just referencing them.

Yes, I think referencing them is better. I will rework that section.

> The text in section 4.4.2 still doesn't seem to address Joe's and my
> concerns. Making width and case mappings optional poses an
> interoperability hazard. If a sending server performs these mappings,
> while the receiving server doesn't, this will yield stanzas that can not
> be routed. I would strongly suggest either dropping any text about these
> mappings, or making this a MUST NOT.

OK, I will think about this some more and reply on the list or just 
update the spec with improvements.

Thanks again for the review.

Peter

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


From nobody Fri Oct 10 13:48:29 2014
Return-Path: <internet-drafts@ietf.org>
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 244AB1AD33B; Fri, 10 Oct 2014 13:48:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 53g12R1R4Coo; Fri, 10 Oct 2014 13:48:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE071AD277; Fri, 10 Oct 2014 13:47:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141010204758.29803.21356.idtracker@ietfa.amsl.com>
Date: Fri, 10 Oct 2014 13:47:58 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/UQ2oIIgxRtjae8NS0krnwW4BapI
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-14.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Oct 2014 20:48:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Extensible Messaging and Presence Protocol (XMPP): Address Format
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-xmpp-6122bis-14.txt
	Pages           : 29
	Date            : 2014-10-10

Abstract:
   This document defines the address format for the Extensible Messaging
   and Presence Protocol (XMPP), including support for code points
   outside the ASCII range.  This document obsoletes RFC 6122.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 10 13:57:00 2014
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 D6C671AD385 for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 13:56:58 -0700 (PDT)
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 s6vdqoK8OKI3 for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 13:56:57 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1942C1AD384 for <xmpp@ietf.org>; Fri, 10 Oct 2014 13:56:57 -0700 (PDT)
Received: by mail-ig0-f177.google.com with SMTP id a13so4301821igq.4 for <xmpp@ietf.org>; Fri, 10 Oct 2014 13:56:56 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BXtSLXWies0JV00VwtvQWP1S7AELxvqNBkO9X8mGjpE=; b=Pte+N4lIqtVm7pPGYDdyaw5rcqP63wNX5eLwA6mLfeyenmfEiWl3pd5/yT448vE3Ja Nw0Rwp1yvlMMdrKoKRcnWWALD+FPgSN0yihAQ48CvONMkiZi78kHBKEDiWytb12nrKty gYwDrRBYgti8wy2NfWDTsAAvZLHQL7MhdSTMKwjtzUj2LekUuaItVLY2D5P/o1jqSY9x bR4GrPwmZSSI8fQgz+KscDLvKgwr8fXNU7Esatx9iAzHyVxR8+uAEuhE/EHsSwEcikTe G3BOFiUDaN/Dtkrqd9QpaAdtgAsinau0xiejkxxLDq9BcklJImeTmBTrmtwlxXB3aBGf euJw==
X-Gm-Message-State: ALoCoQk194gjAw3gi3zQu1E9XL9oJGaC0ctEcoUeL3uS2d+N3NyB6RdAnxGwhR8mlc/7GXqvwPsN
X-Received: by 10.42.106.204 with SMTP id a12mr6393346icp.88.1412974616504; Fri, 10 Oct 2014 13:56:56 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id nj4sm2666963igb.12.2014.10.10.13.56.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 13:56:55 -0700 (PDT)
Message-ID: <54384815.9040505@andyet.net>
Date: Fri, 10 Oct 2014 14:56:53 -0600
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: xmpp@ietf.org
References: <20141010204758.29803.21356.idtracker@ietfa.amsl.com>
In-Reply-To: <20141010204758.29803.21356.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/eEurB6Gfy0v1KCLhY6ByKfmxYhY
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-14.txt
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, 10 Oct 2014 20:56:59 -0000

As promised. :-)

On 10/10/14, 2:47 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.
>
>          Title           : Extensible Messaging and Presence Protocol (XMPP): Address Format
>          Author          : Peter Saint-Andre
> 	Filename        : draft-ietf-xmpp-6122bis-14.txt
> 	Pages           : 29
> 	Date            : 2014-10-10
>
> Abstract:
>     This document defines the address format for the Extensible Messaging
>     and Presence Protocol (XMPP), including support for code points
>     outside the ASCII range.  This document obsoletes RFC 6122.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-14
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-14
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp
>


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


From nobody Fri Oct 10 15:09:43 2014
Return-Path: <internet-drafts@ietf.org>
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 355291AD45B; Fri, 10 Oct 2014 15:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qXfFQGOSA0o2; Fri, 10 Oct 2014 15:09:38 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7541AD423; Fri, 10 Oct 2014 15:09:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141010220938.3460.83660.idtracker@ietfa.amsl.com>
Date: Fri, 10 Oct 2014 15:09:38 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/6CtQ4-4qIP3f0rjVSF53bMgM2vo
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-posh-02.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Oct 2014 22:09:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : PKIX over Secure HTTP (POSH)
        Authors         : Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-xmpp-posh-02.txt
	Pages           : 14
	Date            : 2014-10-10

Abstract:
   Experience has shown that it is extremely difficult to deploy proper
   PKIX certificates for TLS in multi-tenanted environments, since
   certification authorities will not issue certificates for hosted
   domains to hosting services, hosted domains do not want hosting
   services to hold their private keys, and hosting services wish to
   avoid liability for holding those keys.  As a result, domains hosted
   in multi-tenanted environments often deploy non-HTTP applications
   such as email and instant messaging using certificates that identify
   the hosting service, not the hosted domain.  Such deployments force
   end users and peer services to accept a certificate with an improper
   identifier, resulting in obvious security implications.  This
   document defines two methods that make it easier to deploy
   certificates for proper server identity checking in non-HTTP
   application protocols.  The first method enables the TLS client
   associated with a user agent or peer application server to obtain the
   end-entity certificate of a hosted domain over secure HTTP as an
   alternative to standard PKIX techniques.  The second method enables a
   hosted domain to securely delegate a non-HTTP application to a
   hosting service using redirects provided by HTTPS itself or by a
   pointer in a file served over HTTPS at the hosted domain.  While this
   approach was developed for use in the Extensible Messaging and
   Presence Protocol (XMPP) as a Domain Name Association prooftype, it
   can be applied to any non-HTTP application protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-posh-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Oct 10 15:19:06 2014
Return-Path: <mamille2@cisco.com>
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 6D21F1AD456 for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 15:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.966
X-Spam-Level: 
X-Spam-Status: No, score=-13.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 UzbFjXIPhf9M for <xmpp@ietfa.amsl.com>; Fri, 10 Oct 2014 15:19:02 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D435F1A88D0 for <xmpp@ietf.org>; Fri, 10 Oct 2014 15:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3758; q=dns/txt; s=iport; t=1412979541; x=1414189141; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=8B67PESkSupzNdMowD7/RFig2uncf/V2o9p5BlppPVE=; b=nKnfHMMhpVe0isCkgRTPxD1K6DeaBEHtcT51cTEm6ukxiSLGv6kXIERl /V72jlSMM+phtv7VMb5UuO4kj2FSj9uLY0OzyZJTjbgxaO/5dBsEHilR+ eAza4pgq71cnvhYdPO0FAxaScUQ3jA7ZlweGGCg6RhYNqwDDgZAbIdmYW I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwNAP5ZOFStJA2M/2dsb2JhbABWAQmDDlNTBQSDAsgXCodNAiVgFgF7g3sJAQEEAQEBIEsLEAsYAgIFIQICDwIWMBMBAwICAQEFhW2CSAgFqneUbgEBAQEBAQQBAQEBAQEcgSyONgYBCgEdMweCdw+BRQWEYoZ8il2EPoJSgS48gwqCco4rggAegXgiK4EPOYECAQEF
X-IronPort-AV: E=Sophos;i="5.04,695,1406592000"; d="scan'208";a="85955613"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 10 Oct 2014 22:19:00 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9AMJ0ib023459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <xmpp@ietf.org>; Fri, 10 Oct 2014 22:19:01 GMT
Received: from [10.129.24.59] (10.129.24.59) by xhc-aln-x06.cisco.com (173.36.12.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 10 Oct 2014 17:19:00 -0500
Message-ID: <54385B54.60207@cisco.com>
Date: Fri, 10 Oct 2014 16:19:00 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <mamille2@cisco.com>
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
CC: <xmpp@ietf.org>
References: <20141010220938.3460.83660.idtracker@ietfa.amsl.com>
In-Reply-To: <20141010220938.3460.83660.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.129.24.59]
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/69u51wJ9J4KMMqb0Rfqy6L8ujLE
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-02.txt
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, 10 Oct 2014 22:19:04 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This revision adds more constraints around the value of the "ttl"
fields, which was brought to the editors' attention off-list.

The previous revision only vaguely said the "ttl" was a number.  It
now states the "ttl" is a JSON number that MUST be non-negative integer.


- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On 10/10/14, 4:09 PM, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Extensible Messaging
> and Presence Protocol Working Group of the IETF.
> 
> Title           : PKIX over Secure HTTP (POSH) Authors         :
> Matthew Miller Peter Saint-Andre Filename        :
> draft-ietf-xmpp-posh-02.txt Pages           : 14 Date            :
> 2014-10-10
> 
> Abstract: Experience has shown that it is extremely difficult to
> deploy proper PKIX certificates for TLS in multi-tenanted
> environments, since certification authorities will not issue
> certificates for hosted domains to hosting services, hosted domains
> do not want hosting services to hold their private keys, and
> hosting services wish to avoid liability for holding those keys.
> As a result, domains hosted in multi-tenanted environments often
> deploy non-HTTP applications such as email and instant messaging
> using certificates that identify the hosting service, not the
> hosted domain.  Such deployments force end users and peer services
> to accept a certificate with an improper identifier, resulting in
> obvious security implications.  This document defines two methods
> that make it easier to deploy certificates for proper server
> identity checking in non-HTTP application protocols.  The first
> method enables the TLS client associated with a user agent or peer
> application server to obtain the end-entity certificate of a hosted
> domain over secure HTTP as an alternative to standard PKIX
> techniques.  The second method enables a hosted domain to securely
> delegate a non-HTTP application to a hosting service using
> redirects provided by HTTPS itself or by a pointer in a file served
> over HTTPS at the hosted domain.  While this approach was developed
> for use in the Extensible Messaging and Presence Protocol (XMPP) as
> a Domain Name Association prooftype, it can be applied to any
> non-HTTP application protocol.
> 
> 
> The IETF datatracker status page for this draft is: 
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/
> 
> There's also a htmlized version available at: 
> http://tools.ietf.org/html/draft-ietf-xmpp-posh-02
> 
> A diff from the previous version is available at: 
> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-02
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________ xmpp mailing list 
> xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUOFtUAAoJEDWi+S0W7cO1lzcH/0btZ9aCGIWFSy0kgMBAqk76
CYNuN3reOypnDUCULfSilcs1KypKbNfGjVI6UFdKYBmJg9+Z9p34YbobKZk7tooD
KNAW+YLtTYGz9cnGse88z9I/kgErqqu0D2vvb64fqvp963lVNGlaOFruB3mrbAOO
iZKYQwgnusNi63FN8Z7HVfiRgFxM9k6Pet4BrFRR+WcLuglVlJUshtVcOHTAfrKU
UjcFQ+oaresFEHthuLZMH4DxbHuuO3sofKm9juxMC7N35RkXXkgrzTGcxNsrGLsA
iOfAby43uqPj6tk3bMG8VDcRbTm3GMu+UcARaPjAjAf9USfsDrP+YVGdTogp+cM=
=//3z
-----END PGP SIGNATURE-----


From nobody Sat Oct 11 21:00:03 2014
Return-Path: <internet-drafts@ietf.org>
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 8C3751A884B; Sat, 11 Oct 2014 21:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RAmFiMnI9_xj; Sat, 11 Oct 2014 20:59:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 088151A884A; Sat, 11 Oct 2014 20:59:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141012035959.28936.8055.idtracker@ietfa.amsl.com>
Date: Sat, 11 Oct 2014 20:59:59 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VQMDd30L_1-s3uBlmLe2WXx6-QE
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-07.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 12 Oct 2014 04:00:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
        Authors         : Peter Saint-Andre
                          Matthew Miller
	Filename        : draft-ietf-xmpp-dna-07.txt
	Pages           : 17
	Date            : 2014-10-11

Abstract:
   This document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in two ways.  First, it specifies how to
   establish a strong association between a domain name and an XML
   stream, using the concept of "prooftypes".  Second, it describes how
   to securely delegate a service domain name (e.g., example.com) to a
   target server host name (e.g., hosting.example.net), which is
   especially important in multi-tenanted environments where the same
   target server hosts a large number of service associated with
   different domains.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-dna-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Oct 11 21:00:57 2014
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 9770F1A8850 for <xmpp@ietfa.amsl.com>; Sat, 11 Oct 2014 21:00:56 -0700 (PDT)
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 SDc_9q51fTKb for <xmpp@ietfa.amsl.com>; Sat, 11 Oct 2014 21:00:55 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE6C1A884A for <xmpp@ietf.org>; Sat, 11 Oct 2014 21:00:54 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id h3so7121930igd.5 for <xmpp@ietf.org>; Sat, 11 Oct 2014 21:00:54 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GuvC0dwdwrQGfs6YwUzehY4niN/0sQCo7G1kNT48eRY=; b=fKhhU1LeBvSaBRvx7O4CJi2Hgx/VezOBzyKV0zO6FNbC8pBldCkRLaV0ZqXwdrFozg ROr5+Nvtcnnhvs8BqTjuvwrlz8/QRhCLIciVVwmsD8q/NYdcVNjgtUD2jAnXi8nGa8MU +e/oco2MERkbDYOt+jvr0n9l0xGGL0415hdtHE+gP+ODKuzxu0gSsZcqfK9DzV9M6rCD nrPbm2q5nJi9MN+EJsJGhZJGbTHi39Iy4h8sP2ffaDd6InZx8brNYM3ezyBOXWQq5hyV 8dhbw/rBEhNXTL2BztSEHARG+sfHdb9H78V84dz47YFTnUSkRGlhcFhgGbvEmkS21tse dLww==
X-Gm-Message-State: ALoCoQkaZTD8zNVJVgjfIh+oM3K62PzUoJbumIUEz0hXoGno1ZidIjqN4k5nh1xPGn2ov091Gtzp
X-Received: by 10.50.147.9 with SMTP id tg9mr19941375igb.31.1413086454371; Sat, 11 Oct 2014 21:00:54 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p5sm5591249iga.5.2014.10.11.21.00.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Oct 2014 21:00:53 -0700 (PDT)
Message-ID: <5439FCF5.20108@andyet.net>
Date: Sat, 11 Oct 2014 22:00:53 -0600
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: xmpp@ietf.org
References: <20141012035959.28936.8055.idtracker@ietfa.amsl.com>
In-Reply-To: <20141012035959.28936.8055.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/XAEfr3YDClHwZOb0KsgMhhLTKOk
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-07.txt
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: Sun, 12 Oct 2014 04:00:56 -0000

Just a copy edit to update and improve the text here and there...

On 10/11/14, 9:59 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.
>
>          Title           : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
>          Authors         : Peter Saint-Andre
>                            Matthew Miller
> 	Filename        : draft-ietf-xmpp-dna-07.txt
> 	Pages           : 17
> 	Date            : 2014-10-11
>
> Abstract:
>     This document improves the security of the Extensible Messaging and
>     Presence Protocol (XMPP) in two ways.  First, it specifies how to
>     establish a strong association between a domain name and an XML
>     stream, using the concept of "prooftypes".  Second, it describes how
>     to securely delegate a service domain name (e.g., example.com) to a
>     target server host name (e.g., hosting.example.net), which is
>     especially important in multi-tenanted environments where the same
>     target server hosts a large number of service associated with
>     different domains.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-xmpp-dna-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp
>


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


From nobody Mon Oct 13 07:25:17 2014
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 7C5411A0009 for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 07:25:13 -0700 (PDT)
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 X8qusFwav8R3 for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 07:25:11 -0700 (PDT)
Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC02F1A0006 for <xmpp@ietf.org>; Mon, 13 Oct 2014 07:25:11 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id hn15so13857874igb.3 for <xmpp@ietf.org>; Mon, 13 Oct 2014 07:25:11 -0700 (PDT)
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 :subject:content-type:content-transfer-encoding; bh=bGyAmgVvoH+/0OXzVOVQU7Kw1LlSpu18+Gxpq5jTuCA=; b=Bv7dLTsrJpnF+RbURzdSLll/HbK/x19RSltkS6ApVt+VC5Nuv4dgiXWaDR7z3bmsZv CJ4SaRbqj0hFrHTnAYmUG0v0YI/Q+59+l85sTxLhO6LFqZX0cN9R0HY1EiFJHpPhWJg7 0FKqh1loDTrKBL0sk1RwDw1y96naml+2zVpojPrgboc6kCRdqhHdLHHk+22HNCMOweRE TiGz79ua1zK8sGChojyNMBfWwIgmau1FxmqJHP0GGa10PHRluHjgdTrh7HLjunJYNDZH STUIjJ0fu0gE+nhYH3jM4LHmF6Z2th3FpBd8hvmOZrUUleSYHflK1HnwHFaVljvPJmtI 3vbQ==
X-Gm-Message-State: ALoCoQmnV50ictLVKYMVuM6rbSir8IDgYcZJfbmWJeee5ZXkXG8prgWqDNw3b2K9t62/AjC2tqIx
X-Received: by 10.51.17.2 with SMTP id ga2mr1950516igd.2.1413210310984; Mon, 13 Oct 2014 07:25:10 -0700 (PDT)
Received: from aither.local ([96.46.73.2]) by mx.google.com with ESMTPSA id rj5sm8983118igc.8.2014.10.13.07.25.09 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 07:25:10 -0700 (PDT)
Message-ID: <543BE0B7.3010609@andyet.net>
Date: Mon, 13 Oct 2014 07:24:55 -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: XMPP Working Group <xmpp@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/1hr4LWkYpVZ83LWolc8aC7_y3Yc
Subject: [xmpp] dialback in DNA
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: Mon, 13 Oct 2014 14:25:13 -0000

Currently draft-ietf-xmpp-dna does not consider server dialback to be a 
DNA prooftype. Matt and I propose adding the following text to §7:

    Although the PKIX prooftype uses the XMPP Server Dialback protocol
    [XEP-0220] for signalling between servers, this framework document
    does not define the exchange of dialback keys (also specified in
    [XEP-0220]) as a DNA prooftype.  However, a future specification, or
    an updated version of [XEP-0220], might define a DNA prooftype for
    dialback in a way that is consistent with this framework.

Peter

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


From nobody Mon Oct 13 13:05:38 2014
Return-Path: <ben@nostrum.com>
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 15CDB1A001A for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 13:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level: 
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 xcB8Uei_1bYF for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 13:05:32 -0700 (PDT)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702D61A000F for <xmpp@ietf.org>; Mon, 13 Oct 2014 13:05:08 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9DK513x028012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Oct 2014 15:05:02 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <ben@nostrum.com>
Date: Mon, 13 Oct 2014 15:05:00 -0500
X-Mao-Original-Outgoing-Id: 434923500.720694-c1c47ae8020d7d32a970e8e4142092d1
Content-Transfer-Encoding: quoted-printable
Message-Id: <68E1EF4E-18F3-44E6-844D-115E22648183@nostrum.com>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/pGr3DafQf_m5lVb3tF07hO_Eob8
Cc: draft-ietf-xmpp-posh-02.all@tools.ietf.org
Subject: [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: Mon, 13 Oct 2014 20:05:34 -0000

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.

Thanks!

Ben.


From nobody Mon Oct 13 15:40:48 2014
Return-Path: <fippo@goodadvice.pages.de>
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 EBBE81A1A3E for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 15:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OJgMWkcAWeWC for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 15:40:44 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DECD1A1A00 for <xmpp@ietf.org>; Mon, 13 Oct 2014 15:40:41 -0700 (PDT)
Received: from [192.168.178.45] (p5DCFDD14.dip0.t-ipconnect.de [93.207.221.20]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9DMeqdt003352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Tue, 14 Oct 2014 00:40:54 +0200
Message-ID: <543C54E2.3030602@goodadvice.pages.de>
Date: Tue, 14 Oct 2014 00:40:34 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <20141012035959.28936.8055.idtracker@ietfa.amsl.com>
In-Reply-To: <20141012035959.28936.8055.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/cdRFqipwDwrk20FmyOpIv3EKbdw
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-07.txt
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: Mon, 13 Oct 2014 22:40:47 -0000

5.2. (POSH) doesn't currently describe the "matching rules for comparing 
the client's verification material against the server's proof".

Can you add some text (similar to the one in 5.1) for the sake of 
conforming to the formal prooftype model defined later?


From nobody Mon Oct 13 15:53:28 2014
Return-Path: <fippo@goodadvice.pages.de>
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 76A1A1A1A34 for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 15:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] 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 E60HY_Hx8e64 for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 15:53:22 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805291A0386 for <xmpp@ietf.org>; Mon, 13 Oct 2014 15:53:22 -0700 (PDT)
Received: from [192.168.178.45] (p5DCFDD14.dip0.t-ipconnect.de [93.207.221.20]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9DMrXUC003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Tue, 14 Oct 2014 00:53:35 +0200
Message-ID: <543C57DB.7040005@goodadvice.pages.de>
Date: Tue, 14 Oct 2014 00:53:15 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <543BE0B7.3010609@andyet.net>
In-Reply-To: <543BE0B7.3010609@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VKF5F3EdRRK9CX0kZUMQ-eI41vo
Subject: Re: [xmpp] dialback in DNA
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: Mon, 13 Oct 2014 22:53:25 -0000

Am 13.10.2014 16:24, schrieb Peter Saint-Andre - &yet:
[...]
> Matt and I propose adding the following text to §7:
>
>     Although the PKIX prooftype uses the XMPP Server Dialback protocol

reuses?

>     [XEP-0220] for signalling between servers, this framework document

[XEP-0220] _syntax_ for ...?

>     does not define the exchange of dialback keys (also specified in
>     [XEP-0220]) as a DNA prooftype.  However, a future specification, or

but doesn't use the semantics for the generation and validation of 
dialback keys?

I'd note that it will still work with server dialback because one of the 
design goals was backward compat. So we don't need to define anything.

>     an updated version of [XEP-0220], might define a DNA prooftype for
>     dialback

I just tried that and failed. Let's try to find some time and a 
whiteboard later this year.

> in a way that is consistent with this framework.

0220 currently says that dialback-without-dialing-back is not described. 
smart servers should not use the db:verify to do any weak identify 
verification of the dialback keys.
But if we make any such statements, they belong into the security 
considerations of xep-0220.





From nobody Mon Oct 13 16:17:31 2014
Return-Path: <ben@nostrum.com>
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 59CBC1A1A45 for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 16:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level: 
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 tULrsmYgWK-j for <xmpp@ietfa.amsl.com>; Mon, 13 Oct 2014 16:17:27 -0700 (PDT)
Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB57B1A1A34 for <xmpp@ietf.org>; Mon, 13 Oct 2014 16:17:27 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9DNHOJx045852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Oct 2014 18:17:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <ben@nostrum.com>
Date: Mon, 13 Oct 2014 18:17:23 -0500
X-Mao-Original-Outgoing-Id: 434935043.793552-29d813f4875db79debab838baac81b9e
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/JFOKJENxe51_lgbF_A_fYWCtDEY
Cc: draft-ietf-xmpp-posh.all@tools.ietf.org
Subject: [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: Mon, 13 Oct 2014 23:17:29 -0000

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

Thanks!

Ben.


From nobody Tue Oct 14 01:42:54 2014
Return-Path: <dave@cridland.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 1F5891A00F0 for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 01:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 6RzvaiYuTZH1 for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 01:42:49 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B231A0035 for <xmpp@ietf.org>; Tue, 14 Oct 2014 01:42:49 -0700 (PDT)
Received: by mail-oi0-f51.google.com with SMTP id h136so15737739oig.38 for <xmpp@ietf.org>; Tue, 14 Oct 2014 01:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UNZjN6O85Ux0GID7EPyYjtEUQ7D5WQzEWJwOeBNWeLM=; b=XnWVnPXDb8+gDR7dKv192E663zG4BUcrl2qifenq5bcgLrYsSCGr3q3LrLIYmgXXkW 1m7u0s0ziS+zPJkgB+cIcNA/46LvbLx/VOtDdzNAln5F5CH6UsGkbZGxirr6fDNVB662 L4Fqg+jXaape3aRsZJ1DqMUAotObZ2UBCMrI0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UNZjN6O85Ux0GID7EPyYjtEUQ7D5WQzEWJwOeBNWeLM=; b=MAHFMG22NcfLhJKABFVCPA+8CLHqYPTSJz8DWTo3ylSXXnHucfTKDlPOCo3vJ2Y8WE pcJJc5mndfYk71Oq0+2b973K5KqVDEHmD/T5FCel0fXIWtUcpcwHdumCw9sCbbObjuSV 8LyJ7W04Q9M12bw/b4fmMxHVz6uS2Ki/q/4v2xcJouttbxkd0JfMIumLd/yBG7FxxpDS TRH7vJ+ceF/CuGfUC4wm5vsF4GCPShbuqiGOCcGL3cvAkuai8DoUN0d7YyGUUeQGlreg VvR9GWnNjOU85fpjrFqyGFRD1WCO1dYvFV4m/lSR4cDI6LtKtMwi++Ic2L2/DFuj08qy Dj6w==
X-Gm-Message-State: ALoCoQlO+aWODakbhvXhPPTTe/FGdb9lIA4cK9s5GehzSS6QWCz3PS5mKm1y/5c/YEvBff0B8ZAG
MIME-Version: 1.0
X-Received: by 10.202.193.138 with SMTP id r132mr2733818oif.52.1413276168839;  Tue, 14 Oct 2014 01:42:48 -0700 (PDT)
Received: by 10.60.150.238 with HTTP; Tue, 14 Oct 2014 01:42:48 -0700 (PDT)
In-Reply-To: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
References: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
Date: Tue, 14 Oct 2014 09:42:48 +0100
Message-ID: <CAKHUCzyy1TugO2mU0Br+hTPGPztfqv+zyVrP4-5m5FJToe1H4g@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary=001a113dc368037a8c05055e00ac
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/IXMUlTcsQAuXbruFWDuapYgTGOM
Cc: draft-ietf-xmpp-posh.all@tools.ietf.org, XMPP Working Group <xmpp@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: Tue, 14 Oct 2014 08:42:52 -0000

--001a113dc368037a8c05055e00ac
Content-Type: text/plain; charset=UTF-8

On 14 October 2014 00:17, Ben Campbell <ben@nostrum.com> wrote:

> This is a Working Group Last Call of draft-ietf-xmpp-posh-02. The draft is
> available at the following URL:
>

0) Abstract:

The last sentence is problematic, because it's not clear that the XMPP WG
can make such a pronouncement.

Also, it fails to explain why hosted HTTPS isn't a problem, but I suspect
I'll never understand that one. :-)

I note that this Abstract is huge, and contains almost the same information
as the Introduction.

1) Introduction:

I was under the impression that when this issue was first raised, the
problem was one of management of certificates rather than anything else -
that is, if you host 1,000 domains, you needed to have a certificate for
each of them in practise, and this meant handling 1,000 certificates, each
with different expiry dates etc.

Suggestion: After the existing three bullet points:

o Even if your legal department is happy, this still means managing one
certificate for each customer across the infrastructure, contributing to a
large administrative load.

Though the same organization that raised this point seems perfectly happy
to do so for HTTP; as noted before, this is because of Strange Things
Beyond My Understanding.

Finally, this section does not constitute a thought experiment, but an
illustrative story.

3) Obtaining Verification Materials

It would make things clearer if the term of art "source domain" were
briefly introduced, at least hinting at its meaning. While it's mentioned
in Terminology, because there is no typographic convention to alert the
reader that it is a term of art, it's difficult to spot it immediately. As
an alternative to calling it out, perhaps capitalizing it (although it's
not capitalized in RFC 6125)?

I note that "end-entity certificate" is not called out explicitly, but this
is probably OK - though using it in the initial point 1's parenthesis may
help. "(in PKIX, this takes the form of a PKIX end-entity certificate
[RFC5280])."

In the second numbered list, there seems to be a dearth of metasyntactic
variables. The Foo client connecting to the foo domain to verify the Foo
service by looking for the foo token is almost awesomely unclear. Since at
this stage we have already established that the Source Domain contains
"foo", perhaps we could make this the "Bar" service, with posh.bar.json -
this also has the advantage that the Bar Service is very familiar to a
large proportion of the XMPP community.

Within this point 1, "foo.example.com" is referred to as the "domain" - it
is, I think, the Source Domain, and would be clearer noted as such.

Finally, I think it's worthwhile stressing that although the ultimate goal
is to verify the certificate foo presents for the Bar service of the Source
Domain, the certificate presented by HTTPS is still validated in isolation
by traditional methods - that is, the HTTPS cert has to be valid for the
Source Domain.

3.1) Source Domain Possesses PKIX Certificate Information

I'll freely admit I'm not terribly keen on this being in JSON. It means
including a JSON library within XMPP; we've not needed one before.

3.3) Performing Verification

a) This reads "You take a bunch of hashes and see if any match". Given the
example contains more than one hash function, which should be used? Both?
Whatever the client supports?

b) I've a nagging feeling that we should include Issuer and Serial matches
as well, in order to mitigate against hashes becoming weaker. I suspect
that hashing only the keying material (or using the SKI) might be even
better. Has this been run past someone who actually knows some crypto (ie,
someone other than me)?

4) Secure Delegation

This text reads that we should match the "POSH certificate". This is
presumably a term of art, but used only in this section. Similarly "TLS
server" is used only once, here. There are two TLS servers at play here,
and it's unclear what a POSH certificate might be; given that the only
certificates discussed are not the JSON objects.

7) Alternates and Roll-over

It appears that it is impossible to state something like a switch of
hosting using this mechanism; also I'd note that this same mechanism might
also be used if a hosting provider has multiple certificates.

8) Security Considerations

Not really sure that the second paragraph belongs here. (Nor, actually, am
I sure it belongs anywhere in the document).

Summary:

Some more work required.

I still would rather the earth swallowed this whole, really, and we did
these things properly. I would be happier to go along with this if there
were any sign that large hosting providers in the XMPP world were at all
likely to deploy any kind of security at all, but this seems unlikely
because of the combination of this not being trivial, and there being
implementations which follow the strict rules of RFC 6120 and drop the
session if TLS is encountered with a non-matching certificate - yet
cheerfully connect if there's no TLS at all.

Still, rant over - if we're to do this, there's a few rough edges in the
specification, and I'd appreciate knowing if the certificate identity
mechanism has been properly reviewed.

Dave.

--001a113dc368037a8c05055e00ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
4 October 2014 00:17, Ben Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:=
ben@nostrum.com" target=3D"_blank">ben@nostrum.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">This is a Working Group Last Call of draft-=
ietf-xmpp-posh-02. The draft is available at the following URL:<br></blockq=
uote><div><br></div><div>0) Abstract:</div><div><br></div><div>The last sen=
tence is problematic, because it&#39;s not clear that the XMPP WG can make =
such a pronouncement.</div><div><br></div><div>Also, it fails to explain wh=
y hosted HTTPS isn&#39;t a problem, but I suspect I&#39;ll never understand=
 that one. :-)</div><div><br></div><div>I note that this Abstract is huge, =
and contains almost the same information as the Introduction.</div><div><br=
></div><div>1) Introduction:</div><div><br></div><div>I was under the impre=
ssion that when this issue was first raised, the problem was one of managem=
ent of certificates rather than anything else - that is, if you host 1,000 =
domains, you needed to have a certificate for each of them in practise, and=
 this meant handling 1,000 certificates, each with different expiry dates e=
tc.</div><div><br></div><div>Suggestion: After the existing three bullet po=
ints:</div><div><br></div><div>o Even if your legal department is happy, th=
is still means managing one certificate for each customer across the infras=
tructure, contributing to a large administrative load.</div><div><br></div>=
<div>Though the same organization that raised this point seems perfectly ha=
ppy to do so for HTTP; as noted before, this is because of Strange Things B=
eyond My Understanding.</div><div><br></div><div>Finally, this section does=
 not constitute a thought experiment, but an illustrative story.</div><div>=
<br></div><div>3) Obtaining Verification Materials</div><div><br></div><div=
>It would make things clearer if the term of art &quot;source domain&quot; =
were briefly introduced, at least hinting at its meaning. While it&#39;s me=
ntioned in Terminology, because there is no typographic convention to alert=
 the reader that it is a term of art, it&#39;s difficult to spot it immedia=
tely. As an alternative to calling it out, perhaps capitalizing it (althoug=
h it&#39;s not capitalized in RFC 6125)?</div><div><br></div><div>I note th=
at &quot;end-entity certificate&quot; is not called out explicitly, but thi=
s is probably OK - though using it in the initial point 1&#39;s parenthesis=
 may help. &quot;(in PKIX, this takes the form of a PKIX end-entity certifi=
cate [RFC5280]).&quot;</div><div><br></div><div>In the second numbered list=
, there seems to be a dearth of metasyntactic variables. The Foo client con=
necting to the foo domain to verify the Foo service by looking for the foo =
token is almost awesomely unclear. Since at this stage we have already esta=
blished that the Source Domain contains &quot;foo&quot;, perhaps we could m=
ake this the &quot;Bar&quot; service, with posh.bar.json - this also has th=
e advantage that the Bar Service is very familiar to a large proportion of =
the XMPP community.</div><div><br></div><div>Within this point 1, &quot;<a =
href=3D"http://foo.example.com">foo.example.com</a>&quot; is referred to as=
 the &quot;domain&quot; - it is, I think, the Source Domain, and would be c=
learer noted as such.</div><div><br></div><div>Finally, I think it&#39;s wo=
rthwhile stressing that although the ultimate goal is to verify the certifi=
cate foo presents for the Bar service of the Source Domain, the certificate=
 presented by HTTPS is still validated in isolation by traditional methods =
- that is, the HTTPS cert has to be valid for the Source Domain.</div><div>=
<br></div><div>3.1) Source Domain Possesses PKIX Certificate Information</d=
iv><div><br></div><div>I&#39;ll freely admit I&#39;m not terribly keen on t=
his being in JSON. It means including a JSON library within XMPP; we&#39;ve=
 not needed one before.</div><div><br></div><div>3.3) Performing Verificati=
on</div><div><br></div><div>a) This reads &quot;You take a bunch of hashes =
and see if any match&quot;. Given the example contains more than one hash f=
unction, which should be used? Both? Whatever the client supports?</div><di=
v><br></div><div>b) I&#39;ve a nagging feeling that we should include Issue=
r and Serial matches as well, in order to mitigate against hashes becoming =
weaker. I suspect that hashing only the keying material (or using the SKI) =
might be even better. Has this been run past someone who actually knows som=
e crypto (ie, someone other than me)?</div><div><br></div><div>4) Secure De=
legation</div><div><br></div><div>This text reads that we should match the =
&quot;POSH certificate&quot;. This is presumably a term of art, but used on=
ly in this section. Similarly &quot;TLS server&quot; is used only once, her=
e. There are two TLS servers at play here, and it&#39;s unclear what a POSH=
 certificate might be; given that the only certificates discussed are not t=
he JSON objects.</div><div><br></div><div>7) Alternates and Roll-over</div>=
<div><br></div><div>It appears that it is impossible to state something lik=
e a switch of hosting using this mechanism; also I&#39;d note that this sam=
e mechanism might also be used if a hosting provider has multiple certifica=
tes.</div><div><br></div><div>8) Security Considerations</div><div><br></di=
v><div>Not really sure that the second paragraph belongs here. (Nor, actual=
ly, am I sure it belongs anywhere in the document).</div><div><br></div><di=
v>Summary:</div><div><br></div><div>Some more work required.</div><div><br>=
</div><div>I still would rather the earth swallowed this whole, really, and=
 we did these things properly. I would be happier to go along with this if =
there were any sign that large hosting providers in the XMPP world were at =
all likely to deploy any kind of security at all, but this seems unlikely b=
ecause of the combination of this not being trivial, and there being implem=
entations which follow the strict rules of RFC 6120 and drop the session if=
 TLS is encountered with a non-matching certificate - yet cheerfully connec=
t if there&#39;s no TLS at all.</div><div><br></div><div>Still, rant over -=
 if we&#39;re to do this, there&#39;s a few rough edges in the specificatio=
n, and I&#39;d appreciate knowing if the certificate identity mechanism has=
 been properly reviewed.</div><div><br></div><div>Dave.</div></div></div></=
div>

--001a113dc368037a8c05055e00ac--


From nobody Tue Oct 14 19:22:55 2014
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 190871A016D for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 19:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.458
X-Spam-Level: 
X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 XfNXma499WOT for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 19:22:50 -0700 (PDT)
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 6DC511A0121 for <xmpp@ietf.org>; Tue, 14 Oct 2014 19:22:50 -0700 (PDT)
Received: by mail-ig0-f175.google.com with SMTP id uq10so16588250igb.8 for <xmpp@ietf.org>; Tue, 14 Oct 2014 19:22:49 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t/TugWDa4Wx05rdb+AJIDwiSGL98PzjgkcrPEJVmKyk=; b=ZKyhLtaZjxuGm9nlV2pn3qHYbW8X67gs5SjEzaTy9QFG5bfhUU9AU+oi9SKu341KLs zudS3trOumMO14MTDpXCSaCb9guUAeDvuZD3KUciAJB6NJEO3VD7eLkBNh00xT8C+9OM ZnJUhC1Ifwwfp5TCFApTwX6ryvgxJd8Q6nsvH2Lo9BkP6yDtiuKxPN+/rXzvCwnjy6/n iZYx/KvVmjZMOAKbCud3u9BZ1Yp1NeXwcROfDOcuKIm3JAQnDTE3eHDvc542EID1c99Y 1Gv3mo4NOeFrniDk15E1y3njw6lfKH1+L7c4bTojawII9cJvcOsYc5IbL+oxaEMUlevf wThg==
X-Gm-Message-State: ALoCoQnYYnYl+PCydMNRbs7puvm4aU7xXDW4ii52ozCso4UrdqzdrQZdkUPR1Q5SLh2EK3rqpQa+
X-Received: by 10.43.63.17 with SMTP id xc17mr8389249icb.50.1413339769799; Tue, 14 Oct 2014 19:22:49 -0700 (PDT)
Received: from aither.local ([216.9.110.8]) by mx.google.com with ESMTPSA id 141sm1240447ioz.39.2014.10.14.19.22.48 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 19:22:49 -0700 (PDT)
Message-ID: <543D60B3.1020203@andyet.net>
Date: Tue, 14 Oct 2014 10:43:15 -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@ietf.org
References: <543BE0B7.3010609@andyet.net> <543C57DB.7040005@goodadvice.pages.de>
In-Reply-To: <543C57DB.7040005@goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/hEjWXZkckh3lQ0Mhj90s34Limu8
Subject: Re: [xmpp] dialback in DNA
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: Wed, 15 Oct 2014 02:22:52 -0000

On 10/13/14, 3:53 PM, Philipp Hancke wrote:
> Am 13.10.2014 16:24, schrieb Peter Saint-Andre - &yet:
> [...]
>> Matt and I propose adding the following text to §7:
>>
>>     Although the PKIX prooftype uses the XMPP Server Dialback protocol
>
> reuses?
>
>>     [XEP-0220] for signalling between servers, this framework document
>
> [XEP-0220] _syntax_ for ...?
>
>>     does not define the exchange of dialback keys (also specified in
>>     [XEP-0220]) as a DNA prooftype.  However, a future specification, or
>
> but doesn't use the semantics for the generation and validation of
> dialback keys?

Will fix.

> I'd note that it will still work with server dialback because one of the
> design goals was backward compat.

I propose that we add this clause:

"nothing in this document prevents the continued use of server dialback"

> So we don't need to define anything.

I'd need to double-check XEP-0220, one of our favorite documents. ;-)

>>     an updated version of [XEP-0220], might define a DNA prooftype for
>>     dialback
>
> I just tried that and failed.

How so?

> Let's try to find some time and a
> whiteboard later this year.

Always a pleasure. :-)

>> in a way that is consistent with this framework.
>
> 0220 currently says that dialback-without-dialing-back is not described.
> smart servers should not use the db:verify to do any weak identify
> verification of the dialback keys.
> But if we make any such statements, they belong into the security
> considerations of xep-0220.

Makes sense to me.

Peter

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


From nobody Tue Oct 14 19:23:59 2014
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 B98C41A017E for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 19:23:56 -0700 (PDT)
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 BfAO32SNOsML for <xmpp@ietfa.amsl.com>; Tue, 14 Oct 2014 19:23:54 -0700 (PDT)
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A591A0121 for <xmpp@ietf.org>; Tue, 14 Oct 2014 19:23:54 -0700 (PDT)
Received: by mail-ig0-f169.google.com with SMTP id uq10so19072164igb.4 for <xmpp@ietf.org>; Tue, 14 Oct 2014 19:23:54 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/21/Md/klg9r6tJ8TFDIM4Xj9lgaWARH/e+Y/x5UN2Y=; b=P9KtYRxPT7BCj+30HVRSVsJ3vz899aDkJeviDVmVh/gY4im8vnpErLRpn005GZEsg7 a9rjrPeKPDgP5A8ew6u9LCNQDur5XXe1k8ee8w1mzdhC/KriRhfIF8LDI5jEambk5J6b 6Hn5dc/jhbYVdoNtqW5jkTKp3FtVUiPOxwFoBxUSSS8n+3AVxVCgQRPvPWio+lq6QG3I Cpqf3LyhcxbMzsxWVA2W80qxZO6SMpSGMAI14VTPLYgGmOnTH2z3FUazy/cebFJ9YHuP iMQXfijEsVFkh+197GzqwQwn5buTtU/2ph/sraz2FCXYWdkaDgP864aJsnG3k2UGud3x pYLw==
X-Gm-Message-State: ALoCoQnLfzvMud9AtdKYa2zxKCQ8BltVEP1mCZeWYyN7YxUJBX4JtZiGRq8IoV4KbRQlyc0Q0nBk
X-Received: by 10.42.14.69 with SMTP id g5mr8328852ica.17.1413339833940; Tue, 14 Oct 2014 19:23:53 -0700 (PDT)
Received: from aither.local ([216.9.110.8]) by mx.google.com with ESMTPSA id f71sm1196011ioe.28.2014.10.14.19.23.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Oct 2014 19:23:53 -0700 (PDT)
Message-ID: <543DDAB6.1090208@andyet.net>
Date: Tue, 14 Oct 2014 19:23:50 -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@ietf.org
References: <20141012035959.28936.8055.idtracker@ietfa.amsl.com> <543C54E2.3030602@goodadvice.pages.de>
In-Reply-To: <543C54E2.3030602@goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Z5IaLNOSJIMkN_-Zy_LYuw8aeEw
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-07.txt
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: Wed, 15 Oct 2014 02:23:56 -0000

On 10/13/14, 3:40 PM, Philipp Hancke wrote:
> 5.2. (POSH) doesn't currently describe the "matching rules for comparing
> the client's verification material against the server's proof".

What about §3.3 of the POSH I-D?

> Can you add some text (similar to the one in 5.1) for the sake of
> conforming to the formal prooftype model defined later?

Sure. :-)

Peter

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


From nobody Thu Oct 16 12:08:40 2014
Return-Path: <fippo@goodadvice.pages.de>
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 847171A7D83 for <xmpp@ietfa.amsl.com>; Thu, 16 Oct 2014 12:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level: 
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] 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 6bfbFX4jW5l7 for <xmpp@ietfa.amsl.com>; Thu, 16 Oct 2014 12:08:28 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E0A1A87A0 for <xmpp@ietf.org>; Thu, 16 Oct 2014 12:08:28 -0700 (PDT)
Received: from [192.168.178.45] (p5DCFDF1F.dip0.t-ipconnect.de [93.207.223.31]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9GJ8aD6007244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Thu, 16 Oct 2014 21:08:37 +0200
Message-ID: <544017A0.3000302@goodadvice.pages.de>
Date: Thu, 16 Oct 2014 21:08:16 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <543BE0B7.3010609@andyet.net> <543C57DB.7040005@goodadvice.pages.de> <543D60B3.1020203@andyet.net>
In-Reply-To: <543D60B3.1020203@andyet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/xxZYbx0kXZdiHSl0HjF86DTCHFs
Subject: Re: [xmpp] dialback in DNA
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: Thu, 16 Oct 2014 19:08:30 -0000

> I'd need to double-check XEP-0220, one of our favorite documents. ;-)
>
>>>     an updated version of [XEP-0220], might define a DNA prooftype for
>>>     dialback
>>
>> I just tried that and failed.
>
> How so?

I could not figure out which proof of identity I wanted.

Did I want the proof that the receiving server is who it claims to be? 
With dialback, the proof seems to be "oh yeah, it is listening on the 
port DNS says"? That's pretty bad but we know it is vulnerable to DNS 
poisoning...

For the sending server, the proof is slightly better, db:verify and 
merlins spell assert the sender shares a secret with the authoritative 
server.

I just need to write up the formal prooftype definition for both.

It seems this is more complicated for dialback than for PKIX or 
POSH/DANE because it's not symmetric there. OTOH, we might have 
scenarios where we have PKIX in one direction and POSH in the other.


From nobody Thu Oct 16 19:30:49 2014
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 9E0C31A9028 for <xmpp@ietfa.amsl.com>; Thu, 16 Oct 2014 19:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, 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 ejWA9VtvAVyn for <xmpp@ietfa.amsl.com>; Thu, 16 Oct 2014 19:30:46 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116B41A1BA4 for <xmpp@ietf.org>; Thu, 16 Oct 2014 19:30:27 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id rl12so4773318iec.3 for <xmpp@ietf.org>; Thu, 16 Oct 2014 19:30:23 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Luc3jBklgYRM2fuq6WiWJULoCUepgGyDYzNhpgQGEEk=; b=jXNjZ0TFco/sqExtyn10sXARCYvHCBR04KRn1MGaRFlKBkeghtImbI2hdlqQNY9PgV L4j8Rp/bwvTqqBLgoAAgAhazBino2NkV8j1Ao8bB9is0ddsW8wC8/ZLHs9Rw6LIFzdWf 4AI/Cpn28vRGt7FhJFgiMGdtGHvk8RhJ1DLl75HREiNgpcg+NfCZOPgwN7U/xm3D8M0t OQoI1U3CsIRXdT3bETSXmVug1lX/A3lGOojaslEcHUpWi1UdiBql5tzb5RTIvXpmecAf rS24WJHgWJwKagAv6ZPk6M4PJ9CqwI0zld99XnbpBoTjXOzBb9yynFwY14nCCXtPK5iu rGtg==
X-Gm-Message-State: ALoCoQnsSi/VaQMh5VRmj3NiNh0pa0mXtK2p/CJyEBjcsWL9u+Y1QBDPGgUl1PdxliEi/1P1lRfC
X-Received: by 10.50.6.100 with SMTP id z4mr9162399igz.37.1413513023174; Thu, 16 Oct 2014 19:30:23 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id h8sm4042176ioh.35.2014.10.16.19.30.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 19:30:22 -0700 (PDT)
Message-ID: <54407F3D.7060401@andyet.net>
Date: Thu, 16 Oct 2014 20:30:21 -0600
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@ietf.org
References: <543BE0B7.3010609@andyet.net> <543C57DB.7040005@goodadvice.pages.de> <543D60B3.1020203@andyet.net> <544017A0.3000302@goodadvice.pages.de>
In-Reply-To: <544017A0.3000302@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/Fa9Cu9JjBT-LRlPN0yCZ-1Fc_3k
Subject: Re: [xmpp] dialback in DNA
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, 17 Oct 2014 02:30:47 -0000

On 10/16/14, 1:08 PM, Philipp Hancke wrote:
>> I'd need to double-check XEP-0220, one of our favorite documents. ;-)
>>
>>>>     an updated version of [XEP-0220], might define a DNA prooftype for
>>>>     dialback
>>>
>>> I just tried that and failed.
>>
>> How so?
>
> I could not figure out which proof of identity I wanted.
>
> Did I want the proof that the receiving server is who it claims to be?
> With dialback, the proof seems to be "oh yeah, it is listening on the
> port DNS says"? That's pretty bad but we know it is vulnerable to DNS
> poisoning...
>
> For the sending server, the proof is slightly better, db:verify and
> merlins spell assert the sender shares a secret with the authoritative
> server.

Thanks for the clarification.

> I just need to write up the formal prooftype definition for both.
>
> It seems this is more complicated for dialback than for PKIX or
> POSH/DANE because it's not symmetric there. OTOH, we might have
> scenarios where we have PKIX in one direction and POSH in the other.

True, that's possible. These things get messy. I think one way around 
the messiness is to say that DNA applies only to a single stream in a 
single direction. Bidi is interesting but what matters for DNA is that I 
check my server or peer.

Peter

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


From nobody Thu Oct 23 18:28:03 2014
Return-Path: <internet-drafts@ietf.org>
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 EFFF51AD6AF; Thu, 23 Oct 2014 18:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1IWqjnYkfox7; Thu, 23 Oct 2014 18:27:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 623961AD5AF; Thu, 23 Oct 2014 18:27:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141024012758.11258.17226.idtracker@ietfa.amsl.com>
Date: Thu, 23 Oct 2014 18:27:58 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/JLueUD-eZTaPEv5ibZC32I7cKSc
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-08.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Oct 2014 01:28:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
        Authors         : Peter Saint-Andre
                          Matthew Miller
	Filename        : draft-ietf-xmpp-dna-08.txt
	Pages           : 18
	Date            : 2014-10-23

Abstract:
   This document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in two ways.  First, it specifies how to
   establish a strong association between a domain name and an XML
   stream, using the concept of "prooftypes".  Second, it describes how
   to securely delegate a service domain name (e.g., example.com) to a
   target server host name (e.g., hosting.example.net), which is
   especially important in multi-tenanted environments where the same
   target server hosts a large number of service associated with
   different domains.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-dna-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Oct 23 18:48:51 2014
Return-Path: <internet-drafts@ietf.org>
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 553601AD6FC; Thu, 23 Oct 2014 18:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BemHIOCeVxN0; Thu, 23 Oct 2014 18:48:41 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7B1AD7C5; Thu, 23 Oct 2014 18:48:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.4.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141024014841.18125.13624.idtracker@ietfa.amsl.com>
Date: Thu, 23 Oct 2014 18:48:41 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/RnjaQ1rnlbO85ZvPcnkIYuGqgUE
Cc: xmpp@ietf.org
Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-15.txt
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Oct 2014 01:48:44 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Extensible Messaging and Presence Protocol (XMPP): Address Format
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-xmpp-6122bis-15.txt
	Pages           : 28
	Date            : 2014-10-23

Abstract:
   This document defines the address format for the Extensible Messaging
   and Presence Protocol (XMPP), including support for code points
   outside the ASCII range.  This document obsoletes RFC 6122.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Oct 25 01:16:32 2014
Return-Path: <fippo@goodadvice.pages.de>
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 6A8771A86E6 for <xmpp@ietfa.amsl.com>; Sat, 25 Oct 2014 01:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IKfMZb2TVMxI for <xmpp@ietfa.amsl.com>; Sat, 25 Oct 2014 01:16:23 -0700 (PDT)
Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9159C1A8547 for <xmpp@ietf.org>; Sat, 25 Oct 2014 01:16:23 -0700 (PDT)
Received: from [192.168.178.45] (p5DCFDE85.dip0.t-ipconnect.de [93.207.222.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9P8GLcx018481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 25 Oct 2014 10:16:23 +0200
Message-ID: <544B5C48.6070107@goodadvice.pages.de>
Date: Sat, 25 Oct 2014 10:16:08 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
In-Reply-To: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/psA_UZeba2avynkjctZ617OV9NY
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: Sat, 25 Oct 2014 08:16:26 -0000

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.

minor editorial stuff:
 > While this approach was developed for use in the Extensible
 > Messaging and Presence Protocol (XMPP) as a Domain Name
 > Association prooftype, it can be applied to any non-HTTP

"Domain Name Association (DNA) prooftype" (as done at the end of the 
introduction)?

section 1:
 > The product managers in your company are pushing you

bugging you? :-)

section 3.2:
 > The client performs an HTTPS GET for the URL

HTTPS GET _request_ for the URL?


From nobody Sat Oct 25 01:41:31 2014
Return-Path: <fippo@goodadvice.pages.de>
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 C28561A8704 for <xmpp@ietfa.amsl.com>; Sat, 25 Oct 2014 01:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 n2XnyFrl4Q3D for <xmpp@ietfa.amsl.com>; Sat, 25 Oct 2014 01:41:28 -0700 (PDT)
Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440711A86E5 for <xmpp@ietf.org>; Sat, 25 Oct 2014 01:41:28 -0700 (PDT)
Received: from [192.168.178.45] (p5DCFDE85.dip0.t-ipconnect.de [93.207.222.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s9P8fRu7018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 25 Oct 2014 10:41:29 +0200
Message-ID: <544B622A.9050807@goodadvice.pages.de>
Date: Sat, 25 Oct 2014 10:41:14 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: XMPP Working Group <xmpp@ietf.org>
References: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
In-Reply-To: <E2E3603E-F48C-4853-AF15-3F6EE0A64510@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/5Cnls21IKyJY3B0NI5v9uZe-A8A
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: Sat, 25 Oct 2014 08:41:29 -0000

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.

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.


From nobody Thu Oct 30 17:17:19 2014
Return-Path: <wwwrun@rfc-editor.org>
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 A7B2D1A8A4C; Thu, 30 Oct 2014 17:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level: 
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 7LskLK0Q-s06; Thu, 30 Oct 2014 17:17:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF4E1A8981; Thu, 30 Oct 2014 17:16:55 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id A02DC181C86; Thu, 30 Oct 2014 17:16:05 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 6000:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20141031001605.A02DC181C86@rfc-editor.org>
Date: Thu, 30 Oct 2014 17:16:05 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/1xjSIv1H1fllBxbzOr_H8klqYDY
Cc: drafts-update-ref@iana.org, xmpp@ietf.org, rfc-editor@rfc-editor.org
Subject: [xmpp] RFC 7395 on An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
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, 31 Oct 2014 00:17:03 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7395

        Title:      An Extensible Messaging and Presence 
                    Protocol (XMPP) Subprotocol for WebSocket 
        Author:     L. Stout, Ed.,
                    J. Moffitt,
                    E. Cestari
        Status:     Standards Track
        Stream:     IETF
        Date:       October 2014
        Mailbox:    lance@andyet.net, 
                    jack@metajack.im, 
                    eric@cstar.io
        Pages:      18
        Characters: 36795
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-xmpp-websocket-10.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7395.txt

This document defines a binding for the Extensible Messaging and
Presence Protocol (XMPP) over a WebSocket transport layer.  A
WebSocket binding for XMPP provides higher performance than the
current HTTP binding for XMPP.

This document is a product of the Extensible Messaging and Presence Protocol Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Thu Oct 30 17:54:21 2014
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 2C3891A8A3A for <xmpp@ietfa.amsl.com>; Thu, 30 Oct 2014 17:54:20 -0700 (PDT)
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 ddHUxEvOdc-V for <xmpp@ietfa.amsl.com>; Thu, 30 Oct 2014 17:54:17 -0700 (PDT)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A24A1A8A28 for <xmpp@ietf.org>; Thu, 30 Oct 2014 17:54:17 -0700 (PDT)
Received: by mail-ig0-f179.google.com with SMTP id r10so83170igi.0 for <xmpp@ietf.org>; Thu, 30 Oct 2014 17:54:16 -0700 (PDT)
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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VKyIpeDacCFkELGeVHWmEwvXrluLG1nsyx5KUpGHhAU=; b=Mf09gebYsFha2YpDKmzgUgNU42TLZnpKmySowBiEFob5vIqwccSwkYVgxyZzJYA0J7 mnWFz/QOqxd5+o2b5E2o2yY9t5g7tFJhUTpJjYUUrjyAvF7cj/2XOjWhrGQiJdhoqdjD ftMDY4Pzm6VUZ6iSRhWKK/pYMDfKEUudL1yOoqpdCFgok5xhT+gLIz0MqozIxpPsDpUV GkfOlpOj3I5lmdU/traUlAsJr9YDrxPSvm1JGqu2lq5+0JcQpNtGSjdnJGFnpT03+40i fMbMvfuL5MTtJ9drow5gqn140mWYSGxX5/sl5NhSbQNr7Go7K7n7BWvaWIwEQSnkNav0 Q+SA==
X-Gm-Message-State: ALoCoQlVA4ZniXPezdJlVoSWHwALSnGkltc8TASr2bDE0ZD0R+Od5aG4amVx+Z6Y5690TQProMUh
X-Received: by 10.107.37.12 with SMTP id l12mr10470849iol.40.1414716856693; Thu, 30 Oct 2014 17:54:16 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ro6sm4782488igb.3.2014.10.30.17.54.14 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 17:54:15 -0700 (PDT)
Message-ID: <5452DDB6.9090907@andyet.net>
Date: Thu, 30 Oct 2014 18:54:14 -0600
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: XMPP Working Group <xmpp@ietf.org>
References: <20141031001605.A02DC181C86@rfc-editor.org>
In-Reply-To: <20141031001605.A02DC181C86@rfc-editor.org>
X-Forwarded-Message-Id: <20141031001605.A02DC181C86@rfc-editor.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/q4jHKUyl3Uv-lawIZxkDWx0OuTI
Subject: [xmpp] Fwd: [rfc-dist] RFC 7395 on An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
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, 31 Oct 2014 00:54:20 -0000

Good work Lance, Jack, & Eric!


-------- Original Message --------
Subject: [rfc-dist] RFC 7395 on An Extensible Messaging and Presence 
Protocol (XMPP) Subprotocol for WebSocket
Date: Thu, 30 Oct 2014 17:16:05 -0700 (PDT)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: drafts-update-ref@iana.org, xmpp@ietf.org, rfc-editor@rfc-editor.org

A new Request for Comments is now available in online RFC libraries.


         RFC 7395

         Title:      An Extensible Messaging and Presence
                     Protocol (XMPP) Subprotocol for WebSocket
         Author:     L. Stout, Ed.,
                     J. Moffitt,
                     E. Cestari
         Status:     Standards Track
         Stream:     IETF
         Date:       October 2014
         Mailbox:    lance@andyet.net,
                     jack@metajack.im,
                     eric@cstar.io
         Pages:      18
         Characters: 36795
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-ietf-xmpp-websocket-10.txt

         URL:        https://www.rfc-editor.org/rfc/rfc7395.txt

This document defines a binding for the Extensible Messaging and
Presence Protocol (XMPP) over a WebSocket transport layer.  A
WebSocket binding for XMPP provides higher performance than the
current HTTP binding for XMPP.

This document is a product of the Extensible Messaging and Presence 
Protocol Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   https://www.ietf.org/mailman/listinfo/ietf-announce
   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org

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