Hi Scott:
I think it is really premature to speculate on features PQ-secure
algorithms can or cannot provide (*) and try and have this influence
*current* TLS1.3 protocol design. Should one wish to include PQ
algorithms in a future update of TLS1.3, one can simply specify which
protocol ingredients those updates relate to. As long as the current
TLS1.3 specification has some facility for implementing algorithm
agility, one can shy away from crystal ball gazing for now.
Best regards, Rene
(*) I am not sure everyone would concur with your speculation, but
crypto conferences may be a better venue to discuss this than a TLS
mailing list.
On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote:
*From:*Tony Arcieri [mailto:[email protected]]
*Sent:* Monday, March 07, 2016 11:40 AM
*To:* Scott Fluhrer (sfluhrer)
*Cc:* Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 -
MITLL; [email protected]
*Subject:* Re: [TLS] RSA-PSS in TLS 1.3
On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer)
<[email protected] <mailto:[email protected]>> wrote:
Defenses against the first type of attack (passive evesdropping by
someone who will build a QC sometime in the future) are something that
this WG should address; even if the PKI people don't have an answer,
we would at least be secure from someone recording the traffic and
decrypting it later
I think it would make sense to wait for the CFRG to weigh in on
post-quantum crypto. Moving to a poorly studied post-quantum key
exchange algorithm exclusively runs the risk that when it does receive
wider scrutiny new attacks will be found. I think we need to define
hybrid pre/post-quantum key exchange algorithms (e.g.
ECC+Ring-LWE+HKDF), and that sounds like work better suited for the
CFRG than the TLS WG.
I’m sorry that I wasn’t clearer; I agree that **now** isn’t the time
to define a postquantum ciphersuite/named group; we’re not ready yet
(and this WG probably isn’t the right group to define it). However, I
believe that we will need to do at some point; my guess is that it’ll
be sooner rather than later. What (IMHO) this WG should be doing now
is making sure that there isn’t something in TLS 1.3 that’ll make it
harder to transition to postquantum crypto when we do have a concrete
proposal.
One thing that proposed QR key exchanges have is that they don’t have
the full flexibility that (EC)DH have; either they aren’t secure with
static key shares, or we can’t use the same key share as both an
‘initiator’ and a ‘responder’ key share. This would indicate to me
that we need to make sure that TLS 1.3 should be engineered to use
(EC)DH as only a simple, ephemeral-only key exchange – yes, it has
more flexibility than that, however taking advantage of such
flexibility might cause us problems in the future
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
