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