I support adoption.
Regards,
Uri
> On Mar 6, 2024, at 19:51, Rebecca Guthrie
> wrote:
>
> !---|
> This Message Is From an External Sender
> This message came from outside the Laboratory.
> |
I recall an argument that a truncated auth tag increased the likelihood of
collision (though still within the acceptable bound), and made the verification
of the auth key guess harder.
--
V/R,
Uri
On 8/6/24, 13:52, "Michael Richardson" mailto:mcr+i...@sandelman.ca>> wrote:
Benjamin K
I prefer Type-2, as it seems a more straightforward approach overall, with fewer chances of “cross-interruptions”.—Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Nov 5, 2024, at 09:28, tirumal reddy wrote:
I prefer Type-1 over Type-2, it seems more compl
>> Generally, we'd need new documents if there are significant features which
>> have NEVER been useful/implemented, and we should drop them first.
>> (I think that all of AH might fall into that, sadly)
>
> I have tried to kill AH a number of times and failed. I don't think we
> can strip it out
Responding on behalf of our Design Team.
Scott and Panos, thank you for pointing out the extra round-trip times in our
protocol, and rising other questions about the design. We would like to mention
a few points to address your concerns:
At first glance, this (from section 5.1, 5.2) appears
We’d like IPSECME WG to consider the following Internet Draft as a
less-expensive (and formally-proven 😉) candidate Post-Quantum authenticated
exchange within IKEv2. In our opinion, it is “better” than the current approach
of “explicit” signatures – we follow the MQV/HMQV design. Basically, PQu
Why would you trust “full identity” that’s been authenticated by Classic means?
—
Regards,
Uri
Secure Resilient Systems and Technologies
MIT Lincoln Laboratory
> On May 21, 2025, at 09:40, Kampanakis, Panos
> wrote:
>
>
> This Message Is From an External Sender
> This message came from outsi
ethod 0 (signature authentication), and in the future cipher suites with
ML-KEM and e.g., MAYO would have less overhead than KEM-based authentication
such as PQuAKE.
Cheers,
John
From: Blumenthal, Uri - 0553 - MITLL <mailto:u...@ll.mit.edu>
Date: Friday, 13 June 2025 at 18:29
To: ip
application?
Would appreciate your response!
Thank you!
P.S. Copying to LAKE WG, because this protocol may be useful to them as well –
and they may benefit from following our discussion in IPSECME.
--
V/R,
Uri
From: Blumenthal, Uri - 0553 - MITLL
Date: Monday, May 5, 2025 at 13:17
To: ipsec
I’ll be presenting PQuAKE protocol at LAKE WG, and since this protocol is designed for integration with IKE as well, would like an opportunity to present it here. https://datatracker.ietf.org/doc/draft-uri-lake-pquake/ Thanks!--V/R,Uri
smime.p7s
Description: S/MIME cryptographic signature
to advise
how your protocol is best to be integrated into the IKEv2 protocol.
I hear you. Based on my answers, comments, and explanations above – what would
you say?
Thanks!
From: Blumenthal, Uri - 0553 - MITLL
Sent: Friday, June 13, 2025 7:29 PM
To: ipsec@ietf.org
Cc: Wilson, David
knowledgeable could
explain.
Sent from Commodore VIC-20
😊
From: Blumenthal, Uri - 0553 - MITLL
Sent: Monday, June 30, 2025 9:06:19 PM
To: Valery Smyslov ; ipsec@ietf.org
Cc: Wilson, David - 0553 - MITLL ; Luo, Brandon - 0553
- MITLL ; l...@ietf.org
I agree - mandating use of PPK may not work. However, suggesting use of PPK,
i.e., as a (negotiable?) option would be a very good thing: those who have the
ability to employ it, and want better security - would opt in. While those who
don’t care or for various reasons cannot manage the distribut
has been out for a while, and I know quite some ipsec implementations
> already supported it.
> I think if the WG adopt this draft, there should be texts in the draft
> mentioning all these mitigations beside protocol changes.
>
> From: Christopher Patton
> Sent: Thursd
14 matches
Mail list logo
