Hi Jun,
please see inline.
Hi Valery,
Thank you for the comments, pls see my reply in line below
From: Valery Smyslov <smyslov.i...@gmail.com>
Sent: Wednesday, November 6, 2024 12:31 AM
To: Jun Hu (Nokia) <jun...@nokia.com>; 'Wang Guilin' <wang.gui...@huawei.com>;
'Daniel Van Geest' <daniel.vange...@cryptonext-security.com>; 'Scott Fluhrer
(sfluhrer)' <sfluh...@cisco.com>; 'tirumal reddy' <kond...@gmail.com>
Cc: 'ipsec' <ipsec@ietf.org>; 'Wang Guilin' <wang.gui...@huawei.com>
Subject: RE: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Hi,
I do not have strong opinion regarding type-1 (composite signatures) vs type-2
(non-composite signatures). But as it was already mentioned,
if we support non-composite signatures, then we in fact support both.
And if we support type-2 (non-composite), then I believe that RFC 4739 approach
is better, than what is proposed in the draft.
1. It behaves much better on lossy networks. This is because IKE
fragmentation doesn’t allow to ack individual fragments.
If any fragment is lost, the whole message is retransmitted. For this reason it
is desirable to keep the number of fragments small.
The draft currently suggests to send a single large IKE_AUTH message, that will
be resulted in the more fragments, thus more
probability for the need to retransmit it. With RFC 4739 several smaller
IKE_AUTH messages are sent, each is individually
acknowledged. The total size of the data sent will be a bit larger, than in
case of single message, but this is insignificant
comparing to the size of PQ signatures. Thus, I think that the need for
multiple IKE_AUTH exchanges is not a drawback (as listed below),
instead this is an advantage. And note, that IKE_AUTH is already
multi-exchange, thus the need to extend it with more additional exchanges
is easy to implement.
[HJ] ML-DSA signature (2k-4kB) and certificate (2k-3kB) alone are already quite
big, so even you only use ML-DSA in one IKE_AUTH packet, it almost for sure
already be fragmented; plus if we think current IKEv2 fragmentation mechanism
has such limitation, then shouldn’t we try to fix IKEv2 fragmentation instead?
Since that limitation is a general issue, not just for this case.
It is not a problem that message is fragmented with IKE fragmentation.
The problem may arise with lossy networks.
The more fragments message is split over, the higher chance of message
retransmission due to loss of some of them.
IKEv2 generally makes quite a lot of attempts to retransmit message before
finally giving up. So, it is not a *fatal*
problem, but with design from the draft the chance that SA establishment will
take long time in this situation (due to losses and retransmissions) is higher.
You are correct that this is a general issue of IKEv2. However, it is
insignificant unless you use PQ algorithms, that make IKE messages
much larger than typical MTUs. With PQ key establishment we already perform
each PQ KEM in a separate IKE exchange,
thus addressing this problem as much as we can (there are also other
considerations to do in such a way).
I believe the same approach is worth to follow with PQ signatures by using RFC
4739.
What about the idea to “fix” IKE fragmentation – well this is not an easy
task and would significantly complicate protocol.
Acknowledging individual fragments was considered at the time IKE
fragmentation was being developed, but was rejected as a major change to the
protocol.
Alternatively TCP encapsulation of IKE and ESP (RFC 9329) can be used, but it
badly influences ESP performance.
This can be mitigated with draft-smyslov-ipsecme-ikev2-reliable-transport,
but it is not yet much discussed in the WG.
2. In case of misconfiguration the RFC 4739 approach provides faster
detection and reduces unnecessary resource consumption on initiator.
With the approach in the draft the initiator have to sign with all signatures
and then send the message. The responder will check them
one by one and in case one of them fails (e.g. due to misconfiguration), there
is no point to verify the rest. It means that the initiator
spent its resources in vain for generating them. Note also, that with of RFC
4739 the responder immediately sends AUTHENTICATION_FAILED
in this situation, thus the rest of IKE_AUTH exchanges do not take place and
the initiator gets quick indication that something is wrong.
[HJ] there is also case if we use RFC4739 where first AUTH exchange succeed but
2nd one fails, I don’t see huge difference
The difference is that with your design the initiator would have to do
the full work of applying all signatures in any case,
while with RFC 4739 this would happen only in case when the last
signature is wrong. In all other cases
the detection of misconfiguration will be faster and less resource
consuming for initiator.
3. As a consequence of the previous consideration, the RFC 4739 approach
provides better defense against DoS attacks (with some modifications).
A malicious initiator may send invalid signature in the AUTH payload (e.g. just
garbage), forcing the responder to spend resources to check it.
It costs nothing to the initiator, but the responder has to receive the whole
(large) message, buffer it, decrypt it, parse it, start verifying
signature (a clever attacker would put the most resource-consuming signature
first) only to drop the message.
If the signatures are sent one by one in separate IKE_AUTH exchanges, and the
responder has an ability to indicate the preferred order
(not currently in RCC 4739, but can be added), then it would start with the
smallest and easy to verify one, saving resources in case it fails.
[HJ] DoS attack in this conext is not cheap, since IKEv2 already have multiple
mechanisms to prevent DoS attack during IKE_SA_INIT/key-exchange, like cookie
or puzzle; if attacker could reach IKE_AUTH phase after all those mechanisms,
it already used quite some compute resources, especially in case of multiple
key exchange case.
It depends on the particular algorithms. If used KEMs are fast with
decap and have small PKs while used signature algorithms are slow with
verification
and have large signatures, then it makes sense for attacker to mount
this kind of attack.
4. I don’t buy the argument that an additional logic is needed to bind two
signatures together. They both operate on the same data,
that includes random values from both sides. Thus I think that both are bound
to the exchange. Am I missing something?
[HJ] I think this is related to the security concern of stripping attack as
described in draft-ietf-lamps-pq-composite-sigs
From my understanding draft-ietf-lamps-pq-composite-sigs discussed
composite (type-1) signatures.
RFC 4739 may also be used with non-composite (type-2) ones.
But I agree that security properties of using them in IKEv2 should be
further evaluated.
5. And finally, I fail to see that the draft provides a single solution
for both type-1 and type-2 approaches. It seems to me that the AUTH payload
processing for type-2 (non-composite) will be very different, since there
should be some internal formatting to separate the signatures
(or perhaps I’m missing something, the draft currently has absolutely no
details on this).
[HJ] the AUTH payload generation in both type-1 and type-2 are same procedure
as described in 4.2.1 of draft-ietf-lamps-pq-composite-sigs, in case of type-2,
step-3 is skipped, I could put more text to clarify it
OK, I now seem to understand, that you always use composite signatures
in IKEv2 and the difference is only whether
the used private keys are certified together by a single certificate
(type-1) or separately, each by its own certificate (type-2).
If this is the case, then RFC 4739 cannot be used, as you don’t
support non-composite signatures.
I think this should be clarified in the draft and aligned with
draft-ietf-pquip-hybrid-signature-spectrums and
draft-ietf-pquip-pqt-hybrid-terminology.
Regards,
Valery.
Lastly less round-trips is always better than more 😊
Regards,
Valery.
From: Jun Hu (Nokia) <jun.hu=40nokia....@dmarc.ietf.org
<mailto:jun.hu=40nokia....@dmarc.ietf.org> >
Sent: Tuesday, November 5, 2024 9:15 PM
To: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org
<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org> >; Daniel Van Geest
<daniel.vangeest=40cryptonext-security....@dmarc.ietf.org
<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org> >; Scott
Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org>; tirumal reddy
<kond...@gmail.com <mailto:kond...@gmail.com> >
Cc: ipsec <ipsec@ietf.org <mailto:ipsec@ietf.org> >; Wang Guilin
<wang.gui...@huawei.com <mailto:wang.gui...@huawei.com> >
Subject: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth
Thanks all for your comments. Let me try to address your comments in one reply
1. Do we need to address both type-1 and type-2? I do think we
need to address both because it is not entirely up to IPsec system to decide
which type to use, it is also depends on the CA, and I don’t expect all CA will
take same approach, and I also don’t expect CA could quickly change from one
type to another (e.g. do type-2 first, and change to type-1 in short amount of
time)
2. regarding security of using lamps composite signatures for
type-2, I have asked John Grey (who is one author of
draft-ietf-lamps-pq-composite-sigs) to take a look; the main concern that if
attacker could get signature from individual component key, but my opinion is
that it is ok in this context, as long as we add some requirements and
clarification like following:
a. the private key used in type-2 must be dedicated to IKEv2
hybrid authentication; they can’t be used to sign anything else, not even for
induvial authentication; e.g. RSA key in hybrid auth can only be used for
hybrid authentication, it can’t even be used to generate a RSA only AUTH
payload.
b. this is already in draft, but we could mandate the two
certificates must have RelatedCertificate extension as specified in
draft-ietf-lamps-cert-binding-for-multi-auth, so that two certificates are
indeed issued in pairs for same end-entity
3. regarding using two AUTH payloads for type-2, I don’t think
that’s simpler; first of all,, AFAIK, IKEv2 never support more than one AUTH
payload, support multiple AUTH payloads break that and also requires
additional logic; plus multiple AUTH payloads means additional encapsulation
overhead
4. regarding why not using RFC4739, following are the reasons:
a. save on round-trip since if using hybrid auth with hybrid
key exchange (very likely), the total amount of exchange will be quite high
b. with setup-2, we will need addition logic to bind two
key/signature together if using rfc4739
c. trying to use a single solution for both type-1 and type-2
5. regarding draft-reddy-ipsecme-ikev2-pqc-auth, my draft is
about hybrid authentication while my understanding of
draft-reddy-ipsecme-ikev2-pqc-auth is about using ML-DSA/SLH-DSA as single
auth, so they are addressing different problem
From: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org
<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org> >
Sent: Tuesday, November 5, 2024 5:58 PM
To: Daniel Van Geest <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org
<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org> >; Scott
Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org
<mailto:sfluhrer=40cisco....@dmarc.ietf.org> >; tirumal reddy
<kond...@gmail.com <mailto:kond...@gmail.com> >
Cc: ipsec <ipsec@ietf.org <mailto:ipsec@ietf.org> >; Wang Guilin
<wang.gui...@huawei.com <mailto:wang.gui...@huawei.com> >
Subject: [IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Type-1 is more compatible with composite-signature in lamps. However, Type-2 is
more flexible.
Say, we have 4 traditional signature algorithms and 3 PQ signature algorithms.
Then, we just need in total 7 algorithm IDs to denote these algorithms and all
possible combinations of them.
However, for Type-1, we need another 12 algorithm IDs just for all PQ/T
combinations (not mentioning potential combinations of 3 or more algorithms).
Also, the improving suugestions from Scott are interesting.
Guilin
From:Daniel Van Geest <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org
<mailto:daniel.vangeest=40cryptonext-security....@dmarc.ietf.org> >
To:Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org
<mailto:sfluhrer=40cisco....@dmarc.ietf.org> >;tirumal reddy <kond...@gmail.com
<mailto:kond...@gmail.com> >
Cc:ipsec <ipsec@ietf.org <mailto:ipsec@ietf.org> >
Date:2024-11-05 17:28:00
Subject:[IPsec] Re: draft-hu-ipsecme-pqt-hybrid-auth
And if the WG decides it wants to use Type-2 as specified in
draft-hu-ipsecme-pqt-hybrid-auth, we should also advise LAMPS that we intend to
abuse their composite signatures construction by reusing private keys within a
composite signature and stand-alone. Perhaps the non-separability concerns
aren't an issue in IKEv2 because the nonces make the signed content different
for every signature.
Daniel
On 2024-11-05 4:31 p.m., Scott Fluhrer (sfluhrer) wrote:
If we (as a working group) decide we want to use Type-1, we should advise the
LAMPS working group that we intend to use their proposal. They provide a tool
that we (IPSecME) uses; they need to know that there is demand for such a tool.
From: tirumal reddy <mailto:kond...@gmail.com> <kond...@gmail.com>
Sent: Tuesday, November 5, 2024 9:17 AM
To: Scott Fluhrer (sfluhrer) <mailto:sfluh...@cisco.com> <sfluh...@cisco.com>
Cc: ipsec@ietf.org <mailto:ipsec@ietf.org>
Subject: Re: [IPsec] draft-hu-ipsecme-pqt-hybrid-auth
I prefer Type-1 over Type-2, it seems more complicated to manage multiple
certificates and the possibility of a downgrade attack .
-Tiru
On Tue, 5 Nov 2024 at 15:40, Scott Fluhrer (sfluhrer)
<sfluhrer=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org> >
wrote:
While I support the goals of this draft, I do not believe that the methods
proposed are the most effective.
It tries to merge Type-1 (certificates that include both classical and PQ keys)
and Type-2 (two separate certificates) methods of providing public keys,
however I believe it would be cleaner to keep them separate.
For Type-1, if we use the ietf-lamps-pq-composite-sigs certificate format, then
it is easy. That defines a new signature algorithm (which internally consists
of a classical signature and a PQ signature pasted together, but we can ignore
the internal details). We can use that as the signature method within the Auth
payload, and hence the only changes we need to make to IKE is to recognize this
new signature method.
For Type-2 (multiple certificates), we need to request multiple certificates
(which you do with the current proposal). However, it would be cleaner i(IMHO)
if the other side just provided multiple CERT payloads and multiple AUTH
payloads (rather than try to combine them). Each AUTH payload would contain the
signature (based on the public key from the corresponding CERT payload) of the
same data which is being signed now. The idea is that if we keep the
fundamental structure of IKE authentication (just having multiple payloads when
necessary), it may be easier for an existing IKE implementation to be extended.
_______________________________________________
IPsec mailing list -- ipsec@ietf.org <mailto:ipsec@ietf.org>
To unsubscribe send an email to ipsec-le...@ietf.org
<mailto:ipsec-le...@ietf.org>
_______________________________________________IPsec mailing list --
ipsec@ietf.org <mailto:ipsec@ietf.org> To unsubscribe send an email to
ipsec-le...@ietf.org <mailto:ipsec-le...@ietf.org>
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
