> On Feb 12, 2020, at 6:22 PM, Martin Thomson <m...@lowentropy.net> wrote:
>
> On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
>> I'm brand new to the IETF, so please forgive me if I'm totally off base
>> here, but my understanding is that Informational RFCs are explicitly
>> not recommendations (let alone mandates)?
>
> This would of course be information, but my comment was about phrasing. This
> document comes off as being quite prescriptive, where it doesn't really need
> to be. Absent actual algorithms, it's just a set of guidelines. That's
> reflected in its Informational status, but it would be better if the verbiage
> also reflected that more clearly.
>
> To address Stephen's comment at the same time: I think that we can publish an
> RFC on this before the competition completes if it is just a framework. That
> might in fact make standardizing the one true composite scheme easier.
I do not agree. I do not think the WG should adopt this draft.
The CFRG has stated a position that the IETF should wait for the NIST
standardization process to be complete. There are at least two approaches to
mixing symmetric keying material into the TLS 1.3 key schedule for information
that needs to be protected for the next few decades. (The two that I know
about are draft-ietf-tls-tls13-cert-with-extern-psk and draft-vanrein-tls-kdh.)
These approaches make existing key establishment techniques secure even if a
quantum computer gets developed as long as the symmetric key is not disclosed.
In my opinion, those techniques will hold us until the NIST standardization
process finishes.
I do not understand the goal of mixing (EC)DH with one of candidate algorithms.
We do not know enough about the candidate algorithms in the NIST process. If
the goal is to add quantum resistance, we do not have enough information to
pick well. If the goal is to learn about mixing in general, then I question
the project altogether. Once the NIST standardization process is complete, we
can simply use the selected algorithm without mixing.
Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
