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

[Sean Turner]

Hi! The chairs have judged that there is consensus to request an early code 
point for this draft-ietf-tls-tlsflags. I will send a message to the DEs and 
IANA to get this code point assigned.

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.

spt

> On Sep 27, 2024, at 15:00, Sean Turner  wrote:
> 
> Hi! We paused progression of draft-ietf-tls-tlsflags until we had 
> implementations. We (the chairs) have gotten requests for an early IANA code 
> point; if you remember draft-ietf-tls-cross-sni-resumption, a WG I-D that is 
> now expired, and draft-jhoyla-req-mtls-flag, a individual I-D, would both 
> need this code point.  Note that like draft-ietf-tls-dtls-rrc, 
> draft-ietf-tls-tlsflags also creates a new sub-registry, but IANA cannot 
> create a temporary registry and then manage it for us. We will do that in the 
> WG/I-D; there is not much to manage because at this point it’s only two 
> values. With that said ….
> 
> We (the Chairs) would like to determine whether there is consensus to request 
> an early code point request for "tls_flags” in the TLS ExtensionType Values 
> registry registry; see Section 4 of the I-D [0].  The point of this consensus 
> call is to determine whether you think this I-D is stable enough to request a 
> code point from the DEs.  Please let the list know by 11 October 2024 if you 
> support this request.
> 
> Cheers,
> spt
> (as TLS Co-Chair)
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

___
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-key-share-prediction

[Sean Turner]

Hi! The chairs have judged that there is consensus to request an early code 
point for this I-D.

While there was some discussion about what the Name value should be, there was 
no consensus on a new Name value and it is not clear that choosing a different 
name from where the values comes from is of benefit.

spt

> On Sep 24, 2024, at 14:17, Sean Turner  wrote:
> 
> Hi! After discussions with the author (David Benjamin) of 
> draft-ietf-tls-key-share-prediction [0], I would like to determine whether 
> there is consensus to request an “early” * code point request for a 
> 'tls-supported-group' entry in the Service Parameter Keys registry; see 
> Section 5 of the I-D.  The point of this consensus call is to determine 
> whether you think this I-D is stable enough to request a code point in the 
> Expert Review range [1].  Please let the list know by 8 October 2023 if you 
> support this “early" allocation.
> 
> * Early is in quotes because, technically, this is not an early IANA 
> allocation as defined in [2]; I am just calling it “early" because it’s 
> before the I-D is an RFC. I confirmed with the Service Parameter Keys DEs 
> (Designated Experts) that we can get a code point in the Expert Review space 
> if the I-D is stable; if not, then we should be using the Private Use space.
> 
> spt
> 
> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-key-share-prediction/
> [1] https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml
> [2] https://datatracker.ietf.org/doc/rfc7120/

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

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

[Sean Turner]

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] Re: [Last-Call] Artart last call review of draft-ietf-tls-svcb-ech-06

[Eric Rescorla]

I don't think a MUST would be totally inappropriate but it's possible to
get into a state where you have a mismatch due to DNS latency or partial
rollback, so this MUST will be violated in practice in some cases (though
as you indicate, that's not good). ECH has a way to recover from these
conditions,

-Ekr


On Wed, Oct 23, 2024 at 9:45 AM Barry Leiba via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Barry Leiba
> Review result: Ready with Nits
>
> Just two small comments on this straightforward document:
>
> — Section 3 —
>
>  Figure 1: ECH SvcParam with a public_name of "ech-sites.example.com"
>
> The example actually encodes example.net, not example.com
> [This was a test to see if we check these things, right? :-) ]
>
> — Section 4 —
>
>These servers SHOULD support a protocol version that is compatible
>with ECH.
>
> Why is this not a MUST?  What might be a reason to publish an ECH record
> for a
> server that doesn’t support ECH?
>
>
> --
> last-call mailing list -- last-c...@ietf.org
> To unsubscribe send an email to last-call-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

[Stephen Farrell]

Hiya,

On 23/10/2024 18:29, Bas Westerbaan wrote:


Unless I overlooked something, we don't have a draft out to assign a
SignatureAlgorithm to ML-DSA for use in TLS.


I don't think a gap in the set of documentation is
anywhere near a good reason to add things to TLS.

I also agree with ekr that there's absolutely no real
rush here, despite what seems like vendor enthusiasm
for shiny new things.

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Deirdre Connolly]

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


Yes.


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.


Definitely agree.


On Thu, Oct 24, 2024 at 1:04 PM Ilari Liusvaara 
wrote:

> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Deirdre Connolly]

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

💯% agree.

> 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.)

I don't necessarily agree but, sure whatever

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

++

Doing the same for pure ML-KEM SupportedGroup codepoints too.

On Thu, Oct 24, 2024 at 3:39 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.
>
> 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
>>> 
>>> >
>>> > So far, I see only one open question: whether to set a non-zero
>>> > context string.
>>> >
>>> > Best,
>>> >
>>> >  Bas
>>> >
>>> >
>>> >
>>>
>>> --
>>> 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%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%3D&reserved=0
>>> 
>>> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Rep

[TLS] Re: ML-DSA in TLS

[Watson Ladd]

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

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.
>
> 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.
>
> -Tim
>
> > -Original Message-
> > From: Alicja Kario 
> > Sent: Thursday, October 24, 2024 5:57 AM
> > To: Eric Rescorla 
> > Cc: John Mattsson ; Bas
> > Westerbaan ; 
> > 
> > Subject: [TLS] Re: ML-DSA in TLS
> >
> > On Thursday, 24 October 2024 04:47:02 CEST, 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.
> >
> > For TLS I'm of the opinion that hybrids are not necessary.
> > We might define hybrids later, if those gain traction, but pure have their 
> > place.
> >
> > > -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://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
> > >>
> > >> So far, I see only one open question: whether to set a non-zero
> > >> context string.
> > >>
> > >> Best,
> > >>
> > >>  Bas
> > >>
> > >>
> > >>
> > >
> >
> > --
> > Regards,
> > Alicja (nee Hubert) Kario
> > Principal Quality Engineer, RHEL Crypto team
> > Web: http://www.cz.redhat.com/
> > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
> >
> > ___
> > T

[TLS] Re: ML-DSA in TLS

[Tim Hollebeek]

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

-Tim

> -Original Message-
> From: Alicja Kario 
> Sent: Thursday, October 24, 2024 5:57 AM
> To: Eric Rescorla 
> Cc: John Mattsson ; Bas
> Westerbaan ; 
> 
> Subject: [TLS] Re: ML-DSA in TLS
> 
> On Thursday, 24 October 2024 04:47:02 CEST, 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.
> 
> For TLS I'm of the opinion that hybrids are not necessary.
> We might define hybrids later, if those gain traction, but pure have their 
> place.
> 
> > -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://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
> >>
> >> So far, I see only one open question: whether to set a non-zero
> >> context string.
> >>
> >> Best,
> >>
> >>  Bas
> >>
> >>
> >>
> >
> 
> --
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: http://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


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

[Alicja Kario]

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://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html

So far, I see only one open question: whether to set a non-zero 
context string.


So, we do have a context string in the actual message being signed
in TLS 1.3, so that's a property for all signatures in TLS 1.3.

I've proposed a PR that makes it explicit how they're supposed to be
generated and validated: https://github.com/bwesterb/tls-mldsa/pull/6

I've also proposed a draft to forbid use of those schemes in TLS 1.2:
https://github.com/bwesterb/tls-mldsa/pull/7

--
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: [Last-Call] Artart last call review of draft-ietf-tls-svcb-ech-06

[Ben Schwartz]

Thanks for noticing the example.net error.  Fixed! [1].

I think we made that a SHOULD for contrast with the requirement that the server 
prove authority for public_name.  If the server isn't authoritative for 
public_name, the connection will fail completely, so that's a MUST.  If the 
server has the wrong TLS version, the client will degrade gracefully to a 
non-ECH connection mode, which is arguably tolerable.

--Ben

[1] 
https://github.com/tlswg/draft-ietf-tls-svcb-ech/commit/4c70e781eb3bb9f05354f54fa1337131f823b96e


From: Eric Rescorla 
Sent: Thursday, October 24, 2024 11:29 AM
To: Barry Leiba 
Cc: a...@ietf.org ; draft-ietf-tls-svcb-ech@ietf.org 
; last-c...@ietf.org 
; tls@ietf.org 
Subject: Re: [Last-Call] Artart last call review of draft-ietf-tls-svcb-ech-06

I don't think a MUST would be totally inappropriate but it's possible to get 
into a state where you have a mismatch due to DNS latency or partial rollback, 
so this MUST will be violated in practice in some cases (though as you indicate,

I don't think a MUST would be totally inappropriate but it's possible to get 
into a state where you have a mismatch due to DNS latency or partial rollback, 
so this MUST will be violated in practice in some cases (though as you 
indicate, that's not good). ECH has a way to recover from these conditions,

-Ekr


On Wed, Oct 23, 2024 at 9:45 AM Barry Leiba via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Barry Leiba
Review result: Ready with Nits

Just two small comments on this straightforward document:

— Section 3 —

 Figure 1: ECH SvcParam with a public_name of 
"ech-sites.example.com"

The example actually encodes 
example.net,
 not 
example.com
[This was a test to see if we check these things, right? :-) ]

— Section 4 —

   These servers SHOULD support a protocol version that is compatible
   with ECH.

Why is this not a MUST?  What might be a reason to publish an ECH record for a
server that doesn’t support ECH?


--
last-call mailing list -- last-c...@ietf.org
To unsubscribe send an email to 
last-call-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)]

> -Original Message-
> From: ilariliusva...@welho.com 
> Sent: Thursday, October 24, 2024 1:03 PM
> To:  
> Subject: [TLS] Re: ML-DSA in TLS
> 
> On Thu, Oct 24, 2024 at 03:51:50PM +, Tim Hollebeek wrote:
> > 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.

I'm sorry, but I have a really hard time buying this 'composite signatures are 
hugely complex' argument.  For hybrid, the validation check is essentially:

if conventional_signature_validates && pq_signature_validates
accept the signature

Now, at least in the transition time, we need both conventional and pq 
signature routines, hence I can't see how those routines count as additional 
complexity (because we need them anyways).

The only complexity I see added are:
- Something to initially hash the message (at least, in the current 
LAMPS proposal)
- Something to parse the hybrid public key into its components
- Something to parse the hybrid signature into its components
- The AND operation

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'.

And, BTW: the AND operation is externally testable (by the simple expedient of 
passing in a hybrid signature with one signature incorrect).


That said, if the working group thinks that it is better to modify the TLS 
protocol to accept two certificates (and generate two signatures with the two 
public keys), that is reasonable - it could facilitate easier transitions from 
an operational standpoint (and then later a transition to a pure PQ solution 
once a CRQC becomes a reality, and the classical half is no longer useful).

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

Possibly because the analysis would be too trivial to publish an academic paper 
on?  If you can generate a forgery of 'ECDSA signature || ML-KEM signature', 
then you can obviously generate a forgery of 'ML-KEM signature'.


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

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

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.

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
>> 
>> >
>> > So far, I see only one open question: whether to set a non-zero
>> > context string.
>> >
>> > Best,
>> >
>> >  Bas
>> >
>> >
>> >
>>
>> --
>> 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%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Alicja Kario]

On Wednesday, 23 October 2024 22:46:08 CEST, Bas Westerbaan wrote:

Alicja, John, thanks for your review.

Onto Alicja's open comments:

 - 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

Good points, but these stipulations are not specific to ML-DSA 
and belong, if not already present, in rfc8446(bis).


yes, I agree about scope creep, will consider writing a SLH-DSA later
(if somebody won't beat me to it)

And yes, the alerts are what RFC 8446 already specifies, so if anything
a short note to the tune of "All errors and inconsistencies MUST
be handled as described in RFC 8446." would be equivalent to what I 
proposed.



Best,

 Bas

On Wed, Oct 23, 2024 at 9:44 PM Tim Hollebeek 
 wrote:
Agree completely, the only thing that can go wrong with this 
draft is scope creep.


 


-Tim

 

From: Deirdre Connolly  
Sent: Wednesday, October 23, 2024 3:22 PM

To: Alicja Kario 
Cc: Bas Westerbaan ; 
 

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

 

I would rather have a separate I-D for anything beyond ML-DSA 
(and thanks, this is great!)


 


On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario  wrote:

On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote:

Let’s have an adoption call asap.
 
I made some minor suggestions

https://github.com/bwesterb/tls-mldsa/pull/3


good catch on the signature_algorithms_cert part!

and on that front, I wonder if we shouldn't also include SLH-DSA
codepoints as those may be used by the CA certs, even if the EE use 
ML-DSA...


or make it a separate I-D?


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

So far, I see only one open question: whether to set a non-zero 
context string.


Best,

 Bas









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

[Alicja Kario]

On Thursday, 24 October 2024 04:47:02 CEST, 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.


For TLS I'm of the opinion that hybrids are not necessary.
We might define hybrids later, if those gain traction, but pure have
their place.


-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%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0

So far, I see only one open question: whether to set a non-zero 
context string.


Best,

 Bas







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

[Bas Westerbaan]

On Thu, Oct 24, 2024 at 8:55 AM John Mattsson 
wrote:

> I have gotten the understanding, see e.g., [1-2], that the WebPKI might
> wait for FN-DSA or wait even longer for something like MAYO, UOC, HAWK, and
> SQISign.
>

>From a performance perspective MAYO looks really nice, but we'd be really
pushing our luck on its security given its age. We must have a plan B.
Using UOV for SCTs doesn't seem as risky, but that doesn't cut enough bytes.

I would like us to consider more drastic directions to solve the
post-quantum authentication problem, such as for instance
https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/

Best,

 Bas

>
___
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)]

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.

Standardizing ML-DSA only appears to be straightforward – we just need to 
assign some code words, and it “works”.  Perhaps not as efficiently as we would 
like, with the largish ML-DSA certificates, but (IMHO) I believe that the 
optimization efforts can be done independently of the actual signature 
algorithm.

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?

From: Eric Rescorla 
Sent: Wednesday, October 23, 2024 10:47 PM
To: John Mattsson 
Cc: Bas Westerbaan ;  

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

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 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
>
> So far, I see only one open question: whether to set a non-zero
> context string.
>
> Best,
>
>  Bas
>
>
>

--
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%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[John Mattsson]

Hi Scott, Ekr,

Good points. In the telecom industry, which is seen as critical infrastructure, 
we do not have time and we use TLS/DTLS/QUIC for a large number of interfaces. 
We already have governments and customers telling us that all public-key crypto 
should be quantum-resistant by 2030. I would like to see ML-DSA registration in 
some form asap. As scott says, this draft is very straightforward. Maybe the 
best thing is to make IANA registrations (Recommended = N) soon and then 
continue the discussion.

I agree that we should have hybrids and that we need more discussion regarding 
hybrids. That is more complex than hybrid key exchange.

I would like to see SLH-DSA in TLS, especially for use as conservative 
root-of-trust.

I have gotten the understanding, see e.g., [1-2], that the WebPKI might wait 
for FN-DSA or wait even longer for something like MAYO, UOC, HAWK, and SQISign. 
I like that there is a lot of discussion of PQC sizes, which are problematic. 
NIST's ramp-on triggers a lot of research on small PQC signatures. I hope that 
academic research on KEMs (or full DH replacements) with smaller sizes also 
continue.

[1] https://blog.cloudflare.com/pq-2024/
[2] https://dadrian.io/blog/posts/pqc-signatures-2024/

Cheers,
John

From: Scott Fluhrer (sfluhrer) 
Date: Thursday, 24 October 2024 at 05:15
To: Eric Rescorla , John Mattsson 
Cc: Bas Westerbaan , 
Subject: RE: [TLS] Re: ML-DSA in TLS
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.

Standardizing ML-DSA only appears to be straightforward – we just need to 
assign some code words, and it “works”.  Perhaps not as efficiently as we would 
like, with the largish ML-DSA certificates, but (IMHO) I believe that the 
optimization efforts can be done independently of the actual signature 
algorithm.

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?

From: Eric Rescorla 
Sent: Wednesday, October 23, 2024 10:47 PM
To: John Mattsson 
Cc: Bas Westerbaan ;  

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

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 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
>
> So far, I see only one open question: whether to set a non-zero
> context string.
>
> Best,
>
>  Bas
>
>
>

--
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%40

[TLS] Re: [IANA #1388286] expert review for draft-ietf-tls-svcb-ech (dns-svcb)

[Dave Lawrence]

David Dong via RT writes:
> As a designated expert for the Service Parameter Keys (SvcParamKeys)
> registry, can you review the proposed registration modification in
> draft-ietf-tls-svcb-ech-06 for us? Please note that Benjamin
> Schwartz is a co-author on this document.  

Yes, the request is reviewed and approved from my end.

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

[TLS] Re: ML-DSA in TLS

[Kris Kwiatkowski]

I support the adoption. I also think we will end up standardizing pure ML-DSA 
anyway.


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)?
+1. Composite signatures are also interesting, but since TLS already includes 
certificate negotiation, this option seems like a better way to reduce 
certificate size.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org