[Standards] Re: XEP-0440 and tls-server-end-point

[Dave Cridland]

On Tue, 30 Jan 2024 at 10:11, Florian Schmaus  wrote:

> If we are not positive about it, then why should be push implementations
> into non-compliance by mandating it, when we simply could (strongly)
> recommend it?


Exactly this - interoperability should be a pragmatically achievable goal.
Security should be as high as possible without disrupting that goal,
because if it's disrupted then people will just use something else that
actually works, and the additional requirements have achieved nothing.

Given this, tls-server-end-point seems like it ought to be baseline - it's
relatively easy to implement anywhere, and while it has weaknesses, it's
still a lot better than nothing.

So that says, to me, text along the lines of "MUST implement".

tls-exporter is clearly superior, so we want to encourage that, but accept
there are lots of cases where that's not practical, so "SHOULD implement".

Finally, we know that in some deployments, there is enough control of
clients and other deployment aspects that there's no practical benefit to
supporting the weaker tls-server-end-point, so we might want to indicate
that while deployment in the general case is "strongly advised" (I'm
side-stepping RFC 2119 here), if a particular deployment can remove it
that's actually better security.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Florian Schmaus]

On 11/01/2024 14.03, Simon Josefsson wrote:

tor 2024-01-11 klockan 13:48 +0100 skrev Florian Schmaus:

Hi Simon,

thanks for your mail.

On 11/01/2024 13.39, Holger Weiß wrote:

* Simon Josefsson  [2024-01-11 13:10]:

I believe tls-server-end-point is generally best left
unimplemented to
guide efforts towards supporting the stronger tls-exporter.


One use case I see for tls-server-end-point is that it allows for
supporting channel binding by setups where TLS is terminated by
some
reverse proxy, thereby protecting against _some_ but not all attack
vectors that tls-exporter protects against.


Additionally, implementing tls-server-end-point demands minimal
effort
since it is just based on the hash of the certificate. I believe that
not making it mandatory won't deter anyone who is inclined to
implement
it, as it is a low hanging fruit.

Furthermore, we hope to achieve a high success rate by making it
mandatory to implement for servers.

You are correct, one should aim for better altnatives than
tls-server-end-point when implementing XEP-0440, and this should be
explicitly mentioned in the XEP. As it stands, the XEP does not
clearly
convey this. I intend to propose a revision to rectify this in the
near
future.


Thanks Florian.  Extracting the correct certificate from the TLS
library, hashing it using the right algorithm, and getting that into a
SCRAM library that support tls-server-end-point may be as easy or
challenging as support for tls-exporter.  So I'm not as convinced tls-
server-end-point is minimal effort.


It's a few lines of code in Java to extract the channel-binding data for 
tls-server-end-point from a SSLSession using only API from Java's 
runtime library [1].


The situation is vastly different for tls-exporter. Last time I've 
checked, there was no API in the Java's runtime library to retrieve the 
tls-exporter. So you have to resort to third party libraries, which 
increases your code complexity (it's usually nicer if you can just rely 
on the API of the standard library of your programming language's ecosystem.


In my experience you find APIs to retrieve the tls-server-end-point data 
pretty easily. Getting the tls-exporter data can be tricky. It can even 
be impossible, I believe, though the situation may has improved over the 
last years.




What do you think about a compromise to mandate support for both tls-
server-end-point and tls-exporter?  I'd prefer only tls-exporter
though.


Mandating tls-exporter gets you nothing if people can not implement it. 
I think this is fallacy many standards organizations fall for. We also 
have to look at the software ecosystem and its capabilities.


Are you positive that it is sufficiently easy to retrieve tls-exporter 
data from a TLS session in all ecosystems of "relevant" programming 
languages?


If we are not positive about it, then why should be push implementations 
into non-compliance by mandating it, when we simply could (strongly) 
recommend it?


- Flow


1: 
https://github.com/igniterealtime/Smack/blob/e504bc23cfe601e4e414aac1aff54c8f3d69c67f/smack-core/src/main/java/org/jivesoftware/smack/util/TLSUtils.java#L197


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Travis Burtrum]

On 1/11/24 10:37, Dave Cridland wrote:



On Thu, 11 Jan 2024 at 12:39, Holger Weiß > wrote:


* Simon Josefsson mailto:si...@josefsson.org>>
[2024-01-11 13:10]:
 >I believe tls-server-end-point is generally best left unimplemented to
 >guide efforts towards supporting the stronger tls-exporter.

One use case I see for tls-server-end-point is that it allows for
supporting channel binding by setups where TLS is terminated by some
reverse proxy, thereby protecting against _some_ but not all attack
vectors that tls-exporter protects against.


I'm pretty sure this was a key reason we picked the approach. If TLS is 
terminated before the server ever sees it, the server can still be 
configured to handle tls-server-end-point.


Also the TLS terminating proxy can pass the required secrets for "real 
channel binding" to the backend XMPP server via extensions to the PROXY 
protocol.  I plan on adding support for this to xmpp-proxy soon.


___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Dave Cridland]

On Thu, 11 Jan 2024 at 12:39, Holger Weiß  wrote:

> * Simon Josefsson  [2024-01-11 13:10]:
> >I believe tls-server-end-point is generally best left unimplemented to
> >guide efforts towards supporting the stronger tls-exporter.
>
> One use case I see for tls-server-end-point is that it allows for
> supporting channel binding by setups where TLS is terminated by some
> reverse proxy, thereby protecting against _some_ but not all attack
> vectors that tls-exporter protects against.


I'm pretty sure this was a key reason we picked the approach. If TLS is
terminated before the server ever sees it, the server can still be
configured to handle tls-server-end-point.

It's not, of course, really channel binding - it's not binding to the
channel itself at all - but it does give some of the protection real
channel binding would.

Dave.
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Martin Dosch]

Dear all,

coincidentally I was implementing `tls-server-end-point` channel binding 
for go-sendxmpp this morning. As a client can choose the method to use I 
don't see an issue here.
I just prefer `tls-exporter` if TLSv1.3 is used and `tls-unique` 
otherwise and only use `tls-server-end-point` when it's the only method 
offered.
As Holger and Andrzej pointed out there might be cases where the better 
methods are not available and using a weaker one is still better than no 
channel binding at all.


Best regards,
Martin


signature.asc
Description: PGP signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Simon Josefsson]

tor 2024-01-11 klockan 13:48 +0100 skrev Florian Schmaus:
> Hi Simon,
> 
> thanks for your mail.
> 
> On 11/01/2024 13.39, Holger Weiß wrote:
> > * Simon Josefsson  [2024-01-11 13:10]:
> > > I believe tls-server-end-point is generally best left
> > > unimplemented to
> > > guide efforts towards supporting the stronger tls-exporter.
> > 
> > One use case I see for tls-server-end-point is that it allows for 
> > supporting channel binding by setups where TLS is terminated by
> > some 
> > reverse proxy, thereby protecting against _some_ but not all attack
> > vectors that tls-exporter protects against.
> 
> Additionally, implementing tls-server-end-point demands minimal
> effort 
> since it is just based on the hash of the certificate. I believe that
> not making it mandatory won't deter anyone who is inclined to
> implement 
> it, as it is a low hanging fruit.
> 
> Furthermore, we hope to achieve a high success rate by making it 
> mandatory to implement for servers.
> 
> You are correct, one should aim for better altnatives than 
> tls-server-end-point when implementing XEP-0440, and this should be 
> explicitly mentioned in the XEP. As it stands, the XEP does not
> clearly 
> convey this. I intend to propose a revision to rectify this in the
> near 
> future.

Thanks Florian.  Extracting the correct certificate from the TLS
library, hashing it using the right algorithm, and getting that into a
SCRAM library that support tls-server-end-point may be as easy or
challenging as support for tls-exporter.  So I'm not as convinced tls-
server-end-point is minimal effort.

Remember, tls-server-end-point has pretty detailed requirement of which
certificate in the chain to hash, and what hash algorithm to use that
is not future proof.  The simplicity of this depends on the TLS and
SASL/SCRAM library that are used.  For modern libraries, I believe that
tls-exporter should be easier and more efficient than tls-server-end-
point.  RFC 5929 on tls-server-end-point:

   The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message.  Note
   that the Certificate message contains a certificate_list, in which
   the first element is the server's certificate.

   The hash function is to be selected as follows:

   o  if the certificate's signatureAlgorithm uses a single hash
  function, and that hash function is either MD5 [RFC1321] or SHA-1
  [RFC3174], then use SHA-256 [FIPS-180-3];

   o  if the certificate's signatureAlgorithm uses a single hash
  function and that hash function neither MD5 nor SHA-1, then use
  the hash function associated with the certificate's
  signatureAlgorithm;

   o  if the certificate's signatureAlgorithm uses no hash functions or
  uses multiple hash functions, then this channel binding type's
  channel bindings are undefined at this time (updates to is
  channel binding type may occur to address this issue if it ever
  arises).

What do you think about a compromise to mandate support for both tls-
server-end-point and tls-exporter?  I'd prefer only tls-exporter
though.

/Simon



signature.asc
Description: This is a digitally signed message part
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Matthew Wild]

On Thu, 11 Jan 2024 at 12:49, Simon Josefsson  wrote:
>
> tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
> > * Simon Josefsson  [2024-01-11 13:10]:
> > > I believe tls-server-end-point is generally best left unimplemented
> > > to
> > > guide efforts towards supporting the stronger tls-exporter.
> >
> > One use case I see for tls-server-end-point is that it allows for
> > supporting channel binding by setups where TLS is terminated by some
> > reverse proxy, thereby protecting against _some_ but not all attack
> > vectors that tls-exporter protects against.
>
> Indeed -- however I think the burden to support those kind of
> environments should be on the entities chosing to deploy and use those
> kind of environments, instead of placing the burden (and weakening
> security) for everyone else.
>
> While I think it is acceptable for standards to acknowledge and allow
> insecure usage modes (with proper caveats), I believe the primary
> purpose and default recommendations for a standard should be to promote
> secure behaviour.  That is not achieved in XEP-0440 now.
>
> A compromise would be to mandate both tls-exporter and tls-server-end-
> point, however I'm hoping the short period that tls-server-end-point
> has been mandated can be ignored and we can select a better mandatory
> method.

Thankfully I think all server implementations took sensible routes
already (i.e. everyone who supports channel binding has tls-exporter
implemented, in current or current+1 releases). Prosody will
automatically offer tls-unique/tls-exporter, and tls-server-end-point
by default unless explicitly configured by the admin.

I think the logic for the wording in the XEP was because some
deployments cannot (easily) use the algorithms with dynamic values, so
tls-server-end-point is seen as the lowest common denominator, and
recommended from an interoperability perspective (some channel binding
is better than none at all).

However I think that the difficulties deploying
tls-unique/tls-exporter that exist today could be overcome with
sufficient support from TLS middleware. I'm not aware of any such
support right now though.

Regards,
Matthew
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Simon Josefsson]

tor 2024-01-11 klockan 13:39 +0100 skrev Holger Weiß:
> * Simon Josefsson  [2024-01-11 13:10]:
> > I believe tls-server-end-point is generally best left unimplemented
> > to
> > guide efforts towards supporting the stronger tls-exporter.
> 
> One use case I see for tls-server-end-point is that it allows for 
> supporting channel binding by setups where TLS is terminated by some 
> reverse proxy, thereby protecting against _some_ but not all attack 
> vectors that tls-exporter protects against.

Indeed -- however I think the burden to support those kind of
environments should be on the entities chosing to deploy and use those
kind of environments, instead of placing the burden (and weakening
security) for everyone else.

While I think it is acceptable for standards to acknowledge and allow
insecure usage modes (with proper caveats), I believe the primary
purpose and default recommendations for a standard should be to promote
secure behaviour.  That is not achieved in XEP-0440 now.

A compromise would be to mandate both tls-exporter and tls-server-end-
point, however I'm hoping the short period that tls-server-end-point
has been mandated can be ignored and we can select a better mandatory
method.

/Simon



signature.asc
Description: This is a digitally signed message part
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Florian Schmaus]

Hi Simon,

thanks for your mail.

On 11/01/2024 13.39, Holger Weiß wrote:

* Simon Josefsson  [2024-01-11 13:10]:

I believe tls-server-end-point is generally best left unimplemented to
guide efforts towards supporting the stronger tls-exporter.


One use case I see for tls-server-end-point is that it allows for 
supporting channel binding by setups where TLS is terminated by some 
reverse proxy, thereby protecting against _some_ but not all attack 
vectors that tls-exporter protects against.


Additionally, implementing tls-server-end-point demands minimal effort 
since it is just based on the hash of the certificate. I believe that 
not making it mandatory won't deter anyone who is inclined to implement 
it, as it is a low hanging fruit.


Furthermore, we hope to achieve a high success rate by making it 
mandatory to implement for servers.


You are correct, one should aim for better altnatives than 
tls-server-end-point when implementing XEP-0440, and this should be 
explicitly mentioned in the XEP. As it stands, the XEP does not clearly 
convey this. I intend to propose a revision to rectify this in the near 
future.



- Flow


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Andrzej Wójcik]

Another use case of tls-server-end-point is for cases where you are unable to 
support tls-exporter, ie. in some languages TLS/SSL stack doesn’t expose data 
required for tls-exporter. In those cases it is better to have 
tls-server-end-point for channel binding instead of not having anything 
available.

> Wiadomość napisana przez Holger Weiß  w dniu 
> 11.01.2024, o godz. 13:39:
> 
> * Simon Josefsson  [2024-01-11 13:10]:
>> I believe tls-server-end-point is generally best left unimplemented to
>> guide efforts towards supporting the stronger tls-exporter.
> 
> One use case I see for tls-server-end-point is that it allows for supporting 
> channel binding by setups where TLS is terminated by some reverse proxy, 
> thereby protecting against _some_ but not all attack vectors that 
> tls-exporter protects against.
> 
> Holger
> ___
> Standards mailing list -- standards@xmpp.org
> To unsubscribe send an email to standards-le...@xmpp.org

Regards,
Andrzej Wójcik

XMPP: andrzej.woj...@tigase.org
Email: andrzej.woj...@tigase.net

___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org

[Standards] Re: XEP-0440 and tls-server-end-point

[Holger Weiß]

* Simon Josefsson  [2024-01-11 13:10]:

I believe tls-server-end-point is generally best left unimplemented to
guide efforts towards supporting the stronger tls-exporter.


One use case I see for tls-server-end-point is that it allows for 
supporting channel binding by setups where TLS is terminated by some 
reverse proxy, thereby protecting against _some_ but not all attack 
vectors that tls-exporter protects against.


Holger
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org