Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Tim Hollebeek]

I’m worried about the fact that this means a certificate that was issued for 
and intended to be used by a particular IP address is now potentially usable on 
any arbitrary IP address via this behavior.  Though I haven’t thought it all 
the through yet, it seems to me to be likely that there are use cases where 
this has at least mild unexpected security consequences.  Bonus points if you 
find a way this makes it easier to collect traffic intended for that IP from a 
different IP.

On .in-addr.arpa certificates, I’ve been trying to find out why there are web 
servers running on those domains since I was at my previous employer over five 
years ago, and have been periodically asking about them:

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html

If anyone knows why they exist, I’d love to know.

Also, if IP certificates are getting more common again, I’d love to hear about 
those use cases as they’re not on my radar at this time.  When I wrote the 
ballot for validation of IP addresses, it was a royal pain and took a few years 
because no one was actually interested in them.  My impression was that they 
were slowly going away with time, but I haven’t looked at the numbers recently.

-Tim

From: TLS  On Behalf Of Erik Nygren
Sent: Wednesday, July 27, 2022 4:59 PM
To: David Benjamin 
Cc: TLS@ietf.org
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other hacks.
It would have a higher implementation overhead, but also might be more likely 
to be deployable.

I checked search.censys.io and there appear to be 
around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a 
guarantee
that some of them will break with sending something new in an existing SNI 
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
I agree this is quite a compatibility risk. In addition to messing with SNI 
lookup, there are servers that try to correlate TLS SNI and HTTP Host. Indeed, 
when we accidentally sent IP literals in SNI, we broke a server that tried to 
do that but got very confused by the colons in an IPv6 literal. That server 
would likely also be confused by this draft, less by syntax and more by 
SNI/Host mismatch. I would be surprised if this option were viable.

Another option, which doesn't require redefining existing fields, is to simply 
allocate a new extension. Though I agree with Martin that one would expect the 
server to know its own IP. If you implicitly interpret a missing server_name 
extension as "I want the IP cert for this connection's IP", it's already 
unambiguous. Granted, there may be edge cases because missing server_name can 
also mean "I want the default cert" and perhaps your "default" cert and IP cert 
are different.

On Wed, Jul 27, 2022 at 12:17 PM Martin Thomson 
mailto:m...@lowentropy.net>> wrote:
Hi Erik,

As far as it goes, this might work.  However, I'm not sure about the effect of 
this on compatibility.  I'm concerned that maybe this would end up causing some 
servers to choke.  Servers that receive SNI can sometimes use that SNI value to 
lookup the correct certificate.  Your design could have those servers searching 
for a certificate that doesn't exist.

Anything along these lines would need to be tested for compatibility - 
extensively - before it could even be trialed.

(I never saw the DDR as having deployment problems along these lines.  It isn't 
THAT hard to know your own IP address for that purpose.)

On Wed, Jul 27, 2022, at 14:38, Erik Nygren wrote:
> Following discussions in ADD around the DDR draft (as well as in UTA
> around Martin Thomson's PR to add IP address SANs to 6125-bis),
> I wrote up a draft on how IP addresses might be represented in SNI:
>
>   https://datatracker.ietf.org/doc/draft-nygren-tls-ip-in-sni/
>
> There are at least three different ways we could do it, but this draft
> proposes what seems to be the least bad while also talking about the
> other alternatives.  (I suspect we'd want to move the alternatives
> to an appendix or remove entirely from a final version.)
>
> Is this interesting to the working group?
> While IP address SANs have a bunch of corner cases and gaps,
> they do seem to be picking up new uses.
>
> What motivated me to realize we need to solve this is that
> draft-ietf-add-ddr uses IP SANs in a new way.  Rather than the
> client connecting to an IP address and expecting to see a SAN
> (where returning a cert associated with the IP address containing
> a SAN that the client connected to is straight-forward),
> DDR has clients connecting to a different IP and then
> expects to find an original IP also in the SAN list.
> This means that for an ISP with a large

Re: [TLS] Representing IP addresses in SNI -- proposed draft

[Tim Hollebeek]

Thanks for the pointer to that draft, it’s very helpful.  The security 
considerations sections touches on my concerns a little bit, but probably needs 
more detail in this area.

Another thing that might help is some sort of extension or signal that 
indicates that the certificate is intended to be used in this manner.  
Otherwise we’re adding new and potentially surprising behavior to all the 
existing IP address certificates out there, whether they want it or not.  If 
the behavior is “opt-in” by all the participants that desire it, that would be 
safer.

Maybe that’s not necessary, still reading and thinking this through.  It’s an 
interesting use case.

-Tim

From: Erik Nygren 
Sent: Thursday, July 28, 2022 7:14 PM
To: Tim Hollebeek 
Cc: David Benjamin ; TLS@ietf.org
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

The use-case that may increase IP certificates is this from ADD's DDR:

https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-08#section-4.2

At a high-level, the client talks insecurely to their configured local DNS 
resolver with IP address "A"
and queries for "_dns.resolver.arpa."
That returns a SVCB record that points to another DNS resolver that may have 
hostname dot.example.com<http://dot.example.com>
with IP address "B".
As part of the "Verified Discovery" logic, the client connects to 
dot.example.com<http://dot.example.com> (IP address "B")
but then has to verify that the presented TLS certificate contains IP address 
"A".

If they share an IP address this is straight-forward (and a "normal" IP address 
cert).
But if A and B are different IPs then "dot.example.com<http://dot.example.com>" 
in this case may need
a separate IP address "B" (and hostname) for each IP address "A" that might be 
in-use
(with perhaps some efficiencies possible through SAN-packing).

Erik


On Thu, Jul 28, 2022 at 3:04 PM Tim Hollebeek 
mailto:tim.holleb...@digicert.com>> wrote:
I’m worried about the fact that this means a certificate that was issued for 
and intended to be used by a particular IP address is now potentially usable on 
any arbitrary IP address via this behavior.  Though I haven’t thought it all 
the through yet, it seems to me to be likely that there are use cases where 
this has at least mild unexpected security consequences.  Bonus points if you 
find a way this makes it easier to collect traffic intended for that IP from a 
different IP.

On .in-addr.arpa certificates, I’ve been trying to find out why there are web 
servers running on those domains since I was at my previous employer over five 
years ago, and have been periodically asking about them:

https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg11410.html

If anyone knows why they exist, I’d love to know.

Also, if IP certificates are getting more common again, I’d love to hear about 
those use cases as they’re not on my radar at this time.  When I wrote the 
ballot for validation of IP addresses, it was a royal pain and took a few years 
because no one was actually interested in them.  My impression was that they 
were slowly going away with time, but I haven’t looked at the numbers recently.

-Tim

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Erik 
Nygren
Sent: Wednesday, July 27, 2022 4:59 PM
To: David Benjamin mailto:david...@chromium.org>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: Re: [TLS] Representing IP addresses in SNI -- proposed draft

Both of these are very good concerns about the compatibility risk.
I think David's alternative of having a new extension (eg, server_name_ip)
might address a bunch of the issues and be cleaner than any of the other hacks.
It would have a higher implementation overhead, but also might be more likely 
to be deployable.

I checked search.censys.io<http://search.censys.io> and there appear to be 
around 150M certificates
with IP addresses in them that it is aware of, and that is pretty much a 
guarantee
that some of them will break with sending something new in an existing SNI 
extension...

Erik


On Wed, Jul 27, 2022 at 4:16 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
I agree this is quite a compatibility risk. In addition to messing with SNI 
lookup, there are servers that try to correlate TLS SNI and HTTP Host. Indeed, 
when we accidentally sent IP literals in SNI, we broke a server that tried to 
do that but got very confused by the colons in an IPv6 literal. That server 
would likely also be confused by this draft, less by syntax and more by 
SNI/Host mismatch. I would be surprised if this option were viable.

Another option, which doesn't require redefining existing fields, is to simply 
allocate a new extension. Though I agree with Martin that one would expect the 
server to know its own IP. If you implicitly interpret a missing server

Re: [TLS] OCSP and browsers

[Tim Hollebeek]

Also, the amount of work necessary to make Certificate Transparency work with 
three day certificates is probably not worth the effort.

It's not that you can't do it ... the easiest way is to break the 1-1 
correspondence between SCTs and certificates, and make allowances for issuing a 
series of certificates that are identical except for serial numbers and dates, 
and can all reasonably share the same CT entry.  But that's a non-trivial 
redesign.

Blowing up CT logs by a factor of 100 is also possible but less desirable.

I was a huge fan of the extremely short-lived cert idea, but I think it's time 
may have passed.  The compressed CRL stuff that browsers are already 
contemplating and deploying is a better path forward.

-Tim

From: TLS  On Behalf Of Salz, Rich
Sent: Sunday, October 2, 2022 9:14 AM
To: Phillip Hallam-Baker 
Cc: tls@ietf.org
Subject: Re: [TLS] OCSP and browsers


> Now we have ACME, why not move to 3 day certs issued daily and avoid the need 
> for revocation entirely?



Not all CA's in use on the WebPKI support ACME.  Automating a single-host to 
renew every 48 hours (have to allow for faults and retries) is okay, as long as 
you are confident your site will not be done during the "get new cert" window.  
As you scale up to millions of sites and/or thousands of locations, it's much 
less simple.



But I'm still looking for an answer about what browsers and OCSP see as their 
future.


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

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

[Tim Hollebeek]

It largely isn't necessary.  I like proof of possession for issuance, but 
mostly just to avoid nuisances.  But this topic is widely misunderstood.  I 
think if you took a poll of PKI professionals, you'd find that lots of them 
erroneously believe that issuance of a certificate certifies that the 
subscriber has the corresponding private key.  It doesn't (in most ecosystems). 
 It just means the subscriber has asked for that particular public key to be 
associated with their identity.

It's not uncommon for security researchers to grab a prominent public key, for 
example, a public WebPKI root, get a certificate issued to themselves for it, 
and claim to have found a security hole, when the proper response is: "You 
don't have the private key.  What do you think you are able to do with that?"  
This comes up semi-regularly on mozilla.dev.security-policy.

So I like proof of possession just to avoid those sorts of nuisance scenarios.  
If you can do it (e.g. in an automated issuance protocol), I think you should.

But I also like not being forced to do proof of possession, because there are 
scenarios where being forced to do it makes things worse.  They tend to involve 
things like offline systems where it's easier to securely get a bare public key 
across an air gap than it is to attempt to sign and transport a CSR.  There are 
probably others.

There's also the problem that there's no standard for secure proof of 
possession for revocation, despite a number of us calling for one for years.  
This means losing control of your CSR can be dangerous as some Certification 
Authorities will accept them as proof of possession for revocation purposes.

-Tim

From: Spasm  On Behalf Of Mike Ounsworth
Sent: Thursday, October 6, 2022 10:05 PM
To: Peter Gutmann ; von Oheimb, David 
; John Gray ; 
tomas.gustavs...@keyfactor.com
Cc: sp...@ietf.org; morgan...@dataio.com; tls@ietf.org
Subject: Re: [lamps] [TLS] [EXTERNAL] Re: Q: Creating CSR for encryption-only 
cert?

Hi Peter,

We grappled with that same question in our recent work on non-interactive KEM 
PoPs, and I have to admit, came up emptier than we expected.

See appendix A of:

https://eprint.iacr.org/2022/703

---
Mike Ounsworth

From: Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>
Sent: Thursday, October 6, 2022 8:51:17 PM
To: von Oheimb, David 
mailto:david.von.ohe...@siemens.com>>; John Gray 
mailto:john.g...@entrust.com>>; Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>; 
tomas.gustavs...@keyfactor.com 
mailto:tomas.gustavs...@keyfactor.com>>
Cc: sp...@ietf.org 
mailto:sp...@ietf.org>>; 
morgan...@dataio.com 
mailto:morgan...@dataio.com>>; 
tls@ietf.org mailto:tls@ietf.org>>
Subject: Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only 
cert?

A general question, motivated by "I need a different hammer because the one
I'm currently using isn't able to pound screws in properly": Why is PoP
actually required?  And by this I don't mean "why is it in theory a good
thing", I mean what actual attack that's been actively exploited in the real
world will use of PoP prevent?  We've been shipping raw PKCS #10's around for
decades (with no PoP) without causing the collapse of civilisation.

Peter.
Any email and files/attachments transmitted with it are confidential and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If this message has been sent to you in error, you must not copy, 
distribute or disclose of the information it contains. Please notify Entrust 
immediately and delete the message from your system.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

[Tim Hollebeek]

> > I mean what actual attack that's been actively exploited in the real world 
> > will use of PoP prevent?
> > We've been shipping raw PKCS #10's around for decades (with no PoP) without 
> > causing the collapse of civilisation.
> 
> Peter, just wanted to point out that this is one of the most humorous things
> I've read in a while.   I should make a poster or t-shirt out of this 
> statement
> (as we watch civilization collapse around us for other reasons)   😊

If it doesn't include a picture of raw PKCS #10 on top of sushi rice, I won't 
buy it.

-Tim

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

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

[Tim Hollebeek]

I think he is.

In order to pull off your attack, you need to convince a CA that you have their 
identity, so you can bind an arbitrary public key to it, then publish it.

But if you can attach an arbitrary public key to someone else's identity, 
you're going to use that for MITM and not the DoS you described.  Which is far 
worse.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Blumenthal, Uri - 0553 -
> MITLL
> Sent: Friday, October 7, 2022 3:04 PM
> To: tls@ietf.org
> Subject: Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-
> only cert?
> 
> Victor,  actually, I take it back - you may be right in that last point. Need 
> to
> think.
> 
> Regards,
> Uri
> 
> > On Oct 7, 2022, at 14:59, Blumenthal, Uri - 0553 - MITLL 
> wrote:
> >
> > 
> >>> On Oct 7, 2022, at 14:42, Viktor Dukhovni 
> wrote:
> >>>
> >>> On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL
> wrote:
> >>>
> >>> Then publish the certificate. Then the victim is unable to read
> >>> email encrypted to her. A DoS that costs the attacker very little,
> >>> practically nothing.
> >>
> >> What victim is that?
> >
> > Person or organization, whose credentials and email address were in the
> bogus/modified CSR.
> >
> >> All the PoP does is make it harder to convince your CA to attest that
> >> someone else's key is yours.  It plays no role in the most critical
> >> role of your CA, which is to not attest that your key is someone else's.
> >
> > Concur with both points above.
> >
> >> The scenario you suggest seems to me to require the latter.
> >
> > I don’t think so.
> >
> >
> >
> >>   Viktor.
> >>
> >> ___
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposal to make TLS universal

[Tim Hollebeek]

I wish people would stop citing the Cloudflare example as if something 
nefarious is going on there.  It is absolutely, 100% false that the identity in 
a certificate should identify who Cloudflare is getting the certificate on 
behalf of.  Cloudflare requests the certificates, holds the keys, and operates 
the servers.  It is the correct entity to identify as the certificate subject.

Modern web architectures are complicated, and there are other organizations 
participating in other roles.  It would be possible to name those as well, but 
you'd have to define the roles, what they mean, how to validate them, and how 
to put them into certificates.  If people want to make proposals in that area, 
they certainly can.  But Cloudflare isn't doing anything wrong here.

-Tim

From: TLS  On Behalf Of Yannick LaRue
Sent: Tuesday, March 28, 2023 12:29 AM
To: tls@ietf.org
Subject: [TLS] Proposal to make TLS universal

Dear TLS Working Group,

Thank you for your response to our previous message from Eric Rescorla. We 
appreciate your clarification on the use of ECDH ephemeral for encrypting the 
exchange of certificates in the TLS 1.3 handshake.

Based on this information, we have a new proposal to make TLS universal and 
promote the use of encryption across the internet. Our idea is to use ECDH 
ephemeral to create secure connections for sites that do not have certificates. 
This will provide a low level of security for these sites, but still better 
than the current situation where plaintext HTTP is used for these sites. 
Furthermore, using a certificate for a site should provide a medium level of 
security, which is already the case. Finally, mutual authentication should 
provide a high level of security. We believe this approach would be in line 
with the spirit of the Browser Forum, which seeks to promote universal 
encryption on the internet.

Furthermore, our proposal to use ECDHE for securing connections without a 
certificate provides the same level of assurance as the use of low-assurance 
certificates, such as those issued by Let's Encrypt or Cloudflare, which do not 
guarantee the identity of the server and its owners. In fact, many certificates 
simply guarantee that the site is hosted by a particular provider, such as the 
certificate used any site on Cloudflare, which lists Cloudflare, Inc. as the 
organization. Our proposal offers a more universal approach to encryption that 
doesn't rely on specific certificate authorities or their levels of assurance, 
and it would bring the benefits of encryption to all sites, regardless of their 
level of technical sophistication or resources.

Additionally, it is worth noting that many websites currently use low-assurance 
certificates simply to meet TLS requirements and enable encryption on their 
channels. This practice goes against the original philosophy of TLS, which was 
designed to provide strong assurance of server identity. Therefore, our 
proposal to include a low-assurance level using ephemeral ECDH in TLS would not 
only make the protocol universal but also help mitigate this problem. This 
reinforces the idea of including a method within TLS for users to securely 
utilize the protocol without having to resort to workarounds.

We believe that by making encryption available to all sites, we can promote 
greater security on the internet. This proposal will also help users understand 
the level of security provided by their connections and will encourage them to 
demand stronger security where it is necessary.

Thank you for your consideration, and we look forward to your response.

Best regards,

Yannick LaRue
SSE Carte à Puce Inc.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Abridged Certificate Compression (server participation)

[Tim Hollebeek]

Honestly, people can blame all sorts of things for the OCSP stapling problems,
but there was nothing inherently wrong with the approach.  The implementations
were just pretty poor due to issues Hubert Kario correctly outlined.  In 
general,
the needs of server operators and maintainers of server software and the
challenges they face are not always taken into account as well as they should 
be.

I think the best way to avoid those problems in this case would be to get up 
front
buy-in from one or two major server software implementors, to make sure they
agree with the approach and would be willing to implement it.

I'm also very happy with the recent efforts in the ecosystem to increase 
transparency around all the existing intermediate CAs, and the fact that this 
enables this sort of technology going forward.  There are a bunch of 
interesting 
points in this thread that I look forward to thinking more about and discussing 
in a few weeks.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:01 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (server participation)
> 
> Imo, the dictionary approach a simple way of trimming down the PQ auth
> data. And your argument for the frequency of synching OCSP staples vs these
> certs is a good one. I hope TLS termination points will agree if this moves
> forward, but personally I don't find the approach too bad.
> 
> -Original Message-
> From: TLS  On Behalf Of Dennis Jackson
> Sent: Wednesday, July 12, 2023 1:16 PM
> To: Kampanakis, Panos ; TLS List
> 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (server
> participation)
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
> 
> 
> 
> On 12/07/2023 05:02, Kampanakis, Panos wrote:
> 
> > The abridged certs draft requires a server who participates and fetches
> dictionaries in order to make client connections faster. As Bas has pointed 
> out
> before, this paradigm did not work well with OSCP staples in the past. Servers
> did not chose to actively participate and go fetch them.
> >
> > Are we confident that servers would deploy the dictionary fetching
> mechanism to benefit their connecting clients?
> 
> I think OCSP staples is quite a bit different from this draft. OCSP Staples
> requires the server to fetch new data from the CA every day or week. It's
> inherently hard to do this reliably, especially with the large number of poor
> quality or poorly maintained OCSP servers and the large fraction of operators
> who do not want their servers making outbound connections. Besides these
> barriers I don't think the benefit was huge as clients already cached OCSP
> responses for up to a week so at most it was speeding up one connection per
> client per week (this was before network partitioning in browsers) and at
> worst it was breaking your website entirely.
> 
> In contrast, this draft aims to speed up every connection that isn't using
> session tickets, cause no harm if its misconfigured or out of date and be slow
> moving enough that the dictionaries can be shipped as part of a regular
> software release and so suitable for anyone willing to update their server
> software once a year (or less). Similarly, these updates aren't going to 
> involve
> code changes, just changes to the static dictionaries, so they are suitable 
> for
> backporting or ESR releases.
> 
> It would definitely be good to hear from maintainers or smaller operators if
> they have concerns though!
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Abridged Certificate Compression

[Tim Hollebeek]

SCTs have always seemed surprisingly large to me, and it has always seemed
like there should be a more compact representation that has the same security
properties, but I've never found the time to look more closely at it.  If 
someone
does have the time, figuring out how to reduce the size of SCTs would be quite 
helpful.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 2:23 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression
> 
> > The performance benefit isn't purely in the ~1KB saved, its whether it 
> > brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
> 
> Fair. I would add one more tradeoff which is pulling the end-entity certs in 
> the
> CT window for pass 2. This is an one time cost for each dictionary version, so
> maybe not that bad.
> 
> Regardless, would compressing the leaf bring us below the QUIC 3.6KB
> threshold for Dilithium 2 or 3 certs whereas not suppressing would keep us
> above? I think it is not even close if we are talking WebPKI. Without SCTs,
> maybe compressing could keep us below 4KB for Dilithium 2 leaf certs. But
> even then, if we add the CertVerify signature size we will be well over 4KB.
> 
> Additionally, would compressing the leaf bring us below the 9-10KB threshold
> that Bas had tested to be an important inflection point? For WebPKI, it may
> the 8-9KB cert below 9KB if we add the CertVerify signature size. Maybe not. 
> It
> would need to tested. For Dilithium 3, maybe compression could render the
> 11-12KB cert below 9KB if we got lucky, maybe not, but if we add the
> CertVerify signature we won’t make it. For non-WebPKI, they will already be
> below 9-10KB.
> 
> So, I am arguing that we can't remain below the QUIC threshold by
> compressing the leaf Dilithium cert. And we could remain below the 9-10KB
> only for Dilithium2 leaves.  I could be proven wrong if you have implemented
> it.
> 
> One more argument for making pass 2 optional or allowing for just pass 1
> dictionaries is that if we are not talking about WebPKI we don't have the
> luxury of CT logs. But we would still want to option of compressing / omitting
> the ICAs by using CCADB.
> 
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 12:39 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
> 
> 
> 
> On 12/07/2023 04:34, Kampanakis, Panos wrote:
> 
> > Thanks Dennis. Your answers make sense.
> >
> > Digging a little deeper on the benefit of compressing (a la Abridged
> > Certs draft) the leaf cert or not. Definitely this draft improves vs
> > plain certificate compression, but I am trying to see if it is worth
> > the complexity of pass 2. So, section 4 shows a 2.5KB improvement over
> > plain compression which would be even more significant for Dilithium
> > certs, but I am trying to find if the diff between ICA
> > suppression/Compression vs ICA suppression/Compression+leaf
> > compression is significant. [/n]
> >
> > I am arguing that the table 4 numbers would be much different when
> > talking about Dilithium certs because all of these numbers would be
> > inflated and any compression would have a small impact. Replacing a CA
> > cert (no SCTs) with a dictionary index would save us ~4KB (Dilithium2)
> > or 5.5KB (Dilithium3). That is significant. [/n]
> >
> > Compressing the leaf (of size 8-9KB (Dilithium2) or 11-12 KB (Dilithium 3))
> using any mechanism would trim down ~0.5-1KB compared to not
> compressing. That is because the PK and Sig can't be compressed and these
> account for most of the PQ leaf cert size. So, I am trying to see if pass 2 
> and
> compression of the leaf cert benefit us much.
> 
> I think there's a fairly big difference between suppressing CA certs in SCA 
> and
> compressing CA certs with pass 1 of this draft. But I do agree its fair to 
> ask if
> pass 2 is worth the extra effort.
> 
> The performance benefit isn't purely in the ~1KB saved, its whether it brings
> the chain under the QUIC amplification limit or shaves off an additional 
> packet
> and so avoids a loss+retry. There's essentially no difference in 
> implementation
> complexity, literally just a line of code, so the main tradeoff is the 
> required disk
> space on the client & server.
> 
> Best,
> Dennis
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list

Re: [TLS] Abridged Certificate Compression (dictionary versioning)

[Tim Hollebeek]

I wish root programs accepted roots from new CAs at a speed where a one year
old dictionary would be a problem.  Cross-certificates are already generally 
required 
for several years, on average.  However, cross-certificates are not ideal, as 
they increase 
server configuration problems and chain length, which as we've been discussing 
sometimes has performance impacts.

It's something I wish the industry would fix, and I'm glad that improvements in 
this 
area are getting discussed again at CABF.

But yes, we should be careful that we do not introduce a new mechanism that
would potentially add a new bottleneck to root ubiquity, even if it isn't and 
won't
be the long pole today.  Because we don't want it to become the long pole in the
future as the ecosystem continues to improve.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Kampanakis, Panos
> Sent: Wednesday, July 12, 2023 9:31 PM
> To: Dennis Jackson ; TLS List
> 
> Subject: Re: [TLS] Abridged Certificate Compression (dictionary versioning)
> 
> I wish there was a study of the certs issued by newly introduced CAs in CCADB
> and how quickly they ramp up. I am concerned that a 1 year old dictionary
> could end up slowing down a good amount of destinations. But again, that
> slowdown does not mean an outage. And servers could ensure they get their
> certs issued or cross-issued by relatively mature CAs if they do not want PQ 
> Sig
> related slowdowns.
> 
> Btw, in 3.1.1 I noticed
> - "Remove all intermediate certificates which are not signed by root 
> certificates
> still in the listing."
> 
> That could eliminate some 2+ ICA cert chains. Any reason why?
> 
> 
> 
> -Original Message-
> From: Dennis Jackson 
> Sent: Wednesday, July 12, 2023 1:01 PM
> To: Kampanakis, Panos ; TLS List 
> Subject: RE: [EXTERNAL][TLS] Abridged Certificate Compression (dictionary
> versioning)
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
> 
> 
> 
> On 12/07/2023 04:54, Kampanakis, Panos wrote:
> 
> > Hi Dennis,
> >
> > Appendix B.1 talks about 100-200 new ICA and 10 Root certs per year. In
> the past I had looked at fluctuations of CCADB and there are daily changes.
> When checking in the past, I did not generate the ordered list as per pass 1 
> on
> a daily basis to confirm it, but I confirmed the fluctuations. The commits in
> https://github.com/FiloSottile/intermediates/commits/main  show it too.
> Given that, I am wondering if CCADB is not that stable. Are you confident that
> ICA dictionaries (based on CCADB) won't materially change often?
> 
> I checked the historical data for the last few years to ballpark a rate of 
> 100-200
> new intermediates per year. A uniform distribution of arrivals would mean 2 to
> 4 changes a week, which matches Filippo's commit frequency [1]. In practice
> Filippo's commits include removals (which we don't care about) and batched
> additions (which we do), but the numbers seem about right.
> 
> In terms of impact, the question is how much usage do those new ICAs see in
> their first year. If we expect websites to adopt them equally likely as 
> existing
> ICAs then they should make up <5% of the population. I think in practice they
> see much slower adoption and so the impact is even lower, for example a
> reasonable proportion are vanity certificates with limited applicability or
> intended to replace an existing cert in the future. If we wanted to confirm 
> this
> we could build the abridged cert dictionaries for '22 and then use CT to 
> sample
> the cert chains used by websites that year. I'll see if I can find the time 
> to put
> that together.
> 
> If there was an appetite for a faster moving dictionary, we could use the
> scheme I sketched in the appendix to the draft. But I think we should try to
> avoid that complexity if we can.
> 
> Best,
> Dennis
> 
> [1] https://github.com/FiloSottile/intermediates/graphs/commit-activity
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge

[Tim Hollebeek]

The WebPKI has a few features that enable this, which other PKIs really should
consider adopting.  It's one of the few fully transparent PKIs I'm currently 
aware of,
where all of the intermediate and root CAs, and most of the end entity 
certificates
are publicly known and available.

For those reasons, doing this for the WebPKI first and expanding outward from
there makes a lot of sense.

I support adoption as well.

-Tim

> -Original Message-
> From: TLS  On Behalf Of Stephen Farrell
> Sent: Tuesday, August 1, 2023 5:18 PM
> To: Christopher Wood ; TLS@ietf.org
> Subject: Re: [TLS] Adoption call for draft-jackson-tls-cert-abridge
> 
> 
> Hiya,
> 
> I saw the presentation and scanned the draft and support adoption on the
> basis that this could be useful before any certificates using PQC algorithms 
> are
> in play so the target of an experimental RFC is fine, even moreso as I could
> imagine details/codepoints changing over time as new better compressions
> are found.
> 
> I could see this also being a valuable input to work that aims to evolve PKI 
> in
> the face of a potential CRQC but I think it'd be premature to adopt on that
> basis alone as that overall topic needs broader consideration (best done IMO
> in a year or two and not now). In any case, I guess the CCADB doesn't and
> won't have entries using PQC algs for some time, and they might decide to
> handle things in some other way themselves so I'm not sure adopting this as a
> PQ scheme now actually makes sense.
> 
> IIUC it's also a bit of a pity that this'd be formally limited to the WebPKI, 
> being
> based on the CCADB. I guess handling the pretense that nobody uses
> letsencrypt for smtp/tls is probably better handled as part of another
> discussion elsewhere. (One worth having though.)
> 
> Cheers,
> S.
> 
> 
> On 01/08/2023 20:35, Christopher Wood wrote:
> > Hi all,
> >
> > Based on positive feedback received during IETF 117, this email begins an
> adoption call for "Abridged Compression for WebPKI Certificates" (draft-
> jackson-tls-cert-abridge).
> >
> > The datatracker page for this document can be found here:
> > https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> >
> > And the GitHub repository can be found here:
> > https://github.com/dennisjackson/draft-jackson-tls-cert-abridge
> >
> > Please indicate whether or not your support adoption of this document in its
> current state. Procedure questions raised during the WG meeting last week
> can be ironed out in the event of this item being adopted.
> >
> > This call for adoption will conclude on August 16.
> >
> > Thanks,
> > Chris, for the chairs
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version Notification for draft-ounsworth-lamps-pq-external-pubkeys-00.txt

[Tim Hollebeek]

When considering caching large public keys for TLS (or other protocols), please 
make sure the security considerations section carefully considers whether the 
proposed mechanism leaks information about whether the client has previously 
contacted the server and possibly how recently, etc.  

 

-Tim

 

From: TLS  On Behalf Of Kampanakis, Panos
Sent: Tuesday, October 10, 2023 9:48 PM
To: Mike Ounsworth ; tls@ietf.org
Subject: Re: [TLS] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Personally, I am against any practical use of McEliece given all the other 
available options. 1MB public keys are unnecessary, impact performance, and are 
wasteful.

 

Regardless of the public key in the cert though, RFC7924 allows (with other 
caveats) for not sending the server cert (and public key) if the client has 
prior knowledge of it. So, it solves the issue for TLS at least in one 
direction. 

 

Are there any other uses for this draft? For example, what use-cases would see 
a material difference by omitting 1-2KB of the Dilithium or Falcon public key 
when the rest of the cert will still amount to 2-3KB (4-7KB if we add in SCTs)? 

 

 

 

 

 

From: TLS mailto:tls-boun...@ietf.org> > On Behalf Of 
Mike Ounsworth
Sent: Saturday, September 30, 2023 6:19 PM
To: tls@ietf.org  
Subject: [TLS] FW: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Hi TLS WG!

 

This is both a new draft announcement, and a request for a short (5 min?) 
speaking slot at 118.

 

We want to socialize the idea of X.509 certificates with external public keys 
(ie the cert contains a link and hash of the public key that can be fetched or 
cached out-of-band.

 

The primary motivator of this LAMPS draft is Classic McEliece encryption certs, 
but we think this could also be valuable for TLS authentication certs. 

 

Consider the following two potential use-cases:

 

1. Browsers

Browsers already have mechanisms to cache intermediate CA certificates. It does 
not seem like a big leap to also cache external public keys for the server 
certs of frequently-visited websites. (yes, yes, I know that the idea of 
caching server public keys runs counter to the desire for the Internet to move 
to 14-day certs. Shrug)

 

2. Mutual-auth TLS within a cluster

Consider a collection of docker containers within a kubernetes cluster. 
Consider that each container has a local volume mount of a read-only database 
of the public keys of all containers in the cluster. Then 
container-to-container mutual-auth TLS sessions could use much smaller 
certificates that contain references to public key objects in the shared 
database, instead of the large PQ public keys themselves.

 

---

Mike Ounsworth

 

From: Spasm <  spasm-boun...@ietf.org> On Behalf 
Of Mike Ounsworth
Sent: Saturday, September 30, 2023 5:16 PM
To: 'LAMPS' <  sp...@ietf.org>
Cc: John Gray <  john.g...@entrust.com>; 
Markku-Juhani O. Saarinen <  m...@pqshield.com>; 
David Hook <  david.h...@keyfactor.com>
Subject: [lamps] FW: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

 

Hi LAMPS! This is both a new draft announcement, and a request for a short (5 
min?) speaking slot at 118. Actually, this is not a new draft. Back in 2021 
Markku and I put forward a draft for External Public Key -- 
draft-ounsworth-pq-external-pubkeys-00 

 

Hi LAMPS!

 

This is both a new draft announcement, and a request for a short (5 min?) 
speaking slot at 118.

 

Actually, this is not a new draft. Back in 2021 Markku and I put forward a 
draft for External Public Key -- draft-ounsworth-pq-external-pubkeys-00 (the 
only reason this is an -00 is because I included "lamps" in the draft name). 
The idea is that instead of a putting the full public key in a cert, you just 
put a hash and pointer to it:

 

   ExternalValue ::= SEQUENCE {

 location GeneralName,

 hashAlg  AlgorithmIdentifier,

 hashVal  BIT STRING

   }

   

That allows super small PQ certs in cases where you can pass the public key 
blob through some out-of-band mechanism.

 

Here's the mail list discussion from 2021:

 

 https://mailarchive.ietf.org/arch/msg/spasm/yv7mbMMtpSlJlir8H8_D2Hjr99g/

 

 

It turns out that BouncyCastle has implemented this at the request of one of 
their customers as a way around megabyte sized Classic McEliece certs; it is 
especially useful for usecases where clients have a way to fetch-and-cache or 
be pre-provisioned with its peer's public keys out-of-band. As such, Entrust 
and KeyFacto

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Tim Hollebeek]

So, I was talking to Mike Ounsworth about similar issues at the PQC hackathon.  
I would like us to agree on what a cocktail napkin description of the desired 
PQC end state for all the affected protocols looks like.  I think that would be 
very helpful, and this thread looks like it’s starting to explore what that 
would look like for TLS.

 

The reason is because I think the transition is going to be an order of 
magnitude harder than the end state, and it’s going to be TWO orders of 
magnitude harder if we don’t have at least rough agreement on what end state 
we’re trying to get to.  We tend to be working on the individual parts right 
now, without the bigger picture being nailed down, which is what we need to be 
doing right now, but we need to get past that pretty soon.

 

(1) and (2) are pretty standard crypto transition problems that we will argue 
about for quite some time, but fundamentally aren’t that hard and I think we’ll 
figure them out pretty easily.

 

(3)-(5) are exactly the hard problems I’ve been thinking a lot about lately.  
I’d actually be tempted to say that AuthKEM vs signatures is something we 
should figure out ASAP.  I read AuthKEM again this morning, and it has a lot of 
attractive features, but I’m not quite sure what the right answer is yet.

 

This stuff is hard.

 

-Tim

 

From: TLS  On Behalf Of Bas Westerbaan
Sent: Monday, November 6, 2023 12:37 PM
To: John Mattsson 
Cc: TLS@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

 

Thanks for bringing this up. There are a bunch of (implicit) questions in your 
e-mail.

 

1. Do we want rfc describing the final NIST standards? And for which? I'm ok 
with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.

 

2. For which algorithms do we want to assign codepoints once the NIST standards 
are out? Codepoints are cheap and use cases/rules are different, but especially 
with the hybrids, I'd encourage us to try to be disciplined and keep the list 
as short as we can for now, so that early adopters for which it doesn't matter, 
all choose the same thing. The DNS mechanism of 
draft-davidben-tls-key-share-prediction helps on the performance side, but it 
doesn't solve the duplicate engineering/validation if there are a dozen 
essentially equivalent KEMs.

 

3. Do we want to standardise non-hybrid KEMs for TLS? I don't care for them 
yet, but others might.

 

4. Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
could be convinced otherwise.

 

5. What is the future of AuthKEM? That's definitely a different e-mail thread.

 

Concretely, after ML-KEM is finished, I was planning to update 
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint for 
a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

 

Best,

 

 Bas

 

 

On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org> > wrote:

Hi,


NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
standards are expected in Q1 2024.

 

 https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography

 

I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
ML-DSA (all security levels standardized by NIST) as soon as possible after the 
final NIST standards are ready. 3GPP is relying almost exclusively on IETF RFCs 
for uses of public key cryptography (the exception is ECIES for IMSI encryption 
but that will likely use HPKE with ML-KEM in the future).

 

Looking at the TLS document list, it seems severely lacking when it comes to 
ML-KEM, ML-DSA…

 

The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with the 
pre-standard Kyber. 

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

AuthKEM is a quite big change to TLS

https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/

 

This is not adopted, informal, and dealing with the pre-standard Kyber.

https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/

 

What is the TLS WG plan for quantum-resistant algorithms? My current view is 
that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and X448 
are the only options that make sense. For hybrid signing, ECDSA, EdDSA, and RSA 
could all make sense.

 

Cheers,
John

 

From: TLS mailto:tls-boun...@ietf.org> > on behalf of 
internet-dra...@ietf.org   
mailto:internet-dra...@ietf.org> >
Date: Friday, 8 September 2023 at 02:48
To: i-d-annou...@ietf.org   
mailto:i-d-annou...@ietf.org> >
Cc: tls@ietf.org   mailto:tls@ietf.org> >
Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt

Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is a
work item of the Trans

Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

[Tim Hollebeek]

I’m fine if the cocktail napkin says “we’ll either do A or B, we’re still 
figuring that out”.

 

What I’m trying to avoid is the situation where everyone has a different 
notional quantum-safe TLS design in their heads, but nobody realizes it because 
nobody has bothered to try to write down the details, even at a very high level.

 

If it changes in the future due to new events or analysis, that’s ok too.

 

-Tim

 

From: Bas Westerbaan  
Sent: Monday, November 6, 2023 1:14 PM
To: Tim Hollebeek 
Cc: John Mattsson ; TLS@ietf.org
Subject: Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?

 

 

(3)-(5) are exactly the hard problems I’ve been thinking a lot about lately.  
I’d actually be tempted to say that AuthKEM vs signatures is something we 
should figure out ASAP.  I read AuthKEM again this morning, and it has a lot of 
attractive features, but I’m not quite sure what the right answer is yet.

 

I don't think we can settle the future of PQ authentication in TLS just yet — 
there are still many unknowns. To name a few:

 

1. What signature schemes are on the horizon? MAYO [1] from the NIST signatures 
on-ramp would be great, if it doesn't turn out to be broken.

 

2. How will the confidence in existing schemes develop? AuthKEM will look 
different depending on whether it can use Kyber-512 or Kyber-1024. Also, will 
it replace Dilithium5 or Dilithium2?

 

3. What other higher level changes is the ecosystem able to adopt? For instance 
Merkle Tree Certs [2].

 

These are all hard questions, and although I do not believe we can answer them 
now, we should be thinking about them right now. I think we should have 
different pots on the fire, so to say.

 

Best,

 

 Bas

 

[1] https://pqmayo.org/params-times/

[2] https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Tim Hollebeek]

I personally think this point is important enough to be made explicitly instead 
of implicitly.

 

If we want to communicate loudly and clearly that post-quantum cryptography is 
NEVER coming to TLS 1.2, we need to explicitly say that.

 

Otherwise people will say “I know you said TLS 1.2 was frozen, but post-quantum 
cryptography isn’t a feature, it’s a critical security vulnerability that needs 
to be patched regardless of any freezes.”

 

The answer will be and needs to be: “No, we told you clearly and explicitly 
that post-quantum cryptography would require moving to TLS 1.3 or later”.

 

-Tim

 

From: TLS  On Behalf Of Hannes Tschofenig
Sent: Monday, December 11, 2023 12:06 PM
To: Salz, Rich ; Hannes Tschofenig 
; Bas Westerbaan 
; Deirdre Connolly 

Cc: TLS@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

Hi Rich,

 

that is implied by a "feature freeze". No reason to highlight PQC (even though 
it is a hype topic right now).

 

Ciao

Hannes

 

Am 11.12.2023 um 17:18 schrieb Salz, Rich:

1.   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section

2.   The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto, and it 
*will not be a 1.2 enhancement*

 





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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Tim Hollebeek]

Most people in the positions you describe are not experts themselves, but rely 
on the recommendations and analysis of prominent industry groups because they 
know that that is likely to produce better answers than every IT practitioner 
trying to determine the answer themselves.

 

The best and brightest will say “what has the TLS working group at IETF said 
about this important topic?”  Which is why it is useful for us to provide high 
quality analysis and practical guidance about how we think any upcoming 
transition(s) and upgrade(s) will go.  And why it is important that we get it 
right …

 

-Tim

 

From: TLS  On Behalf Of Salz, Rich
Sent: Tuesday, January 2, 2024 10:06 AM
To: Blumenthal, Uri - 0553 - MITLL 
Cc: TLS@ietf.org
Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

 

My starting assumption here is that the majority of people implementing TLS 
and/or deciding what to authorize for deployment TLS-wise, are not stupid, and 
understand the benefits of the newer protocol version, including its added 
security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying 
with 1.2. 

 

That is a much nicer and broader brush than one I am willing to use to paint 
the IT industry.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Tim Hollebeek]

So, this has been discussed extensively at the CA/Browser forum, for obvious
reasons.

In my mind, it is not so important to identify and define and implement an
alternative hash.

What *is* important is that the protocol and associated software is able to
support a smooth transition period where people are moving from one
algorithm to another.

Ideally, you'd want certificates to be able to have two signatures during
the transition period, in order to support clients who have transitioned and
those who have not.  Unfortunately RFC 5280 is deficient in that regard.
Hosting multiple certificates and switching based on the client is feasible,
but requires some technical wizardry and isn't possible in all situations.

A lot of these transitions are painful because with the way things currently
work, algorithms have to reach near ubiquity before the transition can begin
(the popularity of Windows XP was a huge problem).

The transition will happen at different rates for various industries and use
cases that have different security requirements, so everyone needs to be
able to move at a pace that makes sense for their needs.  It needs to be
carefully coordinated, and yes, transitions will take years.  The current
maximum certificate lifetime is a compromise between the speed at which
changes can be made, and the pain imposed by replacement, which largely
still isn't automated.  I know people are working to improve that, but we
are where we are.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> Sent: Friday, December 15, 2017 11:50 AM
> To: Andrei Popov 
> Cc: tls@ietf.org
> Subject: Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS
> 
> On Fri, Dec 15, 2017 at 06:41:06PM +, Andrei Popov wrote:
> > It's true, the migration will be slow, but IMHO it still makes sense
> > to define and implement an alternative hash.
> 
> Agreed. However, on certificates front, we need a method to perform
> backward-compatible algorithm transition. Because non-backward-
> compatible ones are just too hard. As we have seen _twice_.
> 
> On TLS handshake hashes, the transitions are already backward- compatible.
> But that does not mean the transition will be easy.
> 
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in general, and what we can do in TLS

[Tim Hollebeek]

Because it's easier for the client to decide what the client understands
than it is for the server to decide what the client understands.  Less
complexity = less failures.  

Note that this is how XP was handled for code signing.  The Authenticode
spec actually made it so if you did things in the right order, XP would only
see the SHA-1 signature, while more recent operating systems would see both
the SHA-1 and SHA-2 signatures, ignore the SHA-1 signature, and use the
SHA-2 signature.  This allowed doubly-signed binaries that worked both on XP
and non-XP systems.  Unfortunately the technical steps to do so weren't
widely publicized, but I know some companies took advantage of it.

However, servers are easier to upgrade than clients, which is why you see
some of the server side support you mention.  I know CloudFlare in
particular helped a lot of people cope with communicating with clients who
had different certificate capabilities.  It isn't a bad thing that both
approaches exist.

-Tim

> -Original Message-
> From: Andrei Popov [mailto:andrei.po...@microsoft.com]
> Sent: Friday, December 15, 2017 12:25 PM
> To: Tim Hollebeek ; Ilari Liusvaara
> 
> Cc: tls@ietf.org
> Subject: RE: [TLS] A closer look at ROBOT, BB Attacks, timing attacks in
> general, and what we can do in TLS
> 
> > Ideally, you'd want certificates to be able to have two signatures
> > during the transition period, in order to support clients who have
> > transitioned and those who have not.
> 
> > Hosting multiple certificates and switching based on the client is
> > feasible, but requires some technical wizardry and isn't possible in all
> situations.
> 
> For my understanding, why is the former (double-signed certs, where either
> signature is trusted) better than the latter (multiple certs with
different
> algorithms)?
> The latter is currently supported by some TLS servers.
> 
> Cheers,
> 
> Andrei


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Additional TLS 1.3 results from Chrome

[Tim Hollebeek]

> I'm not sure I agree renumbering is the right reaction, though I don't 
> object to
> that. This could be a case where it's overall better that those specific 
> devices
> suffer breakage, and hopefully then do get firmware updated to support
> TLS1.3 or TLS-without-extended-random-or-dual-ec
> at some point.

It's never better to break large numbers of things, if it can be avoided at 
low
cost.  The reaction isn't going to be "TLS 1.3 broke my printer, it's time to
upgrade my firmware.", it's going to be "TLS 1.3 broke my printer, which was
working perfectly fine.  TLS 1.3 is bad.  I wonder what else they got wrong.
People shouldn't use TLS 1.3."

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Tim Hollebeek]

> The webpki is changing dramatically. The amount of CAB/forum violations
> seems to be increasing, partially as a result of these violations getting
> exposed
> by certificate transparancy and perhaps partially because of the financial
> strain
> caused by the free LetsEncrypt.

Uniformed speculations that are just flat out wrong do not help anyone.

LetsEncrypt, if anything, has been a big help to the CA industry.  Both free 
and paid offerings are seeing significant growth.  Let's not spread FUD about 
"financial strain" that does not actually exist.  And furthermore, it's best 
not suggest hypothetical unproved ("seems to be") observations are caused by 
the previously mentioned cause that doesn't actually exist.  That's 
irresponsible.

Tools like cablint have actually contributed far more to improvements in the 
technical compliance of certificates from vendors who previously didn't adhere 
that closely to strict compliance with RFCs, CABF requirements, required 
certificate profiles, and so on.  CT is less responsible, as it is only 
required for EV (though many large CAs have voluntarily started logging all 
certificates).  Many bad certificates were still found the old fashioned way: 
by crawling for them.

There's an old story about an intelligence analyst who found a handful of 
suspicious structures in a remote desert.  More resources were assigned to 
figure out what they were.

A few months later, the number of structures was observed to be increasing 
rapidly.  More resources were assigned.

Pretty soon, new ones were found every day.  People started panicking, and 
someone was dispatched to investigate on the ground.

It turned out to be a kind of water condenser common in the region, and the 
increase in numbers was only because people had started looking for them. 
They had always been there, just no one paid attention to them.

The truth is that the increase in activity around problems with various 
certificates is because people are just paying far more attention to even the 
smallest, most obscure details of every issued web PKI certificate these days: 
far, far more than they did even just two or three years ago.

And that's a good thing, not a bad thing.  Progress is being made.  The 
certificates being issued by almost every CA out there are much technically 
cleaner than they  were when I first started doing CA things, maybe five years 
ago.

The Symantec swamp cleanup effort is also responsible for a significant 
fraction (the majority?) of recent reports.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Tim Hollebeek]

I generally really like it.

 

My only comment is about the use of a zero byte as a separator in a string 
(4.2.2).

 

There are commonly used languages where this is likely to lead to 
implementation bugs, causing the signature to be computed over a shorter length 
than expected.

 

While I doubt this causes any problems other than failures and debugging pain, 
the first 64 bytes contain the octet 32; I don’t see any reason why byte 87 
can’t also be octet 32.

 

-Tim

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nick Sullivan
Sent: Thursday, May 3, 2018 4:16 PM
To: Sean Turner 
Cc: TLS WG 
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

 

Does anyone have any comments about the draft, criticisms, or votes of support?

 

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner mailto:s...@sn3rd.com> > wrote:



> On Apr 21, 2018, at 10:25, Sean Turner   > wrote:
> 
> 
>> On Apr 19, 2018, at 16:32, Sean Turner >  > wrote:
>> 
>> All,
>> 
>> This is the working group last call for the "Exported Authenticators in TLS" 
>> draft available at 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ 
>>  . 
>>  Please review the document and send your comments to the list by 2359 UTC 
>> on 4 April 2018.
> 
> … 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of James Cloos
> Sent: Wednesday, May 16, 2018 6:20 PM
> To: Ted Lemon 
> Cc:  
> Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
> 
> > "TL" == Ted Lemon  writes:
> 
> TL> Melinda made a pretty serious technical objection.  Your response is
not
> TL> responsive to her objection.   She explicitly said that her objection
was
> TL> not the two bytes.
> 
> I don't see anything in her note today which is a technical objection.
> 
> And I've seen no useful or reasonable objections to Viktor's suggestion.
> 
> The sixteen bit field harms no one, and when defined and used provides
> significant benefit to many.
> 
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

I’m actually fine with that.  You have to consider P_{extension implemented and 
used}.

 

Different people will disagree about the value of P.

 

-Tim

 

From: Paul Wouters [mailto:p...@nohats.ca] 
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek 
Cc: James Cloos ; Ted Lemon ; 
 
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

 

On May 17, 2018, at 19:44, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

 

The consequence of this opinion would be this:

 

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

 

Which is a lot of complexity for one TLS extension to define the behaviour of 
another TLS extension. And it still adds two bytes in the 2nd extension.

 

So if you believe more simplicity is better, then you made the wrong choice.

 

 

Paul



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Tim Hollebeek]

I think there’s room for two people in front of the steamroller.  And I have a 
towel.  How many votes does that get me?

 

-Tim

 

From: Melinda Shore [mailto:melinda.sh...@nomountain.net] 
Sent: Thursday, May 17, 2018 9:21 PM
To: Tim Hollebeek 
Cc: Paul Wouters ;  
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

And to be clear, it's not that nobody is going to implement the extension (it's 
already been done in an IETF hackathon and elsewhere), the work on the 
extension was funded by Mozilla, and there's been an outstanding request for 
this in Bugzilla.  What's not being implemented is the proposed changes.

 

But, it's clear that those guys don't intend to compromise and we're going to 
be deadlocked pretty much forever unless someone does something.  That's not 
going to be Viktor and it's not going to be the chairs, so I guess it's me.  

 

Melinda

 

On Thu, May 17, 2018, 16:20 Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

I’m actually fine with that.  You have to consider P_{extension implemented and 
used}.

 

Different people will disagree about the value of P.

 

-Tim

 

From: Paul Wouters [mailto:p...@nohats.ca <mailto:p...@nohats.ca> ] 
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >
Cc: James Cloos mailto:cl...@jhcloos.com> >; Ted Lemon 
mailto:mel...@fugue.com> >; mailto:tls@ietf.org> > mailto:tls@ietf.org> >
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

 

 

On May 17, 2018, at 19:44, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:

Making things more complicated with no obvious benefit just makes things
more complicated.

I oppose adding two bytes for some nebulous future purpose.

 

The consequence of this opinion would be this:

 

https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00

 

Which is a lot of complexity for one TLS extension to define the behaviour of 
another TLS extension. And it still adds two bytes in the 2nd extension.

 

So if you believe more simplicity is better, then you made the wrong choice.

 

 

Paul

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DNS-based Encrypted SNI

[Tim Hollebeek]

One of the things we found out with CAA is that this extremely optimistic view
of the support for unknown RR types by large hosting providers is not 
accurate.

-Tim

> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Monday, July 2, 2018 11:53 PM
> To: tls@ietf.org
> Subject: Re: [TLS] DNS-based Encrypted SNI
>
> On Mon, 2 Jul 2018, Eric Rescorla wrote:
>
> >   https://tools.ietf.org/html/draft-rescorla-tls-esni-00
>
> > This is at a pretty early stage, so comments, questions, defect
> > reports welcome.
>
>
>   This structure is placed in the RRData section of a TXT record as a
>   base64-encoded string.  If this encoding exceeds the 255 octet limit
>   of TXT strings, it must be split across multiple concatenated strings
>   as per Section 3.1.3 of [RFC4408].
>
> It is strongly recommended not to use TXT records. Why not use a new
> RRTYPE? Everything these days knows how to serve unknown record types (see
> RFC 3597). The only possibly exception is provisioning tools of small 
> players,
> but this document starts of saying you basically need to be on a bulk 
> hosting
> provider anyway. They can properly provision.
>
> I need to think more about the document to see if there is really not 
> something
> simpler or better possible.
>
> Paul
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

[Tim Hollebeek]

Unfortunately, I haven’t had time to review the document, but +1 for 
interesting problem, and +1 for anything Richard writes as a good starting 
point, even if I haven’t read it.

 

-Tim

 

From: TLS  On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: Richard Barnes 
Cc:  
Subject: Re: [TLS] Fwd: New Version Notification for 
draft-barnes-tls-pake-04.txt

 

+1 for this work.

 

If you are one of those that think, as I did 20 years ago, that password 
authentication is dying and practical replacements are just around the corner, 
do not support this document. Otherwise, please do. 

 

Asymmetric or augmented PAKE (aPAKE) protocols provide secure password 
authentication in the common client-server case (where the server stores a 
one-way mapping of the password) without relying on PKI - except during 
user/password registration. Passwords remain secure regardless of which 
middleboxes or endpoints spy into your decrypted TLS streams.  The server never 
sees the password, not even during password registration. 

 

To see real deployment of such protocols, they need to be integrated with TLS 
which is what Barnes's draft facilitates. Not only this improve significantly 
the protection of passwords and password authentication, but aPAKE protocols 
also provide an hedge against PKI failures by enabling mutual client-server 
authentication without relying on regular server certificates.

 

Hugo

 

 

On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes mailto:r...@ipv.sx> > wrote:

Hey TLS WG,

 

In response to some of the list discussion since the last IETF, Owen and I 
revised our TLS PAKE draft.  In the current version, instead of binding to a 
single PAKE (SPAKE2+), it defines a general container that can carry messages 
for any PAKE that has the right shape.  And we think that "right shape" covers 
several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, 

 

The chairs have graciously allotted us 5min on the agenda for Thursday, where 
I'd like to ask for the WG to adopt the document.  So please speak up if you 
think this is an interesting problem for the TLS WG to work on, and if you 
think the approach in this document is a good starting point.  Happy for 
comments here or at the microphone on Thursday!

 

Thanks,

--Richard

 

 

-- Forwarded message -
From: mailto:internet-dra...@ietf.org> >
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes mailto:r...@ipv.sx> >, Owen Friel 
mailto:ofr...@cisco.com> >




A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:   draft-barnes-tls-pake
Revision:   04
Title:  Usage of PAKE with TLS 1.3
Document date:  2018-07-16
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt
Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:   https://tools.ietf.org/html/draft-barnes-tls-pake-04
Htmlized:   https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff:   https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04

Abstract:
   The pre-shared key mechanism available in TLS 1.3 is not suitable for
   usage with low-entropy keys, such as passwords entered by users.
   This document describes an extension that enables the use of
   password-authenticated key exchange protocols with TLS 1.3.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
 .

The IETF Secretariat


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

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Tim Hollebeek]

I think this is a good summary.  I want to support this sort of effort, in part 
because it's very similar to some other ideas my boss and I were pushing about 
five years ago.  Something similar to this would solve, but also cause, lots of 
problems.  It's not clear whether the net result is better or worse.

But I find it difficult or impossible to evaluate for exactly the reasons 
Dennis mentions: there's no context explaining how it will be used, or any 
discussion of the impact on the many other things that would need to change for 
this draft to be useful.

We need to have open and honest discussions about how roots and root management 
will work going forward, if we want things to work differently in the future.

-Tim

> -Original Message-
> From: Dennis Jackson 
> Sent: Tuesday, July 23, 2024 9:51 PM
> To: TLS List 
> Subject: [TLS]Discussions on Trust Anchor Negotiation at IETF 120
> 
> There has been a lot of discussion over the past few days, both in person and
> on the mailing list. I want to share some thoughts on those discussions before
> the meeting tomorrow.
> 
> My impression is that there is little consensus on which problems we want to
> solve as a WG. Resolving this is critical for making progress.
> It is almost impossible to have sensible conversations about new drafts
> without agreeing on and understanding the problems we want to solve.
> 
> The vast majority of folks I've spoken with have said they're interested in
> solving the challenges around deploying fully PQ TLS, but don't feel that we
> are currently close to a shared understanding of those challenges or the
> tradeoffs around the drafts on the table today.
> 
> A smaller number of folks are interested in tackling other problems around
> root store management. I fear this aspect of the problem space is even less
> clearly understood and I heard very little agreement on what the key
> challenges are or how they might be addressed.
> 
> I hope tomorrow we can focus our discussion on figuring out as a WG the
> problem(s) that we want to tackle and where we differ in our understanding
> of those problems. I am sure that 20 minutes will not be enough time to
> resolve these complex issues, but I hope we can find a way to continue the
> conversation constructively.
> 
> Ahead of the meeting tomorrow, I want to highlight some of the questions
> which I think we need to find and agree on answers for:
> 
> - What are the problems that we solving?
> 
> - Who are we solving these problems for? Browsers or everyone?
> 
> - Are we proposing a hard requirement on this negotiation mechanism for
> anyone wanting to do fully PQ TLS?
> 
> - Can the proposed mechanism be enabled by default in TLS Libraries without
> requiring application changes?
> 
> - Can the proposed mechanism support use in a private PKI? How about in a
> private PKI that runs over the public Internet (in the now-classic zero-trust
> networking model)?
> 
> - What is the long-term vision for TLS and the WebPKI? Are we moving
> forward together or fragmenting?
> 
> - How do the proposed mechanisms affect TLS Client Hello fingerprinting or
> other tracking vectors?
> 
> - How would the proposed system work in practice? What happens when
> actors follow their own interests rather than the requirements of RFCs?
> 
> - Are less popular clients incentivized to lie in their Trust Expressions 
> about
> which root stores they have? The history of browser HTTP User Agent
> spoofing [1] highlights how minority clients are forced to spoof the signals 
> of
> other browsers to maximize site compatibility (even though it violates
> protocol requirements).
> 
> - How would versioning root programs work in practice when security
> requirements change? If the same root CAs are in version N and version
> N+1 of a root store and version N+1 adopts a stricter security policy -
> can these root CAs still issue certificates for version N?
> 
> - What are the consequences of making it easier to establish new root
> programs? For governments that have previously tried to build domestic
> root programs, would solve some of the problems they faced and encourage
> them to try again?
> 
> Ultimately, these are two complex drafts which propose substantial
> changes to TLS and the WebPKI. Besides evaluating the technical details
> in the draft themselves, we also have to tackle the nitty gritty
> operational questions about how a new system would work in practice—in
> particular, considering the incentives of the stakeholders to adopt the
> system and or to deliberately deviate from the intended protocol for
> self-benefit.
> 
> Finally, in any proposal which alters the power dynamics of a system,
> there will be difficult questions of a political nature, especially when
> the system in question is depended upon by billions of people.
> 
> Naturally, good people will often disagree on the nuances of these
> complex topics. However, we owe it to each other to communicate
> constructively, arr

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Tim Hollebeek]

I agree with this.

Also, the poll that was done at the TLS session is prone to being 
misunderstood.

There was a poll about a preference between the two drafts, but the question 
of
whether either of the drafts is necessary was skipped. I don't think it's fair 
to do
a presumptive close on that unaddressed question.

Someone asked on the chat, something along the lines of "does anyone other 
than
Chrome want this?"  So the question is out there and deserves an intelligent 
answer.

I happen to be one of the people who perhaps does want something like this, 
but
I want to have a full discussion on where we're going and why, instead of 
prematurely
focusing on any particular draft or solution before we know what problem(s) 
we're
trying to solve.

I realize Google has spilled a lot of electrons on these questions, and I 
think everyone
deserves an appropriate amount of time to digest and think through the complex 
issues
these drafts raise.

And I think and interim to focus on clarifying these important issues would be 
helpful.

-Tim

> -Original Message-
> From: Andrei Popov 
> Sent: Monday, July 29, 2024 1:49 PM
> To: Salz, Rich ; Dennis Jackson
> ; TLS List 
> Subject: [TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120
>
> I agree that an interim meeting would be useful. It seems unlikely that we 
> will
> make much progress on the mailing list alone.
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Salz, Rich 
> Sent: Monday, July 29, 2024 9:00 AM
> To: Dennis Jackson ; TLS List
> 
> Subject: [EXTERNAL] [TLS]Re: Discussions on Trust Anchor Negotiation at IETF
> 120
>
> >The Trust Anchor Identifiers draft was first published only 4 weeks
> >ago,  received less than 10 minutes of discussion in the meeting
>
> I strongly agree with this. Well, actually, everyone should be able to agree
> with this because it's two factual statements. :)
>
> I think the challenge of having an interim will be that one group will want 
> to
> discuss the details of the proposal, while another group will want to 
> discuss
> the details of the problem we are trying to solve. I hope the chairs will be 
> able
> to make things explicit and keep the discussions on-topic.
>
> If the authors share Sophie's opinion, they could withdraw the Trust
> Expressions draft and just leave Trust Anchors as something to be discussed.
>
>
> ___
> 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


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

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

[Tim Hollebeek]

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 mailto:hka...@redhat.com> > 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 mailto:hka...@redhat.com> >
> Date: Wednesday, 23 October 2024 at 19:59
> To: Bas Westerbaan   >
> 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: 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: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

[Tim Hollebeek]

+1 to choosing reasonable and consistent names that make sense, instead of 
being overly concerned with whether they exactly replicate the implementation.



-Tim



From: David Benjamin 
Sent: Thursday, October 17, 2024 11:33 AM
To:  
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02



While this whole situation is indeed ridiculous (there is obviously no 
security reason to use one or the other order and any certification systems 
that believe otherwise are clearly wrong and should be fixed), this draft with 
this order is now running code in several large deployments. I don't think 
it's worth the churn just to flip this back and forth now. Especially as key 
share prediction is not yet done and widely deployed.



I also agree that making the names inconsistent with each other will just 
confuse people, even if the internal orders are inconsistent.



On Thu, Oct 17, 2024, 08:19 Jan Schaumann 
mailto:40netmeister@dmarc.ietf.org> > wrote:

Bas Westerbaan mailto:40cloudflare@dmarc.ietf.org> > wrote:
> The number of people that actually implement these hybrid KEMs is much
> smaller than the number of people that need to make a choice based on their
> name. How do we explain that one is called MLKEM768X25519 and the other
> SecP256r1MLKEM768?

"In hybrid key exchanges, the name reflects the
order."

This strikes me as overall much less confusing all
around than

"One is called , the other is called
, because we wanted to have both end in
the same string."

People choosing will do a substring match ("I want
PQC, so... ok, here's one that contains 'MLKEM', let
me enable that.").

-Jan

___
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

[Tim Hollebeek]

Because there are other drafts for the other ideas.

 

Standardizing how to do ML-DSA in TLS in no way “favors” it or otherwise 
indicates any sort of exclusivity. There is nothing in the draft that precludes 
other approaches.

 

-Tim

 

From: Andrey Jivsov  
Sent: Friday, November 15, 2024 12:39 PM
To: John Mattsson 
Cc: Bas Westerbaan ; tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS

 

I am curious why this draft exclusively proposes ML-DSA, instead of adopting a 
composite signature approach as outlined in draft-ounsworth-pq-composite-sigs, 
at least as an option. For instance, id-MLDSA87-ECDSA-P384-SHA512 defined in 
the draft aligns with CNSA 2.0.

Could supporters of the draft elaborate on the rationale to favor or 
exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in 
another draft?

 

 

On Fri, Nov 15, 2024 at 9:13 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org> > wrote:

>I'm unenthusiastic but don't strongly oppose adoption of this and

>similar drafts, mostly because I think we should try get some WG

>consensus on guidance for when these things may be needed (if ever)

>and what the consequences might be should people deploy 'em in the

>meantime. (By 'em I mean anything with any kind of PQ sig or non

>hybrid PQ key exchange.) That guidance might or might not be in a

>separate document, or be copied into each relevant one.

 

More discussion would certainly be welcome. IPSECME is discussing what the 
right solution for hybrid PQC authentication is. The two proposals are 
composite public keys and signatures in a single certificate chain vs. two 
certificate chains. Both approaches have benefits and disadvantages. TLS should 
have the same discussion. Using two certificate chains is already possible in 
TLS with Post-Handshake Certificate-Based Client Authentication. Post-Handshake 
Certificate-Based Server Authentication should be added anyway as it is needed 
for long lasting TLS connections in infrastructure. 

WebPKI might want to wait but the many infrastructure use cases of TLS, DTLS, 
and QUIC need to migrate very soon. US government new requirement is that pure 
RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European countries have 
similar recommendations/requirements. Country to an earlier comment on the 
list, industry does not like new shiny tools, to the contrary, industry loves 
using existing stuff if possible.

https://csrc.nist.gov/pubs/ir/8547/ipd

https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf

>but don't strongly oppose adoption

Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and JOSE. Any 
further delay would likely end up in a lot of LSs from various infrastructure 
SDOs urging IETF to specify quantum-resistant authentication in TLS ;)

 

Cheers,

John

 

From: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie> >
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan mailto:40cloudflare@dmarc.ietf.org> >, tls@ietf.org   
mailto:tls@ietf.org> >
Subject: [TLS] Re: ML-DSA in TLS



On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
> 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00
>   
> &data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0

I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

Cheers,
S.

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



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: Working Group Last Call for TLS 1.2 is in Feature Freeze

[Tim Hollebeek]

One of the things we need to be honest with ourselves about is that telling 
people not to do it won’t prevent them from doing it.

 

So this decision is saying that WHEN people decide do PQC with TLS 1.2, they 
will be doing so without IETF guidance about how to do it. If this is the path 
we choose, we need to be ok with that.

 

I’m somewhat ok with that, but it does concern me and cause me to wonder if 
there’s something better we can do.

 

-Tim

 

From: Salz, Rich  
Sent: Tuesday, December 10, 2024 11:48 AM
To: Muhammad Usama Sardar ; Valery Smyslov 
; 'Sean Turner' ; 'TLS List' 

Subject: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

 

 

I would suggest "For TLS, it is important to note that PQC efforts are 
exclusively for TLS 1.3 or later." 

To me, the draft (even v3) is not clear on this point. At some point in future, 
PQ will become an urgent security issue, and the wording "outside of urgent 
security fixes" in the draft seems to imply that then we will start working on 
PQC for TLS 1.2. I suggest being explicit on this point. 

How about this:

For TLS it is important to note that the focus of these efforts is exclusively 
TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT 
be supported (see {{iana}}) at any time and anyone wishing to deploy 
post-quantum cryptography should expect to be using TLS 1.3.

 



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: Fwd: New Version Notification for draft-farrell-tls-pqg-00.txt

[Tim Hollebeek]

+1

 

From: Salz, Rich  
Sent: Sunday, December 15, 2024 12:56 PM
To: Tim Bray ; Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: Fwd: New Version Notification for 
draft-farrell-tls-pqg-00.txt

 

If that draft is useful, it probably belongs in the UTA working group, not TLS.

 

I would express the guidance this way: Use a hybrid that combines PQ and 
“classic” algorithms, so that if one is broken you’re still safe. If you are 
required to use only PQ, so be 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: ML-DSA in TLS

[Tim Hollebeek]

Yes, the thread on this draft got hijacked by a completely off-topic discussion 
about composite and hybrid.

 

To be clear, the draft says absolutely nothing about either of those two 
topics, and to be even more clear, does not at all imply in any way that pure 
ML-DSA is superior or is the only option. It just says that if you need ML-DSA 
for TLS, here’s how you do it.

 

People who want to discuss composite / hybrid, which by the way I personally am 
also in favor of and actually prefer for many use cases, should move those 
discussions to threads about the appropriate drafts. 

 

ML-DSA support for TLS is obvious and straightforward. We should explain and 
standardize the right way to do it, to prevent people from inventing a plethora 
of slightly different, non-standard implementations out of necessity because 
IETF failed to publish a straightforward draft in a timely manner.

 

Let’s get back on topic and get this done.

 

-Tim

 

From: Scott Fluhrer (sfluhrer)  
Sent: Thursday, November 21, 2024 8:55 AM
To: Andrey Jivsov ; Eric Rescorla 
Cc: tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS

 

Might I ask what are we arguing about?  Does the TLS working group feel the 
need to prohibit pure ML-DSA as authentication?  Even though, after Q-day 
happens (whenever that will be), that might be what people want?

 

If you go through the TLS ML-DSA draft, all they do is define three code points 
(for the three ML-DSA parameter sets), that’s it.  That sounds like a 
reasonable addition, even if it were to turn out to be useful only in a few 
networks with private CAs.

 

From: Andrey Jivsov mailto:cry...@brainhub.org> > 
Sent: Wednesday, November 20, 2024 3:36 PM
To: Eric Rescorla mailto:e...@rtfm.com> >
Cc: tls@ietf.org  
Subject: [TLS] Re: ML-DSA in TLS

 

Given that the series of Suite B RFCs were Informational, it stands to reason 
that a document of the type that e.g. prohibits hybrids because of internal 
policies of any organization, a viewpoint which is not strongly shared by IETF, 
should not be a standards-track document. For what I see, no-hybrids policy 
increases complexity in real-world systems that need to expose a hybrid and its 
components as a separate option, and this is especially difficult for systems 
that must have a single option acceptable to everyone.

 

TLS https://datatracker.ietf.org/doc/html/rfc5430

IPSec https://datatracker.ietf.org/doc/html/rfc6380

SMIME https://datatracker.ietf.org/doc/html/rfc6318

OpenPGP: there was pushback on Standards-track, and it only could get standards 
track after we made sure that Brinpool curves are supported 
https://www.rfc-editor.org/rfc/rfc6637.html 

 

(The difference in practice may not be significant, but I still think that 
Informational is correct)

 

On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla mailto:e...@rtfm.com> > wrote:

 

 

On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein mailto:d...@cr.yp.to> > wrote:

https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
 

 
includes the following note: "Even though hybrid solutions may be
allowed or required due to protocol standards, product availability, or
interoperability requirements, CNSA 2.0 algorithms will become mandatory
to select at the given date, and selecting CNSA 1.0 algorithms alone
will no longer be approved."

This looks 100% compatible with a TLS WG decision saying "PQ in TLS has
to be hybrid". 

 

Without addressing the question of what CNSA 2.0 requires, I don't think

the TLS WG making that decision is really on the table here. As a reminder,

the relevant TLS registry 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)

operates under an "Expert Review" policy with the standard being quite

low.

  Note:  The role of the designated expert is described in RFC 8447 
 .
  The designated expert [RFC8126  ] 
ensures that the specification is
  publicly available.  It is sufficient to have an Internet-Draft
  (that is posted and never published as an RFC) or a document from
  another standards body, industry consortium, university site, etc.
  The expert may provide more in-depth reviews, but their approval
  should not be taken as an endorsement of the supported group.

So, the question isn't so much whether a given algorithm can be used with

TLS but rather (1) whether the WG adopts it (2) whether it's standards track,

(3) whether we mark it Recommended and (4) whether it's mandatory to

implement. We certainly could mark ML-KEM Recommended=N (or

even D), but  the policy isn't to forbid code point registration

just because we don't have confidence in the algorithm; I don't think we should

ch

[TLS] Re: Changing WG Mail List Reputation

[Tim Hollebeek]

Consensus has nothing to do with number of votes. We don’t vote, and we 
shouldn’t. We also shouldn’t disadvantage those who can’t attend sessions live 
for whatever reason. The existing rules cover this pretty well, imo.

 

The reason we appoint technically competent chairs and directors, and those 
chairs and directors spend quite a bit of time on this stuff, is because it 
can’t be handled by arbitrary rules or just counting. And we have appeals 
procedures, too. If you ever have any questions about a particular consensus 
call or believe consensus is being declared when it hasn’t been achieved, 
please feel free to publicly or privately reach out to a chair or area director.

 

-Tim

 

From: Quynh Dang  
Sent: Wednesday, January 15, 2025 1:04 PM
To: Ted Lemon 
Cc: tls@ietf.org
Subject: [TLS] Re: Changing WG Mail List Reputation

 

 

 

On Wed, Jan 15, 2025 at 12:47 PM Ted Lemon mailto:mel...@fugue.com> > wrote:

Although it is, as ekr has pointed out, not normative, nevertheless RFC 7282 
provides a solid process for coming to rough consensus. This method does not 
involve voting, and I think operates in the way that DJB proposes. I certainly 
would not consider vote counting to be a valid way to determine consensus, 
because it doesn't inform the working group in any way—it's really just a count 
of how many bodies a particular proponent was able to throw at the problem.

 

As for what the minimum number of people involved should be, that's also really 
hard to state objectively because some working groups get vastly more 
participation than others: what works for one will not work for another.

 

I'm not suggesting that we make RFC 7282 normative; what I am suggesting is 
that it's a good basis for reasoning about this problem, and we do really 
already know how to solve this problem. Unfortunately it does require that WG 
leadership and IETF leadership actually put the effort in to accurately judge 
the consensus. 

 

How the chair "accurately judge the consensus." and to avoid the problem I 
mentioned in the previous email : "So consensus calls can be made based on 
inconsistent "policies" or "unknown rules/policies" and many people might feel 
that they are treated unfairly in many consensus calls and they could have a 
question in their head: why did the chairs do that to me ?" ? 

 

If we don't think the problem above is a problem, then we don't have to change 
anything.  But if we think that problem is a problem, then I don't see any 
better way to take care of it other than defining a minimum percentage of votes 
to have the consensus. 

 

Regards,

Quynh. 

 

 

 

If there really is no better reason to choose solution A as opposed to solution 
B as the number of votes, then the decision is effectively arbitrary anyway, 
and a coin flip would also work (and this has been done in the past in such 
situations).

 

 

On Wed, Jan 15, 2025 at 6:39 PM Quynh Dang mailto:quyn...@gmail.com> > wrote:

 

 

On Wed, Jan 15, 2025 at 11:40 AM D. J. Bernstein mailto:d...@cr.yp.to> > wrote:

Quynh Dang writes:
> D. J. Bernstein mailto:d...@cr.yp.to> > wrote:
> > Quynh Dang writes:
> > > Any result will hurt one group (can't be both groups have what they
> > > want).
> > BCP 54: "IETF participants use their best engineering judgment to find
> > the best solution for the whole Internet, not just the best solution for
> > any particular network, technology, vendor, or user."
> The key point in that policy is "the best solution for the whole Internet".
> So, in my example, one group thinks A is the one and the other group thinks
> B is the one.

That wouldn't be a case of some group not getting what it wants. It
would be everyone wanting what's best for the Internet, but not enough
analysis having been carried out yet to know what that is. The usual way
out of such cases is via a closer look at the engineering.

The "not just" part of the above BCP 54 quote is recognizing that
vendors have an incentive to push for what's best for those vendors.
That's a much more obvious reason for conflicts---and if one starts by
thinking of IETF as a way to manage conflicts of vendor interests then
votes might seem to be a natural way to make decisions. But the policy
is saying that IETF's goal is instead to do what's best from an
engineering perspective for the Internet as a whole.

 

As discussed previously, "what's best from an engineering perspective", is 
there the decision maker such as a judge to say A is the right one, not B or 
give a verdict such as this patent covers this, but not that ?  That is why the 
IETF requires "rough" consensus.  

 


Votes don't help the engineering process; they disrupt it. Voting is not
how IETF is supposed to work in the first place. As Dave Clark famously
said in https://www.ietf.org/proceedings/24.pdf: "We reject: kings,
presidents and voting. We believe in: rough consensus and running code."

 

I have not advocated against "rough consensus".  

 

The problem is that