[kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)

[Eric Rescorla via Datatracker <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-kitten-pkinit-alg-agility-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

IMPORTANT
I think this document would benefit greatly from describing the
downgrade properties of each of the axes on which algorithms
can be negotiated against various forms of compromise in the
digest function.

The relevant case is one in which the client and KDC both support
one weak and one strong algorithm. Can the attacker either

(1) force them to complete a handshake with a weak algorithm
or
(2) convince one side that the other side supports a weak algorithm
and then interpose itself as that side.

Specifically it would be useful to know which attacks are possible
with a collision attack versus a preimage attack (though this
can sometimes be hard to know).


Here is one case of a potential real downgrade attack (though not a
very powerful one).

The client sends a KRB-REQ signed with algorithm A, the attacker
forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
weaker algorithm. This causes the client to retry with that weaker
algorithm. Is this attack detectable? It's not clear to me how (though
it maybe could be if the message were folded into the transcript).

OTOH, I don't think that the equivalent attack on the cert signer
algorithms is necessarily very useful because presumably the certs are
public already. OTOH, it might force the client into using some weaker
key.


I'm having a little trouble following the point in S 3. Is the idea
that the paChecksum is always SHA-1 and you don't add a way to negotiate
it, so you are instead folding the information into the KDF? If so,
I think we need to work through the chain of logic here. As I understand
it, the paRequest is included in the AuthPack, which is signed. So
presumably the idea is that the AuthPack is signed with SHA-256
but because paChecksum is SHA-1, the binding is weak, right? But
can you safely send a SHA-256 signature to a KDC which you have
never talked to before? Can't you just get downgraded by the attack
I describe above? Can you help unpack this for me?


MINOR
I wish you were using HKDF, but I don't think this is a dealbreaker.