XSF Discussion - 2020-05-10

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 ✏

Deriving intent from the schema?

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

or if a certain element or attribute is required

That seems fine to me. Isn't it primarily when the text and the schema disagree that the text takes priority? Like with examples.

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

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...

i didn’t read the whole thread (just the initial xep proposal) but i like that solution

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 ✏

flow, I thought it wasn't properly defined which type to use and that is an issue, isn't it?

larma, no, the issue is that you do not know which cb types the remote endpoint supports

-PLUS just signalls that cb is used, but not which cb type

all currently registered cb types with IANA are currently available for all -PLUS sasl mechanisms

and tls-server-end-point should be (basically) always available

but tls-unique may not

so if a client tries to do -PLUS with tls-unique, then things get a bit ugly

My understanding is that PLUS being advertised means channel binding is supported, and then negotiated in a header in a header in SCRAM.

Zash, yes, but the server has no way to signal the supported cb types to the client

IIRC there is no negotiation in gss api

Yes

the client just says, I do cb type x and hopes the server supports x ✏

Right, which is weird and why it's good to try to solve that.

correct, and I think my proposal solves that in a neat and clean way

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)

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

larma, ^

also why no cb type agility? if something the past has shown is that cb types are not easy to get right

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

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.

larma, unfortunately, I think, the reality is different

larma, that is, chances are higher that you find tls-server-end-point than tls-unique

Zash, isn't tls-server-end-point just the hash of the certificate?

flow, go read the rules for what hash algorithm to use, then try to implementing it given only an opaque binary blob

wheras tls-unique requires you to get the tls finial message, which is often not exposed (as raw bytes) by TLS APIs

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.

flow: so you are saying servers in practice are not rfc compliant?

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"

It's exposed by OpenSSL and LuaSec.

larma, yep, there is always a discrepancy between whoe specifications writers wish the world would be, and how the world actually is

The hash algorithm of a certificate is not exposed however.

Zash, it being the tls finished message?

Yes.

Interestingly it also does this for TLS 1.3

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.

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

are you telling me to implement another ASN.1 parser?

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

I'd very much rather not.

(with the standard Java SE API)

Agility if it can be achieved with reasonable Syntax (and I like flows proposal in that regard) should be preferred to convention

Yes in Java Standard api that's correct

That's why I never implemented it

Sure, that'd be good. (why data in attributes tho?)

Zash, data in attributes?

Conscrypt does support unique. But then came tls1.3

Zash: flows. Not Marvin's

flow, `<cb name='tls-unique'/>` instead of `<cb>tls-unique</cb>`, but this is a nit

Daniel, ?

Zash, right, I actually think the latter should be considered an anti-pattern when designing xmpp wire protocol

because <cb name=""/> alows us to extend <cb/> with child elements if that ever becomes necessary

No, that's the opposite of what it is

Ah. Sorry. I was confused

Yeah I don't care

In general data should go in text nodes and metadata in attributes.

so this was a deliberate design choice, and I think pattern to list something as cdata in elements should be avoided

Zash, because?

Because.

General XMPP or XML design advice that I don't remember the exact location of

well I think keeping the door open to child element based extensibility is a better argument than some handwaving rule ;)

that design advice *may* is sensible if you allow mixed content, but we do not allow mixed content

Also because `stanza:get_child_text()` in Prosody is the best API ever :)

Zash, I am sure your get_attribute_value() API is of similar quality ;)

There's no such thing.

because it's a map (or table?)? ✏

yes

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

Then why isn't it like that in SASL2?

If it's not clear that extensibility is not needed of course.

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

Zash, good point, guess someone would need to convince dave to change it

<mechanisms> <mechanism> <name>PLAIN</name> <channel-bindings> <channel-binding> <name>tls-unique</name> </////>

using a <name/> element has the drawback that there could be multiple, whereas there can only be one attribute with the name 'name'

You can't extend attributes either tho.

right, but I can extend the element they are declared at

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.

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

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

Well, a server that supports SCRAM-SHA-256 is not better in any regard if it also supports SCRAM-SHA-1

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

Yes.

If you see a Prosody offering both then it is most likely storing the password in plain text.

Or someone implemented a way to store two credentials without me knowing

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?

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

currently it's a matter of whether the sasl mechanism supports gss-api, or somesuch.

Zash, please clarify 'it'? I'd assume that every -PLUS mechanism supports gss-api (or maybe I confuse gss-api with something different)?

flow: it's scram that supports gssapi, no?

SCRAM supports GSS-API. GSS-API supports channel bindings.

Or something like that.

IIRC I did gss-api stuff when implementing the -PLUS variants of scram

Point is that there's some indirection.

yes, the whole existence of -PLUS is a design weakness

And -PLUS is just a dirty hack to announce that the server supports cb

not sure if it was because channel binding came after SASL was initialy invented

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

Redefine PLUS to mean `tls-unique`? Invent a new SCRAM-SHA-256-PLSCRT for tls-server-endpoint? :D

Wait that's basically what Sam proposed

Almost.

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` ;)

Mmmmmm `SCRAM-SHA-256-DOUBLEPLUS`

Except it's too long

I like -PLUSPLUS more :D

SCRAM-SHA-2-PLUSPLUS is 20 chars

Or maybe we just should stop with -PLUS, because if we announce cb types anyway, we don't need -PLUS anymore

True