Thanks so much for the comments.I'll respond to some from the top of my head, the others I'll address some time next week.
On 03.03.24 13:39, Alexander Clouter wrote:
Section 4.1.2 ------------- It just popped up as an idea in my reply to the the SEC review of TEAP but... EAP-TLS sub-methods have been copying the version bits since forever. Maybe it is time to break the mold? You could instead mark the version field just as reserved bits and move to use TLS ALPN to indicate version as it solves all the problems of downgrade attacks. It would though require a registration for the entry. Fortunately, this is the initial version, so you could just use "no ALPN" as the indicator and make it a problem for 'future you' to seek a registration when you want a v2.
The idea here is that future versions may signal some information outside the TLS tunnel. Our first idea, where this kind of still stems from was that the server signals the RPID outside the TLS tunnel, so the client can verify that the server's certificate is in fact valid for that. Now that we've moved the RPID to be an explicit configuration item, this has become obsolete, but who knows what other things you could signal there.
But I'm open to just define those as "reserved" and completely rely on ALPN.
Section 4.3 ----------- Explicitly stating SHA256 is going to get you into trouble as hardcoding these things makes it awkward to remove them later (eg. MD5 and RADIUS) Instead I would be inclined to mix your client component (the 'second' part) by using it as the 'context' value for the TLS-Exporter. If you look at the exporter (RFC8446, section 7.5) it is used to mix the label which I suspect is what you are looking for; not part of the secret which the client part is likely to be public knowledge. This way, as future ciphers and TLS versions come along, you should not need to update the 'hardcoded' SHA256 as you have just outsourced the problem to the TLS-Exporter; the OpenSSL magic for this is `SSL_CIPHER_get_handshake_digest(SSL_get_current_cipher(ssl))`.
The idea to use SHA256 comes from FIDO, they make a lot of use of SHA-256.But of course, since that part is not done inside the FIDO Authenticator, there should be no problem to use the hash algorithm negotiated in the cipher suite for that too.
Thanks for spotting that.
Section 6.1.1: -------------- Do not mix the advantages and disadvantages into the same itemised list.
Completely agree. That's still on my TODO list to reformat that.Shame on me for not doing that this time around, I'll definitely fix that in the -03 version of the draft.
Cheers, Janfred
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
