[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/rfc8447bis (+1/-1/đź’¬1) 1 issues created: - Address SecDir review comments (by seanturner) https://github.com/tlswg/rfc8447bis/issues/69 1 issues received 1 new comments: - #60 AD review comments (1 by seanturner) https://github.com/tlswg/rfc8447bis/issues/60 1 issues closed: - AD review comments https://github.com/tlswg/rfc8447bis/issues/60 Pull requests - * tlswg/rfc8447bis (+7/-6/đź’¬0) 7 pull requests submitted: - Fix nits from SecDir Review (by seanturner) https://github.com/tlswg/rfc8447bis/pull/70 - Add submissionType (by seanturner) https://github.com/tlswg/rfc8447bis/pull/67 - More AD updates (by seanturner) https://github.com/tlswg/rfc8447bis/pull/66 - Make consistent "Y" to "D" text (by seanturner) https://github.com/tlswg/rfc8447bis/pull/65 - Remove Tabs (by seanturner) https://github.com/tlswg/rfc8447bis/pull/64 - Spelling (by seanturner) https://github.com/tlswg/rfc8447bis/pull/63 - Addressing decimal (by seanturner) https://github.com/tlswg/rfc8447bis/pull/62 6 pull requests merged: - More AD updates https://github.com/tlswg/rfc8447bis/pull/66 - Make consistent "Y" to "D" text https://github.com/tlswg/rfc8447bis/pull/65 - Remove Tabs https://github.com/tlswg/rfc8447bis/pull/64 - Spelling https://github.com/tlswg/rfc8447bis/pull/63 - Addressing decimal https://github.com/tlswg/rfc8447bis/pull/62 - Addressing AD comments https://github.com/tlswg/rfc8447bis/pull/61 * tlswg/tls-flags (+1/-1/đź’¬0) 1 pull requests submitted: - Clarify language around the size of the extension. (by bob-beck) https://github.com/tlswg/tls-flags/pull/38 1 pull requests merged: - Clarify language around the size of the extension. https://github.com/tlswg/tls-flags/pull/38 * tlswg/tls-key-update (+2/-0/đź’¬0) 2 pull requests submitted: - Updated description of the key update (by hannestschofenig) https://github.com/tlswg/tls-key-update/pull/17 - PQC Typo (by hannestschofenig) https://github.com/tlswg/tls-key-update/pull/16 Repositories tracked by this digest: --- * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/dnssec-chain-extension * https://github.com/tlswg/draft-deprecate-obsolete-kex * https://github.com/tlswg/draft-ietf-tls-cert-abridge * https://github.com/tlswg/draft-ietf-tls-ctls * https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead * https://github.com/tlswg/draft-ietf-tls-ech-keylogfile * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-grease * https://github.com/tlswg/draft-ietf-tls-iana-registry-updates * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-svcb-ech * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/draft-ietf-tls-tls13-vectors * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/dtls-rrc * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/rfc4492bis * https://github.com/tlswg/rfc8447bis * https://github.com/tlswg/rfc8773bis * https://github.com/tlswg/sniencryption * https://github.com/tlswg/sslkeylogfile * https://github.com/tlswg/sslv3-diediedie * https://github.com/tlswg/super-jumbo-record-limit * https://github.com/tlswg/tls13-spec * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/tls-flags * https://github.com/tlswg/tls-key-share-prediction * https://github.com/tlswg/tls-key-update * https://github.com/tlswg/tls-record-limit * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/tls12-frozen * https://github.com/tlswg/tls13-pkcs1 * https://github.com/tlswg/tls13-rfc -- To have a summary like this sent to your list, see: https://github.com/ietf-github-services/activity-summary ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Mon, Mar 17, 2025 at 6:17 AM Eric Rescorla wrote: > On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre wrote: > >> On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman > 40apple@dmarc.ietf.org> wrote: >> >>> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >>> and provided feedback so far. As more people start reading it, I wanted to >>> clarify that the current draft version does not yet reflect the change we >>> intend to make to allow Certificates and the pake extension to be used >>> together. We’ve filed a GitHub issue here tracking our intent to change >>> this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. >>> >> >> I'm pretty sure this is not news to authors, but I've thought about this >> one before (when the IRTF was conducting their PAKE contest). It seems like >> using both PAKE and certificates together, in combination with "Sign In" >> products would be pretty powerful. I am not sure why this draft needs TLS >> extensions, and it doesn't cover the thorny problem of PAKE registration at >> all. >> > > Leaving the question of registration aside, I don't believe that PAKEs are > really viable in the Web context, for two reasons: > > - Sites in general want to control the login experience and this means > having the password typed in in a box they control, not in the browser UI, > especially given the current terrible state of password UIs for browsers. > - In the phishing context, the attacker site can just prompt the user > directly for their password or simulate the PAKE UI, thus bypassing the > PAKE. The whole premise of phishing is that the user doesn't check > carefully, so I don't think we can rely on users to detect this form of > attack. > > We already have phishing resistant authentication mechanisms such as > WebAuthn which don't have this problem, so I think the motivation for PAKEs > on the Web is pretty weak. > I'd also add that, *if* we want something PAKE-shaped in a web-like context, I don't think TLS-PAKE is a good fit for it. (Which is fine! Not everything needs to be for every use case.) Each run of the PAKE gives the peer a chance to guess our low-entropy secret. That means, from what I can tell, the ideal flow is for your application to have some kind of one-time or infrequent password auth flow that it actually runs the PAKE, and then that gives you a more robust higher-entropy secret that can be used for subsequent operations if you need that (e.g. for new connections). While applications often have flows like this (login with password that establishes some cookie-like credential from there, some sort of pairing ceremony, etc.), a connection-based PAKE story needs the logic for those flows to be close enough to be sufficiently close to the application logic to capture that. Over something like HTTP, and particularly on the web where you can't break through the HTTP request/response abstraction, that sort of thing doesn't work out. If your application works in terms of HTTP requests and responses, HTTP connection creation is an internal detail of your HTTP stack. It's all part of a big black box that tries to effectively manage the sea of HTTP requests made by the application. HTTP client stacks will do all kinds of things like open connections in parallel, pool them, predictively connect them, etc. Different HTTP versions have very different kinds of connection reuse capabilities. We keep inventing ways for servers to influence connection management for load balancing, etc. This is similar to why TLS client certificates has worked badly for authenticating humans, who have to make decisions on the fly which hat they're wearing, what information to reveal, etc.. So *if* someone wants to do PAKE in *that* environment, something with HTTP as the substrate would work better. Whereas if your application is a bit closer to the TLS side, then doing it in TLS can make sense. (But I would also agree that WebAuthn seems a better direction for web-like stuff. That seems to have a lot more energy and existing deployment behind it, and some additional nice properties.) > Couldn't it be click "Sign In", and start the TLS key schedule from there, >> instead of "0"? No extensions necessary. >> > > Regardless of the point above, I do not believe this would work. You need > some protocol to carry the PAKE information and if that's not going in the > TLS handshake, where is it going? > > -Ekr > > > > >> I decided not to work on this problem, because I figured it would make a >> lot of people mad, and I didn't want to spend my time on it. But, might as >> well ask the question since we have this draft in front of us. >> >> thanks, >> Rob >> >> >> ___ >> 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: Opsdir telechat review of draft-ietf-tls-tls12-frozen-06
Thanks for the review. I'm not a native speaker but I'm afraid this sentence may be read as 'encrypting more of the traffic' and 'removing primitives" are examples of known deficiencies, not fixes. Maybe rephrase as '...it fixes most known deficiencies with TLS 1.2 [TLS12]. In particular, TLS 1.3 encrypting more..."? This is a very good idea, thanks! ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman wrote: > Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt > and provided feedback so far. As more people start reading it, I wanted to > clarify that the current draft version does not yet reflect the change we > intend to make to allow Certificates and the pake extension to be used > together. We’ve filed a GitHub issue here tracking our intent to change > this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. > I'm pretty sure this is not news to authors, but I've thought about this one before (when the IRTF was conducting their PAKE contest). It seems like using both PAKE and certificates together, in combination with "Sign In" products would be pretty powerful. I am not sure why this draft needs TLS extensions, and it doesn't cover the thorny problem of PAKE registration at all. Couldn't it be click "Sign In", and start the TLS key schedule from there, instead of "0"? No extensions necessary. I decided not to work on this problem, because I figured it would make a lot of people mad, and I didn't want to spend my time on it. But, might as well ask the question since we have this draft in front of us. thanks, Rob ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre wrote: > On Sat, Mar 15, 2025 at 7:21 PM Laura Bauman 40apple@dmarc.ietf.org> wrote: > >> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >> and provided feedback so far. As more people start reading it, I wanted to >> clarify that the current draft version does not yet reflect the change we >> intend to make to allow Certificates and the pake extension to be used >> together. We’ve filed a GitHub issue here tracking our intent to change >> this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. >> > > I'm pretty sure this is not news to authors, but I've thought about this > one before (when the IRTF was conducting their PAKE contest). It seems like > using both PAKE and certificates together, in combination with "Sign In" > products would be pretty powerful. I am not sure why this draft needs TLS > extensions, and it doesn't cover the thorny problem of PAKE registration at > all. > Leaving the question of registration aside, I don't believe that PAKEs are really viable in the Web context, for two reasons: - Sites in general want to control the login experience and this means having the password typed in in a box they control, not in the browser UI, especially given the current terrible state of password UIs for browsers. - In the phishing context, the attacker site can just prompt the user directly for their password or simulate the PAKE UI, thus bypassing the PAKE. The whole premise of phishing is that the user doesn't check carefully, so I don't think we can rely on users to detect this form of attack. We already have phishing resistant authentication mechanisms such as WebAuthn which don't have this problem, so I think the motivation for PAKEs on the Web is pretty weak. Couldn't it be click "Sign In", and start the TLS key schedule from there, > instead of "0"? No extensions necessary. > Regardless of the point above, I do not believe this would work. You need some protocol to carry the PAKE information and if that's not going in the TLS handshake, where is it going? -Ekr > I decided not to work on this problem, because I figured it would make a > lot of people mad, and I didn't want to spend my time on it. But, might as > well ask the question since we have this draft in front of us. > > thanks, > Rob > > > ___ > 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] Artart last call review of draft-ietf-tls-rfc8447bis-11
Reviewer: Barry Leiba Review result: Ready with Nits This document is in good shape and does what it needs to do. I have just one very minor substantive comment, and two very nitty nits: — Section 3.1 — If the "Recommended" column is set to "D" the item is discouraged and SHOULD NOT or MUST NOT be used. That seems a little odd, and I wonder whether some readers of the note (who don’t look here for the definition of “D”) might be confused about whether it’s SHOULD NOT or MUST NOT. Perhaps this?: NEW-1 If the "Recommended" column is set to "D" the item is discouraged and SHOULD NOT or MUST NOT be used; consult the item’s references to understand the situation. END …or maybe… NEW-2 If the "Recommended" column is set to "D" the item is discouraged and SHOULD NOT or MUST NOT be used, depending upon the situation; consult the item’s references for clarity. END — Section 3 — Nit in the definition of “N”: “leave an items” -> “leave an item”. Also “basis of it having” -> “basis of its having”, as standard practice uses possessive pronouns with gerunds. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] A different approach to Attestation
A common requirement in device security is to know that a key is bound to a
device with some degree of hardware assurance such that the key can be used
on the device but not extracted from it.
FIPS-140 specifies a set of assurance levels but there is value in even the
lightest of lightweight assurance levels. By far the largest risk of key
disclosure comes from administrative error, backing up the private key file
in plaintext, selling a host machine on EBay without wiping the disks, etc.
etc. Yes, Kocher side channel attacks are important if you are going to do
it right but the bar to measurable improvement in security turns out to be
really really low.
So what if we could add a means of attesting that a key that the
manufacturer of the device has absolutely no knowledge of is bound to a
device that is completely compatible with SSL/1.0 thru TLS/1.3? No protocol
changes needed. The only change comes in the key generation step and the
manner in which the hardware key is used.
Step 1: Device generation
Manufacturer generates an ECC private key pair {x.P, x} and an assertion
A(x.P) that the private key corresponding to x.P is bound to the device
accredited under the trust chain of your choice.
This assertion does not expire. The manufacturer has absolutely no
involvement in the protocol after the device ships.
Step 2: Key generation
Since Alice does not trust the manufacturer at all or in any degree, Alice
is going to generate her own keypair {y.P, y}.
Alice also generates P(x.P, y.P) a proof of possession for y consisting of
Sig (x.P, y)
Step 3: Certificate request
A certificate request is generated for the public key z.P = x.P + y.P with
an attestation section containing A(x.P) and P(x.P, y.P)
The CA verifies that z.P is consistent with the claims specified in A(x.P)
and P(x.P, y.P), if the check succeeds, the CA adds an extension to the
cert saying the key is dependent on the bound key x.P.
[Alternatively, the extension can specify A(x.P) and P(x.P, y.P) allowing
endpoints to do the validation, this can be achieved either directly or
through a self validating URI such as an EARL.]
Step 4: Performing TLS (or other protocol)
Key operations involving x have to be submitted to whatever security module
holds x. This API is extended to support the operation Sign (Data, keyID,
offset), the caller specifies Sign (Data, "boundKey", y)
This is not a threshold signature protocol, it is a threshold key protocol
where the key produced by adding x+y is used for signature. So we don't
have to worry about all the 'concurrency' issues to do with combining the
results of two signature operations. There is a single signature operation
occurring but under a key that is not known to either the manufacturer or
the user.
Impact
This approach is completely backwards compatible. An attested TLS
certificate works in every circumstance that legacy certificates work with
absolutely no protocol changes. The only difference in use is that a
relying party that requires the attestation can see it in the certificate.
The Manufacturer is required to do the attestation bit but their
involvement is minimal, they have to develop some sort of secure enclave
and provide an api to use the key with a user specified offset.
The Key Generation app used by the client needs to be slightly modified but
this is minimal
The CA needs to do some additional validation checks but these are easy to
specify and enforce.
The TLS library doesn't need to change very much beyond being able to
present a private key to a crypto provider. This might fit into existing
plug and play crypto schemes or it might not. This is something that is
fixable and should be fixed.
The big win for security is that disclosure of the private key y doesn't
lead to a breach unless the manufacturer also suffers a breach. The value y
can be stored unencrypted.
Key Rollover
Yup, the device bound key never changes. We can spin up a new y as many
times as we like but x never changes. Nor is there any value in changing
it. Any mechanism you try to construct for rolling over the bound key is
going to increase rather than decrease attack surface. Yes, I am aware that
you could put in place a route for rollover of the bound key via the
manufacturer but... just no, not needed, not useful.
Post Quantum
Yup, depends on ECC so if you want PQC as well, you would need to have a
hybrid config until someone works out how to do threshold securely in PQC.
Yes, I can do threshold in ML-KEM, I can also break that scheme.
Draft
Will spin up the draft when I get home. My MacBook is refusing to run my
dotNET code for my Word->XML2RFC converter. Anyone know how to bypass the
malware protection checks?
Patents
Yeah, probably covered by prior art I disclosed in the Mesh documents and
in public presentations many years back. I am not intending to make a
claim. If someone does, please remember who provides relevant expert
witness services...
_
[TLS] Re: A different approach to Attestation
Phill:
This is really a description of IDevID certificates that are installed by a
factory, and then replaced by LDevID certificates that are issed by the device
owner at the time of installation. NETCONF already supports that model.What am
I missing?
Russ
> On Mar 16, 2025, at 11:31 PM, Phillip Hallam-Baker
> wrote:
>
> A common requirement in device security is to know that a key is bound to a
> device with some degree of hardware assurance such that the key can be used
> on the device but not extracted from it.
>
> FIPS-140 specifies a set of assurance levels but there is value in even the
> lightest of lightweight assurance levels. By far the largest risk of key
> disclosure comes from administrative error, backing up the private key file
> in plaintext, selling a host machine on EBay without wiping the disks, etc.
> etc. Yes, Kocher side channel attacks are important if you are going to do it
> right but the bar to measurable improvement in security turns out to be
> really really low.
>
> So what if we could add a means of attesting that a key that the manufacturer
> of the device has absolutely no knowledge of is bound to a device that is
> completely compatible with SSL/1.0 thru TLS/1.3? No protocol changes needed.
> The only change comes in the key generation step and the manner in which the
> hardware key is used.
>
>
> Step 1: Device generation
>
> Manufacturer generates an ECC private key pair {x.P, x} and an assertion
> A(x.P) that the private key corresponding to x.P is bound to the device
> accredited under the trust chain of your choice.
>
> This assertion does not expire. The manufacturer has absolutely no
> involvement in the protocol after the device ships.
>
>
> Step 2: Key generation
>
> Since Alice does not trust the manufacturer at all or in any degree, Alice is
> going to generate her own keypair {y.P, y}.
>
> Alice also generates P(x.P, y.P) a proof of possession for y consisting of
> Sig (x.P, y)
>
>
> Step 3: Certificate request
>
> A certificate request is generated for the public key z.P = x.P + y.P with an
> attestation section containing A(x.P) and P(x.P, y.P)
>
> The CA verifies that z.P is consistent with the claims specified in A(x.P)
> and P(x.P, y.P), if the check succeeds, the CA adds an extension to the cert
> saying the key is dependent on the bound key x.P.
>
> [Alternatively, the extension can specify A(x.P) and P(x.P, y.P) allowing
> endpoints to do the validation, this can be achieved either directly or
> through a self validating URI such as an EARL.]
>
>
> Step 4: Performing TLS (or other protocol)
>
> Key operations involving x have to be submitted to whatever security module
> holds x. This API is extended to support the operation Sign (Data, keyID,
> offset), the caller specifies Sign (Data, "boundKey", y)
>
> This is not a threshold signature protocol, it is a threshold key protocol
> where the key produced by adding x+y is used for signature. So we don't have
> to worry about all the 'concurrency' issues to do with combining the results
> of two signature operations. There is a single signature operation occurring
> but under a key that is not known to either the manufacturer or the user.
>
>
> Impact
>
> This approach is completely backwards compatible. An attested TLS certificate
> works in every circumstance that legacy certificates work with absolutely no
> protocol changes. The only difference in use is that a relying party that
> requires the attestation can see it in the certificate.
>
> The Manufacturer is required to do the attestation bit but their involvement
> is minimal, they have to develop some sort of secure enclave and provide an
> api to use the key with a user specified offset.
>
> The Key Generation app used by the client needs to be slightly modified but
> this is minimal
>
> The CA needs to do some additional validation checks but these are easy to
> specify and enforce.
>
> The TLS library doesn't need to change very much beyond being able to present
> a private key to a crypto provider. This might fit into existing plug and
> play crypto schemes or it might not. This is something that is fixable and
> should be fixed.
>
> The big win for security is that disclosure of the private key y doesn't lead
> to a breach unless the manufacturer also suffers a breach. The value y can be
> stored unencrypted.
>
>
> Key Rollover
>
> Yup, the device bound key never changes. We can spin up a new y as many times
> as we like but x never changes. Nor is there any value in changing it. Any
> mechanism you try to construct for rolling over the bound key is going to
> increase rather than decrease attack surface. Yes, I am aware that you could
> put in place a route for rollover of the bound key via the manufacturer
> but... just no, not needed, not useful.
>
>
> Post Quantum
>
> Yup, depends on ECC so if you want PQC as well, you would need to have a
> hybrid conf
