[TLS] I-D Action: draft-ietf-tls-cert-abridge-02.txt
Internet-Draft draft-ietf-tls-cert-abridge-02.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Abridged Compression for WebPKI Certificates Author: Dennis Jackson Name:draft-ietf-tls-cert-abridge-02.txt Pages: 21 Dates: 2024-09-16 Abstract: This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-cert-abridge-02.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-cert-abridge-02 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
Thanks for the additional details, Mark. So it sounds like these organizations are not only requiring that the remote party's certificate be issued by a public CA, but that it be a specific certificate. Couple of observations here: 1. This is clearly not business for the TLS WG. This WG doesn't do anything with how certificate trust is provisioned. UTA might be right, or just run through the DISPATCH process. 2. This seems like a terrible design. * It's basically HTTP certificate pinning [RFC7469], which is being aggressively deprecated by browsers for exactly the downtime reasons you mention. * The public CA isn't adding any value here, and as you note, they add to the downtime risk * Trying to automate this is pointless, because you'll just end up back at the same problem of establishing trust with the other side. If you had an automated "here's my new cert" protocol, well, how do you verify that the thing sending you the new cert is authorized to? In light of (2), I would be disinclined for the IETF to do any work on this particular flavor of the mTLS problem. On Fri, Sep 13, 2024 at 11:08 PM Mark Robinson wrote: > I want to thank everyone for your feedback. It's been super helpful. > > I think I should elaborate on what the problem is and how it can be fixed. > > I've worked with a lot of companies who want to use mTLS (as bas as the > name is) to increase security but don't know how to do it in a way that > won't reduce reliability. For example, many companies require a certificate > signed by a public CA and then *emailed* to them. They have the annual cert > expiry of a regular cert combined with a manual (and hackable process) that > basically guarantees downtime when someone goes on vacation. > > What I'd like to cover: > - How two orgs (that aren't CAs) can exchange keys > - How to rotate keys > - What parameters keys should be set, and how keys should be validated > - When and how keys should be updated > - All of this without manual steps or #$%#$%ing email. > > Setting up cross-validation of TLS should be a single line change for high > performing organizations and should never, ever, ever involve email certs > between customer service reps. > > Mark > > On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann > wrote: > >> Andrei Popov writes: >> >> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes >> >confusion where customers ask whether "mTLS" is a different protocol or a >> >specific TLS implementation? However, it can be argued that this >> unfortunate >> >term has already taken root. >> >> +1, Richard pretty much said everything I have concerns about but saved >> me a >> lot of typing. mTLS *is* TLS, there's no need to give it a special name >> for >> marketing(?) purposes. >> >> Having said that, I'd have no problems with a "TLS Profile for xxx", >> which is >> what it really seems to be. >> >> (And I'll add an obligatory comment that what (m)TLS does isn't mutual >> authentication, it's unidirectional authentication in both directions, but >> that boat has long since sailed. If you wanted to have actual mTLS it'd >> have >> to use PSK). >> >> Peter. >> ___ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
Public CAs not only add another risk, but public CAs shouldn't want to be issuing these anyway if they are not for use with the web PKI. I agree that it doesn't seem in scope for the IETF's work, but I'll admit that I'd love to see more advocacy for divorcing such configurations from the public web PKI... Mike On Mon, Sep 16, 2024 at 10:33 AM Richard Barnes wrote: > Thanks for the additional details, Mark. So it sounds like these > organizations are not only requiring that the remote party's certificate be > issued by a public CA, but that it be a specific certificate. > > Couple of observations here: > > 1. This is clearly not business for the TLS WG. This WG doesn't do > anything with how certificate trust is provisioned. UTA might be right, or > just run through the DISPATCH process. > > 2. This seems like a terrible design. > * It's basically HTTP certificate pinning [RFC7469], which is being > aggressively deprecated by browsers for exactly the downtime reasons you > mention. > * The public CA isn't adding any value here, and as you note, they add > to the downtime risk > * Trying to automate this is pointless, because you'll just end up > back at the same problem of establishing trust with the other side. If you > had an automated "here's my new cert" protocol, well, how do you verify > that the thing sending you the new cert is authorized to? > > In light of (2), I would be disinclined for the IETF to do any work on > this particular flavor of the mTLS problem. > > > On Fri, Sep 13, 2024 at 11:08 PM Mark Robinson > wrote: > >> I want to thank everyone for your feedback. It's been super helpful. >> >> I think I should elaborate on what the problem is and how it can be fixed. >> >> I've worked with a lot of companies who want to use mTLS (as bas as the >> name is) to increase security but don't know how to do it in a way that >> won't reduce reliability. For example, many companies require a certificate >> signed by a public CA and then *emailed* to them. They have the annual cert >> expiry of a regular cert combined with a manual (and hackable process) that >> basically guarantees downtime when someone goes on vacation. >> >> What I'd like to cover: >> - How two orgs (that aren't CAs) can exchange keys >> - How to rotate keys >> - What parameters keys should be set, and how keys should be validated >> - When and how keys should be updated >> - All of this without manual steps or #$%#$%ing email. >> >> Setting up cross-validation of TLS should be a single line change for >> high performing organizations and should never, ever, ever involve email >> certs between customer service reps. >> >> Mark >> >> On Wed, Sep 11, 2024 at 4:30 PM Peter Gutmann >> wrote: >> >>> Andrei Popov writes: >>> >>> >I'm with Richard on this one. Not a fan of the "mTLS" concept: it causes >>> >confusion where customers ask whether "mTLS" is a different protocol or >>> a >>> >specific TLS implementation? However, it can be argued that this >>> unfortunate >>> >term has already taken root. >>> >>> +1, Richard pretty much said everything I have concerns about but saved >>> me a >>> lot of typing. mTLS *is* TLS, there's no need to give it a special name >>> for >>> marketing(?) purposes. >>> >>> Having said that, I'd have no problems with a "TLS Profile for xxx", >>> which is >>> what it really seems to be. >>> >>> (And I'll add an obligatory comment that what (m)TLS does isn't mutual >>> authentication, it's unidirectional authentication in both directions, >>> but >>> that boat has long since sailed. If you wanted to have actual mTLS it'd >>> have >>> to use PSK). >>> >>> Peter. >>> ___ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org >>> >> ___ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-rfc8446bis-11.txt
This version addresses all known issues. I will being work on the write-up, but I would expect it to be with our AD by next week. spt > On Sep 14, 2024, at 16:19, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-rfc8446bis-11.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: The Transport Layer Security (TLS) Protocol Version 1.3 > Author: Eric Rescorla > Name:draft-ietf-tls-rfc8446bis-11.txt > Pages: 160 > Dates: 2024-09-14 > > Abstract: > > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to communicate > over the Internet in a way that is designed to prevent eavesdropping, > tampering, and message forgery. > > This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes > RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies > new requirements for TLS 1.2 implementations. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-11.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8446bis-11 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] ECH status
ECH has been revised based on working group input and is ready to go to the IESG. You can see the diff between the latest (-22) and the one published previous to the last IETF (-18) here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-18&url2=draft-ietf-tls-esni-22&difftype=--html . There has been some discussion of ECH proxy on the list, but something similar has already been discussed as pointed out in the thread and there does not appear to be consensus to make this sort of change in this version. I plan to submit this early next week. Cheers, Joe ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: ECH status
I personally propose the community to reconsider the design of accept_confirmation. May be it sounds crazy, I advise to drop the requirements of the accept_confirmation. So that we can deploy the IETF without touching the backend server in the Split-Mode. And this will be a big promotion for the deployment of ETH, in the cost of the complication of client side. The client side must be modified to deploy the ETH. However, the server-side modifications is optional. Requiring modify the server-side will do harm for the deployment rate of ETH. Just FYI~ > On Sep 17, 2024, at 13:05, Joseph Salowey wrote: > > ECH has been revised based on working group input and is ready to go to the > IESG. You can see the diff between the latest (-22) and the one published > previous to the last IETF (-18) here: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-18&url2=draft-ietf-tls-esni-22&difftype=--html. > > There has been some discussion of ECH proxy on the list, but something > similar has already been discussed as pointed out in the thread and there > does not appear to be consensus to make this sort of change in this version. > > I plan to submit this early next week. > > Cheers, > > Joe > ___ > 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
