[Standards] Advance XEP-0368 to Proposed
travis at burtrum.org
Tue Jan 24 12:54:32 UTC 2017
Thanks for the comments, I'll address these in-line:
On 01/19/2017 05:11 PM, Dave Cridland wrote:
> 1) SNI really needs to be a MUST rather than a SHOULD. It's the moral
> equivalent to having a "to" in the stream open for the pre-TLS
> STARTTLS case, which is also mandated as of RFC 6120.
That makes sense, I agree.
> 2) IANA registration is required for xmpps-client and xmpps-server SRV
Also registration of the ALPN protocol IDs is required also:
4 IANA registrations for 1 XEP, is that a new record? :)
> 3) Should we request IANA register 5223 and 5270 as default ports?
That's another issue I guess, this XEP at least doesn't have any concept
of default ports.
> 4) "TLS provides more security than STARTTLS", for example, in
> Security Considerations doesn't make sense - I think we need a term
> for immediate-mode TLS. What about "Immediate-mode TLS"?
That's as good as anything else I suppose, I might mention in a note
that this is 'like HTTPS' but otherwise I'm fine with that.
> 5) I think it'd be beneficial to point to RFC 2595 Section 7, and note
> that the rationales listed there have either become outdated, or else
> do not apply where SRV records are in use. For example, the URL issue
> is a non-issue with XMPP, where the URL scheme will not change
> irrespective of the record followed. (Also, it's always fun to cite
> any RFC mentioning ACAP, right?)
Yea I read through that and they indeed don't apply in this case at all.
Where in the XEP should this be pointed out? and in how much detail?
> 6) Security Considerations should note that in the absence of DNSSEC,
> there is still a downgrade attack possible. (You can spoof the
> non-existence or incorrect Immediate-mode TLS records fairly
DNS spoofing/manipulation equally applies to regular STARTTLS SRV lookup
and this SRV lookup in the absence of DNSSEC, I suppose it wouldn't hurt
to mention it though.
> Incidentally, while I've coded up the S2S variant in Metre, I've not
> really tested it at all - if anyone else is up for implementing it
> than we can give it a bit of a whirl on interop.
Awesome! That's the first S2S implementation of this that I've heard of. :)
More information about the Standards