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✎✏
debaclehas joined
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?
krauqhas joined
krauqhas left
krauqhas joined
Shellhas joined
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
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
waqashas left
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.
stpeterhas left
Jeybehas left
Jeybehas joined
sonnyhas left
sonnyhas joined
Mikaelahas joined
lorddavidiiihas left
lorddavidiiihas joined
Shellhas left
Shellhas joined
mukt2has left
Shellhas left
Shellhas joined
debaclehas left
debaclehas joined
debaclehas left
debaclehas joined
LNJhas joined
LNJhas left
archas left
LNJhas joined
archas joined
lovetoxhas left
werdanhas joined
lovetoxhas joined
werdanhas left
lovetoxhas left
debaclehas left
debaclehas joined
Shellhas left
Shellhas joined
APachhas left
APachhas joined
Shellhas left
Shellhas joined
emushas joined
mukt2has joined
vanitasvitaehas left
vanitasvitaehas joined
lovetoxhas joined
Yagizahas joined
mimi89999has left
mimi89999has joined
Steve Killehas left
lovetoxhas left
Shellhas left
Shellhas joined
Steve Killehas joined
mukt2has left
mukt2has joined
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
debaclehas left
debaclehas joined
debaclehas left
jonas’has left
sonnyhas left
jonas’has joined
sonnyhas joined
jonas’has left
jonas’has joined
debaclehas joined
j.rhas left
j.rhas joined
adiaholic_has left
adiaholic_has joined
debaclehas left
debaclehas joined
jonas’has left
jonas’has joined
jonas’has left
jonas’has joined
stpeterhas joined
jonas’has left
jonas’has joined
karoshihas joined
Danielhas left
!XSF_Martinhas left
Danielhas joined
!XSF_Martinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
stpeterhas left
jonas’has left
jonas’has joined
mukt2has left
mukt2has joined
Marandahas left
Marandahas joined
Marandahas left
Marandahas joined
karoshihas left
karoshihas joined
Zashhas left
sonnyhas left
sonnyhas joined
LNJhas left
Zashhas joined
adiaholic_has left
adiaholic_has joined
chynahas joined
Shellhas left
mukt2has left
sonnyhas left
sonnyhas joined
Jeybehas left
Shellhas joined
rionhas joined
karoshihas left
karoshihas joined
mukt2has joined
Jeybehas joined
debaclehas left
sonnyhas left
mukt2has left
sonnyhas joined
mukt2has joined
stpeterhas joined
sonnyhas left
sonnyhas joined
Dele Olajidehas joined
pdurbinhas left
Dele Olajidehas left
Dele Olajidehas joined
krauqhas left
krauqhas joined
stpeterhas left
mukt2has left
mukt2has joined
sonnyhas left
sonnyhas joined
jonas’has left
jonas’has joined
sonnyhas left
sonnyhas joined
Maxhas left
DebXWoodyhas left
Maxhas joined
Yagizahas left
jonas’has left
jonas’has joined
mukt2has left
j.rhas left
j.rhas joined
karoshihas left
mukt2has joined
adiaholic_has left
karoshihas joined
adiaholic_has joined
Jeybehas left
Maxhas left
jonas’has left
jonas’has joined
Maxhas joined
mukt2has left
lovetoxhas joined
Yagizahas joined
stpeterhas joined
pdurbinhas joined
Maxhas left
pdurbinhas left
stpeterhas left
DebXWoodyhas joined
nycohas left
nycohas joined
DebXWoodyhas left
Shellhas left
robertooohas left
robertooohas joined
mukt2has joined
karoshihas left
karoshihas joined
Nekithas left
Dele Olajidehas left
mukt2has left
mukt2has joined
lovetoxhas left
calvinhas joined
eevvoorhas left
Zashhas left
Zashhas joined
calvinhas left
calvinhas joined
chynahas left
davidhas left
davidhas joined
adiaholic_has left
adiaholic_has joined
j.rhas left
j.rhas joined
Jeybehas joined
Jeybehas left
Jeybehas joined
pdurbinhas joined
stpeterhas joined
calvinhas left
pdurbinhas left
calvinhas joined
stpeterhas left
Kevhas joined
Neustradamushas left
Neustradamus_has left
LNJhas joined
Neustradamushas joined
Neustradamus_has joined
debaclehas joined
calvinhas left
DebXWoodyhas joined
Jeybehas left
Jeybehas joined
calvinhas joined
mukt2has left
archas left
archas joined
sonnyhas left
sonnyhas joined
emushas left
emushas joined
adiaholic_has left
adiaholic_has joined
werdanhas joined
chynahas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
mukt2has joined
lovetoxhas joined
karoshihas left
karoshihas joined
adiaholic_has left
calvinhas left
j.rhas left
j.rhas joined
Jeybehas left
Jeybehas joined
adiaholic_has joined
pdurbinhas joined
stpeterhas joined
pdurbinhas left
stpeterhas left
govanifyhas left
govanifyhas joined
karoshihas left
karoshihas joined
adiaholic_has left
adiaholic_has joined
Nekithas joined
xsfhas joined
lorddavidiiihas left
lovetoxhas left
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✎
andrey.ghas left
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 ✏
moparisthebesthas joined
Shellhas joined
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
karoshihas left
karoshihas joined
calvinhas joined
lovetoxhas joined
archas left
archas joined
calvinhas left
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)
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
calvinhas joined
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.
stpeterhas joined
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
goffihas left
flow
wheras tls-unique requires you to get the tls finial message, which is often not exposed (as raw bytes) by TLS APIs
waqashas joined
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
calvinhas left
calvinhas joined
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
mukt2has left
flow
well I think keeping the door open to child element based extensibility is a better argument than some handwaving rule ;)
stpeterhas left
mukt2has joined
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 :)
DebXWoodyhas left
flow
Zash, I am sure your get_attribute_value() API is of similar quality ;)
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?
adiaholic_has left
adiaholic_has joined
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
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
moparisthebesthas left
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?
Yagizahas left
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)?
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.
lovetoxhas left
archas left
archas joined
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
bearhas left
Tobiashas left
larma
Or maybe we just should stop with -PLUS, because if we announce cb types anyway, we don't need -PLUS anymore