Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 authors (the
> opposite of the intended effect).
>
> Currently, if a malware author wants to match the TLS characteristics of
> the host device, they have to do some work to characterize its TLS
> behavior.  This may be difficult, especially in the case of partial
> compromise, or for malware that targets a wide variety of hosts.  However,
> with this MUD module in place, the malware can read the TLS behavior right
> out of the MUD profile, and configure its behavior to match.
>

The MUD URL is encrypted and shared only with the authorized components in
the network. An  attacker cannot read the MUD URL and identify the IoT
device. Otherwise, it provides the attacker with guidance on what
vulnerabilities may be present on the IoT device.


> Note that, except in the case of TLS termination, the proxy cannot verify
> anything about the TLS session by observing it.  Just because a connection
> appears to use a particular SNI or certificate does not prove anything
> about the actual destination.
>

Yes, it is discussed in
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-4

Cheers,
-Tiru


>
> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) wrote:
>> > Hello, opsawg.  This draft as underwent a number of revisions based on
>> reviews and presentations at the last few IETF meetings.  The authors feel
>> they have addressed the issues and concerns from the WG in their latest
>> posted -05 revision.  As a reminder, this document describes how to use
>> (D)TLS profile parameters with MUD to expose potential unauthorized
>> software or malware on an endpoint.
>> >
>> > To that end, this serves as a two-week call for adoption for this
>> work.  Please reply with your support and/or comments by September 16, 2020.
>>
>> I have read the document in a number of different revisions, and I
>> support adoption.
>>
>> I have been concerned that this document codifies a kind of TLS snooping
>> by middle boxes which has in the past caused significant harm to
>> development of TLS. (In particular, TLS version negotiation has had to
>> evade existing middle box policies!)
>>
>> However,  this document seems to walk the fine line between causing
>> protocol ossification and providing real security.  To the extent that
>> it reduces the pressure by enterprises to invade the TLS encryption
>> envelope through use of Enterprise certificates [is there a term for the
>> activity describe in section 4.1? I wish there was] this document is a
>> very useful thing.
>>
>> I would like to suggest that upon adoption, that this document go
>> through a TLS WG review of some sort before OPSAWG does a WGLC.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> OPSAWG mailing list
> ops...@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 the IoT device. Otherwise, it provides the attacker with
> > guidance on what vulnerabilities may be present on the IoT device.
>
> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> over LLDP without - so far as I was able to see - any mechanism by which
> it should be meaningfully "encrypted" as to prevent an attacker on your
> network from reading it.
>

RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
example, TEAP (it does not allow TLS cipher suites without encryption).
The client identity (certificate carrying the MUD URL) is encrypted and not
visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
even omit the URL. It recommends to use a proxy to retrieve the MUD file
for privacy reasons.

-Tiru


>
> Nick.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 malware to learn the TLS
> profile of the device, and then proceeds to place this profile information
> in the (public) MUD file, where malware can easily retrieve it.
>
> Ok, I didn’t take that from this discussion.
>

I see the confusion, will try to clarify the issues raised:

a) The MUD URL includes privacy sensitive device details like (device type
and firmware version), and it should be stored in a secure location (like
TEE to avoid exposure to an unauthorized software) and to avoid sending
the MUD URL in clear text otherwise it will help an attacker to exploit a
vulnerability on the IoT device. It is already discussed in RFC8520.

b) One of the comments is that an attacker can observe the traffic from the
IoT device, learn the TLS profile and try to mimic some of the TLS profile
parameters of legitimate clients. This attack is discussed in detail in
Sections 3 and 5.  Please have a look.

c) The proposed mechanism not only helps detecting malware but also helps
identifying TLS and cryptographic vulnerabilities on the IoT device (to
prevent the device from getting compromised in the first place).


>
> >
> > I'm not thinking of the hours-days timescale of MUD file updates; I'm
> thinking of the months-years timescale of updating standards to support new
> features.  How long does a device have to wait after a new protocol
> revision comes out before it can start using the new protocol?
>
> Ok, I see what you are saying.  Thanks for getting me there.
>
> The question is what to do when you start seeing something you don’t
> understand.  Let’s take a TLS extension, for instance.  If the TLS
> extension is unknown to the f/w but is declared somehow, that tells the
> firewall that they have some coding to do, and should be conservative about
> complaining over something that is out of profile.


Yes.


> I don’t see that as a show stopper.  What I do see as a showstopper would
> be if, as is written and you rightly observe, a new rev of a YANG model is
> required to introduce the TLS extension, so that part would need to be
> described in a more flexible manner (e.g, an IANA registration or
> similar).  I’d suggest the authors consider that.
>

Agreed, the YANG model relies on IANA for TLS parameters values including
extension type values. Even if a f/w does not support a new extension, it
can still identify whether the new extension is included in the MUD
profile. If the extension is not included in the MUD profile, presence of
unauthorized software is detected.

We will update the draft to make it more clear.

-Tiru


> Eliot
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 versions can introduce entirely new messages in the
> handshake, or remove messages that are currently visible in the handshake.
> QUIC is arguably just an extreme version of this observation.
>
>
> I understand.  I used TLS extensions merely as an example.
>
>
> Even within the realm of ClientHello extensions, there is significant
> inflexibility here.  For example, consider the handling of GREASE
> extensions.  GREASE uses a variety of reserved extension codepoints,
> specifically to make sure that no entity is attempting to restrict use of
> unrecognized extensions.  This proposal therefore has to add a flag
> declaring whether the client uses GREASE, because otherwise the set of
> extensions is dynamic, and the number of potential codepoints is
> impractically large.  Any change to the way GREASE selects and rotates
> extension codepoints would therefore require a revision of this YANG model
> first.  There has also been discussion of adding GREASE-type behavior to
> the "supported_versions" extension; that would similarly require a revised
> YANG model here.
>
>
> Probably greasing is something that needs a certain special handling.
> Indeed that’s a form of fingerprinting (greases field XYZ).
>

Yes, GREASE requires special handling. The YANG model uses a flag to define
whether the client supports GREASE or not. The MUD TLS profile does not
advertise the GREASE values (see
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-5).

-Tiru


>
> Eliot
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 mentioned in
> this draft, except to say that a client may send values (cipher suites,
> extensions, named groups, signature algorithms, versions, key exchange
> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that
> the middlebox MUST NOT reject connections with values unknown to the
> middlebox.
>

The grease_extension parameter in the YANG model is a "boolean" type to
indicate whether the GREASE values are offered by the client or not.  The
MUD YANG model does not convey the GREASE values.


> (This can be stated without mentioning GREASE specifically.)
>
> There is also an issue where this draft does not describe how an observer
> identifies whether a TLS ClientHello is compliant with a MUD profile.
>

For example, an alert could be triggered to quarantine and remediate the
compromised device, and will update the draft to clarify.

-Tiru


>
> On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd  wrote:
>
>> On Tue, Sep 15, 2020, 9:10 AM 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 versions can introduce entirely new messages in the
>> handshake, or remove messages that are currently visible in the handshake.
>> QUIC is arguably just an extreme version of this observation.
>> >
>> >
>> > I understand.  I used TLS extensions merely as an example.
>>
>> There is no reason that a firewall should expect to parse TLS 1.4. TLS
>> 1.3 had to go through significant hoops due to middleboxes that
>> assumed they could see into everything like it was 1.2. This easily
>> added a year to the development time. The final hunt for incompatible
>> devices involved attempting to purchase samples, with no real
>> guarantee that they would find an intolerant device. Encouraging this
>> sort of behavior is a bad idea IMHO, as it will substantially burden
>> the TLS WG when designing TLS 1.4 in all sorts of unexpected ways.
>>
>> >
>> >
>> > Even within the realm of ClientHello extensions, there is significant
>> inflexibility here.  For example, consider the handling of GREASE
>> extensions.  GREASE uses a variety of reserved extension codepoints,
>> specifically to make sure that no entity is attempting to restrict use of
>> unrecognized extensions.  This proposal therefore has to add a flag
>> declaring whether the client uses GREASE, because otherwise the set of
>> extensions is dynamic, and the number of potential codepoints is
>> impractically large.  Any change to the way GREASE selects and rotates
>> extension codepoints would therefore require a revision of this YANG model
>> first.  There has also been discussion of adding GREASE-type behavior to
>> the "supported_versions" extension; that would similarly require a revised
>> YANG model here.
>> >
>> >
>> > Probably greasing is something that needs a certain special handling.
>> Indeed that’s a form of fingerprinting (greases field XYZ).
>>
>> The whole point of grease is keeping extensions open. Coding special
>> handling defeats the purpose.
>>
>> Sincerely,
>> Watson Ladd
>>
>> >
>> > Eliot
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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 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 mentioned in
>>> this draft, except to say that a client may send values (cipher suites,
>>> extensions, named groups, signature algorithms, versions, key exchange
>>> modes, ALPN identifiers, etc.) that are unknown to the middlebox and that
>>> the middlebox MUST NOT reject connections with values unknown to the
>>> middlebox.
>>>
>>
>> The grease_extension parameter in the YANG model is a "boolean" type to
>> indicate whether the GREASE values are offered by the client or not.  The
>> MUD YANG model does not convey the GREASE values.
>>
>>
> This is still problematic.
>
> Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to
> check that their peers correctly ignore unknown values (instead of closing
> the connection). If a device special-cases GREASE values when processing
> TLS messages, that device has completely missed the purpose of GREASE and
> is likely to cause interoperability failures when in the future it sees a
> TLS message that contains a new extension/cipher suite/etc. that isn't a
> GREASE value.
>
> The IETF should not be encouraging devices to special-case GREASE values.
> I can see no use of the grease_extension parameter in the YANG model that
> does not involve special-casing GREASE values. Hence it needs to be removed.
>

Got it, Thanks. Removed the grease_extension parameter from the YANG module
and added the following text:

   GREASE [RFC8701] sends random values on TLS parameters to ensure
   future extensibility of TLS extensions.  Such GREASE values might be
   extended to other TLS parameters.  Thus, the (D)TLS profile
   parameters defined in the YANG module by this document MUST NOT
   include the GREASE values for extension types, named groups,
   signature algorithms, (D)TLS versions, pre-shared key exchange modes,
   cipher suites and for any other TLS parameters defined in future
   RFCs.

-Tiru
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

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
> >> components in the network. An  attacker cannot read the MUD URL and
> >> identify the IoT device. Otherwise, it provides the attacker with
> >> guidance on what vulnerabilities may be present on the IoT device.
> >
> > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> > over LLDP without - so far as I was able to see - any mechanism by which
> > it should be meaningfully "encrypted" as to prevent an attacker on your
> > network from reading it.
>
> That’s a bit of an overstatement.  RFC 8520 specifies a component
> architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
> certificate).  Two other mechanisms have already been developed (QR code,
> Device Provisioning Protocol), and a 3rd new method is on the way for
> cellular devices.
>
> I would not universally claim that a MUD URL is secret but neither would I
> claim it is not.  The management tooling will know which is which, as will
> the manufacturer, and can make decisions accordingly.
>
> This having been said, it seems to me we are off on the wrong foot here.
> The serious argument that needs to be addressed is Ben’s and EKR's.  We
> have to be careful about ossification.
>

In order to address the comments on ossification, we added a new section 6
to explain the rules to processing the MUD (D)TLS rules to handle unknown
TLS parameters and updated Section 10 to enable faster update to the YANG
module. Please see
https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt

-Tiru
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy]

Hi Ben,

Please see inline

On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  wrote:

> I'm not able to understand the new text in Section 6.  Are you saying that
> clients MUST include all the listed extensions/features, but MAY also
> include extensions/features not listed in the MUD profile?  So the MUD
> profile only acts as a "minimum" set of features?
>

Section 6 discusses the firewall behaviour when it sees a) known
extensions/features in a TLS session but not specified in the MUD profile
b) unknown extensions/features in a TLS session either specified or not
specified in the MUD profile c) updated MUD profile specifying
extensions/features  not supported by the firewall.

If the client supports new features/extensions but not yet added in the
YANG module, it can be updated using expert review or specification
required registration procedure, discussed 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 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 the IoT device. Otherwise, it provides the attacker with
>>> >> guidance on what vulnerabilities may be present on the IoT device.
>>> >
>>> > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
>>> > over LLDP without - so far as I was able to see - any mechanism by
>>> which
>>> > it should be meaningfully "encrypted" as to prevent an attacker on your
>>> > network from reading it.
>>>
>>> That’s a bit of an overstatement.  RFC 8520 specifies a component
>>> architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
>>> certificate).  Two other mechanisms have already been developed (QR code,
>>> Device Provisioning Protocol), and a 3rd new method is on the way for
>>> cellular devices.
>>>
>>> I would not universally claim that a MUD URL is secret but neither would
>>> I claim it is not.  The management tooling will know which is which, as
>>> will the manufacturer, and can make decisions accordingly.
>>>
>>> This having been said, it seems to me we are off on the wrong foot
>>> here.  The serious argument that needs to be addressed is Ben’s and EKR's.
>>> We have to be careful about ossification.
>>>
>>
>> In order to address the comments on ossification, we added a new section
>> 6 to explain the rules to processing the MUD (D)TLS rules to handle unknown
>> TLS parameters and updated Section 10 to enable faster update to the YANG
>> module. Please see
>> https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt
>>
>> -Tiru
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A suggestion for handling large key shares

[tirumal reddy]

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 ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah,
> a server which aims to prefer P256+ML-KEM over P256 should, well, prefer
> P256+ML-KEM over P256. :-) See the discussions around
> draft-davidben-tls-key-share-prediction. In particular, RFC 8446 is clear
> on the semantics of such a ClientHello:
>
>This vector MAY be empty if the client is requesting a
>HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a
>group offered in the "supported_groups" extension and MUST appear in
>the same order.  However, the values MAY be a non-contiguous subset
>of the "supported_groups" extension and MAY omit the most preferred
>groups.  Such a situation could arise if the most preferred groups
>are new and unlikely to be supported in enough places to make
>pregenerating key shares for them efficient.
>
> rfc8446bis contains further clarifications:
> https://github.com/tlswg/tls13-spec/pull/1331
>
> Now, some servers (namely OpenSSL) will instead unconditionally select
> from key_share first. This isn't wrong, per se. It is how you implement a
> server which believes all of its supported groups are of comparable
> security level and therefore prioritizes round trips. Such a policy is
> plausible when you only support, say, ECDH curves. It's not so reasonable
> if you support both ECDH and a PQ KEM. But all the spec text for that is in
> place, so all that is left is that folks keep this in mind when adding PQ
> KEMs to a TLS implementation. A TLS stack that always looks at key_share
> first is not PQ-ready and will need some changes before adopting PQ KEMs.
>
> Regarding the other half of this:
>
> > Suppose we have a client that supports both P-256 and P256+ML-KEM.  What
> the client does is send a key share for P-256, and also indicate support
> for P256+ML-KEM.  Because we’re including only the P256 key share, the
> client hello is short
>
> I don't think this is a good tradeoff and would oppose such a SHOULD here.
> PQ KEMs are expensive as they are. Adding a round-trip to it will only make
> it worse. Given the aim is to migrate the TLS ecosystem to PQ, penalizing
> the desired state doesn't make sense. Accordingly, Chrome's Kyber
> deployment includes X25519Kyber768 in the initial ClientHello. While this
> does mean paying an unfortunate upfront cost, this alternative would
> instead disincentivize servers from deploying post-quantum protections.
>
> If you're interested in avoiding the upfront cost, see
> draft-davidben-tls-key-share-prediction-01. That provides a mechanism for
> clients to predict more accurately, though it's yet to even be adopted, so
> it's a bit early to rely on that one. Note also the Security Considerations
> section, which further depends on the server expectations above.
>

The scenario of handling large key sizes is disussed in
https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-02.html#section-4

-Tiru


>
> David
>
> On Tue, Mar 19, 2024 at 2:47 PM Scott Fluhrer (sfluhrer)  40cisco@dmarc.ietf.org> wrote:
>
>> Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and
>> me) about a suggestion about one way to potentially improve the performance
>> (in the ‘the server hasn’t upgraded yet’ case), and asked if we should add
>> that suggestion to our draft.  It occurs to me that this suggestion is
>> equally applicable to the pure ML-KEM draft (and future PQ drafts as well);
>> hence putting it in our draft might not be the right spot.
>>
>>
>>
>> Here’s the core idea (Matt’s original scenario was more complicated):
>>
>>
>>
>>- Suppose we have a client that supports both P-256 and P256+ML-KEM.
>>What the client does is send a key share for P-256, and also indicate
>>support for P256+ML-KEM.  Because we’re including only the P256 key share,
>>the client hello is short
>>- If the server supports only P256, it accepts it, and life goes on
>>as normal.
>>- 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.
>>
>>
>>
>> Hence, the non-upgraded scenario has no performance hit; the upgraded
>> scenario does (because of the second round trip), but we’re transmitting
>> more data anyways (and the client could, if it communicates with the server
>> again, lead off with the proposal that was accepted last time).
>>
>>
>>
>> Matt’s suggestion was that this should be a SHOULD in our draft.
>>
>>
>>
>> My questions to you: a) do you agree with this suggestion, and b) if so,
>> where should this SHOULD live?  Should it be in our draft

[TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS

[tirumal reddy]

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 has been revised a few times since IETF 119 to incorporate
> list feedback. This message is to judge consensus on whether there is
> support to adopt this I-D. If you support adoption and are willing to
> review and contribute text, please send a message to the list. If you do
> not support adoption of this draft, please send a message to the list and
> indicate why. This call will close on November 7, 2024.
>
> Thanks,
> Deirdre, Joe, and Sean
>
> [0]
> https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
> [1]
> https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00
> [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/
> [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[tirumal reddy]

On Sun, 3 Nov 2024 at 22:51, John Mattsson 
wrote:

> Russ Housley wrote:
>
> >Thanks for doing this work.  I hope the TLS WG will promptly adopt it.
>
> +1
>
>
>
> ”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 generation and
> signing. They have *slower* verification.
>

Good catch, fixed.

-Tiru


>
>
> Cheers,
>
> John
>
>
>
> *From: *Peter C 
> *Date: *Sunday, 3 November 2024 at 17:49
> *To: *tirumal reddy 
> *Cc: *IETF TLS 
> *Subject: *[TLS] Re: New Version Notification for
> draft-tls-reddy-slhdsa-00.txt
>
> Tiru,
>
>
>
> Is SLH-DSA considered a practical option for TLS end-entity certificates?
>
>
>
> Under realistic network conditions, TLS handshakes with full SLH-DSA
> certificate chains seem to be about 5-10 times slower than traditional
> certificate chains and, in some cases, can take on the order of seconds.
> See, for example, the results in https://eprint.iacr.org/2020/071,
> https://eprint.iacr.org/2021/1447, https://mediatum.ub.tum.de/1728103 and
> https://thomwiggers.nl/post/tls-measurements/.
>
>
>
> I agree that there’s an argument for using SLH-DSA in root certificates,
> but I’m surprised it’s being proposed for the full chain.
>
>
>
> Peter
>
>
>
> *From:* Russ Housley 
> *Sent:* 03 November 2024 11:13
> *To:* tirumal reddy 
> *Cc:* IETF TLS 
> *Subject:* [TLS] Re: New Version Notification for
> draft-tls-reddy-slhdsa-00.txt
>
>
>
> Thanks for doing this work.  I hope the TLS WG will promptly adopt it.
>
>
>
> Russ
>
>
>
> On Nov 2, 2024, at 8:15 PM, tirumal reddy  wrote:
>
>
>
> 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
> Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt
> To: Tirumaleswar Reddy.K , John Gray <
> john.g...@entrust.com>, Scott Fluhrer , Timothy
> Hollebeek 
>
>
>
> A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been
> successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name: draft-tls-reddy-slhdsa
> Revision: 00
> Title:Use of SLH-DSA in TLS 1.3
> Date: 2024-11-02
> Group:Individual Submission
> Pages:8
> URL:  https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa
>
> Abstract:
>
>This memo specifies how the post-quantum signature scheme SLH-DSA
>[FIPS205] is used for authentication in TLS 1.3.
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[tirumal reddy]

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
>
> > generation and signing. They have *slower* verification.
>
>
>
> Also:
>
>
>
>   “This document specifies the use of the SLH-DSA algorithm in
>
>TLS at three security levels.  It includes the small (S) or
>
>fast (F) versions of the algorithm and allows for the use of
>
>either SHA-256 [FIPS180] or SHAKE256 [FIPS202] as the hash
>
>function.”
>
>
>
> The SHA2 parameter sets for security categories 3 and 5 use a
>
> mixture of SHA-256 and SHA-512.  This means that you probably
>
> want to rename the SignatureScheme entries to
>

Agreed and we will address this in the next revision.

-Tiru


>
>
>enum {
>
>  slhdsa128s_sha2  (0x0911),
>
>  slhdsa128f_sha2  (0x0912),
>
>  slhdsa192s_sha2  (0x0913),
>
>  slhdsa192f_sha2  (0x0914),
>
>  slhdsa256s_sha2  (0x0915),
>
>  slhdsa256f_sha2  (0x0916),
>
>  ...
>
>} SignatureScheme;
>
>
>
> Peter
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[tirumal reddy]

Hi Peter,

Please see inline

On Sun, 3 Nov 2024 at 22:17, Peter C  wrote:

> Tiru,
>
>
>
> Is SLH-DSA considered a practical option for TLS end-entity certificates?
>
>
>
> Under realistic network conditions, TLS handshakes with full SLH-DSA
> certificate chains seem to be about 5-10 times slower than traditional
> certificate chains and, in some cases, can take on the order of seconds.
> See, for example, the results in https://eprint.iacr.org/2020/071,
> https://eprint.iacr.org/2021/1447, https://mediatum.ub.tum.de/1728103 and
> https://thomwiggers.nl/post/tls-measurements/.
>
>
>
> I agree that there’s an argument for using SLH-DSA in root certificates,
> but I’m surprised it’s being proposed for the full chain.
>

SLH-DSA is not proposed for the end-entity certificates, it is preferred
for CA certificates (please see the 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 for
> draft-tls-reddy-slhdsa-00.txt
>
>
>
> Thanks for doing this work.  I hope the TLS WG will promptly adopt it.
>
>
>
> Russ
>
>
>
> On Nov 2, 2024, at 8:15 PM, tirumal reddy  wrote:
>
>
>
> 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
> Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt
> To: Tirumaleswar Reddy.K , John Gray <
> john.g...@entrust.com>, Scott Fluhrer , Timothy
> Hollebeek 
>
>
>
> A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been
> successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name: draft-tls-reddy-slhdsa
> Revision: 00
> Title:Use of SLH-DSA in TLS 1.3
> Date: 2024-11-02
> Group:Individual Submission
> Pages:8
> URL:  https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
> HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa
>
> Abstract:
>
>This memo specifies how the post-quantum signature scheme SLH-DSA
>[FIPS205] is used for authentication in TLS 1.3.
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[tirumal reddy]

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
> > authentication in TLS 1.3.
>
> I think the context to use should be taken as open question and
> resolved together with ML-DSA.
>

Providing guidance on the use of context would be helpful for all protocols
that utilize PQC signatures. I don't see any of the protocols using
SLH-DSA/ML-DSA leverage the context—for instance, it is set to an empty
string in draft-ietf-lamps-cms-sphincs-plus, draft-ietf-lamps-x509-slhdsa,
and draft-ietf-cose-sphincs-plus (where use of context is not specified).

-Tiru


> After all, ML-DSA and SLH-DSA share the interface design, which is
> beyond the capabilities of Ed25519ctx and Ed448, let alone Ed25519.
>
> And with regards to precedent, Ed25519 does not support contexts.
> Ed25519ctx is the version where I hacked in context support, but
> very few things support that. Ed448 does have native context
> support, but much of code treats it just as larger Ed25519.


>
>
>
> -Ilari
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt

[tirumal reddy]

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: Sun, 3 Nov 2024 at 05:33
Subject: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-tls-reddy-composite-mldsa-00.txt has
been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-tls-reddy-composite-mldsa
Revision: 00
Title:Use of Composite ML-DSA in TLS 1.3
Date: 2024-11-02
Group:Individual Submission
Pages:8
URL:
https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
HTML:
https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-tls-reddy-composite-mldsa


Abstract:

   This document specifies how the post-quantum signature scheme ML-DSA
   [FIPS204], in combination with traditional algorithms RSA-
   PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
   authentication in TLS 1.3.  The composite ML-DSA approach is
   beneficial in deployments where operators seek additional protection
   against potential breaks or catastrophic bugs in ML-DSA.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-tls-reddy-slhdsa-00.txt

[tirumal reddy]

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
Subject: New Version Notification for draft-tls-reddy-slhdsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-tls-reddy-slhdsa-00.txt has been
successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-tls-reddy-slhdsa
Revision: 00
Title:Use of SLH-DSA in TLS 1.3
Date: 2024-11-02
Group:Individual Submission
Pages:8
URL:  https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-tls-reddy-slhdsa/
HTML: https://www.ietf.org/archive/id/draft-tls-reddy-slhdsa-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-tls-reddy-slhdsa


Abstract:

   This memo specifies how the post-quantum signature scheme SLH-DSA
   [FIPS205] is used for authentication in TLS 1.3.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt

[tirumal reddy]

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 algorithms can be
> used
> > for authentication in TLS 1.3.
> >
>
> Important details, such as how signature are encoded seems to be
> missing.
>
>
> And I think this is very premature. As far as I can tell, there are
> major unaddressed issues with hybrid signatures. Those issues need to
> be settled first before adding any codepoints.
>
> Having multiple variants of the same hybrid signature is not acceptable
> due to severe security risks from overloading crypto library authors.
>
> Furthermore, the encodings used by draft-ietf-lamps-pq-composite-sigs
> add additional security risks. Modern crypto design uses byte string
> I/O for safety.
>

This issue is being discussed in the LAMPS WG; the composite signature API
should avoid using protocol-specific encoding.

-Tiru


>
> Currently, only bare ML-DSA and SLH-DSA are usable for post-quantum
> signature authentication. Seems that the only question that does not
> have an obvious answer is the context to use.
>
>
>
>
> -Ilari
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Fwd: New Version Notification for draft-tls-reddy-composite-mldsa-00.txt

[tirumal reddy]

On Mon, 4 Nov 2024 at 19:47, Alicja Kario  wrote:

> Hello,
>
> I don't think we should go back to signing with PKCS#1 v1.5 in TLSv1.3.


> I'm opposed to including those two IDs:
>
>  mldsa44_rsa_pkcs1_sha256 (0x090C),
>  mldsa65_rsa_pkcs1_sha384 (0x090D),
>

I wanted to remove them but I see TLS 1.3 allows rsa_pkcs1 for certificates
but not for certificate verification and it is mandatory to implement
digital signature. I will update the draft to restrict its use to
the "signature_algorithms_cert" extension.

-Tiru


>
> Theoretically 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
> > 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: Sun, 3 Nov 2024 at 05:33
> > Subject: New Version Notification for
> draft-tls-reddy-composite-mldsa-00.txt
> > To: Tirumaleswar Reddy.K , John Gray
> > , Scott Fluhrer ,
> > Timothy Hollebeek 
> >
> >
> > A new version of Internet-Draft draft-tls-reddy-composite-mldsa-00.txt
> has
> > been successfully submitted by Tirumaleswar Reddy and posted to the
> > IETF repository.
> >
> > Name: draft-tls-reddy-composite-mldsa
> > Revision: 00
> > Title:Use of Composite ML-DSA in TLS 1.3
> > Date: 2024-11-02
> > Group:Individual Submission
> > Pages:8
> > URL:
> > https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-tls-reddy-composite-mldsa/
> > HTML:
> >  https://www.ietf.org/archive/id/draft-tls-reddy-composite-mldsa-00.html
> > HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-tls-reddy-composite-mldsa
> >
> >
> > Abstract:
> >
> >This document specifies how the post-quantum signature scheme ML-DSA
> >[FIPS204], in combination with traditional algorithms RSA-
> >PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
> >authentication in TLS 1.3.  The composite ML-DSA approach is
> >beneficial in deployments where operators seek additional protection
> >against potential breaks or catastrophic bugs in ML-DSA.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[tirumal reddy]

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
> address
> > them.
>
> I think it would be better to have a footnote for the two
> SignatureScheme values that are not allowed in signature_algorithms than
> adding a whole new column. The TLS ExtensionType Values already has such
> footnote for non-standard behavior in where the ech_outer_extensions
> extension can appear.
>

Sure, added a footnote.


>
> However, I do not think it is clear if clent is allowed to send the
> values in signature_algorithms or not. And if not, how is the server to
> handle the values appearing anyway? And the values are definitely not
> allowed to appear in CertificateVerify, but this is not stated.
>

Thanks, updated draft to provide clarification.

-Tiru


>
> As reference, TLS 1.3 does allow PKCS#1 v1.5 signatures in
> signature_algorithms, but not in CertificateVerify. And there are no
> notes in the registry about that.
>
>
>
>
> -Ilari
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

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/,
which has recently completed WGLC. If there are any objections, now is the
time to raise them within the PQUIP and LAMPS WGs.

Cheers,
-Tiru

On Sat, 23 Nov 2024 at 14:15, Ilari Liusvaara 
wrote:

> On Thu, Nov 21, 2024 at 08:45:14PM -, D. J. Bernstein wrote:
> > Blumenthal, Uri - 0553 - MITLL writes:
> > > Given how the two (KEM and DSA) are used, and what threats may exist
> > > against each of them, I think it’s perfectly fine to use PQ instead of
> > > ECC+PQ here.
> >
> > Hmmm. I don't see where your previous anti-hybrid argument
> > (
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/rL9T8mpAkMs/m/i3QKJYZbEAAJ
> )
> > distinguishes encryption from signatures.
> >
> > Are you saying that you're now in favor of hybrids for encryption but
> > not for signatures? What's the relevant difference?
>
> The risks posed by the hybrid construction itself.
>
>
> > On the pro-hybrid side, here's the common-sense argument again, where I
> > again don't see a difference between signatures and encryption:
> >
> >* With ECC+PQ encryption, an attacker with a PQ break still has to
> >  break the ECC encryption. This makes ECC+PQ less risky than PQ for
> >  encryption.
> >
> >* With ECC+PQ signatures, an attacker with a PQ break still has to
> >  break the ECC signatures. This makes ECC+PQ less risky than PQ for
> >  signatures.
>
> The argument forgets that to break ECC+PQ, the attacker has to break
> _either_:
>
> a) ECC and PQ.
> b) The hybrid construction.
>
> The risk from b) is very different for encryption and signatures.
>
> With encryption, it is small risk because the constructions are simple
> and quite resilient to flaws (outside memory safety) in real world.
>
> But with signatures, the risks become substantial because:
>
> - Complexity. Some of it to deal with known non-obvious attacks.
> - Known unknown attacks.
>
> Even just the LAMPS composite signature combiner is known to be
> cryptographically unsound. Sound signature combiners are in theory
> impossible (practical sound signature combiners might exist).
>
>
>
>
> -Ilari
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

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
> > going to announce their secret attacks?
>
> For (1) I call it not an “upgrade” (i.e., to something new and often
> untested yet), but a “downgrade” – reverting to the “old mature and
> well-tested ECC code”. Shouldn’t take long at all.
>
> For (2) – why do you assume there are no secret attacks against ECC?
> Merely because you couldn’t find one, and nobody announced it yet?
>
>
> >> then don’t move to PQ DSA until either CRQC is announced
> >
> > That would be too late. It completely fails to address the large risk of
> > quantum attacks happening before the first public attack demos, plus it
> > leaves users vulnerable during the upgrade period.
>
> You don’t really need PQ DSA until CRQC is here. At this point, everybody
> seems to agree that there is time before CRQC arrives. So, keep
> studying/exploring/attacking PQ DSA, and prepare code and infrastructure to
> deploy it – but use ECC for now. It will also
>
The deployment timeline for new algorithms and standards is lengthy. For
instance, once an IETF specification is standardized, it typically takes
around 1.5 years for 3GPP to incorporate it into their release cycle. After
that, product teams require several months for development and testing.
Additionally, operators often adopt these updates gradually, which extends
the timeline further. Moreover, it may not always be feasible to easily
tweak configurations to enable/disable algorithms dynamically when CRQCs
become publicly known. We would like to also consider the potential impact
of zero-day vulnerabilities, where exploits are discovered and used before
vulnerabilities are publicly disclosed. Proactive preparation and
deployment of hybrid signature schemes reduces the risk of being caught
unprepared in such deployments.

-Tiru


> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-01.txt

[tirumal reddy]

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 draft-reddy-tls-composite-mldsa-01.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-reddy-tls-composite-mldsa-01.txt has
been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-tls-composite-mldsa
Revision: 01
Title:Use of Composite ML-DSA in TLS 1.3
Date: 2024-11-26
Group:Individual Submission
Pages:10
URL:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-01.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
HTML:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-01.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-reddy-tls-composite-mldsa-01

Abstract:

   This document specifies how the post-quantum signature scheme ML-DSA
   [FIPS204], in combination with traditional algorithms RSA-
   PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
   authentication in TLS 1.3.  The composite ML-DSA approach is
   beneficial in deployments where operators seek additional protection
   against potential breaks or catastrophic bugs in ML-DSA.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[tirumal reddy]

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.

Best Regards,
-Tiru

-- Forwarded message -
From: 
Date: Thu, 14 Nov 2024 at 16:55
Subject: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-reddy-tls-composite-mldsa-00.txt has
been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-tls-composite-mldsa
Revision: 00
Title:Use of Composite ML-DSA in TLS 1.3
Date: 2024-11-14
Group:Individual Submission
Pages:8
URL:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
HTML:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa


Abstract:

   This document specifies how the post-quantum signature scheme ML-DSA
   [FIPS204], in combination with traditional algorithms RSA-
   PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
   authentication in TLS 1.3.  The composite ML-DSA approach is
   beneficial in deployments where operators seek additional protection
   against potential breaks or catastrophic bugs in ML-DSA.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[tirumal reddy]

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 draft aligns with CNSA 2.0.
>
> Could supporters of the draft elaborate on the rationale to favor or
> exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in
> another draft?
>
The hybrid ML-DSA draft (see
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/) was
published before the standalone ML-DSA and we published a revised draft to
address the comments from the WG.

-Tiru


> On Fri, Nov 15, 2024 at 9:13 AM John Mattsson  40ericsson@dmarc.ietf.org> wrote:
>
>> >I'm unenthusiastic but don't strongly oppose adoption of this and
>>
>> >similar drafts, mostly because I think we should try get some WG
>>
>> >consensus on guidance for when these things may be needed (if ever)
>>
>> >and what the consequences might be should people deploy 'em in the
>>
>> >meantime. (By 'em I mean anything with any kind of PQ sig or non
>>
>> >hybrid PQ key exchange.) That guidance might or might not be in a
>>
>> >separate document, or be copied into each relevant one.
>>
>>
>>
>> More discussion would certainly be welcome. IPSECME is discussing what
>> the right solution for hybrid PQC authentication is. The two proposals are
>> composite public keys and signatures in a single certificate chain vs. two
>> certificate chains. Both approaches have benefits and disadvantages. TLS
>> should have the same discussion. Using two certificate chains is already
>> possible in TLS with Post-Handshake Certificate-Based Client
>> Authentication. Post-Handshake Certificate-Based Server Authentication
>> should be added anyway as it is needed for long lasting TLS connections in
>> infrastructure.
>>
>> WebPKI might want to wait but the many infrastructure use cases of TLS,
>> DTLS, and QUIC need to migrate very soon. US government new requirement is
>> that pure RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European
>> countries have similar recommendations/requirements. Country to an earlier
>> comment on the list, industry does not like new shiny tools, to the
>> contrary, industry loves using existing stuff if possible.
>>
>> https://csrc.nist.gov/pubs/ir/8547/ipd
>>
>>
>> https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
>>
>> >but don't strongly oppose adoption
>>
>> Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and
>> JOSE. Any further delay would likely end up in a lot of LSs from various
>> infrastructure SDOs urging IETF to specify quantum-resistant authentication
>> in TLS ;)
>>
>>
>>
>> Cheers,
>>
>> John
>>
>>
>>
>> *From: *Stephen Farrell 
>> *Date: *Friday, 15 November 2024 at 17:46
>> *To: *Bas Westerbaan , tls@ietf.org
>> 
>> *Subject: *[TLS] Re: ML-DSA in TLS
>>
>>
>>
>> On 15/11/2024 10:51, Bas Westerbaan wrote:
>> > We have posted a -00.
>> >
>> >
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0
>> 
>>
>> I'm unenthusiastic but don't strongly oppose adoption of this and
>> similar drafts, mostly because I think we should try get some WG
>> consensus on guidance for when these things may be needed (if ever)
>> and what the consequences might be should people deploy 'em in the
>> meantime. (By 'em I mean anything with any kind of PQ sig or non
>> hybrid PQ key exchange.) That guidance might or might not be in a
>> separate document, or be copied into each relevant one.
>>
>> Cheers,
>> S.
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

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 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 16.2KB
>> per signature at the AES-192 security level. In addition to size concerns,
>> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
>> purpose?
>>
>
> If CNSA 2.0 is the guide why consider hybrids?
>
>> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-reddy-tls-slhdsa-00.txt

[tirumal reddy]

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

-- Forwarded message -
From: 
Date: Fri, 15 Nov 2024 at 18:12
Subject: New Version Notification for draft-reddy-tls-slhdsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-reddy-tls-slhdsa-00.txt has been
successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-tls-slhdsa
Revision: 00
Title:Use of SLH-DSA in TLS 1.3
Date: 2024-11-15
Group:Individual Submission
Pages:8
URL:  https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
HTML: https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-tls-slhdsa


Abstract:

   This memo specifies how the post-quantum signature scheme SLH-DSA
   [FIPS205] is used for authentication in TLS 1.3.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

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 16.2KB
> per signature at the AES-192 security level. In addition to size concerns,
> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
> purpose?
>

Yes, we are considering SPHINCS+ for long-lived TLS sessions in telco
deployments for interfaces where computational costs of signature
generation and validation are minor compared to data transmission and
processing demands of user data. The findings in Amazon

paper

shows that while PQ algorithms increase the TLS 1.3 handshake data size,
their effect on connection performance is minimal for large data transfers,
especially in low-loss networks.

-Tiru


> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-reddy-uta-pqc-app-05.txt

[tirumal reddy]

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 -
From: 
Date: Thu, 30 Jan 2025 at 10:40
Subject: New Version Notification for draft-reddy-uta-pqc-app-05.txt
To: Tirumaleswar Reddy.K , Hannes Tschofenig <
hannes.tschofe...@gmx.net>


A new version of Internet-Draft draft-reddy-uta-pqc-app-05.txt has been
successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-uta-pqc-app
Revision: 05
Title:Post-Quantum Cryptography Recommendations for TLS-based
Applications
Date: 2025-01-30
Group:Individual Submission
Pages:17
URL:  https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-05.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/
HTML: https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-uta-pqc-app
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-reddy-uta-pqc-app-05

Abstract:

   Post-quantum cryptography presents new challenges for applications,
   end users, and system administrators.  This document highlights the
   unique characteristics of applications and offers best practices for
   implementing quantum-ready usage profiles in applications that use
   TLS and key supporting protocols such as DNS.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Secdir last call review of draft-ietf-tls-svcb-ech

[tirumal reddy]

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.
Document editors and WG chairs should treat these comments just like any
other
last-call comments.

1. A SVCB RRSet containing some RRs with "ech" and some without is
   vulnerable to a downgrade attack: a network intermediary can block
   connections to the endpoints that support ECH, causing the client to
   fall back to a non-ECH endpoint.  This configuration is NOT
   RECOMMENDED.

Comment> Please mention scenarios where such mixed behavior may be
acceptable. Highlighting the exceptions would be helpful.

2. ECH ensures that TLS does not disclose the SNI, but the same
   information is also present in the DNS queries used to resolve the
   server's hostname.  This specification does not conceal the server
   name from the DNS resolver.  If DNS messages are sent between the
   client and resolver without authenticated encryption, an attacker on
   this path can also learn the destination server name.  A similar
   attack applies if the client can be linked to a request from the
   resolver to a DNS authority.

Comment> While authenticated encryption provides protection against active
attackers, the privacy benefits are negated if the DNS resolver itself is
malicious. It may be useful to recommend using trusted DNS resolvers.

3. It will be helpful to provide recommendations to endpoint
implementations not to mislead end-users that "ECH" would provide the same
level of security fully anonymizing solutions like Tor,  "ECH" may not
provide any privacy because of the reasons discussed in 2nd paragraph of
Security Considerations Section.

4. The discussion on the anonymity set could benefit from examples or
references that illustrate how traffic analysis might narrow it.

5. The behaviour recommendation for middleboxes acting as a TLS proxy
should be discussed.

Cheers,
-Tiru
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

[tirumal reddy]

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 this WG often turn nasty, so we would like to
> remind everyone to keep it civil while we explain our thinking WRT recent
> requests for WG adoptions of some PQ-related I-Ds.
>
> Also, the chairs are trying to gather information here, not actually do
> the calls. If we decide to do them we will do them in the new year.
>
> Background:
>
> Currently, the TLS WG has adopted one I-D related to PQ:
> Hybrid key exchange in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
> This I-D provides a construction for hybrid key exchange in the TLS 1.3.
> The I-D has completed WG last call and is about to progress to IETF LC.
>
> There are a number of Individual I-Ds that specify PQ cipher suite for TLS
> currently being developed that specify either “pure” PQ or composite/hybrid:
>
> ML-KEM Post-Quantum Key Agreement for TLS 1.3;
>   see
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> PQ hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,
>   see https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
> Use of Composite ML-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> Use of SLH-DSA in TLS 1.3;
>   see https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>
> The IANA requests for code points in the I-Ds (now) all have the same
> setting for the “Recommended” column; namely, they request that the
> Recommended column be set to “N”. As a reminder (from RFC 8447bis), “N”:
>
>   Indicates that the item has not been evaluated by the IETF and
>   that the IETF has made no statement about the suitability of the
>   associated mechanism.  This does not necessarily mean that the
>   mechanism is flawed, only that no consensus exists.  The IETF
>   might have consensus to leave  items marked as "N" on the basis
>   of it having limited applicability or usage constraints.
>
> With an “N”, the authors are free to request code points from IANA without
> working group adoption. Currently, five code points have been assigned; 3
> for ML-KEM and 2 for ECDHE-MLKEM.
>
> While there have been calls to run WG adoption calls for these I-Ds, the
> WG chairs have purposely NOT done so. The WG consensus, as we understand
> it, is that because the IANA rules permit registrations in the
> Specification Required with an I-D that there has been no need to burden
> the WG; there is, obviously, still some burden because the I-Ds are
> discussed on-list (and yes there have been some complaints about the volume
> of messages about these cipher suites).
>
> There are a couple of other reasons:
>
> * The ADs are formulating a plan for cipher suites; see
> https://datatracker.ietf.org/doc/draft-pwouters-crypto-current-practices/.
>
> * There are a lot of different opinions and that likely leads to a lack of
> consensus. Based on discussions at and since Brisbane, we do not think
> there will be consensus to mark these ciphersuites as "Y" at this point,
> however the working group can take action to do so in the future.
>
> * There have been a few calls to change the MTI (Mandatory to Implement)
> algorithms in TLS, but in July 2024 at IETF 120 the WG consensus was that
> draft-ietf-tls-rfc8446bis would not be modified to add an additional
> ciphersuite because the update was for clarifications.
>
> * Adopting these or some subset of these I-Ds, will inevitably result in
> others requesting code points too. The WG has historically not been good
> about progressing cipher suite related I-Ds, either the discussion rapidly
> turns unproductive or interest wanes during the final stages in the
> publication process. So while there is great interest (based on the number
> of messages to the list) about these I-Ds, we are unsure how to avoid the
> inevitable complaints that would follow failure to adopt or not adopt a
> specific I-D based on different requirements of different individuals.We
> know some of you are thinking that that’s “tough”, but if we do not need to
> have this fight, see the previous paragraph, we do not see the harm in
> avoiding these complaints.
>
> The chairs would also like to note that currently the WG consensus is to
> NOT port PQ cipher suites back to (D)TLS 1.2.
>
> Ask:
>
> Is the WG consensus to run four separate adoption calls for the individual
> I-Ds in question?
>
> The Chairs,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[tirumal reddy]

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 address
them.

Cheers,
-Tiru

On Mon, 18 Nov 2024 at 20:44, Alicja Kario  wrote:

> Thanks for the work on this document, it's highly appreciated!
>
> Few comments:
>  - If we allow for pkcs#1v1.5 sig schemes in signatures_algorithms_cert but
>not in signatures_algorithms I think we should, at the very least,
>ask IANA to add a column to the SignatureScheme namespace that
>includes that information
>  - while the descriptive text does say PKCS#1v1.5 schemes shouldn't be in
>signature_algorithms, it doesn't specify peer behaviour if the other
>side of the connection misbehaves ("MAY abort connection with
>illegal_parameter if it's included in Client Hello or Certificate
>Request signature_algorithms extension" and "MUST abort the connection
>with an illegal_parameter alert if it's used in Certificate Verify
>message"?)
>  - while the mapping for Schemes to OIDs in
> draft-ietf-lamps-pq-composite-sigs
>for ECDSA and EdDSA is clear and 1-to-1, that's not the case for RSA.
>The draft-ietf-lamps-pq-composite-sigs specifies RSA with specific key
>sizes, and for example we have both id-HashMLDSA65-RSA3072-PSS-SHA512
>and id-HashMLDSA65-RSA4096-PSS-SHA512... which one should be used with
>mldsa65_rsa_pss_pss_sha384?
>  - same for the hash function, the draft-ietf-lamps-pq-composite-sigs uses
>SHA-512 for the combinations with ML-DSA65, while this draft specifies
>SHA-384... I think they should be aligned and identical: the
>draft-ietf-lamps-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,
> >
> > 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.
> >
> > Best Regards,
> > -Tiru
> >
> > -- Forwarded message -
> > From: 
> > Date: Thu, 14 Nov 2024 at 16:55
> > Subject: New Version Notification for
> draft-reddy-tls-composite-mldsa-00.txt
> > To: Tirumaleswar Reddy.K , John Gray
> > , Scott Fluhrer ,
> > Timothy Hollebeek 
> >
> >
> > A new version of Internet-Draft draft-reddy-tls-composite-mldsa-00.txt
> has
> > been successfully submitted by Tirumaleswar Reddy and posted to the
> > IETF repository.
> >
> > Name: draft-reddy-tls-composite-mldsa
> > Revision: 00
> > Title:Use of Composite ML-DSA in TLS 1.3
> > Date: 2024-11-14
> > Group:Individual Submission
> > Pages:8
> > URL:
> > https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> > HTML:
> >  https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.html
> > HTMLized:
> > https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa
> >
> >
> > Abstract:
> >
> >This document specifies how the post-quantum signature scheme ML-DSA
> >[FIPS204], in combination with traditional algorithms RSA-
> >PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
> >authentication in TLS 1.3.  The composite ML-DSA approach is
> >beneficial in deployments where operators seek additional protection
> >against potential breaks or catastrophic bugs in ML-DSA.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
>
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[tirumal reddy]

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 [1]. If you support
> adoption and are willing to review and contribute text, please send a
> message to the list. If you do not support adoption of this draft, please
> send a message to the list and indicate why. This call will close at 2359
> UTC on 15 April 2025.
>
> In response to other WG adoption calls, Dan Bernstein pointed out some
> potential IPR (see [2]), but no IPR disclosure has been made in accordance
> with BCP 79.  Additional information is provided here; see [3].
>
> BCP 79 makes this important point:
>
>   (b) The IETF, following normal processes, can decide to use
> technology for which IPR disclosures have been made if it decides
> that such a use is warranted.
>
> WG members can take this information into account during this adoption
> call to determine if we should adopt these drafts.
>
> Reminder:  This call for adoption has nothing to do with picking the
> mandatory-to-implement cipher suites in TLS.
>
> Cheers,
> Joe and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
> [1]
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> [2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
> [3]
> https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3

[tirumal reddy]

I support adoption and I will review it.

-Tiru

On Tue, 15 Apr 2025 at 23:04, Sean Turner  wrote:

> We are continuing with our WG adoption calls for the following I-D:
> Use of ML-DSA in TLS 1.3 [1]; see [2] for more information about this
> tranche of adoption calls. If you support adoption and are willing to
> review and contribute text, please send a message to the list. If you do
> not support adoption of this draft, please send a message to the list and
> indicate why. This call will close at 2359 UTC on 29 April 2025.
>
> Reminder:  This call for adoption has nothing to do with picking the
> mandatory-to-implement cipher suites in TLS.
>
> Cheers,
> Joe and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-tls-westerbaan-mldsa/
> [2] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Fwd: New Version Notification for draft-reddy-uta-pqc-app-06.txt

[tirumal reddy]

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 Regards,
-Tiru

-- Forwarded message -
From: 
Date: Mon, 17 Feb 2025 at 12:12
Subject: New Version Notification for draft-reddy-uta-pqc-app-06.txt
To: Tirumaleswar Reddy.K , Hannes Tschofenig <
hannes.tschofe...@gmx.net>


A new version of Internet-Draft draft-reddy-uta-pqc-app-06.txt has been
successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-uta-pqc-app
Revision: 06
Title:Post-Quantum Cryptography Recommendations for TLS-based
Applications
Date: 2025-02-17
Group:Individual Submission
Pages:19
URL:  https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-06.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-uta-pqc-app/
HTML: https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-06.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-uta-pqc-app
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-reddy-uta-pqc-app-06

Abstract:

   Post-quantum cryptography presents new challenges for applications,
   end users, and system administrators.  This document highlights the
   unique characteristics of applications and offers best practices for
   implementing quantum-ready usage profiles in applications that use
   TLS and key supporting protocols such as DNS.



The IETF Secretariat
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

In SDOs like 3GPP SA3, progressing technical reports (TRs) requires a stable
reference, typically in the form of an RFC. Publishing a WG document
and eventually
an RFC would make SLH-DSA a candidate for consideration in ongoing work within
3GPP.

-Tiru

On Fri, 16 May 2025 at 22:20, Eric Rescorla  wrote:

>
>
> On Fri, May 16, 2025 at 9:27 AM Simon Josefsson  40josefsson@dmarc.ietf.org> wrote:
>
>> I support adoption -- I think it is important to have conservatively
>> designed PQ-safe cryptographic algorithms (Sphincs+, Classic McEliece,
>> etc) widely available as fallback.  Having them available takes away
>> some arguments against deploying less conservative designed PQ
>> algorithms that I'm seeing.
>>
>
> Following up on Rich and Richard, I'd like to push on what "available"
> means
> in this context. In what way will publishing an RFC make this algorithm
> more available? For instance, are there entities who will implement and/or
> deploy SL-DSA in that case that would not otherwise? If so, I'd like to
> hear
> from them.
>
> -Ekr
>
>
>> /Simon
>>
>> Sean Turner  writes:
>>
>> > We are continuing with our WG adoption calls for the following I-D:
>> > Use of SLH-DSA in TLS 1.3 [1]; see [2] for more information about this
>> > tranche of adoption calls. If you support adoption and are willing to
>> > review and contribute text, please send a message to the list. If you
>> > do not support adoption of this draft, please send a message to the
>> > list and indicate why. This call will close at 2359 UTC on 30 May
>> > 2025.
>> >
>> > Reminder:  This call for adoption has nothing to do with picking the
>> mandatory-to-implement cipher suites in TLS.
>> >
>> > Cheers,
>> > Joe and Sean
>> >
>> > [1] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>> > [2]
>> https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
>> > ___
>> > TLS mailing list -- tls@ietf.org
>> > To unsubscribe send an email to tls-le...@ietf.org
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

We would like to leverage SLH-DSA in 3GPP deployments, particularly for
long-lived connections. While SLH-DSA increases the size of the TLS
1.3 handshake,
its impact on connection performance is minimal in the context of large data
transfers, especially over low-loss networks.

-Tiru

On Fri, 16 May 2025 at 20:50, Salz, Rich 
wrote:

> I am not thrilled about adoption, for the reasons that EKR and Panos said.
> Further, I am concerned about us going back to the old days of “register
> every algorithm” which took years to evolve away from.
>
>
>
> We can assign code points based on drafts and let the world experiment.
>
>
>
> Can the authors -- or anyone actually -- provide a specific example of
> where they WANT to use SLH-DSA?  Not COULD as the draft currently says.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Mon, 19 May 2025 at 17:24, Viktor Dukhovni 
wrote:

> On Mon, May 19, 2025 at 01:29:40PM +0200, Filippo Valsorda wrote:
>
> > 2025-05-19 12:41 GMT+02:00 John Mattsson :
>
> > > OpenSSL 3.5 has already shipped with the Values 0x0911 – 0x91C that
> > > are in the draft.
> >
> > Frankly, this is a bit irritating, especially given the precedent of
> > seed encodings, where we all got saddled with a fractal encoding to
> > appease the "legacy" of a handful of early adopters. Now OpenSSL ships
> > a production feature in a LTS version with 12 commandeered
> > unregistered codepoints from the public range. Ok.
>
> OpenSSL 3.5 DOES NOT have TLS codepoints for SLH-DSA.  I don't know
> where John Mattsson got that impression.  The only PQ signature TLS
> codepoints in OpenSSL 3.5 are:
>
>
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme
>
> 0x0904  mldsa44 N   [draft-tls-westerbaan-mldsa-00]
> 0x0905  mldsa65 N   [draft-tls-westerbaan-mldsa-00]
> 0x0906  mldsa87 N   [draft-tls-westerbaan-mldsa-00]
>

I see that OpenSSL 3.5 supports SLH-DSA (https://openssl-foundation.org/
post/2025-04-08-openssl-35-final-release/), but it is not clear which
codepoints
are used, as they have not yet been assigned by IANA.

-Tiru


>
> --
> Viktor.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

Including TLS WG mailing list.

Thanks Mike for the feedback. The long-lived TLS connections will
undergo periodic
re-authentication to check the certificate validity. In a typical 3GPP
deployment, the certificate will expire and be replaced with a new
certificate with a new key pair well before the SLH-DSA signature limit is
approached. For example, if a server certificate is valid for 1 year and each
connection re-authenticates every 12 hours, this results in approximately 730
signatures per client connection. Even when scaled to many clients, the total
number of signatures generated over the lifetime of a single key remains vastly
below the SLH-DSA signature limit

It is an important security aspect to be discussed in the draft. I will
raise PR to address it.

Cheers,
-Tiru

On Sat, 17 May 2025 at 19:30, Mike Ounsworth 
wrote:

> (my messages are not making it to the list; hoping someone will reply-all
> to get it on the record)
>
> @Martin, would you object to adoption less if there were fewer algorithms
> being registered ... like 1 or 2?
>
> @Tiru, @JohnMattsson -- My objection to this draft in its current form is
> that there is a lack of discussion about that 2^64 signature limit. I am
> aware of the size of the number "2^64", and that this simply won't be
> reached in a long-lived TLS connections, but once we allow SLH-DSA in TLS,
> it's allowed, and Moore's Law scaling over the coming decades could make it
> conceivable to see 2^64 handshakes on a single key, especially with massive
> horizontal scaling and CSR key reuse across cert renewals. How do you solve
> that? Do we require operators to roughly track the number of signatures
> performed? How? So IMO this draft NEEDS a well-worded Security
> Consideration about this limit and I want to see at least roughly what that
> text looks like as part of adoption because to me SLH-DSA is appropriate
> for TLS if and only if we can find something reasonable to say about this.
>
> On Sat, 17 May 2025 at 07:23, Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> So far we’ve heard that 3GPP is considering using this (presumably for
>> thinks like station-to-station, as it were), but they need a stable
>> reference like an RFC. I’d say that “stable reference” is their problem. Do
>> they consider the TLS registries a stable reference?
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

Hi Martin,

The draft currently proposes setting "Recommended" to "N" for all
SLH-DSA variants.
The SLH-DSA variants defined in this document are consistent with OpenSSL
3.5 (see
https://openssl-foundation.org/post/2025-04-08-openssl-35-final-release/).

Cheers,
-Tiru

On Sat, 17 May 2025 at 17:43, Martin Thomson  wrote:

> I'm opposed.  This isn't just one signature algorithm, it is 12.  All 12
> of which seem ill-suited to TLS.  I get the desire for diversity, but this
> is not the choice I'd make.
>
> On Fri, May 16, 2025, at 23:27, Sean Turner wrote:
> > We are continuing with our WG adoption calls for the following I-D: Use
> > of SLH-DSA  in TLS 1.3 [1]; see [2] for more information about this
> > tranche of adoption calls. If you support adoption and are willing to
> > review and contribute text, please send a message to the list. If you
> > do not support adoption of this draft, please send a message to the
> > list and indicate why. This call will close at 2359 UTC on 30 May 2025.
> >
> > Reminder:  This call for adoption has nothing to do with picking the
> > mandatory-to-implement cipher suites in TLS.
> >
> > Cheers,
> > Joe and Sean
> >
> > [1] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
> > [2]
> https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Wed, 21 May 2025 at 18:14, Watson Ladd  wrote:

> On Mon, May 19, 2025 at 2:30 AM tirumal reddy  wrote:
> >
> > Including TLS WG mailing list.
> >
> > Thanks Mike for the feedback. The long-lived TLS connections will
> undergo periodic re-authentication to check the certificate validity. In a
> typical 3GPP deployment, the certificate will expire and be replaced with a
> new certificate with a new key pair well before the SLH-DSA signature limit
> is approached. For example, if a server certificate is valid for 1 year and
> each connection re-authenticates every 12 hours, this results in
> approximately 730 signatures per client connection. Even when scaled to
> many clients, the total number of signatures generated over the lifetime of
> a single key remains vastly below the SLH-DSA signature limit
> >
> > It is an important security aspect to be discussed in the draft. I will
> raise PR to address it.
>
> What's the actual assumption about the authenticity of the data on
> that connection?


> This obviously is dependant on some cryptomania, even if the handshake
> authentication is in minicrypt, because we don't sign data going over
> the connection in TLS. So what's the actual gain from SLH-DSA?
>

Mike was referring to the constraint that SLH-DSA imposes a limit of
2⁶⁴ signatures
per key. I responded that the draft will address how deployments can
remain well
below this limit by issuing new certificates with new key pairs before
the threshold
is reached. The limitation relates specifically to the number of times a key
is used to produce signatures in the CertificateVerify message during the TLS
handshake and post-handshake authentication.
-Tiru


> >
> > Cheers,
> > -Tiru
> >
> > On Sat, 17 May 2025 at 19:30, Mike Ounsworth 
> wrote:
> >>
> >> (my messages are not making it to the list; hoping someone will
> reply-all to get it on the record)
> >>
> >> @Martin, would you object to adoption less if there were fewer
> algorithms being registered ... like 1 or 2?
> >>
> >> @Tiru, @JohnMattsson -- My objection to this draft in its current form
> is that there is a lack of discussion about that 2^64 signature limit. I am
> aware of the size of the number "2^64", and that this simply won't be
> reached in a long-lived TLS connections, but once we allow SLH-DSA in TLS,
> it's allowed, and Moore's Law scaling over the coming decades could make it
> conceivable to see 2^64 handshakes on a single key, especially with massive
> horizontal scaling and CSR key reuse across cert renewals. How do you solve
> that? Do we require operators to roughly track the number of signatures
> performed? How? So IMO this draft NEEDS a well-worded Security
> Consideration about this limit and I want to see at least roughly what that
> text looks like as part of adoption because to me SLH-DSA is appropriate
> for TLS if and only if we can find something reasonable to say about this.
> >>
> >> On Sat, 17 May 2025 at 07:23, Salz, Rich  40akamai@dmarc.ietf.org> wrote:
> >>>
> >>> So far we’ve heard that 3GPP is considering using this (presumably for
> thinks like station-to-station, as it were), but they need a stable
> reference like an RFC. I’d say that “stable reference” is their problem. Do
> they consider the TLS registries a stable reference?
> >>>
> >>> ___
> >>> TLS mailing list -- tls@ietf.org
> >>> To unsubscribe send an email to tls-le...@ietf.org
> >
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
>
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Wed, 21 May 2025 at 15:59, Alicja Kario  wrote:

> On Tuesday, 20 May 2025 21:08:51 CEST, Viktor Dukhovni wrote:
> > On Tue, May 20, 2025 at 07:31:23PM +0200, Alicja Kario wrote:
> >
> >> I would like to point out that we need the same kind of
> >> codepoints no matter
> >> if we want to use SLH-DSA in the end entity certificates or in CA
> >> certificates.
> >
> > This assumes that one bothers signalling support for certificate
> > signature algorithms separately from TLS signature algorithms.  AFAIK,
> > that's rarely done in practice.  If SLH-DSA is not enabled for signing
> > the certiificate verify message, I don't expect to see it supported in
> > CA certificates either, at least in the near term.
>
> you're talking about implementation details, I'm talking about operational
> requirements
>
> yes, it may mean the "unfortunate" reality that we need to have
> speficication
> for use of it in CertificateVeriy when the "primary" use case is for certs,
> but as it was already discussed on the list, there are groups that are
> willing
> to pay the performance penalty even for CertificateVerify, so separating
> those definitions isn't really solving anything
>

The draft discusses trade-offs in detail and the SLH-DSA suitability for CA
certs, see
https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-01.html#section-2.
The overhead of sending intermediate certificates can be avoided by using
techniques like ietf-tls-cert-abridge or draft-kampanakis-tls-scas-latest.

-Tiru


> --
> Regards,
> Alicja Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

3GPP makes use of both TLS and DTLS across several interfaces, as part of its
security architecture. For a detailed overview of cryptographic inventory
in 3GPP, please refer to recent study at
https://www.3gpp.org/ftp/Email_Discussions/SA3/SA3%23121/draft_S3-251710-r2-Draft%20TR%2033938-020.docx
.

It's not just 3GPP; other SDOs, such as GSMA, also depend on IETF RFCs. For
example, the recent liaison statement from GSMA highlights the importance
of the RFC timeline for the PQ/T key agreement draft to be used as a
normative reference.

-Tiru

On Sat, 17 May 2025 at 17:52, Salz, Rich 
wrote:

> So far we’ve heard that 3GPP is considering using this (presumably for
> thinks like station-to-station, as it were), but they need a stable
> reference like an RFC. I’d say that “stable reference” is their problem. Do
> they consider the TLS registries a stable reference?
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [External⚠️] Re: Certificate Update in TLS

[tirumal reddy]

3GPP also has a requirement to secure SCTP-based communications using DTLS,
which involves long-lived sessions. One of the key security requirements is
that mutual authentication must be used, with periodic re-authentication to
allow certificate updates (see Section 4

for
more details).These connections are expected to remain stable for long
periods of time.

Cheers,
-Tiru

On Sat, 21 Jun 2025 at 06:13, Eric Rescorla  wrote:

> Hi Rifaat,
>
> I'm obviously excited to see people encrypting massive amounts of traffic,
> but I did want to pressure test this use case a bit.
>
> I have two questions:
>
> 1. What's the mean time between failure of these connections?
> 2. What do you do if the connection fails? Do you have some way to cleanly
> restart?
>
> Thanks,
> -Ekr
>
>
>
> On Fri, Jun 20, 2025 at 5:31 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> We have a use case where optical systems establish a persistent TLS
>> channel that is then used to mint keys used to encrypt massive amounts of
>> traffic over fiber optic lines.
>> This mechanism could be useful to allow the systems to maintain that TLS
>> channel during certificate rotation, without tearing down the connection.
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Fri, Jun 20, 2025 at 6:55 PM Yaroslav Rosomakho > 40zscaler@dmarc.ietf.org> wrote:
>>
>>> I don't believe certificates expire just because of key compromise.
>>> Hosts could be decommissioned, domains could be repossessed, services could
>>> move around. Certificate Update provides assurance that the peer still has
>>> the right to claim original identity.
>>> Let's say an IoT device established a session with a vendor server to
>>> stream sensitive diagnostic data. The vendor could change server hosting
>>> provider, update DNS records but forget to shut down the previous instance.
>>> Established connections will stay up though the server effectively lost its
>>> identity. Sadly, these things do happen in the wild.
>>>
>>> As of key compromise, there are two separate risks:
>>> - compromised private key of certificate
>>> - compromised session key
>>>
>>> A Certificate with a potentially compromised private key needs to be
>>> revoked and replaced with a fresh one. However, rekey of the session (Key
>>> Update or Extended Key Update) does not bring assurance that the connection
>>> is established with the correct peer - it could well be an imposter in
>>> possession of a stolen private key. Certificate Update provides that
>>> assurance.
>>>
>>> Extended Key Update is about reducing risks associated with the
>>> compromised session key.
>>>
>>> Best Regards,
>>> Yaroslav
>>>
>>> On Fri, Jun 20, 2025 at 11:29 PM Watson Ladd 
>>> wrote:
>>>
 On Fri, Jun 20, 2025 at 3:20 PM Yaroslav Rosomakho
  wrote:
 >
 > Hello Watson,
 >
 > On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd 
 wrote:
 >>
 >>
 >> What exactly is the rationale here? Do we expect that identies
 >> actually change when a certificate expires?
 >
 >
 > Certificate confirms identity information for a certain period of
 validity as long as it is not revoked. Communication with an endpoint that
 produces a revoked or expired certificate is deemed to have unacceptable
 risk and typically denied. However, this risk applies to established
 sessions in exactly the same way as it applies to new sessions. The
 rationale is to ensure that the peer identity is still valid by the time
 the original certificate expired or got revoked.

 Certificate expiry is in some sense driven by the risk of key
 compromise. If the key is compromised it fails to provide assurance as
 to the identity of the counterparty. But that compromise could also
 happen to the keys protecting the session over that length of time
 (yes, there are some differences in threat model depending on how they
 are stored). In that case this draft doesn't actually protect
 anything: an attacker with those keys is able to see the traffic going
 through and continue to exploit the session.

 This isn't really a problem of identities expering (how could they)
 but rather risk limitation.

 The reason I belabor this point is the conclusion: we have to rekey
 the connection as well to get the assurances we want. The mechanism
 here doesn't do that.

 >
 > TLS 1.2 and prior could perform re-key and re-authentication through
 rehandshake. As the very generic rehandshake carried unacceptable security
 risks it was removed in TLS 1.3. Extended Key Update brings back re-key in
 a secure way. Similarly, Certificate Update proposal is intended to bring
 back re-authentication in a very limited controlled fashion.
 >
 > Best Regards,
 > Yaroslav
 >
 >
 > This communication (including any attachments) is intende

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

Hi Mike,

Please review the revised security considerations section
https://github.com/tireddy2/slhdsa-tls1.3/blob/main/draft-reddy-tls-slhdsa.md
to address your comment.

Best Regards,
-Tiru

On Mon, 19 May 2025 at 11:58, tirumal reddy  wrote:

> Including TLS WG mailing list.
>
> Thanks Mike for the feedback. The long-lived TLS connections will undergo 
> periodic
> re-authentication to check the certificate validity. In a typical 3GPP
> deployment, the certificate will expire and be replaced with a new
> certificate with a new key pair well before the SLH-DSA signature limit is
> approached. For example, if a server certificate is valid for 1 year and each
> connection re-authenticates every 12 hours, this results in approximately 730
> signatures per client connection. Even when scaled to many clients, the total
> number of signatures generated over the lifetime of a single key remains 
> vastly
> below the SLH-DSA signature limit
>
> It is an important security aspect to be discussed in the draft. I will
> raise PR to address it.
>
> Cheers,
> -Tiru
>
> On Sat, 17 May 2025 at 19:30, Mike Ounsworth 
> wrote:
>
>> (my messages are not making it to the list; hoping someone will reply-all
>> to get it on the record)
>>
>> @Martin, would you object to adoption less if there were fewer algorithms
>> being registered ... like 1 or 2?
>>
>> @Tiru, @JohnMattsson -- My objection to this draft in its current form is
>> that there is a lack of discussion about that 2^64 signature limit. I am
>> aware of the size of the number "2^64", and that this simply won't be
>> reached in a long-lived TLS connections, but once we allow SLH-DSA in TLS,
>> it's allowed, and Moore's Law scaling over the coming decades could make it
>> conceivable to see 2^64 handshakes on a single key, especially with massive
>> horizontal scaling and CSR key reuse across cert renewals. How do you solve
>> that? Do we require operators to roughly track the number of signatures
>> performed? How? So IMO this draft NEEDS a well-worded Security
>> Consideration about this limit and I want to see at least roughly what that
>> text looks like as part of adoption because to me SLH-DSA is appropriate
>> for TLS if and only if we can find something reasonable to say about this.
>>
>> On Sat, 17 May 2025 at 07:23, Salz, Rich > 40akamai@dmarc.ietf.org> wrote:
>>
>>> So far we’ve heard that 3GPP is considering using this (presumably for
>>> thinks like station-to-station, as it were), but they need a stable
>>> reference like an RFC. I’d say that “stable reference” is their problem. Do
>>> they consider the TLS registries a stable reference?
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Fri, 16 May 2025 at 21:17, Richard Barnes  wrote:

> On Fri, May 16, 2025 at 11:25 AM Eric Rescorla  wrote:
>
>> On Fri, May 16, 2025 at 8:19 AM Salz, Rich  wrote:
>>
>>> I am not thrilled about adoption, for the reasons that EKR and Panos
>>> said. Further, I am concerned about us going back to the old days of
>>> “register every algorithm” which took years to evolve away from.
>>>
>>>
>>>
>>> We can assign code points based on drafts and let the world experiment.
>>>
>>>
>>>
>>> Can the authors -- or anyone actually -- provide a specific example of
>>> where they WANT to use SLH-DSA?  Not COULD as the draft currently says.
>>>
>>
>> This would be helpful to me as well.
>>
>
> It would also be useful to understand why an RFC adds value over just
> having an IANA code point.  Since the registry is Specification Required
> and FIPS 205 exists, someone could send email to IANA today and get code
> points as soon as Yoav/Rich/Nick response to email.
>

While SLH-DSA is defined in FIPS 205, its integration into TLS still
requires details that go beyond what FIPS specifies, including:

a) Providing guidance on deployment contexts where SLH-DSA is appropriate,
such as for long-lived TLS sessions or CA certificates, especially given
its large signature sizes but strong PQ security assurances.
b) Explaining why HashSLH-DSA is not included in this draft, since TLS
already hashes the handshake transcript.
c) Clarifying the use of deterministic versus hedged signing modes
d) Addressing the operational implications of the 2^64 signature limit.

We would like to see the draft adopted by the WG as lack of an RFC would
likely stall adoption in SDOs such as 3GPP, which prefer referencing RFCs
to advance their specifications.

Cheers,
-Tiru


>
> In general, the only value that algorithm registration RFCs add are (a)
> clarifying any technical points, and (b) setting the "Recommended" field to
> "Y".  It doesn't look to me like the draft makes any technical points (just
> says "do what FIPS 205 says").  Is "Recommended = Y" important enough to
> merit the work?  It seems like the algorithm proliferation points that
> others have mentioned militate against it.  Perhaps the best path is to
> register code points with "Recommended = N" (no RFC needed), see if anyone
> actually uses it, and then revisit the question of upgraded to "Y" after a
> while.
>
> --Richard
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Tue, 27 May 2025 at 23:57, Watson Ladd  wrote:

> On Sun, May 25, 2025 at 10:55 PM tirumal reddy  wrote:
> >
> > On Wed, 21 May 2025 at 18:14, Watson Ladd  wrote:
> >>
> >> On Mon, May 19, 2025 at 2:30 AM tirumal reddy 
> wrote:
> >> >
> >> > Including TLS WG mailing list.
> >> >
> >> > Thanks Mike for the feedback. The long-lived TLS connections will
> undergo periodic re-authentication to check the certificate validity. In a
> typical 3GPP deployment, the certificate will expire and be replaced with a
> new certificate with a new key pair well before the SLH-DSA signature limit
> is approached. For example, if a server certificate is valid for 1 year and
> each connection re-authenticates every 12 hours, this results in
> approximately 730 signatures per client connection. Even when scaled to
> many clients, the total number of signatures generated over the lifetime of
> a single key remains vastly below the SLH-DSA signature limit
> >> >
> >> > It is an important security aspect to be discussed in the draft. I
> will raise PR to address it.
> >>
> >> What's the actual assumption about the authenticity of the data on
> >> that connection?
> >>
> >>
> >> This obviously is dependant on some cryptomania, even if the handshake
> >> authentication is in minicrypt, because we don't sign data going over
> >> the connection in TLS. So what's the actual gain from SLH-DSA?
> >
> >
> > Mike was referring to the constraint that SLH-DSA imposes a limit of 2⁶⁴
> signatures per key. I responded that the draft will address how deployments
> can remain well below this limit by issuing new certificates with new key
> pairs before the threshold is reached. The limitation relates specifically
> to the number of times a key is used to produce signatures in the
> CertificateVerify message during the TLS handshake and post-handshake
> authentication.
>
> And I'm taking about assertions that SLH-DSA improves authenticity in
> TLS connections for the *data carried over the connection*. It
> doesn't.
>

To clarify, the draft does not make any claims that SLH-DSA improves the
authenticity of the data transmitted over the TLS connection. If any part
of the text appears to imply otherwise, we’re happy to revise it.

-Tiru


>
> >
> > -Tiru
> >
> >>
> >> >
> >> > Cheers,
> >> > -Tiru
> >> >
> >> > On Sat, 17 May 2025 at 19:30, Mike Ounsworth <
> ounsworth+i...@gmail.com> wrote:
> >> >>
> >> >> (my messages are not making it to the list; hoping someone will
> reply-all to get it on the record)
> >> >>
> >> >> @Martin, would you object to adoption less if there were fewer
> algorithms being registered ... like 1 or 2?
> >> >>
> >> >> @Tiru, @JohnMattsson -- My objection to this draft in its current
> form is that there is a lack of discussion about that 2^64 signature limit.
> I am aware of the size of the number "2^64", and that this simply won't be
> reached in a long-lived TLS connections, but once we allow SLH-DSA in TLS,
> it's allowed, and Moore's Law scaling over the coming decades could make it
> conceivable to see 2^64 handshakes on a single key, especially with massive
> horizontal scaling and CSR key reuse across cert renewals. How do you solve
> that? Do we require operators to roughly track the number of signatures
> performed? How? So IMO this draft NEEDS a well-worded Security
> Consideration about this limit and I want to see at least roughly what that
> text looks like as part of adoption because to me SLH-DSA is appropriate
> for TLS if and only if we can find something reasonable to say about this.
> >> >>
> >> >> On Sat, 17 May 2025 at 07:23, Salz, Rich  40akamai@dmarc.ietf.org> wrote:
> >> >>>
> >> >>> So far we’ve heard that 3GPP is considering using this (presumably
> for thinks like station-to-station, as it were), but they need a stable
> reference like an RFC. I’d say that “stable reference” is their problem. Do
> they consider the TLS registries a stable reference?
> >> >>>
> >> >>> ___
> >> >>> TLS mailing list -- tls@ietf.org
> >> >>> To unsubscribe send an email to tls-le...@ietf.org
> >> >
> >> > ___
> >> > TLS mailing list -- tls@ietf.org
> >> > To unsubscribe send an email to tls-le...@ietf.org
> >>
> >>
> >>
> >> --
> >> Astra mortemque praestare gradatim
>
>
>
> --
> Astra mortemque praestare gradatim
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

I support adoption of the draft. SLH-DSA is intended to be leveraged in
3GPP deployments, particularly for long-lived connections. While it
increases the size of the TLS 1.3 handshake, the impact on connection
performance is minimal in the context of long-lived connections with large
data transfers.

Cheers,
-Tiru

On Tue, 15 Jul 2025 at 03:37, Sean Turner  wrote:

> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We
> called consensus [1], and that decision was appealed. We have reviewed the
> messages and agree that we need to redo the adoption call to get more input.
>
> What appears to be the most common concern, which we will take from Panos'
> email, is that "SLH-DSA sigs are too large and slow for general use in TLS
> 1.3 applications". One way to address this concern is to add an
> applicablity statement to address this point. We would like to propose that
> this (or something close to this) be added to the I-D:
>
> Applications that use SLH-DSA need to be aware that the signatures sizes
> are large; the signature sizes for the cipher suites specified herein range
> from 7,856 to 49,856 bytes. Likewise, the cipher suites are considered
> slow. While these costs might be amoritized over the cost of a long lived
> connection, the cipher suites specified herein are not considered for
> general use in TLS 1.3.
>
> With this addition in mind, we would like to start another WG adoption
> call for draft-reddy-tls-slhdsa. If you support adoption with the above
> text (or something similar) and are willing to review and contribute text,
> please send a message to the list. If you do not support adoption of this
> draft with the above text (or something similar), please send a message to
> the list and indicate why. This call will close at 2359 UTC on 28 July 2025.
>
> Cheers,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
> [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Wed, 16 Jul 2025 at 19:27, Matt G1  wrote:

>
>
> Hello all,
>
>
>
> I think it’s premature to say that 3GPP intends to use SLH-DSA. The 3GPP
> security group (SA3) will start its PQ migration study at its next meeting.
> As such no discussions about which algorithms are
> required/preferred/desired has happened at this stage.
>
>
>
> Details of the study parameters/scope can be found here for the curious:
>
>
>
>
> https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_108_Prague_2025-06/Docs/SP-250858.zip
>

Just to clarify my earlier message: I didn't mean to imply that 3GPP has
decided to adopt SLH-DSA. What I intended to convey is that use of SLH-DSA
in TLS is mentioned as one of the NIST-selected algorithms in the draft SID
for the PQC study in SA3, available here:
https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/SA3/Inbox/Drafts/draft_S3-252154-r1_PQC%20SID.docx.
TLS-based protocols are increasingly used to secure long-lived interfaces
in critical infrastructure, including mobile networks. For example,
DTLS-in-SCTP is required in 3GPP for several interfaces (such as N2), which
rely on long-lived TLS connections.

The argument that SLH-DSA is not ideal for TLS, but I believe this comment
comes from HTTP use cases. In contrast, for infrastructure use cases
where large volumes of data are transferred over long-lived connections,
the additional few kilobytes in the handshake are comparatively negligible.
Cheers,
-Tiru


>
>
> Regards,
>
>
>
> Matt
>
>
>
> The Standards Person
>
> NCSC Telecoms Security Consultant
>
>
>
>
>
>
>
> *From:* tirumal reddy 
> *Sent:* 16 July 2025 12:46
> *To:* Sean Turner 
> *Cc:* TLS List 
> *Subject:* [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
>
>
>
> I support adoption of the draft. SLH-DSA is intended to be leveraged in
> 3GPP deployments, particularly for long-lived connections. While it
> increases the size of the TLS 1.3 handshake, the impact on connection
> performance is minimal in the context of long-lived connections with large
> data transfers.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> On Tue, 15 Jul 2025 at 03:37, Sean Turner  wrote:
>
> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We
> called consensus [1], and that decision was appealed. We have reviewed the
> messages and agree that we need to redo the adoption call to get more input.
>
> What appears to be the most common concern, which we will take from Panos'
> email, is that "SLH-DSA sigs are too large and slow for general use in TLS
> 1.3 applications". One way to address this concern is to add an
> applicablity statement to address this point. We would like to propose that
> this (or something close to this) be added to the I-D:
>
> Applications that use SLH-DSA need to be aware that the signatures sizes
> are large; the signature sizes for the cipher suites specified herein range
> from 7,856 to 49,856 bytes. Likewise, the cipher suites are considered
> slow. While these costs might be amoritized over the cost of a long lived
> connection, the cipher suites specified herein are not considered for
> general use in TLS 1.3.
>
> With this addition in mind, we would like to start another WG adoption
> call for draft-reddy-tls-slhdsa. If you support adoption with the above
> text (or something similar) and are willing to review and contribute text,
> please send a message to the list. If you do not support adoption of this
> draft with the above text (or something similar), please send a message to
> the list and indicate why. This call will close at 2359 UTC on 28 July 2025.
>
> Cheers,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
> [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

Thanks Quynh, raised a PR
https://github.com/tireddy2/slhdsa-tls1.3/pull/7/files to address the issue.

Cheers,
-Tiru

On Tue, 15 Jul 2025 at 04:28, Quynh Dang  wrote:

> Hi Sean, Deirdre and Joe,
>
> The phrase "cipher suites" has a specific meaning in TLS and it does not
> mean a signature algorithm.
>
> How about the following: "Applications that use SLH-DSA need to be aware
> that the signature sizes of the signature algorithms specified in this
> document are generally considered large, from 7,856 to 49,856 bytes.
> Likewise, they are also considered slow generally. While their costs might
> be amortized over long lived connections, they are not recommended for
> general uses in TLS 1.3 where performance is sensitive." ?
>
> Regards,
> Quynh.
>
> On Mon, Jul 14, 2025 at 6:07 PM Sean Turner  wrote:
>
>> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We
>> called consensus [1], and that decision was appealed. We have reviewed the
>> messages and agree that we need to redo the adoption call to get more input.
>>
>> What appears to be the most common concern, which we will take from
>> Panos' email, is that "SLH-DSA sigs are too large and slow for general use
>> in TLS 1.3 applications". One way to address this concern is to add an
>> applicablity statement to address this point. We would like to propose that
>> this (or something close to this) be added to the I-D:
>>
>> Applications that use SLH-DSA need to be aware that the signatures sizes
>> are large; the signature sizes for the cipher suites specified herein range
>> from 7,856 to 49,856 bytes. Likewise, the cipher suites are considered
>> slow. While these costs might be amoritized over the cost of a long lived
>> connection, the cipher suites specified herein are not considered for
>> general use in TLS 1.3.
>>
>> With this addition in mind, we would like to start another WG adoption
>> call for draft-reddy-tls-slhdsa. If you support adoption with the above
>> text (or something similar) and are willing to review and contribute text,
>> please send a message to the list. If you do not support adoption of this
>> draft with the above text (or something similar), please send a message to
>> the list and indicate why. This call will close at 2359 UTC on 28 July 2025.
>>
>> Cheers,
>> Deirdre, Joe, and Sean
>>
>> [0]
>> https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
>> [1]
>> https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
>> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

I agree with John. I will give a concrete example to help clarify the
uncertainty. DTLS based security solution for SCTP has been mandated by
3GPP for several key interfaces. These interfaces involve long-lived DTLS
sessions. For more details, see the liaison statement from 3GPP:
https://datatracker.ietf.org/liaison/1851/. The DTLS-in-SCTP standrds work
is done in the TSVWG WG.

-Tiru

On Tue, 22 Jul 2025 at 12:20, John Mattsson  wrote:

> I feel like I need re-iterate that according to 3GPP specifications, SLH-DSA
> is already allowed (MAY/OPTIONAL) to support and use for all uses of TLS
> in 3GPP deployments and that vendors are planning to support both ML-DSA
> and SLH-DSA. As Matt correctly points out it is not yet decided which PQC
> signature algorithms 3GPP specifications will have as SHOULD/MUST support.
>
> Cheers,
>
> John
>
>
>
> *From: *Matt G1 
> *Date: *Tuesday, 22 July 2025 at 11:29
> *To: *Loganaden Velvindron , Simon Josefsson  40josefsson@dmarc.ietf.org>
> *Cc: *TLS List 
> *Subject: *[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
>
> [You don't often get email from matt.g1=40ncsc.gov...@dmarc.ietf.org.
> Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> I feel like I need re-iterate that use cases for SLH-DSA have not been
> addressed in 3GPP meetings. The discussion will happen over the next 6
> months. We may or may not come to consensus to wish to use it.
>
> Matt
>
> NCSC Telecoms Security Consultant
>
>
> -Original Message-
> From: Loganaden Velvindron 
> Sent: 21 July 2025 05:53
> To: Simon Josefsson 
> Cc: TLS List 
> Subject: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
>
> [You don't often get email from logana...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> I also support adoption of the draft. If there is a use case for 3gpp, I'm
> ok with that.
>
> On Sat, 19 Jul 2025 at 22:49, Simon Josefsson  40josefsson@dmarc.ietf.org> wrote:
> >
> > I support adoption of the draft, and believe SLH-DSA in TLS would be
> > useful and that a stable reference in the form of an RFC would be good.
> >
> > I think the people who have concerns with the performance assume the
> > intended use is for regular web browser HTTPS use, but TLS has broader
> > applicability than that.  50kb sizes is peanuts for the majority of
> > applications today, and you may compare with 1MB handshakes as for
> > Classic McEliece [1] which is still performant for many use-cases.
> > Performance on modern machines are negligible, slower than what RSA
> > was in SSL 30 years ago on then typical machines.  So I would disagree
> > with the notion that SLH-DSA is slow, and suggest that we let users
> > decide how to balance performance to (perceived) security.
> >
> > /Simon
> >
> > [1]
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cc6e3804471cb437ac51f08ddc90243f7%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638887733753195174%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H8DztUNNzMNxaulvcyxeZR%2BDaEbu5WUI%2BZm4hjiNQ3M%3D&reserved=0
> .
> > wolfssl.com%2Fannouncing-mcwolf-classic-mceliece-support-with-wolfssl%
> > 2F&data=05%7C02%7Cmatt.g1%40ncsc.gov.uk%7C658ad8d442be497c63ae08ddc812
> > a2db%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638886704564536777%7
> > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA
> > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dpu3n
> > srM9sPaWFv4sQnnpibD8l19opMipusegEuI3wc%3D&reserved=0
> >
> > Sean Turner  writes:
> >
> > > We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see
> > > [0]. We called consensus [1], and that decision was appealed. We
> > > have reviewed the messages and agree that we need to redo the
> > > adoption call to get more input.
> > >
> > > What appears to be the most common concern, which we will take from
> > > Panos' email, is that "SLH-DSA sigs are too large and slow for
> > > general use in TLS 1.3 applications". One way to address this
> > > concern is to add an applicablity statement to address this point.
> > > We would like to propose that this (or something close to this) be
> added to the I-D:
> > >
> > > Applications that use SLH-DSA need to be aware that the signatures
> > > sizes are large; the signature sizes for the cipher suites specified
> > > herein range from 7,856 to 49,856 bytes. Likewise, the cipher suites
> > > are considered slow. While these costs might be amoritized over the
> > > cost of a long lived connection, the cipher suites specified herein
> > > are not considered for general use in TLS 1.3.
> > >
> > > With this addition in mind, we would like to start another WG
> > > adoption call for draft-reddy-tls-slhdsa. If you support adoption
> > > with the above text (or something sim

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

Thanks Daniel for the support. We have not yet requested codepoints, this
was intentional. We wanted to allow for more discussion within the WG,
particularly around the type of codepoints needed.

-Tiru

On Thu, 24 Jul 2025 at 13:29, Daniel Van Geest  wrote:

> I support adoption with the applicability statement.
>
> I am guilty of helping spread OID proliferation in
> draft-ietf-lamps-x509-slhdsa, although that was because we couldn't predict
> all the use cases for SLH-DSA end-entity certificates.  I'm glad this draft
> only uses the pure half of SLH-DSA, but I hope that it can cut down on the
> number of codepoints.  For example, TLS is currently dependent on SHA-2 for
> cipher suites, perhaps the SLH-DSA SHAKE options could be removed.  Some
> thought on whether the small or fast versions would be more appropriate for
> TLS could help then the codepoints to a reasonable number.
>
> A point of process: I don't think this draft should have claimed any IANA
> codepoints, that is for IANA to assign after a request is made. At least, I
> don't see these in the IANA registry.  Is it too late for the draft to
> remove these values, hopefully reduce the number of codepoints (if
> adopted), and only request those codepoints from IANA?
>
> Regards,
> Daniel
> On 2025-07-14 11:05 p.m., Sean Turner wrote:
>
> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We 
> called consensus [1], and that decision was appealed. We have reviewed the 
> messages and agree that we need to redo the adoption call to get more input.
>
> What appears to be the most common concern, which we will take from Panos' 
> email, is that "SLH-DSA sigs are too large and slow for general use in TLS 
> 1.3 applications". One way to address this concern is to add an applicablity 
> statement to address this point. We would like to propose that this (or 
> something close to this) be added to the I-D:
>
> Applications that use SLH-DSA need to be aware that the signatures sizes are 
> large; the signature sizes for the cipher suites specified herein range from 
> 7,856 to 49,856 bytes. Likewise, the cipher suites are considered slow. While 
> these costs might be amoritized over the cost of a long lived connection, the 
> cipher suites specified herein are not considered for general use in TLS 1.3.
>
> With this addition in mind, we would like to start another WG adoption call 
> for draft-reddy-tls-slhdsa. If you support adoption with the above text (or 
> something similar) and are willing to review and contribute text, please send 
> a message to the list. If you do not support adoption of this draft with the 
> above text (or something similar), please send a message to the list and 
> indicate why. This call will close at 2359 UTC on 28 July 2025.
>
> Cheers,
> Deirdre, Joe, and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
> [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Thu, 24 Jul 2025 at 13:49, Daniel Van Geest <
daniel.vange...@cryptonext-security.com> wrote:

> Tiru,
>
> While you haven't requested codepoints, the draft claims them, e.g.
>
> slhdsa_sha2_128s (0x0911),
>
> That is my concern regarding process.
>
These are just placeholders, we haven’t requested IANA to assign codepoints
yet. We’ll update the draft to make that clearer.

-Tiru

> Daniel
> On 2025-07-24 12:45 p.m., tirumal reddy wrote:
>
> Thanks Daniel for the support. We have not yet requested codepoints, this
> was intentional. We wanted to allow for more discussion within the WG,
> particularly around the type of codepoints needed.
>
> -Tiru
>
> On Thu, 24 Jul 2025 at 13:29, Daniel Van Geest  40cryptonext-security@dmarc.ietf.org> wrote:
>
>> I support adoption with the applicability statement.
>>
>> I am guilty of helping spread OID proliferation in
>> draft-ietf-lamps-x509-slhdsa, although that was because we couldn't predict
>> all the use cases for SLH-DSA end-entity certificates.  I'm glad this draft
>> only uses the pure half of SLH-DSA, but I hope that it can cut down on the
>> number of codepoints.  For example, TLS is currently dependent on SHA-2 for
>> cipher suites, perhaps the SLH-DSA SHAKE options could be removed.  Some
>> thought on whether the small or fast versions would be more appropriate for
>> TLS could help then the codepoints to a reasonable number.
>>
>> A point of process: I don't think this draft should have claimed any IANA
>> codepoints, that is for IANA to assign after a request is made. At least, I
>> don't see these in the IANA registry.  Is it too late for the draft to
>> remove these values, hopefully reduce the number of codepoints (if
>> adopted), and only request those codepoints from IANA?
>>
>> Regards,
>> Daniel
>> On 2025-07-14 11:05 p.m., Sean Turner wrote:
>>
>> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We 
>> called consensus [1], and that decision was appealed. We have reviewed the 
>> messages and agree that we need to redo the adoption call to get more input.
>>
>> What appears to be the most common concern, which we will take from Panos' 
>> email, is that "SLH-DSA sigs are too large and slow for general use in TLS 
>> 1.3 applications". One way to address this concern is to add an applicablity 
>> statement to address this point. We would like to propose that this (or 
>> something close to this) be added to the I-D:
>>
>> Applications that use SLH-DSA need to be aware that the signatures sizes are 
>> large; the signature sizes for the cipher suites specified herein range from 
>> 7,856 to 49,856 bytes. Likewise, the cipher suites are considered slow. 
>> While these costs might be amoritized over the cost of a long lived 
>> connection, the cipher suites specified herein are not considered for 
>> general use in TLS 1.3.
>>
>> With this addition in mind, we would like to start another WG adoption call 
>> for draft-reddy-tls-slhdsa. If you support adoption with the above text (or 
>> something similar) and are willing to review and contribute text, please 
>> send a message to the list. If you do not support adoption of this draft 
>> with the above text (or something similar), please send a message to the 
>> list and indicate why. This call will close at 2359 UTC on 28 July 2025.
>>
>> Cheers,
>> Deirdre, Joe, and Sean
>>
>> [0] https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/
>> [1] https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/
>> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[tirumal reddy]

On Mon, 28 Jul 2025 at 19:10, Peter C
 wrote:

I don't support adopting the draft at the moment.
>
> A stronger applicability statement and reducing the number of parameter
> sets would be steps in the right direction, but I'm a "not yet" because the
> motivating example seems to be DTLS.  Unlike TLS, I'm not aware of any
> experiments using SLH-DSA in DTLS and I think there are still open
> questions about amplification attacks (https://eprint.iacr.org/2023/266)
> which are potentially much worse with SLH-DSA.
>

The draft has been updated to include an Applicability section, please
see 
https://github.com/tireddy2/slhdsa-tls1.3/blob/main/draft-reddy-tls-slhdsa.md.
While the example refers to DTLS, it specifically targets
DTLS-over-SCTP, which is a reliable transport and therefore does not
face the amplification issues with DTLS over UDP. The draft does not
use the “pre-hash” variants of SLH-DSA. We are open to feedback from
the WG, including suggestions for reducing the number of parameter
sets.


We look forward to further discussion on progressing this work.


Cheers,

-Tiru



> Peter
>
> > -Original Message-
> > From: Sean Turner 
> > Sent: 25 July 2025 08:26
> > To: TLS List 
> > Subject: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
> >
> > Hi! Just a reminder that this call closes on Monday.
> >
> > spt
> >
> > > On Jul 15, 2025, at 00:05, Sean Turner  wrote:
> > >
> > > We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0].
> We
> > called consensus [1], and that decision was appealed. We have reviewed
> the
> > messages and agree that we need to redo the adoption call to get more
> input.
> > >
> > > What appears to be the most common concern, which we will take from
> > Panos' email, is that "SLH-DSA sigs are too large and slow for general
> use in
> > TLS 1.3 applications". One way to address this concern is to add an
> > applicablity statement to address this point. We would like to propose
> that
> > this (or something close to this) be added to the I-D:
> > >
> > > Applications that use SLH-DSA need to be aware that the signatures
> sizes are
> > large; the signature sizes for the cipher suites specified herein range
> from
> > 7,856 to 49,856 bytes. Likewise, the cipher suites are considered slow.
> While
> > these costs might be amoritized over the cost of a long lived
> connection, the
> > cipher suites specified herein are not considered for general use in TLS
> 1.3.
> > >
> > > With this addition in mind, we would like to start another WG adoption
> call
> > for draft-reddy-tls-slhdsa. If you support adoption with the above text
> (or
> > something similar) and are willing to review and contribute text, please
> send
> > a message to the list. If you do not support adoption of this draft with
> the
> > above text (or something similar), please send a message to the list and
> > indicate why. This call will close at 2359 UTC on 28 July 2025.
> > >
> > > Cheers,
> > > Deirdre, Joe, and Sean
> > >
> > > [0]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> > hive.ietf.org%2Farch%2Fmsg%2Ftls%2Fo4KnXjI-
> > OpuHPcB33e8e78rACb0%2F&data=05%7C02%7Cpeter.c%40ncsc.gov.uk%7C2
> > 01c39c6390f4576286708ddcb4c9e26%7C14aa5744ece1474ea2d734f46dda64
> > a1%7C0%7C0%7C638890252124042183%7CUnknown%7CTWFpbGZsb3d8eyJ
> > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pKHJhIxCE1%2BWnwU
> > wbXT7ze1ACjY95T2MZg%2Fo315EjPs%3D&reserved=0
> > > [1]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> > hive.ietf.org%2Farch%2Fmsg%2Ftls%2FhhLtBBctK5em6l82m7rgM6_hefo%2F&
> > data=05%7C02%7Cpeter.c%40ncsc.gov.uk%7C201c39c6390f4576286708ddcb4
> > c9e26%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C63889025212
> > 4069084%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C
> > 0%7C%7C%7C&sdata=v6vIitoNnT1s2sYIN8GARL6e0DDV2gdI36%2FXaPsf4dM
> > %3D&reserved=0
> > > [2]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> > cker.ietf.org%2Fdoc%2Fdraft-reddy-tls-
> > slhdsa%2F&data=05%7C02%7Cpeter.c%40ncsc.gov.uk%7C201c39c6390f45762
> > 86708ddcb4c9e26%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6
> > 38890252124080664%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> > %3D%3D%7C0%7C%7C%7C&sdata=0IFzKvjlnSxwi0Sm2nFB9%2BpezAqrADail0
> > 7tqlShQyE%3D&reserved=0
> >
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org