Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

On Mittwoch, 27. September 2017 17:25:02 CEST Dave Cridland wrote:
> On 27 September 2017 at 16:37, Jonas Wielicki  wrote:
> > aioxmpp as client library supports this XEP minus ALPN. If ALPN support in
> > a second client implementation is all it needs, I can probably fix that
> > in a week or so (I took a quick look, the TLS library supports it). I
> > don’t have a server to test against though, and thus it hasn’t been on my
> > short list until now.
> 
> I'm not actually convinced ALPN is an interoperability requirement of
> this protocol anyway.
> 
> It's nice to have it, probably, but lacking it would not mean that the
> essential notion of Direct TLS broke.

Indeed, but if the choice is to remove ALPN from the XEP or not to advance it 
to Final, I would personally prefer this XEP to stay in Draft for now. ALPN 
*is* a useful tool in this context when multiplexing is needed or desired.

If you’re only talking about removing ALPN for S2S, I have no strong opinion 
about that.


> >> On that basis, I don't *think* we can include S2S in Final,
> > 
> > We’re talking about Draft here, not Final. But I assume this is a typo?
> 
> The CFE is for Final, isn't it? The XEP is Draft now.

Ha, you’re right. Got something confused in my mind, sorry for carrying on 
that confusion to the list.


kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 27 September 2017 at 16:37, Jonas Wielicki  wrote:
> aioxmpp as client library supports this XEP minus ALPN. If ALPN support in a
> second client implementation is all it needs, I can probably fix that in a
> week or so (I took a quick look, the TLS library supports it). I don’t have a
> server to test against though, and thus it hasn’t been on my short list until
> now.

I'm not actually convinced ALPN is an interoperability requirement of
this protocol anyway.

It's nice to have it, probably, but lacking it would not mean that the
essential notion of Direct TLS broke.

>> On that basis, I don't *think* we can include S2S in Final,
>
> We’re talking about Draft here, not Final. But I assume this is a typo?

The CFE is for Final, isn't it? The XEP is Draft now.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

On Mittwoch, 27. September 2017 08:51:48 CEST Dave Cridland wrote:
> The rules on "two implementations" are, I believe, aimed to correspond
> to RFC 2026's Section 4.1.2, with the addition of licensing
> requirements.
> 
> I'd note, in particular, the second paragraph:
> 
>The requirement for at least two independent and interoperable
>implementations applies to all of the options and features of the
>specification.  In cases in which one or more options or features
>have not been demonstrated in at least two interoperable
>implementations, the specification may advance to the Draft Standard
>level only if those options or features are removed.
> 
> This does not have procedural force in the XSF, however I think it's a
> sensible consideration - it makes little sense to include options not
> exercised.
> 
> > 1. Yes Conversations supports SNI[1] and ALPN[2] where available.  These
> > are guaranteed to be in android 4.2 and 4.4 respectively, and *might* be
> > supported earlier depending on vendor.  According to the stats[3] this
> > means ~92% of androids currently in use support both.
> 
> FWIW, XEP-0001 talks about implementations, rather than deployment,
> but this information is nevertheless useful, thanks.

aioxmpp as client library supports this XEP minus ALPN. If ALPN support in a 
second client implementation is all it needs, I can probably fix that in a 
week or so (I took a quick look, the TLS library supports it). I don’t have a 
server to test against though, and thus it hasn’t been on my short list until 
now.

> So we end up with:
> 
> * ALPN seems to be a MAY for servers, and at most a SHOULD for clients
> (but probably a MAY).
> * SNI is a MUST for clients but a SHOULD for servers, noting that
> multiple certificates will necessitate SNI to be properly
> interoperable.
> * With these changes, anything supporting "legacy SSL", or "xmpps", is
> conformant on the server side for C2S - but none of these support SNI
> or ALPN.
> * We have one client implementation, supporting SNI and ALPN.
> * We have one S2S implementation, supporting SNI.
> 
> On that basis, I don't *think* we can include S2S in Final, 

We’re talking about Draft here, not Final. But I assume this is a typo?

> which is
> frustrating. We probably can include C2S, but with only one
> client-side implementation it's playing a little fast and loose, I
> think, and I'd much rather see SNI support server-side to feel
> satisfied that SNI is actually covered.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Evgeny Khramtsov]

Wed, 27 Sep 2017 14:33:07 +0100
Dave Cridland  wrote:

> But in any case, I think we can declare victory.

Neat.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 27 September 2017 at 11:34, Evgeny Khramtsov  wrote:
> Wed, 27 Sep 2017 13:10:58 +0300
> Evgeny Khramtsov  wrote:
>
>> Wed, 27 Sep 2017 10:17:14 +0100
>> Dave Cridland  wrote:
>>
>> > I believe I have the right records and code running at
>> > dave.cridland.net if you'd like to try.
>>
>> Yes, it works (connected to 5270 port and TLS auth is accepted), but
>> your server then connected on my _xmpp-server port, despite I have
>> _xmpps-server defined:
>>
>> $ host -t srv _xmpps-server._tcp.zinid.ru
>> _xmpps-server._tcp.zinid.ru has SRV record 0 0 5270 xmpp.zinid.ru.
>
> Ah, this is probably because of priority. I fixed that, but it will
> take time for DNS zone update.

Well, maybe.

If you have records:

_xmpps-server ... SRV 0 0 5270 host
_xmpp-server ... SRV 0 0 5269 host

then you have two records at the same priority with zero weight, and
Metre will be confused. You want 0/1 and 0/1 at least, for 50%
selection.

On the other hand, having 0/0 and 1/0 is fine.

I see you now have 1/1 and 5/1 for STARTTLS and Direct TLS respectively.

FWIW, I'm connecting fine to you using Direct TLS; although I noticed
I've just got 5/1 for both, so it's a 50% probability of connecting
either way to me.

But in any case, I think we can declare victory.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Evgeny Khramtsov]

Wed, 27 Sep 2017 13:10:58 +0300
Evgeny Khramtsov  wrote:

> Wed, 27 Sep 2017 10:17:14 +0100
> Dave Cridland  wrote:
> 
> > I believe I have the right records and code running at
> > dave.cridland.net if you'd like to try.  
> 
> Yes, it works (connected to 5270 port and TLS auth is accepted), but
> your server then connected on my _xmpp-server port, despite I have
> _xmpps-server defined:
> 
> $ host -t srv _xmpps-server._tcp.zinid.ru
> _xmpps-server._tcp.zinid.ru has SRV record 0 0 5270 xmpp.zinid.ru.

Ah, this is probably because of priority. I fixed that, but it will
take time for DNS zone update.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Evgeny Khramtsov]

Wed, 27 Sep 2017 10:17:14 +0100
Dave Cridland  wrote:

> I believe I have the right records and code running at
> dave.cridland.net if you'd like to try.

Yes, it works (connected to 5270 port and TLS auth is accepted), but
your server then connected on my _xmpp-server port, despite I have
_xmpps-server defined:

$ host -t srv _xmpps-server._tcp.zinid.ru
_xmpps-server._tcp.zinid.ru has SRV record 0 0 5270 xmpp.zinid.ru.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 27 September 2017 at 10:09, Evgeny Khramtsov  wrote:
> Wed, 27 Sep 2017 08:51:48 +0100
> Dave Cridland  wrote:
>
>> * We have one S2S implementation, supporting SNI.
>>
>> On that basis, I don't *think* we can include S2S in Final, which is
>> frustrating. We probably can include C2S, but with only one
>> client-side implementation it's playing a little fast and loose, I
>> think, and I'd much rather see SNI support server-side to feel
>> satisfied that SNI is actually covered.
>
> I just added partial support to ejabberd:
> https://github.com/processone/ejabberd/commit/c17ec50e3a989e3d8ceb78f94ee2a7d5eec5f7d3
>
> Not sure if this is counted as THE IMPLEMENTATION, because incoming SNI
> is not processed (not a big deal if you have only a single virtual
> host, but a problem with multi-hosting deployments).

I believe I have the right records and code running at
dave.cridland.net if you'd like to try.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 27 September 2017 at 02:37, Travis Burtrum  wrote:
> On 09/25/2017 06:57 AM, Dave Cridland wrote:
>> On 25 September 2017 at 06:06, Travis Burtrum  wrote:
>>>
>>> Conversations has had support since before this became a XEP actually.
>>>
>>> Everyone I know of has implemented the server-side of the c2s connection
>>> either with a dedicated xmpp-over-TLS port, or using sslh to multiplex
>>> on ALPN.  Debian even has an (unfortunately-named) section of their wiki
>>> on installing prosody about it [1].
>>>
>>> I also count 21 public servers on this test chart that have support [2].
>>>
>>
>> Do those all support SNI? I think SNI is critically important here
>> (and it's a MUST in the specification).
>
> I'm not sure exactly which you are asking questions about, so I'll just
> mention them all.
>

Thanks for this information. For the record, I'd love this XEP to
advance, I'm just trying to ascertain whether it can, and would much
rather apply a strict interpretation of the rules.

The rules on "two implementations" are, I believe, aimed to correspond
to RFC 2026's Section 4.1.2, with the addition of licensing
requirements.

I'd note, in particular, the second paragraph:

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

This does not have procedural force in the XSF, however I think it's a
sensible consideration - it makes little sense to include options not
exercised.

> 1. Yes Conversations supports SNI[1] and ALPN[2] where available.  These
> are guaranteed to be in android 4.2 and 4.4 respectively, and *might* be
> supported earlier depending on vendor.  According to the stats[3] this
> means ~92% of androids currently in use support both.
>

FWIW, XEP-0001 talks about implementations, rather than deployment,
but this information is nevertheless useful, thanks.

> 2. SSLH will multiplex on both ALPN and SNI, prosody doesn't support SNI
> on it's 'legacy_ssl_ports' (name needs changed...), though there was an
> unfinished patch floating around.
>
> 3. My guess is most of those host a single domain and don't need SNI.

It's not clear to me whether SSLH really counts as an implementation,
and your (3) suggests that you really consider SNI a "SHOULD" or
possibly "MAY" for servers. This may be a reasonable stance, given
that for a single domain C2S it isn't required. The strict
interpretation is really on the number of distinct certificates rather
than the number of distinct domains, so one could apply the same
argument to S2S.

So we end up with:

* ALPN seems to be a MAY for servers, and at most a SHOULD for clients
(but probably a MAY).
* SNI is a MUST for clients but a SHOULD for servers, noting that
multiple certificates will necessitate SNI to be properly
interoperable.
* With these changes, anything supporting "legacy SSL", or "xmpps", is
conformant on the server side for C2S - but none of these support SNI
or ALPN.
* We have one client implementation, supporting SNI and ALPN.
* We have one S2S implementation, supporting SNI.

On that basis, I don't *think* we can include S2S in Final, which is
frustrating. We probably can include C2S, but with only one
client-side implementation it's playing a little fast and loose, I
think, and I'd much rather see SNI support server-side to feel
satisfied that SNI is actually covered.

I'm therefore leaning toward gently pushing back on this (though I
suspect I might find the time to implement in Openfire).

Dave.

>
> [1]:
> https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/SSLSocketHelper.java#L33
> [2]:
> https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/utils/SSLSocketHelper.java#L45
> [3]: https://developer.android.com/about/dashboards/index.html
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 25 September 2017 at 06:14, Travis Burtrum  wrote:
> On 09/22/2017 08:39 AM, Dave Cridland wrote:
>> a) I query whether ALPN needs to be SHOULD rather than MAY,
>> particularly for S2S cases.
>
> That very well could be.  I'll give you the background, and the exact
> wording can be discussed.
>
> ALPN is only required for easy multiplexing multiple services on a
> single TLS port.  On the server, it has the upside of being simple, a
> standard, and easy to do.  On the client, it has the downside of
> announcing to the network that you will be talking xmpp in this TLS
> stream. (same as STARTTLS today)
>
> So once firewalls start looking at and blocking connections based on
> ALPN, clients need the option to try again without ALPN (or even to try
> first without ALPN).
>
> So MAY might be a better fit?  I just don't want to make it MUST.

It might be better as a MAY.

For S2S, I don't see that we're likely to run into any problem for
which the best solution is ALPN. For C2S, the only case I can see the
utility is in "traversing" (ie, exploiting) old HTTPS-only firewalls,
but we also have WebSocket for that. Most of the features ALPN
provides are already taken care of by the SRV discovery.

Support is spotty, as you say, and it's not clear to me that ALPN is
an inherent part of this protocol, in the way SNI is.

This is not to say that ALPN isn't useful at all - but I don't think
it makes much difference to XEP-0368's success.

>
> Thanks,
> Travis
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Travis Burtrum]

On 09/22/2017 08:39 AM, Dave Cridland wrote:
> a) I query whether ALPN needs to be SHOULD rather than MAY,
> particularly for S2S cases.

That very well could be.  I'll give you the background, and the exact
wording can be discussed.

ALPN is only required for easy multiplexing multiple services on a
single TLS port.  On the server, it has the upside of being simple, a
standard, and easy to do.  On the client, it has the downside of
announcing to the network that you will be talking xmpp in this TLS
stream. (same as STARTTLS today)

So once firewalls start looking at and blocking connections based on
ALPN, clients need the option to try again without ALPN (or even to try
first without ALPN).

So MAY might be a better fit?  I just don't want to make it MUST.

Thanks,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Travis Burtrum]

On 09/19/2017 12:04 PM, Jonas Wielicki wrote:
> Dear list,
> 
> With my XEP Editor hat on, we’d like to issue a Call for Experience for 
> XEP-0368. This is the step taken before proposing advancement of a XEP to 
> Final status to Council.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0368 implemented? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of 
> which must be free or open-source software) in order to advance from 
> Draft to Final.

Conversations has had support since before this became a XEP actually.

Everyone I know of has implemented the server-side of the c2s connection
either with a dedicated xmpp-over-TLS port, or using sslh to multiplex
on ALPN.  Debian even has an (unfortunately-named) section of their wiki
on installing prosody about it [1].

I also count 21 public servers on this test chart that have support [2].

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368? If so, please describe the problems and, if possible,
> suggested solutions.

ALPN support is still spotty, but getting better quick due to HTTP2
requiring it.

> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

I thought so, but maybe providing some additional clarification re:
STARTTLS might be appropriate.

Thanks,
Travis

[1]: https://wiki.debian.org/InstallingProsody#XMPP_over_HTTPS
[2]: https://gultsch.de/compliance.html
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Guus der Kinderen]

As an Openfire developer, I can tell you that we find the naming "legacy"
for "direct SSL" unfortunate. We're planning to rename that. Direct SSL. I
happened to create an issue for that in our tracker yesterday:
https://issues.igniterealtime.org/projects/OF/issues/OF-1378

On 23 September 2017 at 14:58, 殷啟聰 | Kai-Chung Yan 
wrote:

> According to the documentations of some XMPP servers (e.g. OpenFire and
> ejabberd), using TLS directly when connecting is described as "legacy",
> "deprecated" or "not recommended". Is this "legacy" connection method the
> same as the one described in this XEP? If so, is this XEP also encouraging
> direct TLS unlike those servers?
>
>
> Guus der Kinderen 於 2017年09月23日 02:08 寫道:
>
>
> Wait, what are we discussing again?
>>
>>
> We were discussing if I was fully, or completely right, of course. :-P
>
> Also, I again have to postpone my bikeshed-warming-party. It's not
> finished yet. Will let you know.
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

On Samstag, 23. September 2017 20:58:08 CEST 殷啟聰 | Kai-Chung Yan wrote:
> According to the documentations of some XMPP servers (e.g. OpenFire and
> ejabberd), using TLS directly when connecting is described as "legacy",
> "deprecated" or "not recommended". Is this "legacy" connection method the
> same as the one described in this XEP? If so, is this XEP also encouraging
> direct TLS unlike those servers?

It is described as "legacy" etc. because back in the days there was the move 
to STARTTLS as specified in RFC6120. There’s no mention of direct TLS 
connection in RFC6120. (Correct me if I’m wrong :-).)

However, XEP-0368 introduces a mechanism to properly discover direct TLS 
connections (via SRV records). It doesn’t force to use a specific port (which 
is often an argument against direct TLS).

So, in part, yes, this is the "legacy" method those servers support. Make sure 
they support SNI on the direct TLS port.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[殷啟聰 | Kai-Chung Yan]

According to the documentations of some XMPP servers (e.g. OpenFire and 
ejabberd), using TLS directly when connecting is described as "legacy", 
"deprecated" or "not recommended". Is this "legacy" connection method the same 
as the one described in this XEP? If so, is this XEP also encouraging direct 
TLS unlike those servers?

Guus der Kinderen 於 2017年09月23日 02:08 寫道:
>
> Wait, what are we discussing again?
>
>
> We were discussing if I was fully, or completely right, of course. :-P
>
> Also, I again have to postpone my bikeshed-warming-party. It's not finished 
> yet. Will let you know.
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Guus der Kinderen]

> Wait, what are we discussing again?
>
>
We were discussing if I was fully, or completely right, of course. :-P

Also, I again have to postpone my bikeshed-warming-party. It's not finished
yet. Will let you know.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 22 September 2017 at 18:23, Florian Schmaus  wrote:
> On 22.09.2017 19:19, Guus der Kinderen wrote:
>>
>>
>> On 22 September 2017 at 19:15, Florian Schmaus > > wrote:
>>
>> On 22.09.2017 13 :50, Guus der Kinderen wrote:
>> > I suggest to improve the wording of this XEP by replacing the command
>> > name "STARTTLS" with the technique name "Opportunistic TLS".
>>
>> I'm pretty sure STARTTLS is not the same as Opportunistic TLS. I also
>> think that XEP-0368 does not explicitly talk about opportunistic TLS.
>>
>>
>> Wikipedia says it is: https://en.wikipedia.org/wiki/StartTLS
>
> No, it says that STARTTLS can be used with opportunistic TLS. But I can
> do STARTTLS without opportunistic TLS. And I can do opportunistic TLS
> without STARTTLS.

Purple. I think we should paint it purple.

Wait, what are we discussing again?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Florian Schmaus]

On 22.09.2017 19:19, Guus der Kinderen wrote:
> 
> 
> On 22 September 2017 at 19:15, Florian Schmaus  > wrote:
> 
> On 22.09.2017 13 :50, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
> 
> I'm pretty sure STARTTLS is not the same as Opportunistic TLS. I also
> think that XEP-0368 does not explicitly talk about opportunistic TLS.
> 
> 
> Wikipedia says it is: https://en.wikipedia.org/wiki/StartTLS 

No, it says that STARTTLS can be used with opportunistic TLS. But I can
do STARTTLS without opportunistic TLS. And I can do opportunistic TLS
without STARTTLS.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Guus der Kinderen]

On 22 September 2017 at 19:15, Florian Schmaus  wrote:

> On 22.09.2017 13:50, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
>
> I'm pretty sure STARTTLS is not the same as Opportunistic TLS. I also
> think that XEP-0368 does not explicitly talk about opportunistic TLS.
>

Wikipedia says it is: https://en.wikipedia.org/wiki/StartTLS
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Florian Schmaus]

On 22.09.2017 13:50, Guus der Kinderen wrote:
> I suggest to improve the wording of this XEP by replacing the command
> name "STARTTLS" with the technique name "Opportunistic TLS". 

I'm pretty sure STARTTLS is not the same as Opportunistic TLS. I also
think that XEP-0368 does not explicitly talk about opportunistic TLS.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Peter Saint-Andre]

On 9/22/17 8:14 AM, Guus der Kinderen wrote:
> 
> 
> On 22 September 2017 at 15:58, Peter Saint-Andre  > wrote:
> 
> On 9/22/17 5:50 AM, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
> 
> "Opportunistic Security" usually means encryption without
> authentication:
> 
> https://tools.ietf.org/html/rfc7435
> 
> 
> 
> To me, that wouldn't be a problem. "Security" is rather generic,
> distinct from the very specific "TLS". 

Section 4 of that RFC is entitled "Example: Opportunistic TLS in SMTP".

https://tools.ietf.org/html/rfc7435#section-4

> I've also seen "Opportunistic Encryption" being used, described as
> "Opportunistic encryption (OE) refers to any system that, when
> connecting to another system, attempts to encrypt the communications
> channel, otherwise falling back to unencrypted communications."
> 
> I still favor "Opportunistic TLS" over "STARTTLS" in this text - but
> adding a clear description to the glossary would be good.

IMHO it's not smart for us to redefine a term that is well-understood
elsewhere.

Peter



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Guus der Kinderen]

On 22 September 2017 at 15:58, Peter Saint-Andre  wrote:

> On 9/22/17 5:50 AM, Guus der Kinderen wrote:
> > I suggest to improve the wording of this XEP by replacing the command
> > name "STARTTLS" with the technique name "Opportunistic TLS".
>
> "Opportunistic Security" usually means encryption without authentication:
>
> https://tools.ietf.org/html/rfc7435
>
>
To me, that wouldn't be a problem. "Security" is rather generic, distinct
from the very specific "TLS".

I've also seen "Opportunistic Encryption" being used, described as
"Opportunistic encryption (OE) refers to any system that, when connecting
to another system, attempts to encrypt the communications channel,
otherwise falling back to unencrypted communications."

I still favor "Opportunistic TLS" over "STARTTLS" in this text - but adding
a clear description to the glossary would be good.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Peter Saint-Andre]

On 9/22/17 5:50 AM, Guus der Kinderen wrote:
> I suggest to improve the wording of this XEP by replacing the command
> name "STARTTLS" with the technique name "Opportunistic TLS". 

"Opportunistic Security" usually means encryption without authentication:

https://tools.ietf.org/html/rfc7435

Peter




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

On 19 September 2017 at 17:04, Jonas Wielicki  wrote:
> Dear list,
>
> With my XEP Editor hat on, we’d like to issue a Call for Experience for
> XEP-0368. This is the step taken before proposing advancement of a XEP to
> Final status to Council.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0368 implemented? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of
> which must be free or open-source software) in order to advance from
> Draft to Final.
>

Metre, my S2S Proxy and Component Host, has implemented XEP-0368 for
some time, though without implementing ALPN. Artguably this places it
in breach of the specification as written, and I'd be curious as to
whether ALPN in particular is in other implementations. I'm sure I can
put the support in, I just haven't yet.

Metre is MIT-licensed, thus qualifies as an implementation, however it
does not interoperate with clients by its nature, and therefore I
would consider it essential for another server to exist to cover this
requirement.

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368? If so, please describe the problems and, if possible,
> suggested solutions.
>

I have not found any problems, other than a slightly increased
complexity at session startup.

> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>

It's clear enough for me.

> If you have any comments about advancing XEP-0368 from Draft to Final,
> please provide them by the close of business on Tuesday, October 3rd,
> 2017. After the Call for Experience, this XEP might undergo revisions to
> address feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.

While I have no objections to moving to Final at this time, I would note:

a) I query whether ALPN needs to be SHOULD rather than MAY,
particularly for S2S cases.
b) We may wish to republish this as an RFC in the future, and/or fold
it into a revision of the core specification.

Dave.

>
>
> You can review the specification here:
>
> https://www.xmpp.org/extensions/xep-0368.html
>
> Please send all feedback to the standards@xmpp.org discussion list.
>
> Thanks!
>
> Jonas
>
> P.S.: Procedural note: I’m not entirely clear on what is allowed to trigger a
> CFE (I don’t think that’s spelled out in XEP-0001). In this specific case, the
> author asked for it.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Guus der Kinderen]

I suggest to improve the wording of this XEP by replacing the command name
"STARTTLS" with the technique name "Opportunistic TLS". This way, we're not
comparing apples to oranges, when mentioning both in the same text.

To retain clarity, this term should be added to the glossary, with a
mention of STARTTLS.

I didn't invent the term, by the way: Wikipedia redirects to a page named
"Opportunistic TLS" from the "STARTTLS" page.

On 19 September 2017 at 18:04, Jonas Wielicki  wrote:

> Dear list,
>
> With my XEP Editor hat on, we’d like to issue a Call for Experience for
> XEP-0368. This is the step taken before proposing advancement of a XEP to
> Final status to Council.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0368 implemented? Please note that the protocol
> must be implemented in at least two separate codebases (at least one of
> which must be free or open-source software) in order to advance from
> Draft to Final.
>
> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368? If so, please describe the problems and, if possible,
> suggested solutions.
>
> 3. Is the text of XEP-0368 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>
> If you have any comments about advancing XEP-0368 from Draft to Final,
> please provide them by the close of business on Tuesday, October 3rd,
> 2017. After the Call for Experience, this XEP might undergo revisions to
> address feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
>
>
> You can review the specification here:
>
> https://www.xmpp.org/extensions/xep-0368.html
>
> Please send all feedback to the standards@xmpp.org discussion list.
>
> Thanks!
>
> Jonas
>
> P.S.: Procedural note: I’m not entirely clear on what is allowed to
> trigger a
> CFE (I don’t think that’s spelled out in XEP-0001). In this specific case,
> the
> author asked for it.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Sam Whited]

On Tue, Sep 19, 2017, at 11:15, Jonas Wielicki wrote:
> * Do we need to interact with some registry to get xmpps-server and
> xmpps-
> client SRV record service names registered? From my understanding, SRV
> records 
> can use the names as assigned in [3] or "locally defined" (whatever that 
> means!). Does what we do classify as "locally defined" and is sufficient?
> If 
> not, we should probably get xmpps-server / xmpps-client registered
> somewhere.

IANA has been contacted and the designated expert has said he's fine
with the registration from the XEP. Presumably he just hasn't gotten
around to publishing it yet.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

Now with my client developer hat on.

> 1. What software has XEP-0368 implemented?

I implemented XEP-0368 support in aioxmpp [1] (which is under LGPLv3 license).

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368?

I did not have outstanding issues (the ones I had have been clarified since 
then). I did not implement ALPN support though (which is a SHOULD in the 
spec), because I didn’t have a chance to look into how to do that yet.

> 3. Is the text of XEP-0368 clear and unambiguous? 

I think so.

> Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? 

Two final remarks:

* I find that the ALPN protocol ID registration still hasn’t gotten through to 
the official IANA registry [2].

* Do we need to interact with some registry to get xmpps-server and xmpps-
client SRV record service names registered? From my understanding, SRV records 
can use the names as assigned in [3] or "locally defined" (whatever that 
means!). Does what we do classify as "locally defined" and is sufficient? If 
not, we should probably get xmpps-server / xmpps-client registered somewhere.


Otherwise I find the XEP short and precise, understable, and easy to 
implement.


kind regards,
Jonas


   [1]: https://github.com/horazont/aioxmpp/blob/
97b34721585e2f761195ce1df5b2fc7dd42d3ef9/aioxmpp/node.py#L106
   [2]: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
   [3]: 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

[Jonas Wielicki]

Dear list,

With my XEP Editor hat on, we’d like to issue a Call for Experience for 
XEP-0368. This is the step taken before proposing advancement of a XEP to 
Final status to Council.


During the Call for Experience, please answer the following questions:

1. What software has XEP-0368 implemented? Please note that the protocol
must be implemented in at least two separate codebases (at least one of 
which must be free or open-source software) in order to advance from 
Draft to Final.

2. Have developers experienced any problems with the protocol as defined
in XEP-0368? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0368 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0368 from Draft to Final,
please provide them by the close of business on Tuesday, October 3rd, 
2017. After the Call for Experience, this XEP might undergo revisions to
address feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.


You can review the specification here:

https://www.xmpp.org/extensions/xep-0368.html

Please send all feedback to the standards@xmpp.org discussion list.

Thanks!

Jonas

P.S.: Procedural note: I’m not entirely clear on what is allowed to trigger a 
CFE (I don’t think that’s spelled out in XEP-0001). In this specific case, the 
author asked for it.

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___