Hi Ben,
Please see inline
On Fri, 11 Sep 2020 at 07:05, Ben Schwartz wrote:
> Thanks for highlighting this, Michael. I don't support adoption of this
> draft, because I don't think it is fit-for-purpose. Specifically, I think
> it is likely to provide a significant advantage to malware author
On Fri, 11 Sep 2020 at 16:11, Nick Lamb wrote:
> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy wrote:
>
> > The MUD URL is encrypted and shared only with the authorized
> > components in the network. An attacker cannot read the MUD URL and
> > identify th
Thanks Ben and Eliot for the feedback. Please see inline
On Tue, 15 Sep 2020 at 14:51, Eliot Lear wrote:
> Hi Ben
>
> Thanks for the response. Please see below.
>
> >
> > Agreed ... but this proposal appears to be predicated on a contrary
> assumption. It assumes that it is difficult for malwa
On Tue, 15 Sep 2020 at 18:39, Eliot Lear wrote:
>
>
> My concern is not with "new extensions" per se. The hidden assumption
> here is that "extensions" are the only way TLS can evolve. In fact, future
> TLS versions are not constrained to evolve in any particular way. For
> example, future ver
Hi Nick,
Please see inline
On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote:
> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
>
> The grease_extension parameter shouldn't exist, and there should be no
> special handling for GREASE values. GREASE doesn't need to be ment
On Thu, 17 Sep 2020 at 01:38, Nick Harper wrote:
>
>
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy wrote:
>
>> Hi Nick,
>>
>> Please see inline
>>
>> On Wed, 16 Sep 2020 at 06:00, Nick Harper wrote:
>>
>>> I agree with EKR, Ben Schwar
On Sun, 20 Sep 2020 at 14:05, Eliot Lear wrote:
>
>
> > On 11 Sep 2020, at 12:40, Nick Lamb wrote:
> >
> > On Fri, 11 Sep 2020 12:32:03 +0530
> > tirumal reddy wrote:
> >
> >> The MUD URL is encrypted and shared only with the authorized
> >&g
in
https://tools.ietf.org/html/rfc8126.
Cheers,
-Tiru
>
> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy wrote:
>
>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear wrote:
>>
>>>
>>>
>>> > On 11 Sep 2020, at 12:40, Nick Lamb wrote:
>>> >
On Tue, 19 Mar 2024 at 15:27, David Benjamin wrote:
> > If the server supports P256+ML-KEM, what Matt suggested is that, instead
> of accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then
> continue as expected and end up negotiating things in 2 round trips.
>
> I assume Client
I support adoption of the draft, it is useful in telco networks.
-Tiru
On Fri, 25 Oct 2024 at 08:18, Sean Turner wrote:
> At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS
> and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2]
> and [3]. The I-D h
to generate and verify signatures.”
>
>
>
> This is incorrect. The “f” versions only have faster key generation and
> signing. They have *slower* verification.
>
Good catch, fixed.
-Tiru
>
>
> Cheers,
>
> John
>
>
>
> *From: *Peter C
> *Date: *Sun
On Mon, 4 Nov 2024 at 02:52, Peter C wrote:
> John Mattsson wrote:
>
> > ”Conversely, the fast version prioritizes speed over
>
> > signature size, minimizing the time required to generate
>
> > and verify signatures.”
>
> >
>
> > This is incorrect. The “f” versions only have faster key
>
> > gen
e 3rd paragraph in
https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html#section-2)
-Tiru
>
>
> Peter
>
>
>
> *From:* Russ Housley
> *Sent:* 03 November 2024 11:13
> *To:* tirumal reddy
> *Cc:* IETF TLS
> *Subject:* [TLS] Re: New Version Notification fo
On Sun, 3 Nov 2024 at 14:34, Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 05:45:13AM +0530, tirumal reddy wrote:
> >
> > This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> > specifies how the PQC signature scheme SLH-DSA can be used for
> > authe
Hi all,
The draft https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
specifies how ML-DSA in combination with traditional algorithms can be used
for authentication in TLS 1.3.
Comments and suggestions are welcome.
Regards,
- Tiru
-- Forwarded message -
From:
Date:
Hi all,
This draft https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
specifies how the PQC signature scheme SLH-DSA can be used for
authentication in TLS 1.3.
Comments and suggestions are welcome.
Regards,
-Tiru
-- Forwarded message -
From:
Date: Sun, 3 Nov 2024 at 05:39
On Sun, 3 Nov 2024 at 14:12, Ilari Liusvaara
wrote:
> On Sun, Nov 03, 2024 at 05:37:34AM +0530, tirumal reddy wrote:
> >
> > The draft
> https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> > specifies how ML-DSA in combination with traditional algorith
ly we could require the RSA part to still make PSS signatures
> but I think that would be rather hard on the cryptographic backends...
> So I'd rather not have them.
>
> On Sunday, 3 November 2024 01:07:34 CET, tirumal reddy wrote:
> > Hi all,
> >
> > The draft
&g
On Fri, 22 Nov 2024 at 20:39, Ilari Liusvaara
wrote:
> On Fri, Nov 22, 2024 at 07:34:18PM +0530, tirumal reddy wrote:
> > Thank you, Alicja, for the review. I agree with all your comments and
> have
> > raised a PR https://github.com/tireddy2/composite-mldsa/pull/1 to
> ad
Hi Illari,
The composite signature defined in draft-ietf-lamps-pq-composite-sigs is
EUF-CMA secure and achieves weak non-separability. It aligns with the
security considerations for hybrid digital signatures discussed in
https://datatracker.ietf.org/doc/draft-ietf-pquip-hybrid-signature-spectrums/
On Mon, 25 Nov 2024 at 06:55, Blumenthal, Uri - 0553 - MITLL
wrote:
> > To clarify, are you continuing to claim that there's "no damage possible
> > (at least, in the TLS context) caused by PQ DSA break", despite the
> > facts that (1) upgrades often take a long time and (2) attackers aren't
> >
The revised draft
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/ addresses
comments from Alicja and Illari. Further, comments and suggestions are
welcome.
-Tiru
-- Forwarded message -
From:
Date: Tue, 26 Nov 2024 at 11:07
Subject: New Version Notification for d
Hi all,
The updated draft
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/,
incorporates feedback received from the WG. It outlines how ML-DSA in
combination with traditional algorithms can be utilized for authentication
in TLS 1.3.
Further, comments and suggestions are welcome.
On Fri, 15 Nov 2024 at 23:10, Andrey Jivsov wrote:
> I am curious why this draft exclusively proposes ML-DSA, instead of
> adopting a composite signature approach as outlined in
> draft-ounsworth-pq-composite-sigs, at least as an option. For instance,
> id-MLDSA87-ECDSA-P384-SHA512 defined in the
Hybrids are mandatory for protocols like IKEv2 over UDP to handle
fragmentation (traditional key exchange followed by a PQ KEM), see
https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/.
-Tiru
On Sat, 16 Nov 2024 at 11:43, Watson Ladd wrote:
>
>
> On Fri, Nov 15, 2024, 8:52 PM Andrey
Hi all,
The updated draft https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/,
incorporates feedback received from the WG. It specifies how the PQC
signature scheme SLH-DSA can be used for authentication in TLS 1.3.
Further, comments and suggestions are welcome.
Best Regards,
-Tiru
---
On Sat, 16 Nov 2024 at 10:23, Andrey Jivsov wrote:
> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote:
>
>> ...
>> Why not hash based signatures?
>>
>
> I think that the stateful ones are perfectly suited for certifications in
> X.509 certs, but in the TLS handshake this has to be Sphincs+, at
Hi all,
The document https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/
discusses Quantum-Ready usage profiles for TLS-based Applications to defend
against passive and on-path attacks employing CRQCs.
Comments and Suggestions are welcome.
Best Regards,
-Tiru
-- Forwarded message
Reviewer: Tirumaleswar Reddy K
Review result: Ready with issues
I have reviewed this document as part of the SEC area directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security area
directors.
Docume
I support the adoption call for all four drafts, with higher priority given
to the hybrid and pure key exchange drafts.
-Tiru
On Tue, 17 Dec 2024 at 03:31, Sean Turner wrote:
> Note that there are three parts to this email; the “ask” is at the end.
>
> Requests:
>
> Ciphersuite discussions in t
s-pq-composite-sigs schemes should be considered atomic,
>with a key of id-HashMLDSA65-RSA3072-PSS-SHA512 able to perform
> signatures
>only with that scheme, not with arbitrary hash functions...
>
> On Saturday, 16 November 2024 06:57:17 CET, tirumal reddy wrote:
> > Hi all,
&
Hi all,
The revised https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/
addresses comments from the WG. It discusses Quantum-Ready usage profiles
for TLS-based Applications to defend against passive and on-path attacks
employing CRQCs.
Further comments and suggestions are welcome.
Best Reg
I support adoption of the draft.
-Tiru
On Tue, 1 Apr 2025 at 18:29, Sean Turner wrote:
> We are continuing with our pre-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for
> the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D
33 matches
Mail list logo
