Re: [Last-Call] [art] Artart last call review of draft-ietf-uta-rfc7525bis-09

[Peter Saint-Andre <[e-mail]>]

Hi Cullen, having looked more closely at the text that's already in 
7525bis, I have a few questions inline...

On 8/1/22 4:18 PM, Peter Saint-Andre wrote:
> On 8/1/22 2:58 PM, Cullen Jennings wrote:
>>
>>
>>> On Jul 30, 2022, at 1:40 PM, Peter Saint-Andre <[e-mail]> 
>>> wrote:
>>>
>>> Hi again,
>>>
>>> The authors have conferred on this and at this time we don't think 
>>> that we can recommend anything other than EC ciphers, for several 
>>> reasons:
>>>
>>> 1. DHE negotiation is broken.
>>
>> Perhaps a bit more explanation in the draft about the issues with 
>> DHE-RSA (in context of 7919) would help. 
> 
> For sure. We weren't crafting text yet, merely pointing out the basic 
> rationale behind exclusing non-EC ciphersuites. We can definitely 
> explain each of these three reasons more fully in text to follow. >
>> I was under the perhaps mistaken perception that the RFC 7919 was not 
>> subject to the Raccoon attack and that there were mitigation for the 
>> Racoon timing attacks. Given the reliance on a single class of 
>> algorithms, I think it would be worth highlighting the risks and 
>> provide good info on why alternatives don’t work.
> 
> Agreed.

Section 2.1 already says:

    *  Implementations SHOULD NOT negotiate cipher suites based on non-
       ephemeral (static) finite-field Diffie-Hellman key agreement.

       Rationale: These cipher suites, which have assigned values
       prefixed by "TLS_DH_*", have several drawbacks, especially the
       fact that they do not support forward secrecy.

Do you see the need for further explanation?

>>> 2. Static RSA is out of the question.
>>
>> I agree but would prefer that was phrased as things don’t provide PFS 
>> are out of the question, not that RSA is not usable. 
> 
> That makes sense.

Section 2.1 already says:

    *  Implementations SHOULD NOT negotiate cipher suites based on RSA
       key transport, a.k.a. "static RSA".

       Rationale: These cipher suites, which have assigned values
       starting with the string "TLS_RSA_WITH_*", have several drawbacks,
       especially the fact that they do not support forward secrecy.

Do you see the need for further explanation?

>> I see lots of confusion of those two. I will note that, if EC was 
>> broken by quantum or optical computers but RSA was not, I’m pretty 
>> sure I would be switching to something with no PFS vs something that 
>> was broken.
> 
> Very likely. :-)

Although I agree with the sentiment, it's not clear to me that 7525bis 
needs to include text on this somewhat speculative point.

>>> 3. Post-quantum (PQ) methods aren't ready yet.
>>
>> agree (thought I think they are getting surprising close and probably 
>> plan to ship them well ahead of any schedule I imagine the IETF 
>> getting around to agreeing on )
>>
>>>
>>> Our forecast is that a few years from now the PQ methods will be 
>>> ready for recommending in 7525ter, but for now EC is the best we can do.
> 
> I suspect that 7525ter will be published after the PQ methods have been 
> standardized at the IETF, but as we know it's never smart to make 
> specific forecasts about standardization schedules. ;-)

Here again I'm not sure that we need more text beyond what is already in 
version -10 (see Section 1):

    Naturally, future attacks are likely, and this document does not
    address them.  Those who implement and deploy TLS/DTLS and protocols
    based on TLS/DTLS are strongly advised to pay attention to future
    developments.  In particular, although it is known that the creation
    of quantum computers will have a significant impact on the security
    of cryptographic primitives and the technologies that use them,
    currently post-quantum cryptography is a work in progress and it is
    too early to make recommendations; once the relevant specifications
    are standardized in the IETF or elsewhere, this document should be
    updated to reflect best practices at that time.

Peter