XSF Discussion - 2020-05-10

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

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

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

  4. Zash

    Deriving intent from the schema?

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

  6. flow

    or if a certain element or attribute is required

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

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

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

  10. Daniel

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

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

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

  13. larma

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

  14. flow

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

  15. flow

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

  16. flow

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

  17. flow

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

  18. flow

    but tls-unique may not

  19. flow

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

  20. Zash

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

  21. flow

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

  22. flow

    IIRC there is no negotiation in gss api

  23. Zash


  24. flow

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

  25. flow

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

  26. Zash

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

  27. flow

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

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

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

  30. flow

    larma, ^

  31. flow

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

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

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

  34. flow

    larma, unfortunately, I think, the reality is different

  35. flow

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

  36. flow

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

  37. Zash

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

  38. flow

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

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

  40. larma

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

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

  42. Zash

    It's exposed by OpenSSL and LuaSec.

  43. flow

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

  44. Zash

    The hash algorithm of a certificate is not exposed however.

  45. flow

    Zash, it being the tls finished message?

  46. Zash


  47. Zash

    Interestingly it also does this for TLS 1.3

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

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

  50. Zash

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

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

  52. Zash

    I'd very much rather not.

  53. flow

    (with the standard Java SE API)

  54. Daniel

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

  55. Daniel

    Yes in Java Standard api that's correct

  56. Daniel

    That's why I never implemented it

  57. Zash

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

  58. flow

    Zash, data in attributes?

  59. Daniel

    Conscrypt does support unique. But then came tls1.3

  60. Daniel

    Zash: flows. Not Marvin's

  61. Zash

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

  62. Zash

    Daniel, ?

  63. flow

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

  64. flow

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

  65. Zash

    No, that's the opposite of what it is

  66. Daniel

    Ah. Sorry. I was confused

  67. Daniel

    Yeah I don't care

  68. Zash

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

  69. flow

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

  70. flow

    Zash, because?

  71. Zash


  72. Zash

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

  73. flow

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

  74. flow

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

  75. Zash

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

  76. flow

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

  77. Zash

    There's no such thing.

  78. flow

    because it's a map (or table?)

  79. flow

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

  80. Zash


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

  82. Zash

    Then why isn't it like that in SASL2?

  83. larma

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

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

  85. flow

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

  86. Zash

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

  87. flow

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

  88. Zash

    You can't extend attributes either tho.

  89. flow

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

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

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

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

  93. larma

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

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

  95. larma


  96. Zash

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

  97. Zash

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

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

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

  100. Zash

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

  101. flow

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

  102. larma

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

  103. Zash

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

  104. Zash

    Or something like that.

  105. flow

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

  106. Zash

    Point is that there's some indirection.

  107. flow

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

  108. larma

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

  109. flow

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

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

  111. Zash

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

  112. Zash

    Wait that's basically what Sam proposed

  113. Zash


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

  115. Zash


  116. Zash

    Except it's too long

  117. larma

    I like -PLUSPLUS more :D

  118. Zash

    SCRAM-SHA-2-PLUSPLUS is 20 chars

  119. larma

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

  120. Zash