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

[Dennis Jackson]

Hi Mike,

On 30/09/2023 23:19, Mike Ounsworth wrote:



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)


I think a bigger objection would be that caching the public keys is a 
tracking vector and seems a bit redundant if the browser and server can 
do session resumption instead (with less storage overhead).


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.


You could easily used abridged certs here, just with an enterprise 
specific dictionary rather than the external public keys. That would let 
you reduce the entire certificate chain to a few bytes, without having 
to implement any key fetching logic in the TLS client. Would you be 
interested in that? It would be easy enough to have a generic IETF draft 
for abridged certs schemes and then a particular draft defining the 
WebPKI instantiation. I think Panos may also be interested in a similar 
enterprise use case?


I'm a little confused on why caching the public key independently of the 
certificate is a good idea. It seems like a recipe for encouraging 
people to issue new certificates without rolling new public keys, which 
would not be great for security.


Best,
Dennis


---

*Mike*Ounsworth

*From:*Spasm  *On Behalf Of *Mike Ounsworth
*Sent:* Saturday, September 30, 2023 5:16 PM
*To:* 'LAMPS' 
*Cc:* John Gray ; Markku-Juhani O. Saarinen 
; David Hook 
*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 KeyFactor are reviving this draft.


We suspect this might also be of interest to the TLS WG, but I will 
start a separate thread on the TLS list.


---

*Mike*Ounsworth

*From:*internet-dra...@ietf.org 
*Sent:* Saturday, September 30, 2023 5:12 PM
*To:* D. Hook ; John Gray 
; Markku-Juhani O. Saarinen 
; John Gray ; Markku-Juhani 
Saarinen ; Mike Ounsworth 
*Subject:* [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt


A new version of Internet-Draft 
draft-ounsworth-lamps-pq-external-pubkeys-00. txt has been 
successfully submitted by Mike Ounsworth and posted to the IETF 
repository. Name: draft-ounsworth-lamps-pq-external-pubkeys Revision: 
00 Title: External


A new version of Internet-Draft
draft-ounsworth-lamps-pq-external-pubkeys-00.txt has been successfully
submitted by Mike Ounsworth and posted to the
IETF repository.
Name: draft-ounsworth-lamps-pq-external-pubkeys
Revision: 00
Title:    External Keys For Use In Internet X.509 Certificates
Date: 2023-09-30
Group:    Individual Submission
Pages:    9
URL: 
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ounsworth-lamps-pq-external-pub

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Rob Sayre]

On Tue, Oct 10, 2023 at 8:28 AM David Benjamin 
wrote:

> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> To make sure I've understood correctly, we're trying to solve three
>> problems:
>>
>>- Some servers don't tolerate large Client Hellos
>>- Some servers don't implement HelloRetryRequest correctly
>>- Some servers prefer fewer round trips and accept an offered key
>>share even if both client and server would prefer a different group (for
>>which no key share was sent). This is especially troubling if we have to
>>migrate between PQ KEMs since we can't afford multiple key shares in the
>>ClientHello.
>>
>>
> First and third, yeah. I was mostly focused on the third one, but yeah
> we'll also need this if the first can't be cleared. (I hope we can just
> clear through it though. Even if we solve the downgrade problem,
> compatibility hacks for the large ClientHello will be bad for the ecosystem
> and very hard to remove later. But if we need it, we need it.)
>

The impression I got in reading the various PQ experiment reports (and I
think David Benjamin did some of them...) was that the issues with large
Client Hellos *will* arise with PQ Client Hello messages. So... if a server
adds support for PQ, they will have to fix any underlying issues with large
Client Hello messages as a prerequisite, right? Can we cross the first
point off the list here? I'm a little confused about that point.

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

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

[Russ Housley]

Dennis:

If we are going to allow a certificate to include pointers to externally stored 
public keys, I think a solution that works for the Web PKI and other PKI 
environment as well.  I would not object to the use of abridged certs as an 
option, but I would object if it is the only option.

Russ


> On Oct 10, 2023, at 11:21 AM, Dennis Jackson 
>  wrote:
> 
> Hi Mike, 
> 
> On 30/09/2023 23:19, Mike Ounsworth wrote:
> 
>> 
>> 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)
> I think a bigger objection would be that caching the public keys is a 
> tracking vector and seems a bit redundant if the browser and server can do 
> session resumption instead (with less storage overhead).  
>>  
>> 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.
> You could easily used abridged certs here, just with an enterprise specific 
> dictionary rather than the external public keys. That would let you reduce 
> the entire certificate chain to a few bytes, without having to implement any 
> key fetching logic in the TLS client. Would you be interested in that? It 
> would be easy enough to have a generic IETF draft for abridged certs schemes 
> and then a particular draft defining the WebPKI instantiation. I think Panos 
> may also be interested in a similar enterprise use case? 
> 
> I'm a little confused on why caching the public key independently of the 
> certificate is a good idea. It seems like a recipe for encouraging people to 
> issue new certificates without rolling new public keys, which would not be 
> great for security. 
> 
> Best,
> Dennis
> 
>>  
>> ---
>> Mike Ounsworth
>>  
>> From: Spasm   On 
>> Behalf Of Mike Ounsworth
>> Sent: Saturday, September 30, 2023 5:16 PM
>> To: 'LAMPS'  
>> Cc: John Gray  ; 
>> Markku-Juhani O. Saarinen  ; 
>> David Hook  
>> 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 KeyFactor are reviving this draft.
>>  
>> We suspect this might also be of interest to the TLS WG, but I will start a 
>> separate thread on the TLS list.
>>  
>>  
>> ---
>> Mike Ounsworth
>>  
>> From: internet-dra...@ietf.org  
>> mailto:internet-dra...@ietf.org>> 
>> Sent: Saturday, September 30, 2023 5:12 PM
>> To: D. Hook mailto:david.h...@keyfactor.com>>; 
>> John Gray mailto:john

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[David Benjamin]

On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre  wrote:

> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin 
> wrote:
>
>> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote:
>>
>>> To make sure I've understood correctly, we're trying to solve three
>>> problems:
>>>
>>>- Some servers don't tolerate large Client Hellos
>>>- Some servers don't implement HelloRetryRequest correctly
>>>- Some servers prefer fewer round trips and accept an offered key
>>>share even if both client and server would prefer a different group (for
>>>which no key share was sent). This is especially troubling if we have to
>>>migrate between PQ KEMs since we can't afford multiple key shares in the
>>>ClientHello.
>>>
>>>
>> First and third, yeah. I was mostly focused on the third one, but yeah
>> we'll also need this if the first can't be cleared. (I hope we can just
>> clear through it though. Even if we solve the downgrade problem,
>> compatibility hacks for the large ClientHello will be bad for the ecosystem
>> and very hard to remove later. But if we need it, we need it.)
>>
>
> The impression I got in reading the various PQ experiment reports (and I
> think David Benjamin did some of them...) was that the issues with large
> Client Hellos *will* arise with PQ Client Hello messages. So... if a server
> adds support for PQ, they will have to fix any underlying issues with large
> Client Hello messages as a prerequisite, right? Can we cross the first
> point off the list here? I'm a little confused about that point.
>

No, issues with large ClientHellos cannot be crossed off so simply. Keep in
mind we cannot update the internet all at once. The client does not have a
priori knowledge that the server implements PQ, but it needs to construct a
ClientHello. It can choose to either:

a) Send a ClientHello with Kyber in key_shares
b) Send a ClientHello without Kyber in key_shares

If it picks (a), any *non-Kyber-supporting* servers that break with large
ClientHellos will break. If there are sufficiently few of these, we can
maybe clear through it, but it is a compatibility risk we need to deal
with. But the important thing is that we are precisely concerned with the
non-Kyber servers here. It's not as simple as saying you fix that when you
deploy Kyber.

If it picks (b), non-Kyber-supporting servers behave as before, buggy or
not. However, Kyber-supporting servers not only suffer a round-trip but
also may not even pick Kyber. For example, if you were to add Kyber to
OpenSSL today, it would pick X25519 when presented with (b). See
https://github.com/openssl/openssl/issues/22203. BoringSSL will behave
correctly, because we anticipated this issue when we first implemented TLS
1.3. I think NSS also knows about group preferences? But clearly the spec
wasn't clear enough here. Thus this draft exists to resolve this. *This* server
fix *can* be done as servers add Kyber support, but only if we remember to
tell them that.

Now, I'm hoping we can just make (a) work. Sending (b) also makes the
preferred option (Kyber) take a round-trip and more complex schemes like
fallbacks have a tendency to overstay their welcome. But different folks
will have different risk preferences and deployment strategies, so I think
it is worth making sure strategies involving (b) remain viable. And, of
course, there's still the third problem.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Rob Sayre]

On Tue, Oct 10, 2023 at 10:01 AM David Benjamin 
wrote:

> On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre  wrote:
>
>> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin 
>> wrote:
>>
>>> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson >> 40dennis-jackson...@dmarc.ietf.org> wrote:
>>>
 To make sure I've understood correctly, we're trying to solve three
 problems:

- Some servers don't tolerate large Client Hellos
- Some servers don't implement HelloRetryRequest correctly
- Some servers prefer fewer round trips and accept an offered key
share even if both client and server would prefer a different group (for
which no key share was sent). This is especially troubling if we have to
migrate between PQ KEMs since we can't afford multiple key shares in the
ClientHello.


>>> First and third, yeah. I was mostly focused on the third one, but yeah
>>> we'll also need this if the first can't be cleared. (I hope we can just
>>> clear through it though. Even if we solve the downgrade problem,
>>> compatibility hacks for the large ClientHello will be bad for the ecosystem
>>> and very hard to remove later. But if we need it, we need it.)
>>>
>>
>> The impression I got in reading the various PQ experiment reports (and I
>> think David Benjamin did some of them...) was that the issues with large
>> Client Hellos *will* arise with PQ Client Hello messages. So... if a server
>> adds support for PQ, they will have to fix any underlying issues with large
>> Client Hello messages as a prerequisite, right? Can we cross the first
>> point off the list here? I'm a little confused about that point.
>>
>
> No, issues with large ClientHellos cannot be crossed off so simply. Keep
> in mind we cannot update the internet all at once. The client does not have
> a priori knowledge that the server implements PQ, but it needs to construct
> a ClientHello. It can choose to either:
>
> a) Send a ClientHello with Kyber in key_shares
> b) Send a ClientHello without Kyber in key_shares
>
> If it picks (a), any *non-Kyber-supporting* servers that break with large
> ClientHellos will break. If there are sufficiently few of these, we can
> maybe clear through it, but it is a compatibility risk we need to deal
> with. But the important thing is that we are precisely concerned with the
> non-Kyber servers here. It's not as simple as saying you fix that when you
> deploy Kyber.
>

OK, I see. It's worse than a compatibility risk, though, isn't it? If you
just let them break in case (a), and then maybe try again with (b), that
opens up a downgrade attack. Intermediaries can observe the size of the
Client Hello and make it break.

I understand it now, thanks for taking the time to explain.

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

>
> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
> just let them break in case (a), and then maybe try again with (b), that
> opens up a downgrade attack. Intermediaries can observe the size of the
> Client Hello and make it break
>

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[David Benjamin]

On Tue, Oct 10, 2023 at 1:24 PM Bas Westerbaan  wrote:

> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
>> just let them break in case (a), and then maybe try again with (b), that
>> opens up a downgrade attack. Intermediaries can observe the size of the
>> Client Hello and make it break
>>
>
> Exactly.
>

Yup! The draft fixes that downgrade, should any clients take such an (a) +
(b) fallback strategy. I would very much prefer not needing such a strategy
(so Chrome's current rollout attempt simply does (a)), since such fallbacks
have other bad consequences. But if we can at least make it secure, that
gives us a bit more breathing room in case anyone needs it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt

[Bas Westerbaan]

> But if we can at least make it secure, that gives us a bit more breathing
> room in case anyone needs it.
>

For those who missed it: we need it for Edge -> Origin connections, as some
origins do break on split ClientHello. (See e-mail sept 29th.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Dennis Jackson]

On 10/10/2023 17:53, Russ Housley wrote:


Dennis:

If we are going to allow a certificate to include pointers to 
externally stored public keys, I think a solution that works for the 
Web PKI and other PKI environment as well.


I'm trying to understand the use case of certificates with pointers to 
externally stored public keys. What's the value in splitting these 
objects? If you're going to cache a public key, why not cache the whole 
certificate?


The suggestion of Abridged Certs is just one way to do that caching. If 
the external fetching via URL is the key feature - you could define a 
certificate compression scheme which compresses and decompresses a 
certificate to a URL.


I skimmed the LAMPS list as well, but I did not see any discussion of 
the rationale there.



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

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

[Russ Housley]

Dennis:

>> If we are going to allow a certificate to include pointers to externally 
>> stored public keys, I think a solution that works for the Web PKI and other 
>> PKI environment as well.
> 
> I'm trying to understand the use case of certificates with pointers to 
> externally stored public keys. What's the value in splitting these objects? 
> If you're going to cache a public key, why not cache the whole certificate?
> 
> The suggestion of Abridged Certs is just one way to do that caching. If the 
> external fetching via URL is the key feature - you could define a certificate 
> compression scheme which compresses and decompresses a certificate to a URL.
> 
> I skimmed the LAMPS list as well, but I did not see any discussion of the 
> rationale there.


This has not yet been discussed on the LAMPS mail list, thus there is no 
consensus that this is a good idea,

Russ

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

Re: [TLS] [Editorial Errata Reported] RFC5054 (7538)

[Chris Smiley]

H Paul,

We are unable to verify this erratum that the submitter marked as editorial. 
Please note that we have changed the “Type” of the following errata 
report to “Technical”. As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

You may review the report at: 
https://www.rfc-editor.org/errata/eid7538

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/cs

> On Jun 6, 2023, at 11:58 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC5054,
> "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7538
> 
> --
> Type: Editorial
> Reported by: Mingye Wang 
> 
> Section: 2.1
> 
> Original Text
> -
> The version of SRP used here is sometimes referred to as "SRP-6"
>   [SRP-6].
> 
> Corrected Text
> --
> The version of SRP used here is sometimes referred to as "SRP-6a"
>   [SRP-6a].
> 
> 
> [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, 
> http://srp.stanford.edu/design.html
> 
> Notes
> -
> The protocol described uses a non-constant k, which is an innovation of 
> SRP-6a -- never published formally in a technical report (until this RFC) and 
> dating to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 
> 2002 uses a constant k = 3.
> 
> Reference to the [SRP-6] text is still valuable for rationale, but is not 
> accurate. Confusion between these two versions is harmful and may impeded 
> interoperability.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC5054 (draft-ietf-tls-srp-14)
> --
> Title   : Using the Secure Remote Password (SRP) Protocol for TLS 
> Authentication
> Publication Date: November 2007
> Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
> Category: INFORMATIONAL
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 

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

[TLS] [Errata Verified] RFC5054 (7538)

[RFC Errata System]

The following errata report has been verified for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7538

--
Status: Verified
Type: Technical

Reported by: Mingye Wang 
Date Reported: 2023-06-07
Verified by: Paul Wouters (IESG)

Section: 2.1

Original Text
-
 The version of SRP used here is sometimes referred to as "SRP-6"
   [SRP-6].

Corrected Text
--
 The version of SRP used here is sometimes referred to as "SRP-6a"
   [SRP-6a].


 [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, 
http://srp.stanford.edu/design.html

Notes
-
The protocol described uses a non-constant k, which is an innovation of SRP-6a 
-- never published formally in a technical report (until this RFC) and dating 
to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a 
constant k = 3.

Reference to the [SRP-6] text is still valuable for rationale, but is not 
accurate. Confusion between these two versions is harmful and may impeded 
interoperability.

--
RFC5054 (draft-ietf-tls-srp-14)
--
Title   : Using the Secure Remote Password (SRP) Protocol for TLS 
Authentication
Publication Date: November 2007
Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
Category: INFORMATIONAL
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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

Re: [TLS] [Editorial Errata Reported] RFC5054 (7538)

[Paul Wouters]

Thanks Chris,

I've checked the errata and it is correct. I've marked it as Verified.

Paul


On Tue, Oct 10, 2023 at 8:11 PM Chris Smiley  wrote:

>
> H Paul,
>
> We are unable to verify this erratum that the submitter marked as
> editorial.
> Please note that we have changed the “Type” of the following errata
> report to “Technical”. As Stream Approver, please review and set the
> Status and Type accordingly (see the definitions at
> https://www.rfc-editor.org/errata-definitions/).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid7538
>
> Please see https://www.rfc-editor.org/how-to-verify/ for further
> information on how to verify errata reports.
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php.
>
> Thank you.
>
> RFC Editor/cs
>
> > On Jun 6, 2023, at 11:58 PM, RFC Errata System <
> rfc-edi...@rfc-editor.org> wrote:
> >
> > The following errata report has been submitted for RFC5054,
> > "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7538
> >
> > --
> > Type: Editorial
> > Reported by: Mingye Wang 
> >
> > Section: 2.1
> >
> > Original Text
> > -
> > The version of SRP used here is sometimes referred to as "SRP-6"
> >   [SRP-6].
> >
> > Corrected Text
> > --
> > The version of SRP used here is sometimes referred to as "SRP-6a"
> >   [SRP-6a].
> >
> >
> > [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005,
> http://srp.stanford.edu/design.html
> >
> > Notes
> > -
> > The protocol described uses a non-constant k, which is an innovation of
> SRP-6a -- never published formally in a technical report (until this RFC)
> and dating to ~2005 if we go by the libsrp version history. Actual [SRP-6]
> of 2002 uses a constant k = 3.
> >
> > Reference to the [SRP-6] text is still valuable for rationale, but is
> not accurate. Confusion between these two versions is harmful and may
> impeded interoperability.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC5054 (draft-ietf-tls-srp-14)
> > --
> > Title   : Using the Secure Remote Password (SRP) Protocol
> for TLS Authentication
> > Publication Date: November 2007
> > Author(s)   : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin
> > Category: INFORMATIONAL
> > Source  : Transport Layer Security
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> >
>
>
___
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

[Kampanakis, Panos]

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  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 mailto:spasm-boun...@ietf.org>> On Behalf 
Of Mike Ounsworth
Sent: Saturday, September 30, 2023 5:16 PM
To: 'LAMPS' mailto:sp...@ietf.org>>
Cc: John Gray mailto:john.g...@entrust.com>>; 
Markku-Juhani O. Saarinen mailto:m...@pqshield.com>>; David 
Hook mailto: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 KeyFactor are reviving this draft.

We suspect this might also be of interest to the TLS WG, but I will start a 
separate thread on the TLS list.


---
Mike Ounsworth

From: internet-dra...@ietf.org 
mailto:internet-dra...@ietf.org>>
Sent: Saturday, September 30, 2023 5:12 PM
To: D. Hook mailto:david.h...@keyfactor.com>>; John 
Gray mailto:john.g...@entrust.com>>; Markku-Juhani O. 
Saarinen mailto:m...@pqshield.com>>; John Gray 
mailto:john.g...@entrust.com>>; Markku-Juhani Saarinen 
mailto:m...@pqshield.com>>; Mike Ounsworth 
mailto:mike.ounswo...@entrust.com>>
Subject: [EXTERNAL] New Version Notification for 
draft-ounsworth-lamps-pq-external-pubkeys-00.txt

A new version of Internet-Draft draft-ounsworth-lamps-pq-external-pubkeys-00. 
txt has bee