-
flow
larma, I think we are probably saying the same: you may can deduce RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema✎ -
flow
larma, I think we are probably saying the same: you may can provide a indication of RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema✎ ✏ -
flow
larma, I think we are probably saying the same: you may can provide a "hint" towards RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema ✏
-
Zash
Deriving intent from the schema?
-
flow
I think I do that all the time, e.g. when it is unclear if the value provided by the xml-layer should be an integer or a string
-
flow
or if a certain element or attribute is required
-
Zash
That seems fine to me. Isn't it primarily when the text and the schema disagree that the text takes priority? Like with examples.
-
flow
That certainly is the case. Although, I'm not sure about meaning of the "primarily" part, sometimes the text underspecifies the wire protocol, and the schema helps
-
larma
flow, not sure if I missed something in the channel binding discussion, but what would be wrong with `<mechanism xmlns='urn:xmpp:channel-binding' type='tls-exporter'>SCRAM-SHA-1-PLUS</mechanism>`. This looks a lot cleaner to me...
-
Daniel
i didn’t read the whole thread (just the initial xep proposal) but i like that solution
-
flow
larma, as special case for a hypothetical sasl mechanism channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all✎ -
flow
larma, as special case for a hypothetical sasl mechanism exclusive channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all ✏
-
larma
flow, I thought it wasn't properly defined which type to use and that is an issue, isn't it?
-
flow
larma, no, the issue is that you do not know which cb types the remote endpoint supports
-
flow
-PLUS just signalls that cb is used, but not which cb type
-
flow
all currently registered cb types with IANA are currently available for all -PLUS sasl mechanisms
-
flow
and tls-server-end-point should be (basically) always available
-
flow
but tls-unique may not
-
flow
so if a client tries to do -PLUS with tls-unique, then things get a bit ugly
-
Zash
My understanding is that PLUS being advertised means channel binding is supported, and then negotiated in a header in a header in SCRAM.
-
flow
Zash, yes, but the server has no way to signal the supported cb types to the client
-
flow
IIRC there is no negotiation in gss api
-
Zash
Yes
-
flow
the client just says, I do cb type x and hopes the server support x✎ -
flow
the client just says, I do cb type x and hopes the server supports x ✏
-
Zash
Right, which is weird and why it's good to try to solve that.
-
flow
correct, and I think my proposal solves that in a neat and clean way
-
larma
flow, I like yours more than the original proposal. But looking at the specs again, I was just wondering if instead of signaling it we could just define that a) in TLS < 1.3, only tls-unique may be used, b) in TLS 1.3 only tls-exporter may be used (although we'd probably want to wait for it to be IANA registered before defining that)
-
flow
why only tls-unique for tls 1.3? and why close the door for tls-server-end-point? all other cb's are probably blocked or at least stalled until the TLS APIs provide a way to extract the cb data, tls-server-end-point should usually be easily implementable and is probably better than performing no channel binding at all
-
flow
larma, ^
-
flow
also why no cb type agility? if something the past has shown is that cb types are not easy to get right
-
Zash
flow, funny tho that in Prosody, tls-unique is already implemented and my attempts at tls-server-end-point is stalled by not having access to the needed info
-
larma
flow: according to scram rfc, tls-unique is the default and must be implemented by servers. So as client, it's safe to use it even without further negotiation.
-
flow
larma, unfortunately, I think, the reality is different
-
flow
larma, that is, chances are higher that you find tls-server-end-point than tls-unique
-
flow
Zash, isn't tls-server-end-point just the hash of the certificate?
-
Zash
flow, go read the rules for what hash algorithm to use, then try to implementing it given only an opaque binary blob
-
flow
wheras tls-unique requires you to get the tls finial message, which is often not exposed (as raw bytes) by TLS APIs
-
Zash
I would be happy if TLS libs could have an API to tell what channel bindings are supported and then return the data for those by channel binding name.
-
larma
flow: so you are saying servers in practice are not rfc compliant?
-
flow
Zash, IIRC the rules just say "use whatever the cert uses as hash algorithm, unless if it is MD5 or SHA-1, in this case use SHA-256"
-
Zash
It's exposed by OpenSSL and LuaSec.
-
flow
larma, yep, there is always a discrepancy between whoe specifications writers wish the world would be, and how the world actually is
-
Zash
The hash algorithm of a certificate is not exposed however.
-
flow
Zash, it being the tls finished message?
-
Zash
Yes.
-
Zash
Interestingly it also does this for TLS 1.3
-
Zash
I have some WIP somewhere that just always uses SHA-256, and since that's what all certificates use it'll probably work until the day someone gets a SHA-512 or SHA-3 certificate.
-
flow
Zash, don't you have another way to get a hold of the whole certificate, as far as I understand it, the hash algorithm used is noted there
-
Zash
are you telling me to implement another ASN.1 parser?
-
flow
anyway, last time I checked the situation in java land was the opposite: you can not get the tls finish message, but doing tls-server-endpoint is easy
-
Zash
I'd very much rather not.
-
flow
(with the standard Java SE API)
-
Daniel
Agility if it can be achieved with reasonable Syntax (and I like flows proposal in that regard) should be preferred to convention
-
Daniel
Yes in Java Standard api that's correct
-
Daniel
That's why I never implemented it
-
Zash
Sure, that'd be good. (why data in attributes tho?)
-
flow
Zash, data in attributes?
-
Daniel
Conscrypt does support unique. But then came tls1.3
-
Daniel
Zash: flows. Not Marvin's
-
Zash
flow, `<cb name='tls-unique'/>` instead of `<cb>tls-unique</cb>`, but this is a nit
-
Zash
Daniel, ?
-
flow
Zash, right, I actually think the latter should be considered an anti-pattern when designing xmpp wire protocol
-
flow
because <cb name=""/> alows us to extend <cb/> with child elements if that ever becomes necessary
-
Zash
No, that's the opposite of what it is
-
Daniel
Ah. Sorry. I was confused
-
Daniel
Yeah I don't care
-
Zash
In general data should go in text nodes and metadata in attributes.
-
flow
so this was a deliberate design choice, and I think pattern to list something as cdata in elements should be avoided
-
flow
Zash, because?
-
Zash
Because.
-
Zash
General XMPP or XML design advice that I don't remember the exact location of
-
flow
well I think keeping the door open to child element based extensibility is a better argument than some handwaving rule ;)
-
flow
that design advice *may* is sensible if you allow mixed content, but we do not allow mixed content
-
Zash
Also because `stanza:get_child_text()` in Prosody is the best API ever :)
-
flow
Zash, I am sure your get_attribute_value() API is of similar quality ;)
-
Zash
There's no such thing.
-
flow
because it's a map (or table?)✎ -
flow
because it's a map (or table?)? ✏
-
Zash
yes
-
larma
If it was <mechanism name='SCRAM-SHA-1-PLUS' /> we could do <mechanism name='SCRAM-SHA-1-PLUS'><cb type='tls-unique' /></mechanism> now, so I'm totally on flows side to prefer attributes for extensibility
-
Zash
Then why isn't it like that in SASL2?
-
larma
If it's not clear that extensibility is not needed of course.
-
flow
larma, yep, that is the point. but i really like to stress that there is no reason to list cb types per sasl mechanism, and that this is also verly likely to be true in the future
-
flow
Zash, good point, guess someone would need to convince dave to change it
-
Zash
<mechanisms> <mechanism> <name>PLAIN</name> <channel-bindings> <channel-binding> <name>tls-unique</name> </////>
-
flow
using a <name/> element has the drawback that there could be multiple, whereas there can only be one attribute with the name 'name'
-
Zash
You can't extend attributes either tho.
-
flow
right, but I can extend the element they are declared at
-
larma
flow: well I agree that cb is unlikely to be specific to a single mechanism, on the other hand, one typically also doesn't support multiple mechanisms with channel binding either. And the supported cb are clearly related to that mechanism and not related to all of them.
-
flow
larma, wait, one typically also does not support multiple mechanisms with channel binding either? I'd assume quite the contrary to be the case, given that SCRAM-SHA-256 starts to gain popularity
-
flow
the server presents you with a list of sasl mechanism currently. my propsal adds another list with supported cb types alongside the sasl mechanism list. the client is free to choose the combination he deems to be best
-
larma
Well, a server that supports SCRAM-SHA-256 is not better in any regard if it also supports SCRAM-SHA-1
-
flow
I am not sure if this is true. you are probably hinting towards that the server also has to store the auth data using the weaker hash
-
larma
Yes.
-
Zash
If you see a Prosody offering both then it is most likely storing the password in plain text.
-
Zash
Or someone implemented a way to store two credentials without me knowing
-
flow
I think there are lot of cases where the password is stored in plain text server side, but does that mean that those servers should continue to offer only scram sha-1 for eternity?
-
flow
larma, I see, of course, your point. but this is not an argument to closely couple the sasl mechanisms and the cb types in the sasl mechanism stream feature
-
Zash
currently it's a matter of whether the sasl mechanism supports gss-api, or somesuch.
-
flow
Zash, please clarify 'it'? I'd assume that every -PLUS mechanism supports gss-api (or maybe I confuse gss-api with something different)?
-
larma
flow: it's scram that supports gssapi, no?
-
Zash
SCRAM supports GSS-API. GSS-API supports channel bindings.
-
Zash
Or something like that.
-
flow
IIRC I did gss-api stuff when implementing the -PLUS variants of scram
-
Zash
Point is that there's some indirection.
-
flow
yes, the whole existence of -PLUS is a design weakness
-
larma
And -PLUS is just a dirty hack to announce that the server supports cb
-
flow
not sure if it was because channel binding came after SASL was initialy invented
-
flow
if the RFC SASL profile would also allow for a list of supported cb types, alongside the list of supported sasl mechanisms, then gss-api would be sufficient to negotiate cb
-
Zash
Redefine PLUS to mean `tls-unique`? Invent a new SCRAM-SHA-256-PLSCRT for tls-server-endpoint? :D
-
Zash
Wait that's basically what Sam proposed
-
Zash
Almost.
-
larma
Given that `tls-unique` is a MUST on servers that do -PLUS and SHOULD on clients, it's not even incompatible to define -PLUS = `tls-unique` ;)
-
Zash
Mmmmmm `SCRAM-SHA-256-DOUBLEPLUS`
-
Zash
Except it's too long
-
larma
I like -PLUSPLUS more :D
-
Zash
SCRAM-SHA-2-PLUSPLUS is 20 chars
-
larma
Or maybe we just should stop with -PLUS, because if we announce cb types anyway, we don't need -PLUS anymore
-
Zash
True