Hi Nimrod:
All the quoted Raccoon attack (of which you are a coauthor) does is
highlight that poorly designed post-processing of a shared key
(variable-size bit-string representation) could be used to extract
secret info by solving an instance of the hidden number problem.
Let us not over-state the importance of this attack, though: the attack
(for those who care) is easy to mitigate, e.g., as follows:
a) Let K be the derived shared key; let K1, ..., Kt be a set of keys
including this key K (where this set has keys of byte-size L-1 and L,
respectively, say L-1 once and L for all others);
b) Compute kj:=kdf(Kj) for all j=1,...,t;
c) Select select kj, where Kj corresponds to K.
Note: (if t:=2) if K has size L-1, set, e.g., K':=K xor random L-byte
offset; if K has size L, set, e.g., K':=trunc_{L-1}(K) xor random
{L-1}-byte offset.
Contrary to what you claim, this seems to be easy to implement in
constant-time, however if not, this would still most likely thwart the
attack (since one cannot apply the HNP any more {since one has to guess
which leaks are real (correct j value) and which are spurious).
Bottom line (for me) is that one should not use attacks that are easy to
mitigate as a pretext for deprecating things. There may be other reasons
that have more merit, but the draft in the adoption call does not
provide any of this. Hence, my feedback to reject the individual draft
as it stands (based on lack of proper detail).
As Peter Gutmann already said in the thread, what problem is one trying
to solve here???
Contrary to what Filippo suggests, I do think one should query why
implementors do not heed advice that has been around for a long time (in
that case, they should rightfully assume some blame). Implementors have
duty of care too.
[my email of Aug 13, 2021, 9.58am EDT]
I think this document should absolutely *not* be adopted, without
providing far more technical justification. The quoted Raccoon attack is
an easy to mitigate attack (which has nothing to do with finite field
groups, just with poor design choices of postprocessing, where one uses
variable-size integer representations for a key). There are also good
reasons to have key exchanges where one of the parties has a static key,
whether ecc-based or ff-based (e.g., sni, opaque), for which secure
implementations are known. No detail is provided and that alone should
be sufficient reason to not adopt.
On 2021-08-27 1:00 p.m., Nimrod Aviram wrote:
> The implementation guidance to avoid weaknesses in any
ephemeral-static exchange is "don't get anything wrong, anything at all
Agreed that it's not workable. I'm not sure there is existing and
suitable implementation guidance.
To avoid the Raccoon attack, one would have to implement the KDF such
that it is constant time, even for variable-length secrets. This is
possible, at least in principle, but I'm not aware of any
implementation that does it or plans to do it, and neither of any
document that describes the complex strategy for achieving this.
On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda <fili...@ml.filippo.io
<mailto:fili...@ml.filippo.io>> wrote:
2021-08-27 05:08 GMT+02:00 Joseph Salowey <j...@salowey.net
<mailto:j...@salowey.net>>:
Thanks for all the discussion on this topic. There are several
modes that TLS 1.2 can operate with respect to DH. Below is a
proposal on cases to merge some of the cases covered by this
draft into the obsolete keyex draft. I'd like to see if there is
some consensus to make this change before we adopt it into the
working group.
1. static-static where both client and server have DH
certificates with long term keys. I think we have general
consensus that this mode should be a must not. To deprecate this
mode I think we need to state that clients MUST NOT use
certificates of type rsa_fixed_dh and dsa_fixed_dh and server
MUST NOT request them. Would the working group support merging
this guidance into the obsolete keyex draft?
2. ephemeral-static where the client uses an ephemeral key and
the server uses a long term key. This mode does not provide
forward secrecy. I'm not sure we have reached consensus on how
far to deprecate this option. Would the working group support
MUST NOT use these ciphersuites unless forward secrecy does not
matter for your use case and any implementation guidance provided
to avoid weaknesses is followed?
The implementation guidance to avoid weaknesses in any
ephemeral-static exchange is "don't get anything wrong, anything
at all, all the way down to your field arithmetic libraries". I
don't think that's a workable recommendation, and I believe we
should deprecate modes that are so unsafe to implement.
3. ephemeral-ephemeral - I think these are already covered in
the obsolete keyex draft.
Thanks,
Joe
On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle
<cbartle...@icloud.com <mailto:cbartle...@icloud.com>> wrote:
> which is a main reason cited for deprecating RSA
in draft-aviram-tls-deprecate-obsolete-kex.
Have the authors look at Post-Quantum KEMs?
I'm not sure why PQ KEMs are relevant here.
On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL
<u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
> Regardless of the Raccoon attack, the static DH and ECDH
ciphersuites do not provide
> forward secrecy,
Unless you use semi-static exchange, which in many cases
makes sense.
> which is a main reason cited for deprecating RSA
in draft-aviram-tls-deprecate-obsolete-kex.
Have the authors look at Post-Quantum KEMs?
> Do you object to just the citation of the Raccoon attack
or do you also feel that we
> should keep these ciphersuites that do not provide forward
secrecy around?
I think these suites should stay around.
While static-static indeed do not provide forward secrecy
(and many of us – though not everybody! – carry for that),
static-ephemeral DH and ECDH are perfectly fine from that
point of view.
On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 -
MITLL <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
I agree with Rene’s points.
--
Regards,
Uri
*From:*TLS <tls-boun...@ietf.org
<mailto:tls-boun...@ietf.org>> on behalf of Rene Struik
<rstruik....@gmail.com <mailto:rstruik....@gmail.com>>
*Date:*Friday, August 13, 2021 at 09:58
Dear colleagues:
I think this document should absolutely *not* be adopted,
without providing far more technical justification. The
quoted Raccoon attack is an easy to mitigate attack (which
has nothing to do with finite field groups, just with poor
design choices of postprocessing, where one uses
variable-size integer representations for a key). There are
also good reasons to have key exchanges where one of the
parties has a static key, whether ecc-based or ff-based
(e.g., sni, opaque), for which secure implementations are
known. No detail is provided and that alone should be
sufficient reason to not adopt.
Rene
On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
This is a working group call for adoption for Deprecating
FFDH(E) Ciphersuites in TLS
(draft-bartle-tls-deprecate-ffdhe-00
<https://datatracker.ietf.org/doc/draft-bartle-tls-deprecate-ffdhe/>).
We had a presentation for this draft at the IETF 110
meeting and since it is a similar topic to the key
exchange deprecation draft the chairs want to get a sense
if the working group wants to adopt this draft (perhaps
the drafts could be merged if both move forward). Please
review the draft and post your comments to the list by
Friday, August 13, 2021.
Thanks,
The TLS chairs
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
--
email:rstruik....@gmail.com <mailto:rstruik....@gmail.com> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
