Hello, 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 > protocols. Also registration of the ALPN protocol IDs is required also: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids 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 > trivially). 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. :) Thanks, Travis _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________