XSF Discussion - 2020-05-09

I am not sure but SCRAM-SHA-256(-PLUS) is prefered than SCRAM-SHA-1(-PLUS) no? -> https://xmpp.org/extensions/xep-0438.html

RFC 8600 is not listed -> https://tools.ietf.org/html/rfc8600 "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802])"

-> https://github.com/xsf/xeps/issues/944

Neustradamus_, I'm not sure you understand what you just changed. All the SCRAM-*-PLUS are on the same level, they have the same priority

Also github is not the venue to discuss specifications

The RFC8600 thing seems like a valid concern though (not for me to judge, I'm no crypto-specialist). You should raise this on the standards list

pep.: Thanks for your reply

Prefered is not same

-> "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802])"

I'm sorry I don't understand what you're trying to say

(and I'm also not the one to be convinced by the way)

SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1

I invite you to raise this issue on the standards list then if you think it's important.

I'm going to close the github issue you opened though as it's not what we use github for

pep.: no no no

no?

It is important to keep open, the problem is not solved.

This is not the place to open it

The place is the standards mailing list

I think you can close all opened issues

Look here: https://github.com/xsf/xeps/issues

No, opened issues are editorial issues, not issues about standards

That is, something not being properly displayed, or broken links etc.

Is that ok?

There is an editorial problem here

No there isn't.

You're trying to change the meaning of a standard

Again if you want this to change, it may be a very valid concern, we have processes in place (sometimes annoying I give you that, but there are there nonetheless for reasons)

Are you fine with me closing the issue now? :)

No.

Well I'm sorry I tried the peaceful way.. but I'm going to close it anyway

If it happens I'm wrong I am very sorry but I really don't think this is an editorial issue.

A ticket is here for a trace, we do not close a not solved ticket...

So if you open a ticket on my XMPP client tracker saying "There is hunger in the world", should I keep it open forever?

Even if it's unrelated

(well somewhat..)

Does this make sense?

Github is not the place for this.

Period.

I can create a new ticket to explain missing RFC 8600 in XEP-0438 :) ✏

If you want to change standards, send an email to the standards list, please.

Please re-add the tracker.xmpp.org ^^

Raise that to board if that's an issue for you, I'll be happy to raise it

(Unfortunately I have an idea of the answer)

We will see the return of stpeter about it.

I know that some people think that SCRAM-SHA-256(-PLUS) is not needed.

I hope you understand this is not what I am discussing here

It is the official XSF MUC Room :) Maybe we must talk on jdev?

That is not what I mean

I'll do it in french quickly: Le fait que SCRAM-SHA-256* soit important ou pas n'est pas la question pour moi ici. La question c'est que Github n'est pas un endroit où on souhaite avoir des discussions concernant les spécifications. Les discussions sur le tracker sont uniquement déstinées à la forme (formattage, liens cassés, etc.). Les discussions sur les spécifications se passent sur la liste « standards »

(And that's it for baguette)

And I'm going to sleep now :x night

Fwiw the benefits PLUS offers definitely outweigh the downsides of Sha1 over over sha2

I have the same feeling, but that it's crypto territory, so I'd really like if someone could provide some arguments in either direction ;)

I can 't find anything in my notes, but wasn't there something like tls-server-end-point being broken (or "broken")? it's been a loooong time since I looked deeply into the various channel binding types and TLS.

hmm sam writes that tls-server-end-point is not specified(/avaialble?) in TLS 1.3? I'd assume that is the cb type that would always work, since IIRC it's simply the hash of the server certificate ✏

The TLS 1.3 RFC says in an appendix that channel bindings are not defined.

In a (oh btw those aren't defined), in the cellar behind a locked door marked "beware the otter"

Zash, thanks. But does this mean it is impossible for technical reasons to use tls-server-end-point with TLS 1.3?

The only reason I know of is the parenthesis in https://tools.ietf.org/html/rfc8446#appendix-C.5

Zash: maybe but software can add it

I will show you examples

flow: the main implementation issue for me is that you need to know the signature algorithm used in the cert and I don't know it because all I have is a cert object with very limited introspection

tho 99% of the time it'll be SHA-256, so you could just guess that

because of how anything less than that should use SHA-256, but if someone somewhere has a cert with SHA-512 signatures then it'll break

and according to OpenSSL tls-unique works just fine in TLS 1.3 and I hadn't even noticed that it wasn't supposed to

A lot of RFC has been done before TLS 1.3 but it is not a problem to add support.

Example: http://w1.fi/cgit/hostap/plain/hostapd/ChangeLog - added experimental support for EAP-TLS server with TLS v1.3 EAP-TLS in not normally with TLS v1.3.

Daniel, Ge0rG, I sent the announcement for the sprint just now and you’re welcome to join in :) ✏

jonas’, do you have a *huge* whiteboard?

Zash, I hear there are online whiteboard things

I think they even have "infinite" scroll :)

on .. line? but I want 2d, not 1d! :P

infinite zoom too?

not sure

A Turing board?

if only we had networked Inkscape already :)

jonas’: thanks, I'll look into it

Yeah, that, be great, eh, Link Mauve?

flow, > Actually the schema is irrelevant when it comes to RFC compliance. Schemas are non-normative. This is explicitly noted in the RFC. true, but the fact that this is described explicitly in the non-normative part thus very much clarifies that the lack of explicit prohibition is intentional and not by accident. Thus it's still relevant, even if non-normative. After all, the non-normative part isn't there just for fun. That's one thing I learned in law classes 😉

good that you two agree (I read flows email saying essentially the same)

Do any other protocols do TLS channel binding?

Zash, if only I didn’t lose an important part of it from svn being terrible.

I’m not done rewriting it yet. :/

moparisthebest: Yes. Probably LDAP and protocols like that.

moparisthebest: But HTTPS doesn't so who cares, right?

Pretty much yes :)

People: XMPP is too complicated XSF: hold my beer *writes more complicated authentication mechanisms with no real benefit*

I'd feel real special if the IETF & co invented channel bindings just for us :)

As if HTTP was simple

That’s a lie people can tell themselves because of widespread library support for their *simple* usecases.

It's so simple you just GET and POST and wait what's this section about caching and content negotiation?

Hello

Hi