Re: [TLS] WG Adoption for TLS Trust Expressions

[Ilari Liusvaara]

On Tue, Apr 23, 2024 at 01:37:26PM -0700, Devon O'Brien wrote:
> After sharing our first draft of TLS Trust Expressions
>  and
> several discussions across a couple  IETFs, we’d like to proceed with a
> call for working group adoption of this draft. We are currently prototyping
> trust expressions in BoringSSL & Chromium and will share more details when
> implementation is complete.
> 
> As we mentioned in our message to the mailing list from January, our
> primary goal is to produce a mechanism for supporting multiple subscriber
> certificates
> 
> and efficiently negotiating which to serve on a given TLS connection, even
> if that ends up requiring significant changes to the draft in its current
> state.

The negotiation mechanism mostly looks OK. Might need a few tweaks,
e.g.:

- Sorting the TrustExpressionList in some canonical order, to simplify
  TLS server a bit.
- Adding record type to TrustExpression for future extension (with
  unknown trust expressions ignored).


The subscriber side is far more challenging. The core issue is that
applications act as middlemen between ACME client and TLS library,
and those are very variable bunch.

There currently is no way of passing the information required, so
some application changes will be required. The issue is application
limitations that would require drastic changes, which are discouraged,
to remove.

Examples of application limitations that might be very hard to fix:

- Application selects one subscriber certificate to use.
- Application selects some fixed (unchangeable by ACME client) N
  subscriber certificates, and then the TLS library selects among
  those. 

And there are very popular applications that are like this.


However, even with fixed subscriber certificate, it is still valuable
to be able to select among available issuer chains. Some can be
significantly smaller than the others (e.g., 1119 bytes vs. 701 bytes
vs. 0 bytes). Things get even more lopsided with post-quantum
certificates.


This would lead to model where the certificate files have:

- Subscriber certificate
- Default issuer chain
- Alternate issuer chains, together with negotiation data.

The application would then pass these to the TLS library, which would
perform the final merging of data across possible subscriber
certificates, and then perform subscriber selection and issuer chain
selection from available candidates.


And even if alternate issuer chains seem to be associated with the
issuer, there is a subtle issue: Name constraints can differ among
possible issuer chains. This can happen due to:

- explicit name constraints present in some intermediates but not
  others. This has happened, and led to divergent name constraints.
- Root programs imposing implicit name constraints on roots. This
  has also happened (but I don't know if this has led to divergent
  name constriants).


> To that end, we’re interested in learning whether wg members support
> adoption of this deployment model and the currently-described certificate
> negotiation mechanism or if they oppose adoption (and why!).

The bar to clear for adoption is "good starting point", which this seems
to be, even if the details of mechanism do not work out (as detailed
above).




-Ilari

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

Re: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[Ilari Liusvaara]

On Mon, Mar 18, 2024 at 06:46:51PM +, John Mattsson wrote:
> Hi,
> 
> I thought the old version was a quite good starting point. This new
> version seems significantly worse. I think it has three major
> problems:
> 
> 1. It uses the application layer and therefore requires changes in the
> application layer. For many uses of TLS, it is not acceptable to
> change the application layer.

I expect that in many applications, it is not even possible to change
the application layer.


> 3. I don't see the need for HPKE. All discussions, specifications,
> and deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary
> "KeyShareEntry". Replacing the existing key exchange mechanism in TLS
> with the public key encryption mechanism HPKE. This seems to add a
> lot of code to an TLS implementation already doing quantum-resistant
> key exchange in the initial handshake.

Yes, using existing TLS mechanisms is much easier for implementations.


> I think a solution to do post-handshake ephemeral-ephemeral key
> exchange as well as mutual post-handshake authentication on the
> TLS/DTLS/QUIC layer would be very welcome. I think ephemeral-
> ephemeral key exchange as well as not using the application layer
> should be requirements.

Note that TLS-level post-handshake authentication has very nontrivial
implications on application protocols. E.g., HTTP/2 explicitly bans
TLS post-handshake authentication for very good reasons.

For supporting application-layer authentication, there already are
TLS exporter and exported authenticators.

For EE key exchange, TLS is the relatively easy case. Everything in
TLS is in-order and lossless. The only possible race condition is the
crossed update, and it is easy to make both sides agree that happened.

DTLS is much more difficult due to all the race conditions caused by
reordering and packet loss. Which is something TLS does not have to
deal with, and is especially problematic with the crossed update case.

And while QUIC is based on TLS, it replaces some of the key parts
this mechanism touches. Which means it has to have its own version.
And looks like it has to deal with similar problems (reordering and
packet loss) as DTLS does.


> I think frequent rekeying with ephemeral-ephemeral key exchange is a
> must for long-lived interfaces. This has for a long time been an
> established requirement. Typical requirements are 1 hour of 100 GB in
> IPsec and 1 hour or 1 GB in SSH. Note that there is no problem with
> TLS 1.3 when you can frequently setup new connection with psk_dhe_ke.
> Discussing with Eric Rescorla and Martin Thomson in the past, they
> suggested that this was the way forward. It would be interesting to
> hear if there are more use cases than RFC 6083 where frequently
> setting up a new connection with psk_dhe_ke is problematic. I expect
> there is.

Any application that associates resources with connection poses major
problems with setting up new connections.

While I don't think anybody uses it with TLS, up until recently BGP
(extremely important, to put it mildly) was infamous of recting very
badly to connection loss.




-Ilari

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

Re: [TLS] ML-KEM key agreement for TLS 1.3

[Ilari Liusvaara]

On Wed, Mar 06, 2024 at 04:25:16PM +, John Mattsson wrote:
> I think TLS should register all algorithm variants standardized by
> NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in
> the future a subset of HQC/BIKE/Classic McEliece.

Just as note, supporting Classic McEliece is not possible at all due to
the key size exceeding hard TLS 1.3 limit.

Even FrodoKEM, which seems to be quite widely viewed as "next step up"
from likes of ML-KEM, has painfully large keys. But at least those do
not bust any hard limits.




-Ilari

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

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt

[Ilari Liusvaara]

On Fri, Mar 01, 2024 at 12:48:54PM +, Dennis Jackson wrote:
> 
> On 06/09/2023 17:46, Ilari Liusvaara wrote:
> > Doing quick review:
> > 
> > Section 3.1.2:
> > 
> > - RFC 8879 does not allow ignoring unrecognized three-byte identifiers.
> >Instead, the connection MUST be terminated with bad_certificate alert.
> > 
> >This has consequence that any client that can ever add a custom trust
> >anchor via any means must have the complete certificate list (whereas
> >partial list would be enough if no custom trust anchors can ever be
> >added).
> 
> I hope that clarifies why transmitting the lengths is necessary. Regarding
> the decompression errors, I've updated the draft to say that decompression
> must fail and the correct alert sent if the length fields are incorrect as
> you suggested. I've filed an issue to discuss the case of unrecognized
> identifiers specifically [1].

The unrecognized identifier issue is a bit more subtle.

Suppose that a client:

- Has only partial list of certificates (enough to cover the built-in
  trust store).
- Allows an admin to add a new trust anchor, or to override validation
  error.

Then such client can get into situation where server sends chain that
should be valid, but instead references a certificate the client does
not have. Which is a hard error.


> > Section 3.2.:
> > 
> > - Using alternate scheme could result drastically reduced implementation
> >complexity.
> > 
> >Furthermore, one can't even use standard zstd decoder with this due to
> >security reasons. One needs special one (but seems like reference zstd
> >library ships that as alternative API).
> 
> Can you clarify what you mean by this? The standard zstd decoder works fine.

The standard zstd decoder can allocate very large amounts of memory.
Thus, one has to use decoder that decodes in one shot to given buffer
with a small bounded memory usage.

Fortunately, standard zstd library does have such decoder.


> > Section 3.2.1.:
> > 
> > - I suspect that having CA-specific dictionaries would make it much
> >easier to be equitable and improve compression.
> > 
> >Then I don't think the dictionary construction method is good:
> >* Using just one certificate is very dubious.
> >* It is more optimal to consider byte substrings with no structure.
> 
> This is tracked in [2] and [3]. Depending on the experimental data we get
> when evaluating [3], we might omit pass 2 entirely.

Regarding the dictionary construction, it is just that I think that
using many certificates and choosing common unstructured substrings
would lead to a better dictionary.

It is not like this method uses certificate structure in any way.


> > Section 3.2.1.1.:
> > 
> > - Caching monolithic compression from startup does not work because of
> >extension fields.
> > 
> >For caching to work, one would have to compress the certificate
> >entries independently and leave the extension fields in between
> >uncompressed.
>
> The draft currently preserves the extension fields. Existing TLS Certificate
> Compression APIs perform the caching at the level of the entire message and
> so the cache is only used if the entire message, including extensions, is
> bytewise identical. Can you think of an extension in a Certificate message
> which changes frequently?

Dealing with 1 variant is easy, dealing with up to N variants is much
harder. And that N is exponential in number of supported extensions,
and some extensions might do internal negotiation, making it grow even
faster than 2^k.


> > Section 5.1.:
> > 
> > - I think the argument about adding roots taking time is flawed. Roots
> >are usually not even included in the chain, but intermediates are,
> >and can change much faster.
> > 
> >I remember seeing one CA that judging from naming of the intermediate
> >rotated it every 6 months.
> 
> This draft definitely doesn't want to be a factor slowing rotation. I've
> filed [4] to keep track of this. As discussed in Appendix B and in the IETF
> 117 presentation, it might be that dynamic versioning is more suitable in
> the long run.

It seems to be very difficult for strategy like this to work well in
very dynamic situations.

Things like trust expressions seem to be much better designed for
dealing with highly dynamic situations. And trust expressions can be
leveraged for omitting intermediates (intermediates can be temporarily
promoted into trust anchors).


> > Section 5.4:
> > 
> > - I think the current complexity as I understand the draft is just
> >scary.
> > 
> >I consider not being able to adjust

Re: [TLS] [CFRG] Chempat-X: hybrid of X25519 and sntrup761

[Ilari Liusvaara]

On Sat, Jan 27, 2024 at 02:56:45PM -, D. J. Bernstein wrote:
> David Benjamin writes:
> > No more heavily parameterized algorithms. Please precompose them.
> >
> > Once you precompose them, you may as well take advantage of properties
> > of the inputs and optimize things.
> 
> In my implementor's hat, I partially agree. Knowing the context often
> enables speedups that aren't available in more generality, as long as
> the implementation isn't factored into context-independent pieces.
> 
> However, at the design stage, speedups have to be weighed against other
> considerations, such as overloading security reviewers and introducing
> unnecessary traps into the ecosystem.

Security review of X-wing only needs to be done once.

I think generic combiner would be the unnecressary trap.

Generic combiner would likely lead to lots of combinations. Something
multiple crypto library maintainers have said they don't want. And
overloading crypto library maintainers is far worse than overloading
security reviewers.

And I think it much easier to understand integrated thing that is unsafe
to change than that the component KEMs must be  (oh,
and then being used with stuff that fails the requirement).

And things are made worse by different protocols tending to do things
subtly differently even when using the same KEMs.


None of this is theroretical risk, this all has been seen in practice.
Unlike unsafe modified versions of X-Wing.


> The particular speedup we're talking about here is eliminating hashing a
> kilobyte or two of data. In context, this speedup is negligible: about
> 1% of the cost of communicating that data in the first place, never mind
> other application costs.

The cost is not negligible.


> There's a 20-page paper saying that this tiny speedup is safe _for
> Kyber_. Why exactly do we want security reviewers spending time on this?
> And why should this be sitting around in the ecosystem, given the clear
> risk of someone plugging in something other than Kyber?

Not all of that is security proofs, and the part about the speedup is
like 1.3 pages of simple rather sparsely spaced text. And there are even
simpler ways of proving the same thing.

Looking at other stuff in the paper, there is about 2.3 pages of much
more complicated text proving that using X25519 is safe at all! Which
is something that generic composition does not even consider, and this
matter is not trivial.

If somebody starts blindly replacing algorithms, there is much higher
risk of actual security problem caused by choosing bad algorithms than
omitting some hashing.

No real attacker is looking how to break IND-CCA. They are looking at
how to attack actual systems. The value of IND-CCA is that despite
unrealistically strong attack model, most algorithms that fail it tend
to fail in rather dangerous ways. Which is not at all clear for
combiner with insufficient hashing.




-Ilari

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

Re: [TLS] Trust Expressions Follow-up

[Ilari Liusvaara]

On Fri, Jan 26, 2024 at 12:52:44PM -0500, David Benjamin wrote:
> On Fri, Jan 26, 2024 at 5:15 AM Ilari Liusvaara 
> wrote:
> 
> > On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote:
> > >
> > > Second, I wanted to take a step back and try to better articulate our
> > > goals. I think the best way to look at this draft is in three parts:
> > >
> > > 1. A new multi-certificate deployment model (the overall goal)
> > >
> > > 2. Selecting certificates within that model (the TLS parts of the draft)
> > >
> > > 3. Provisioning certificates (the ACME parts of the draft)
> >
> > I think a bit differently:
> >
> > a. What information does the server have, what information it
> > dynamically receives from the client?
> >
> > b. How does this drive certificate chain selection?
> >
> > c. How the information from client is encoded?
> >
> > d. How the information server has is provisioned?
> >
> >
> > The reason for splitting it this way is that b., c. and d. are all
> > important problems, all three depend on a., but only b. and c. are in
> > remit of TLS. Oh, and I regard d. as formidable challenge, by far the
> > most difficult part.
> >
> 
> Ah sure. I was mostly thinking a step before that split. From Prague, I got
> the sense it'd be useful to focus the initial discussion about why a
> multi-certificate model is useful, and perhaps the high-level shape of the
> solution, separate from hashing out the protocol details. I suspect if
> "what are we trying to do and why" vs "here's how to provision the server"
> are lumped into one discussion thread, it'll be very difficult to keep
> track of things. Also the former seems more useful for questions like
> whether to adopt, while the latter seems like something we can hash out
> later.

As note, there are already some certificate negotiation stuff in TLS,
and some servers already support choosing among multiple certificates
based on those.


> Beyond that, my division between 2 and 3 was perhaps a bit sloppy
> there, yeah. I was just trying to capture that we've been focusing a bit
> less on the ACME bits for now. Not because they aren't important or tricky,
> but because I think they're not *strongly* impacted by the rest of the
> design. "Some way to get multiple certs" and "some metadata to attach to
> the certs" is a pretty general thing to design for. Maybe some variability
> around whether we need to believe metadata update and certificate refresh
> are the same operation or different.

There is already means in ACME to get multiple certificates: Making
multiple orders.

And I think that on ACME level the metadata should be associated with
issuer chains instead of certificates.

It is up to server to convert that to certificate chain metadata, if
that is more convinient for the server.


> > The thing that makes provisioning challenging is that there is fourth
> > party involved: Application terminating TLS on server side.
> >
> > I am not aware of any current (I know one that existed in the past)
> > deployments that have ACME client software directly interface with TLS
> > software.
> >
> > And I have never encountered application configuration interface I could
> > easily see how to make it work with something like this. Most because
> > certificate lists are either static or unordered.
> >
> > A more reduced scope that is likely feasible with more applications is
> > selecting among chains for single end-entity certificate. However, such
> > restrictions do not affect the TLS-visible parts.
> >
> 
> Yeah the ACME client <-> server configuration interface is definitely on
> the interesting side. I think it's more important to preserve the graph of
> what components talk to each other (i.e. the operational considerations),
> than to preserve the exact interfaces between them. Obviously, the less we
> have to change, the better, but I think it's also okay to have to extend
> those interfaces if push comes to shove.

It is requiring drastic changes to interfaces when things get bit sticky.

Example of (relatively) easy problem:

One has unordered set of N>1 certificate chains all passing feasible
candidate filtering. Which of those chain to chose to send, deadline is
in less than a millisecond?

 
> And yeah, reduced-scope versions for some cases could also be useful.
> Although the single-leaf restriction does remove a lot of the flexibility
> that we'd otherwise afford the server operator, so I think we should still
> design for the general case.

I would argue that ACME should assume single-leaf, and then software
running 

Re: [TLS] Trust Expressions Follow-up

[Ilari Liusvaara]

On Thu, Jan 25, 2024 at 05:00:19PM -0500, David Benjamin wrote:
> 
> Second, I wanted to take a step back and try to better articulate our
> goals. I think the best way to look at this draft is in three parts:
> 
> 1. A new multi-certificate deployment model (the overall goal)
> 
> 2. Selecting certificates within that model (the TLS parts of the draft)
> 
> 3. Provisioning certificates (the ACME parts of the draft)

I think a bit differently:

a. What information does the server have, what information it
dynamically receives from the client?

b. How does this drive certificate chain selection?

c. How the information from client is encoded?

d. How the information server has is provisioned?


The reason for splitting it this way is that b., c. and d. are all
important problems, all three depend on a., but only b. and c. are in
remit of TLS. Oh, and I regard d. as formidable challenge, by far the
most difficult part.


> We’d most like to get consensus on the first, as it’s the most important.
> Trust expressions are a way to achieve that goal, but we’re not attached to
> the specific mechanism if there’s a better one. 

Well, I certainly do not have ideas for solving the problem that are
dramatically different from what is in there currently. 


> The aim is to get to a more flexible and robust PKI, by allowing servers to
> select between multiple certificates. To do this, we need a way for the
> servers to reliably select the correct certificate to use with each client.
> In doing so, we wish to minimize manual changes by server operators in the
> long run. Most ongoing decisions should instead come from TLS software,
> ACME client software, and ACME servers.

The thing that makes provisioning challenging is that there is fourth
party involved: Application terminating TLS on server side.

I am not aware of any current (I know one that existed in the past)
deployments that have ACME client software directly interface with TLS
software.

And I have never encountered application configuration interface I could
easily see how to make it work with something like this. Most because
certificate lists are either static or unordered.

A more reduced scope that is likely feasible with more applications is
selecting among chains for single end-entity certificate. However, such
restrictions do not affect the TLS-visible parts.


> Why does this matter? PKIs need to evolve over time to meet user security
> needs: CAs that add net value to the ecosystem may be added, long-lived
> keys should be rotated to reduce risk, and compromised or untrustworthy CAs
> are removed. Even a slow-moving, mostly aligned ecosystem is still made of
> individual decisions that roll out to individual clients. This means,
> whether we like it or not, trust divergence is a fact of life, if for no
> other reason than out-of-date clients in the ecosystem. These clients could
> range from unupdatable TV set-top boxes to some IoT device to a browser
> that could not communicate with its update service.

Or worse, SCADA systems. Unupdatable *and* very long-lived.


> Now, some of these problems can be addressed with cross-signs between CAs,
> but this is a partial solution at best. Without negotiation, this still
> means sending certificates for the lowest common denominator to all
> clients. This wastes bandwidth, particularly with post-quantum
> cryptography, where every signature costs kilobytes. Additionally, an
> individual server operator cannot unilaterally configure this. Cross-signs
> apply to entire intermediate CAs, not just the individual server’s
> certificate.

Also, having certificate negotiation lets one in most cases drop
intermediates, saving a chunk of bandwidth (e.g., Let's Encrypt RSA
intermediate is 1306 bytes.)




-Ilari

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

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Ilari Liusvaara]

On Thu, Jan 11, 2024 at 01:58:07PM -0600, Orie Steele wrote:
> Hybrids by their very nature are the explosion.
> 
> If there will only ever be X-Wing, I think it's fine to not make it generic
> (since we admit that it is a special case, not an instance of a generic).
> 
> However, if B-Wing (brainpool + kyber) and P-Wing (p curve + kyber) also
> end up getting made, we never stopped the explosion, and we made it harder
> to evaluate the security properties, and we delayed the rollout against
> harvest and decrypt... for the cases where X-Wing could not fit.
> 
> Yes, we will need proofs for all those other hybrids, sounds like that will
> keep people busy for a while... It feels like promising false hope to say
> that making X-Wing not generic will stop all that other work from
> happening... If anything, making X-Wing generic will reduce the cost of
> doing the work, that seems inevitable at this point.
> 
> I do think it's important for this to not end up as "crabs in a bucket",
> where each candidate holds the others back, and then they all get cooked
> together.
> 
> If arguing over generic's causes that, I suggest we not make generics a
> requirement.

It is actually worse than that.

It seems hard to make generic composition mechanism that explodes only in
its components, not in protocols as well.

That is, it probably will not be better than the mess that exists now.

Even having low and high variants for each of x, p and b curves would
only be 6 KEMs. There are more protocols than that interested in hybrid
KEM stuff.

Plus I am not aware of any protocol where consensus is that generic
composition is a great idea, let's do that.




-Ilari

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

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

[Ilari Liusvaara]

On Tue, Jan 16, 2024 at 08:49:24AM -0800, Eric Rescorla wrote:
> On Tue, Jan 16, 2024 at 8:24 AM D. J. Bernstein  wrote:
>
> > To be clear, I think other concerns such as efficiency _can_ outweigh
> > the advantages of unification, but this has to be quantified. When I see
> > a complaint about "hashing the typically large PQ ciphertexts", I ask
> > how this compares quantitatively to communicating the ciphertexts, and
> > end up with a cost increment around 1%, which is negligible even in the
> > extreme case that the KEM is the main thing the application is doing.
> >
> 
> Responding to Dan but really this is a question to the draft authors. Do
> you agree with Dan on the approximate overhead here?

I am not one of draft authors, but I tried to estimate the overhead and
ended up with in ballpark of 7%.




-Ilari

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

On Mon, Jan 08, 2024 at 11:52:53AM +0100, Hannes Tschofenig wrote:
> 
> Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara:
> 
> Your design proposal below is nice but the number of messages make it
> less attractive (even though the use of this mechanism is likely for
> devices where performance and bandwidth is less of an issue).

I think the number of messages is the smallest possible for
bidirectional fresh key exchange over reliable channel (3 for non-
crossed, 4 for crossed).

However, there are some bandwith improvements:

- In crossed case if groups match and group is symmetric (not PQC),
  then both sides immediately ack. Saves 2 key shares.
- In crossed mismatch/asymmetric case, one side drops the request,
  and other handles it as non-crossed. Saves 1 server key share.

AFAICT, after that, there are no more pareto improvements.


The flows are (with server responding):

<-- request -->
<-- ack -->

and

<-- request -->
<-- response
ack -->


However, this might not work at all in unreliable case (DTLS).
Especially the symmetric crossed case, but even in the asymmetric
case request getting delayed until after key exchange completes
could cause nasty issues.




-Ilari

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

On Fri, Jan 05, 2024 at 03:11:37PM +, Fries, Steffen wrote:
> Hi David,
> 
> In addition to what Hannes stated, the alternative in Appendix B was
> the result of further thoughts on potential alternatives keeping the
> single shot approach of the keyUpdate in TLS 1.3.
> 
> The intension was to have an ephemeral-static DH exchange, which uses
> the previously used DH key of the receiver R and an ephemeral DH
> parameter for the sender S in the ExtendedKeyUpdate. That way, both
> sides can immediate generate a new session key without any
> interruption. The receiver R may then directly react with a
> ExtendedKeyUpdate utilizing the updated DH key of S and an own
> ephemeral DH key for R.  That way both sides have stepwise contributed
> an ephemeral DH part. As the ExtendedKeyUpdate messages are
> independent, application data may still be exchanged in between,
> without introducing waiting time.
> 
> While keeping the single shot feature, this approach would have the
> disadvantage, that the last received DH key needs to be stored in
> cases it is needed for an ephemeral-static exchange. But this may be
> easier to handle.

Would that work with groups that are not DH (client and server shares
are not interchangeable)?

And would it work with implementations where there is hard constraint
that each key exchange may only be completed once?


I don't know if it would work for DTLS, but I did come up with design
with four different messages: request, response, ack and crossed.

- Request:
  * Has client key share.
  * Causes no key change.
  * MUST NOT be sent while pending handshake.
  * MUST NOT be sent while pending EKU.
  * Receiver responds with response if no pending EKU.
  * Receiver responds with crossed if pending EKU (will also
happen on the other side).
- Response:
  * Has server key share.
  * Causes forward key change.
  * Reverse keys calculated for install with ack.
  * Receiver responds with ack.
- Ack:
  * Does not carry key share.
  * Causes forward key change (to previously calculated keys).
  * EKU completed on send/receive.
- Crossed:
  * Has server key share.
  * Causes forward key change.
  * No reverse key change (done by other crossed EKU).
  * EKU completed on send/receive.

The possible flows are (all update keys in both directions):

A) Non-crossed, client initiated:
--- request -->
<-- response ---
--- ack -->

B: Non-crossed, server initiated:
<-- request ---
--- response -->
<-- ack ---

C: Crossed

<-- request -->
<-- crossed -->




-Ilari

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

On Thu, Jan 04, 2024 at 04:26:09PM +, Dennis Jackson wrote:
> From a security perspective, this would be equivalent to having the
> client open a new connection to the server using a session ticket from
> the existing connection with psk_dhe_ke mode?
> 
> I guess the ergonomics of that approach perhaps aren't as neat, but it
> would only require client side implementation changes and no spec or
> server-side changes to deploy.

Opening a new connection is rather distruptive in some applications,
even if done as make-before-break.

For example, if application ties some resources to existence of
connection, there would have to be some mechanism to transfer the
resources from old connection to new to avoid distruption from the
resources going away. And very few applications are capable of doing
that.




-Ilari

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

On Thu, Jan 04, 2024 at 04:33:30PM +0100, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> When exchanging key shares, the use of supported_groups is mandatory (at
> least that's what I remember).

Only for client, it is not mandatory for server.

RFC 8446 only says that servers "are permitted to send" supported_groups
and SHOULD send it if doing HRR because of missing group.


> > 
> > - The endpoint sending EKU with update_requested is the initiator for
> >groups that have asymmetric roles, right?
> 
> The client sends an EKU to the server in an attempt to update the
> traffic key for traffic sent from itself to the server. If it also
> wants to trigger the server to update the traffic keys in the reverse
> direction, namely from the server to the client, it needs to set the
> update_requested flag. Then, the server will have to trigger a
> separate exchange.

There are groups where it is not possible for client to tell crossed EKU
request from EKU reply from the key share itself, and things go south if
it processes crossed EKU requesst as EKU reply.

Milder version of that is groups that have incompatble client and server
key shares, but those can be identified from length. 

I don't think having just update_requested/update_not_requested flag
is sufficient. Non-crossed bidirectional update needs three-way (with
two or four key shares), and the crossed case needs to be handled (with
four key shares).




-Ilari

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Ilari Liusvaara]

On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
> Hi all,
> 
> we have just submitted a draft that extends the key update
> functionality of TLS/DTLS 1.3. We call it the "extended key update"
> because it performs an ephemeral Diffie-Hellman as part of the key
> update.
> 
> The need for this functionality surfaced in discussions in a design
> team of the TSVWG. The need for it has, however, already been
> discussed years ago on the TLS mailing list in the context of long-
> lived TLS connections in industrial IoT environments. Unlike the TLS
> 1.3 Key Update message, which is a one-shot message, the extended Key
> Update message requires a full roundtrip.
> 
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

Some quick comments:

- The supported_groups in EE is optional. The group used in initial
  handshake is always considered supported, right?

- I can't quite parse what is going on in figure 3. 

- The endpoint sending EKU with update_requested is the initiator for
  groups that have asymmetric roles, right?

- Crossed extended key update with DTLS sounds complicated enough that
  there should be an argument it works even with various message loss
  or reordering patterns.

- TLS 1.3 limits labels in key schedule to 12 bytes (so that all the
  data fits into SHA256 block), but the label used here appears to
  be 13 bytes.




-Ilari

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

Re: [TLS] Questions about RFC 5929 (channel bindings)

[Ilari Liusvaara]

On Tue, Dec 26, 2023 at 09:48:32PM +0900, Kazu Yamamoto (山本和彦) wrote:
> Hi,
> 
> I'm trying to implement channel bindings defined RFC 5929.
> I have three questions:

Also note RFC 9266. That defines how to perform SCRAM/GSS-API with TLS
1.3.


> Q2) Can "tls-server-end-point" apply to TLS 1.3?

It could be appiled, but that is probably not a good idea.

For SCRAM and GSS-API, "tls-server-end-point" is not used in TLS 1.3.


> Q3) If the answer to Q2 is yes, which part is hashed?
> 
> RFC 8446 defines Certificate as:
> 
>  struct {
>   opaque certificate_request_context<0..2^8-1>;
>   CertificateEntry certificate_list<0..2^24-1>;
>   } Certificate;
> 
>
>hash(Certificate) or hash(Handshake:Certificate) or
>hash(certificate_list)?

I don't think it is specified anywhere, but I think the most reasonable
thing is neither of those, but instead re-encoding the certificate_list
into TLS 1.2 form and hashing that. So the resulting binding values are
compatible with TLS 1.2.




-Ilari

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

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

[Ilari Liusvaara]

On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> 
> Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> change.  I’ll wait until/if this is adopted by the WG to merge it.

Reading through the document, I noticed the following:

"To securely deploy TLS 1.2, either renegotiation must be disabled
entirely, or this extension must be present." (where this extension
means renegotiation_info)


Entirely disabling renegotiation is not sufficient to fix the
renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
MUST be required both ways.

And then there is the other part to the triple handshake attack where
using TLS exporters for authentication without extended_master_secret
extension is insecure, even if renegotiation is not supported at all
by either side and both sides implement renegotiation_info.

And then there is more dangerously flawed stuff, e.g., session tickets
(technically an extension).




-Ilari

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

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[Ilari Liusvaara]

On Wed, Dec 06, 2023 at 03:46:32PM +, John Mattsson wrote:
> That sounds great.
> 
> Who is doing the work of adding “for TLS 1.3 and later”?
> 
> My understanding is that the currently registered TLS 1.3 cipher suites are:
> 
> Value Description
> 0x13,0x01 TLS_AES_128_GCM_SHA256
> 0x13,0x02 TLS_AES_256_GCM_SHA384
> 0x13,0x03 TLS_CHACHA20_POLY1305_SHA256
> 0x13,0x04 TLS_AES_128_CCM_SHA256
> 0x13,0x05 TLS_AES_128_CCM_8_SHA256
> 0x13,0x06 TLS_AEGIS_256_SHA512
> 0x13,0x07 TLS_AEGIS_128L_SHA256
> 0xC0,0xB0 TLS_ECCPWD_WITH_AES_128_GCM_SHA256
> 0xC0,0xB1 TLS_ECCPWD_WITH_AES_256_GCM_SHA384
> 0xC0,0xB2 TLS_ECCPWD_WITH_AES_128_CCM_SHA256
> 0xC0,0xB3 TLS_ECCPWD_WITH_AES_256_CCM_SHA384
> 0xC0,0xB4 TLS_SHA256_SHA256
> 0xC0,0xB5 TLS_SHA384_SHA384
> 0xC1,0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
> 0xC1,0x04 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
> 0xC1,0x05 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
> 0xC1,0x06 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S


Also,

0x00,0xC6 TLS_SM4_GCM_SM3
0x00,0xC7 TLS_SM4_CCM_SM3 

Both are explicitly flagged as not OK for DTLS. However, using GCM/CCM
in usual way, so not difficult to define how those would work in DTLS
or QUIC (just copy what AES-128 does there).


> Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some
> cipher suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2,
> TLS 1.3, DTLS 1.2 but not DTLS 1.3….

If the _ECCPWD_ ones work for TLS 1.3, why wouldn't those work for DTLS
1.3 or QUIC? Those ciphersuites use AES in standard way, and DTLS/QUIC
do serialize the flights.


> Do we need some guidance/requirements on naming and use of TLS 1.3
> cipher suites? The _ECCPWD_ ones seem to include authentication in
> the TLS 1.3. The _GOSTR341112_ seems to include authentication and
> key exchange…. I did not think this was how TLS 1.3 cipher suites
> were supposed to be used.

Well, _ECCPWD_ is just special snowflake as it modifies the key
exchange (I haven't checked if what it does actually works). The GOST
ciphers do not seem to do anything special with key exchange (unlike
other things like seemingly rekeying for every record), so those
presumably should just be TLS_KUZNYECHIK_* and TLS_MAGMA_*.

The rekey-every-record the GOST ciphers do could pose a problem for
defining a mapping to DTLS or QUIC... Unless doing it like AES-GCM
was added to SECSH (a.k.a. SSH).




-Ilari

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Ilari Liusvaara]

On Tue, Dec 05, 2023 at 06:24:33PM -0800, Christian Huitema wrote:
> 
> Yes. Both are used to compute the "early secret" -- external PSK for the
> initial handshake, resumption PSK in subsequent handshakes. If the secrets
> are "short" and the attacker can use early data as some kind of oracle, then
> the attacker can probably crack the PSK for the initial handshake, or the
> resumption PSK in subsequent handshakes. If the PSK is cracked, it probably
> does not add much effective entropy to the key computed via the [EC]DH + PSK
> combination.

AFAICT, If the PSK is too weak, then the attacker can crack it using the
binder, no need for any early data.




-Ilari

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

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

[Ilari Liusvaara]

On Thu, Nov 09, 2023 at 08:48:07AM +, John Mattsson wrote:
> 
> Everybody seem to agree that hybrids should be specified. Looking in
> my crystal ball, I predict that registering hybrids as code points
> will be a big mess with way too many opinions and registrations
> similar to the TLS 1.2 cipher suites. The more I think about it, the
> more I think TLS 1.3 should standardize a generic solution for
> combining two or more key shares.

I don't think future hybrids in TLS will be anything even close to the
mess that TLS 1.2 ciphersuites are.


> My understanding of what would be needed:
> 
> - New "split_key_PRF" extension indicating that client supports
>   split-key PRF.
> 
> - When "split_key_PRF" is negotiated the server may chose more than
>   one group/key share.

The one part that could be problematic is multiple choices for classical
group to hybrizide with. That could be addressed with share compression
in client hello.

Probably simplest such scheme is allowing replacing first/second part of
share with group number, and then copying that share from start/end of
the referenced share.




-Ilari

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

Re: [TLS] Request mTLS Flag

[Ilari Liusvaara]

On Mon, Oct 23, 2023 at 01:37:55PM -0400, Viktor Dukhovni wrote:
> 
> - Some Java TLS libraries (used to?) fail the handshake when the
>   client has no configured certs, or the list of issuer CA DN hints
>   does include any of its available (typically just zero or one)
>   certificates.
> 
>   They could just proceed without a certificate, or return a default
>   one, but they don't.

A colleague discovered a case where sending CertificateRequest to Chrome
causes it to fail, instead of just proceeding without a certificate
(which would have worked).




-Ilari

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

Re: [TLS] Request mTLS Flag

[Ilari Liusvaara]

On Mon, Oct 23, 2023 at 12:26:03PM -0400, David Benjamin wrote:
> > So in my mind this is something that will (almost) never be sent by
> browsers.
> 
> What cases would the "(almost)" kick in? This extensions model just doesn't
> match how client certificates work in browsers. I'm not seeing any
> interpretation beyond "always send" or "never send".

Explicit configuration to send this for some names/domains.

Needed for some "enterprise" use cases (can also pop up in much smaller
corporate contexts).




-Ilari

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

Re: [TLS] Updated AuthKEM drafts

[Ilari Liusvaara]

On Tue, Nov 07, 2023 at 08:00:57AM +0100, Thom Wiggers wrote:
> Hi Peter,
> 
> The KEM used for authentication indeed needs to be IND-CCA secure,
> but so does the KEM for ephemeral key exchange (IND-1CCA, at least).
> The TLS key schedule should ensure that this all goes correctly, if
> I recall the discussion on the concatenation of the secrets and
> is-HKDF-a-dual-PRF discussion.

I thought key exchange only needs absolute minimum to avoid trivial
breakage (one-wayness)?

Authentication indeed needs IND-CCA.


> But AuthKEM currently tries to build on HPKE, and I think the HPKE
> draft intends to give IND-CCA security.

>From reading HPKE RFC, it seems weird.

I thought that HPKE intends to guarantee IND-CCA2, however, I can
not find a requirement for KEM part to be IND-CCA2 secure (all the
other parts yes). And if the KEM is not IND-CCA2, the whole HPKE
will not be either.

And there is some text that seems to say that there is no proof
that IND-CCA2 security of KEM impiles IND-CCA2 security of HPKE
(but one would expect that to hold)?

But this might be just me reading the thing wrong.




-Ilari

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Mon, Oct 23, 2023 at 03:04:05PM -0400, David Benjamin wrote:
> 
> The note about sharing an EE cert is just a SHOULD, not a MUST. RFC 8555
> doesn't say why, but our interpretation was, like you note, this was mostly
> a concern for things like accounting for renewals and revocations. We tried
> to firm that up a bit by saying this makes sense when you're willing to
> issue and renew all the variants together. For something like ARI, I was
> imagining the ACME client would just check all of them (we're already
> assuming the ACME client has been updated) and, if it needs to renew any of
> them, it goes ahead and renews all of them. Slightly wasteful if renewal
> was triggered by one of them getting revoked, rather than them all expiring
> together. But I expect that's not common enough to be worth optimizing for.

I think ACME client are expected to pick one of the alternates and
discard the rest.

 
> Do you think multiple orders would be better? A multi-order flow is
> probably more complex than fits in this document (this ACME change is
> pretty small), so we didn't start with it. Plus this initial version seemed
> natural to us based on what ACME had already defined. But we're much more
> interested in making this kind of multi-certificate deployment model
> possible than any of the particular details. Happy to adjust things based
> on what turns out to work best. (One nuisance with a multi-order flow is
> that the CA will have a harder time linking the requests together, which
> opens a can of worms around whether they do separate validations or not.)

Multi-order flow is no more complex for ACME. It is also just requesting
extended information.

However, I think that the design space is severly constrained by TLS
server configuration. I do not think any TLS server is capable of
handling either flow without drastic changes to how certificate
configuration works.

What I think could work is shipping one certificate with its default
issuer chain, plus alternate chains with trust expression info, all
in one package. This would avoid the highly problematic variable
grouping of certificates.

When using certificate, the TLS server could select a certificate and
then change to alternate chain depending on the RP support.

 
> I think having to do a round of updating existing clients is fine here.
> We'd already need to teach them to implement this thing. But if we think
> putting them in one bundle is more convenient, that's fine by me too. I
> don't actually care.

I think that depending on the design, the TLS server changes may be less
than fine.

And at simplest designs, the ACME client changes could be just adding
accept to certficate fetches and updating the type whitelists to accept
the chain override info.

 
> Exploring that direction a bit, won't that make issues around ARI and
> different issuance rates worse? Bundling them means the system is further
> inclined to treat them as one unit, but a lot of these problems come from
> wanting to be able to treat each path separately, be it different renewal
> times, different issuance times, potentially even different private keys
> associated, etc. I also worry it'll get a bit thorny as it passes through
> the layers. E.g. if the TLS serving software expects one PEM file to be one
> certificate chain, but the TLS library secretly turns it into multiple
> alternative chains, the rest of the logic will break. (E.g. imagine if the
> serving software knows to set up OCSP stapling or otherwise associate data
> with the cert it's serving.)

Normal OCSP and SCT will work just fine even if TLS library secretly
turns PEM files into multiple chains. The stuff that would break is
quite exotic (e.g., multi-OCSP). And I expect vast majority of even
such exotic stuff to work okay if TLS library just drops all the
problematic stuff on chain override (e.g., downgrading multi-OCSP to
normal OCSP).

In contrast, if there are multiple distinct certificates or chains,
those need to be handled as unit. Which is not something present TLS
servers are capable of doing, because nothing else requires that.

 
> Ah, this is "expiry" in the sense of actually removing the root from v2?
> I.e. distinct from what our draft (somewhat confusingly) calls expiry. (Our
> "expiry" relates to this cross-version issue.)

Expiry in sense of removing the root from all versions.

I have heard some roots are considering limiting the root certificate
lifetime. So individual root programs might have different expiry
date from the one contained in the root certificate (and there may be
multiple versions of the same root with different lifetimes!). 

 
> Yeah, we don't have that right now. Though I think most cases don't need
> explicit expiry information. Since this is used for negotiation, not trust,
> it doesn't actually matter if v2 contains some roots that have expired, as
> long as both RP and CA agree on when this happens. I.e. *for negotiation
> purposes*, it makes no difference whether 

Re: [TLS] Fw: New Version Notification for draft-ietf-tls-ctls-09.txt

[Ilari Liusvaara]

On Tue, Oct 24, 2023 at 06:05:27PM +, Ben Schwartz wrote:
> Hi TLS,
> 
> We've just uploaded a new revision of the cTLS draft.  The most
> exciting change in this revision is an additional informative
> reference to Comparse [1], a new formal verification system. 
> The Comparse paper includes a security proof of cTLS (and also
> TLS and MLS).  This revision also includes some slight
> configuration changes that were made in support of that formal
> analysis.
> 
> --Ben Schwartz
> 
> [1] https://eprint.iacr.org/2023/1390
> 
> 
> 
> A new version of Internet-Draft draft-ietf-tls-ctls-09.txt has been
> successfully submitted by Benjamin Schwartz and posted to the
> IETF repository.
> 
> Name: draft-ietf-tls-ctls
> Revision: 09
> Title:Compact TLS 1.3
> Date: 2023-10-23
> Group:tls
> Pages:26
> URL:  https://www.ietf.org/archive/id/draft-ietf-tls-ctls-09.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/
> HTML: https://www.ietf.org/archive/id/draft-ietf-tls-ctls-09.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls
> Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-ctls-09

Quick review:


Section 2.1.1.4.:

- Messed up list in last paragraph.

Section 2.1.1.5.:

- Looks like the previous last paragraph did not get removed.
- Messed up list in last paragraph.

Section 2.1.1.6.:

- On open issue, TLS 1.3 does not directly use the randoms for anything,
  so such hashing implicitly already happens.

Section 2.1.1.9.:

- On certificate_entry_extensions element, I think that if one wanted
  something here, a threestate flag would be sufficient:

  * No extension fields
  * Extension field only on first certificate
  * Extension fields on all certificates.

  (If certificate extensions are used, most commonly those are on the
  first certificate only.)

Section 2.3.1.:

- I don't see it stated anywhere that CTLSHandshake is used for reliable
  transports, and CTLSDatagramHandshake for unreliable transports.

Section 2.3.3.:

- On random values being extended, are those actually used for anything?

Section 6.1.:

- What is the ctls content type used for?
- And thinking about it, how should unencrypted alert be formatted?




-Ilari

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

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote:
> Thanks for the comments! Responses inline.
> 
> On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara 
> wrote:
> 
> > Some quick thoughts:
> >
> > - The multiple certificates from one ACME order really scares me. It
> >   seems to me that can lead to all sorts of trouble.
> >
> 
> Certainly open to different mechanisms, though could you elaborate on
> the trouble? We started with this one because it's actually just fixing a
> mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:
>
>The server MAY provide one or more link relation header fields
>[RFC8288] with relation "alternate".  Each such field SHOULD express
>an alternative certificate chain starting with the same end-entity
>certificate.  This can be used to express paths to various trust
>anchors.  Clients can fetch these alternates and use their own
>heuristics to decide which is optimal.

Note the part "the same end-entity certificate.". The way I interpretted
the draft, returning different end-entity certificates would be allowed.


> Whether anyone has ever used this, I don't know. The "and use their own
> heuristics to decide which is optimal" bit is quite absurd. :-) Relative to
> that, all we've done is:

Yes, that gets sometimes used.


> But I suspect we'll want to define one where you make multiple orders too.
> That would probably work better for, e.g., Merkle Tree certs where the two
> issuances complete at very different times. But then, conversely, when the
> two paths actually share an end-entity certificate, I imagine a single
> order would be better so the CA knows it only needs to generate one
> signature. And then when they don't share an end-entity certificate but are
> similar enough in lifetime and issuance time, either seems fine, so we
> figured this was a reasonable starting point.

Well, I do not think it is feasible to use the normal ACME issuance
mechanism for Merkle Tree certificates. The issuance is just too slow.

And things like ACME ARI (which is required for actually handling
revocations) inherently assume each order can only result one 
certificate.
 
 
> > - If there can be only one certificate, one could send all the chains
> >   in one go via fist sending the certificate, then issuer chains each
> >   ended by entry describing the trust anchor.
> >
> 
> I'm not quite sure if I've parsed this right, but are you thinking of one
> file that somehow describes all alternatives together? That's plausible
> too. Like I said, we mostly did this one because ACME already did it, so we
> inferred that was The ACME Way. :-)

Yes, one file describing all alternatives together. I think that is
easier to work with than the existing alternatives mechanism (I don't
think most clients even support that).


> > - I am not sure this is useful for the client->server direction.
> >
> 
> Eh, it costs ~nothing to define it in both directions, just a global
> s/client/relying party/ and s/server/subscriber/ across the document. :-) I
> figure we may as well define it in both directions, and if some client
> certificate deployments find it useful, cool. On the Chrome side, if the
> operating systems could give us something like this, with pre-made paths
> and unambiguous rules for when to send each, I would be overjoyed. We spend
> quite a lot of time helping people debug misconfigurations and quirks
> around client certificate selection.

How useful it is is different from how difficult it is to specify. :-)


> > What I think is a simpler version that might work:
> >
> >
> > Information from root program to CA:
> >
> > - Root program name.
> > - For each trust anchor:
> >   * Trust anchor certificate.
> >   * First version TA appeared in.
> >   * Expiry time
> >   * List of indices.
> >
> > Indices can be reused after all TAs using those have expired.
> >
> >
> > Information from CA to TLS server for each TA:
> >
> > - For each root program:
> >   * Root program name
> >   * The first version TA appeared in.
> >   * List of indices.
> >
> > CA MUST NOT include entries that expire before the certificate.
> >
> >
> > Information from TLS client to TLS server:
> >
> > - Root program name.
> > - Root program version.
> > - List of revoked indices.
> >
> > The revoked indices specifies TAs that have been recently removed
> > before expiry (there could still be unexpired certificates out
> > there).
> >
> >
> > Chain is usable if it includes an entry where:
> >
> > a) Root program name matche

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Thu, Oct 19, 2023 at 11:38:33AM -0400, David Benjamin wrote:
> Hi all,
> 
> We just published a document on certificate negotiation. It's a TLS
> extension, which allows the client to communicate which trust anchors it
> supports, primarily focused on use cases like the Web PKI where trust
> stores are fairly large. There is also a supporting ACME extension, to
> allow CAs to provision multiple certificate chains on a server, with enough
> metadata to match against what the client sends. (It also works in the
> other direction for client certificates.)
> 
> The hope is this can build towards a more agile and flexible PKI. In
> particular, the Use Cases section of the document details some scenarios
> (e.g. root rotation) that can be made much more robust with it.
> 
> It's very much a draft-00, but we're eager to hear your thoughts on it!

Some quick thoughts:

- The multiple certificates from one ACME order really scares me. It
  seems to me that can lead to all sorts of trouble.
- If there can be only one certificate, one could send all the chains
  in one go via fist sending the certificate, then issuer chains each
  ended by entry describing the trust anchor.
- The latest version and previous version stuff seems pretty confusing
  to me.
- I am not sure this is useful for the client->server direction.



What I think is a simpler version that might work:


Information from root program to CA:

- Root program name.
- For each trust anchor:
  * Trust anchor certificate.
  * First version TA appeared in.
  * Expiry time
  * List of indices.

Indices can be reused after all TAs using those have expired.


Information from CA to TLS server for each TA:

- For each root program:
  * Root program name
  * The first version TA appeared in.
  * List of indices.

CA MUST NOT include entries that expire before the certificate.


Information from TLS client to TLS server:

- Root program name.
- Root program version.
- List of revoked indices.

The revoked indices specifies TAs that have been recently removed
before expiry (there could still be unexpired certificates out
there).


Chain is usable if it includes an entry where:
 
a) Root program name matches, AND
b) Root program version is at least the first version, AND
c) Intersection of indices and revoked indices is empty.

If TLS server has multiple configured certificates, it should skip ones
that have no usable chains. If no certificate has usable chain, it
should act like the extension was not sent.



> -- Forwarded message -
> From: 
> Date: Thu, Oct 19, 2023 at 11:36 AM
> Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
> To: Bob Beck , David Benjamin , Devon
> O'Brien 
> 
> Name: draft-davidben-tls-trust-expr
> Revision: 00
> Title:TLS Trust Expressions
> Date: 2023-10-19
> Group:Individual Submission
> Pages:35
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr
 



-Ilari

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

Re: [TLS] I-D Action: draft-ietf-tls-cert-abridge-00.txt

[Ilari Liusvaara]

On Wed, Sep 06, 2023 at 07:39:12AM -0700, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-tls-cert-abridge-00.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-00.txt
>Pages:   19
>Dates:   2023-09-06

Doing quick review:

Section 3.1.2:

- It is not clear what exactly is replaced if cert_data is known.
  Obviously overriding the length field would be more compact, but it
  also can be interpreted as replacing the value, wasting 3 bytes.

  (Reminds me of RFC 8879, which is not clear about similar things.)

- CertificateEntry and Certificate length fields are just waste of
  space, since both can be recovered in other ways when decoding.

- RFC 8879 does not allow ignoring unrecognized three-byte identifiers.
  Instead, the connection MUST be terminated with bad_certificate alert.

  This has consequence that any client that can ever add a custom trust
  anchor via any means must have the complete certificate list (whereas
  partial list would be enough if no custom trust anchors can ever be
  added).

  And I find the last comment about transcript validation failing very
  scary.


Section 3.2.:

- Using alternate scheme could result drastically reduced implementation
  complexity.

  Furthermore, one can't even use standard zstd decoder with this due to
  security reasons. One needs special one (but seems like reference zstd
  library ships that as alternative API).


Section 3.2.1.:

- I suspect that having CA-specific dictionaries would make it much
  easier to be equitable and improve compression.

  Then I don't think the dictionary construction method is good:
 
  * Using just one certificate is very dubious.
  * It is more optimal to consider byte substrings with no structure.

Section 3.2.1.1.:

- Caching monolithic compression from startup does not work because of
  extension fields.

  For caching to work, one would have to compress the certificate
  entries independently and leave the extension fields in between
  uncompressed.

Section 5.1.:

- I think the argument about adding roots taking time is flawed. Roots
  are usually not even included in the chain, but intermediates are,
  and can change much faster.

  I remember seeing one CA that judging from naming of the intermediate
  rotated it every 6 months.


Section 5.4:

- I think the current complexity as I understand the draft is just
  scary.

  I consider not being able to adjust extension fields in the fly to
  be a hard blocker (that is already a hard blocker for implementing
  RFC 8879 sending side).

 


-Ilari  

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

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

[Ilari Liusvaara]

On Tue, Aug 01, 2023 at 03:35:47PM -0400, 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. 

Adopt.

Even if this draft has major unresolved issues, it is a decent starting
point to explore the idea (which might or might not turn out to work at
the end).




-Ilari

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

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
> 
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> >
> > And an alternative idea:
> > 
> > [...]
> > 
> > 1) Where if next certificate in chain is also not found, zstd uses
> > empty dictionary. Otherwise it uses dictionary associated with the
> > next certificate in chain.
> > 
> > [...]
> > 
> > This allows dictionaries to be specific to CA, avoiding tradeoffs
> > between CAs.
> 
> Interesting idea! Can you share more about the motivation for using many
> small dictionaries rather than a single combined one? Is it purely for
> supporting memory constrained devices? We can already ensure that each CA
> contributes an equal number of bytes to the pass 2 dictionary.
> 
> One drawback is that some of the data isn't unique to a particular issuer
> (e.g. the CT log ids) and so would either have to be handled in its own pass
> or be included as redundant data in each individual dictionary.

Actually, I don't think this idea would work well: Clients would still
need at least all the dictionaries for end-entity certificates, for the
case where server certificate is from unknown CA and certificate
validation is overridden.

Because to comply with TLS 1.3 requirements (CV validation is required),
the client needs the server signature key, which is embedded in server
certificate, which in turn needs dictionary to decompress.

Altough I think it is technically possible to just skip CV validation,
allowing the decompression to be skipped. However, this breaks the
TLS 1.3 specification.




-Ilari

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

Re: [TLS] RFC 9345 on Delegated Credentials for TLS and DTLS

[Ilari Liusvaara]

On Thu, Jul 13, 2023 at 03:29:20PM -0700, rfc-edi...@rfc-editor.org wrote:
> A new Request for Comments is now available in online RFC libraries.
> 
> RFC 9345
> 
> Title:  Delegated Credentials for TLS and DTLS 
> Author: R. Barnes,
> S. Iyengar,
> N. Sullivan,
> E. Rescorla
> Status: Standards Track
> Stream: IETF
> Date:   July 2023
> Mailbox:r...@ipv.sx,
> sub...@fb.com,
> n...@cloudflare.com,
> e...@rtfm.com
> Pages:  17
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-ietf-tls-subcerts-15.txt
> 
> URL:https://www.rfc-editor.org/info/rfc9345
> 
> DOI:10.17487/RFC9345

Are there any known servers that support this (for quick interop check)?
All the test servers I have found (three) seem to have been shut down.




-Ilari

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

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:
> Hi Ilari,
> 
> On 10/07/2023 20:19, Ilari Liusvaara wrote:
> > What does "Note that the connection will fail regardless even if this
> > step is not taken as neither certificate validation nor transcript
> > validation can succeed." mean? TLS certificate compression does not
> > do anything special with transcript, so transcript validation should
> > always succeed.
> 
> TLS Certificate Compression influences the transcript for the decompressing
> party, as the output is the Certificate message which is used in the
> transcript. So if the Certificate message is incorrectly formatted, then the
> the decompressing party will likely bail when passing it to the TLS library.
> Even if they succeed and try to use it in a transcript calculation, the
> compressing party's transcript includes the uncompressed certificate
> directly and so will differ.

RFC 8879 does not alter how transcript is computed in any way.

An extension altering computation of transcript would be truly
extraordinary.

 
> > And are there zstd decoders that can reuse output buffer in oneshot
> > decompression for lookback? The zstd command line tool manual page
> > mentions default 128MB memory limit for decompression. I presume
> > mostly for lookback. Such limit is way too large.
> Zstd is already supported without a dictionary for TLS Certificate
> Compression so others with deployment experience may be able to give an
> authoritative answer. That said, Facebook's Zstd implementation is
> permissively licensed, used in the Linux Kernel and their discussion here
> <https://github.com/facebook/zstd/issues/2093> suggests much smaller limits
> are fine.

Actually, that issue pointed to the API I was looking for. And looks
like memory requirement is something like <300kB.


> > And an alternative idea:
> > 
> > [...]
> > 
> > 1) Where if next certificate in chain is also not found, zstd uses
> > empty dictionary. Otherwise it uses dictionary associated with the
> > next certificate in chain.
> > 
> > [...]
> > 
> > This allows dictionaries to be specific to CA, avoiding tradeoffs
> > between CAs.
> 
> Interesting idea! Can you share more about the motivation for using many
> small dictionaries rather than a single combined one? Is it purely for
> supporting memory constrained devices? We can already ensure that each CA
> contributes an equal number of bytes to the pass 2 dictionary.
> 
> One drawback is that some of the data isn't unique to a particular issuer
> (e.g. the CT log ids) and so would either have to be handled in its own pass
> or be included as redundant data in each individual dictionary.

I was assuming that including all the CA-specific stuff across all CAs
would cause the dictionary to grow quite large. And I think smaller
dictionaries that still have everything needed give slightly better
compression.

And it is possible to do constructions like dictionary = common_part ||
ca_specific_part. With possibly common_part being the dictionary used on
next certificate not found.





-Ilari

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

Re: [TLS] Abridged Certificate Compression

[Ilari Liusvaara]

On Thu, Jul 06, 2023 at 11:18:01PM +0100, Dennis Jackson wrote:
> Hi all,
> 
> I've submitted the draft below that describes a new TLS certificate
> compression scheme that I'm calling 'Abridged Certs' for now. The aim is to
> deliver excellent compression for existing classical certificate chains and
> smooth the transition to PQ certificate chains by eliminating the root and
> intermediate certificates from the bytes on the wire. It uses a shared
> dictionary constructed from the CA certificates listed in the CCADB [1] and
> the associated extensions used in end entity certificates.

What does "Note that the connection will fail regardless even if this
step is not taken as neither certificate validation nor transcript
validation can succeed." mean? TLS certificate compression does not
do anything special with transcript, so transcript validation should
always succeed.


And are there zstd decoders that can reuse output buffer in oneshot
decompression for lookback? The zstd command line tool manual page
mentions default 128MB memory limit for decompression. I presume
mostly for lookback. Such limit is way too large. 


And an alternative idea:

The compressed stream is concatenation of two kinds of certificate
entries:

1) If certificate is not found in dictionary:

   opaque zstd_compressed_cert<1..16711679>;
   opaque extensions<0..65535>;

   Where if next certificate in chain is also not found, zstd uses
   empty dictionary. Otherwise it uses dictionary associated with the
   next certificate in chain.

2) If certificate is found in dictionary:

   uint8 always_0xff = 255;
   uint16 dictionary_index;
   opaque extensions<0..65535>;
  
The overall length is not compressed, because compressed_certificate
message already has it.

This allows dictionaries to be specific to CA, avoiding tradeoffs
between CAs.


As illustration, minimal compressed certificate message for certificate
issued by Let's Encrypt E1:

- 4 byte message header.
- 2 byte compression algorithm.
- 3 byte uncompressed length.
- 3 byte length of EE certificate.
- X byte zstd compressed certificate using dictionary for Let's Encrypt
  E1.
- 2 byte extension block length.
- 0 byte extension block.
- 3 byte entry for Let's Encrypt E1.
- 2 byte extension block length.
- 0 byte extension block.
- 3 byte entry for ISRG Root X2.
- 2 byte extension block length.
- 0 byte extension block.

Total: 24 + X bytes.



> On 06/07/2023 23:11, internet-dra...@ietf.org wrote:
> > A new version of I-D, draft-jackson-tls-cert-abridge-00.txt
> > has been successfully submitted by Dennis Jackson and posted to the
> > IETF repository.
> > 
> > Name:   draft-jackson-tls-cert-abridge
> > Revision:   00
> > Title:  Abridged Compression for WebPKI Certificates
> > Document date:  2023-07-06
> > Group:  Individual Submission
> > Pages:  19
> > URL:
> > https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.txt
> > Status: 
> > https://datatracker.ietf.org/doc/draft-jackson-tls-cert-abridge/
> > Html:   
> > https://www.ietf.org/archive/id/draft-jackson-tls-cert-abridge-00.html
> > Htmlized:   
> > https://datatracker.ietf.org/doc/html/draft-jackson-tls-cert-abridge




-Ilari

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

Re: [TLS] AuthKEM: Splitting the draft and next steps

[Ilari Liusvaara]

On Wed, Jul 05, 2023 at 04:34:28PM +0200, Thom Wiggers wrote:
> 
> Op wo 5 jul 2023 om 14:22 schreef Ilari Liusvaara  >:
> 
> > On Wed, Jul 05, 2023 at 09:26:57AM +0200, Thom Wiggers wrote:
> > > Hi Ilari,
> >
> >   * The certificate being a message, it is subject to acknowledgements.
> > However, server hello must be logically before it. This is required
> > to meet the acknowledgment epoch rule.
> >   * The server flight needs to be broken into two just before server
> > Finished, first part being unordered with certificate, and second
> > being the next flight. This is required to have the certificate
> > available for computing finished, and to meet the implicit
> > acknowledgment rule.
> >
> 
> I'm very open to hacks, such as turning it into an ECH-style encrypted
> extension. Whatever makes this easier.
> 
> I think the main open question, also for regular client-auth
> pre-shared-kem-key AuthKEM is how do we treat this message in the
> transcript if the server *can't* decrypt this message (and tries to fall
> back to e.g. plain AuthKEM or TLS). But this is something that is in the
> issue tracker and document already.

The transcript would be computed with plain AuthKEM or TLS rules.

This is already required for handling the case where client thinks the
server supports PSK-KEM, but the server supports only TLS (e.g., due to
information time skew, or non-uniform cluster). This needs to fallback
to regular TLS.
 
 
> > And then it occured to me earlier today that web browsers might not like
> > the abbreviated AuthKEM very much: They really do not like to use DNS
> > for server authentication, instead preferring to use certificates sent
> > in-band. Of course, adding certificate message would duplicate the key
> > information, which is a footcannon.
> >
> 
> The keys-in-DNS idea is definitely more of an extension that I do not want
> to solve before settling on the main protocol. The main hard problem seems
> to be authenticating this key in DNS, and we definitely do not want to push
> all certificates there. (ChrisW told me that keys-in-DNS was also briefly
> discussed and shot down for semi-static/OPTLS for similar reasons). I am
> hoping we might have some synergies with the infra that supports ECH and
> perhaps the proposed much-compressed merkle tree certificates though. Any
> such deployments, which will need to periodically update the DNS records in
> the case of MTCs, might be a bit more advanced but seem by no means
> impossible.

Unfortunately, I don't think DNS is capable of handling the more
elaborate MTC negotiation.

With regard to certificate size, the main limit with newer DNS
transports (Do{T,Q,H,H3}) is the hard 64kB limit for a record set.

I think nowadays certificates are mostly 2.5-7kB or thereabouts.
However, future post-quantum certificates can be much larger.




-Ilari

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

Re: [TLS] AuthKEM: Splitting the draft and next steps

[Ilari Liusvaara]

On Wed, Jul 05, 2023 at 09:26:57AM +0200, Thom Wiggers wrote:
> Hi Ilari,
> 
> Thanks for pointing this out. I will admit I am pretty unaware of the
> additional constraints that DTLS has, but I will try to look at this issue
> in more detail. In the meantime, I would also appreciate it if people who
> are also concerned about AuthKEM+DTLS share their interest and concerns, as
> that will help with their visibility and maybe give me a list of people to
> ask questions to :)

Actually, the changes might not be quite so nasty:

- The DTLS epoch numbering needs to be changed: If AuthKEM is used,
  then epoch 3 needs to be autheticated_handshake epoch instead of
  application_0 epoch, which is pushed to epoch 4 and then that pushes
  other application epoch one number forward.

- Fortunately even if there are 5 active epochs during handshake,
  the 2 bits in DTLS header are still enough, because one of those is
  plaintext, and can be recognized from record types used.

- There actually might be chance to make the early auth work. However,
  there are subtle details:

  * The certificate being a message, it is subject to acknowledgements.
However, server hello must be logically before it. This is required
to meet the acknowledgment epoch rule.
  * The server flight needs to be broken into two just before server
Finished, first part being unordered with certificate, and second
being the next flight. This is required to have the certificate
available for computing finished, and to meet the implicit
acknowledgment rule.


Of course, even if the theroetical changes are not so nasty, those can
still play absolute hell with implementations. And there could be some
other gotcha I have not considered.


And then it occured to me earlier today that web browsers might not like
the abbreviated AuthKEM very much: They really do not like to use DNS
for server authentication, instead preferring to use certificates sent
in-band. Of course, adding certificate message would duplicate the key
information, which is a footcannon.




-Ilari

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

Re: [TLS] AuthKEM: Splitting the draft and next steps

[Ilari Liusvaara]

On Tue, Jul 04, 2023 at 08:00:00AM +0200, Thom Wiggers wrote:
> 
> It has been a while since I have had time to work on the IETF draft for
> AuthKEM (``draft-celi-wiggers-tls-authkem``, aka "KEMTLS"), and some of you
> have previously asked when the draft (which is currently expired) will be
> updated. In this email, I want to pick up the work again.
> 
> Specifically, I want to do the following:
> 
> * Split the proposal in two parts for improved legibility and applicability
> to use cases
> * Once this is done and in a good shape, move forward towards consensus
> with the aim of adoption
> 
> I will now describe the plan in more detail. I am welcoming further
> suggestions, and would like to hear if these changes make sense and are
> appreciated. If nothing else, you're welcome to help bikeshed draft names.
> :-)
> 
> The draft currently describes TLS authentication via KEM ("KEMTLS
> authentication") and TLS-PSK-style abbreviated handshakes via KEM
> (KEMTLS-PDK). The TLS authentication and the abbreviated KEM-based
> PSK-style handshake probably are independently interesting. The two
> proposals can be split and this would hopefully make evaluating them
> easier. AuthKEM and "pre-shared KEM" can be independently implemented.

Reading the draft, it occurs to me that adapting it to work on DTLS (or
unreliable CTLS) might require major and very challenging changes to
DTLS 1.3. Especially with client authentication.

And 0-RTT client auth probably can not work in DTLS at all, since DTLS
has no reliability for 0-RTT, unlike other handshake, which is reliable.




-Ilari

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

Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara]

On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote:
> > > Thanks! That’s indeed inconsistent, we’ll fix it.
> > > https://github.com/davidben/merkle-tree-certs/issues/32
> >
> > Hmm... Looking at that construct, why is the pad there?
> 
> 
> We pad to the hash block size. When computing the full Merkle tree, or
> verifying an authentication path, the values before the pad are the same,
> and thus we can precompute the hash state after digesting those fixed
> values.
> 
> (With the current inputs and sha256, it will only make a difference for
> HashAssertion though.)

I mean, is there a cryptographic reason for it? 

If one wanted to really micro-optimize performance, I think the optimal
design for SHA-256 would be to have padding for assertions but not for
empty nor nodes (since not padding empty and node saves one block).

(However, absent cryptographic reasons, this all is way premature.)


> > And there does not seem to be any way to salt the hash. WebPKI requires
> > what effectively amounts to salting the hash via serial number (even
> > for SHA-256).
> >
> 
> Please elaborate.

>From CABForum Baseline Requirements version 1.8.7 (2.0.0 has the same
requirement, but in several places), section 7.1.:

"CAs SHALL generate non‐sequential Certificate serial numbers greater
than zero (0) containing at least 64 bits of output from a CSPRNG."

In certificate structure, serial number comes very early (it is in
fact the first non-length field that varies). What that in effect does
is to make it much more difficult to exploit chosen-prefix collisions in
hash function.

However, that requirement holds irrespective of the hash function used,
and it has in fact been held for SHA-256 (regardless of there not being
any known even remotely feasible attacks) instead of just being a dead
letter from the past with much worse hash functions.




-Ilari

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

Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara]

On Mon, Jun 05, 2023 at 03:35:17PM -0400, David Benjamin wrote:
> Thanks for such detailed feedback! Responses inline.
> 
> On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara 
> wrote:
> 
> > Some quick comments / ideas:
> >
> > - I think it would be easier for subscribers to get inclusion proofs
> >   from transparency service than certificate authority.
> >
> >   This is because issuance is heavily asynchronous, whereas most
> >   servers assume ACME is essentially synchronous.
> >
> >   If certificates are canonicalized (this is mostly matter of ensuring
> >   the names are always sorted), this could be endpoint to download known
> >   inclusion proofs by certificate hash.
> >
> >   Or maybe even have both, and subscribers can use whichever is more
> >   convinient.
> >
> 
> We’re currently envisioning that the transparency services will potentially
> vary by RP. They’re effectively the RP’s CT policy. The different TSs all
> see the same trees, just later than the CA. It seems simpler then to get it
> from the CA, which will be the least behind. This also means RPs can adjust
> TS preferences without impacting subscribers or CAs at all. The equivalent
> of a CT log migration and distrust is much less invasive.
> 
> Also, subscribers already talk to CAs via, e.g., ACME, so it seemed natural
> to rely on that existing relationship. Especially as subscribers will need
> a fallback credential from a CA anyway.
> 
> I suppose there’s no reason why the subscriber couldn’t fetch from the TS.
> Though I’m not seeing how it would be more convenient. Could you elaborate?

Well, maybe that was a bit X-Y.

What I am really after is some mechanism of downloading certificates
outside ACME, because the issuance wait is likely prohibitive for many
ACME clients.
 

> >   I don't see rule for how claims are sorted within each type,
> >   only how different types are sorted.
> >
> > - If each claim was in its own Claim, then one could maybe even
> >   shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and
> >   dns/dns_wildcard.
> >
> >   This could also simplify sorting: Sort by type, lexicographic
> >   sort by claim contents.
> >
> 
> Thanks! Yeah, the actual Claim bits were just a naive transcription of
> X.509 SANs for now without much thought. I filed
> https://github.com/davidben/merkle-tree-certs/issues/31 to track those.

One use of strict canonical encoding would be to let the subscriber
compute the certificate body itself. E.g., so it could look up the
certificates by body hash.


> > - I don't think anybody is going to use signatures with >64kB keys,
> >   so subject_info length could be shortened to 16 bits.
> >
> 
> Added to https://github.com/davidben/merkle-tree-certs/pull/29

As a note about signature sizes, TLS (1.2 and 1.3) have 64kB signature
limit. IIRC, in NISTPQC outside the "interesting" stuff, only PICNIC
had trouble with that. However, when it comes to PQC stuff, IIRC there
is second call for proposals going on right now.

> 
> > - I think it would be easier if lifetime was expressed in batch
> >   durations. Then one would not need window size, and especially not
> >   handle lifetime / batch_duration not being an integer!
> >
> 
> I think we’d still need to be able measure it in both units, but maybe I’m
> missing something?
> 
> We need something in units of batch duration (currently window size) to
> size the signed windows, etc.
> 
> But the RP can’t just use the window in lieu of expiry, because it can’t
> simply assume all batches are valid, because the RP may be unable to fetch
> new windows for a long period of time, such that the old (or all!) batches
> have fallen off.
> 
> We could do that calculation in batch durations, but then we need to
> measure the current time in batch numbers, which seemed unintuitive to me.
> And then once that was in seconds, it didn’t seem that aligning it on batch
> duration did much.

Well, actually doesn't look like things get too annoying if lifetime /
batch_duration is not an integer:

- window size can be just the ceiling of that.
- RPs can calculate explicit expiry via t = t_0 + p * t_p + t_l.

Neither of which needs floating-point (which one definitely does not
want to use here).


> > - The root hash being dependent on issuer and batch number iff there
> >   are multiple assertions looks very odd.
> >
> >   Empty assertion list might be special. But this also happens for
> >   one assertion.
> >
> 
> Thanks! That’s indeed inconsistent, we’ll fix it.
> https://github.com/davidben/merkle-tree-certs/issues/32

Hmm... Looking at that construct, why is the pa

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Fri, May 19, 2023 at 06:57:09PM +0100, Kris Kwiatkowski wrote:
> Hello,
> 
> The codepoint for P-256+Kyber768 has been just assigned by IANA. The value
> is 0x639A.
> Thanks Rich for pointing to the request form.

I get off-by-one for the sizes of key shares.

The given size of client key share seems to be size of kyber public key
plus 64 bytes, and given size of server key share seems to be the size
of kyber ciphertext plus 64 bytes.

However, the difference is stated to be UncompressedPointRepresentation
for P256 from TLS 1.3. AFACIT, that is 65 bytes (1 legacy_form byte,
32 bytes for x, 32 bytes for y).

So I get that the client share should be 1249 bytes (instead of 1248
bytes) and the server key share should be 1153 bytes (instead of 1152
bytes).

Obviously something is wrong somewhere, but where?




-Ilari

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

Re: [TLS] [UNVERIFIED SENDER] Re: Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Thu, May 11, 2023 at 02:44:18PM +, Kampanakis, Panos wrote:
> ACK, thx all. So we should refrain from defining such “point-in-time”
> codepoints for other needed long-term algorithm combinations to not
> waste registry space. Only absolutely necessary codepoints should be
> registered.

That registry has >64,000 free codepoints. I don't see there being
anywhere close enough individual registrations to fill that up, no
matter how loose the criteria are.

However, with post-quantum, there is another reason to be careful:
The shares are so large that the client effecively only has one shot.


Some sort of systematic registrations reseving large chunks of space
is the only way I can foresee the registry being seriously depleted.
In contect of TLS groups, No such registrations exist currently, nor
have I seen proposals for such thing.




-Ilari

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

Re: [TLS] Servers sending CA names

[Ilari Liusvaara]

On Thu, Apr 13, 2023 at 02:35:50AM +, Peter Gutmann wrote:
> Salz, Rich  writes:
> 
> >Is this generally used?  Would things go badly if we stopped sending them?
> 
> Just as a data point, in the SCADA world it seems to be universally ignored.
> I've seen everything from servers that send a list containing every CA in
> existence, so much data in that one field that it overflows the TLS maximum
> message size (when queried the server admins asked what a CA name list was,
> and what it was used for), to a few random CA names that don't correspond to
> anything they'll accept (when queried the server admins asked what a CA name
> list was, and what it was used for), to nothing at all.  I've also seen plenty
> of servers that send cert requests to the client without actually wanting a
> cert (when queried the server admins asked what a cert request was, and what
> it was used for).

You mean overflow the maximum field size (64kB)?

I don't think anything can deal with overflowing maximum message size,
as that will cause the handshake to desync (everything afterwards will
be garbage). Overflowing the field could still work if client just
ignores what is in there (there is nothing after that in certificate
request).

And furthermore, overflowing the message would require a truly
impressive number of CA certs. Even WebPKI, infamous for having lots of
CAs, does not have even close to enough for that (an order of magnitude
more might start coming close).



-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Ilari Liusvaara]

On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> On the subject of clarification, the update also needs to explain why PSK is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key, with complex and awkward reconciliation rules between then,
> and why the PSK has to be the last extension in the client hello.  I can't see
> any reason for either of those two, which in particular for the latter one
> means why would an implementation follow that apparently pointless
> requirement?  Is this codifying someone's implementation bug?  Do demons fly
> out of your nose if it's not the last extension?

For the first, I actually asked that very question during TLS 1.3
development. Psk_key_exchange_modes can appear without pre_shared_key.

As for the second, the present method of computing binders (message
truncation) requires pre_shared_key to be the last extension. While
it would be possible to design ways of computing binders without such
requirement, those methods would seem to be much more complicated.



-Ilari

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Sun, Apr 02, 2023 at 02:54:57AM +, Blumenthal, Uri - 0553 - MITLL wrote:
> CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B
> that also permitted P-256. P-521 is not included either. See
> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
> (page 1).
> 
> CNSA-2.0 allows only Kyber-1024. Not -768. See 
> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
> (page 4).
>
> So, if somebody would insist on a CNSA-compliant hybrid - there is
> only one candidate from each group to consider for the MTI. 
> 
> It also means that MTI für P-384 with Kyber-768 is likely to be quite
> useless, as those not bound by CNSA would probably make other choices
> (not P-384)  anyway, and those required to comply with CNSA will have
> to settle for what I described. 
> 
> Did I make it clear enough? Or do you see a hole in my logic?

I think what "CRYSTALS: Kyber" means in CNSA-2.0 is the final
specification. Which obviously is not available yet, so it is impossible
to currently make any key exchange or asymmetric encryption compliant
with CNSA-2.0.

As to what sense does publishing CNSA-2.0 before the algorithms are
known make? Note that it does have algorithms for firmware signing
fully specified, and urges those to be deployed as soon as possible.
And I suppose there might be sense timing-wise on publishing a spec
referencing a future spec that will likely undergo nontrivial draft
period.



-Ilari

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Sat, Apr 01, 2023 at 02:12:14AM +, Kampanakis, Panos wrote:
> Hi Bas,
> 
> I prefer for the MTI to be P-256+Kyber768 for compliance reasons.

Uh, I think this thing is too experimental to have any MTI.
 
> It would be trivial for servers to add support for both identifiers
> as they introduce Kyber768, but you are right, the new draft should
> include an MTI identifier.

The problem with having both is that it bifurcates the system. While
being on wrong side is not a hard failure, it is still rather annoying
perf hit.

For clients to support either, servers must support both.

At least with P-384 hybrid, folks are less likely to deploy the thing
unless needed.



-Ilari

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Sat, Apr 01, 2023 at 01:56:23AM +0200, Bas Westerbaan wrote:
> >
> > The draft draft-tls-westerbaan-xyber768d00-00 references
> > draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
> > since fixed in editor's copy.
> >
> > And then, the correct reference for X25519 is probably RFC7748 instead
> > of RFC8037...
> >
> >
> > Really quick and dirty way to fix this would be to publish editor's
> > copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
> > RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
> > the references.
> >
> 
> Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Thanks, that addresses my concern. 



-Ilari

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

[TLS] A comment on draft-mattsson-tls-psk-ke-dont-dont-dont

[Ilari Liusvaara]

It seems that draft-mattsson-tls-psk-ke-dont-dont-dont also deprecates
some other stuff. However, it does not seem to deprecate session_ticket
(recommended=Y!).

That extension is flawed in multiple ways, and those flaws interact in
nasty ways, with end result worse than psk_ke. If psk_ke warrants being
marked as recommended=D, then session_ticket definitely also does.

If server has session tickets enabled, then STEK is master key to
decrypt all TLS 1.2 connections that advertise session_ticket.
Furthermore, unless server has explicit checks to limit total session
lifetime (which is not the same as ticket age), attacker can roll over
tickets to new STEK.



-Ilari

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Wed, Mar 29, 2023 at 02:59:51PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> Because that’s what CNSA requires. 

I don't think that is the case. CNSA1 does not consider the Kyber part,
and CNSA2 requires something that is not currently available.

 
> > On Mar 29, 2023, at 00:45, Kampanakis, Panos  wrote:
> > 
> > 
> >  
> > > I would also like secp384r1_kyber1024 option, please.
> >  
> > Why do you up the ECDH curve sec level with Kyber1024? It adds
> > unnecessary size to the keyshare. like secp384r1_kyber768
> > combines two equivalent security levels.

Is that the case? Secp384r1 is 192-level DH, but Kyber768 is quoted to
be Category III (and I think it is not significantly above Category III
requirements), which is defined as equivalent to 192-level encryption.
192-level DH is stronger than 192-bit encryption.

(Another illustration of numbers not being comparable is that Category
IV is defined as equivalent to 192-level hash.)

I would pair secp384r1 with Kyber768 for completely different reasons:
Kyber768 is what the team kyber recommends.


> > From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
> > Sent: Tuesday, March 28, 2023 10:40 PM
> > To: Krzysztof Kwiatkowski ; Christopher Wood 
> > 
> > Cc: TLS@ietf.org
> > Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
> > draft-ietf-tls-hybrid-design
> >  
> > Can we add secp256r1_kyber768 option for those who prefer NIST
> > curves?
> >  
> > I support this.
> >  
> > I would also like secp384r1_kyber1024 option, please.
> >  
> > Thanks

I don't think there are very good reasons for NIST curves here outside
wanting CNSA1 compliance, and for that you need secp384r1 classical
part. And for that, I would pick secp384r1_kyber768.




-Ilari

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Wed, Mar 29, 2023 at 10:48:32AM +0900, Christopher Wood wrote:
> As discussed during yesterday's meeting, we would like to assess
> consensus for moving draft-ietf-tls-hybrid-design forward with the
> following strategy for allocating codepoints we can use in
> deployments.
> 
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance
>this document through the process towards publication.

Support.


> 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas
> helpfully did this for us already [1].) Once this is complete,
> request a codepoint from IANA using the standard procedure.

I have a concern with this:

The draft draft-tls-westerbaan-xyber768d00-00 references
draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
since fixed in editor's copy.

And then, the correct reference for X25519 is probably RFC7748 instead
of RFC8037...


Really quick and dirty way to fix this would be to publish editor's
copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
the references.




-Ilari

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

Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara]

On Fri, Mar 10, 2023 at 05:09:10PM -0500, David Benjamin wrote:
>
> I've just uploaded a draft, below, describing several ideas we've
> been mulling over regarding certificates in TLS. This is a draft-00
> with a lot of moving parts, so think of it as the first pass at
> some of ideas that we think fit well together, rather than a
> concrete, fully-baked system.
>
> Thoughts? We're very eager to get feedback on this.

Some quick comments / ideas:

- I think it would be easier for subscribers to get inclusion proofs
  from transparency service than certificate authority.

  This is because issuance is heavily asynchronous, whereas most
  servers assume ACME is essentially synchronous.

  If certificates are canonicalized (this is mostly matter of ensuring
  the names are always sorted), this could be endpoint to download known
  inclusion proofs by certificate hash.

  Or maybe even have both, and subscribers can use whichever is more
  convinient.

- I don't think there are any sane uses for >64kB claims, so the
  claim_info length could be shortened to 16 bits.

  I don't see rule for how claims are sorted within each type,
  only how different types are sorted.

- If each claim was in its own Claim, then one could maybe even
  shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and
  dns/dns_wildcard.

  This could also simplify sorting: Sort by type, lexicographic
  sort by claim contents.

- I don't think anybody is going to use signatures with >64kB keys,
  so subject_info length could be shortened to 16 bits.

- What does it mean that in this document the hash is always SHA-256?

- Apparently issuer id is limited to 32 octets. This could be noted in
  the definition.

- I think it would be easier if lifetime was expressed in batch
  durations. Then one would not need window size, and especially not
  handle lifetime / batch_duration not being an integer!

- The root hash being dependent on issuer and batch number iff there
  are multiple assertions looks very odd.

  Empty assertion list might be special. But this also happens for
  one assertion.

- I think LabeledWindow should add 64 spaces in front, so it
  reuses the TLS 1.3 signature format.

  This reduces risks of cross-protocol attack if the key gets
  reused anyway (despite there being MUST NOT requirement).

- Is there reason for type of trust_anchor_data to vary by proof_type?
  Why not always have MerkleTreeTrustAnchor there?

- And proof_data length field should probably be 16 bits. I don't think
  proof_data will ever exceed 8kB.

- For type-independent expiry info to be helpful, this must be somehow
  plumbed to the TLS server.

- Even if ACME itself allows for long processing delays, many (most?)
  ACME clients do not.

- Multiple orders from single newOrder or multiple certificates in
  single order sounds like it would break assumption made in ACME
  rather badly, and thus recipe for trouble.

- Isn't cert_type deprecated?

- "We may need to define a third one.", you men fourth one?

- I think the uniform certificate format is already a requirement in
  TLS 1.3. And OpenPGP format is banned in TLS 1.3 anyway. So parsing
  to extension blocks without knowing certificate type is no problem.




> On Fri, Mar 10, 2023 at 4:38 PM  wrote:
> 
> >
> > A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt
> > has been successfully submitted by David Benjamin and posted to the
> > IETF repository.
> >
> > Name:   draft-davidben-tls-merkle-tree-certs
> > Revision:   00
> > Title:  Merkle Tree Certificates for TLS
> > Document date:  2023-03-10
> > Group:  Individual Submission
> > Pages:  45




-Ilari

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

Re: [TLS] Merkle Tree Certificates

[Ilari Liusvaara]

On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote:
> >
> > Unpopular pages are much more likely to deploy a solution that
> > doesn't require a parallel CA infrastructure and a cryptographer
> > on staff.

I don't think the server-side deployment difficulties with this have
anything to do with parallel CA infrastructure or admins having to
understand cryptography.


> CAs, TLS libraries, certbot, and browsers would need to make changes,
> but I think we can deploy this without webservers or relying parties
> having to make any changes if they're already using an ACME client 
> except upgrading their dependencies, which they would need to do
> anyway to get plain X.509 PQ certs.

I don't agree.

I think deploying this is much much harder than deploying X.509 PQ
certificates. X.509 PQ certificates are mostly dependency update. This
looks to require some nontrivial configuration work that can not be
done completely automatically.

And then in present form, this could be extremely painful for ACME
clients to implement (on level of complete rewrite for many).




-Ilari

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Ilari Liusvaara]

On Fri, Mar 03, 2023 at 09:37:48PM +0100, Bas Westerbaan wrote:
> >
> > And of course, we really
> > don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
> >
> 
> More to the point, I'd say the post-quantum transition is the
> natural moment to move from ≤1.2 to 1.3.

Agreed.
 
> (TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades
> during the transition because of CurveSwap like attacks.)

I would say that much more severe problem is that TLS 1.2 group shares
are too small and the rest is not even close to how KEM operates. So
one would need to pretty much redefine the entiere key exchange, which
is not a good idea.

Whereas TLS 1.3 group shares can be large enough, offering the trivial
extension to post-quantum.



-Ilari

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

Re: [TLS] TLS 1.2, RFC7250 RPK and (not sending) client certificates?

[Ilari Liusvaara]

On Sat, Feb 04, 2023 at 07:25:31PM +0100, Achim Kraus wrote:
> My interpretation of RFC5246, 7.4.6 Client Certificate
> 
> https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6
> 
> "If no suitable certificate is available, the client MUST send a
> certificate message containing no certificates. That is, the
> certificate_list structure has a length of zero."
> 
> covers RFC7250 as well. That section doesn't say something about
> the certificate type and so in my interpretation it applies general
> to all certificate types, including RPK.
> 
> So, even if RPK is negotiated for the client, the client complies
> to RFC5246, 7.4.6 sending a empty list in order to indicate, that
> "no suitable certificate is available".

Unfortunately, that would not work for the earlier OpenPGP certificate
type (RFC6091), which does not use 0x00 as its NAK (instead, it
uses 0x0100). Of course, I don't think anyone is using that type.


Looking at TLS library I wrote, the TLS 1.2 parsing routines do
interpret RPK certficate containing 0x00 as refusal to authenticate.
However, it does not actually support either TLS 1.2 client
certificates, nor RPK client certificates, so that code can not actually
be used.



-Ilari

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

Re: [TLS] Regulations for EKU validation for CA certificates in the certificate chain

[Ilari Liusvaara]

On Sat, Jan 28, 2023 at 11:57:46AM +0200, Oleg Pekar wrote:
> Dear TLS WG,
> When TLS party receives other party's certificate chain, there is a rule
> for validation of end-entity certificate EKU specified by the RFC 3280,
> section "4.2.1.13 Extended Key Usage":
> 
> "If the extension is present, then the certificate MUST only be used
>for one of the purposes indicated.  If multiple purposes are
>indicated the application need not recognize all purposes indicated,
>as long as the intended purpose is present.  Certificate using
>applications MAY require that a particular purpose be indicated in
>order for the certificate to be acceptable to that application.
> 
>If a CA includes extended key usages to satisfy such applications,
>but does not wish to restrict usages of the key, the CA can include
>the special keyPurposeID anyExtendedKeyUsage.  If the
>anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
>be critical."
> 
> However the RFC doesn't require CA certificates in the party's chain to
> follow the same rule as the end-entity certificate.

Right. By RFCs, the EKU of CA certificates does not matter.

 
> Example: if the client sends a chain Root->CA1->CA2->End-Entity, then the
> End-Entity certificate, if EKU is present in it, must include
> EKU=clientAuth. But Root, CA1, CA2 can have EKU=serverAuth (and don't
> include EKU=clientAuth at all). Such a chain would be considered valid from
> the RFC perspective, nevertheless it is counter-intuitive. Due to this
> potential gap some implementations (including OpenSSL) apply the same
> validation rules for client end-entity certificate to client's chain CA
> certificates and this creates incompatibility between implementations.
> 
> * Am I missing a standard that explicitly regulates EKU for CA certificates
> in the party's chain?

The standard interpretation in WebPKI is that EKU of CA certificates
does matter, and I guess this has spilled over to a number of non-Web
TLS implementations.



-Ilari

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

Re: [TLS] about hash and post-quantum ciphers

[Ilari Liusvaara]

On Sat, Jan 28, 2023 at 09:02:32AM +, John Mattsson wrote:
> 
> >Well, duplex mode is a bit special-purpose thing, for cases where one
> >wants to reduce number of primitives to reduce code size, or has
> >hardware acceleration to make it much faster than AES-GCM.
> 
> That is also a good idea. NIST stated a long time ago that they would
> standardize an AEAD based on Keccak, but that has not happened so far.

There is paper about Keccak duplex mode by Team Keccak, which contains
important information like how the mode works and what assumptions it
has.

And I meant using duplex mode for bulk encryption. It seems to be
useful for that in both constrained and extreme-performance hardware-
accelerated implementations.


> I was thinking that Keccak duplex mode could be used in the key
> schedule. It feels high level like a more natural construct for a key
> schedule. You cen see it as a generalization of the running hash
> interface.
> 
> Running hash:
> init(), update(Mi), digest = finalize()
> 
> Duplex:
> init(), digest = update(Mi, length)
> 
> But it might too much changes and too little gain to do.

That definitely seems too much change and too little gain.

- Seems to be kind of change that would really mess with
  implementations.
- Could cause problems with the way PSK binders are calculated
  (tapped in middle of ClientHello!).
- Minimal code size benefit at most.
- No performance benefit (possibly even slight performance
  penalty).



-Ilari

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

Re: [TLS] Security of using same cert for TLS client and server

[Ilari Liusvaara]

On Fri, Jan 27, 2023 at 06:01:04PM +, John Mattsson wrote:
> Hi,
> 
> - Using the same signature key or PSK for TLS and another protocol is
>   obviously unsecure in the worst case. But probably practically
>   secure in many cases even if nobody has proved it.

Well, looking at the signatures:

- TLS 1.2 client signatures start with 0x01 (client hello message
  type).
- TLS 1.2 server signatures are messy, as the first 32 octets are
  from client (client random)!
- TLS 1.3 signatures start with 0x20 (explicit padding).
- JOSE signatures start with 0x65 (base64url of '{').
- COSE signatures start with 0x84 or 0x85 (Countersignatures can
  also start with 0x86); (Array of 4, 5 or 6 elements).
- X.509 signatures (S/MIME, PKIX, etc...) typically start with 0x30
  (SEQUENCE type).
- SSH pubkey signatures start with 0x00 (session id is <16MB).
- SSH hostkey signatures are a bit messy, as those seem to be over a
  raw hash.
- SSH signatures start with 0x53 (explicit magic).


So looks like none of those can interact badly with others, except
for TLS 1.2 server signatures and SSH hostkey signatures (and even
those probably don't interact badly in practice)


> - Did any of the formal analysis prove that using the same key for
>   TLS client and server is secure? It is quite common that the same
>   node is a TLS server and client.

For TLS 1.3, it is secure (the signatures have context). For TLS 1.2,
things are more complicated (but it is probably still secure).



-Ilari

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

Re: [TLS] about hash and post-quantum ciphers

[Ilari Liusvaara]

On Fri, Jan 27, 2023 at 11:24:59AM +, John Mattsson wrote:
> Hi,
> 
> I don't think non-standardized algorithms should be adopted by the
> WG. Even for just assigning a number, a good first step would be CFRG.

Well, getting adopted by the WG isn't a requirement for those to wind up
with a number... There is expert review process as well.

I think it might be time for experimental PQC codepoints for final
round of testing before the final PQC algorithms. Recommended=N of
course.


> But this mail got me thinking:
> 
> - NIST is expected to exclusively use SHA3 in the lattice-based PQC
>   algorithms. I think it would make very much sense to include SHA3
>   (the SHAKE variants) at the same time as the standardized NIST PQC
>   algorithms.

Why wait for those? It seems to me that one could add the SHA-3
ciphersuites already, as SHA-3 has been standardized years ago.

- TLS_AES_128_GCM_SHA3_32
- TLS_AES_256_GCM_SHA3_48
- TLS_CHACHA20_POLY1305_SHA3_32
- TLS_KECCAK_DUPLEX_SHA3_48

I think all could use 256-level SHA-3, I don't think dropping to
128-level for AES-128 is worth it.


> - TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF
>   constructions that only exists because SHA2 is fixed-length and
>   suffers badly from length-extension attacks. Modern hash algorithm
>   like SHAKE/KMAC are variable-length and does not suffer from
>   length-extension attacks. If SHA3 is added in the future, I think
>   it would make sense to use KMAC instead of HMAC and HKDF. Might also
>   be nice to use the duplex construction whose security can be shown
>   to be equivalent to the sponge construction.

Well, duplex mode is a bit special-purpose thing, for cases where one
wants to reduce number of primitives to reduce code size, or has
hardware acceleration to make it much faster than AES-GCM. 

One might want to design padding in duplex mode so that each data block
is 128 octets... And another trick is only supporting plaintext sizes
multiple of 8 octets (TLS 1.3 record layer can pad to it anyway).


And TLS 1.3 uses hash function in four ways:

- Raw hash (Transcript-Hash).
- Raw HMAC (verify_data).
- KDF extraction (HKDF-Extract). Which actually turns out to be raw
  HMAC under the hood.
- KDF expansion (HKDF-Expand-Label).

To actually use SHA3 to full capacity, one would have to weird stuff
by redefining HKDF-Extract and HKDF-Expand-Label to be something else
than HKDF.

One could optimize a bit by using SHAKE256 instead of KMAC256 for the
last three. I think all the standard stuff would then be doable with
only one Keccak-F per MAC/KDF (maximum 135 octets in, 136 out). This
would save a few Keccak-F computations.



-Ilari

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

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

[Ilari Liusvaara]

On Tue, Dec 13, 2022 at 03:51:33PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I do not support deprecation, because there will be deployed devices
> (IoT, SCADA) that aren’t upgradable – and the new stuff will have to
> access them.

Any stuff that needs to access such devices already has to be special.
One more MUST to ignore is not a big deal for such case.



-Ilari

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

Re: [TLS] Call for adoption of draft-thomson-tls-keylogfile

[Ilari Liusvaara]

On Mon, Nov 28, 2022 at 07:02:20PM +, Andrei Popov wrote:
> 
> I oppose adoption of draft-thomson-tls-keylogfile. The stated goal
> was to find a permanent, discoverable location for this document,
> other than NSS project's repository. Perhaps it's fine to create an
> RFC for this purpose, but then I'd argue that it should be an
> Informational RFC.

The I-D has: "Intended status: Informational" (for some reason
the datatracker is unable to determine this).



-Ilari

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

Re: [TLS] draft-ietf-tls-batch-signing

[Ilari Liusvaara]

On Thu, Nov 10, 2022 at 02:29:38PM +0300, Benson Muite wrote:
> The above draft has expired.  However, if there is still interest in
> it, the EdDSA specification will need to be updated based on findings
> in [1] and [2]. An erratum to [3] has been filed [4]. Libsodium seems
> to offer best checks for batch verification. Currently testing other
> libraries that offer support for EdDSA.
> 
> 1) Chalkias, Garillot, and Nikolaenko "Taming the many EdDSAs"
> https://eprint.iacr.org/2020/1244
> 
> 2) Brendel, Cremers, Jackson, and Zhao "The Provable Security of
> Ed25519: Theory and Practice" https://eprint.iacr.org/2020/823
> 
> 3) https://datatracker.ietf.org/doc/html/rfc8032
> 
> 4) https://www.rfc-editor.org/errata_search.php?rfc=8032_status=0

Note that the mention of "batch" in [1] is about batch verification,
which is unrelated to TLS batch signing. And as far as I know, the
problems with implementations only concern beyond-standard-model
security of Ed25519, which TLS does not rely upon (since TLS works
with ECDSA, which is much worse).

IIRC, the only check that RFC 8032 omits is checking that all of
X^2, Y^2 and X^2+Y^2 for both R and A are nonzero (for Ed448, 
X^2+Y^2 is always nonzero).


However, there is unrelated security problem with the way the TLS batch
signing draft uses Ed25519 (and Ed448): There is leaf salt, but it does
not salt the innermost hash, degrading security. 



-Ilari

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

Re: [TLS] HRR delenda est (was Re: Published RFC 8446bis -05)

[Ilari Liusvaara]

On Tue, Oct 25, 2022 at 02:57:47PM +1100, Martin Thomson wrote:
> 
> Removing HRR might be possible if we look at putting more stuff in 
> DNS or something along those lines, but that would require a bunch
> of care and preparation.  That's effort that - at least to me -
> might be better spent elsewhere.

Idea: SVCB/HTTP key preferredgroups. Value is one or more group ids
encoded as 2 octet big endian and concatenated, in order from most
preferred to least preferred.

When connecting, the client should scan the list for first group it
supports and send a share for that (send no share if no overlap?).
Supported_groups still contains full supported group list.

... The problem with this is that in some servers, key share affects
group selection. This could lead into downgrade attacks with such
servers. On the other hand, most clients today send x25519 key share
by default, which seems to be the weakest supported group in TLS 1.3.



-Ilari

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

Re: [TLS] Published RFC 8446bis -05

[Ilari Liusvaara]

On Mon, Oct 24, 2022 at 01:07:25PM -0700, Eric Rescorla wrote:
> Hi Folks,
> 
> I have just published draft-ietf-tls-rfc8446bis-05, with
> the following changes:
 
Should there be "SHOULD NOT reuse key shares between client hellos"?
I did't find such requirement (or maybe it is there but I just missed
it), which I think is odd, given that there is similar requirement for
tickets, and reusing key shares has similar impact as reusing tickets.

Such reuse is especially bad if SNI differs, or if the group is not
actually safe for key reuse.

(In case of hybrid key exchanges, implementations might reuse shares
within the same client hello. E.g., reusing the same X25519 key both
for x25519 and x25519+kyber768.)



And then section 5.5 contains "SHOULD not". I presume that should
be "SHOULD NOT". 




-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Tue, Aug 30, 2022 at 02:11:57PM +0200, Bas Westerbaan wrote:
> For TLS on the Web it would be ideal if we can find a single[1] hybrid
> which we can all be happy with because that will make keyshare
> negotiation easier.

I don't suppose that will happen, as:

- Some folks want something with P384 classical part.
- Some folks do not want P384 classical part.
- Some folks do not want Kyber768, as it does not fit into MTU.

> The PQ hybrid situation is more painful. Suppose we end up with two
> essentially equivalent hybrids, say P-256+Kyber768 and
> X25519+Kyber768, and different servers have a different preference.
> Then clients are forced to either send both keyshares or suffer an
> HRR.

And without compression (which is not trivial to implement), sending
both uses quite a bit of space...
 
> Of course, we can change the server logic, but it isn't simple.

I think there could be some guidance on server logic.


And one another thing would be adding group hint to SVCB/HTTPS.
However, this would run into trouble with downgrade attacks.



-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Fri, Aug 12, 2022 at 06:13:38PM +, Scott Fluhrer (sfluhrer) wrote:
> Again, this is late, however Stephen did ask this to be discussed in the 
> working group, so here we go:
> 
> > -Original Message-
> > From: TLS  On Behalf Of Stephen Farrell
> > Sent: Saturday, April 30, 2022 11:49 AM
> > To: Ilari Liusvaara ; TLS@ietf.org
> > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design
> > 
> > 
> > Hiya,
> > 
> > On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> > >> - section 5: IMO all combined values here need to have recommended ==
> > >> "N" in IANA registries for a while and that needs to be in this draft
> > >> before it even gets parked. Regardless of whether or not the WG agree
> > >> with me on that, I think the current text is missing stuff in this
> > >> section and don't recall the WG discussing that
> > >
> > > I think that having recommended = Y for any combined algorithm
> > > requires NIST final spec PQ part and recommended = Y for the classical
> > > part (which allows things like x25519 to be the classical part).
> > >
> > > That is, using latest spec for NISTPQC winner is not enough. This
> > > impiles recommended = Y for combined algorithm is some years out at
> > > the very least.
> > 
> > I agree, and something like the above points ought be stated in the draft
> > after discussion in the WG.
> 
> Section 5 is 'IANA considerations', and would be where we would list
> the various supported hybrids, which we don’t at the moment.
> 
> Well, if we were to discuss some suggested hybrids (and we now know
> the NIST selection), I would suggest these possibilities:
> 
> - X25519 + Kyber512
> - P256 + Kyber512
> - X448 + Kyber768
> - P384 + Kyber768

I would take:

X25519+Kyber768
P384+Kyber768

The reason for taking Kyber768 is because the CRYSTALS team recommends
it. The reason for taking P384 is because it is CNSA-approved, so folks
that need CNSA can use that.

Of course, that is likely to bust packet size limits. I do not think
that is an issue in TLS, but DTLS and QUIC might be another matter
entierely (in theory DTLS and QUIC can handle it just fine, practice
might be another matter entierely. And if such problems are there, it
is good to know about those... This stuff is experimental).


> Of course, it's possible that NIST will tweak the definition of Kyber;
> that's just a possibility we'll need to live with (and wouldn't change
> what hybrid combinations we would initially define)

I would think such changes would just mean the interim post-quantum
kex is not compatible with the final one. Not that big of deal, there
are tens of thoursands of free codepoints. If an implementation  needs
both, it can probably share vast majority of the code.



-Ilari

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

Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

[Ilari Liusvaara]

On Tue, Aug 09, 2022 at 09:05:31AM +0200, Kristijan Sedlak wrote:
> 
> thank’s for replying. I did verify the transcript as well. Everything
> seems to be correct. I bet if it wasn't the 1-RTT and
> 0-RTT(no-early-data) would fail too. Something weird is going on only
> in 0-RTT(early-data) case.

Well, if an implmentation incorrectly omitted EOED from transcript, that
would only fail in accepted early-data case, not in other cases.
However, looking at the library source, it seems to properly include
EOED in the transcript (however, I am not a Ruby programmer).


Wild thing to try, and extremely unlikely to work, but does removing the
EOED from the transcript (but still sending the message!) make the
server accept the client finished? If yes, the server is buggy: TLS 1.3
is very clear that EOED is part of the transcript.


> Can you maybe point me to an URL with the correct TLS1.3
> implementation where I could safely test the client?

Well, I would try testing against some major CDN that accepts early
data, as they likely have the most debugged server implementations.
As for safety, if you don't have automated repeats, I would think that
would be unlikely to trip any sort of attack detection with the CDN.

I have written a TLS implementation, but it will not support early
data.


On Tue, Aug 09, 2022 at 09:55:37AM +0200, Kristijan Sedlak wrote:
> After some sleep, I went playing with the content of the EarlyData
> sent to the server and it turned out that the "Connection: close"
> header must be present in the HTTP1.1 request. After adding it, the
> error was gone and the connection closed with Alert(0).

Well, what I think is happening here is that the server can only ever
send one alert per connection. The Connection: close then causes it
to send close_notify from early data, and so when the finished MAC is
bad, it can not send alert for it. Or else that the close from early
data causes it to get confused and silently abort the handshake.

> Is this the expected behavior and Keep-Alieve is not allowed when
> EarlyData is used or it's just the remote server implementation
> specific? If I understand the spec correctly, the behavior of the
> EarlyData part is mostly up to the implementor, and you must know
> the rules up front, right?

Keep-Alive is definitely supposed to work with early data.

The behavior specified is that if early data is accepted, the
client data consists of concatenation of the early data and the
application data the client sends. If early data is not proposed, or
it gets rejected, then client data consists of application data the
client sends.


Note that for HTTP, only GET and HEAD (and in future, QUERY) are
allowed in early data. And the requests might get 425 error, which
MUST be retried.



-Ilari

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

Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

[Ilari Liusvaara]

On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote:
> Hello everyone. 
> 
> I decided to get involved here since I hit a dead end when resolving
> an Alert(20) error that I get from almost all servers when using PSK
> with EarlyData.
> 
> Here's the initial issue I opened 
> https://github.com/thekuwayama/tttls1.3/issues/48.
> It relates to a specific implementation but my questions are general.
> There's also a code snippet that you can run and see the issue
> yourself.
> 
> So it happens that when sending a GET request as EarlyData and then
> completing the handshake with EndOfEarlyData following the
> ClientFinished message, a server (e.g. ssltest.louis.info)
> successfully sends a complete response but finishes the request with
> Alert(20) message. It doesn't happen on 1-RTT nor 0-RTT(without early
> data). If I don't send ClientFinished in 0-RTT+EarlyData I don't get
> Alert(20) and everything works as expected.
> 
> I don't see anything in the spec that would describe something like
> this or would point to a different way for calculating the
> ClientFinished for 0-RTT+EarlyData case. Is maybe this sentence from
> the spec "PSK-based authentication happens as a side effect of key
> exchange." something that some of us miss interpreter and states
> that Finished message should be verified and sent only in 1-RTT? 
>
> What could be the case here?

Wild guess, the transcript is not computed over correct messages or in
correct order.


When server accepts early data, the sequence of messages client sends
is:

- ClientHello
- (0-RTT data)
- EndOfEarlyData
- client Finished

And the sequence of messages in transcript used to compute the client
finished is (note the EoED, RFC 8446 section 4.4.1 is very explicit
about it):

- ClientHello
- ServerHello
- EncryptedExtensions
- server Finished
- EndOfEarlyData


(This assumes there is no extension that would add new messages in
play. There can not be HelloRetryRequest because that implicitly
rejects early data.)



-Ilari

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Ilari Liusvaara]

On Sat, Aug 06, 2022 at 02:40:37PM -0400, Phillip Hallam-Baker wrote:
> On Sat, Aug 6, 2022 at 1:53 PM Stephen Farrell 
> wrote:
> > On 06/08/2022 17:47, Phillip Hallam-Baker wrote:
> > > Are you proposing pure Kyber or a hybrid though?
> >
> > I've not heard anyone suggest securing an IETF protocol
> > only via PQC algs. It'd be incredibly dim to make that
> > suggestion IMO, esp now that two of the 3rd round entries
> > have been busted. So I'm not worried that we'd even come
> > close to landing there for TLS.

I remember hearing proposals to use PQC-only in some IETF stuff. I do
not mean hash signatures, which are very solid stuff, but I do not
offhand remember any concrete examples. Agreed that it is not a good
idea at this point.

Another thing to watch out for is stuff that ends up being a
complexity nightmare in practice. E.g., multiple certificate chains
validated in parallel.


> +1
> 
> Anything the WG does has to be proof against Quantum Cryptanalysis and
> LoW (Laptops on Weekends). The fact that the broken algorithms did not
> get picked does not change the fact that they made it to the third
> round.

Actually, there is a big difference in scaryness of the two cases.

For Rainbow, as far as I am aware, the key attack techniques were
very recent, developed during the second and the third rounds of the
NISTPQC. That mostly falls into "new attacks appearing".

For SIKE, it is much much worse. The key attack techniques actually
_predated_ SIDH (which SIKE is based on) by many years. And that still
made it to third round. Now that is scary.


Then there was smaller third oops:

SABER: During late third round, one well-known lattice crypto researcher
asked for cryptoanalysis of the MLWR problem (used in, e.g., SABER).
Turns out there is not much. Mostly some folks applying basic smoke
tests on it (anything failing those is very broken).



-Ilari

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Ilari Liusvaara]

On Fri, Aug 05, 2022 at 10:11:05PM -0700, Benjamin Kaduk wrote:
> Hi Scott,
> 
> On Sat, Aug 06, 2022 at 03:18:31AM +, Scott Fluhrer (sfluhrer) wrote:
> > 
> > I’m trying to figure out what you’re saying; at least one of us is
> > confused.  NIST asked for a Key Exchange Mechanism (KEM), and Kyber
> > meets that definition (which is essentially what you describe; both
> > sides gets a shared secret).  That is the functionality that TLS
> > needs, and is the functionality that NIST (and others) evaluated. 
> > Yes, there are internal functions within Kyber; no one is suggesting
> > those be used directly.  And, yes, NIST might tweak the precise
> > definition of Kyber before it is formally approved; any such tweak
> > would be minor (and there might not be any at all); if they do make
> > such a change, it should not be difficult to modify any draft we put
> > out to account for that change.

My guess about the changes is replacing the four different SHA-3
variants (yup, KYBER uses all of SHA3-256, SHA3-512, SHAKE-128 and
SHAKE-256) with some kind of contextualized SHAKE-256. But That's deep
internals of KYBER, not something TLS WG needs to be concerned about.


> I thought KEM expanded to "Key Encapsulation Mechanism" (viz RFC
> 9180). Indeed, my understanding is that PHB's specific point is
> that it is *not* an exchange, and rather that the sender picks a key
> and the recipient just gets that key without contributing do it.
> (Well, I think there is maybe also some bit in PHB's note that's
> quibbling about how the sender doesn't actually pick the key, and
> rather the local output of the KEM is the encapsulated blob plus the
> shared key, with the shared key not being an input to the KEM ...
> but I haven't read NIST's report yet and can't confirm or reject that
> assertion.)  I am reading PHB as saying that the "internal function"
> within Kyber that is an "actual KEM" is one that takes the shared
> key as input and produces the encapsulated blob as output (again,
> cannot confirm or reject).

Due to how KYBER internally works, the public key does contribute to
the final key (e.g., see page 10 of KYBER specification version 3.02).
This leads to both sides contributing to the key if public keys are
not reused (as is recommended). However, I don't think that that
generically holds for IND-CCA2 KEMs.


> > It was my understanding that TLS 1.3 didn’t do rekeys
> > (ChangeCipherSuite).  Instead, the key agreement is done only at
> > connection establishment time, and could be broken into:
> > 
> >   *   Full negotiation (the client not having any context)
> >   *   Resumption (0-RTT or 1-RTT) negotiation (where the client has
> >   some secret data from a previous full negotiation)
> > Because those are both fresh negotiations, I don’t see any
> > alternative to using a postquantum key exchange for both.
> 
> There's also KeyUpdate.
> And the PSK handshake mode that's just psk_ke, not psk_dhe_ke.
> But I don't think I understand PHB's proposed taxonomy yet, either.

I think the point was that even if PQC key material is just indirectly
chained, the thing is still PQC. Of course, only relying on indirect
chaning is not a great idea.

As for TLS 1.3, there is little problem doing direct PQC for both,
because psk_dhe_ke resumption is possible, and (hybrid) PQC KEMs look
like DH to TLS 1.3.



-Ilari

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

Re: [TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting

[Ilari Liusvaara]

On Fri, Jul 29, 2022 at 01:59:58PM +, Peter Gutmann wrote:
> An additional comment on this, a pretty straightforward solution is
> to use the TLS-LTS one:
 
Unfortunately, that does not work because it would require protocol
modifications requiring coordinated updates to both clients and
servers. Renego fix was over 12 years ago, and I still sometimes hit
servers that have not fixed that.


I think the best current practices are:

Client side:

- Do not implement DH and ECDH.
- Disable DHE entierely.

Server side:

- Do not implement RSA kex.
- Prefer ECDHE to DHE.


No idea what is the best practice DHE size to use on server side if
supported. Note that anything that does not support TLS 1.2 (since it
can not connect) or supports ECDHE (since ECDHE is preferred) is
irrelevant here. For 1024-bit, one wants custom group, for 2048-bit
one wants ffdhe2048.



-Ilari

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

Re: [TLS] PQC key exchange sizes

[Ilari Liusvaara]

On Wed, Jul 27, 2022 at 02:27:12AM +, Kampanakis, Panos wrote:
> Hi Ilari,
> 
> > - DTLS-level fragmentation. There are buggy implementations that
> >   break if one tries this.
> 
> DTLS servers have been fragmenting and sending cert chains that don’t
> fit in the MTU for a long time. Is this buggy on the TLS client side?

These problems are specific to fragmenting Client Hello. Handling
fragmented DTLS Client Hello is different from handling fragmented
DTLS Certificate (and even more so in DTLS 1.3). I think DTLS
specification just pretends both cases are the same. They are not.


QUIC implementations could have similar issues with multiple initial
packets, but operating QUIC with fast failure-independent fallback
would make failures soft.


There is the general principle that if some protocol feature is not
used in the wild, it tends to break, even if required part of the
protocol. Either by implementation being poorly tested and buggy,
assuming the feature does not exist, or being missing entierely.
Combine this with interop failures having outsize impact and old
versions sticking around far longer than desriable. And I do not think
fragmented Client Hellos in DTLS or multiple initials in QUIC are seen
much.


One trick with DTLS would be sending client hello with no key
shares. Causes extra round-trip, but any server that selects PQC
causing fragmentation would presumably be capable of handling that.



-Ilari

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

Re: [TLS] PQC key exchange sizes

[Ilari Liusvaara]

On Tue, Jul 26, 2022 at 02:15:34PM +0200, Thom Wiggers wrote:
> 
> In yesterday’s working group meeting we had a bit of a discussion of the
> impact of the sizes of post-quantum key exchange on TLS and related
> protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide
> deck (unlike the signature schemes), I thought it would be a good idea to
> get the actual numbers of Kyber onto the mailing list.
> 
> Note that in the context of TLS’s key exchange, the public key would be
> what goes into the ClientHello key_shares extension, and the ciphertext
> would go into the Server’s ServerHello key_shares extension.
> 
> Kyber512: NIST level I, "strength ~AES128"
>   public key: 800 bytes
>   ciphertext: 768 bytes
>   secret key: 1632 bytes
> Kyber768: NIST level III, "~AES192"
>   public key: 1184
>   ciphertext: 1088
>   secret key: 2400 bytes
> Kyber1024: NIST level V, "~AES256"
>   public key: 1568
>   ciphertext: 1568
>   secret key: 3168
> 
> So for the key exchange at least, it seems to me Kyber512 should work for
> TLS and QUIC just fine; Kyber768 might be a bit of a squeeze if you want to
> stay in QUIC’s default 1300 byte initial packet? Also, I don't really know
> how the D of DTLS might change the story.

The initial packet size is 1200, so Kyber768 public key does not fit
into a packet. However, the initial packets can be split, so even
Kyber1024 key does fit into two initial packets (this also doubles the
server initial window from 3600 to 7200 due to the way amplification
limit works)


DTLS is a bit more problematic. There are two ways to deal with the key
being too big to fit in a single IP packet.

- IP-level fragmentation. REALLY SHOULD NOT be used.
- DTLS-level fragmentation. There are buggy implementations that break
  if one tries this.

And in both case, the failure modes are not easy to recover from.




-Ilari

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

Re: [TLS] Transcript ambiguity in cTLS

[Ilari Liusvaara]

On Mon, Jul 25, 2022 at 06:47:53PM -0400, Ben Schwartz wrote:
> I noticed some confusion today about the topic of ambiguous
> transcripts in cTLS.  My claim was not that any single cTLS profile
> has an ambiguous transcript.  If such a thing were true, I believe
> that would be a bug in the cTLS specification.
> 
> Instead, I was trying to highlight the concern of "profile confusion"
> attacks, in which an attacker is able to convince the two parties
> that different profiles (with the same ID) are in use.  In these
> cases, the two parties can verify their agreed-upon transcript,
> but interpret it differently, which could lead to vulnerabilities.
> 
> Including the "template" in the transcript rules out these attacks.
> However, this protection depends on the use of a strong transcript
> hash in the Finished message, and shortening or omitting this hash
> has also been discussed.
> 
> As you can see, there are still many interesting open questions
> related to cTLS.

Furthermore (this is just from "known unknown" category):

- The impact of shortening the finished is probably different for PSK
  versus certificate modes.
- Impact of record protection probably can not be ignored if finished
  is shortened. Traditional TLS 1.3 security analysis ignores RP
  completely (conservative choice to make analysis easier).
- None of the common record protectors in TLS 1.3 are committing
  (except the NULL ones!), which might have an impact on security
  analysis.
- PSK has binders, which are finished-like, but not protected. The
  impact of shortening those is probably very different from impact
  of shortening actual finished.




-Ilari

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

Re: [TLS] I-D Action: draft-ietf-tls-ctls-06.txt

[Ilari Liusvaara]

On Mon, Jul 11, 2022 at 05:03:03PM -0400, Ben Schwartz wrote:
> Thanks for the detailed review!  I've proposed some changes to address most
> of your comments (https://github.com/tlswg/draft-ietf-tls-ctls/pull/70).
> Some additional questions below.
> 
> On Sun, Jul 10, 2022 at 11:54 AM Ilari Liusvaara 
> wrote:
> 
> > On Sat, Jul 09, 2022 at 02:32:07PM -0700, internet-dra...@ietf.org wrote:
> >
> ...
> 
> > Reviewing this (again after version update):
> >
> >
> > 1) Section 1. Introduction:
> >
> > > More compact encodings, for example point compression.
> >
> > I think it would be better to define compact versions of NIST curves
> > (and maybe Brainpool curves too) and register those into supported
> > groups registry (where those could also be used in (D)TLS).
> >
> 
> Would this actually help in ordinary (D)TLS, or would the extra bytes
> needed to advertise the additional supported algorithms in the ClientHello
> outweigh the savings from a compact representation?

Not quite sure if I understand right, but adding 3 compact NIST curves
and replacing P-256 -> P-256-compact for share would be net 27 octets
saved (33 for smaller share, minus 6 bytes for extra groups).

> ...
> 
> > 3) Section 2.1.1. Initial template elements
> >
> > I think the following should be added:
> >
> > - More efficient ECDSA signature encoding. Right now, ECDSA signatures
> >   use ASN.1 encoding, which is very inefficient in communication-
> >   constrained environments. Using simple concatenate-raw-r-and-s
> >   encoding would be more efficient.
> >
> 
> Would you do this by registering new SignatureSchemes, similar to your idea
> of defining new NamedGroups above?

I had an idea for compression knob to do this, but I suppose
SignatureScheme could be used too.
 
> 
> > - Option to force extension blocks on any chain certificates to be
> >   empty. Those are very rarely used for anything.
> >
> 
> Could you clarify what you mean by "chain certificates"?  Are you including
> leaf certificates in that definition?

Oh, sorry. All except the leaf.

> I have the impression that Signed Certificate Timestamps and OCSP Stapling
> both use CertificateEntry.extensions, and are widely used, including on
> intermediate certificates.

Yes, both SCTs and OCSP use ce-extensions. I do not think I have ever
seen those used on intermediates. WebPKI rules make intermediate OCSP
stapling useless (there are more serious PKIs where using intermediate
OCSP would be useful tho). Intermediate stapling of SCTs would be useful
for some usecases, but what servers support that?

The TLS implementation I have written does support OCSP and SCT stapling
on leaf certificate (both sending and receiving), but the intermediate
extensions is hardcoded to be empty when sending, and those extensions
are mostly ignored (parsed, but not anything else).


> ...
> 
> > 9) Section 2.2. Record Layer
> >
> > The E bits should presumably be hardwired to zero on reliable/ordered
> > transports. As reliable/ordered corresponds to TLS 1.3, and TLS 1.3
> > has no equivalent of E bits (as it never needs to handle out-of-order
> > key update).
> 
> 
> This is an interesting question.  I would expect that the E bits are set by
> the sender as they would be for DTLS, and perhaps are ignored by the
> receiver.  However, I suppose this might reveal the use of KeyUpdates that
> would otherwise be undetectable...

Another way to look at it: TLS has no epoch (searching RFC 8446 for
"epoch" gives nothing), epoch is DTLS-specific concept.


Another thing: ScTLS can not migrate (TLS requires reliablity, but
DTLS/QUIC-style migration requires unreliability) and inherently
requires channeling from underlying transport, so I do not think
connection ID makes any sense in ScTLS.



-Ilari

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

Re: [TLS] I-D Action: draft-ietf-tls-ctls-06.txt

[Ilari Liusvaara]

On Sat, Jul 09, 2022 at 02:32:07PM -0700, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : Compact TLS 1.3
> Authors : Eric Rescorla
>   Richard Barnes
>   Hannes Tschofenig
>   Benjamin M. Schwartz
>   Filename: draft-ietf-tls-ctls-06.txt
>   Pages   : 24
>   Date: 2022-07-09

Reviewing this (again after version update):


1) Section 1. Introduction:

> More compact encodings, for example point compression.

I think it would be better to define compact versions of NIST curves
(and maybe Brainpool curves too) and register those into supported
groups registry (where those could also be used in (D)TLS).


2) Section  2.1. Template-based Specialization:

> OPEN ISSUE: Is it really worth converting snake_case to camelCase?
> camelCase is slightly more traditional in JSON, and saves one byte,
> but it seems annoying to implement.

I think both are equally bad choices, with implementation complexity
dominated by having table mapping names to codepoints.

And I remember many TLS 1.2 implementations using nonstandard forms of
ciphersuite names in ciphersuite configuration (e.g., OpenSSL).


3) Section 2.1.1. Initial template elements 

I think the following should be added:

- More efficient ECDSA signature encoding. Right now, ECDSA signatures
  use ASN.1 encoding, which is very inefficient in communication-
  constrained environments. Using simple concatenate-raw-r-and-s
  encoding would be more efficient.
- Option to force extension blocks on any chain certificates to be
  empty. Those are very rarely used for anything.


4) Section 2.1.1.5. signature_algorithm 

This should presumably omit CertificateVerify.algorithm, and make
CertificateVerify.signature a static vector if signature has constant
length (e.g., EdDSA, concatenate-r-and-s encoding of ECDSA).


5) Section 2.1.1.6. random 

> OPEN ISSUE: Karthik Bhargavan suggested the idea of hashing ephemeral
> public keys and to use the result (truncated to 32 bytes) as random
> values. Such a change would require a security analysis.

Another idea: If using ephemeral public keys, just set random=0 (as
the random field was not actually doing anything anyway). However,
if not using ephemeral public keys, repeating a random value is very
bad idea (on server side it is bad to repeat random value pair), let
alone setting random=0.


6) Section 2.1.1.8. client_hello_extensions, server_hello_extensions,
   encrypted_extensions, and cert_request_extensions 

In client_hello_extensions, extension 41 needs special handling, as
the corresponding extension is magic in TLS 1.3 (it has to be the last
extension).


7) Section 2.1.1.10. handshake_framing 

This section does not seem to handle the case of SEQPACKET transport:
Ordered, reliable and packetized. Such transport is neither stream nor
datagram transport. However, it should be treated like stream transport
here (that is, use ScTLS).

This seems to have further problem of being the only place that selects
between ScTLS and DcTLS. I would expect this to be in some more central
place than discussion of some (bit obscure) knob.

Then I don't see anywhere that DcTLS presumably uses the whole ACK
machinery from DTLS, but ScTLS does not.


8) Section 2.2. Record Layer

This gets the SEQPACKET case right: !stream and reliable/ordered gives
desired properties (allowing omitting lengths and no sequence numbers).


9) Section 2.2. Record Layer 

The E bits should presumably be hardwired to zero on reliable/ordered
transports. As reliable/ordered corresponds to TLS 1.3, and TLS 1.3
has no equivalent of E bits (as it never needs to handle out-of-order
key update).


10) Section 2.3.2. The Transcript layer 

If one has many clients using client certificate authentication in
communication-constrained environment, one likely wants to use per-
client profile. This avoids blowing up client storage and updates with
client certificates. The server is likely much better equipped to handle
the storage demands.

(Took me far too much time to come up with this.)


11) Section 3.3. HelloRetryRequest 

> OPEN ISSUE: Does server_hello_extensions apply to HelloRetryRequest?

The format of extensions in server_hello and hello_retry_request is
not even the same:

- tls_cert_with_extern_psk, pre_shared_key and connection_id are only
  valid in server_hello.
- cookie is only valid in hello_retry_request.
- key_share only has the key_exchange field only in server_hello.
- (I can't make heads or tails about what is going on with Dragonfly).


12) Section  5. Security Considerations 

> Transcript expansion also needs some analysis and we need to
> determine whether we need an extension to indicate that cTLS is in
> use and with which profile.

Wasn't transcript 

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-01.txt

[Ilari Liusvaara]

On Thu, Jul 07, 2022 at 09:25:15PM -0700, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
>   Sean Turner
>   Filename: draft-ietf-tls-rfc8447bis-01.txt
>   Pages   : 24
>   Date: 2022-07-07

I find this from section 7 confusing:

>   *  IANA [SHALL update/has updated] this registry to include a "TLS
>  1.3" column that lists the messages in which the extension may
>  appear.  This column [SHALL be/has been] initially populated from
>  the table in Section 4.2 of [I-D.ietf-tls-rfc8446bis] with any
>  extension not listed there marked as "-" to indicate that it is
>  not used by TLS 1.3.

The issue here is:

- The [SHALL/has] language means pending change.
- The TLS 1.3 column in the registry already exists.
- There are about dozen TLS 1.3 extensions in the extensions registry
  that are not in the table in RFC8446bis (few are even recommended).
- The text can be read to clear TLS 1.3 flags on those ~dozen
  extensions, which I do not think is intended.


There's also this:

>   *  IANA [SHALL update/has updated] this registry to include the
>  "key_share", "pre_shared_key", "psk_key_exchange_modes",
>  "early_data", "cookie", "supported_versions",
>  "certificate_authorities", "oid_filters", "post_handshake_auth",
>  and "signature_algorithms_cert", extensions with the values
>  defined in [I-D.ietf-tls-rfc8446bis] and the "Recommended" value
>  of "Y".

As far as I can tell, the values in the registry already match what is
listed in rfc8446bis (other than maybe references).


And while going over this, I also found that extension #52
transparency_info seems to have recommended=Y. The problem is that
the RFC9162 is Experimental, while recommended=Y requires standard
action.



-Ilari

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

Re: [TLS] Draft TLS Extension for Path Validation

[Ilari Liusvaara]

On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote:
> Hi TLS,
> 
> I have just submitted a draft TLS Extension for Path Validation 
> https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt 
> 
> 
> The proposal is for a Path Validation Extension to provide a new
> protocol for TLS/DTLS allowing inclusion of certificate path
> validation information in the TLS/DTLS handshake. Specifically, it
> covers the use of Server-based Certificate Validation Protocol
> (SCVP) for path validation.

Looking at how this is integrated to (D)TLS:


For (D)TLS 1.2, the server extension does not seem to be technically
necressary, and omitting it could simplify things. Yes, this design
is the same as one used for OCSP stapling (status_request), but I
found the server hello extension in OCSP to be seemingly unnecressary
extra complexity.

For (D)TLS 1.3, why there are seemingly two server extensions, one in
server hello, which is usually only used for low-level crypto stuff,
which this is not, and another in certificate message (which makes
sense for certificate-related thing.


And this is maybe a stupid question, but I didn't find an answer by
quickly looking at the draft nor the SCVP RFC, does the server need to
send the certificate chain to the client if it sends the SCVP response,
or just the end-entity certificate? Omitting the chain could save
quite a bit of handshake size.



-Ilari

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

Re: [TLS] Client programs and stapling?

[Ilari Liusvaara]

On Fri, May 20, 2022 at 01:23:31PM -0400, David Benjamin wrote:
> On Fri, May 20, 2022 at 1:07 PM Salz, Rich  wrote:
> 
> > Do client programs staple a status when sending a cert to the server? It
> > seems possible, someone just asked me if anyone does it.
> >
> Prior to TLS 1.3, it wasn't possible because the Certificate message
> didn't have extensions. Starting TLS 1.3, it looks like we did define
> status_request to be allowed in either direction. We (BoringSSL)
> never implemented the client certificate direction, since we haven't
> needed it yet. We just ignore the extension if we see it in
> CertificateRequest. At a glance, it looks like OpenSSL does the same.
> Dunno about other implementations.

Looking at what my implementation does, if an application gives the
library an OCSP staple to send, it will be sent if server requests one.
However, I do not think any application using the library does that, so
in practice OCSP never gets stapled into client certificate.

(Similar thing appliles to Signed Certificate Timestamp (Certificate
Transparency) stapling, and in some very recent versions, Transparency
Item (Certificate Transparency 2.0) stapling.)



-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Sat, Apr 30, 2022 at 04:48:59PM +0100, Stephen Farrell wrote:
> 
> On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> > > 
> > > On 27/04/2022 16:27, Christopher Wood wrote:
> > > > This email commences a two week WGLC for draft-ietf-tls-hybrid-design, 
> > > > located here:
> > > > 
> > > >  https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
> > > 
> > 
> > However, I did come up with compression method:
> > 
> > 1) Sub-shares in CH may be be just replaced by a group id (two octets).
> > The replacements can be deduced from length of the whole share.
> > 2) First sub-share copies from first octets of share for the designated
> > group.
> > 3) Second sub-share copies from last octets of share for the designated
> > group.
> > 
> > This can be decoded regardless of if the sever knows what the referenced
> > groups are. The compression can also never run into loop, as recursive
> > references are not allowed.
> > 
> > 
> > So for example, if one wants to send x25519, p256, x25519+saber and
> > p256+saber, one can do that as:
> > 
> > - x25519:  (32+4 octets)
> > - p256:  (65+4 octets)
> > - x25519+saber:  (2+992+4 octets)
> > - p256+saber:  (2+2+4 octets)
> > 
> > Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression
> > itself.
> 
> So yes that could work. We'd need to think through how
> it'd interact with the ECH scheme were both to end up
> standardised.

The ECH scheme copies entiere extensions whereas this works inside
the key_share extension, so I do not see any nontrivial interactions.
Furthermore the extension involved (key_share) REALLY SHOULD NOT
differ between inner and outer hello.


(The same analysis that says that key_share should not differ between
inner and outer hellos also trips my hinky detection on interaction
between ECH and PSK. And those interactions look much too complicated
for me to analyze.)


> > > - I'm also HRR-confused - if we don't yet know the
> > > details of the range of possible PQ KEM algs we want to
> > > allow here, how do we know that we almost always continue
> > > to avoid HRR in practice and thus benefit from a mixture of
> > > classic and PQ algs? (It's also a bit odd that HRR,
> > > much as I dislike it, doesn't get a mention here;-) I
> > > think the problem is that we don't want HRR to push a
> > > client back to only "classic" groups, if the client but
> > > not the server is worried about PQ stuff while both
> > > prioritise interop.
> > 
> > Well, avoiding HRR impiles that client is willing to bloat its client
> > hello even for servers that do not support PQ. And for such clients,
> > using PQ at all requires servers to priorize it (send HRR even if
> > acceptable share is present).
> 
> I don't understand the above sorry;-)
> 
> ISTM one would need to analyse/guess what'll happen with
> this scheme and HRR before being done. Maybe someone's
> done that but if so, I'm surprised there's no mention in
> the draft.

Well, three scenarios:


1) PQ without HRR:

Client hello (large): Hybrid key share, classical key share.
Server hello: Hybrid key share.


2) PQ with HRR:

Client hello (small): Hybrid supported, classical key share.
Server hello: Restart handshake, hybrid.
Client hello (large): Hybrid key share, classical supported.
Server hello: Hybrid key share.

(The "Hybrid supported, classical key share." turning into "Hybrid
key share, classical supported." is due to standard TLS rules on
HRR.)


3) Failure to use PQ even if supported by both sides:

Client hello (small): Hybrid supported, classical key share.
Server hello: Classical key share.

 
> > 
> > > - section 4: if this cannot support all NIST finalists
> > > due to length limits then we're again being premature
> > > esp. if NIST are supposed to be picking winners soon.
> > > We'd look pretty dim if we didn't support a NIST winner
> > > for this without saying why.
> > 
> > Just yeet McEliece. Its keys are just too large for it to be practical
> > in TLS, even if the keys did not bust hard limits.
> > 
> > After removing McEliece from consideration, all the finalists and
> > alternates can trivially be supported (albeit FrodoKEM busts some
> > soft limits).
> 
> Nonetheless, this is another respect in which the draft
> text has to remain incomplete because we're IMO progressing
> it too soon.

I disagree. None of this stuff will change. The reason why current
app

Re: [TLS] DTLSv1.3: Record Number in AEAD computation

[Ilari Liusvaara]

On Mon, May 02, 2022 at 10:58:50AM +0200, Marco Oliverio wrote:
> Hi all,
> 
> In the RFC9147, in the last paragraph of Section 4 it's stated:
> 
> """
> This 128-bit value is used in the ACK message as well as in the
> "record_sequence_number" input to the Authenticated Encryption with
> Associated Data (AEAD) function.
> """
> 
> But the very last sentence of the same paragraph states:
> 
> """
> In DTLS 1.3 the 64-bit sequence_number is used as the sequence number
> for the AEAD computation; unlike DTLS 1.2, the epoch is not included.
> """
> 
> Aren't these statements contradictory?
> 
> I think only the 64-bit sequence number is meant to be used and the
> first paragraph is a replace-error done while increasing the epoch
> size from the last draft.

Yes, the sequence number in AEAD is meant to be 64-bit. 128-bit sequence
number is not compatible with any mainstream TLS 1.3 ciphersuite (since
it would require nonce at least 16 octets, but all main ciphers have 12
octet nonces).

And there are further problems. What is the "record_sequence_number"
input? That sentence is the only match for 'record_sequence_number'
in RFC9147, and there are no matches in RFC8446.


I also found this in section 4.1:

"If the first byte is alert(21), handshake(22), or ack(proposed, 26),
the record MUST be interpreted as a DTLSPlaintext record."

I presume "proposed" should not be there (ACK is indeed ContentType 26).



-Ilari

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

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[Ilari Liusvaara]

On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 27/04/2022 16:27, Christopher Wood wrote:
> > This email commences a two week WGLC for draft-ietf-tls-hybrid-design, 
> > located here:
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
> 
> As I guess I've said before, I think progressing this draft
> now, even with this WGLC-then-park approach, is premature.
> 
> However, I seem to be in the rough on that so can live with
> this ad-hoc process (teeth grinding mind you:-) so long as we
> park this for a sufficient period *and* are open to changing
> anything at the end of the parking-lot period.
> 
> Even so, I think this is not yet ready for any such ad-hoc
> parking-lot:
> 
> - section 1.5 implies a wish to reduce the number of
> octets sent - ECH creates a way to point from one part
> of the (encrypted, inner) ClientHello to another (the
> outer ClientHello). I don't think we want two such
> mechanisms, or one mechanism defined in ECH but none at
> all here, or even worse a second method. For me, that
> implies not "freezing" the structural work here 'till
> we see if ECH gets widespread deployment at which point
> we should consider re-use of the ECH mechanism. (Or maybe
> even consider both cases of re-using octets and invent
> another thing, but not 'till we see if ECH gets traction.)

I don't think compression method like ECH uses would work here.

However, I did come up with compression method:

1) Sub-shares in CH may be be just replaced by a group id (two octets).
   The replacements can be deduced from length of the whole share.
2) First sub-share copies from first octets of share for the designated
   group.
3) Second sub-share copies from last octets of share for the designated
   group.

This can be decoded regardless of if the sever knows what the referenced
groups are. The compression can also never run into loop, as recursive
references are not allowed.


So for example, if one wants to send x25519, p256, x25519+saber and
p256+saber, one can do that as:

- x25519:  (32+4 octets)
- p256:  (65+4 octets)
- x25519+saber:  (2+992+4 octets)
- p256+saber:  (2+2+4 octets)

Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression
itself.


> - section 2: if "classic" DH were broken, and we then
> depend on a PQ-KEM, doesn't that re-introduce all the
> problems seen with duplicating RSA private keys in
> middleboxes? If not, why not? If so, I don't recall
> that discussion in the WG (and we had many mega-threads
> on RSA as abused by MITM folks so there has to be stuff
> to be said;-)

No. The private key is held by the client, and client sends the public
key to use in its client hello. Furthermore, every connection should use
different public key.

> - similar to the above: if PQ KEM public values are
> like RSA public keys, how does the client know what
> value to use in the initial, basic 1-RTT ClientHello?
> (sorry if that's a dim question:-) If the answer is
> to use something like a ticket (for a 2nd connection)
> then that should be defined here I'd say, if it were
> to use yet another SVCB field that also ought be
> defined (or at least hinted at:-)

Whatever public key the keygen() operation outputs.

> - I'm also HRR-confused - if we don't yet know the
> details of the range of possible PQ KEM algs we want to
> allow here, how do we know that we almost always continue
> to avoid HRR in practice and thus benefit from a mixture of
> classic and PQ algs? (It's also a bit odd that HRR,
> much as I dislike it, doesn't get a mention here;-) I
> think the problem is that we don't want HRR to push a
> client back to only "classic" groups, if the client but
> not the server is worried about PQ stuff while both
> prioritise interop.

Well, avoiding HRR impiles that client is willing to bloat its client
hello even for servers that do not support PQ. And for such clients,
using PQ at all requires servers to priorize it (send HRR even if
acceptable share is present).

> - section 4: if this cannot support all NIST finalists
> due to length limits then we're again being premature
> esp. if NIST are supposed to be picking winners soon.
> We'd look pretty dim if we didn't support a NIST winner
> for this without saying why.

Just yeet McEliece. Its keys are just too large for it to be practical
in TLS, even if the keys did not bust hard limits.

After removing McEliece from consideration, all the finalists and
alternates can trivially be supported (albeit FrodoKEM busts some
soft limits).

> - section 5: IMO all combined values here need to have
> recommended == "N" in IANA registries for a while and
> that needs to be in this draft before it even gets
> parked. Regardless of whether or not the WG agree with
> me on that, I think the current text is missing stuff
> in this section and don't recall the WG discussing that

I think that having recommended = Y for any combined algorithm requires
NIST final spec PQ part and recommended 

Re: [TLS] Can flags be responded to with an extension?

[Ilari Liusvaara]

On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> Consider the case where the client wants to offer some capability that
> the server then responds to with real data, rather than just an
> acknowledgement.
> 
> For instance, supposing the SCT extension from RFC 6962 did not exist,
> the client would want to indicate support in CH and the server would
> send the SCT in CERT, but this extension would need to be non-empty
> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> uncelar on this point (unless I'm missing it) but I think we
> should explicitly allow it.
> 
> Thoughts?

There is actually precedent for stuff like this (even if it is a nasty
hack): The TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite. The reply to
that is the renegotiation_info extension, even if that extension was
not present in the client hello.

However, that one is not exactly pleasant to implement in TLS library,
Looking at source of my TLS library, it has some magic hacks in order
to support parsing client hello with TLS_EMPTY_RENEGOTIATION_INFO_SCSV.



-Ilari

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

Re: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

[Ilari Liusvaara]

On Tue, Mar 01, 2022 at 09:21:02AM -0500, Sean Turner wrote:
> Thanks to all that responded.
> 
> I have create this issue:
> https://github.com/tlswg/tls-subcerts/issues/94
> And this PR to address the issue:
> https://github.com/tlswg/tls-subcerts/pull/95

I do not think the TLS context string should be changed. That breaks
compatiblity, and this extension already has seemingly permanent IANA
registration. So I think that change is far from harmless.



-Ilari

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara]

On Sat, Feb 19, 2022 at 04:28:52PM -0500, Ryan Sleevi wrote:
> On Sat, Feb 19, 2022 at 6:15 AM Ilari Liusvaara 
> wrote:
> 
> > > - Connection re-establishment affects the security and privacy
> > > assumptions and should be captured. I am not sure the concern is
> > > worse than the regular fingerprinting text already in the draft,
> > > but point taken. We can improve the text and I created an issue
> > > for it.
> > https://github.com/csosto-pk/tls-suppress-intermediates/issues/12
> >
> > Regarding security and privacy, the most severe impact of any attack
> > I can come up with is determining if some arbitrary ICA is on the
> > ICA list or not (for passive attacks, that is restricted to the issuing
> > ICA used by the server). Practical impact of attacker being able to do
> > that depends on how many endpoints share that same ICA list.
> >
> > Rough outline of the attack (active variant): Fabricate a certificate
> > purporting to be from some ICA, send it to client and observe if the
> > client retries (ICA not on the list) or just fails (ICA is on the list).
> 
> 
> I'm hopeful that some may be interested to perform a more thorough
> analysis. We saw enough complexity with respect to previous TLS versions
> and the fallback logic being possible to induce downgrade attacks that I
> think we should be very wary about introducing a class of anticipated
> handshake failures that require connection re-establishment, especially
> across independent TLS sessions. I realize that sounds a little like FUD,
> but rather: every time we've tried to do this, it's blown up spectacularly,
> so we need to make sure we're not setting up another bomb.

I have hard time seeing how one could construct downgrade attack out of
this, as it just requests extra data from server on fallback. For most
other retry stuff, downgrade attack risk is obvious as less secure modes
are introduced / more secure modes are removed.
 
> I also think the active attack analysis is a bit lacking, especially since
> the attacker has the ability to mint arbitrary ICAs on demand, without
> running afoul of any existing client policies. For example, for the Web
> PKI, by virtue of nameConstraints without pathLen in the basicConstraints,
> the site can mint arbitrary ICAs and arbitrary EE certificates. Combined
> with the discovery mechanism discussed, this is effectively the same as
> other forms of stateful tracking (ala HSTS tracking), and thus likely to be
> subjected to the same mitigations that would largely render the benefits
> here ineffective, at best.

Having pathLen >= 1 would do as well, right?

And such ICAs can already be abused for tracking if the browser does
transvalidity. Suppress ICAs flag would make it worse, by allowing other
sites to read such tracking supercookies.

Defense is not doing transvalidity nor cached AIA chasing (since those
caches represent state that could be attacked). This closes the attack
for both with and without suppress ICAs.

Another defense to make reading ICA list harder would be to always
trigger fallback if certificate validation fails and ICAs were
suppressed.

Neither defense would render suppress ICAs ineffective, since in vast
majority of cases one can use quasi-static ICA list to buld verifiable
certificate chain and then use that with no fallback.



-Ilari

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara]

On Sat, Feb 19, 2022 at 03:59:23AM +, Kampanakis, Panos wrote:

> - If we can assume an OOB mechanism to load the ICAs then we can
> simplify things. Practically we can assume there is no failure.
> Agreed, but I am not sure that we should not include any
> non-normative language for the inadvertent corner case though.
> There should be a fallback, one that we are assuming will never
> happen, but an implementer should account for it.

It seems to me that the dominant failure modes are:

- Using old ICA list that is missing some newly minted ICA.
- Using custom TA that is missing ICA data.


> - Connection re-establishment affects the security and privacy
> assumptions and should be captured. I am not sure the concern is
> worse than the regular fingerprinting text already in the draft,
> but point taken. We can improve the text and I created an issue
> for it. https://github.com/csosto-pk/tls-suppress-intermediates/issues/12

Regarding security and privacy, the most severe impact of any attack
I can come up with is determining if some arbitrary ICA is on the
ICA list or not (for passive attacks, that is restricted to the issuing
ICA used by the server). Practical impact of attacker being able to do
that depends on how many endpoints share that same ICA list.

Rough outline of the attack (active variant): Fabricate a certificate
purporting to be from some ICA, send it to client and observe if the
client retries (ICA not on the list) or just fails (ICA is on the list).


> I would be interested to track how that ICA list has been changing
> over time. Let’s see if we can get data on that for FFs preload
> list, Filippo’s or others.

I only have some isolated random datapoints on number of disclosed
WebPKI ICAs since 2021-02-08 (a bit over year ago), but during that
time, that number has grown from 1669 to 1820.



-Ilari

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara]

On Fri, Feb 18, 2022 at 04:47:09AM +, Kampanakis, Panos wrote:
> 
> About the tlsflags, make sense. It would simplify things too. The
> impression I got from the old draft-thomson-tls-sic thread and the
> tlsflags draft was that it mandates an acknowledgement. I will
> confirm with Yoav. 

The text in tlsflags looks like it mandates an acknowledgement,
but I think it might be just confusing text.

Regarding actual need for acknowledgement for this flag, I think that
server acknowledging it could be useful so client knows if retrying
without flag could be useful or not.

For the client acknowledging it, I find that much less useful. If
server proposes the extension, it better have exhaustive issuer
list, be using certificates as just holders for raw public keys,
or using certificate fingerprints for identification. Anything
else looks like it is asking for trouble.



-Ilari

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara]

On Wed, Feb 16, 2022 at 05:45:47AM +, Kampanakis, Panos wrote:
> Good comments, thank you Ilari. 
> 
> To answer your comments  
> 
> > 1) There are a few "shall" in the text. Should those be "SHALL"?
> 
> The two "shall" refer to draft-ietf-tls-tlsflags. Based on experience
> from previous drafts, we do not want to repeat normative language
> from another draft, so we kept them lowercase. We can still consider
> making them normative though. 

I think the language in tlsflags about acknowledging extensions is
confusing. Tlsflags behavior should be similar to extensions, which do
not have acknowledgment requirement in base TLS (any acknowledgement
requirement is per extension). So I think any acknowledgement
requirement should be explicitly stated normatively.

As to why I find tlsflags language confusing: I think flags as
shorthand for empty extensions, and TLS extensions can be capability
advertisments (no reply). E.g., compress_certificate, which happens
to add a new HandshakeType.


> > 3) Why there are two flags? I do not see a case where both would
> > be sent in the same message.
> 
> In the original draft there was only one. But we want for both the
> client and server (CertReq) to be able to signal to their peer to
> suppress CAs. draft-ietf-tls-tlsflags defines that the peer needs to
> acknowledge the flag, thus we needed one per direction. 

There are no less than four existing TLS extensions (and flags work
similarly to extensions), which work in both directions with the
same codepoint, in the IANA registry:

- status_request
- signed_certificate_timestamp
- delegated_credentials
- transparency_info

And there does not seem to be a percedent for extension that works in
both directions, but with different codepoints.

 
> > 4) In WebPKI, there are some cornercases (constrained ICAs) where
> > the client might be missing a certificate or certificates in the
> > chain. Currently the WebPKI root program rules allow not disclosing
> > "technically constrained" certificates (but there are plans to
> > change this).
> 
> Good point. That has come up in discussions with my co-authors. As
> Martin was pointing out, a lot hinges on the semantics of the
> tls_flags bit.  We probably can say that it means "I have all the
> intermediates I am willing to accept".  That's a little too absolute
> for the web PKI as it stands. We don't have stats on how often we'd
> fail as a result; we would have to check but unconstrained
> intermediates probably isn't exceptional. The flag should probably
> say "I have all the *unconstrained* intermediates that I'm willing
> to accept" or maybe "I have all the intermediates from that I'm
> willing to accept, unless it's the WebPKI and then I only have
> unconstrained intermediates"' 

I would expect constrained intermediates to be quite rare. IIRC, there
is a lot of red tape in Baseline Requirements about constrained ICAs.

> But if MSRP 2.8 adds constrained intermediates, then "I have all the
> intermediates I am willing to accept" may just suffice. 

MSRP 2.8 is slated for this year, so it might very well fix this issue
for WebPKI.

Another way to address the issue would be to write some text that the
server might want to send any ICA that has not been publically
disclosed. As that is neutral to PKI and is exactly what makes
constrained ICAs problematic here.


> > 5) In the client auth scenario, the server might have exhaustive
> > list of all issuing ICAs it accepts, so including any ICAs is never
> > necressary. However, this might be handled even currently by not
> > giving the client a chain. However, doing this in other direction
> > can be quite dangerous without prior agreement.
> 
> I am not sure I am following that argument. If the client does not
> have a chain what happens if the server does not have all
> intermediates?

Sending ICA will not help: The authentication would still fail.

But actually, if using public PKI certificates for client auth (usually
not a great idea), then this can fail rather badly with legacy servers
that do not have issuing ICA lists at all.

> By quite dangerous do you mean that if they have not pre-agreed on
> the ICA list there could be an auth failure and recovery will not
> be easy because the server can't track the clients it is expecting
> ICAs from? Am I getting you right? 

The problem is legacy clients. If one of those connects to the server
and server omits the chain, that will cause handshake failure.

Unfortunately, currently there are fair amount of misconfigured servers
that behave this way.



-Ilari

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

[TLS] dnssec_chain entry in IANA registry seems to be missing CT

[Ilari Liusvaara]

I noticed that the "dnssec_chain" extension in the IANA registry lists
only "CH" in the "TLS 1.3" column. However, the extension sends its
response in the certificate message (section 2.2), so I think that
column should read "CH, CT".


-Ilari

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

Re: [TLS] Implementations of draft-ietf-tls-flags and draft-ietf-tls-cross-sni-resumption

[Ilari Liusvaara]

On Thu, Feb 03, 2022 at 09:53:16AM -0800, Christopher Wood wrote:
> 
> On Feb 3, 2022, at 9:49 AM, Jens Guballa  wrote:
> > 
> > Thanks for the clarification. Is there a value reserved for the
> > tls-flags extension? I couldn't find one, neither in the draft
> > nor in the IANA registry.
> 
> Nope, not yet. We still need to get a codepoint for the extension.
> We can probably do that now. =)

On assigning the value, I noticed the draft talks about including the
flags extension in literially every TLS message with extension block.
However, the IANA assignment request only has "CH,SH,EE" (in both -08
and Git HEAD). I think that should be "CH,HRR,SH,EE,CR,CT,NST" (or
however those should be ordered).


-Ilari

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

Re: [TLS] New Version Notification for draft-kampanakis-tls-scas-latest-00.txt (ICA Supression)

[Ilari Liusvaara]

On Mon, Feb 14, 2022 at 03:33:05AM +, Kampanakis, Panos wrote:
> Hi TLS WG,
> 
> This draft draft-kampanakis-tls-scas-latest is attempting to resurrect
> Martin’s original draft-thomson-tls-sic. It proposes using two new TLS
> 1.3 flags (draft-ietf-tls-tlsflags ) to signal to the TLS server or
> client to not send its Intermediate CA (ICA) certificates. 
> 
> Feedback and discussion are welcome. 
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: Sunday, February 13, 2022 2:34 PM
> To: Bas Westerbaan ; Bytheway, Cameron 
> ; Martin Thomson ; Kampanakis, Panos 
> 
> Subject: [EXTERNAL] New Version Notification for 
> draft-kampanakis-tls-scas-latest-00.txt
> 
> 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.
> 
> 
> 
> A new version of I-D, draft-kampanakis-tls-scas-latest-00.txt
> has been successfully submitted by Panos Kampanakis and posted to the IETF 
> repository.
> 
> Name:   draft-kampanakis-tls-scas-latest
> Revision:   00
> Title:  Suppressing CA Certificates in TLS 1.3
> Document date:  2022-02-13
> Group:  Individual Submission
> Pages:  10
> URL:
> https://www.ietf.org/archive/id/draft-kampanakis-tls-scas-latest-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-latest/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest
> 

Some quick comments:

1) There are a few "shall" in the text. Should those be "SHALL"?

2) Section 3.2:

"To prevent a failed TLS connection, a client could chose to not send
its intermediates regardless of the flag from the server, if it has a
reason to believe the issuing CAs do not exist in the server ICA
list." 

... Shouldn't the client send its intermediates if it thinks the server
does not have them.

3) Why there are two flags? I do not see a case where both would be
sent in the same message.

4) In WebPKI, there are some cornercases (constrained ICAs) where the
client might be missing a certificate or certificates in the chain.
Currently the WebPKI root program rules allow not disclosing
"technically constrained" certificates (but there are plans to change
this).

5) In the client auth scenario, the server might have exhaustive
list of all issuing ICAs it accepts, so including any ICAs is never
necressary. However, this might be handled even currently by not
giving the client a chain. However, doing this in other direction
can be quite dangerous without prior agreement.



-Ilari

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

Re: [TLS] Does TLS support ECDHE based SEED cipher suites?

[Ilari Liusvaara]

On Thu, Dec 30, 2021 at 03:56:02PM +0800, M K Saravanan wrote:
> 
> https://datatracker.ietf.org/doc/html/rfc4162#section-3.3 says the
> following SEED cipher suites are supported for TLS:
> 
> Does anyone know whether any ECDHE based cipher suites were added for
> SEED for TLS?

No, those have not been added. The actual registry is at:

https://www.iana.org/assignments/tls-parameters/tls-parameters.txt

There are no cipher suites with both ECDHE and SEED (or cipher suite
for SEED in TLS 1.3). My guess is that this is because SEED has
essentially been obsoleted by ARIA.

For ARIA, one can find TLS 1.2 chipersuites with ECDHE and AEAD.
Altough there are no cipher suites for TLS 1.3, so ARIA can not be used
in TLS 1.3 either.


-Ilari 

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

Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing

[Ilari Liusvaara]

On Mon, Nov 08, 2021 at 04:08:51AM -0800, Eric Rescorla wrote:
> On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker  wrote:
> 
> > > > 'Small tweak in wording': Can we say "Where possible, implementations
> > > > MAY process data immediately rather than buffering it"?

What I think about possibilities of partial record processing for each
message type:

Client hello (DTLS 1.3): If PQC is used, fragmentation is likely. Cookie
is not guaranteed to be in first fragment, even if fragment sizes are
reasonable (cookie is extension, and not header field like in DTLS 1.2).
PQC keys are likely to be major part of mesage size, and everything else
probably is in first and last fragments. I have not looked at various
PQC key exchanges, but possibilities for partial processing are likely
limited if existent at all. Any existing implementations will certainly
not support it.

Server hello (DTLS 1.3): As in client hello.

Certificate verify (DTLS 1.3): If full-PQC is used, fragmentation is
virtually unavoidable (low level Falcon might avoid it, but poses
challenges for MCUs due to its use of FPU). Virtually the entiere
message is signature. Notes about partial processing of keys apply
here too.

Certificate (DTLS 1.2): There are signature algorithms that can not
do anything without key, message and signature. However, because DTLS
1.2 requires chain to be ordered, it is possible to process the chain
with two or one-and-half (half being certificate up to the SPKI field)
certificate window.

Certificate (DTLS 1.3): The same trick as in DTLS 1.2 will not work
unless one ignores SHOULD and requires ordered chain (ignoring that
requirement is also great for reducing probability of serious security
issues).

For all other messages, I think those messages either are small enough
for fragmentation to be unlikely, or be very obscure (e.g., DTLS 1.2
supplemental_data).
 

In summary, I think the only real oppurtunity is Certificate message,
if the chain is required to be ordered (which needs ignoring SHOULD in
DTLS 1.3; but there are also other good reason for doing so).

> >
> > I might have misunderstood, I thought you'd confirmed that buffering only
> > fragments aligning or overlapping with the current buffer would work OK --
> > it does in the examples you mentioned, I think.
> >
> 
> It will eventually work, but I believe it will cause extremely poor
> performance.

On causing poor performance, some stuff from ACK mechanism: Suppose side
attacker sends numerious empty unencrypted ACK packets.

It seems like if implementation is not careful, it could immediately
resend its entiere first flight (there is holddown for sender, but
seemingly not for receiver). This could lead into at least two
problems:

- Excessive network usage from all the spurious retransmits. Server's
  first flight is a lot larger than empty ACK, especially if one can
  pile many empty ACKs into a single packet.
- Excessive memory usage from tracking entries for all the resent
  records.


As for ACK holddown, it would seem to me that the following algorithm:

- When receiving first fragment of flight, start a timer.
- When trailing edge of flight reassembly makes progress, reset the
  timer.
- If flight completes, cancel timer.
- When timer expires, send ACK.

Would allow much faster timeouts, as it is limited by dispersion,
which can be orders of magnitude below RTT.


 
-Ilari

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

Re: [TLS] TLS Flags and IANA registration policy

[Ilari Liusvaara]

On Mon, Oct 25, 2021 at 05:13:07PM +, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> > "If an item is not marked as 'Recommended', it does not necessarily
> > mean that it is flawed; rather, it indicates that the item either
> > has not been through the IETF consensus process, has limited
> > applicability, or is intended only for specific use cases."
> 
> I think the flags draft should state that (if that's how it should be 
> interpreted).
> 
> FWIW I looked through the current list of extensions and their Y/N
> assignment for "recommended". The assignment appears random. This is
> not surprising that extensions are, by their nature, related to
> specific use cases and therefore have a certain applicability only.

Yeah, the assignments are pretty strange, here are some recommended
ones I think are odd:

- trusted_ca_keys: Wasn't that supposed to be deprecated?
- client_certificate_url: No replacment in TLS 1.3, security issues.
- user_mapping: No replacement in TLS 1.3, who uses this?
- ec_point_formats: No replacement in TLS 1.3, who uses this?
- heartbeat: The most infamous extension of them all.
- token_binding: No replacement in TLS 1.3.
- status_request_v2: Who uses this (at least TLS 1.3 has a replacement)?
- session_ticket: Nasty security issues (destroys forward secrecy of
  any connection it is used on).
- transparency_info: Similar to signed_certificate_timestamp, which is
  not recommended.

On the reverse side, not recommended extensions, there does not seem
to be any really strange ones (I presume some are due to procedural
matters, and will be changed to recommended later).

I dinged extensions for not working and not having replacment in TLS 1.3,
as one would think that all the common stuff would have replacements.


Then on stuff other than extensions, there are some other odd ones:

- ciphers TLS_DHE_RSA_WITH_*: Negotiation is flawed.
- ciphers TLS_DHE_PSK_WITH_*: Who uses this?
- exporter label "client finished": Actually reserved.
- exporter label "server finished": Actually reserved.
- exporter label "master secret": Actually reserved.
- exporter label "key expansion": Actually reserved.
- exporter labels: Why is there recommended column at all?


-Ilari

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

Re: [TLS] TLS Flags and IANA registration policy

[Ilari Liusvaara]

On Sat, Oct 23, 2021 at 08:46:56AM +, Hannes Tschofenig wrote:
> Hi all,
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags gives
> guidance on registering values in the TLS Flags namespace.
> 
> One of the field is the "Recommended" field and it is described as
> follows:
> 
> "
> o  Recommended, which is a Y/N value determined in the document
>defining the optional feature.
> "
> 
> What does this mean? When do I use a "Y" and when a "N"? What is the
> implication of declaring it as a "N"?

I would presume it is the same as for extensions, which is
described in registry note as:

"If an item is not marked as 'Recommended', it does not necessarily mean
that it is flawed; rather, it indicates that the item either has not
been through the IETF consensus process, has limited applicability, or
is intended only for specific use cases."



-Ilari

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

Re: [TLS] tls-flags: abort on malformed extension

[Ilari Liusvaara]

On Mon, Oct 11, 2021 at 01:12:14PM +0200, Hubert Kario wrote:
> On Thursday, 7 October 2021 20:37:22 CEST, Yoav Nir wrote:
> > 
> > OK, so now my response:
> > 
> > I agree with the first and second comments. About the third, what I
> > meant was that a supported flag that is supposed to appear only in CH
> > appears instead and CR, or more likely, a flag that should appear in EE
> > apears in SH instead.
> > 
> > But I think the best way to resolve the issue is to remove the bullet
> > point list and the last sentence before them, IOW: remove the examples.
> 
> Clients aborting on unrecognised flags in SH or EE is expected, that's what
> already happens for normal extensions, but yes, it's too strong for CH.
> Maybe
> also NST.

I presume flags should mirror how extensions behave (being essentially
compact encoding for zero-length extension), and TLS 1.3 specifies that
known unexpected extension in any message, including CH, causes abort
with illegal_parameter alert (Reference: RFC 8446, Section 4.2).

For unknown extensions, the rule is to ignore any unknown extension in
CH, CR and NST, and abort with unsupported_extension on any unknown
extension in SH, EE and CT (Reference: RFC 8446, Section 4.2).


And there already exists an extension that can trigger the first rule
in CH, namely oid_filters. So an implementation that supports that
extension is supposed to abort if it receives the extension in CH.



-Ilari

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

Re: [TLS] Late DLS 1.3 issue

[Ilari Liusvaara]

On Tue, Oct 05, 2021 at 06:58:24PM -0700, Eric Rescorla wrote:
> On Tue, Oct 5, 2021 at 6:36 PM Martin Thomson  wrote:
> 
> > I left a comment, but I don't think that the fix, as it is specifically
> > proposed, works.
> >
> > The general shape of the proposal seems credible.  A larger epoch space,
> > of which we only send the least-significant bits, would seem to address the
> > concern.  But the proposal doesn't specify what to do with the per-record
> > nonce.
> >
> > If we go with a 48-bit epoch we get a few more records (2^32 times as many
> > I suppose), which is probably enough.  And the value would fit in the
> > per-record nonce.  Then you just need a bunch more text that explains how
> > to encode that nonce.
> >
> > A 64-bit epoch doesn't fit in any nonce we currently use.  We could
> > truncate, which would need more analysis (my intuition is that it would be
> > OK, but I'd like more than a gut feeling).  We might use the expanded nonce
> > options that some (not all) AEAD ciphers have, but that would be a very bad
> > idea.
> >
> 
> This isn't dispositive, but note that TLS 1.3 doesn't include the epoch in
> its nonce at all.

The way I read editor's copy (section 4), DTLS 1.3 does stick the
(64-bit!) epoch in nonce, Which does not work at all with
Chacha20-Poly1305-AEAD, and would need AES-GCM with expanded nonce,
which is poorly suppored and IIRC cryptographically busted. 

Because DTLS 1.3 ratchets keys when switching epochs, it is not
necressary to include epoch in nonce. Just allowing epochs to wrap
around would not create cryptographic problems. It seems that it would
not cause problems with ACKs either:

Burning through the 65536 epochs will presumably either require insane
rekeying rate, or take so long that all potentially confusable ACK-
elicting packets and ACKs have been permanently lost. Badly timed
rehandshake could reuse epoch much faster than that, but it is not
possible to confuse such ACKs as any wrong ACKs are undecryptable.


-Ilari

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

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

[Ilari Liusvaara]

On Thu, Jul 29, 2021 at 02:50:20PM -0700, Joseph Salowey wrote:
> This is a working group call for adoption of Deprecating Obsolete Key
> Exchange Methods in TLS  (draft-aviram-tls-deprecate-obsolete-kex-00
> ).
> There was support for adopting this draft at the IETF 111 meeting.  Please
> review the draft and post your comments to the list by Friday, August 13,
> 2021.

Adopt. And then fold the material from deprecate-ffdhe in.

Then I think nobody cares about KRB5 key exchange:

- There are no AES ciphers for it.
- It does not work with TLS 1.3 at all, and there are no plans to make
  it work.


-Ilari

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

Re: [TLS] Possible TLS 1.3 erratum

[Ilari Liusvaara]

On Fri, Jul 16, 2021 at 12:43:34PM +, Peter Gutmann wrote:
> Eric Rescorla  writes:
> 
> >As we are currently working on a 8446-bis, the best thing to do would be to
> >file a PR at: https://github.com/tlswg/tls13-spec
> 
> Before I do that I thought I'd get some input on what to say, there's actually
> two issues, the first being the one I mentioned.  I was thinking something
> like:
> 
>   TLS 1.2 defined the entries in the "extension_data" as two eight-bit values
>   constituting a { hash, signature } pair.  TLS 1.3 changes the definition to
>   be a single 16-bit value constituting a cipher suite that encodes both the
>   signature and hash algorithm into a single value.  Although some of the TLS
>   1.3 values, in particular the rsa_pss_rsae_xxx ones, appear to follow the
>   TLS 1.2 format, implementations SHOULD NOT treat them as { hash, signature }
>   pairs but as a single cipher suite identifier.

Actually, I think this is quite messy issue:

- Signature schemes 0x0403, 0x0503 and 0x0603 alias signature algoritm 3
  hash 4, 5 and 6. However, those two things are not the same, because
  the former have curve restriction, but the latter do not.
- The Ed25519 and Ed448 in TLS 1.2 are registered in messy way: It
  looks like signature algorithms 7 and 8 are registered for that.
  However, those are only valid for hash 8, so codepoints actually
  precisely overlap with corresponding TLS 1.3 signature schemes.
- There is even worse issue with GOST signatures in TLS 1.2. Those are
  signature algorithms 64 and 65, only valid for hash 8. Unfortunately,
  the corresponding schemes 0x0840 and 0x0841 are unallocated.
  Allocating those could cause issues.
- Signature algorithms 224 to 255 are reserved for private use. However,
  much of the schemes those alias are unallocated. Putting any standard
  allocations there could cause issues. No similar issue exists for hash
  algorithms in private use range, because any standard signatures one
  would use with those are reserved anyway.

So one algorithm one could use is:

- Handle anything with signature 0-3/224-255 and hash 0-6/224-255 as
  signature/hash pair.
- Display schemes 0x0840 and 0x0841 specially.
- Handle anything else as signature scheme. 

However, this would not be right for the three ECDSA codepoints, and it
would not be right if in future anything gets allocated to some
potentially troublesome scheme identifiers. It is not necressary to do
anything special with 0x0807 and 0x0808 because mapping those to schemes
gives correct result anyway.

 
> The second one is the fact that there are two different cipher suites for RSA-
> PSS, rsa_pss_rsae_xxx and rsa_pss_pss_xxx, with conditions for use that are
> stated in a somewhat backwards form, "If the public key is carried in an
> X.509 certificate, it MUST use the RSASSA-PSS OID".  Since the only reason
> these exist AFAICT is to deal with rsaEncryption vs. RSA-PSS certs, it should
> really be stated as something like "the RSA-PSS code point used depends on how
> the key is carried in an X.509 certificate.  If the certificate OID is
> rsaEncryption then the rsa_pss_rsae_xxx form MUST be used.  If the certificate
> OID is RSASSA-PSS then the rsa_pss_pss_xxx form MUST be used".
> 
> And then add some explanation for why this is so and what'll go wrong if you
> use the other one, since I can't see any reason why you can't just use
> rsa_pss_rsae_xxx or rsa_pss_pss_xxx for everything.  What vulnerability is
> this mitigating?

It is not mitigating any vulnerability. The reason is that some TLS
implementations have very hard time supporting RSA-PSS certificates.
And I do not find the conditions to be backwards: There are two, both
scoped.

There is an edge case through: What if keys are not carried on X.509
certificate? In that case, it seems that both are allowed. In
practicular, are Raw Public Keys X.509 certificates? Those do have
RSAEncryption/RSA-PSS distinction like X.509 certificates do. And
then there was some certificate type for automotive applications,
and potentially more future certificate types ("CBOR compressed" is
particualrly fun one, considering those can expand to actual X.509
certificates, but might not do so.)



-Ilari

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

Re: [TLS] I-D Action: draft-ietf-tls-ctls-01.txt

[Ilari Liusvaara]

On Mon, Nov 02, 2020 at 10:14:48AM -0800, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : Compact TLS 1.3
> Authors : Eric Rescorla
>   Richard Barnes
>   Hannes Tschofenig
>   Filename: draft-ietf-tls-ctls-01.txt
>   Pages   : 19
>   Date: 2020-11-02

Some comments:

- Section 3.1.  Varints:

  Using varint encoding is problematic for PskIdentity.obfuscated_ticket_age
  and NewSessionTicket.ticket_age_add, since these are actually
  cryptographic values, and cryptography and variable-length do not
  mix. RFC8446 defines these to be uint32_t, so they would get caught
  by the varint rule.

- Section 3.2.  Record Layer:

  How are alerts represented? Some TLS alerts are in plaintext.
  Especially:

  * Server puking on something in client hello.
  * Client puking on something in server hello.

  And some TLS libraries have more cases:

  * Failing to decrypt first encrypted server record.
  * Client puking on anything in EE..serverFinished.

- Section 3.2.  Record Layer:

  Could be useful to divide transports into three classes (these classes
  are isomorphic to socket types in Linux):

  * DGRAM: Packet-oriented, unreliable (e.g., UDP)
+ Length: OPTIONAL
+ Sequence numbers: REQUIRED
  * STREAM: Byte-oriented, reliable (e.g., TCP)
+ Length: REQUIRED
+ Sequence numbers: OPTIONAL
  * SEQPACKET: Packet-oriented, reliable (apperntly SCTP can do this)
+ Length: OPTIONAL
+ Sequence numbers: OPTIONAL

- Section 5.  Template-Based Specialization:

  I fear that having specialization work without modifying transcripts
  leads to prohibitive complexity. Especially considering that cTLS
  seems to be aimed at (semi-)constrained environments.

  Being able to directly work with on-wire specialized represenations
  would be much simpler code-wise. And I would guess that to make that
  safe, one would only need to inject the profile hash into handshake
  (as sythetic message, in style of how first ClientHello is bound
  on restart in TLS 1.3).

  This would require being able to canonically serialie profiles, which
  would have implications as detailed below.

- Section 5.1.  Specifying a Specialization:

  If this is ever serialized, entiere use of JSON needs to be dumped.
  The reason for this is that it is not dictionaries (objects) are the
  problem in canonicalizing JSON, it is numbers that are the problem.

  There exists CBOR, which is essentially binary encoding of mildly
  extended version of JSON. The main differences:

  * There is octet string type.
  * Dictionaries can also be keyed by integers and octet strings (and
one can mix-and-match the types in the same dictionary).
  * Integer range is limited to -18446744073709551616 to
18446744073709551615 (superset of interoperable JSON).
  * Canonicalization is easy.

- Section 5.1.  Specifying a Specialization:

  suppressSequenceNumber seems to only make sense if DGRAM transports
  are supported. And in that case, one needs mechanism to retransmit
  lost handshake messages.

  And considering apperant itended scope, the DTLS 1.3 mechanism looks
  to be way too complex.

- Section 5.1.  Specifying a Specialization:

  dhGroup could also save some more bytes (3?) by having key_share
  encode the raw share, and then reconstruct one-element list from that.

- Section 5.1.  Specifying a Specialization:

  signatureAlgorithm could save 2 bytes by having it also automatcally
  encode the signature algorithm value in server CertificateVerify
  message.

- Section 5.1.  Specifying a Specialization:

  Some more ideas for specializations:

  * Server signature size (saves 1 byte)
  * ECDSA signature compression (saves ~7 bytes).

  (note that uncompressed ECDS signatures do not have constant size,
  but compressed ones do).

- Section 5.1.1.  Requirements on the TLS Implementation:

  Ascending order will not work with extension 41, as it is magic and
  needs to be last. 0 to 40, 42 to 65535 and 41 would work.

- Section 6.  Examples:

  Why is that '"named_groups": 29' there?

- Section 6.  Examples:

  Why is the ALPN extension encoded as "030016832"? That doesn't even
  seem to be of integral number of octets. I get that the value should
  be "03026832".
   
- Section 7.  Security Considerations

  On transcript expansion, suppressSequenceNumber looks to make any
  sense only if DGRAM transports are also supported, and it is not
  obvious to me that uncompressing to TLS 1.3 is possible in such
  cases.

  It is also not obvious to me that explicit transcript expansion can
  be implemented with acceptable complexity, especially considering
  the apparent intended scope.



-Ilari

___
TLS mailing list
TLS@ietf.org

Re: [TLS] Sending Custom DHE Parameters in TLS 1.3

[Ilari Liusvaara]

On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> 
> It appears that there may be a need to revert to the
> old way of sending Diffie-Hellman parameters that
> the server generates.  I see that TLS 1.3 removed
> this capability*; is there any way to add it back?

The Diffie-Hellman support in TLS 1.2 is severly broken. There is no
way to use it safely on client side. This has lead to e.g., all the web
browers to remove support for it.

There is no way to ensure that the parameters sent are not totally
broken, e.g.:

- Modulus too small.
- Modulus too large.
- Modulus not prime (has been used as a backdoor!).
- Modulus is weak (possibly backdoored).
- Subgroup order does not have large prime factor.

Even checking the third would require primality test, and primality
tests at relevant sizes are slow. And the fourth and fifth can not be
checked at all in general case.


For ECDHE, TLS 1.2 allowed server to specify custom curve to do the
key exchange with. Rightfully pretty much nobody implemented that.


I think TLS WG should withdraw recommendation (as flawed) on all
TLS_DHE_* ciphersuites.


-Ilari

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Ilari Liusvaara]

On Sun, Oct 11, 2020 at 08:26:47AM +0200, Achim Kraus wrote:
> Hi Joe,
> 
> > [Joe]  It's unfortunate to find issues that require breaking change at
> > the end of the review cycle, especially for a draft that has taken a
> > long path to get here.   If there is an issue that is exploitable, even
> > in a corner case, someone will develop an attack, clever name, logo and
> > website and we will all have to scramble to deploy a fix.   It's better
> > to fix now rather than later.
> 
> Agreed, therefore I wrote at the begin of the discussion with Ben:
> 
> >> I would prefer, if this is not changed again without strong
> >> arguments!
> 
> > In this case, I don't have a way to
> > exploit this issue, but unless someone has a way to demonstrate that
> > this is not going to be an issue then I believe it is prudent to fix it
> > now.
> >
> 
> In my opinion, ONE change may be possible. A server may be configured to
> use only the old, only the new, or both by "try on the client's finish".
> I'm not happy with such "dirty" work-around. I would prefer to do so for
> something more the "cryptographic hygiene".
> 
> So, if the MAC is considered to be adpated again, should it not be
> discussed, why at all the cid-length should be put in?
> I asked this already in January 2019
> 
> https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915
> 
> The MAC contains already a overall length. Even in that discussion, no
> one mentioned the reason for adding it. So if there a doubts about
> injection, why not remove it at all?

The problem is the follows:

Take the following input to the MAC (MtE case):

 19 FE FD 63 01 00 05 04 00 02 FF 17

There is no way to tell from that input if it is:

- Application record on CID 63 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.

The overall MAC length will not catch this, because the overall length
is the same in both cases.

And even if it seems that the data lengths after depad should be
different, it is unsafe to rely on depad length.


Stripping the CID length will not solve the issue. Heck, if cid length
is removed, the very above example is still ambiguous, now for:

- Application record on CID 63 01 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.


For EtM construction, it is even worse. There is no way to check for
consistency, because CBC mode leaves end of message intact even if
IV or length are bogus, meaning all the depad and content-type checks
will pass.

The AEAD construction is not affected. Even if the design is pretty
bad, the CID is the only variable-length field in AD, so its length
can be inferred from AD length.


Swapping order of CID and its length will solve it:

 19 FE FD 01 63 00 05 04 00 02 FF 17

- Application record on CID 63 containing 04 00 02 FF.

 19 FE FD 04 63 01 00 05 00 02 FF 17

- Application record on CID 63 01 00 05 containing FF.

Tricks altering CID length are not possible, because those will
alter a byte at fixed position. And one can not alter CID without
changing its length either, as those will alter bytes at fixed
position as well.



-Ilari

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

Re: [TLS] Un-deprecating everything TLS 1.2

[Ilari Liusvaara]

On Tue, Oct 06, 2020 at 10:13:19PM -0400, Michael D'Errico wrote:
> On 10/5/20 22:00, Christopher Patton wrote:
> > I agree that the HRR code path is hard to reason about, but I don't
> > really see an attack here. Is it your contention that the HRR code path
> > leads to an attack not accounted for by existing proofs?
> 
> I know that it may lead to denial-of-service
> for a legitimate client.  That's a big deal, but
> I was more worried that there might be a bigger
> problem with ECC, and I'm glad to hear that you
> and Nick Harper say it's just fine (or at least
> that we're no worse off than we are by trusting
> ECC in version 1.2).

If implemented properly, it will never lead to denying a legimate
client.
 
> I'm still very concerned that everything 1.2- and
> non-ECC is being thrown in the trash.

Because actually proving security of any practical cryptography is far
beyond current capabilities of open cryptography, the way security of
crypto is judged today is from attempts to break it.

ECC has been subject to this for ~35 years, and natural prime curves
(which include P-256, P-384, P-521, Curve25519 and Curve448) are second
to none in how well those have fared.

RSA and finite-field discete-logs have fared MUCH worse in ~45 years.

And there is no tradeoff between security and performance: Using ECC
instead of RSA/DH gives massive performance improvement.

This is not to say there will not be major challenges in future: If
large quantum computers can be built, ECC is toast (along with lots
of other stuff), and one needs new crypto, which is a necressarily a lot
less secure.


And regarding TLS 1.2, it is a mess:

- There is an extension to prevent attacks from having server confuse
  initial handshake and renegotiation.
- There is an extension to prevent attacks from failing to include
  exchange keys into master secret.
- Diffie-Hellman group negotiation is completely broken. To prevent
  attacks, clients must either disable DHE or tolerate handshakes with
  some servers failing.
- Signatures fail to include handshake type. The endpoints can disagree
  about handshake type, leading to attacks.
- Session ticket mechanism is pretty totally insecure.
- Static RSA uses insecure encryption (and is not forward-secure).
- Blockmodes use mac-then-pad, leading to timing attacks. There is
  extension to fix this, but pretty much nobody implements it.
- The MTI ciphersuite is insecure.
- You think EXPORT and single-DES have gone the way of dodo, >20
  years after being proven completely insecure? Unfortunately no.
- Limited extensibilty due to middlebox threat.
- Adding post-quantum cryptography is not feasible.

It is in practice impossible to implement TLS 1.2 securely. The best
one can do is some approximation with multiple unimplemented features
that is approximately secure.

Then there are non-security issues with TLS 1.2. Like ciphersuite
negotiation being petty much impossible to implement correctly due
to coupling between encryption and certificates.

> To see what I mean about denial of service, a
> "stateless" server implemented according to the
> way RFC 8446 describes is not going to have the
> actual HelloRetryRequest message it sent to the
> client.  I don't know what is done to solve this
> problem, but apparently a lot of people have
> implemented stateless-HRR so they must have done
> something to either guess this value, or maybe
> their code is not actually stateless.  If they
> are guessing the value of HRR based on the 2nd
> ClientHello received, and they guess wrong, and
> the client puts a different value of HRR in its
> own Transcript-Hash, then the handshake will
> fail and a legitimate client will be denied
> service.

Have function cookie_to_hrr(c,cs,grp) that turns a cookie c into
HRR message, and is pure function of the cookie.

Then:

Without cookie:

1) Receive ClientHello without cookie.

2) Figure out ciphersuite cs and group grp to use.

3) Compute invariant partial hash of Client Hello.

4) Serialize state, including full client hello hash, cs and grp in
   cookie (no need to include the invariant hash).

5) Use MAC to authenticate the cookie, including the invariant hash.
   
   OR

   Use MRAE to encrypt and authenticate cookie, including the invariant
   hash in associated data.

6) Use cookie_to_hrr(c,cs,grp), send result to client and abort.


With cookie:

1) Receive ClientHello with cookie.

2) Compute invariant partial hash of Client Hello.

3) Authenticate the cookie, and decrypt it if it is encrypted. If
   authentication fails, abort. Important: There is an attack if
   this is not done!

4) Read full client hello hash, cs and grp from cookie.

5) Inject client hello hash to transcript.

6) Use cookie_to_hrr(c,cs,grp), and inject result to transcript.

7) Add inject second client hello to transcript.

8) Figure out other connection parameters besides ciphersuite and
   group, and continue handshake.


This can be proven to always work.


-Ilari

Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

[Ilari Liusvaara]

On Wed, Sep 16, 2020 at 07:26:56PM +0300, Nimrod Aviram wrote:
> 
> We also note that a related RFC exists, "Hybrid Post-Quantum Key
> Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
> [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
> PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
> may be prudent to add cautionary language to that document as well,
> in case other KEMs are used in the future.

Searching for newest available versions of finalists/alternates
specifications, all have constant output lengths except Kyber (usually
32 octets, but HQC uses 64, and FrodoKEM and SIKE use 16 at Cat1 and 24
at Cat3).

Kyber is a bit odd case. The spec uses raw XOF output as key, and the
specification does not seem to say anywhere how long the output should
be. The reference implementation always uses 32 octets as output
length.

So none of the finalists/alternates need variable-length secret fields.
And with TLS 1.3, due to the way secret is injected into key schedule,
a length field would only be strictly needed for injectivity if there
are multiple variable-length subkeys.

And with regards to TLS 1.2, I would just leave it. Adding PQC to TLS
1.2 is harder than adding PQC to TLS 1.3 (this is definitely not one
of those "old versions for free" cases), and TLS 1.2 is pretty much
obsolete anyway.


-Ilari

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