> On Nov 13, 2019, at 6:01 PM, Wolfgang Breyha via Exim-users <exim-users@???> wrote:
>
>> I agree that the new format is inadequate, especially for TLS 1.3.
>> In Postfix I've kept, and even expanded the "comment" form of the
>> TLS trace info. For example:
>
> Do you know of any proposed improvements to RFC 8314? I did not find any
> comments, erratas or drafts trying to improve the situation.
I don't, but you could propose a draft on either the "uta" or "ietf-smtp"
lists or both. I guess my example of:
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
could at least be closer to the 8314 spec via:
tls TLS_AES_256_GCM_SHA384 group X25519
(TLSv1.3 server-signature RSA-PSS (2048 bits) server-digest SHA256)
and you could propose additional keywords beyond "tls" (should have been
"tls-cipher") and "group" (should have been "tls-group"):
* tls-version: e.g. 1.3
* tls-signature: e.g. RSA-PSS
* tls-hash: e.g. SHA256
one complication is that TLS 1.3 introduces combined SignatureSchemes
that (key + possible hash all in one), but e.g. OpenSSL did not when I
last looked expose these as properties of the SSL state at the
completion of the handshake, instead I get the split out components
(just as in TLS 1.2) via:
- SSL_get_signature_nid() (OpenSSL 1.1.a and later, did I sign the
handshake, and with what digest algorithm id).
- SSL_get_certificate() (what certificate did I use if the above
returned success).
from which I extract the public key algorithm name and digest name.
Mapping these back to a single SignatureScheme name from the IANA
registry was too much work, and it is more readable to split the
scheme into its parts, and add RSA bit counts to just the public
key type, ...
If you want to propose something, I'd like to see something that
is grounded in actual implementations in say both Postfix with
OpenSSL and Exim (with at least GnuTLS, and likely also OpenSSL).
It is too easy to just look at the IANA registry and produce
a spec that is difficult to implement with existing toolkits.
While the toolkit can evolve, waiting for revisions means that
MTAs may not be able to implement the spec on many platforms
for years ("stable" OS releases don't pick up new features).
--
Viktor.
