Subject: [xmpp] WGLC Extension (was Re: WGLC on draft-ietf-xmpp-3920bis-08)

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Jun 2010 13:51:45 -0500

Hi,

We received very little WGLC feedback, I assume due to the length of the document, and the long holiday weekend in the US. Therefore we will extend the WGLC another week, to now conclude on 8 June 2010. Please send feedback to the authors and the working group mail list. 

This is the core specification for XMPP, so it's very important to get right. Please, even things like "The draft is ready to go; I don't have any more feedback" are good feedback.

Thanks!

Ben.

On May 13, 2010, at 4:38 PM, Ben Campbell wrote:

> This is a Working Group Last Call on draft-ietf-xmpp-3920bis-08. The draft is available at the following URL:
> 
> http://tools.ietf.org/id/draft-ietf-xmpp-3920bis-08.txt 
> 
> The WGLC will conclude on 28 May, 2010. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group.
> 
> Thanks!
> 
> Ben.

---

From: Matthew Wild <[email-masked]>
Date: Wed, 2 Jun 2010 04:13:38 +0100

> We received very little WGLC feedback, I assume due to the length of the document, and the long holiday weekend in the US. Therefore we will extend the WGLC another week, to now conclude on 8 June…

Good call, much thanks. I /have/ been working through the spec, but
you're right - it's a long one. I've simply been too busy the past
week to get finished and submit the feedback.

> This is the core specification for XMPP, so it's very important to get right. Please, even things like "The draft is ready to go; I don't have any more feedback" are good feedback.

*vigorous nod*

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 01 Jun 2010 21:28:42 -0600

On 6/1/10 9:13 PM, Matthew Wild wrote:
>> We received very little WGLC feedback, I assume due to the length
>> of the document, and the long holiday weekend in the US. Therefore
>> we will extend the WGLC another week, to now conclude on 8 June
>> 2010. Please send feedback to the authors and the working group
>> mail list.
>> 
> 

Sorry about the length. I have reviewed it probably a dozen times since
RFC 3920 was published, so I know it's not something you can do in an
hour or two...

/psa

---

From: Justin Karneges <[email-masked]>
Date: Thu, 3 Jun 2010 11:22:59 -0700

On Tuesday 01 June 2010 11:51:45 Ben Campbell wrote:
> We received very little WGLC feedback, I assume due to the length of the
> document, and the long holiday weekend in the US. Therefore we will extend
> the WGLC another week, to now conclude on 8 June 2010. Please send feedback
> to the authors and the working group mail list.
>
> This is the core specification for XMPP, so it's very important to get
> right. Please, even things like "The draft is ready to go; I don't have any
> more feedback" are good feedback.

Thanks for the extension.  I must have missed the original announcement.  I'll 
try to go through it.

My first reaction is that I think it's insane that dialback is missing from 
the core spec, and referred to via XEP.  It's an incredibly core feature, one 
that won't be going away anytime soon, and isn't even being deprecated (the 
XEP version is modernized from the original RFC).  Why split it out?

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 12:39:08 -0600

> XEP version is modernized from the original RFC).  Why split it out?

My first reaction to your first reaction is that we split dialback off
to XEP-0220 three years ago -- where have you been? :)

Considerations at that time included:

1. Dialback doesn't provide any security.

2. TLS + dialback is woefully underspecified.

3. It's not hard to follow the reference to XEP-0220.

4. Implementers all know about the need for dialback anyway.

5. rfc3920bis is long enough as it is, why clutter it up with
documentation of server dialback?

6. We might want to make changes to dialback (or at least documentation
thereof) and it would be easier to do that in a XEP than in an RFC.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Justin Karneges <[email-masked]>
Date: Thu, 3 Jun 2010 12:32:32 -0700

On Thursday 03 June 2010 11:39:08 you wrote:
> > My first reaction is that I think it's insane that dialback is missing
> > from the core spec, and referred to via XEP.  It's an incredibly core
> > feature, one that won't be going away anytime soon, and isn't even being
> > deprecated (the XEP version is modernized from the original RFC).  Why
> > split it out?
>

I'm pretty sure I had the same reaction 3 years ago too.  I believe the 
response I got back then was something along the lines of "we'll see what 
happens".  Well, now we're seeing. ;)

> 1. Dialback doesn't provide any security.

It may not provide real security, but that doesn't make it totally worthless.

I'd understand the decision if dialback were deprecated and we're trying to 
remove baggage, but that's not the case here.  The fact is dialback is still 
encouraged today, and not merely for interop with existing legacy XMPP 
services.  Dialback the best way to federate among modern, brand new servers 
being built this afternoon.

> 2. TLS + dialback is woefully underspecified.

If only there was an opportunity to revise a specification.

> 3. It's not hard to follow the reference to XEP-0220.

I accept this for things like XEP-0030 and XEP-0198.  But dialback and was 
already present in the original document, and it's not like all of federation 
was removed (the SASL approach remains).  Sure, it's not hard to follow a 
reference, but it just feels wrong to me that we're using a reference for 
something so core, particularly a XEP reference.

> 4. Implementers all know about the need for dialback anyway.

Why document anything?

> documentation of server dialback?

If you insist on splitting documents, then I might suggest moving both SASL 
and dialback mechanisms to a separate internet draft about XMPP federation.  
With the way the documents are split currently, it appears like SASL is the 
main way to federate and dialback is some optional approach, when in reality 
it's the reverse.

> thereof) and it would be easier to do that in a XEP than in an RFC.

Dialback is one of those things that really shouldn't be changing in any 
fundamental way.  We can easily put it in the core document, and define 
extensions outside in a XEP, just as we do with any other aspect of xmpp-core 
that we extend.

-Justin

---

From: Luca Taliaferri <[email-masked]>
Date: Fri, 04 Jun 2010 09:47:32 +0200

Hi,

I just finished reading the whole document.

I found everything was fine; both the new text and examples are even 
clearer than before.
I have only one concern about stanza numbering in many examples: I 
noticed that the numbering changed in many places from *bind_1*, 
*bind_2*, *roster_1*,etc. to *h83vxa4c*,*yhc13a95*, etc. .
I know that this may better reflect servers and clients behaviour 
however for clearifying and teaching purposes I think it should better 
to keep the former numbering sequences.

Thanks!

Luca

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 Jun 2010 15:55:23 -0600

> Hi,

Ciao Luca, thanks for the review. :)

> I found everything was fine; both the new text and examples are even 

Excellent.

> I have only one concern about stanza numbering
> in many examples: I noticed that the numbering changed in many places
> from *bind_1*, *bind_2*, *roster_1*,etc. to *h83vxa4c*,*yhc13a95*,
> etc. . I know that this may better reflect servers and clients
> behaviour however for clearifying and teaching purposes I think it
> should better to keep the former numbering sequences.

Hmph, I just changed those. But I could change them back if that's
preferred.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Curtis King <[email-masked]>
Date: Fri, 4 Jun 2010 16:00:41 -0700

> Hmph, I just changed those. But I could change them back if that's

I prefer them as is.

ck

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Jun 2010 10:50:37 -0500

<as individual>

>> Hmph, I just changed those. But I could change them back if that's

I would prefer to see the examples be representative of what we expect reasonable implementations to do. I suspect, but am not certain, that the current numbers are more realistic than numbers chosen for human readability.

It has been my experience that some implementors will look at the examples rather than the normative text. 

> 
> ck
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Dave Cridland <[email-masked]>
Date: Mon, 07 Jun 2010 17:31:07 +0100

On Tue Jun  1 19:51:45 2010, Ben Campbell wrote:
> This is the core specification for XMPP, so it's very important to  
> get right. Please, even things like "The draft is ready to go; I  
> don't have any more feedback" are good feedback.

I'm crap, but I have, finally, managed to review this specification  
at least as far as the end of Section 7.

It's a marked improvement over the original, please consider the  
number of points I make as an indication of my pickiness (maybe I  
mean thoroughness), rather than the quality of the spec itself.

I've prefixed comments with "EDITORIAL" and "TECHNICAL", although  
there is no doubt some overlap, and with the section number that the  
comment refers to - again, there is likely some overlap.

EDITORIAL: 1.1 and the abstract appear to be word-for-word identical.

TECHNICAL: 3.2.1 How much of this section is reiterating RFC 2782?  
And is it right? I note that it suggests, in point 4, "in order  
according to the returned SRV record weight", which seems wrong to me  
- it could be read as presuming the SRV weight to be an absolute  
ordering, rather than weighting the random selection given equal  
priority - priority seems conspicious by its absence here.

EDITORIAL: 3.2.3 While I understand the sentiment here (and agree  
with it, our product allows for this), I find it bizarre to  
legislate, as it were, with a SHALL, that explicit configuration must  
always override SRV-based discovery. Surely a mere note that  
implementations MAY provide explicit configuration, which may be used  
with, or instead of, discovery is sufficient?

TECHNICAL: 3.2.4 I'm unclear on precisely what this means. Is this  
saying that if I lookup cridland.net and find that it's hosted at  
Google, then I should ask my user about this? Why?

TECHNICAL: 3.3 I sincerely hope that a client ensures that the  
identity of the server is correct. This has nothing whatsoever to do  
with bidirectionality. I think much of this section needs replacing  
with a nice, handwavey "For historical reasons" bit.

TECHNICAL: 3.4 I vaguely recall some discussion about reconnecting to  
the same IP address, and/or hostname, before performing a full SRV  
rediscovery.

TECHNICAL: 4.2.7 You don't receive stream features after negotiating  
a feature which does not restart. I think another box is needed.

EDITORIAL: 4.2.7 It may be me, but I actually find state diagrams  
like this to be more complex than prose - I stared at this one trying  
to figure out why it had no much stuff in it. :-)

TECHNICAL: 4.3 ... "(but MAY >react< to data sent by the other  
entity)." - seems better, "respond" suggests the transmission of data.

TECHNICAL: 4.3.2 Most of this seems, to me, to apply to 4.3.1 cases  
as well - that is, you want to wait for your peer to acknowledge the  
close in the case where you've sent a stream error, as well, ideally.

TECHNICAL: 4.3.3 I'm not sure that much of the terminology of the  
second paragraph of this section is correct. A TCP connection being  
idle does not mean the network connection has been lost, for example.  
I also note that the recommendations I'm hearing seem to be that  
servers should be very conservative in doing whitespace pings - ie,  
every 5 minutes or more. Finally, an idle stream can, surely, be  
closed with a stream error of connection-timeout - §4.6.3.4 seems to  
describe this case. I don't follow why this is MUST NOT (here) and  
RECOMMENDED against (4.6.3.4) - these conflict in any case. Surely a  
client session, in particular, being disconnected due to non-response  
should be given a stream error?

TECHNICAL: 4.4.3 As I (vaguely) recall, and attribute in XML called  
"id" must actually be an id, syntactically, and the example you've  
chosen doesn't look like one to me. I suspect nobody cares, but just  
in case...

TECHNICAL: 4.4.4 I'm not entirely sure this is correct, either.  
Specifically, much of this appears to apply (and make sense in the  
context of) C2S rather than S2S.

EDITORIAL: 4.5.3 The Interop note at the end seems odd - why  
historical reasons for not supporting something not defined in the  
specification...?

TECHNICAL: 4.6.1.1 I don't think there's any pressing reason why the  
closing tag needs to be sent at the same time - "immediately close  
the stream" is what I think you mean here. Nor do I think there's any  
good reason why the TCP connection SHOULD be immediately closed,  
although for many cases, this is likely behaviour, so it's certainly  
a MAY, and with good reason (ie, the remainder fo the stream from the  
peer may be unparseable due to earlier errors).

TECHNICAL: 4.6.3.10 I think this error should be taken out and shot.  
Firstly, it's a fatal eror in response to a non-fatal condition, and  
secondly, it means I can randomly shut streams down. (Thankfully this  
one is never generated AFAIK). I don't think that syntactic  
enforcement of stream IDs is at all useful either.

EDITORIAL: 5.1 Can I just say how nice it is to see a reference to  
ACAP. It's still a vitally important protocol, and this just proves  
it. :-)

EDITORIAL: 5.1 By "An administrator of a given deployment MAY  
necessitate", does that mean that a dodgy admin might cause TLS to be  
required, or does it mean - as I suspect - "AN administrator of a  
given deployment MAY require"?

TECHNICAL: 5.1 I note that this recommends TLS for channel  
encryption, but I note that some SASL mechanisms may provide equal  
security - therefore I'd explain that this recommendation is aimed at  
mandating clients secure the channel, rather than simply recommending  
TLS for TLS's sake, per se.

EDITORIAL: 5.2.2 Perhaps reference previous discussion on stream  
restarts?

TECHNICAL: 5.2.2 ALso, this section fails to note that information  
needs discarding after the negotiation, too.

TECHNICAL: 5.2.5 When did this sneak in? And why?

TECHNICAL: 5.2.6 Mandating server_name? This seems unsatisfactory,  
not least because XMPP has its own perfectly sound method for  
selecting server name which works perfectly well.

TECHNICAL: 5.3.3.1 My understanding is that an initiating entity MAY  
send a certificate whether or not the receiving entity asks for one,  
so I see no value in (3). (1) is quite amusing, given that it's  
impossible to contravene. (2) eliminates usage of, for example,  
Anonymous DH, which might be acceptable in C2S deployments in  
conjunction with a channel-binding SASL mechanism. And (4) mandates  
that the receiving entity lives or dies on the sole basis of its  
certificate, whereas we've commonly treated this as one possible  
authentication rather than the sole means.

EDITORIAL: 5.3.3.2 It'd be useful to define some terms to describe  
<failure/> vs negotiation failure, here, to make this clearer.

TECHNICAL: 5.3.3.3 Point (5) does, technically, depend still on  
whether the version attribute was included in the stream header.

TECHNICAL: 6.2.3 "[...] if the server >erroneously< offers [...]",  
since it's an example of what a server MUST NOT do... I'm hesitant in  
describing this as in strength order, however - I think it's a case  
of preferential order, since "strength" is not only a movable feast,  
but may be outweighed by other factors such as use of SSO facilities.

TECHNICAL: 6.2.7 Traditionally, the simple username has been the node  
portion of a jid. I maintain this is remains a sensible default,  
although this mapping MAY not hold - it's certainly worthwhile noting  
that this is a typical mapping in current deployments.

TECHNICAL: 6.3.1 Third para: "If the receiving entity supports SASL"  
this is wrong - it's if the receiving entity wishes to offer any SASL  
mechanisms at this point - not offering SASL may simply mean that TLS  
is required first, for example.

TECHNICAL: 7.1 Can we mandate that the <not-authorized/> stream error  
is used? I dislike optional behaviour unless it serves some useful  
purpose - I don't see one here. (And this is without looking at what  
our implementation does).

TECHNICAL: 7.4 I see no compelling reason why the specification  
should require the use of a UUID as a resource identifier for strict  
comformance.

TECHNICAL: 7.6.3 I'm not sure why we mandate no more than 5 retries.  
The rest seems fine.

(To be continued, hopefully)

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 10:55:24 -0600

On 6/7/10 9:50 AM, Ben Campbell wrote:
>>>> I found everything was fine; both the new text and examples are
>>>> even clearer than before.
>>> 
>>> Excellent.
>>> 
>>>> I have only one concern about stanza numbering in many
>>>> examples: I noticed that the numbering changed in many places 
>>>> from *bind_1*, *bind_2*, *roster_1*,etc. to
>>>> *h83vxa4c*,*yhc13a95*, etc. . I know that this may better
>>>> reflect servers and clients behaviour however for clearifying
>>>> and teaching purposes I think it should better to keep the
>>>> former numbering sequences.
>>> 
>>> Hmph, I just changed those. But I could change them back if
>>> that's preferred.
>> 
>> I prefer them as is.
> 
> I would prefer to see the examples be representative of what we
> expect reasonable implementations to do. I suspect, but am not
> certain, that the current numbers are more realistic than numbers
> chosen for human readability.

A random sample of 'id' values from the XML console in my client yields
values like these:

762
a1194a
sqy_109
961-19247
8H8f4Fk-769
262380298080
purplea4591a82 (generated by libpurple)
+Poty7SpirDvwT/p

> examples rather than the normative text.

Mine, too.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 18:32:26 +0100

> It has been my experience that some implementors will look at the examples rather than the normative text.

I really dislike the hashish ids, I think it makes the examples harder
to read. However - what Ben says is right, and I think we need to keep
them.

/K

---

From: Matthew Wild <[email-masked]>
Date: Mon, 7 Jun 2010 18:39:43 +0100

> It has been my experience that some implementors will look at the examples rather than the normative text.

One middle-ground option would be to use letters in alphabetical order
instead of numbers. If someone hard-codes ids into their app that's
their problem as far as I'm concerned :)

Psi I think uses ids of the form "aaaa", "aaab" or something like
that. It seems reasonable to me.

Matthew

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 07 Jun 2010 19:46:03 +0200

> It may not provide real security, but that doesn't make it totally worthless.

It can provide real security when used with certificates. This works 
like SASL EXTERNAL and is - theoretically - capable of piggybacking.

> being built this afternoon.

[...]

> main way to federate and dialback is some optional approach, when in reality

Actually, I think that SASL EXTERNAL is the baggage which merely 
increases complexity - see XEP 0238. I disabled it months ago in favor 
of dialback with certificates.

If SASL EXTERNAL documented in 3920bis will make it much harder to get 
rid of it.

---

From: Florian Zeitz <[email-masked]>
Date: Mon, 07 Jun 2010 23:39:35 +0200

> This is the core specification for XMPP, so it's very important to get right. Please, even things like "The draft is ready to go; I don't have any more feedback" are good feedback.

*takes a deep breath*
Okay, so I finally managed to read through the RFC more or less
thoroughly. Unfortunately I haven't read the "original", but compared to
others I've seen it's amazing. None the less I have some feedback, most
of them nits, but still:

Section 1.3:
Point 5 in the first list probably should be reworded. You will actually
perform authentication and not only negotiate a algorithm.

Section 1.4:
"Following the convention used in [URI] to represent Uniform Resource
Indentifiers, XMPP addresses in running text are enclosed between '<'
and '>'."
This is not true as such. Most XMPP addresses in running text are
enclosed between '"'s.
Also text between '<' and '>' in this document tends to be a mail
address, but not (if I didn't miss anything) a URI as such, because it
lacks a scheme.

Section 1.5:
"However, thanks are due to those who have who have provided
implementation feedback"
Typo, one "who have" should suffice ;)

Section 2.5:
"Storing XML data that is used by clients (e.g., contact lists for users
of XMPP-based instant messaging and presence applications"
This data is not strictly stored as XML and the data will eventually
change until the client next requests it (especially for rosters). Maybe
rather something along the lines of "Managing data[...]". YMMV

Section 3.2.5:
This says that SRV records are mandatory for Add-On Services.
In current practice they are not, a "normal" DNS entry suffices, which
is to say that the fallback (3.2.2) for a XMPP service should apply to
Add-On Services too IMHO.

Section 3.3:
More of a question: While out of scope here, is use and signaling of
bidirectonal connections explained somewhere? If so: Shouldn't there be
a reference to it here?

Section 4.1:
The definition of XML Stanza seems a bit overcomplicated. It goes to
great lenght to explain that a first XML child of the <stream/> is a
stanza and only later clarifies that only <message/>, <presence/> and
<iq/> are stanzas. The phrase "only XML stanzas defined in this
specification" also sounds strange. Do/will other specifications define
other XML stanzas? And if that's the case how does one tell stanzas and
ordinary elements apart?
Additionally the definition says a stanza is denoted by a start- and
end-tag. This would mean that empty elements are never a stanza, because
they are a special third case according to [XML], is this intentional?
In general I suspect it suffices to say something to the effect of:
"A XML stanza is a special kind of first level XML child element of the
<stream/> element. This specification defines that <message/>,
<presence/> and <iq/> are stanzas."

Section 4.4.1:
"as described under (see Section 13.5."
Typo, superfluous "(see"

Section 4.6.3.2:
Depending on the intention the example should say
"C: <?xml version='1.0'?>
   <foobar:stream
       from=[email-masked]'
       to='im.example.com'
       version='1.0'
       xmlns='jabber:client'
       xmlns:foobar='http://etherx.jabber.org/streams'>"
The current example shows two error conditions. Not supported namespace
prefix and an unbound namespace prefix of "stream". Only the former is
mentioned.

Section 4.6.3.23:
IMHO the example should contain a <required/> child element for clarity.

Section 6.3.1:
"if the initiating entity is capable of STARTTLS negotiation"
In the first paragraph probably should say "SASL negotiation".

Section 7.6.1:
"The server SHOULD accept the client-submitted resourcepart."
Might be worth spending a subordinate clause saying that this is only
true if resourceprep is successful etc.

Section 8.3.2:
"<stanza-kind from='intended-recipient' to='sender' type='error'>"
Mention somewhere that "intended-recipient" and "sender" is that of the
original stanza even though rather obvious.

Section 8.3.3.13:
Typo, s/servive/service/

Section 9.1.3:
Possibly add a "Step 14 (alt)" showing the error case for resource binding.

Section 10.1.4:
"If the IQ stanza is of type "error" or "result", the server MUST handle
the error or result in accordance with the payload of the associated IQ
stanza or type "get" of "set"."
Should probably say that if a IQ stanza of type "error" or "result" is
received, but the server didn't send a IQ stanza of type "get" or "set"
it should be silently ignored.

It is I think in multiple places, but at least in Section 4.2.2 said
that an initiating entity is cleared to send XML stanzas when there are
no MTN features left. However resource binding is MTN, but uses IQ
stanzas for negotiation. Maybe at least explicitly mention it as an
exception?

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 15:51:11 -0600

> like SASL EXTERNAL and is - theoretically - capable of piggybacking.

I assume you mean TLS+dialback. Dialback on its own doesn't provide any
security (or barely any).

> If SASL EXTERNAL documented in 3920bis will make it much harder to get

It would be a major change to (1) document and mandate TLS+dialback plus
(2) remove and deprecate TLS+SASL-EXTERNAL for s2s.

Among other things, such a change would imply that we're making security
claims for dialback, despite the fact that dialback has never undergone
a security review (as has SASL).

IMHO such a change would not be well-received by the security
directorate, Security Area ADs, etc.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Tue, 8 Jun 2010 08:48:22 +0100

> a security review (as has SASL).

Plus you still want EXTERNAL for c2s anyway.

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 08 Jun 2010 11:18:34 +0100

On Mon Jun  7 22:51:11 2010, Peter Saint-Andre wrote:
> >> It may not provide real security, but that doesn't make it  
> totally
> >> worthless.
> >
Hence the reason we have such a major problem with rampant spoofing  
of servers, of course.

But seriously, Philipp is describing using the mechanism of dialback  
to perform the task usually done by EXTERNAL.

> (2) remove and deprecate TLS+SASL-EXTERNAL for s2s.

And more to the point, the idea of documenting a SASL mechanism which  
is *not* allowed would be terribly, terribly weird.

> directorate, Security Area ADs, etc.

Probably not, no.

Dave.

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 08 Jun 2010 14:08:22 +0200

> security (or barely any).

Two definitions:
TLS+dialback:
doing dialback after <starttls/> if the certificate of the peer is not 
trusted. This is common practice, even though it is theoretically not 
possible because of some statements in RFC 3920 (which are less strict 
in 3920bis-08).

DWD (or dialback-without-dial-back):
when receiving
	<db:result from='some.host' to='example.com'>somekey</db:result>
(STEP 1 in XEP 220) after <starttls/> and the certificate is 
trustworthy, example.com immediately replies with
	<db:result from='example.com' to='some.host' type='valid'/>
(STEP 4 in XEP 220) without verifying the key. This is the most 
important of Dave's dialback shortcuts proposed last (?) year.

I mean DWD here.

> It would be a major change to (1) document and mandate TLS+dialback plus

Yes. That was the reason that I preferred to bury my head in the sand.

> (2) remove and deprecate TLS+SASL-EXTERNAL for s2s.

TLS+SASL-EXTERNAL for s2s is not broken actually. It is not that hard to 
implement either. And even if 0238 is looking really complex, it is not 
like you have to implement 36 special cases to do both dialback and 
external.

But when I looked at my s2s logs (before disabling external), only three 
servers (out of about hundred) were offered TLS+SASL-EXTERNAL by my 
server. There is not that much to deprecate actually.

> a security review (as has SASL).

No. The security claim would only be made for the dialback request and 
response, not for the dialback key verification.

> directorate, Security Area ADs, etc.

Oh, I will happily accept the decision to keep TLS+SASL-EXTERNAL as MTI
if those guys (or anyone else) explain me:
1) why SASL has to be used for S2S. RFC 2779 states that
  "It MUST be possible for ENTITIES in one DOMAIN to interoperate
   with ENTITIES in another DOMAIN, without the DOMAINS having
   previously been aware of each other."
   How does SASL help with that?

2) how I can use TLS+SASL-EXTERNAL (and only TLS+SASL-EXTERNAL!) in an 
environment where 75 percent (I am optimistic) of the peer certificates 
are not trusted.