[TLS] Re: ML-DSA in TLS

[Ilari Liusvaara]

On Thu, Oct 24, 2024 at 03:51:50PM +, Tim Hollebeek wrote:
> My personal feelings on pure vs composite are actually the union of several 
> previous comments:
> 
> 1. Like EKR, I actually have a weak preference for composite, all other 
> things being equal. Failures happen and I like backup mechanisms
> when they are relatively affordable and can be afforded.

Unfortunately, the mechanism to combine the two signatures can also
fail, and its failure can end up totally undermining security.
So it is not just pure backup.


> 2. That said, I don't think composite should be forced on people. There are 
> valid use cases where I would recommend NOT using it, and I'm hearing 
> demand for both pure and composite. Like Scott said, I think we'll end 
> up standardizing both.

I would imagine NSA IA would not be happy about hybrid signatures. One
of their main arguments against hybrids has been complexity, and hybrid
signatures seem to bring that in spades, much more than hybrid KEM.


> 3. Composite is slightly more complicated, though not as complicated as its 
> detractors claim. However, since composite signatures are not 
> standardized 
> yet, I think they shouldn't be dragged into the 'pure' discussion. They 
> can have 
> their own draft and thread, like Diedre noted.

I don't agree with composite signatures being slightly more complicated.
I think that composite signatures are much more complicated, and that I
am underestimating the complexity.

For hybrid KEMs, I think slightly more complicated would be fair, as
long as one keeps away from more complex stuff.


> I strongly oppose the "we have some time" sentiment, though. There are
> ecosystems that are slow to transition due to long approval timelines and
> the desire to do rigorous analysis and discussion, and some of them are 
> starting 
> to make transition plans now. The lack of IETF guidance on some of these 
> topics
> is starting to be a blocker now that NIST algorithm specifications are 
> complete.
> 
> In the absence of standards, they will just do their own thing, and we'll end 
> up 
> with lots of unnecessary diversity and "interesting" design choices.

I think that the only quantum-safe signatures that are currently
ready-to-go are ML-DSA and SLH-DSA. These have already seen rigorous
analysis.

AFAIK, hybrid signatures have not seen rigorous analysis, and that
should predate IETF guidance.


And thinking about the decade+ WebPKI SHA-1 to SHA-2 transition, I do
not think the main factor was long approval timelines, need to do
rigorous analysis, or need for rigorous discussion. 




-Ilari

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

[TLS] Re: ML-DSA in TLS

[Tim Hollebeek]

> And thinking about the decade+ WebPKI SHA-1 to SHA-2 transition, I do not
> think the main factor was long approval timelines, need to do rigorous
> analysis, or need for rigorous discussion.

So, the WebPKI SHA-1 to SHA-2 transition was a tiny little corner of the SHA-1
to SHA-2 transition. It happened embarrassingly slowly and late, but was
otherwise pretty much a non-event, as WebPKI transitions are not that hard.
Compared to other PKIs, at least. There's a fairly limited number of 
certificate
consumers, and they update their software reasonably rapidly for the most 
part.

As I'm sure you're aware, most of the problems with the SHA-2 WebPKI
transition were due to mixing the WebPKI with other ecosystems, like banking
and payments, which do indeed have the characteristics I noted.

Now, the good news is that many of those ecosystems have learned from that
experience, and have absolutely no desire to repeat it. Various groups have
various efforts going on in this area, and are actively discussing their own 
plans,
and looking to IETF for guidance, as they will NOT be waiting for the WebPKI
and they will NOT be following the WebPKI's lead this time.

And sorry for the vagueness, many of these private ecosystem discussions
are not public and I have to be a little careful about what I say. Here's one
of them, though, that was created as a direct result of the SHA-2 transition
problems:

https://x9.org/x9f-public-key-infrastructure-pki-study-group/

Over the next 6-12 months we'll probably see lots of announcements from
various ecosystems, regions, stakeholders, verticals, etc as to what their
draft PQC transition plans are. And most of those groups are following the
discussions here very closely.

Focusing most of our discussions on the WebPKI and its needs is part of
what causes other PKIs to become entangled with the WebPKI. We
constantly need to remind ourselves that there's also a world outside of
the WebPKI, and it needs TLS, too. And this is from someone who is
himself very heavily involved in the WebPKI.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] The TLS WG has placed draft-mattsson-tls-super-jumbo-record-limit in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The TLS WG has placed draft-mattsson-tls-super-jumbo-record-limit in state
Call For Adoption By WG Issued (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/


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

[TLS] Re: ML-DSA in TLS

[Ilari Liusvaara]

On Thu, Oct 24, 2024 at 03:15:38AM +, Scott Fluhrer (sfluhrer) wrote:
> In my opinion, we’ll end up standardizing both.  At the very least,
> I (Cisco) have some customers who want ML-DSA only, and other
> customers that insist on hybrid, and so we’ll need to support both.
> 
> Of course, when it comes to hybrid, we have some options to sort
> through.  Do we:
> 
>   *   Support a hybrid certificate (such as proposed in the LAMPS
>   wg)?
>   *   Modify the TLS protocol to rely on multiple certificates (one
>   of which might be a traditional RSA certificate and one an
>   ML-KEM only certificate)?
> 
> I can see reasons why either option makes sense; what does the
> working group think?

I think of these two, only the hybrid certificate is viable.

I think the multiple certificates apporach is extremely complex
with highly nontrivial security considerations. The end result being
extreme risk of serious security issues.

As an example, Most of the currently proposed hybrid signatures are not
strongly non-separable, which makes it unsafe to recompose keys. But
having multiple certificates inherently allows recomposition.




-Ilari

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

[TLS] Re: Changing WG Mail List Reputation

[Peter Gutmann]

Viktor Dukhovni  writes:

>One of the ways in which this WG is sometimes unwelcoming is not covered by
>the called out unprofessional behaviour.  Rather, this list at times appears
>to be dominated by a single browser-centric world-view, and a dominant set of
>entrenched participants.  Perspectives from less dominant sectors of the TLS
>user community may not always receive due consideration.

Thank you for saying this, this was my exact reaction as well.  It's
unwelcoming not because of the occasional spat (which can actually be quite
entertaining in a grab-your-popcorn sort of way) but for the reason you've
given.  I know of a number of former participants who have either given up
entirely or have resigned to being in read-only mode because they feel it's
pointless to try and contribute - they're neither a browser vendor nor content
provider so their input will be ignored.

Peter.

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

[TLS] Re: Changing WG Mail List Reputation

[Tim Hollebeek]

I would like to thank the chairs in advance for all the hard and thankless work 
they just volunteered for. It is desperately needed and I truly appreciate it.

-Tim

> -Original Message-
> From: Sean Turner 
> Sent: Friday, October 25, 2024 8:31 AM
> To: TLS List 
> Subject: [TLS] Changing WG Mail List Reputation
> 
> Hello list,
> 
> The TLS list is infamous in that it is regarded by some as [insert your
> descriptive word; where the chairs have heard the following words used:
> noxious, toxic, unwelcoming, and rude]. The chairs want to change this
> reputation and we hope you do too. A big part of this is on the chairs to be 
> be
> more proactive about moderating behavior that goes against IETF WG
> procedures, code of conduct, etc. The chairs are also going to send a monthly
> reminder, which is included below, that will serve to remind everyone from
> those who joined just today to those who joined many, many years ago of the
> policies and procedures that apply to IETF mailing lists.
> 
> Monthly email reminder follows:
> 
> ---
> 
> Hello list,
> 
> As a regular reminder, this list is governed by IETF’s Working Group
> Procedures [BCP25], which also includes Anti-Harassment Procedures, and by
> participating you agree to the Note Well [NW] and to follow the Code of
> Conduct [CoC]. Thank you for contributing as part of the TLS Working Group.
> 
> As moderators of this list, the chairs are charged with determining when
> messages are “disruptive to the WG process”, phrase from RFC 3934, and, at a
> minimum, the chairs consider the following to be disruptive:
>   • Unsolicited bulk e-mail (from RFC 3683)
>   • Discussion of subjects unrelated to IETF policy, meetings, activities,
> or technical concerns (from RFC 3683)
>   • Unprofessional commentary, regardless of the general subject (from
> RFC 3683)
>   • Repetition of arguments without providing substantive new
> information
>   • Requesting an unreasonable amount of work to provide
> information
> 
> To elaborate on unprofessional commentary, the chairs believe that this also
> includes uncivil commentary as defined by the IETF List Moderators that
> includes threats of violence, personal attacks, and derogatory language; see
> [Language].
> 
> RFC 3683 also includes “announcements of conferences, events, or activities
> that are not sponsored or endorsed by the Internet Society or the IETF”.
> Please contact the chairs if you wish to share these types of announcements,
> but in general the chairs do not believe they are disruptive unless they are
> excessive and lack relevance.
> 
> Reminder that if at anytime you feel that if somebody is out of line you can
> say so on list or directly to us (mailto:tls-cha...@ietf.org), the ADs 
> (mailto:sec-
> a...@ietf.org), or the Ombudsteam (mailto:ombudst...@ietf.org).
> 
> ---
> 
> Obviously, if we receive significant feedback about any of the above, we can
> revisit the message.
> 
> Even though there are three of us, we are still not always immediately
> available to respond and because of that we would like your help in keeping
> the tone of the list professional and civil. Remember that if somebody else is
> behaving badly please refrain from reciprocating.
> 
> Cheers,
> The Chairs
> 
> [BCP25] https://datatracker.ietf.org/doc/bcp25/
> [NW] https://www.ietf.org/about/note-well/
> [CoC] https://datatracker.ietf.org/doc/bcp54/
> [Language] https://github.com/ietf/Moderators/blob/main/uncivil-
> commentary.md#descriptions
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-tlsflags

[Salz, Rich]

> The following PR creates the TLS Flags sub-registry where we can manage the 
> actual flags. I asserted that the chairs control adding values, which won’t 
> be true once (and if) the registry goes to IANA (it’ll be the DEs: Rich, 
> Nick, and Yoav), and populated the 1st value from the draft: 
> resumption_across_names. Assuming this is good, I will merge the PR.

Apparently IANA can have designated experts control things until the RFC is 
published.

Does this mean we'll need a new RFC to switch things?  Or can it be done by 
IESG telling IANA? If the latter, than maybe we do a little dance to say IESG 
designated control to the TLS WG Chairs and then IESG designates control to the 
regular TLS designated experts?  But if the proposal you're saying  works, 
great. I'm just interested in trying to avoid administrivia while we wait to 
get this new sub-registry into our hot little hands :)

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

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

>
> I'm not sure I agree that there is no value. In general, we try to roll
> out new mechanisms slowly so that we get some experience with how they
> perform in the wild. Given the experience with PQ key establishment, we
> should probably have some concern that ML-DSA won't just work in all cases,
> and we'd like to find that out now, which requires some level of deployment.
>

I am well aware, and we will, as we have before.

But I think we've strayed from the original question you asked:

In particular, we should have a discussion of whether we want to
standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
towards the latter, but I, at least, would like to hear arguments to the
contrary.


I think we should at least standardize pure ML-DSA. That does not prevent
us from standardising a hybrid as well. These are independent matters.

Best,

 Bas


PS. Majority of testing can be done without hybrids. Don't run it on
production traffic. Or pad a P-256 key to the length of ML-DSA. If it's
compute we want to test, run a dummy ML-DSA verify. If we do want the full
thing with a hybrid, we can use an ad hoc hybrid (as CECPQ2 was ad hoc too.)




>
>
>> The proposal you sketch also requires an update at the time CRQCs are
>> near to disable the non-PQ certificates.
>>
>
> Absolutely. We're just in an asymmetrical position in that we're already
> exposed to the risk of non-PQ but not to the risk of PQ.
>
> -Ekr
>
>
>> If you have a system that cannot have an update, then you indeed need a
>> hybrid.
>>
>>
>>> In general, the client is exposed to the union of the risks of
>>> compromise of the signature algorithms it supports. Thus, in a world
>>> where the client supports: [ECDSA, ML-DSA], then compromise of either
>>> algorithm is an issue. By contrast, if the client supports [ECDSA,
>>> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
>>> result in an attack. This is of course the same logic that leads
>>> to hybrids for key establishment.
>>>
>>> An obvious response here is "if something goes wrong with ML-DSA,
>>> we'll just turn it off quickly". This is certainly true for browsers,
>>> but I'm less sure it's true for other systems. If you think that
>>> it takes a long time to disable algorithms, then it seems like
>>> that's an argument that hybrid signatures are safer.
>>>
>>> -Ekr
>>>
>>>
>>> [0] There is benefit in the servers supporting PQ ahead of time
>>> because the client will have to make a cost/benefit decision in
>>> terms of breakage, and the more servers support PQ, the easier
>>> this decision is.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

 It's uncomfortable though if the first blessed SignatureScheme would be
 a non-hybrid. (Also regulators don't make the distinction between
 authentication and encryption, but at least most of them insist on hybrids
 for both though.)

 So I agree it makes sense to set recommended=N for now.

 Best,

  Bas



 On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:

> I think an adoption call is a bit premature here. We've got some time,
> especially in the WebPKI setting.
>
> In particular, we should have a discussion of whether we want to
> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
> towards the latter, but I, at least, would like to hear arguments to the
> contrary.
>
> -Ekr
>
>
> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson  40ericsson@dmarc.ietf.org> wrote:
>
>> Let’s have an adoption call asap.
>>
>>
>>
>> I made some minor suggestions
>> https://github.com/bwesterb/tls-mldsa/pull/3
>>
>>
>>
>> John
>>
>>
>>
>> *From: *Alicja Kario 
>> *Date: *Wednesday, 23 October 2024 at 19:59
>> *To: *Bas Westerbaan 
>> *Cc: *
>> *Subject: *[TLS] Re: ML-DSA in TLS
>>
>> Hi,
>>
>> Thanks for the draft, will definitely be helpful.
>>
>> Few issues:
>>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>>I think it will be better to continue the numbering in the 0x08..
>> space
>>  * the must in "must use id_ML-DSA(...)" probably should be
>> capitalised, as
>>if it doesn't match, the connection needs to be aborted
>>
>> open question is if we should document error handling explicitly:
>>  - illegal_parameter alert if the peer used algorithm not advertised,
>> or
>>signature algorithm does not match the certificate
>>  - decrypt_error when verification of the signature failed
>>
>> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
>> > Hi all,
>> >
>> > Unless I overlooked something, we don't have a draft out to
>> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
>> >
>> > It's two days past the I-D submission deadline, but I wanted to
>> > po

[TLS] Re: Changing WG Mail List Reputation

[Salz, Rich]

On 10/25/24, 10:02 AM, "Viktor Dukhovni" mailto:ietf-d...@dukhovni.org>> wrote:

>One of the ways in which this WG is sometimes unwelcoming is not covered
by the called out unprofessional behaviour. Rather, this list at times
appears to be dominated by a single browser-centric world-view, and a
dominant set of entrenched participants. Perspectives from less
dominant sectors of the TLS user community may not always receive due
consideration.

>I did not see being open to a broader set of perspectives on the list of
goals. It was just the usual set of blatant violations of social norms.

These are excellent points and I hope a future revision of the reminder posting 
will incorporate them.

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

[TLS] Changing WG Mail List Reputation

[Sean Turner]

Hello list,

The TLS list is infamous in that it is regarded by some as [insert your 
descriptive word; where the chairs have heard the following words used: 
noxious, toxic, unwelcoming, and rude]. The chairs want to change this 
reputation and we hope you do too. A big part of this is on the chairs to be be 
more proactive about moderating behavior that goes against IETF WG procedures, 
code of conduct, etc. The chairs are also going to send a monthly reminder, 
which is included below, that will serve to remind everyone from those who 
joined just today to those who joined many, many years ago of the policies and 
procedures that apply to IETF mailing lists.

Monthly email reminder follows:

---

Hello list,

As a regular reminder, this list is governed by IETF’s Working Group Procedures 
[BCP25], which also includes Anti-Harassment Procedures, and by participating 
you agree to the Note Well [NW] and to follow the Code of Conduct [CoC]. Thank 
you for contributing as part of the TLS Working Group.

As moderators of this list, the chairs are charged with determining when 
messages are “disruptive to the WG process”, phrase from RFC 3934, and, at a 
minimum, the chairs consider the following to be disruptive:
• Unsolicited bulk e-mail (from RFC 3683)
• Discussion of subjects unrelated to IETF policy, meetings, 
activities, or technical concerns (from RFC 3683)
• Unprofessional commentary, regardless of the general subject (from 
RFC 3683)
• Repetition of arguments without providing substantive new information 
• Requesting an unreasonable amount of work to provide information

To elaborate on unprofessional commentary, the chairs believe that this also 
includes uncivil commentary as defined by the IETF List Moderators that 
includes threats of violence, personal attacks, and derogatory language; see 
[Language].

RFC 3683 also includes “announcements of conferences, events, or activities 
that are not sponsored or endorsed by the Internet Society or the IETF”. Please 
contact the chairs if you wish to share these types of announcements, but in 
general the chairs do not believe they are disruptive unless they are excessive 
and lack relevance.

Reminder that if at anytime you feel that if somebody is out of line you can 
say so on list or directly to us (mailto:tls-cha...@ietf.org), the ADs 
(mailto:sec-...@ietf.org), or the Ombudsteam (mailto:ombudst...@ietf.org).

---

Obviously, if we receive significant feedback about any of the above, we can 
revisit the message.

Even though there are three of us, we are still not always immediately 
available to respond and because of that we would like your help in keeping the 
tone of the list professional and civil. Remember that if somebody else is 
behaving badly please refrain from reciprocating.

Cheers,
The Chairs

[BCP25] https://datatracker.ietf.org/doc/bcp25/
[NW] https://www.ietf.org/about/note-well/
[CoC] https://datatracker.ietf.org/doc/bcp54/
[Language] 
https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[John Mattsson]

>This document certainly needs more work particularly when it comes to security 
>considerations.

Thanks Yaroslav. Do you want to see more details on in the current 
considerations or is there some aspect that you are missing?

Cheers,
John

From: Yaroslav Rosomakho 
Date: Friday, 25 October 2024 at 13:07
To: TLS List 
Subject: [TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS
This document certainly needs more work particularly when it comes to security 
considerations. However, it is well thought through and it widens applicability 
of TLS.

I believe it is ready to be adopted as a working group item and I support 
adoption of this work.



-yaroslav



On Fri, Oct 25, 2024 at 3:47 AM Sean Turner 
mailto:s...@sn3rd.com>> 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: Adoption call for Large Record Sizes for TLS and DTLS

[John Mattsson]

Hi Alicja,

The main use case would be to use this on networks where you know that there 
are no old restrictive middleboxes. If used over UDP or SCTP, I don’t know if 
there are any restrictive DTLS 1.2 middleboxes.

Could be an option to restrict things to 2^24 byte, but we felt it was more 
natural to support sizes up to 2^32.

Cheers,
John

From: Alicja Kario 
Date: Friday, 25 October 2024 at 13:58
To: Sean Turner 
Cc: TLS List 
Subject: [TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS
While I'm sceptical of a need to send nearly 2^32 byte records, or
that it would increase performance, the draft is well thought out
and detailed enough. I wouldn't be opposed to it.

Not being compatible with TLS 1.2 middleboxes is a problem too...
I think that precludes it from being "Recommended = Y".

On Friday, 25 October 2024 04:46:00 CEST, 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-tls-super-jumbo-record-limit%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951824135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MXXjdaYYqzMNIGCGPnSzLQoZXBTSJnTfwsuA0cgDlYo%3D&reserved=0
>
> [1]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F119%2Fmaterials%2Fslides-119-tls-large-record-sizes-for-tls-and-dtls-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951839815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dCTMeKDq6uDHTjY7dT5AOQlIhSNnEf51LyYA2Rsd27c%3D&reserved=0
>
> [2] 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FZnGzqIWOkpm_F6zaqAxxtReHpVg%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951851086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ix23qoTiDz0mfPEQsVGuepl%2BxlhKzySDWrH7VPr%2BnoU%3D&reserved=0
> [3] 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FcRH9x6nbLeAnkG-fhOS3ASDA3oU%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951862447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=q0VoTveb6WuwgW42v2aCOkn8Jez0RT5rmB2F4pXhS48%3D&reserved=0

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951873336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=HHBU%2FvR8p6IarMu%2BOxKglbnoeJjC4ooYQ7E2Q24I6Gs%3D&reserved=0
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: ML-DSA in TLS

[Scott Fluhrer (sfluhrer)]

I've been called out on this, and so I need to apologize

> -Original Message-
> From: Scott Fluhrer (sfluhrer) 
> Sent: Thursday, October 24, 2024 2:18 PM
> To: ilariliusva...@welho.com;  
> Subject: [TLS] Re: ML-DSA in TLS
> 
> 
> Is there some complexity there?  Yes, a little.  However, I cannot see how 
> that
> is an unprecedented amount; certainly, less than Deidre's idea of 'let's open
> up the crypto and smash the two sides together'.
> 

I was referring to https://eprint.iacr.org/2023/423.pdf, which looking back, 
Deidre wasn't even a coauthor (my bad - I thought Deidre presented it; 
obviously my advanced age has not improved my memory).

In any case:
- I was certainly not impugning Deidre herself.  If my words came 
across that way, well, that's a bad choice of words on my part, and I apologize 
for my clumsy wording.
- I am also not impugning Nina Bindel and Britta Hale (the authors of 
the work I was referring to).
- I did mean to impugn 2023/423 - I personally think that it is complex 
(anything that involves opening up the crypto engine is infeasible in some 
environments), and doesn't address a real problem that isn't addressed by the 
simple 'lets concatenate the signatures' approach.

I hope to be more careful with my words in the future.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Michael Tuexen]

> On 25. Oct 2024, at 13:56, Alicja Kario  wrote:
> 
> While I'm sceptical of a need to send nearly 2^32 byte records, or
> that it would increase performance, the draft is well thought out
> and detailed enough. I wouldn't be opposed to it.
Hi Alicja,

there is at least one use case of this extension, where bumping the
record size is not due to performance reasons, but applications
are message based and a user message is encapsulated in a DTLS record
to preserve message boundaries. These cases use SCTP as the lower layer
for DTLS and SCTP already supports large message sizes.

Of course, I support adopting the document.

Best regards
Michael
> 
> Not being compatible with TLS 1.2 middleboxes is a problem too...
> I think that precludes it from being "Recommended = Y".
> 
> On Friday, 25 October 2024 04:46:00 CEST, 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/
> 
> -- 
> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Watson Ladd]

On Fri, Oct 25, 2024 at 7:55 AM Bas Westerbaan
 wrote:
>
> Hi Eric,
>
>>
>> Hi Bas,
>>
>> I'm not sure I agree with this analysis, but perhaps it depends on
>> what you mean by "ready-to-go".
>>
>> I would think that the natural thing to do here is to get fairly
>> widespread deployment of support for PQ certificates but then prefer
>> non-PQ certificates. I.e.,
>>
>> 1. Clients would support both PQ and non-PQ certificates.
>> 2. Servers would have both PQ and non-PQ certificates, but would
>>provide the non-PQ certificate if the client supported it.
>>
>> This would enable clients to decide that the risk from non-PQ was high
>> (as you say "the CRQC is near") and disable non-PQ.  Note that it
>> doesn't matter whether the server supports non-PQ as well, as the
>> security benefit comes from the client refusing it [0]. Do we agree so
>> far?
>
>
> Unless a CRQC is near, there is no value, only risk to advertise support for 
> ML-DSA. Thus I'd say clients would add support, but not advertise it. That 
> requires an update at the time CRQC are near. The proposal you sketch also 
> requires an update at the time CRQCs are near to disable the non-PQ 
> certificates.
>
> If you have a system that cannot have an update, then you indeed need a 
> hybrid.

There is a signature scheme secure if any signature scheme is secure.
This fundamentally changes the risk.
>
>>
>> In general, the client is exposed to the union of the risks of
>> compromise of the signature algorithms it supports. Thus, in a world
>> where the client supports: [ECDSA, ML-DSA], then compromise of either
>> algorithm is an issue. By contrast, if the client supports [ECDSA,
>> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
>> result in an attack. This is of course the same logic that leads
>> to hybrids for key establishment.
>>
>> An obvious response here is "if something goes wrong with ML-DSA,
>> we'll just turn it off quickly". This is certainly true for browsers,
>> but I'm less sure it's true for other systems. If you think that
>> it takes a long time to disable algorithms, then it seems like
>> that's an argument that hybrid signatures are safer.
>>
>> -Ekr
>>
>>
>> [0] There is benefit in the servers supporting PQ ahead of time
>> because the client will have to make a cost/benefit decision in
>> terms of breakage, and the more servers support PQ, the easier
>> this decision is.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> It's uncomfortable though if the first blessed SignatureScheme would be a 
>>> non-hybrid. (Also regulators don't make the distinction between 
>>> authentication and encryption, but at least most of them insist on hybrids 
>>> for both though.)
>>>
>>> So I agree it makes sense to set recommended=N for now.
>>>
>>> Best,
>>>
>>>  Bas
>>>
>>>
>>>
>>> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:

 I think an adoption call is a bit premature here. We've got some time, 
 especially in the WebPKI setting.

 In particular, we should have a discussion of whether we want to 
 standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean 
 towards the latter, but I, at least, would like to hear arguments to the 
 contrary.

 -Ekr


 On Wed, Oct 23, 2024 at 11:02 AM John Mattsson 
  wrote:
>
> Let’s have an adoption call asap.
>
>
>
> I made some minor suggestions
> https://github.com/bwesterb/tls-mldsa/pull/3
>
>
>
> John
>
>
>
> From: Alicja Kario 
> Date: Wednesday, 23 October 2024 at 19:59
> To: Bas Westerbaan 
> Cc: 
> Subject: [TLS] Re: ML-DSA in TLS
>
> Hi,
>
> Thanks for the draft, will definitely be helpful.
>
> Few issues:
>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>I think it will be better to continue the numbering in the 0x08.. space
>  * the must in "must use id_ML-DSA(...)" probably should be capitalised, 
> as
>if it doesn't match, the connection needs to be aborted
>
> open question is if we should document error handling explicitly:
>  - illegal_parameter alert if the peer used algorithm not advertised, or
>signature algorithm does not match the certificate
>  - decrypt_error when verification of the signature failed
>
> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
> > Hi all,
> >
> > Unless I overlooked something, we don't have a draft out to
> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
> >
> > It's two days past the I-D submission deadline, but I wanted to
> > point you to a short draft we put together to fill this gap.
> >
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe

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

[Andrei Popov]

Most likely, we’ll need both composite and pure ML-DSA cert chains. We have a 
set of customers who don’t trust pure PQC (yet?), and we have other customers 
who are determined to skip composite cert deployment.


  *   These are independent matters.
Yes, pure and composite signature suites can be introduced via separate I-Ds.

Cheers,

Andrei

From: Bas Westerbaan 
Sent: Friday, October 25, 2024 8:28 AM
To: Eric Rescorla 
Cc:  
Subject: [EXTERNAL] [TLS] Re: ML-DSA in TLS

I'm not sure I agree that there is no value. In general, we try to roll out new 
mechanisms slowly so that we get some experience with how they perform in the 
wild. Given the experience with PQ key establishment, we should probably have 
some concern that ML-DSA won't just work in all cases, and we'd like to find 
that out now, which requires some level of deployment.

I am well aware, and we will, as we have before.

But I think we've strayed from the original question you asked:

In particular, we should have a discussion of whether we want to standardize 
pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean towards the 
latter, but I, at least, would like to hear arguments to the contrary.

I think we should at least standardize pure ML-DSA. That does not prevent us 
from standardising a hybrid as well. These are independent matters.

Best,

 Bas


PS. Majority of testing can be done without hybrids. Don't run it on production 
traffic. Or pad a P-256 key to the length of ML-DSA. If it's compute we want to 
test, run a dummy ML-DSA verify. If we do want the full thing with a hybrid, we 
can use an ad hoc hybrid (as CECPQ2 was ad hoc too.)





The proposal you sketch also requires an update at the time CRQCs are near to 
disable the non-PQ certificates.

Absolutely. We're just in an asymmetrical position in that we're already 
exposed to the risk of non-PQ but not to the risk of PQ.

-Ekr


If you have a system that cannot have an update, then you indeed need a hybrid.


In general, the client is exposed to the union of the risks of
compromise of the signature algorithms it supports. Thus, in a world
where the client supports: [ECDSA, ML-DSA], then compromise of either
algorithm is an issue. By contrast, if the client supports [ECDSA,
EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
result in an attack. This is of course the same logic that leads
to hybrids for key establishment.

An obvious response here is "if something goes wrong with ML-DSA,
we'll just turn it off quickly". This is certainly true for browsers,
but I'm less sure it's true for other systems. If you think that
it takes a long time to disable algorithms, then it seems like
that's an argument that hybrid signatures are safer.

-Ekr


[0] There is benefit in the servers supporting PQ ahead of time
because the client will have to make a cost/benefit decision in
terms of breakage, and the more servers support PQ, the easier
this decision is.













It's uncomfortable though if the first blessed SignatureScheme would be a 
non-hybrid. (Also regulators don't make the distinction between authentication 
and encryption, but at least most of them insist on hybrids for both though.)

So I agree it makes sense to set recommended=N for now.

Best,

 Bas



On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
I think an adoption call is a bit premature here. We've got some time, 
especially in the WebPKI setting.

In particular, we should have a discussion of whether we want to standardize 
pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean towards the 
latter, but I, at least, would like to hear arguments to the contrary.

-Ekr


On Wed, Oct 23, 2024 at 11:02 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Let’s have an adoption call asap.

I made some minor suggestions
https://github.com/bwesterb/tls-mldsa/pull/3

John

From: Alicja Kario mailto:hka...@redhat.com>>
Date: Wednesday, 23 October 2024 at 19:59
To: Bas Westerbaan 
mailto:40cloudflare@dmarc.ietf.org>>
Cc: mailto:tls@ietf.org>>
Subject: [TLS] Re: ML-DSA in TLS
Hi,

Thanks for the draft, will definitely be helpful.

Few issues:
 * The range 0x0900-0x0903 is reserved for backwards compatibility
   I think it will be better to continue the numbering in the 0x08.. space
 * the must in "must use id_ML-DSA(...)" probably should be capitalised, as
   if it doesn't match, the connection needs to be aborted

open question is if we should document error handling explicitly:
 - illegal_parameter alert if the peer used algorithm not advertised, or
   signature algorithm does not match the certificate
 - decrypt_error when verification of the signature failed

On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
> Hi all,
>
> Unless I overlooked something, we don't have a draft out to
> assign a SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to
> point you to a short dr

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

[Alicja Kario]

On Friday, 25 October 2024 14:28:42 CEST, John Mattsson wrote:

Hi Alicja,
 
The main use case would be to use this on networks where you 
know that there are no old restrictive middleboxes. If used over 
UDP or SCTP, I don’t know if there are any restrictive DTLS 1.2 
middleboxes.


but if it's supposed to be used only on networks fully controlled by 
operator,

why "Recommended = Y"?
 
Could be an option to restrict things to 2^24 byte, but we felt 
it was more natural to support sizes up to 2^32.
 
Cheers,

John
 
From: Alicja Kario 

Date: Friday, 25 October 2024 at 13:58
To: Sean Turner 
Cc: TLS List 
Subject: [TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS

While I'm sceptical of a need to send nearly 2^32 byte records, or
that it would increase performance, the draft is well thought out
and detailed enough. I wouldn't be opposed to it.

Not being compatible with TLS 1.2 middleboxes is a problem too...
I think that precludes it from being "Recommended = Y".

On Friday, 25 October 2024 04:46:00 CEST, 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mattsson-tls-super-jumbo-record-limit%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951824135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MXXjdaYYqzMNIGCGPnSzLQoZXBTSJnTfwsuA0cgDlYo%3D&reserved=0 



[1] 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F119%2Fmaterials%2Fslides-119-tls-large-record-sizes-for-tls-and-dtls-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951839815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dCTMeKDq6uDHTjY7dT5AOQlIhSNnEf51LyYA2Rsd27c%3D&reserved=0 



[2] 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FZnGzqIWOkpm_F6zaqAxxtReHpVg%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951851086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Ix23qoTiDz0mfPEQsVGuepl%2BxlhKzySDWrH7VPr%2BnoU%3D&reserved=0
[3] 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FcRH9x6nbLeAnkG-fhOS3ASDA3oU%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce2f3c3f6c6d84ee346f908dcf4ec4caa%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638654542951862447%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=q0VoTveb6WuwgW42v2aCOkn8Jez0RT5rmB2F4pXhS48%3D&reserved=0




--
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: Changing WG Mail List Reputation

[Arnaud Taddei]

+1million

Sent from my iPhone

> On 25 Oct 2024, at 18:00, Sean Turner  wrote:
>
> Hello list,
>
> The TLS list is infamous in that it is regarded by some as [insert your 
> descriptive word; where the chairs have heard the following words used: 
> noxious, toxic, unwelcoming, and rude]. The chairs want to change this 
> reputation and we hope you do too. A big part of this is on the chairs to be 
> be more proactive about moderating behavior that goes against IETF WG 
> procedures, code of conduct, etc. The chairs are also going to send a monthly 
> reminder, which is included below, that will serve to remind everyone from 
> those who joined just today to those who joined many, many years ago of the 
> policies and procedures that apply to IETF mailing lists.
>
> Monthly email reminder follows:
>
> ---
>
> Hello list,
>
> As a regular reminder, this list is governed by IETF’s Working Group 
> Procedures [BCP25], which also includes Anti-Harassment Procedures, and by 
> participating you agree to the Note Well [NW] and to follow the Code of 
> Conduct [CoC]. Thank you for contributing as part of the TLS Working Group.
>
> As moderators of this list, the chairs are charged with determining when 
> messages are “disruptive to the WG process”, phrase from RFC 3934, and, at a 
> minimum, the chairs consider the following to be disruptive:
>• Unsolicited bulk e-mail (from RFC 3683)
>• Discussion of subjects unrelated to IETF policy, meetings, activities, 
> or technical concerns (from RFC 3683)
>• Unprofessional commentary, regardless of the general subject (from RFC 
> 3683)
>• Repetition of arguments without providing substantive new information
>• Requesting an unreasonable amount of work to provide information
>
> To elaborate on unprofessional commentary, the chairs believe that this also 
> includes uncivil commentary as defined by the IETF List Moderators that 
> includes threats of violence, personal attacks, and derogatory language; see 
> [Language].
>
> RFC 3683 also includes “announcements of conferences, events, or activities 
> that are not sponsored or endorsed by the Internet Society or the IETF”. 
> Please contact the chairs if you wish to share these types of announcements, 
> but in general the chairs do not believe they are disruptive unless they are 
> excessive and lack relevance.
>
> Reminder that if at anytime you feel that if somebody is out of line you can 
> say so on list or directly to us (mailto:tls-cha...@ietf.org), the ADs 
> (mailto:sec-...@ietf.org), or the Ombudsteam (mailto:ombudst...@ietf.org).
>
> ---
>
> Obviously, if we receive significant feedback about any of the above, we can 
> revisit the message.
>
> Even though there are three of us, we are still not always immediately 
> available to respond and because of that we would like your help in keeping 
> the tone of the list professional and civil. Remember that if somebody else 
> is behaving badly please refrain from reciprocating.
>
> Cheers,
> The Chairs
>
> [BCP25] https://datatracker.ietf.org/doc/bcp25/
> [NW] https://www.ietf.org/about/note-well/
> [CoC] https://datatracker.ietf.org/doc/bcp54/
> [Language] 
> https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Changing WG Mail List Reputation

[Viktor Dukhovni]

On Fri, Oct 25, 2024 at 08:30:45AM -0400, Sean Turner wrote:

> The TLS list is infamous in that it is regarded by some as [insert
> your descriptive word; where the chairs have heard the following words
> used: noxious, toxic, unwelcoming, and rude]. The chairs want to
> change this reputation and we hope you do too. A big part of this is
> on the chairs to be be more proactive about moderating behavior that
> goes against IETF WG procedures, code of conduct, etc. The chairs are
> also going to send a monthly reminder, which is included below, that
> will serve to remind everyone from those who joined just today to
> those who joined many, many years ago of the policies and procedures
> that apply to IETF mailing lists.

One of the ways in which this WG is sometimes unwelcoming is not covered
by the called out unprofessional behaviour.  Rather, this list at times
appears to be dominated by a single browser-centric world-view, and a
dominant set of entrenched participants.  Perspectives from less
dominant sectors of the TLS user community may not always receive due
consideration.

I did not see being open to a broader set of perspectives on the list of
goals.  It was just the usual set of blatant violations of social norms.

--  
Viktor.

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

[TLS] Re: Changing WG Mail List Reputation

[David Benjamin]

Hear, hear! Thank for you sending this, Sean!

On Fri, Oct 25, 2024, 08:53 Arnaud Taddei  wrote:

> +1million
>
> Sent from my iPhone
>
> > On 25 Oct 2024, at 18:00, Sean Turner  wrote:
> >
> > Hello list,
> >
> > The TLS list is infamous in that it is regarded by some as [insert your
> descriptive word; where the chairs have heard the following words used:
> noxious, toxic, unwelcoming, and rude]. The chairs want to change this
> reputation and we hope you do too. A big part of this is on the chairs to
> be be more proactive about moderating behavior that goes against IETF WG
> procedures, code of conduct, etc. The chairs are also going to send a
> monthly reminder, which is included below, that will serve to remind
> everyone from those who joined just today to those who joined many, many
> years ago of the policies and procedures that apply to IETF mailing lists.
> >
> > Monthly email reminder follows:
> >
> > ---
> >
> > Hello list,
> >
> > As a regular reminder, this list is governed by IETF’s Working Group
> Procedures [BCP25], which also includes Anti-Harassment Procedures, and by
> participating you agree to the Note Well [NW] and to follow the Code of
> Conduct [CoC]. Thank you for contributing as part of the TLS Working Group.
> >
> > As moderators of this list, the chairs are charged with determining when
> messages are “disruptive to the WG process”, phrase from RFC 3934, and, at
> a minimum, the chairs consider the following to be disruptive:
> >• Unsolicited bulk e-mail (from RFC 3683)
> >• Discussion of subjects unrelated to IETF policy, meetings,
> activities, or technical concerns (from RFC 3683)
> >• Unprofessional commentary, regardless of the general subject (from
> RFC 3683)
> >• Repetition of arguments without providing substantive new
> information
> >• Requesting an unreasonable amount of work to provide information
> >
> > To elaborate on unprofessional commentary, the chairs believe that this
> also includes uncivil commentary as defined by the IETF List Moderators
> that includes threats of violence, personal attacks, and derogatory
> language; see [Language].
> >
> > RFC 3683 also includes “announcements of conferences, events, or
> activities that are not sponsored or endorsed by the Internet Society or
> the IETF”. Please contact the chairs if you wish to share these types of
> announcements, but in general the chairs do not believe they are disruptive
> unless they are excessive and lack relevance.
> >
> > Reminder that if at anytime you feel that if somebody is out of line you
> can say so on list or directly to us (mailto:tls-cha...@ietf.org), the
> ADs (mailto:sec-...@ietf.org), or the Ombudsteam (mailto:
> ombudst...@ietf.org).
> >
> > ---
> >
> > Obviously, if we receive significant feedback about any of the above, we
> can revisit the message.
> >
> > Even though there are three of us, we are still not always immediately
> available to respond and because of that we would like your help in keeping
> the tone of the list professional and civil. Remember that if somebody else
> is behaving badly please refrain from reciprocating.
> >
> > Cheers,
> > The Chairs
> >
> > [BCP25] https://datatracker.ietf.org/doc/bcp25/
> > [NW] https://www.ietf.org/about/note-well/
> > [CoC] https://datatracker.ietf.org/doc/bcp54/
> > [Language]
> https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions
> > ___
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
> --
> This electronic communication and the information and any files
> transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may
> contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
> ___
> 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: ML-DSA in TLS

[Alicja Kario]

On Thursday, 24 October 2024 17:58:18 CEST, Watson Ladd wrote:

On Thu, Oct 24, 2024 at 8:52 AM Tim Hollebeek
 wrote:
My personal feelings on pure vs composite are actually the 
union of several

previous comments:

1. Like EKR, I actually have a weak preference for composite, all other
things being equal. Failures happen and I like backup mechanisms
when they are relatively affordable and can be afforded. ...


If there is an ecosystem that cannot afford an algorithm break in a
signature, and where other constraints are less important, there is
only one choice: hash based signatures.

The difference in security between authentication and encryption (we
do not need authentication to last more than a second beyond the
lifetime of a connection) means that the consequences of a break are
different. If tomorrow RSA was insecure, we would switch to ECC: no
hybrid certs necessary. Likewise we can deploy multiple signature
algorithms.

Of course people complain that it takes time to switch certs etc. etc.
That's exactly why we've invested in automated issuance.


and precisely why we have algorithm agility in TLS; and precisely why any
half-decent server has support for setting up two certificates: now
we use it for RSA and ECDSA, but we need to be able to use it with ECDSA
and ML-DSA, _soon_

and for that we need the signature scheme IDs

--
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: Consensus Call: early code point request for draft-ietf-tls-tlsflags

[Salz, Rich]

I mean "IANA cannot have designated..."

I blame auto-correct.  Or outlook.  Anyone other than me.

On 10/25/24, 10:50 AM, "Salz, Rich"  wrote:

> The following PR creates the TLS Flags sub-registry where we can manage the 
> actual flags. I asserted that the chairs control adding values, which won’t 
> be true once (and if) the registry goes to IANA (it’ll be the DEs: Rich, 
> Nick, and Yoav), and populated the 1st value from the draft: 
> resumption_across_names. Assuming this is good, I will merge the PR.


Apparently IANA can have designated experts control things until the RFC is 
published.


Does this mean we'll need a new RFC to switch things? Or can it be done by IESG 
telling IANA? If the latter, than maybe we do a little dance to say IESG 
designated control to the TLS WG Chairs and then IESG designates control to the 
regular TLS designated experts? But if the proposal you're saying works, great. 
I'm just interested in trying to avoid administrivia while we wait to get this 
new sub-registry into our hot little hands :)


___
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: ML-DSA in TLS

[Bas Westerbaan]

Hi Eric,


> Hi Bas,
>
> I'm not sure I agree with this analysis, but perhaps it depends on
> what you mean by "ready-to-go".
>
> I would think that the natural thing to do here is to get fairly
> widespread deployment of support for PQ certificates but then prefer
> non-PQ certificates. I.e.,
>
> 1. Clients would support both PQ and non-PQ certificates.
> 2. Servers would have both PQ and non-PQ certificates, but would
>provide the non-PQ certificate if the client supported it.
>
> This would enable clients to decide that the risk from non-PQ was high
> (as you say "the CRQC is near") and disable non-PQ.  Note that it
> doesn't matter whether the server supports non-PQ as well, as the
> security benefit comes from the client refusing it [0]. Do we agree so
> far?
>

Unless a CRQC is near, there is no value, only risk to advertise support
for ML-DSA. Thus I'd say clients would add support, but not advertise it.
That requires an update at the time CRQC are near. The proposal you sketch
also requires an update at the time CRQCs are near to disable the non-PQ
certificates.

If you have a system that cannot have an update, then you indeed need a
hybrid.


> In general, the client is exposed to the union of the risks of
> compromise of the signature algorithms it supports. Thus, in a world
> where the client supports: [ECDSA, ML-DSA], then compromise of either
> algorithm is an issue. By contrast, if the client supports [ECDSA,
> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
> result in an attack. This is of course the same logic that leads
> to hybrids for key establishment.
>
> An obvious response here is "if something goes wrong with ML-DSA,
> we'll just turn it off quickly". This is certainly true for browsers,
> but I'm less sure it's true for other systems. If you think that
> it takes a long time to disable algorithms, then it seems like
> that's an argument that hybrid signatures are safer.
>
> -Ekr
>
>
> [0] There is benefit in the servers supporting PQ ahead of time
> because the client will have to make a cost/benefit decision in
> terms of breakage, and the more servers support PQ, the easier
> this decision is.
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> It's uncomfortable though if the first blessed SignatureScheme would be a
>> non-hybrid. (Also regulators don't make the distinction between
>> authentication and encryption, but at least most of them insist on hybrids
>> for both though.)
>>
>> So I agree it makes sense to set recommended=N for now.
>>
>> Best,
>>
>>  Bas
>>
>>
>>
>> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:
>>
>>> I think an adoption call is a bit premature here. We've got some time,
>>> especially in the WebPKI setting.
>>>
>>> In particular, we should have a discussion of whether we want to
>>> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
>>> towards the latter, but I, at least, would like to hear arguments to the
>>> contrary.
>>>
>>> -Ekr
>>>
>>>
>>> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson >> 40ericsson@dmarc.ietf.org> wrote:
>>>
 Let’s have an adoption call asap.



 I made some minor suggestions
 https://github.com/bwesterb/tls-mldsa/pull/3



 John



 *From: *Alicja Kario 
 *Date: *Wednesday, 23 October 2024 at 19:59
 *To: *Bas Westerbaan 
 *Cc: *
 *Subject: *[TLS] Re: ML-DSA in TLS

 Hi,

 Thanks for the draft, will definitely be helpful.

 Few issues:
  * The range 0x0900-0x0903 is reserved for backwards compatibility
I think it will be better to continue the numbering in the 0x08..
 space
  * the must in "must use id_ML-DSA(...)" probably should be
 capitalised, as
if it doesn't match, the connection needs to be aborted

 open question is if we should document error handling explicitly:
  - illegal_parameter alert if the peer used algorithm not advertised, or
signature algorithm does not match the certificate
  - decrypt_error when verification of the signature failed

 On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
 > Hi all,
 >
 > Unless I overlooked something, we don't have a draft out to
 > assign a SignatureAlgorithm to ML-DSA for use in TLS.
 >
 > It's two days past the I-D submission deadline, but I wanted to
 > point you to a short draft we put together to fill this gap.
 >
 >
 https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0
 

[TLS] Re: Changing WG Mail List Reputation

[Bob Beck]

Thanks for this Sean.

On Fri, Oct 25, 2024 at 6:31 AM Sean Turner  wrote:

> Hello list,
>
> The TLS list is infamous in that it is regarded by some as [insert your
> descriptive word; where the chairs have heard the following words used:
> noxious, toxic, unwelcoming, and rude]. The chairs want to change this
> reputation and we hope you do too. A big part of this is on the chairs to
> be be more proactive about moderating behavior that goes against IETF WG
> procedures, code of conduct, etc. The chairs are also going to send a
> monthly reminder, which is included below, that will serve to remind
> everyone from those who joined just today to those who joined many, many
> years ago of the policies and procedures that apply to IETF mailing lists.
>
> Monthly email reminder follows:
>
> ---
>
> Hello list,
>
> As a regular reminder, this list is governed by IETF’s Working Group
> Procedures [BCP25], which also includes Anti-Harassment Procedures, and by
> participating you agree to the Note Well [NW] and to follow the Code of
> Conduct [CoC]. Thank you for contributing as part of the TLS Working Group.
>
> As moderators of this list, the chairs are charged with determining when
> messages are “disruptive to the WG process”, phrase from RFC 3934, and, at
> a minimum, the chairs consider the following to be disruptive:
> • Unsolicited bulk e-mail (from RFC 3683)
> • Discussion of subjects unrelated to IETF policy, meetings,
> activities, or technical concerns (from RFC 3683)
> • Unprofessional commentary, regardless of the general subject
> (from RFC 3683)
> • Repetition of arguments without providing substantive new
> information
> • Requesting an unreasonable amount of work to provide information
>
> To elaborate on unprofessional commentary, the chairs believe that this
> also includes uncivil commentary as defined by the IETF List Moderators
> that includes threats of violence, personal attacks, and derogatory
> language; see [Language].
>
> RFC 3683 also includes “announcements of conferences, events, or
> activities that are not sponsored or endorsed by the Internet Society or
> the IETF”. Please contact the chairs if you wish to share these types of
> announcements, but in general the chairs do not believe they are disruptive
> unless they are excessive and lack relevance.
>
> Reminder that if at anytime you feel that if somebody is out of line you
> can say so on list or directly to us (mailto:tls-cha...@ietf.org), the
> ADs (mailto:sec-...@ietf.org), or the Ombudsteam (mailto:
> ombudst...@ietf.org).
>
> ---
>
> Obviously, if we receive significant feedback about any of the above, we
> can revisit the message.
>
> Even though there are three of us, we are still not always immediately
> available to respond and because of that we would like your help in keeping
> the tone of the list professional and civil. Remember that if somebody else
> is behaving badly please refrain from reciprocating.
>
> Cheers,
> The Chairs
>
> [BCP25] https://datatracker.ietf.org/doc/bcp25/
> [NW] https://www.ietf.org/about/note-well/
> [CoC] https://datatracker.ietf.org/doc/bcp54/
> [Language]
> https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions
> ___
> 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: ML-DSA in TLS

[Eric Rescorla]

On Thu, Oct 24, 2024 at 12:38 AM Bas Westerbaan  wrote:

> Today for the WebPKI there is no security benefit to enabling post-quantum
> certificates (in stark contrast with post-quantum key agreement.) On the
> other hand, there is a big cost with extra bytes on the wire. As it stands,
> we do not intend to enable post-quantum certificates by default before the
> CRQC is near. At that point, there is little value in hybrid certificates.
> There is value in having post-quantum certificates ready-to-go now (without
> flipping the switch.) And for that pure ML-DSA makes more sense.
>

Hi Bas,

I'm not sure I agree with this analysis, but perhaps it depends on
what you mean by "ready-to-go".

I would think that the natural thing to do here is to get fairly
widespread deployment of support for PQ certificates but then prefer
non-PQ certificates. I.e.,

1. Clients would support both PQ and non-PQ certificates.
2. Servers would have both PQ and non-PQ certificates, but would
   provide the non-PQ certificate if the client supported it.

This would enable clients to decide that the risk from non-PQ was high
(as you say "the CRQC is near") and disable non-PQ.  Note that it
doesn't matter whether the server supports non-PQ as well, as the
security benefit comes from the client refusing it [0]. Do we agree so
far?

In general, the client is exposed to the union of the risks of
compromise of the signature algorithms it supports. Thus, in a world
where the client supports: [ECDSA, ML-DSA], then compromise of either
algorithm is an issue. By contrast, if the client supports [ECDSA,
EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
result in an attack. This is of course the same logic that leads
to hybrids for key establishment.

An obvious response here is "if something goes wrong with ML-DSA,
we'll just turn it off quickly". This is certainly true for browsers,
but I'm less sure it's true for other systems. If you think that
it takes a long time to disable algorithms, then it seems like
that's an argument that hybrid signatures are safer.

-Ekr


[0] There is benefit in the servers supporting PQ ahead of time
because the client will have to make a cost/benefit decision in
terms of breakage, and the more servers support PQ, the easier
this decision is.













>
> It's uncomfortable though if the first blessed SignatureScheme would be a
> non-hybrid. (Also regulators don't make the distinction between
> authentication and encryption, but at least most of them insist on hybrids
> for both though.)
>
> So I agree it makes sense to set recommended=N for now.
>
> Best,
>
>  Bas
>
>
>
> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:
>
>> I think an adoption call is a bit premature here. We've got some time,
>> especially in the WebPKI setting.
>>
>> In particular, we should have a discussion of whether we want to
>> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
>> towards the latter, but I, at least, would like to hear arguments to the
>> contrary.
>>
>> -Ekr
>>
>>
>> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson > 40ericsson@dmarc.ietf.org> wrote:
>>
>>> Let’s have an adoption call asap.
>>>
>>>
>>>
>>> I made some minor suggestions
>>> https://github.com/bwesterb/tls-mldsa/pull/3
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> *From: *Alicja Kario 
>>> *Date: *Wednesday, 23 October 2024 at 19:59
>>> *To: *Bas Westerbaan 
>>> *Cc: *
>>> *Subject: *[TLS] Re: ML-DSA in TLS
>>>
>>> Hi,
>>>
>>> Thanks for the draft, will definitely be helpful.
>>>
>>> Few issues:
>>>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>>>I think it will be better to continue the numbering in the 0x08..
>>> space
>>>  * the must in "must use id_ML-DSA(...)" probably should be capitalised,
>>> as
>>>if it doesn't match, the connection needs to be aborted
>>>
>>> open question is if we should document error handling explicitly:
>>>  - illegal_parameter alert if the peer used algorithm not advertised, or
>>>signature algorithm does not match the certificate
>>>  - decrypt_error when verification of the signature failed
>>>
>>> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
>>> > Hi all,
>>> >
>>> > Unless I overlooked something, we don't have a draft out to
>>> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
>>> >
>>> > It's two days past the I-D submission deadline, but I wanted to
>>> > point you to a short draft we put together to fill this gap.
>>> >
>>> >
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0
>>> 

[TLS] Re: ML-DSA in TLS

[Eric Rescorla]

On Fri, Oct 25, 2024 at 7:54 AM Bas Westerbaan  wrote:

> Hi Eric,
>
>
>> Hi Bas,
>>
>> I'm not sure I agree with this analysis, but perhaps it depends on
>> what you mean by "ready-to-go".
>>
>> I would think that the natural thing to do here is to get fairly
>> widespread deployment of support for PQ certificates but then prefer
>> non-PQ certificates. I.e.,
>>
>> 1. Clients would support both PQ and non-PQ certificates.
>> 2. Servers would have both PQ and non-PQ certificates, but would
>>provide the non-PQ certificate if the client supported it.
>>
>> This would enable clients to decide that the risk from non-PQ was high
>> (as you say "the CRQC is near") and disable non-PQ.  Note that it
>> doesn't matter whether the server supports non-PQ as well, as the
>> security benefit comes from the client refusing it [0]. Do we agree so
>> far?
>>
>
> Unless a CRQC is near, there is no value, only risk to advertise support
> for ML-DSA. Thus I'd say clients would add support, but not advertise it.
> That requires an update at the time CRQC are near.
>

I'm not sure I agree that there is no value. In general, we try to roll out
new mechanisms slowly so that we get some experience with how they perform
in the wild. Given the experience with PQ key establishment, we should
probably have some concern that ML-DSA won't just work in all cases, and
we'd like to find that out now, which requires some level of deployment.



> The proposal you sketch also requires an update at the time CRQCs are near
> to disable the non-PQ certificates.
>

Absolutely. We're just in an asymmetrical position in that we're already
exposed to the risk of non-PQ but not to the risk of PQ.

-Ekr


> If you have a system that cannot have an update, then you indeed need a
> hybrid.
>
>
>> In general, the client is exposed to the union of the risks of
>> compromise of the signature algorithms it supports. Thus, in a world
>> where the client supports: [ECDSA, ML-DSA], then compromise of either
>> algorithm is an issue. By contrast, if the client supports [ECDSA,
>> EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
>> result in an attack. This is of course the same logic that leads
>> to hybrids for key establishment.
>>
>> An obvious response here is "if something goes wrong with ML-DSA,
>> we'll just turn it off quickly". This is certainly true for browsers,
>> but I'm less sure it's true for other systems. If you think that
>> it takes a long time to disable algorithms, then it seems like
>> that's an argument that hybrid signatures are safer.
>>
>> -Ekr
>>
>>
>> [0] There is benefit in the servers supporting PQ ahead of time
>> because the client will have to make a cost/benefit decision in
>> terms of breakage, and the more servers support PQ, the easier
>> this decision is.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> It's uncomfortable though if the first blessed SignatureScheme would be
>>> a non-hybrid. (Also regulators don't make the distinction between
>>> authentication and encryption, but at least most of them insist on hybrids
>>> for both though.)
>>>
>>> So I agree it makes sense to set recommended=N for now.
>>>
>>> Best,
>>>
>>>  Bas
>>>
>>>
>>>
>>> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla  wrote:
>>>
 I think an adoption call is a bit premature here. We've got some time,
 especially in the WebPKI setting.

 In particular, we should have a discussion of whether we want to
 standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
 towards the latter, but I, at least, would like to hear arguments to the
 contrary.

 -Ekr


 On Wed, Oct 23, 2024 at 11:02 AM John Mattsson >>> 40ericsson@dmarc.ietf.org> wrote:

> Let’s have an adoption call asap.
>
>
>
> I made some minor suggestions
> https://github.com/bwesterb/tls-mldsa/pull/3
>
>
>
> John
>
>
>
> *From: *Alicja Kario 
> *Date: *Wednesday, 23 October 2024 at 19:59
> *To: *Bas Westerbaan 
> *Cc: *
> *Subject: *[TLS] Re: ML-DSA in TLS
>
> Hi,
>
> Thanks for the draft, will definitely be helpful.
>
> Few issues:
>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>I think it will be better to continue the numbering in the 0x08..
> space
>  * the must in "must use id_ML-DSA(...)" probably should be
> capitalised, as
>if it doesn't match, the connection needs to be aborted
>
> open question is if we should document error handling explicitly:
>  - illegal_parameter alert if the peer used algorithm not advertised,
> or
>signature algorithm does not match the certificate
>  - decrypt_error when verification of the signature failed
>
> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
> > Hi all,
> >
> > Unless I overlooked something, we don't have a draft out to
> > assign a Sig

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

[Alicja Kario]

While I'm sceptical of a need to send nearly 2^32 byte records, or
that it would increase performance, the draft is well thought out
and detailed enough. I wouldn't be opposed to it.

Not being compatible with TLS 1.2 middleboxes is a problem too...
I think that precludes it from being "Recommended = Y".

On Friday, 25 October 2024 04:46:00 CEST, 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/


--
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: Adoption call for Large Record Sizes for TLS and DTLS

[Yaroslav Rosomakho]

This document certainly needs more work particularly when it comes to
security considerations. However, it is well thought through and it widens
applicability of TLS.

I believe it is ready to be adopted as a working group item and I support
adoption of this work.



-yaroslav



On Fri, Oct 25, 2024 at 3:47 AM 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: ML-DSA in TLS

[Alicja Kario]

On Friday, 25 October 2024 16:31:17 CEST, Eric Rescorla wrote:



On Thu, Oct 24, 2024 at 12:38 AM Bas Westerbaan  wrote:
Today for the WebPKI there is no security benefit to enabling 
post-quantum certificates (in stark contrast with post-quantum 
key agreement.) On the other hand, there is a big cost with 
extra bytes on the wire. As it stands, we do not intend to 
enable post-quantum certificates by default before the CRQC is 
near. At that point, there is little value in hybrid 
certificates. There is value in having post-quantum certificates 
ready-to-go now (without flipping the switch.) And for that pure 
ML-DSA makes more sense.


Hi Bas,

I'm not sure I agree with this analysis, but perhaps it depends on
what you mean by "ready-to-go".

I would think that the natural thing to do here is to get fairly
widespread deployment of support for PQ certificates but then prefer
non-PQ certificates. I.e.,

1. Clients would support both PQ and non-PQ certificates.
2. Servers would have both PQ and non-PQ certificates, but would
   provide the non-PQ certificate if the client supported it.

This would enable clients to decide that the risk from non-PQ was high
(as you say "the CRQC is near") and disable non-PQ.  Note that it
doesn't matter whether the server supports non-PQ as well, as the
security benefit comes from the client refusing it [0]. Do we agree so
far?

In general, the client is exposed to the union of the risks of
compromise of the signature algorithms it supports. Thus, in a world
where the client supports: [ECDSA, ML-DSA], then compromise of either
algorithm is an issue. By contrast, if the client supports [ECDSA,
EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
result in an attack. This is of course the same logic that leads
to hybrids for key establishment.

An obvious response here is "if something goes wrong with ML-DSA,
we'll just turn it off quickly". This is certainly true for browsers,
but I'm less sure it's true for other systems. If you think that
it takes a long time to disable algorithms, then it seems like
that's an argument that hybrid signatures are safer.



disabling things is frequently available through user config, we went
through that recently with DSA, enabling things requires support in code
for those new features, that's much more involved

--
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: Consensus Call: early code point request for draft-ietf-tls-tlsflags

[Sean Turner]

> On Oct 25, 2024, at 10:52, Salz, Rich  wrote:
> 
> I mean "IANA cannot have designated..."
> 
> I blame auto-correct.  Or outlook.  Anyone other than me.
> 
> On 10/25/24, 10:50 AM, "Salz, Rich"  wrote:
> 
>> The following PR creates the TLS Flags sub-registry where we can manage the 
>> actual flags. I asserted that the chairs control adding values, which won’t 
>> be true once (and if) the registry goes to IANA (it’ll be the DEs: Rich, 
>> Nick, and Yoav), and populated the 1st value from the draft: 
>> resumption_across_names. Assuming this is good, I will merge the PR.
> 
> 
> Apparently IANA can have designated experts control things until the RFC is 
> published.

Oh, if DEs can (or are willing) to do it then I am all about having you manage 
it! PR updated:
https://github.com/tlswg/wg-materials/pull/22/files

> Does this mean we'll need a new RFC to switch things? Or can it be done by 
> IESG telling IANA? If the latter, than maybe we do a little dance to say IESG 
> designated control to the TLS WG Chairs and then IESG designates control to 
> the regular TLS designated experts? But if the proposal you're saying works, 
> great. I'm just interested in trying to avoid administrivia while we wait to 
> get this new sub-registry into our hot little hands :)

My thinking is that the repo is just going to get PRed to just refer to the 
IANA sub-registry when it is created ;)

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