Re: [TLS] I-D on TLS authentication with VC

[Hannes Tschofenig]

Hi Andrea


thanks for the extra background.


How do you plan to deal with the large number of DID methods?
Standardization of many of the DID methods has not been finished and
they appear to have vastly different security properties, even for the
most basic DID methods like did:web and did:key. It sounds difficult to
accomplish interoperability in such a flexible system.


Ciao
Hannes


Am 05.04.2024 um 12:12 schrieb Andrea Vesco:

Hi Hannes, thanks for your question.

We are referring to a (well-resourced) IoT system with edge computing nodes. In 
the IoT/edge segment, the VC can be used for mutual authentication directly in 
TLS to avoid the only option available today: first establish a TLS channel 
with X.509 based server-only authentication and, second, authenticate the 
client with its VC on top of the TLS channel. The Client authentication at the 
application layer works well, but in our opinion, only in web scenarios.
In addition, using the client_certificate_type and server_certificate_type 
extensions would also enable the option of hybrid (VC - X.509) mutual 
authentication in the edge/cloud segment at the TLS layer.
In our opinion, this is an incremental approach to support the adoption of VC 
and DID technologies in IoT systems.

Best, Andrea



On 4 Apr 2024, at 12:29, hannes.tschofe...@gmx.net wrote:

Hi Andrea,

Thanks for sharing the info.

Could you say a bit more about your IoT use case?

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Andrea Vesco
Sent: Donnerstag, 4. April 2024 10:53
To: tls@ietf.org
Subject: [TLS] I-D on TLS authentication with VC

L. Perugini and I have written an I-D on the use of Verifiable Credentials 
[1][2] as an additional authentication mode in TLS.  We presented the I-D to 
the ALLDISPATCH WG during IETF119 and the outcome was to explore the potential 
interest of the TLS WG. The I-D proposes to add (i) a new Certificate Type 
called VC in addition to X509 and RawPublicKey to the existing 
client_certificate_type and server_certificate_type extensions and (ii) a new 
extension called did_methods to carry the list of DID Methods supported by the 
endpoint to resolve the peer's DID during the validation of the Verifiable 
Credential. The I-D focuses on the IoT use case.

We are aware of the current discussion in the working group about new code 
points and would like to know your opinion in the case of this I-D and to 
explore the possible interest. Thank you in advance for your feedback.

I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/
Code:
- Provider https://github.com/Cybersecurity-LINKS/openssl-ssi-provider
- OpenSSL https://github.com/Cybersecurity-LINKS/openssl

[1] https://www.w3.org/TR/vc-data-model-2.0/
[2] https://www.w3.org/TR/did-core/

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



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

Re: [TLS] I-D on TLS authentication with VC

[hannes . tschofenig=40gmx . net]

Hi Andrea,

Thanks for sharing the info.

Could you say a bit more about your IoT use case?

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Andrea Vesco
Sent: Donnerstag, 4. April 2024 10:53
To: tls@ietf.org
Subject: [TLS] I-D on TLS authentication with VC

L. Perugini and I have written an I-D on the use of Verifiable Credentials 
[1][2] as an additional authentication mode in TLS.  We presented the I-D to 
the ALLDISPATCH WG during IETF119 and the outcome was to explore the potential 
interest of the TLS WG. The I-D proposes to add (i) a new Certificate Type 
called VC in addition to X509 and RawPublicKey to the existing 
client_certificate_type and server_certificate_type extensions and (ii) a new 
extension called did_methods to carry the list of DID Methods supported by the 
endpoint to resolve the peer's DID during the validation of the Verifiable 
Credential. The I-D focuses on the IoT use case.

We are aware of the current discussion in the working group about new code 
points and would like to know your opinion in the case of this I-D and to 
explore the possible interest. Thank you in advance for your feedback.

I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/ 
Code:
 - Provider https://github.com/Cybersecurity-LINKS/openssl-ssi-provider
 - OpenSSL https://github.com/Cybersecurity-LINKS/openssl

[1] https://www.w3.org/TR/vc-data-model-2.0/
[2] https://www.w3.org/TR/did-core/ 

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

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

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

[Hannes Tschofenig]

Hi Scott,


thanks for your feedback. Introducing PQC algorithms in the design for
this proposal has not been discussed in TSVWG design team and has
therefore not been a requirement for me. (Maybe my co-authors see this
differently.)

I will bring this topic up in the next design team call. In any case, it
is good to hear your preferences.


Ciao

Hannes


Am 05.01.2024 um 20:52 schrieb Scott Fluhrer (sfluhrer):


Here’s an issue I see with postquantum exchanges; Kyber (and most
other postquantum key exchanges) would have an issue with the current
format.  There are distinct ‘initiate key shares’ and ‘response key
shares’, and they’re not interchangeable; a ‘response key share’ must
be generated for a specific ‘initiate key share’.

Now, it would be possible to extend ExtendedKeyUpdate to include a
flag stating whether this is a request for new keys, or a response
(distinguishing the two cases); that would be a relatively small change.

However, what happens if both sides happen to issue ExtendedKeyUpdate
at the same time?

With DH, it’s not an issue; they could ignore the flag, and they would
both accept the other’s ExtendedKeyUpdate as a response to their own,
and both update the keys in the same way.

However, with Kyber, if we issue an ‘initiate key share’ and get an
‘initiate key share’ in response, we can’t generate keys.

One possibility would be if there is a tie-breaker between the two
sides (such as ‘who had the lexically larger key share)’; the loser of
that tie-breaker would discard his original ExtendedKeyUpdate, and
reissue another one (which is a response to the other side’s)?

I believe this idea would extend to DTLS as well as TLS.

A bit kludgy (and definitely adding complexity); however I also
believe that it would be short-sighted to ignore postquantum crypto at
this point.

*From:*TLS  *On Behalf Of *Tschofenig, Hannes
*Sent:* Thursday, January 4, 2024 6:42 AM
*To:* TLS List 
*Subject:* [TLS] Key Update for TLS/DTLS 1.3

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/

I am curious what you think.

Ciao
Hannes


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

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

[Hannes Tschofenig]

Hi Ilari,


thanks for your feedback. A few remarks below.


Am 05.01.2024 um 16:59 schrieb 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)?


My focus was not on PQC algorithms for this work. It was meant as an
extension to be used in the near term.

From Scott's feedback I can see that others seem to have different
priorities.




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


No, not in this design. It was not one of the design requirements for me
and, if that's a requirement, then this functionality is probably not
applicable.


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 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 -->




Ciao

Hannes



-Ilari

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

Re: [TLS] TLS Suite Naming Conventions

[Hannes Tschofenig]

Hi Orie,


I am not sure whether the comparison between JOSE/COSE and TLS is
appropriate when the latter uses a handshake and the former is a
one-shot message (or a payload).

In a TLS handshake there are so many things that get negotiated, such as
the algorithms and parameters for protecting the record layer (e.g.
TLS_AES_128_GCM_SHA256), the curve and parameters of the key share (e.g.
secp256r1), the digital signature algorithms (like
ecdsa_secp256r1_sha256) used in the handshake and the signature
algorithm used for cerificates, version, extensions and other features.

On top of the above, the design has a long history and didn't radically
change from version to version (except for the cipershite that was
changed to separate the authentication and key exchange mechanism from
the symmetric key algorithm and hash function used at the record layer).


Hence, I am not sure what the benefit of aligning the registries are. To
me, this entire ciphersuite vs. à la carte discussion is largely a
matter of taste.


Ciao
Hannes

PS: Regarding your question below about "I see that "ed25519(0x0807),"
could have been "eddsa_ed25519", and I assume "0x0807" actually means
"eddsa with ed25519", and "0x0808" actually means "eddsa with ed448".
Since these values are in the signature algorithm registry, those are
could have been prefixed with "eddsa".


Am 06.01.2024 um 15:49 schrieb Orie Steele:

Hello,

Apologies in advance for starting a thread about the proper way to
name things.

We've been discussing the TLS naming conventions in relation to JOSE
and COSE naming conventions for suites.

Here is the start of the full thread:
https://mailarchive.ietf.org/arch/msg/jose/66xvb1EgD-bf7V-XyAgDgRuUTJk/

We've been comparing "trends in suite names", between TLS, JOSE and COSE.

For example, we see the following:

          /* ECDSA algorithms */
          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

         /* EdDSA algorithms */
          ed25519(0x0807),
          ed448(0x0808),


In JOSE, ES256 means ~ " ecdsa_secp256r1_sha256(0x0403),"
In COSE, ES256 means ~ "ecdsa with some curve + sha256"

In JOSE, EdDSA means ~ "EdDSA with some curve"
in COSE, EdDSA means ~ "EdDSA with some curve"

This draft is in call for adoption, and argues for a convention:
https://datatracker.ietf.org/doc/draft-jones-jose-fully-specified-algorithms/

The convention is essentially, when we "name a suite", it should fully
specify all the parameters.

"ecdsa_secp256r1_sha256" is fully specified... "eddsa" or "ecdsa with
sha256" is not (curve parameter is not specified).

In the thread, Neil said that it is better to negotiate for
key (representations), instead of algorithms, and that TLS has been
moving away from fully specifying things.

I see that "ed25519(0x0807)," could have been "eddsa_ed25519", and I
assume "0x0807" actually means "eddsa with ed25519", and "0x0808"
actually means "eddsa with ed448".

I don't expect a hash function here, because I know SHA-512 is used
internally.

Key representations in JOSE and COSE have parameters, and one
parameter is the "alg" field, which restricts the use of the key.

In the case of a fully specified algorithm, this "alg" parameter
contains redundant information to the other key parameters.
In the case of a partially specified algorithm, this "alg" parameter
contains non redundant information (such as dsa and hash, there are
curves that support multiple dsas, and of course everyone has a
favorite hash function).

Neil also made several compelling arguments not to adopt the draft
because fully specified identifiers for partially specified things are
already partially understood.

Assuming we dropped new registrations, and just made recommendations
for how to specify algorithms, how might JOSE and COSE align our
registry guidance with the current thinking in TLS?

Should we recommend against fully specifying things, and argue that
negotiation should be for keys, not algorithms, and keys can choose to
restrict to achieve full specification?

Should we recommend fully specifying things, and then decide if
redundant code points should also be assigned, or if the guidance
should just be forward facing?

Regards,

OS

--


ORIE STEELEChief Technology Officerwww.transmute.industries




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

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

[Hannes Tschofenig]

Nicely written, Ilari.


Additionally, there is this patent for such a key update by John, Magnus
and Claudio written for the SCTP context:

https://datatracker.ietf.org/ipr/6218/



Ciao

Hannes


Am 04.01.2024 um 18:37 schrieb 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


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

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

[Hannes Tschofenig]

Hi David,


thanks for sharing your thoughts.

Here is the approach I had in mind: the application code needs to
trigger the TLS/DTLS stack to start the extended key update. For the TLS
1.3 code I wrote, that's the approach I took for the regular TLS 1.3 key
update as well. In the use cases I have in mind, the application knows
whether it has application data to send and therefore what a good timing
for such an extended key update would be. You are correct that there is
a short time window when the sender of the extended key update has to
wait till it receives the response from the peer party to also update
its sending keys. I have not considered running the extended key update
in parallel to the application data exchange and the use of a three
message exchange.

It may be possible that this approach is not possible in environments
where there is a continuous stream of packets or where potential delays
in sending data are unacceptable. I suspect you have such an environment
(?). When I also take the comments from Thom into account, who didn't
like the change to the state machine with the full-round-trip approach,
I am wondering whether the alternative of using a semi-static DH, which
we considered in Appendix B, may ultimately be better.


Ciao
Hannes


Am 05.01.2024 um 01:40 schrieb David Benjamin:

Skimming the draft, I am not following the timing of this process.
Suppose the client initiates an extended key update. It cannot update
the keys yet, because it does not know the server's response. It needs
to keep reading from the server. In doing so, it will hopefully see a
responding ExtendedKeyUpdate, but it may see something else that
forces it to send data, such as an application protocol message or an
update_requested KeyUpdate. (Or perhaps an update_requested
ExtendedKeyUpdate!)

Are you envisioning that the client is unable to send anything
until it receives the server's response, or that this exchange flows
in parallel with the rest of the connection?

If the client is unable to send anything, this seems like it would
cause problems. Certainly it would not be something the TLS library
can do automatically, because it can only run at a quiet point in the
application protocol. A priori, you may receive an unbounded amount of
application data while waiting for ExtendedKeyUpdate. You need to do
/something/ with that data, but all options result in either an
unbounded buffer or a deadlock somewhere.

If the exchange flows in parallel, how does the server know where, in
the client stream, did the client switch keys? I think you'd need a
third message to mark this point.Though we then need to reason through
what happens if that third message doesn't come in for a long while,
because the server can't release state from that key update until then.

To that end, what happens if someone sends a storm of
ExtendedKeyUpdate messages with update_requested in a row? Over TCP,
we have to worry about a DoS issue caused by asymmetric rates on the
two sides. (If I send you a storm of update_requested but refuse to
read from the socket, at some point backpressure will stop you from
writing responses. At that point, you need to know to stop reading or
you'll buffer up unbounded data.) For plain KeyUpdate, we said the
requests can be coalesced, but ExtendedKeyUpdate messages contain
different key shares. I suspect you need to say that you cannot send a
new update_requested until after you've sent the third message for the
previous one.

Relatedly, this seems tricky:

> If implementations independently send their own ExtendedKeyUpdate
messages, and they cross in flight, the result is that each side
increments keys by two generations.

Since ExtendedKeyUpdate incorporates new key material into the new
secret, you will get a different result depending on which exchange is
processed first. But the two sides may see each exchange resolving in
a different order when crossed like this. (It /might/ work with a
three-message design? Then there's an in-band signal for when the keys
are applied on each side. Though it means this cross case can actually
resolve in different orders for the two streams, which is kind of
interesting.)

On Thu, Jan 4, 2024 at 6:42 AM 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/

   

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

[Hannes Tschofenig]

Hi Ilari,


thanks again for the super quick feedback. Remarks below:


Am 04.01.2024 um 14:53 schrieb 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?



When exchanging key shares, the use of supported_groups is mandatory (at
least that's what I remember).

It would, however, be useful to point out that this needed. As such, the
extended key update is not useful for cases where you only use PSK-based
authentication without a (EC)DHE key exchange.




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


Figure 3 is supposed to show you how the extended key update works in
DTLS 1.3 with epoch values indicating when the keys in the different
directions change.

Let me think about how to better get the story across.




- 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.


Did I understood you correctly?



- 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.


Happy to add more text.




- 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.


Good catch. Will change that.



Ciao

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

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

[Hannes Tschofenig]

Hi Thom


thanks for the quick review.


Directionality of the extended key updates: I should be more clear in
the examples and in the write-up that these key updates can be initiated
by both parties.

Description about when the keys can be deleted: I will re-review the
text again to improve the wording.

Alternative designs: At the start I have been quite excited about the
idea of preserving the one-shot semantics of the key update.
Unfortunately, it comes with a price, as you also point out. Building
the design on top of draft-ietf-tls-semistatic-dh or AuthKEM may have
been possible as well but introduces dependencies that not everyone likes.


Ciao

Hannes


Am 04.01.2024 um 15:12 schrieb Thom Wiggers:

Hi Hannes,

Skimming the document, I had the following questions:

- Can only clients request extended key updates (EKUs)? I think the
text does not attempt to impose this as a restriction, but all the
examples are client-initiating.
- If it is limited to client-initiated EKUs, the client shouldn't need
to indicate it supports this extension?
- Section 5 specifies that the N-1 keys SHOULD be deleted once
computed, but in many other sections (e.g. the tail of section 4) keys
are specified (MUST) to stay around for a bit longer. This seems
contradictory, and I think it would be less confusing if handling of
key material is more explicitly treated in the document.

Personally, I’m not super stoked about having extensions that bolt on
a new state machine, but it seems unavoidable for your problem
description (if we’re excluding application-layer fixes).

Your "alternative designs considered” section might have been more
viable if this was built on top of draft-ietf-tls-semistatic-dh or
AuthKEM, as we’d have long-term static key exchange keys (but it does
have other complications, such not allowing server-initiated EKUs if
there was no client auth). Otherwise I think that you’re right to not
require servers to store their ephemeral keys for the session lifetime
if the client sends an extension, while it may never even send the EKU
request.

Cheers,

Thom



Op 4 jan 2024, om 12:42 heeft Tschofenig, Hannes
 het volgende geschreven:

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/
I am curious what you think.
Ciao
Hannes
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



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

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

[hannes . tschofenig=40gmx . net]

>From my experience, it is possible to update the firmware on many modern 
>constrained IoT devices, including the TLS / DTLS stack, today. Of course, 
>there are a lot of devices out there where updating the firmware involves 
>physical access by some technician.

However, there are a few other challenges. 

First, such a change must be carefully planned since the space on these devices 
is quite limited.

Second, IoT devices often follow "system" standards and for interoperability 
purposes you cannot just replace one version of the security protocol with 
another one. In some IoT standards, you can "easily" switch from one TLS 
version to the next without impacting the interoperability of the entire 
system. This is not necessarily the case with all IoT specifications. There are 
often other subtle changes that have an impact on the transition. For example, 
if you have an IoT deployment that uses EAP-TLS based on RFC 5216 and you 
switch to RFC 9190 then you are suddenly facing the requirement to use OCSP 
stapling in TLS, if you strictly follow RFC 9190. In general, you have to look 
at the whole system rather than just at a single IoT device alone. There may 
also be certification processes to consider. 

Then, there is the incentive issue. Just because there is a new version of TLS 
available does not immediately trigger companies to update their devices, 
particularly when there is not even a security problem with 1.2 (at least if 
you follow the recommendations from the UTA group).

Finally, implementations with the desired feature set also have to be 
available. Depending on the stack you are using, this might be the case, but it 
is not guaranteed. Implementing embedded security protocols takes more time 
than writing a Javascript app...

Ciao
Hannes
 
-Original Message-
From: TLS  On Behalf Of Loganaden Velvindron
Sent: Dienstag, 12. Dezember 2023 06:17
To: Peter Gutmann 
Cc: tls@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Peter,

I'm curious. Are those embedded devices or IoT type of appliances where the 
firmware has a TLS library that will never be updated ?


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and 
> life cycles.  I'm fairly certain TLS 1.2 will still be around when the 
> WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> Peter.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

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

[Hannes Tschofenig]

Hi Rich,


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


Ciao

Hannes


Am 11.12.2023 um 17:18 schrieb Salz, Rich:


  * I consider Section 3 "Implications for post-quantum cryptography"
misplaced. I suggest to delete the section
  * The motivation for the draft is unrelated to developments with PQC.

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


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

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

[Hannes Tschofenig]

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


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


Ciao

Hannes



Am 11.12.2023 um 11:59 schrieb Bas Westerbaan:

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly
 wrote:

At the TLS meeting at IETF 118 there was significant support for
the draft 'TLS 1.2 is in Feature Freeze'
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)
 This call is to confirm this on the list.  Please indicate if you
support the adoption of this draft and are willing to review and
contribute text. If you do not support adoption of this draft
please indicate why.  This call will close on December 20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


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

Re: [TLS] [Pqc] Post-Quantum TLS instantiations and synthetic benchmarks

[Hannes Tschofenig]

FWIW I have been working on synthetic TLS benchmarks as part of work in
the Embedded Microprocessor Benchmark Consortium.

I presented about the work in SAAG twice: here is the first presentation
https://datatracker.ietf.org/meeting/103/materials/slides-103-saag-iot-benchmarking-00
and here is the update
https://www.ietf.org/proceedings/103/slides/slides-103-saag-iot-benchmarking-00


Here is the page to EEMBC: https://www.eembc.org/securemark/

It contains videos and documents explaining the benchmarks. It also
lists the submitted scores from different vendors.


Here is the code for the initial version of the benchmark:

https://github.com/eembc/securemark-tls


The reference implementation for version 2 (based on TLS 1.3 and more
advanced algorithms) is here:

https://github.com/eembc/securemark-v2


I think it would be worthwhile to create a version of the EEMC benchmark
using PQC algorithms.


Ciao

Hannes


Am 26.06.2023 um 13:48 schrieb Thom Wiggers:

Hi TLS-wg and PQUIP-rg,

Recently, I have computed the sizes and measured the performance of
post-quantum TLS (both PQ key exchange and post-quantum
authentication). In these experiments, I have examined combinations of
Kyber, Dilithium, Falcon, SPHINCS+-(sf), HQC, and XMSS. The
experiments include measuring their performance over two network
settings, one high-bandwidth, low-latency and one low-bandwidth,
high-latency connection.

I have examined the instances at NIST PQC security levels I, III and
V, and for both unilaterally authenticated and mutually authenticated TLS.

The report on these experiments (which is basically an excerpt of my
PhD thesis manuscript) can be found in the attached document. It's a
fairly dense document, so refer to the reading suggestions to easily
find what you are looking for.

It can be found at https://wggrs.nl/post/tls-measurements/handout-tls.pdf.

I hope this document can be useful to:

* get a feeling for how we can combine (signature) algorithms to fit
their differing roles in the handshake
* to see how this affects the handshake sizes, and
* have some indication of how the performance of these combinations of
algorithms is in a TLS stack on a network.
* Additionally, I believe my results are useful to compare the cost of
different NIST security levels.

The experiments do not include SCTs or OSCP staples, but I think that
their effect can mostly be extrapolated from the reported results.
Also note that I am simulating the network environment, so the effect
of the initial congestion window is much less gradual than observed in
practice.

As I write in the document, I want to examine the NIST on-ramp
candidates' suitability for use in TLS as soon as the list of
algorithms is formally out; for my PhD thesis they unfortunately came
into the picture too late.

Cheers,

Thom Wiggers
PQShield




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

Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS /QUIC.

[Hannes Tschofenig]

Adding to the response: As with all TLS extensions, if endpoint A depends on a 
feature but endpoint B does not support the feature then the exchange has to be 
terminated.

CIDs are not different from other extensions.

It is, however, quite likely that an application will still work without the 
CID in a given scenario but efficiency might suffer.

Ciao
Hannes

From: TLS  On Behalf Of Eric Rescorla
Sent: Friday, December 9, 2022 3:28 PM
To: Kristijan Sedlak ;  
Cc: architecture-disc...@ietf.org
Subject: Re: [TLS] [arch-d] Question regarding Connection ID (CID) in DTLS 
/QUIC.

This question should go to the TLS mailing list, not to architecture-discuss. I 
have CCed that list.
On Fri, Dec 9, 2022 at 3:02 AM Kristijan Sedlak 
mailto:xpeperm...@gmail.com>> wrote:
Hello, everyone.

I'm scratching my head on RFC 9146 and wonder about the correct implementation 
strategy. Connection IDs in DTLS 1.3 are not mandatory and thus leave related 
challenges to the implementor.

As I understand DTLS 1.3 allows endpoints to choose whether to support 
ConnectionId extension or not. If the sender includes ConnectionId extension in 
the ClientHello, the receiver knows that CIDs are supported and it can include 
its CID in the ServerHello, but if the receiver does not support the extension 
it will not include it in the ServerHello and the sender will get that info.

What should we do if an endpoint features depend on CIDs but the targeting peer 
does not support the CID extension? Let's say that the sender will reuse the 
socket (ip:port) and serve multiple standalone "connections" through it (N 
ClientHello messages will start N connections over the same socket and the peer 
needs to use CIDs to distinguish between them) and thus require the remote 
endpoint to support CIDs? Should an endpoint (sender or receiver) that requires 
CIDs reply with unsupported extension alert?

If you need connection ids and the peer doesn't support them, you should 
probably
terminate the connection with a "handshake_failure" alert. Alternately, you 
could
only allow one connection at a time.

-Ekr





IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-fossati-tls-attestation-02

[Hannes Tschofenig]

Hi all,

at the last IETF meeting I gave a presentation about the TLS attestation draft.
Based on the feedback we have made several changes:


  *   The design is attestation-technology agnostic.
  *   This version focuses on the background check model and the transfer of 
evidence from the attester to the relying party.
  *   Example flows have been added.

The primary use case of this work is for confidential computing.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Securely disabling ECH

[Hannes Tschofenig]

Giving someone, other than those managing the endpoints, the ability to disable 
a security feature like ECH is problematic.

If I read your email correctly then I believe that’s what you are suggesting. I 
hope I am missing something.

Ciao
Hannes

From: TLS  On Behalf Of Safe Browsing
Sent: Wednesday, October 19, 2022 4:56 AM
To: Eric Rescorla 
Cc: TLS@ietf.org
Subject: Re: [TLS] Securely disabling ECH

Hi Eric,

Picking up on your (earlier) reply here.

Though it would be possible to adjust the setting in browsers (disabling ECH), 
this is not an ideal/sufficient method of disabling ECH.

Some reasons it is not sufficient:
- Not all TLS clients are browsers
- Not all browsers (or other TLS clients) may implement this ability
- In a multi-browser environment it means that it needs to be configured in 
more than one place, each using a different method of achieving the same 
(cumbersome)
- even worse if there are other, non-browser, ECH supporting clients present 
for which ECH needs to be disabled

It seems therefore that the ideal place to achieve this is within the protocol 
itself. Making ECH disabling client agnostic.

The draft does consider this by allowing ECH to be disabled - as discussed in 
this thread. Albeit at the cost of an extra round trip. However, the connection 
retry logic in the presence of ECH disabling is currently optional.

The draft states, in Section 8.2:
“ this may trigger the retry logic”


It seems this text must change to:
“ this MUST trigger the retry logic”

In order to ensure functional connections in a TLS client agnostic manner, in 
the presence of protocol level ECH disabling.

I would appreciate your thoughts/input.


On Oct 8, 2022, at 7:41 PM, Eric Rescorla mailto:e...@rtfm.com>> 
wrote:

If you are able to install a new trust anchor, then you should be able to use 
the enterprise configuration mechanisms in browsers to disable ECH.

-Ekr


On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing 
mailto:safebrowsing...@gmail.com>> wrote:
Hi Rich,

When I say “authoritative”, I mean it in the true TLS sense, in the way that I 
believe the ECH draft also suggests and requires.

In other words, the middlebox serves a cert to the client that is 
cryptographically valid for the said public name of the client facing server.

How can that be when the client facing server guards its private key properly? 
By re-signing the server certificate on the middlebox with a private key, local 
to the middle box only, for which the corresponding certificate has been 
installed in the trust store of the client, before sending it on to the client. 
Only after the original server certificate has been validated properly on the 
middlebox, of course. Message digests being managed accordingly/appropriately.

That is a very typical setup for most (all?) TLS inspection devices (next gen 
firewalls and such).

Thus this part of ECH, requiring the middlebox to be authoritative for the 
server, is well understood and prolifically exercised in inspected TLS sessions 
today. What is new is that these connections can now fail/close, in the 
“securely disabling ECH” case, and the onus is on the TLS client, not the 
application, to retry the connection without ECH.

I am after such a client, if one exists already.

Thank you.

Sent from my phone


On Oct 7, 2022, at 11:41 AM, Salz, Rich 
mailto:rs...@akamai.com>> wrote:



  *   Client <-> Middlebox <-> Client-facing server <-> Backend server


  *   With "Middlebox" really meaning a middlebox like a firewall or similar.

The middlebox is not allowed to modify traffic between the client and the 
server. Doing so would mean that the packets the client sent are not the ones 
that the server received, and the two message digests would disagree.  (If you 
think about things, it *has* to be this way, otherwise TLS would not be able to 
provide integrity guarantees.)


  *   From the draft, ECH seems to be designed to still allow successful TLS 
connection establishment if the encrypted_client_hello extension is dropped 
from the ClientHello on a conforming middlebox. Provided that the middlebox is 
authoritative for the client-facing server's public name, as reported/delivered 
by DNS to the client. We can assume that this is the case here.

I do not understand what you mean by this.  The word “authoritative” is used to 
mean that it has a certificate and keypair and can do TLS termination. DNS 
giving the client a particular IP address is not authoritative. It can be 
confusing because DNS terminology uses authoritative to mean that a particular 
entity can prepare data used for DNS responses.  But it is not authoritative in 
the TLS sense.

I think your questions can be answered with those two overall corrections 
above.  If not, please continue the thread.  (And feel free to repost from your 
note since I trimmed for brevity.)

___
TLS mailing list
TLS@ietf.org

Re: [TLS] Securely disabling ECH

[Hannes Tschofenig]

“Authoritative” is not the same as having “a valid TLS certificate for the 
server”. Everyone can get the certificate of a TLS server.

From: TLS  On Behalf Of 
ietf=40dennis-jackson...@dmarc.ietf.org
Sent: Monday, October 10, 2022 10:15 AM
To: tls@ietf.org
Subject: Re: [TLS] Securely disabling ECH


Hi,

provided the middlebox is authoritative (has a valid TLS certificate for the 
server in question), then Firefox will carry out the described retry behavior. 
Currently all ECH support is disabled behind a pref by default, but you can 
enable it by setting network.dns.echconfig.enabled to true. You will also need 
to enable DNS over HTTPS and browse to a domain with an ECH config.

Best,
Dennis


On 08/10/2022 04:40, Safe Browsing wrote:
Hi Rich,

When I say “authoritative”, I mean it in the true TLS sense, in the way that I 
believe the ECH draft also suggests and requires.

In other words, the middlebox serves a cert to the client that is 
cryptographically valid for the said public name of the client facing server.

How can that be when the client facing server guards its private key properly? 
By re-signing the server certificate on the middlebox with a private key, local 
to the middle box only, for which the corresponding certificate has been 
installed in the trust store of the client, before sending it on to the client. 
Only after the original server certificate has been validated properly on the 
middlebox, of course. Message digests being managed accordingly/appropriately.

That is a very typical setup for most (all?) TLS inspection devices (next gen 
firewalls and such).

Thus this part of ECH, requiring the middlebox to be authoritative for the 
server, is well understood and prolifically exercised in inspected TLS sessions 
today. What is new is that these connections can now fail/close, in the 
“securely disabling ECH” case, and the onus is on the TLS client, not the 
application, to retry the connection without ECH.

I am after such a client, if one exists already.

Thank you.

Sent from my phone


On Oct 7, 2022, at 11:41 AM, Salz, Rich 
 wrote:



  1.  Client <-> Middlebox <-> Client-facing server <-> Backend server


  1.  With "Middlebox" really meaning a middlebox like a firewall or similar.

The middlebox is not allowed to modify traffic between the client and the 
server. Doing so would mean that the packets the client sent are not the ones 
that the server received, and the two message digests would disagree.  (If you 
think about things, it *has* to be this way, otherwise TLS would not be able to 
provide integrity guarantees.)


  1.  From the draft, ECH seems to be designed to still allow successful TLS 
connection establishment if the encrypted_client_hello extension is dropped 
from the ClientHello on a conforming middlebox. Provided that the middlebox is 
authoritative for the client-facing server's public name, as reported/delivered 
by DNS to the client. We can assume that this is the case here.

I do not understand what you mean by this.  The word “authoritative” is used to 
mean that it has a certificate and keypair and can do TLS termination. DNS 
giving the client a particular IP address is not authoritative. It can be 
confusing because DNS terminology uses authoritative to mean that a particular 
entity can prepare data used for DNS responses.  But it is not authoritative in 
the TLS sense.

I think your questions can be answered with those two overall corrections 
above.  If not, please continue the thread.  (And feel free to repost from your 
note since I trimmed for brevity.)




___

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] SCHC for DTLS

[Hannes Tschofenig]

Bob, is this about compressing the DTLS record layer or the DTLS handshake 
protocol?
For the former, I wonder how much is there actually to compress (when using 
DTLS 1.3)?

From: TLS  On Behalf Of Eric Rescorla
Sent: Friday, May 27, 2022 5:30 PM
To: Robert Moskowitz 
Cc:  
Subject: Re: [TLS] SCHC for DTLS



On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz 
mailto:rgm-...@htt-consult.com>> wrote:
Is there any activity to define SCHC rules for DTLS?

Not to my knowledge.

-Ekr


I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID)
communications from the UA to the Net-RID Service Provider (SP).

See

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

I am compressing ESP traffic using rfc 8750 and:

https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

SCHC is negotiated in IKE (and will be in HIP) and SA tables allow the
ESP receiver to recognize a SCHC compressed ESP Header and act properly.

It is not so simple with DTLS.  First UDP is below DTLS, so how do you
compress it?  The way I see it, SCHC would need to be assigned an IP
Protocol type so that the transport processing can start right up with
the SCHC rule for UDP and then on to DTLS and then the cipher.

Or at least how I see the challenge.

So I am looking for any extant work on SCHC for DTLS and/or interest in
this activity.

The CoAP SCHC work, rfc 8824, dodge DTLS compression.  Or that is how I
read it.

Thanks

Bob

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hannes Tschofenig]

Hi Sean, Hi all,

I think the document should also include a reference to DTLS since there is no 
reason that sub-certs do not apply to DTLS as well.

Ciao
Hannes


-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Wednesday, February 16, 2022 9:26 PM
To: TLS List 
Subject: [TLS] DTLS for Delegated Credentials (draft-ietf-tls-subcerts)?

Hi

During Ben Kaduk’s AD review of draft-ietf-tls-subcerts, he noted that we need 
to address whether the I-D can also apply to DTLS. This might be useful for 
WebRTC, for example.

Right now the I-D exclusively mentions TLS. The fix might be as easy as a 
global replace of TLS with (D)TLS. Can anybody think of a reason to preclude 
DTLS?

We also need to say one way or the other becase we need to tell IANA to what to 
put in the “DTLS-Only” column when registering the “delegated_credentials” 
extension.

Cheers,
spt (for the chairs)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP in RFC7525bis

[Hannes Tschofenig]

Hi Yaron,

That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS) 
and also in IoT environments where it just don’t make a lot of sense to me. 
Hence, I would like to understand the motivation behind it and the use cases.

Ciao
Hannes


From: Yaron Sheffer 
Sent: Thursday, January 20, 2022 3:18 PM
To: Hannes Tschofenig ; u...@ietf.org; tls@ietf.org
Subject: Re: OCSP in RFC7525bis

Hi Hannes,

This is not about my personal beliefs. RFC 7525 looks at certificate revocation 
in the context of TLS (and not only TLS for Web use but the broader ecosystem) 
and recommends OCSP and OCSP Stapling as the best available techniques to 
enable effective certificate revocation, but with caveats. It’s been more than 
6 years since the RFC was published, and we are reviewing our recommendations, 
which may or may not still be valid.

Thanks,
Yaron

From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Date: Thursday, January 20, 2022 at 12:00
To: Yaron Sheffer mailto:yaronf.i...@gmail.com>>, 
u...@ietf.org<mailto:u...@ietf.org> mailto:u...@ietf.org>>, 
tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Subject: RE: OCSP in RFC7525bis
Hi Yaron,

Where do you believe OCSP will be a good fit and why?

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org<mailto:u...@ietf.org>; tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] OCSP in RFC7525bis

Hi,

RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use 
OCSP and OCSP stapling. We are changing these recommendations [2] in view of 
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail 
if they don’t get an OCSP response within the handshake, i.e. they just ignore 
the problem. As far as we understand, this makes OCSP stapling completely 
ineffective for what it’s trying to solve.

So for the new BCP, we have three options:

1.  Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly 
also TLS 1.2 implementations) to fail the handshake if the OCSP response is 
missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

2.  Remove the whole discussion of OCSP, saying that in its current form 
it’s not adding value.

3.  Maintain the status quo, where many people implement OCSP on the server 
side, but clients rarely benefit.

We would be grateful for feedback based on implementation experience. In 
particular if you have quantitative data on the use or quality of OCSP that’s 
more recent than Chung18 [3], that would be very useful.

Thanks,
Peter, Thomas and Yaron

PS: apologies for cross-posting.


[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files
[3] https://cbw.sh/static/pdf/chung-imc18.pdf

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] OCSP in RFC7525bis

[Hannes Tschofenig]

Hi Yaron,

Where do you believe OCSP will be a good fit and why?

Ciao
Hannes

From: TLS  On Behalf Of Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: u...@ietf.org; tls@ietf.org
Subject: [TLS] OCSP in RFC7525bis

Hi,

RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use 
OCSP and OCSP stapling. We are changing these recommendations [2] in view of 
OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail 
if they don’t get an OCSP response within the handshake, i.e. they just ignore 
the problem. As far as we understand, this makes OCSP stapling completely 
ineffective for what it’s trying to solve.

So for the new BCP, we have three options:

  *   Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly 
also TLS 1.2 implementations) to fail the handshake if the OCSP response is 
missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
  *   Remove the whole discussion of OCSP, saying that in its current form it’s 
not adding value.
  *   Maintain the status quo, where many people implement OCSP on the server 
side, but clients rarely benefit.

We would be grateful for feedback based on implementation experience. In 
particular if you have quantitative data on the use or quality of OCSP that’s 
more recent than Chung18 [3], that would be very useful.

Thanks,
Peter, Thomas and Yaron

PS: apologies for cross-posting.


[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files
[3] https://cbw.sh/static/pdf/chung-imc18.pdf

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Does revocation matter?

[Hannes Tschofenig]

Hey Felipe

There are three key questions when it comes to revocation checking, namely:
* What is the TLS stack being used for?
* What would the device do when a revocation check fails?
* How are the certificates and trust anchors managed?

You mentioned Mbed TLS. It is used for embedded devices. In the embedded 
environment you are not going to import all trust anchors typically found on a 
laptop or desktop PC. Instead, you will have a small number, often only one 
trust anchor. The device, because it has limited resources, will only talk to a 
small number of servers, often only one or two. These servers manage the device 
over it's lifetime, including providing firmware updates. Alongside this device 
management server is functionality to automatically provision the device with 
new certificates and also with trust anchors (if needed).

Since the device is under the full control of the device management server, any 
necessary changes to certificates will be managed by that server.

What benefit would CRLs and OSCP provide in such an environment?

If you want to hear more about the use of device management on IoT devices, I 
have published numerous videos about it. It is a widely deployed concept these 
days with standards available but also lots of proprietary solutions.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Felipe Gasper
Sent: Tuesday, December 7, 2021 2:56 PM
To: tls@ietf.org
Subject: [TLS] Does revocation matter?

Hi all,

I’ve been playing around with mbedTLS of late. It appears to lack any 
support for OCSP--either stapling or just simple client queries. It supports 
CRLs, but CRLs appear to be waning in terms of use; Let’s Encrypt, for example, 
doesn’t create them, as I suspect is the case with other short-term-validity 
certificate solutions.

mbedTLS is not the *most* prominent TLS implementation, but it’s also 
hardly the least. The projects that incorporate it (e.g., PowerDNS) clearly 
“survive” without OCSP. Chrome, at least doesn’t do OCSP client checks, and I 
don’t think it mandates OCSP stapling … which basically means there’s a huge 
swath of contexts where applications won’t notice if a certificate is revoked.

It begs the question … how relevant is certificate revocation nowadays? 
How big of a problem is it if TLS validity checks ignore it?

Cheers,
-Felipe Gasper
Mississauga, Ontario
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

Hi David,





  *   While it's true there is still plenty of 1.2 in many environments, 
defining a new extension like flags or connection ID won't make it apply to 
those connections. Both sides need to deploy new code to implement that 
extension. That means we shouldn't be looking at the trailing end of each 
environment, but the state of new deployments and where those should go. In 
that light, I think it makes sense to focus new protocol development on 1.3. If 
you have to deploy new TLS software anyway, you should migrate to 1.3.

This is just my experience: our partners are interested in moving to TLS 1.3. 
That’s great. There is still a lot of deployment based on 1.2. This deployment 
needs to be maintained. Companies have deployed the CID extension already and 
will apply software updates. Updating the code to add a feature, a bugfix and 
alike is one thing. Switching out the security stack altogether is not a minor 
thing.


  *   Indeed it's because there is still an existing 1.2 deployment that we 
should be judicious with backports. Today, nearly every TLS implementation 
needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it is 
not possible for a client to say "I implement xyz extension only at 1.3". That 
means anyone implementing a backported extension must implement and test it in 
1.2, even though it'll be virtually unused. Existing 1.2 peers don't implement 
it and new peers will use it at 1.3.

In the IoT space, the device have constraints. They are not implementing a dual 
stack 1.2 / 1.3 version for Cortex M class devices (at least in almost all 
cases).

If I have to define an extension for use with the ClientHello in DTLS 1.2 and a 
different one (based on flags) in DTLS 1.3 then this would not make my life any 
easier.

Ciao
Hannes

On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
The term “obsolete” appears to be used incorrectly when it comes to TLS/DTLS 
1.2 used in the IoT environment. It is widely used today and I expect it to be 
used for a while since (a) there are no security problems with it (when 
configured correctly), and (b) for many use cases it also offers suitable 
performance. There is a well-tested open source codebase available for TLS/DTLS 
1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge 
the speed at which the market operates.

From: John Mattsson 
mailto:john.matts...@ericsson.com>>
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; IETF TLS 
mailto:tls@ietf.org>>
Subject: Re: Flags Extension: why only for TLS 1.3?

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS mailto:tls@ietf.org>>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

The term "obsolete" appears to be used incorrectly when it comes to TLS/DTLS 
1.2 used in the IoT environment. It is widely used today and I expect it to be 
used for a while since (a) there are no security problems with it (when 
configured correctly), and (b) for many use cases it also offers suitable 
performance. There is a well-tested open source codebase available for TLS/DTLS 
1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge 
the speed at which the market operates.

From: John Mattsson 
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig ; IETF TLS 
Subject: Re: Flags Extension: why only for TLS 1.3?

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS mailto:tls@ietf.org>>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

The problem we ran into is the following: We are just publishing the RFCs for 
the connection IDs for DTLS 1.2 and for DTLS 1.3. For the RRC work we need to 
define an extension. Using the flags extension makes a lot of sense for TLS 1.3 
(to avoid wasting bytes sent over the wire). Should we do something entirely 
different for DTLS 1.2?

-Original Message-
From: Sean Turner 
Sent: Thursday, November 4, 2021 2:27 PM
To: Hannes Tschofenig 
Cc: TLS List 
Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?

Hannes,

Sorry I forgot to answer this, but John pretty much answered it for me. The 
prevailing notion that the WG has been under is that extensions defined are for 
TLS 1.3. We put the following in the charter to make that clear:

   Changes or additions to older versions of (D)TLS whether
   via extensions or ciphersuites are discouraged and require
   significant justification to be taken on as work items.

So ... do you have a significant justification?

Cheers,
spt

> On Nov 4, 2021, at 09:11, John Mattsson 
>  wrote:
>
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
> obsolete as "no longer produced or used; out of date." NIST requires support 
> of TLS 1.3 everywhere no later than Jan 2024, which at least in theory means 
> no negotiation of TLS 1.2.
>
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
> rather than giving the false idea it is ok to stay on TLS 1.2.
>
> John
>
> From: TLS  on behalf of Hannes Tschofenig 
> 
> Date: Monday, 25 October 2021 at 19:12
> To: IETF TLS 
> Subject: [TLS] Flags Extension: why only for TLS 1.3?
>
> Hi all,
>
> why is the flags extension only defined for TLS 1.3?
>
> There is nothing in this extension that prevents us from using it also in TLS 
> 1.2.
>
> Could we make it also available to TLS 1.2?
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] TLS Flags and IANA registration policy

[Hannes Tschofenig]

Rich, this makes more sense. Maybe the column should say "IETF Consensus"  
(Y/N) instead of Recommended.

In any case, the draft should say what recommended means for the flags values.

-Original Message-
From: TLS  On Behalf Of Salz, Rich
Sent: Tuesday, October 26, 2021 3:19 PM
To: Ilari Liusvaara ; IETF TLS 
Subject: Re: [TLS] TLS Flags and IANA registration policy

The Recommended column is "was this done via IETF consensus."  Some of the 
values you think are odd are from pre-1.3, done by consensus, even if the 
protocol is now outdated by 1.3

If there are some 1.0 and 1.1 extensions that are not defined in 1.2, then that 
deprecation draft should suggest IANA changes.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] TLS Flags and IANA registration policy

[Hannes Tschofenig]

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.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS Flags and IANA registration policy

[Hannes Tschofenig]

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"?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Iot-directorate] [Last-Call] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Hannes Tschofenig]

I have no problem with the suggestion.

A few other observations:

1. FWIW: The reference to [Wang] is incomplete.

2. The references to the other papers use the websites of the authors or 
project websites. I would use more stable references.

3. Kathleen's affiliation is also outdated.

4. Is the update to RFC 7525 relevant given that there is an update of RFC 7525 
in progress (see 
https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc7525bis-01) and even 
near completion?

5. The title of the draft gives the impression that this update only refers to 
TLS 1.2 but later in the draft DTLS is also included via the reference to RFC 
7525. Should the title be changed to "Deprecating MD5 and SHA-1 signature 
hashes in TLS/DTLS 1.2"?

Ciao
Hannes

-Original Message-
From: Iot-directorate  On Behalf Of Russ 
Housley
Sent: Wednesday, July 28, 2021 10:34 PM
To: Sean Turner ; IETF TLS 
Cc: iot-director...@ietf.org; draft-ietf-tls-md5-sha1-deprecate@ietf.org; 
last-c...@ietf.org
Subject: Re: [Iot-directorate] [TLS] [Last-Call] Iotdir last call review of 
draft-ietf-tls-md5-sha1-deprecate-04

>   In Section 7.1.4.1: the following text is removed:

 If the client supports only the default hash and signature algorithms
 (listed in this section), it MAY omit the signature_algorithms
 extension.

>   Since it’s a MAY, I am a-okay with deleting. Anybody else see harm?

I don't see any harm.

Russ

--
Iot-directorate mailing list
iot-director...@ietf.org
https://www.ietf.org/mailman/listinfo/iot-directorate
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What's it called

[Hannes Tschofenig]

Depends on the algorithm and its parameters. Here is a recent document talking 
about AES algorithms limits.
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-02

From: TLS  On Behalf Of Tim Bray
Sent: Thursday, June 24, 2021 9:13 PM
To: Paterson Kenneth 
Cc: tls@ietf.org; Salz, Rich 
Subject: Re: [TLS] What's it called

How much data is too much?

On Thu, Jun 24, 2021 at 12:02 PM Paterson Kenneth 
mailto:kenny.pater...@inf.ethz.ch>> wrote:
Hi Rich,

We speak of reaching data limits, and the process of changing the key has many 
names, e.g. key rotation, key renewal, key refreshing, key updating.

Any of those ring a bell?

Cheers

Kenny


From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
"Salz, Rich" 
mailto:40akamai@dmarc.ietf.org>>
Date: Thursday, 24 June 2021 at 19:32
To: "tls@ietf.org" mailto:tls@ietf.org>>
Subject: [TLS] What's it called

I’m blanking on a term and web searches turn up too much useless info.

What is it called when we have to start using a new symmetric key because we’ve 
encrypted too much data with the old one?  Key exhaustion fits, but probably 
isn’t it.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Hannes Tschofenig]

Hi Sean,

Thanks for keeping track of the backlog of drafts.

I am still interested to do this work and I contributed to the draft because a 
generic mechanism for doing the return routability check is better than pushing 
the responsibility to the application layer. There is always the risk that 
application developers impact security properties unintentionally.

Ciao
Hannes


-Original Message-
From: TLS  On Behalf Of Sean Turner
Sent: Monday, May 3, 2021 5:45 PM
To: TLS List 
Subject: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

Hi!

We would like to re-run the WG adoption call for "Return Routability Check for 
DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of this draft 
as a WG item by posting a message to the TLS list by 2359 UTC 24 May 2021.  
Please include any additional information that is helpful in understanding your 
position.

NOTES:

1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection 
Identifiers for DTLS 1.2 [2] is done.
2) Here is a link to the original WG adoption call [3].

Thanks,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
[3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC5246 (6572)

[Hannes Tschofenig]

Hi Johannes,

TLS 1.2 has been obsoleted by TLS 1.3. Prior to this, other specifications have 
profiles the algorithm choice (see RFC 7525 and RFC 7925).

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of RFC Errata System
Sent: Wednesday, May 5, 2021 12:21 PM
To: t...@dierks.org; e...@rtfm.com; r...@cert.org; ka...@mit.edu; 
c...@heapingbits.net; j...@salowey.net; sean+i...@sn3rd.com
Cc: rfc-edi...@rfc-editor.org; tls@ietf.org; johannes.goerl...@siemens.com
Subject: [TLS] [Technical Errata Reported] RFC5246 (6572)

The following errata report has been submitted for RFC5246, "The Transport 
Layer Security (TLS) Protocol Version 1.2".

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

--
Type: Technical
Reported by: Johannes Görlich 

Section: 9

Original Text
-
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

Corrected Text
--
In the absence of an application profile standard specifying otherwise, a 
TLS-compliant application MUST implement the cipher suite 
TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).

Notes
-
A must-be-implement cipher suite should not relay on a bulk encryption 
algorithm which is vulnerable to plain-text attacks or on a secure hash 
algorithm which has been proven to be insecure.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use "Reply 
All" to discuss whether it should be verified or rejected. When a decision is 
reached, the verifying party can log in to change the status and edit the 
report, if necessary.

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

Hi Martin,

The attack described in Section 9.3.3 of 
https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a 
lot of assumptions about the attacker.

I am not opposed to adding the recommendation but I want to understand it first 
since there is also a price to pay for it (in terms of complexity and 
performance). Like elsewhere there is no free lunch.

Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the 
attacker needs to be able to
* observe the packets sent by DTLS endpoints in both directions, and
* replay the packets in such a way that they arrive faster than the original 
packets send by the DTLS endpoints, and
* re-write both source and destination IP address to appear like a NAT for both 
endpoints.

The last point is needed to ensure that the packet re-routing persists.

IMHO these assumptions hint to an on-path attacker. An on-path attacker (such 
as a router) can already today perform a denial of service attack on DTLS 
secured communication by dropping all packets.

Ciao
Hannes

-Original Message-
From: Martin Duke via Datatracker 
Sent: Tuesday, April 20, 2021 9:47 PM
To: The IESG 
Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; 
tls@ietf.org; Joseph Salowey ; j...@salowey.net
Subject: Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: 
(with COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



--
COMMENT:
--

Thanks for this document.

Section 9.3.3 of quic-transport, which deals with basically the same security 
model, also requires the receiving endpoint to probe the original address, not 
just the new one, to address a somewhat more difficult attack. It would be good 
to at least RECOMMEND this behavior for DTLS applications, and/or 
(repeat/informatively reference) the logic there.



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

Hi John,


[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!

Which one of these is clearer seems like a question of taste, I should think.
It's worth noting that because the length prefix is determined by the ceiling,
arguably 2^8-1 is clearer.

I don’t follow your point, but suit yourself.

[Hannes] As mentioned by Ekr it is a matter of taste how to describe the 
payloads. We follow the style used in previous TLS specifications.
In any case, for an implementer it is important to know the length of each data 
item.

For example, if you have a ceiling of 2^16-1 for a data item you know that two 
bytes have to be written (or parsed). Here is a copy-and-paste from the Mbed 
TLS code to show an example:

*p++ = (unsigned char)( ( MBEDTLS_TLS_EXT_SERVERNAME >> 8 ) & 0xFF );
*p++ = (unsigned char)( ( MBEDTLS_TLS_EXT_SERVERNAME ) & 0xFF );

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

Hi Francesca,

~ snip ~

5. -

Section 10.2

FP: Just checking - why is 53 "incompatible with this document"?

[Hannes] Maybe someone responded already regarding this point. I don't know 
whether it is good or bad practice to provide all this background in the IANA 
considerations but the story here is (if I recall it correctly) that we 
initially assigned the value 53 and implementations used in deployments use 53. 
Then, late in the process we changed the MAC calculation in Section 5...

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

Hi John, Hi Ekr,

Regarding the presentation language used in the document I have added a 
clarification to the terminology section, see 
https://github.com/tlswg/dtls-conn-id/pull/110.

I hope this addresses the issue.

Ciao
Hannes


From: Eric Rescorla 
Sent: Tuesday, April 20, 2021 11:32 PM
To: John Scudder 
Cc: The IESG ; draft-ietf-tls-dtls-connection...@ietf.org; 
tls-chairs ;  ; Joseph Salowey 

Subject: Re: John Scudder's No Objection on 
draft-ietf-tls-dtls-connection-id-11: (with COMMENT)



On Tue, Apr 20, 2021 at 2:09 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> wrote:
John Scudder has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



--
COMMENT:
--

I found this document heavy sledding but once I was through it, it all came
together, with the exception of my #3, below. The “heavy sledding” part I think
would be largely fixed by addressing my #1, below.

1. Section 3:

This pseudocode is a little too pseudo for me:

 struct {
 opaque cid<0..2^8-1>;
 } ConnectionId;

What does the content of the angle brackets mean? At first I took it to mean
“this can take on a value from 0 to 255” [*] but parts of the spec that go on
about variable lengths made me think that couldn’t be right. Eventually, by
paging through RFC 5246, I found some explanations of what this stuff is
supposed to mean; in §4.3 of that RFC I found out that

   Variable-length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation .  When
   these are encoded, the actual length precedes the vector's contents
   in the byte stream.  The length will be in the form of a number
   consuming as many bytes as required to hold the vector's specified
   maximum (ceiling) length.

I assume this is what’s going on in DTLS as well. This cleared up my main
source of confusion, which was regarding just how you were encoding these
variable-length CIDs anyway. (And oh by the way, that definition doesn’t say
what the units of length are. Bytes seems implied but isn’t explicit.)

While I don’t expect you to supply these definitions again, it would be
courteous to your readers to have a sentence or two explaining that pseudo-code
conventions are found in RFC 5246, special extra credit for section references
as well. And yes, I did notice "This document assumes familiarity with DTLS 1.2
[RFC6347].” That’s well and good, but I don’t think “familiarity” is the same
as “we have adopted the same notational conventions”

This seems like a pretty basic assumption. These aren't just notational 
conventions
or pseudo-code. They're the protocol description language that TLS is defined 
in.
If one isn't familiar with how to read this syntax, then you really don't have 
much of
a hope of correctly implementing this specification.


[*] By the way, why not just use “255” in the text instead of “2^8-1”? Eschew
obfuscation!

Which one of these is clearer seems like a question of taste, I should think.
It's worth noting that because the length prefix is determined by the ceiling,
arguably 2^8-1 is clearer.


2. Section 3:

   If DTLS peers have negotiated the use of a non-zero-length CID for a
   given direction, then once encryption is enabled they MUST send with
   the record format defined in {{dtls-ciphertext} with the new MAC
   computation defined in Section 5 and the content type tls12_cid.
   Plaintext payloads never use the new record type and the CID content
   type.

What’s “{{dtls-ciphertext}”? I’m guessing just a botched xref?

Yes, presumably. Looks like I forgot a }}.


Also, the first sentence seems to have no object. (What MUST they send?)

send anything, but I suppose "send records". I can make a change.


3. Section 6:

   *  There is a strategy for ensuring that the new peer address is able
  to receive and process DTLS records.  No such strategy is defined
  in this specification.

This is a little mind-boggling to me. I understand this to mean I can’t send
the new address a DTLS record unless I’ve already ensured it can receive and
process that record, right? This seems almost like a classic Catch-22. I feel
like I must be missing something.

This specification *only* allows you to mux, but doesn't allow you to migrate.
We could probably make this point clearer.

-Ekr

IMPORTANT NOTICE: The contents of this email and any attachments are 

Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

Hi John, Hi Ekr,

I hope I correctly understand the essence of your conversation. I am wondering 
whether a link from the bullet list to the text two paragraphs down will help. 
Here is my proposal:
https://github.com/tlswg/dtls-conn-id/pull/111

Ciao
Hannes

From: John Scudder 
Sent: Wednesday, April 21, 2021 2:07 AM
To: Eric Rescorla 
Cc: The IESG ; draft-ietf-tls-dtls-connection...@ietf.org; 
tls-chairs ; tls@ietf.org; Joseph Salowey 

Subject: Re: John Scudder's No Objection on 
draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

On Apr 20, 2021, at 7:24 PM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
On Tue, Apr 20, 2021 at 3:42 PM John Scudder 
mailto:j...@juniper.net>> wrote:
On Apr 20, 2021, at 5:32 PM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
3. Section 6:

   *  There is a strategy for ensuring that the new peer address is able
  to receive and process DTLS records.  No such strategy is defined
  in this specification.

This is a little mind-boggling to me. I understand this to mean I can’t send
the new address a DTLS record unless I’ve already ensured it can receive and
process that record, right? This seems almost like a classic Catch-22. I feel
like I must be missing something.

This specification *only* allows you to mux, but doesn't allow you to migrate.
We could probably make this point clearer.

Yes, I think so. Various things led me to think this was supposed to be a 
feature. For starters, the abstract:


   A CID is an identifier carried in the record layer header that gives

   the recipient additional information for selecting the appropriate

   security association.  In "classical" DTLS, selecting a security

   association of an incoming DTLS record is accomplished with the help

   of the 5-tuple.  If the source IP address and/or source port changes

   during the lifetime of an ongoing DTLS session then the receiver will

   be unable to locate the correct security context.

It’s true the abstract doesn’t promise that I can migrate to the new address, 
but I felt led in that direction. But more to the point, §6 itself:


   When a record with a CID is received that has a source address

   different than the one currently associated with the DTLS connection,

   the receiver MUST NOT replace the address it uses for sending records

   to its peer with the source address specified in the received

   datagram unless the following three conditions are met:

If I understand your reply correctly, the quoted sentence could end “… unless 
the following three conditions are met (which will never happen):”. Since that 
seems both capricious and pointless, I still think I’m missing something. Is it 
that you envision a future specification that does define a strategy that will 
fulfill the third condition?

Yes.

Got it, thanks. In that case I think it brings us back to your earlier “we 
could probably make this point clearer”.

—John
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Transport Issues in DTLS 1.3

[Hannes Tschofenig]

Hi Bill,

> Are there any issues with space-based paths? I know Elon Musk is planning 
> Internet service via many LEO satellites.
>
> If we were talking about going to the moon, that would be a 3 second delay.
>
> Cheers - Bill

There are profiles for TLS/DTLS for specific deployment environments. One such 
deployment environment is IoT where TLS/DTLS is used in mesh networks and 
networks with lossy links. For those deployment environments we use a different 
timeout. For example, RFC 7925 says "An initial timer value of 9 seconds with 
exponential back off up to no less then 60 seconds is therefore RECOMMENDED." 
for DTLS 1.2

The recommendations for DTLS 1.3 are work in progress in 
draft-ietf-uta-tls13-iot-profile.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Transport Issues in DTLS 1.3

[Hannes Tschofenig]

Hi Martin,

the main issue Ekr is bringing up is that the DTLS handshake happens 
infrequently and it is small in size.
The use of DTLS for protecting application traffic is not impacted by this 
timeout.

Ciao
Hannes

-Original Message-
From: Martin Duke 
Sent: Tuesday, March 30, 2021 8:48 PM
To: Mark Allman 
Cc: Eric Rescorla ; draft-ietf-tls-dtls13@ietf.org; Lars 
Eggert ; Gorry Fairhurst ; 
 
Subject: Re: Transport Issues in DTLS 1.3

 Thank you Eric (and Mark).

To reiterate, I believe introducing latency regressions with respect to DTLS 
1.2 would be bad for the internet. So what's new in the area under discussion 
is (a) lowering the timeout from 1s to 100ms, and (b) the introduction of ACKs.

I would characterize ekr's reply as making the following points:

(1) *DTLS practice at Mozilla and elsewhere already uses timeouts << 1 sec*
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Hannes Tschofenig]

Hi Tom,

I added a few PRs to address your review (see 
https://github.com/tlswg/dtls-conn-id/pulls).

Regarding the zero-length CID I believe the current version in the repo at 
https://github.com/tlswg/dtls-conn-id might have already address your remark.

In general, the zero-length CID in the ClientHello / ServerHello allows us to 
use CIDs unidirectionally.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Thomas Fossati
Sent: Friday, March 12, 2021 11:58 AM
To: tom petch ; last-c...@ietf.org
Cc: tls@ietf.org; tls-cha...@ietf.org; 
draft-ietf-tls-dtls-connection...@ietf.org
Subject: Re: [TLS] Last Call:  
(Connection Identifiers for DTLS 1.2) to Proposed Standard

Hi Tom,

Thanks very much!

Your review is tracked in the issues below.

On 12/03/2021, 10:39, "tom petch"  wrote:
>
> Some editorial quirks
>
> s.2
> lacks the boiler plate of RFC8174

https://github.com/tlswg/dtls-conn-id/issues/88

> s.3
> I found this unclear until I had understood it all (or perhaps I do
> not understand it)
>
> "...or again, alternately, to use a zero-length CID)."
> This suggests that a zero length CID is valid in Application Data
> which later text seems to contradict; otherwise I cannot see what this is 
> saying.
>
> "  If DTLS peers have negotiated the use of a CIDs using the
> ClientHello and the ServerHello messages "
> arguably sending a zero CID and receiving a zero CID is a successful
> Hello negotiation perhaps " If DTLS peers have negotiated the use of a
> non-zero CID in at least one direction, using the ClientHello and the
> ServerHello messages"
>
> "The DTLS peers determine whether incoming and outgoing messages need.."
> seems not to cater for unidirectional CIDs; perhaps "The DTLS peers
> determine whether incoming or outgoing, or both, messages need.. "

https://github.com/tlswg/dtls-conn-id/issues/89

> s.4
> /always recieve CIDs/always receive CIDs/
>
>
> s.5.1
> "the with Encrypt-then-MAC processing described in [RFC7366]."
> I do not understand why 'with' is needed
>
> s.5.2
> ditto
>
> s.8
> /this aspects SHOULD refuse/these aspects SHOULD refuse/

https://github.com/tlswg/dtls-conn-id/issues/90

> s.10
> I would find this clearer as three sections for the three IANA actions
> 10.1 new column for ExtensionType
> 10.2 new value for ExtensionType
> 10.3 new value for ContentType
>
> "   IANA is requested to allocate an entry to the existing TLS
> "ExtensionType Values" registry, defined in [RFC5246],.."
> well no; whatever you think of RFC8447 the name has changed
> "   IANA is requested to allocate an entry to the existing "TLS
> ExtensionType Values" registry, defined in [RFC5246],.."
> or, if you are picky (which I am not),
> IANA is requested to allocate an entry to the existing "TLS
> "ExtensionType Values" registry, defined in [RFC5246], and
> renamed by RFC8447
>
> An extra column is added but I cannot see what value should be placed
> in that column for existing entries.
>
> "The tls12_cid ContentType is only applicable to DTLS 1.2."
> Good information but I struggle to see what IANA will do with it; I
> see nowhere for it to go.

https://github.com/tlswg/dtls-conn-id/issues/91


cheers, t

> Tom Petch
>
>
> On 08/03/2021 11:19, The IESG wrote:
>
>
> >
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document: - 'Connection Identifiers for 
> > DTLS 1.2'
> > as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> > solicits final comments on this action. Please send substantive
> > comments to the last-c...@ietf.org mailing lists by 2021-03-28.
> > Exceptionally, comments may be sent to i...@ietf.org instead. In
> > either case, please retain the beginning of the Subject line to allow 
> > automated sorting.
> >
> > Abstract
> >
> >
> > This document specifies the Connection ID (CID) construct for the
> > Datagram Transport Layer Security (DTLS) protocol version 1.2.
> >
> > A CID is an identifier carried in the record layer header that gives
> > the recipient additional information for selecting the appropriate
> > security association.  In "classical" DTLS, selecting a security
> > association of an incoming DTLS record is accomplished with the help
> > of the 5-tuple.  If the source IP address and/or source port changes
> > during the lifetime of an ongoing DTLS session then the receiver will
> > be unable to locate the correct security context.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > ___
> > IETF-Announce mailing list
> > ietf-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > .
> >
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential 

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Hannes Tschofenig]

Graham, Deb,


  *   'Expiry:  for the server/client.  I suspect this is mostly a 'don't 
care', except in the case where a certificate *should* be revoked after it is 
expired (nobody does that, right?).  Is this worth addressing?  I suspect not.'

I agree.



  *   I would imagine that the implementation would pull the session down once 
the certificate expires, so the session only lasts for the lifetime of the 
certificate.

Agree. I guess this case rarely happens because short-lived certificates are 
not so short lived after all.



  *   Revocation:  The RP* can check this whenever it desires.  If one has 
designed a long lived connection, then the RP needs to handle it.  Does TLS, 
the protocol need to handle it?  Don't know.

I don’t see a need for TLS to do something.


  *   Short lived certificates:  I think these are a good idea.  And if one 
does this, rekey/renewal early and often is the way to prevent breakage.  
IMHO

I would imagine that the change of certificate will trigger a new handshake. If 
only the client-side certificate changes on a regular basis then I could 
imagine the Post handshake authentication to be quite useful.

Ciao
Hannes

On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley 
mailto:debcool...@gmail.com>> wrote:
So we can break this down into 2 categories:

expiry
revocation

for both clients and servers.

Expiry:  for the server/client.  I suspect this is mostly a 'don't care', 
except in the case where a certificate *should* be revoked after it is expired 
(nobody does that, right?).  Is this worth addressing?  I suspect not.

Revocation:  The RP* can check this whenever it desires.  If one has designed a 
long lived connection, then the RP needs to handle it.  Does TLS, the protocol 
need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does 
this, rekey/renewal early and often is the way to prevent breakage.  IMHO




On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett 
mailto:graham.i...@gmail.com>> wrote:
Hi

I have a fair amount of hands on experience with IPsec VPNs, and many 
organisations look to use TLS in a similar manner.

To give you an example of where you might look to perform a regular revocation 
check on long lived connections;

Solution with many remote devices (think remote access, so phones, laptops, IoT 
devices etc)
A remote device is compromised, on the gateway there could be 1000s of devices 
connected.
I've found that most vendor solutions aren't geared up for an admin to easily 
determine the compromised device and prevent this reconnecting. Most 
organisations have a disconnect between the SOC, PKI team and the team that 
manages the remote access gateway, getting a process that'll involve all 3 
teams usually doesn't work.

I've found that the best method to prevent the device from connecting is for 
the certificate to be revoked, the CRL refreshed and then a re-authentication 
performed on all active connections.

I'm not as familiar with TLS as I am IPsec, but hope that this explains a 
scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nico Williams mailto:n...@cryptonector.com>> writes:

>When expirations are short, you will not forget to renew.  That's part of the
>point of short-lived certificates.

So instead of getting one chance a year for your control system to break
itself if the renewal fails, you get hundreds of them?

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Hannes Tschofenig]

Focusing on one sentence from below:


  *   I've found that the best method to prevent the device from connecting is 
for the certificate to be revoked, the CRL refreshed and then a 
re-authentication performed on all active connections.

Why would you trigger re-authentication of all connections? You could terminate 
the connection of the device with the compromised certificate.

In your IPSec VPN scenario, how do you get a new certificate to the compromised 
device?

Ciao
Hannes

From: TLS  On Behalf Of Graham Bartlett
Sent: Sunday, March 7, 2021 12:16 PM
To: Peter Gutmann 
Cc: John Mattsson ; TLS List 

Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in 
long lasting connections

Hi

I have a fair amount of hands on experience with IPsec VPNs, and many 
organisations look to use TLS in a similar manner.

To give you an example of where you might look to perform a regular revocation 
check on long lived connections;

Solution with many remote devices (think remote access, so phones, laptops, IoT 
devices etc)
A remote device is compromised, on the gateway there could be 1000s of devices 
connected.
I've found that most vendor solutions aren't geared up for an admin to easily 
determine the compromised device and prevent this reconnecting. Most 
organisations have a disconnect between the SOC, PKI team and the team that 
manages the remote access gateway, getting a process that'll involve all 3 
teams usually doesn't work.

I've found that the best method to prevent the device from connecting is for 
the certificate to be revoked, the CRL refreshed and then a re-authentication 
performed on all active connections.

I'm not as familiar with TLS as I am IPsec, but hope that this explains a 
scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>> wrote:
Nico Williams mailto:n...@cryptonector.com>> writes:

>When expirations are short, you will not forget to renew.  That's part of the
>point of short-lived certificates.

So instead of getting one chance a year for your control system to break
itself if the renewal fails, you get hundreds of them?

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Hannes Tschofenig]

Nico raised some really good points here.

I think it is useful to start with the problem description.

It seems that you are concerned that there is a possibility for leakage or 
compromise of keying material during the lifetime of the session.
What could happen?

* Long-term keys*,
* Some keys used in the key hierarchy,
* keys used for protecting the application traffic

Additionally, you could also consider the case that the trust anchor store gets 
compromised.

In any case, you seem to be concerned about the leakage of long-term keys (at 
least that's what I get from the email thread).

If your long-term keys got compromised then you have a serious problem. 
Re-running even the full handshake will not indicate problem. It will just work 
fine.

You will somehow have to find out that these long-term keys have been leaked, 
which will not be easy. Then, you need to isolate the endpoints using those 
compromised keys and reprovision new keys to them. You might want to terminate 
ongoing connections as well. Since you will often not know what exactly has 
been compromised (at least not quickly enough), you might need to take a range 
of steps to re-set it to a known good state (such as doing a firmware update, 
in case of an IoT device).

Many of these aspects are, however, outside the scope of TLS itself.

Could you elaborate on the threats you are trying to address?

Ciao
Hannes

*: Often a device has more than one long-term key pair (used for different 
purposes). Without further complicating things, the impact depend a bit on 
which keys have been leaked.

-Original Message-
From: TLS  On Behalf Of Nico Williams
Sent: Friday, March 5, 2021 8:35 PM
To: John Mattsson 
Cc: tls@ietf.org
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in 
long lasting connections

On Fri, Mar 05, 2021 at 06:42:40PM +, John Mattsson wrote:
> >While renegotiation will never be re-added, there is post-handshake
> >authentication (RFC 8446, section 4.6.2), and while that is currently
> >about authenticating the _client_ to the server, it should be trivial
> >to extend the protocol to support re-authenticating the server to the
> >client as well.
>
> I think the current Post-Handshake authentication is not really
> suitable for long-term connections. It assures that the other party is
> still alive but it does not shut out any other third parties with
> access to application_traffic_secret_N. Such parties may have gotten
> the key with or without collaboration with one of the nodes.

We assume local security, so the only way the TLS keys could have leaked to 
third parties is if either a) the local security assumption fails, in which 
case you have bigger problems, or b) the cryptographic security of TLS itself 
failed, in which case you have bigger problems, or c) you're exceeding usage 
limits on a symmetric cipher.

Changing session keys wouldn't help you in cases (a) or (b).

I think the only interesting case is (c).  If you're using a 128-bit block 
cipher, you're not in case (c) as you'd have to transfer something like 2PB 
before you exceed AES key usage limits.

At some point you have to be prepared to reconnect.  Application protocols that 
work like BGP (destroy the world on RST) simply need to be fixed to not do that.

> Agree that the negotiation part of renegotiation should not come back.
> Below is a sketch of what I think would be needed Post-Handshake for

That's essentially renego-lite.  Note that there's protocol timing trickiness 
in getting this right.  SSHv2, which does have proper re-keying, has experience 
with that.

> DTLS/SCTP with DTLS 1.3:

What's special about DTLS vs. TLS?  Why should one get this but not the other?

Nico
--

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[TLS] draft-friel-tls-eap-dpp-01

[Hannes Tschofenig]

Hi all,

I have watched the EMU presentation about draft-friel-tls-eap-dpp-01 at the 
last IETF meeting (see ) 
https://datatracker.ietf.org/meeting/109/materials/slides-109-emu-eap-dpp-00and,
 at that time, I was confused about the scope of the proposed work.

Having read into the WiFi DPP specification in the meanwhile I believe that 
this is a very useful contribution, which simplifies the enrollment of WiFi 
devices to a network.

Hence, I am in support of the document*.

Ciao
Hannes

*: There are various open issues here and there in the draft that need to be 
worked out. The worksplit between EMU and the TLS WG is also something that 
requires the chairs to look into.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Hannes Tschofenig]

FWIW the current scheme described in 
https://tools.ietf.org/html/draft-ietf-tls-ctls-01 only offers variable length 
encoded integers of one to three bytes. We need more than that.

I am in favor of the “deterministic” version, if deterministic means no 
overlaps in the encoded number ranges.

Hence, I am in favor of 2 but would leave the details of how we encode it open 
to work in the group. There are various possible designs and none of them is 
rocket science.

Ciao
Hannes

From: TLS  On Behalf Of Eric Rescorla
Sent: Sunday, November 15, 2020 9:13 PM
To: Nick Harper 
Cc:  
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Trying to close out this discussion, it seems to me like there are three major 
options:

1. The current scheme
2. The current scheme with a deterministic minimal encoding (e.g., the two byte 
version is offset by 127)
3. The QUIC scheme

I don't think that the QUIC scheme with deterministic encoding makes sense, 
because the virtue of the QUIC scheme is commonality with something already 
defined. I'm hearing that people are not as excited about moving to QUIC as I 
had expected and to the best of my knowledge, there is no valid reason to 
encode to > 2^32-1 in TLS. I also don't think using encoding (1) but mandating 
minimal length makes sense, as it's just as easy to do a deterministic minimal 
encoding.

As Christian observes it *is* significantly more painful to do (2): the 
conventional way to encode vectors in TLS with minimal copying is:

- Mark your current place --> X
- Skip forward the length of the length field --> L
- Encode the value
- Encode (current position - (X + L)) at X

But this won't be possible in (2). As MT observes, if you think of this as a 
two-pass system, there is not as much of a problem here [though not necessarily 
no problem]. Also, if you use a separate buffer, there is no problem. As noted 
above by MT and others, cTLS expands the transcript and so having a 
deterministic compression scheme is perhaps not as important, given that 
decompression is deterministic, but it still seems nice to have.

Given the above, I think my preference would be (1) or (2), with, I think, a 
slight preference for (2).

-Ekr









On Tue, Oct 6, 2020 at 5:33 PM Nick Harper 
mailto:nhar...@google.com>> wrote:
I have no strong opinion on how this is formatted. I'd base my decision on what 
the maximum value cTLS needs to encode: If 2^22-1 is sufficient, let's keep it 
as is, otherwise let's change it to the QUIC format (or some other change to 
increase the max value). I do like that the existing scheme, compared to QUIC 
varints, is more efficient for values 64-127 and just as efficient for the rest.

On Mon, Oct 5, 2020 at 8:09 PM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
I don't have a strong opinion on whether to require a minimal encoding, but if 
we're not going to use QUIC's encoding as-is, then I would rather stick with 
the existing scheme, which has twice as large a range for the 1 byte encoding 
and is thus more compact for a range of common cases.

-Ekr


On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
In that case, why use QUIC's encoding at all? It would just put the burden on 
the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the 
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers 
from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?

On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
Can you just say “QUIC rules but use the minimum possible length”?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Hannes Tschofenig]

Hi Ekr,

I had a chat with Richard about this and this change makes a lot of sense 
(particularly since the current cTLS draft only defines the encoding of varints 
up to 3 bytes).

In the work on QUIC did you discuss the ability to make the encoding such that 
there are no ways to express a number in two different ways, as shown in your 
example with the single byte 25 decoding to 37 and the two byte sequence 40 25?

Ciao
Hannes



From: TLS  On Behalf Of Eric Rescorla
Sent: Tuesday, October 6, 2020 3:38 AM
To: Marten Seemann 
Cc:  
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Yeah, I'm certainly sympathetic to this. TBH, from an aesthetic perspective I 
prefer what's in cTLS now (though it had the same property) but I figured that 
some consistency was nice.

-Ekr



On Mon, Oct 5, 2020 at 6:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
One thing that’s a bit annoying about QUIC’s variant format is that there are 
multiple ways to encode a number. This has led to some complications in the 
specification (e.g. QUIC requires you to use the minimal encoding for frame 
types, but allows all encodings everywhere else).
It would be nice to have an unambiguous way to encode a number.

On Tue, Oct 6, 2020 at 07:35 Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Hi folks,

cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose 
adopting their varint format.

https://github.com/tlswg/draft-ietf-tls-ctls/pull/28

Any objections?
-Ekr

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Rob,

From the email Watson sent I got the impression that he does not believe there 
are CPU performance constrained devices.
Since I work in that industry I shared my experience.

I am uncertain how changing the name help us solve such an underlying problem. 
Maybe it was meant to be a joke.

Ciao
Hannes


From: Rob Sayre 
Sent: Wednesday, September 30, 2020 10:20 AM
To: Hannes Tschofenig 
Cc: Watson Ladd ; Blumenthal, Uri - 0553 - MITLL 
; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Wed, Sep 30, 2020 at 12:32 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi Watson,

through Arm I deal with customers who use microcontrollers that have all sorts 
of limitations.

One way to solve this is to name it something other than "TLS", even if it 
shares some code and/or ideas.

thanks,
Rob
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Uri,

I would even argue that key management is less challenging for IoT deployments 
because devices typically talk to a single device management server only.
So, the communication patterns are pretty simplistic compared to a generic 
computing device.
RFC 7452 talks about this topic (see the device-to-cloud and device-to-gateway 
pattern).

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Wednesday, September 30, 2020 2:48 AM
To: Watson Ladd 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Because PSK is one of the affordable and reliable quantum-resistant key 
exchanges that work *today*? And done environments do not wish to do any EC 
operations.

Yes, key management issues are real. Those who need it, understand the 
implications.

Regards,
Uri

> On Sep 29, 2020, at 20:30, Watson Ladd  wrote:
>
> On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL
>  wrote:
>>
>> I share Achim's concerns.
>>
>> But I believe the explanations will turn out mostly useless in the real 
>> world, as the "lawyers" of the industry are guaranteed to steer away from 
>> something "not recommended".
>>
>> In one word: bad.
>
> Why is PSK so necessary? There are very few devices that can't handle
> the occasional ECC operation.  The key management and forward secrecy
> issues with TLS-PSK are real. Steering applications that can afford
> the CPU away from PSK and toward hybrid modes is a good thing and why
> this registry exists imho.
>
>
> --
> Astra mortemque praestare gradatim
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Watson,

through Arm I deal with customers who use microcontrollers that have all sorts 
of limitations. So, the question is not so much whether these limitations exist 
but rather whether you care and what exactly these limitations are (CPU 
processing, RAM, flash memory, energy, networking bandwidth, cost, physical 
size limitations, limitations caused by the environment these devices operate 
in, etc.).

PSK is the most efficient mechanism we have. Not only does it perform extremely 
well when it comes to CPU performance it also reduces the size of code size, 
and RAM utilization. Also the bandwidth requirements are minimal.
Of course, regular 32-bit microcontrollers are all able to do public key crypto 
operations (see a presentation I did a while ago in the LWIG group -- 
https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf). There are, 
however, some environments where you just cannot wait multiple seconds for a 
handshake to complete.

In discussions in the IETF I notice for some the IoT computing world starts 
with Cortex A-class devices, as they are found in Raspberry Pis, tablets and 
phones. Those are high performance processors where crypto is lightning fast. 
But don't forget the other family of processors, of which there are probably 
more than a 80 billion out in the wild already.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Watson Ladd
Sent: Wednesday, September 30, 2020 2:29 AM
To: Blumenthal, Uri - 0553 - MITLL 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

On Tue, Sep 29, 2020 at 12:49 PM Blumenthal, Uri - 0553 - MITLL 
 wrote:
>
> I share Achim's concerns.
>
> But I believe the explanations will turn out mostly useless in the real 
> world, as the "lawyers" of the industry are guaranteed to steer away from 
> something "not recommended".
>
> In one word: bad.

Why is PSK so necessary? There are very few devices that can't handle the 
occasional ECC operation.  The key management and forward secrecy issues with 
TLS-PSK are real. Steering applications that can afford the CPU away from PSK 
and toward hybrid modes is a good thing and why this registry exists imho.


--
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] TLS 1.3 Problem?

[Hannes Tschofenig]

Hi Mike,

> I felt that I was unwelcome in this group by some of the "angry 
> cryptographers" as I call them.

No reason to worry. Luckily, we don't have any angry cryptographers in this 
group.

On top of what Richard mentioned in his response, take a look at Appendix D of 
the spec, see https://tools.ietf.org/html/rfc8446#appendix-D.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Michael D'Errico
Sent: Sunday, September 27, 2020 9:52 PM
To: tls@ietf.org
Subject: [TLS] TLS 1.3 Problem?

Hi,

Took a quick look at RFC 8446 and noticed that there is no definition of 
ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior.  A 
1.3 client talking to a 1.2 or earlier server is likely going to receive both 
of these
messages:

RFC 5246  TLSAugust 2008

   Client   Server

   ClientHello  >
   ServerHello
  Certificate*
ServerKeyExchange*
   CertificateRequest*
<  ServerHelloDone
   Certificate*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished >
[ChangeCipherSpec]
< Finished
   Application Data <---> Application Data

  Figure 1.  Message flow for a full handshake

Since RFC 8446 obsoletes RFC 5246, this is a serious problem.

How is this supposed to work?   Sorry but I did not follow the development of 
TLS 1.3.  I felt that I was unwelcome in this group by some of the "angry 
cryptographers" as I call them.

Mike

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Nicely said, Peter.

To add: this is also the reason why the UTA group has been working on two sets 
of documents to capture profiles for the web (+email+IM) and IoT:
1) RFC 7590 and now draft-ietf-uta-tls13-iot-profile-00
2) RFC 7525 and now draft-sheffer-uta-rfc7525bis

-Original Message-
From: Peter Gutmann 
Sent: Thursday, September 24, 2020 12:02 PM
To: Filippo Valsorda ; Hannes Tschofenig 
; Carrick Bartle 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Filippo Valsorda  writes:

>The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls
>or NSS or Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards

How do you know that?  I don't know of any data supporting that (I'd love to 
see it if you've got it, non-web use of TLS is the submerged part of the 
iceberg).  Taking "SCADA/IoT/etc" to be a placeholder for M2M or more generally 
"non-web use", an awful lot of TLS gets done outside the web, which uses it it 
completely different ways than web users do.  For example pretty much all of 
the fancy features in TLS 1.3, both in the core protocol and the endless 
add-ons, have no purpose or function in M2M communications.  So perhaps the 
answer is to have two sets of requirements, one for web use, one for everything 
else.  If you try for a one-size-fits-all approach you'll either get the 
currently widespread "TLS == the web" or have to include two mostly 
nonintersecting sets of options to cover web vs. M2M use.

Peter.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi David,

my problem is that the IANA registry only says “not recommended” but it does 
not say for what environments these ciphersuites are not recommended. Worse, it 
also wants to indicate whether the specification has gone through the IETF 
process.

Ciao
Hannes

From: David Benjamin 
Sent: Wednesday, September 23, 2020 5:47 PM
To: Salz, Rich 
Cc: Hannes Tschofenig ; Filippo Valsorda 
; Carrick Bartle ; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

There are two different code points involved in TLS 1.3 PSK, and I think there 
may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication method. 
psk_ke and psk_dhe_ke use the same PSKs. The difference is whether the 
handshake mixes an additional (EC)DH exchange into the key schedule. We've 
already marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it seems to me 
psk_ke with an external PSK should be similar. Handshakes using psk_ke with an 
external PSK incorporate no secrets in the key exchange apart from a (often 
long-lived) external symmetric secret. Compromise that secret, and all traffic 
ever authenticated with that PSK is compromised. Resumption PSKs use 
short-lived keys, so psk_ke is less immediately disastrous but given the 
equivalent construction in TLS 1.2 has forward secrecy 
issues<https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it 
as N across the board seems a good idea to me. (BoringSSL does not implement 
psk_ke for this reason. Looks like Go and NSS do not implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so I 
don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Filippo,

I worry that labelling ciphersuites that is deployed in parts of the industry 
as “not recommended” will confuse those who look at the IANA website.

Only those readers who look at the note will then learn that not recommended 
means three things, whereby the option "has not been through the IETF consensus 
process" should not give readers great confidence either.

I hope this explains my concern.

There is no problem with the use of these PSK ciphersuites, so why mark them as 
“not recommended”?

Ciao
Hannes

From: Filippo Valsorda 
Sent: Wednesday, September 23, 2020 3:39 PM
To: Hannes Tschofenig ; Carrick Bartle 

Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>:

Hi Carrick,



you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.



I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.



For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.


I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

(Again, no one is suggesting dropping anything, as far as I can tell.)


Ciao

Hannes


From: Carrick Bartle mailto:cbartle...@icloud.com>>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Carrick Bartle 
mailto:cbartle891=40icloud@dmarc.ietf.org>>;
 Filippo Valsorda mailto:fili...@ml.filippo.io>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3



Can you justify your reasoning?



Which part?




On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:



Hi Carrick,



Can you justify your reasoning?



The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.



I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.



Ciao

Hannes


From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3



I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.







On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:



2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:

John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:



>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and

>especially psk_ke are both marked as RECOMMENDED. If used in the initial

>handshake, both modes have severe privacy problems,



PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

just because there's a concern for one specific environment doesn't mean it

should be banned for any use.  In particular, I think if a specific industry

has a particular concern, they should profile it for use in that industry but

not require that everyone else change their behaviour.



Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Interne

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Carrick,

you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.

I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.

For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

Ciao
Hannes

From: Carrick Bartle 
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
Cc: Carrick Bartle ; Filippo Valsorda 
; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Can you justify your reasoning?

Which part?



On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.

I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:
John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.
___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you. ___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Pascal,

are you saying that the stack on the secure element uses WolfSSL or OpenSSL? I 
am sure that WolfSSL works well but for code size reasons I doubt OpenSSL is 
possible. Can you confirm?

In case of WolfSSL, you have multiple options for credentials, including plain 
PSK, PSK-ECDHE, raw public keys, and certificates as I noted in my mail to the 
UTA list:
https://mailarchive.ietf.org/arch/msg/uta/RJ4wU77D6f7qslfwrc16jkrPTew/

Ciao
Hannes

From: Pascal Urien 
Sent: Monday, September 21, 2020 2:01 PM
To: Hannes Tschofenig 
Cc: Filippo Valsorda ; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Hi Hannes

Yes it has been tested with several  3.04 Javacards  commercially available

In the draft https://tools.ietf.org/html/draft-urien-tls-se-00   Section 5-ISO 
7816 Use Case, the exchanges are done with the existing implementation

TLS-SE TLS1.3 PSK+ECDH server works with ESP8266 or Arduino+Ethernet boards

For client software we use OPENSSL or WolfSSL

Pascal




Le lun. 21 sept. 2020 à 12:35, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> a écrit :
Hi Pascal,

Thanks for the pointer to the draft.

Since I am surveying implementations for the update of RFC 7925 (see 
https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was 
wondering whether there is an implementation of this approach.

Ciao
Hannes


From: Pascal Urien mailto:pascal.ur...@gmail.com>>
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Filippo Valsorda mailto:fili...@ml.filippo.io>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Hi All

Here is an example of PSK+ECDHE for IoT

https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server  
PSK+ECDHE for secure elements

The security level in these devices is as high as EAL5+

The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, + 
secp256r1)

The real critical resource is the required RAM size, less than 1KB in our 
experiments

The secure element  only needs a classical TCP/IP interface (i.e. sockets like)

Trusted PSK should avoid selfie attacks

Pascal



Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> a écrit :
Hi Filippo,

• Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

We have an IoT profile for TLS and it talks about the use of PSK, see 
https://tools.ietf.org/html/rfc7925

On the “open Internet” (probably referring to the Web usage) you are not going 
to use PSKs in TLS. There is a separate RFC that provides recommendations for 
that environmnent, see RFC 752. That RFC is currently being revised, see 
https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
mailto:TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Pascal,

Thanks for the pointer to the draft.

Since I am surveying implementations for the update of RFC 7925 (see 
https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/) I was 
wondering whether there is an implementation of this approach.

Ciao
Hannes


From: Pascal Urien 
Sent: Monday, September 21, 2020 11:44 AM
To: Hannes Tschofenig 
Cc: Filippo Valsorda ; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Hi All

Here is an example of PSK+ECDHE for IoT

https://tools.ietf.org/html/draft-urien-tls-se-00  uses TLS1.3 server  
PSK+ECDHE for secure elements

The security level in these devices is as high as EAL5+

The computing time is about 1.4s for a PSK+ECDHE session (AES-128-CCM, + 
secp256r1)

The real critical resource is the required RAM size, less than 1KB in our 
experiments

The secure element  only needs a classical TCP/IP interface (i.e. sockets like)

Trusted PSK should avoid selfie attacks

Pascal



Le lun. 21 sept. 2020 à 11:29, Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com> a écrit :
Hi Filippo,

• Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

We have an IoT profile for TLS and it talks about the use of PSK, see 
https://tools.ietf.org/html/rfc7925

On the “open Internet” (probably referring to the Web usage) you are not going 
to use PSKs in TLS. There is a separate RFC that provides recommendations for 
that environmnent, see RFC 752. That RFC is currently being revised, see 
https://datatracker.ietf.org/doc/draft-sheffer-uta-rfc7525bis/

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
mailto:TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Filippo,


  *   Indeed, if the SCADA industry has a particular need, they should profile 
TLS for use in that industry, and not require we change the recommendation for 
the open Internet.

We have an IoT profile for TLS and it talks about the use of PSK, see 
https://tools.ietf.org/html/rfc7925

On the "open Internet" (probably referring to the Web usage) you are not going 
to use PSKs in TLS. There is a separate RFC that provides recommendations for 
that environmnent, see RFC 752. That RFC is currently being revised, see 
draft-sheffer-uta-rfc7525bis-00

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.

I don't see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS  On Behalf Of Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda 
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:
John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

John,

The use of plain PSK makes a lot of sense because it provides the lowest 
footprint solution for really constrained systems. Given that the LAKE group 
wanted to focus on constrained IoT devices makes the decision by the group 
questionable.

As you know, TLS 1.3 merged the handling of PSKs previously found in three 
different RFCs, namely session resumption, ciphersuites with PSK, and session 
resumption without server-side state into one solution. As such, there is not 
even extra cost associated with external PSKs.

I have been arguing that a solution that uses PSKs with ECDHE, as you proposed 
in RFC 8442, is less useful because very constrained are not going to use the 
asymmetric crypto needed for the ECDHE. Those deployments could instead go 
directly to a raw public key solution instead.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of John Mattsson
Sent: Saturday, September 19, 2020 1:30 PM
To: TLS@ietf.org
Subject: [TLS] The future of external PSK in TLS 1.3

Hi,

Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric keys for 
authentication and key exchange made me think about the future role of external 
PSK in TLS.

https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/

I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy systems. 
Due to the major privacy, security, and deployment limitations with PSK, I see 
little need to use PSK (besides resumption) in new systems, except for the use 
case in RFC 8773.

LAKE recently removed PSK authentication completely as it does not produce 
smaller messages and comes with severe privacy and deployments problems. 
Increasing code size (a few kB) and slightly increased computation/latency was 
not seen as a big problems.

Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and 
especially psk_ke are both marked as RECOMMENDED. If used in the initial 
handshake, both modes have severe privacy problems, and psk_ke does not give 
PFS, thus making pervasive monitoring much easier. If groups keys are used, 
additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE 
has for good reasons been marked as NOT RECOMMENDED.

I have recently seen several people arguing that the inclusion of PSK in TLS 
1.3 means that the use external PSKs are now recommended. I don't think that 
was the intension of the TLS WG.

I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. 
Irrespectively of what ‘Y’ in the recommended column actually means, people are 
and will read it as recommended to use.

Cheers,
John

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-ietf-tls-ticketrequests-05

[Hannes Tschofenig]

Hi Ilari,

Please see my comments below.

-Original Message-
From: ilariliusva...@welho.com 
Sent: Wednesday, July 1, 2020 8:49 PM
To: Hannes Tschofenig 
Cc:  
Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05

On Wed, Jul 01, 2020 at 04:52:18PM +, Hannes Tschofenig wrote:
> Hi Tommy, Hi David, Hi Chris,
>
> I read through the draft and have a few questions.
>
> 1) Is it really necessary for the client to use two values to
> differentiate the tickets it wants with a new session and with
> resumption. It feels a bit over-designed. I would just have one value
> and that alone would be super useful already.

Consider a client that does:

- Parallel connections
- Does not reuse tickets

Such client needs enough tickets to cover the multiple connections in case of 
fresh handshake (might be 5-10 or so), but only needs to replace the tickets 
for current connection (1 or 2) in case of resumption. So any single value will 
result in oversupply or undersupply.

[Hannes] The client is probably in the best position to know how many tickets 
it wants. I don't see the case where it is necessary to distinguish two types 
of tickets with this extension. I want this to be as simple as possible.

> 2) This sentence confuses me:
> "
>Servers SHOULD NOT send more tickets than requested for the handshake
>type selected by the server (resumption or full handshake).
>Moreover, servers SHOULD place a limit on the number of tickets they
>are willing to send, whether for full handshakes or resumptions, to
>save resources.
> "
>
> Shouldn't the sentence say:
> "
>Servers SHOULD NOT send more tickets than requested for the handshake
>type (resumption or full handshake) indicated by the client.
> "

The server might not want to actually honor request to send 255 tickets.
Even if ticket minting is a fast operation, 255 of them might take non- trivial 
time (and bandwidth).

[Hannes] I was trying to point out that there appears to be a bug in the 
sentence.
(at least that's my understanding as a non-English native speaker)

> Even then, I believe the sentence should actually say MUST NOT instead
> of SHOULD NOT. If the client is already taking the effort to indicate
> that it does not want more than a certain number of tickets then it
> might have a reason. I am thinking about the case where the client
> indicates that it does not want any tickets then it would be strange
> for the server expressing support for the extension and still send
> tickets.

If the client signals 0 tickets for handshake and 0 tickets for resumption, 
then reasonable interpretation is that client does not support resumption at 
all, and it is waste of resources to send it any tickets.

[Hannes] Correct. This is what I am saying. Currently the text allows the 
server to still send a ticket even though the client says "don't send it".

But how should server interpret client saying it wants 1 ticket for full 
handshake and 0 tickets for resumption? A reasonable interpretation is that 
client does support tickets and is is willing to reuse tickets.
So if the server is not willing to reuse tickets, the most reasonable action is 
to send 1 ticket to the client on resumption (if server is willing to reuse 
tickets, the most reasonable act is not send any tickets on resumption).

[Hannes] If the client says it only wants one ticket then he should only get 
one ticket. If it wants another ticket when it resumes the session then the 
client can ask for another ticket.

Basically, there can be good reasons to send more tickets than requested. Just 
that most of the time, sending more tickets will lead to oversupply.

[Hannes] It would be good to decide who makes the decisions in this process. If 
we want to give the client the possibility to indicate how much it wants to 
receive and you can still give the server the ability to send less. Currently, 
the authors did not decide what they want.

> 4) I believe it would make sense to define a ticket flag for the case
> where the client does not want to receive any tickets.

The sensible way to indicate that is to send (0,0) as requested ticket count.

[Hannes] I am suggesting to use the newly defined flags extension draft (see 
https://tools.ietf.org/html/draft-ietf-tls-tlsflags-02) for this purpose.


> 5) If a client sends the ClientTicketRequest extension during the full
> handshake is there an expectation that it sends it again in the
> resumption exchange? Would you assume that the server memorizes how
> many tickets the client wanted across the resumption handshakes?
> For example, in the full handshake I use the extension and indicate
> that I want 5 tickets. I get two tickets from the server. Then, I run
> a resumption handshake without transmitting the extension. Is the
> server expected to remember to still send

Re: [TLS] Proposed change in TLS-Flags

[Hannes Tschofenig]

Hi Yoav,

> If that’s something the group wants, we can add it, but it’s not generally a 
> good thing for a protocol to have two ways of expressing the same thing.
I saw it more as a "compression" mechanism for those cases where an extension 
doesn't carry additional content.

Ciao
Hannes

Yoav

> On 1 Jul 2020, at 19:00, Hannes Tschofenig  wrote:
>
> One question: Wouldn’t you want to register a flag for "Post-Handshake Client 
> Authentication" in this document?
>
> Ciao
> Hannes
>
>
> From: TLS  On Behalf Of Hannes Tschofenig
> Sent: Wednesday, July 1, 2020 5:55 PM
> To: Yoav Nir ;  
> Subject: Re: [TLS] Proposed change in TLS-Flags
>
> Yoav,
>
> I looked at the draft and the PR. I am fine with the proposed changes.
> This is a short and useful draft.
>
> Ciao
> Hannes
>
> From: TLS  On Behalf Of Yoav Nir
> Sent: Monday, June 29, 2020 11:34 PM
> To:  
> Subject: [TLS] Proposed change in TLS-Flags
>
> Hi
>
> I’ve just submitted the following PR:
>
> https://github.com/tlswg/tls-flags/pull/4
>
> Three changes:
> • It is no longer allowed to send an empty flags extension.  If you don’t 
> support any flags, don’t send the extension.
> • The server is no longer allowed to respond with flag types that the client 
> didn’t indicate support for first.
> • I’ve split the extension description section into a format section and a 
> rules section
>
> Please comment. Barring any objections, I’ll merge the PR just before the 
> submission deadline.
>
> Yoav
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-ietf-tls-ticketrequests-05

[Hannes Tschofenig]

Hi Tommy, Hi David, Hi Chris,

I read through the draft and have a few questions.

1) Is it really necessary for the client to use two values to differentiate the 
tickets it wants with a new session and with resumption. It feels a bit 
over-designed. I would just have one value and that alone would be super useful 
already.

2) This sentence confuses me:
"
   Servers SHOULD NOT send more tickets than requested for the handshake
   type selected by the server (resumption or full handshake).
   Moreover, servers SHOULD place a limit on the number of tickets they
   are willing to send, whether for full handshakes or resumptions, to
   save resources.
"

Shouldn't the sentence say:
"
   Servers SHOULD NOT send more tickets than requested for the handshake
   type (resumption or full handshake) indicated by the client.
"

Even then, I believe the sentence should actually say MUST NOT instead of 
SHOULD NOT. If the client is already taking the effort to indicate that it does 
not want more than a certain number of tickets then it might have a reason. I 
am thinking about the case where the client indicates that it does not want any 
tickets then it would be strange for the server expressing support for the 
extension and still send tickets.

3) Does the server really need to send the number of tickets it is planning to 
send back to the client? In the draft you already indicate that the server may 
send fewer tickets than requested by the client. So, the number expressed by 
the client is an upper limit anyway.

4) I believe it would make sense to define a ticket flag for the case where the 
client does not want to receive any tickets.

5) If a client sends the ClientTicketRequest extension during the full 
handshake is there an expectation that it sends it again in the resumption 
exchange? Would you assume that the server memorizes how many tickets the 
client wanted across the resumption handshakes? For example, in the full 
handshake I use the extension and indicate that I want 5 tickets. I get two 
tickets from the server. Then, I run a resumption handshake without 
transmitting the extension. Is the server expected to remember to still send 3 
more tickets till the quota is exhausted?

6) The topic of when to send the tickets is something you mention in the 
document and it is indeed an issue. Have you thought about allowing the client 
to signal to the server when to send the tickets? Even making a distinction 
between "send me all tickets in a batch" and "send one after the other with 
some reasonable time in between" would be helpful.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] Proposed change in TLS-Flags

[Hannes Tschofenig]

One question: Wouldn’t you want to register a flag for "Post-Handshake Client 
Authentication" in this document?

Ciao
Hannes


From: TLS  On Behalf Of Hannes Tschofenig
Sent: Wednesday, July 1, 2020 5:55 PM
To: Yoav Nir ;  
Subject: Re: [TLS] Proposed change in TLS-Flags

Yoav,

I looked at the draft and the PR. I am fine with the proposed changes.
This is a short and useful draft.

Ciao
Hannes

From: TLS  On Behalf Of Yoav Nir
Sent: Monday, June 29, 2020 11:34 PM
To:  
Subject: [TLS] Proposed change in TLS-Flags

Hi

I’ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:
• It is no longer allowed to send an empty flags extension.  If you don’t 
support any flags, don’t send the extension.
• The server is no longer allowed to respond with flag types that the client 
didn’t indicate support for first.
• I’ve split the extension description section into a format section and a 
rules section

Please comment. Barring any objections, I’ll merge the PR just before the 
submission deadline.

Yoav

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed change in TLS-Flags

[Hannes Tschofenig]

Yoav,

I looked at the draft and the PR. I am fine with the proposed changes.
This is a short and useful draft.

Ciao
Hannes

From: TLS  On Behalf Of Yoav Nir
Sent: Monday, June 29, 2020 11:34 PM
To:  
Subject: [TLS] Proposed change in TLS-Flags

Hi

I’ve just submitted the following PR:

https://github.com/tlswg/tls-flags/pull/4

Three changes:

  *   It is no longer allowed to send an empty flags extension.  If you don’t 
support any flags, don’t send the extension.
  *   The server is no longer allowed to respond with flag types that the 
client didn’t indicate support for first.
  *   I’ve split the extension description section into a format section and a 
rules section

Please comment. Barring any objections, I’ll merge the PR just before the 
submission deadline.

Yoav

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Hannes Tschofenig]

Hi Joe, Hi draft authors,

I reviewed draft-ietf-tls-subcerts-09 and the document is well written and easy 
to understand.

I have only a minor remark regarding the validity time of the delegated 
credential.

In Section 3 you say
"
   In
   the absence of an application profile standard specifying otherwise,
   the maximum validity period is set to 7 days.  Peers MUST NOT issue
   credentials with a validity period longer than the maximum validity
   period.
"

In Section 4 you say the following about the validity time. "This MUST NOT 
exceed 7 days."

I wonder whether it makes sense to just copy the text from Section 3 to Section 
4 have it read the same way.
Having the flexibility to extend this maximum validity time via profiles may 
turn out to be useful, as Section 3 already states.

The use of a new X.509 extension is unfortunate because tools used for creating 
certificates are somewhat behind supporting various extensions.
We ran into this issue for use with device certificates in IoT deployments.

I guess there is nothing to do about this other than trying to add support of 
this extension in popular tools.
Any plans to add support for this extension to the OpenSSL command line tool to 
create certificates?

Ciao
Hannes

From: TLS  On Behalf Of Joseph Salowey
Sent: Monday, June 29, 2020 5:59 PM
To:  
Subject: [TLS] 2nd WGLC for Delegated Credentials for TLS

This is the second working group last call for Delegated Credentials for TLS.  
The latest draft can be found here: 
https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.  There have been 2 
revisions since the last review.  Draft 8 contains changes that were not 
committed in time for draft 7 and draft 9 contains revisions from the previous 
WGLC.  Links to the Diffs between the draft 9 and draft 7 can be found at the 
end of this message.   Please focus your review on the changes between draft 7 
and draft 9.  Please send your comments to the list by July 13, 2020.

Thanks,

Sean and Joe

[Inline Diff] 
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-tls-subcerts-09.txt=draft-ietf-tls-subcerts-07.txt
[Side-by-side Diff] 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt=draft-ietf-tls-subcerts-07.txt

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Banning implicit CIDs in DTLS

[Hannes Tschofenig]

I also agree. Even without implicit CIDs we can still put multiple handshake 
messages into a single record. Hence, there is no performance problem.

From: TLS  On Behalf Of Richard Barnes
Sent: Thursday, May 28, 2020 3:37 PM
To: Christopher Wood 
Cc: TLS@ietf.org
Subject: Re: [TLS] Banning implicit CIDs in DTLS

I agree with EKR that this seems like the most expedient solution to the issue.

--Richard

On Thu, May 21, 2020 at 12:00 PM Christopher Wood 
mailto:c...@heapingbits.net>> wrote:
PR #148 in the DTLS 1.3 draft (https://github.com/tlswg/dtls13-spec/pull/148) 
proposes banning implicit CIDs. This comes at an obvious cost in terms of bytes 
on the wire. However, in discussions on a parallel thread [1 and related], it's 
noted that this removes header malleability.

Given that we don't have backing analysis suggesting that malleability (with 
the other AAD properties) is safe*, the chairs propose merging this PR as-is. 
To that end, please respond to the list by May 28, 2020, indicating whether or 
not you support this PR.

Thanks,
Chris, on behalf of the chairs

*One proposal to address this is by extending the AAD to include the 
pseudo-header. However, the chairs feel this is an unnecessary divergence from 
QUIC.

[1] https://mailarchive.ietf.org/arch/msg/tls/kFnlBW-TmlArcU0lD9UQdf_1t_o/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] consensus call: changing cTLS and ECH to standards track

[Hannes Tschofenig]

I have started working on the cTLS implementation and will continue doing so 
together with my co-worker Hanno.

A bit more details:

We have re-based the 1.3 implementation* to the development branch of Mbed TLS 
and we have refactored the code so that we can put a new messaging layer in 
place**, which contains formal annotations. Besides the cleaner separation of 
the handshake layer and the underlying message transmission and record layer 
handling the refactoring also allows us now to test each handshake message 
individually. This was not possible previously and one instead had to run 
through the entire handshake to test a specific message pattern. The new code 
has made it easier to add the cTLS functionality as well, which is what we are 
doing right now. Once we are done with the development, the rest of the Mbed 
TLS team will review the code.

In a nutshell, a bigger restructuring of the codebase and we do the cTLS 
alongside as well.

Ciao
Hannes

*: For the moment we put the code here: 
https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype. The plan is 
to merge it into the mainstream Mbed TLS repo once it is ready.

**: The new messaging layer, called MPS for "Message Processing Stack", can be 
found here: https://github.com/hanno-arm/mbedtls/tree/mps_implementation. The 
plan is to incorporate it into 
https://github.com/hannestschofenig/mbedtls/tree/tls13-prototype.

From: TLS  On Behalf Of Eric Rescorla
Sent: Friday, May 22, 2020 3:27 PM
To: Salz, Rich 
Cc: TLS List 
Subject: Re: [TLS] consensus call: changing cTLS and ECH to standards track

We have already implemented ECH (old versions) for NSS and are eager to deploy 
it in Firefox.

We are likely to implement cTLS.

-Ekr


On Fri, May 22, 2020 at 6:20 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I am reluctant to make CTLS standards-track without a statement from someone 
that they are likely to implement it.  We already have such a statement from 
Stephen about OpenSSL for ECH, and I'll add to that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Choice of Additional Data Computation

[Hannes Tschofenig]

Hi Ekr,


  *   And I am proposing removing implicit CIDs

That would be a bit unfortunate. When we put multiple DTLS records in a single 
UDP datagram then the CID in all but the first datagram is redundant*.

Ciao
Hannes

(*): Even if we optimize the CID away with cTLS the question about the security 
implications will surface again.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Choice of Additional Data Computation

[Hannes Tschofenig]

Hi Achim,

My point is that we made decisions based on the best of our knowledge (and 
personal preferences) but I am wondering whether formal methods can tell us 
whether there is a preferred way.

Ciao
Hannes

-Original Message-
From: Achim Kraus 
Sent: Friday, April 24, 2020 3:07 PM
To: Hannes Tschofenig ; tls@ietf.org
Subject: Re: [TLS] Choice of Additional Data Computation

Hi Hannes,
Hi list,

as input for the discussion:

https://github.com/tlswg/dtls-conn-id/issues/25

A longer "comment-flow", the conclusion was, the CID is on the wire, so it's in 
the MAC.
(ekr: "authenticating the whole header is just good practice.")

My arguments was, that the CID is always included in the MAC, either explicit, 
or implicit (implicit, because the CID selects the "mac-keys"
or "cipher-keys" and gets included equal to the address:port before).

best regards
Achim

Am 24.04.20 um 13:04 schrieb Hannes Tschofenig:
> Hi all,
>
> the thread on the AEAD commutation in DTLS 1.3 and the construction of
> the additional data raised two interesting questions. I believe those
> would benefit from a formal analysis or at least a security investigation.
>
> Here are the questions:
>
>  1. Generic question: Should the construction of the additional data be
> dependent on what is transmitted over the wire or should it be based
> on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the
> data transmitted over the wire in the additional data calculation.
>  2. Specific question: Should the CID be included in the additional data
> calculation, particularly for the case where it is only implicitly
> sent? Asked differently, are there attacks possible?
>
> Your feedback would be appreciated to advance the discussion. I
> believe there is a chance to provide generic guidance for security
> protocol designers here.
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[TLS] Choice of Additional Data Computation

[Hannes Tschofenig]

Hi all,

the thread on the AEAD commutation in DTLS 1.3 and the construction of the 
additional data raised two interesting questions. I believe those would benefit 
from a formal analysis or at least a security investigation.

Here are the questions:


  1.  Generic question: Should the construction of the additional data be 
dependent on what is transmitted over the wire or should it be based on a 
"pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the data 
transmitted over the wire in the additional data calculation.
  2.  Specific question: Should the CID be included in the additional data 
calculation, particularly for the case where it is only implicitly sent? Asked 
differently, are there attacks possible?

Your feedback would be appreciated to advance the discussion. I believe there 
is a chance to provide generic guidance for security protocol designers here.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data

[Hannes Tschofenig]

Hi Martin,

I have a few questions regarding the attack you mentioned below.
I would like to understand whether it relates to the topic of how the 
additional data is constructed and what is included.

> Say that a connection spans two network paths.  CID A is used on path A; CID 
> B is used on path B.
I guess you are considering a scenario where a device, of the lifetime of the 
communication with another peer, changes from CID A to CID B.
Is this correct?

> Let's assume that you need a connection ID to route (otherwise, why bother), 
> but that the first record in each datagram is all that is needed for that 
> purpose.
What do you mean by "route" here? The CID was primarily introduced to allow the 
receiving party to correctly find the correct security context to verify and 
decrypt the packet.

> If an endpoint sends a datagram on path A that contains two records where the 
> second record omits the connection ID, then an attacker can strip that second 
> record out and copy it into a datagram sent on path B.  With the current 
> design, the receiver accepts that packet and maybe leaks some signal to the 
> attacker that CID A and CID B really are the same connection.

If you copy the record that does not contain the CID and send it to the peer 
independently then with the current text in the spec the packet will be dropped.


Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of Martin Thomson
Sent: Thursday, April 23, 2020 1:54 AM
To: tls@ietf.org
Subject: Re: [TLS] DTLS 1.3 AEAD additional data

I prefer Ekr's solution, but I would go with that being a recommendation 
(SHOULD) as opposed to a requirement (MUST).

I was initially inclined toward doing nothing at all, but there is an attack of 
sorts that is worth avoiding here.

Say that a connection spans two network paths.  CID A is used on path A; CID B 
is used on path B.  Let's assume that you need a connection ID to route 
(otherwise, why bother), but that the first record in each datagram is all that 
is needed for that purpose.

The linkabliity confirmation attack allows an attacker that hypothesizes a 
correlation between CID A and CID Bto confirm that hypothesis.  It relies on 
side channel leakage from endpoints, but as this only involves measuring 
application reactions, I'm going to assume that it is feasible to extract some 
signal.

If an endpoint sends a datagram on path A that contains two records where the 
second record omits the connection ID, then an attacker can strip that second 
record out and copy it into a datagram sent on path B.  With the current 
design, the receiver accepts that packet and maybe leaks some signal to the 
attacker that CID A and CID B really are the same connection.  With Hanno's 
proposed fix, the receiver of that record will guess incorrectly that the 
datagram is bad and drop it, providing no signal about the relationship between 
the two CIDs.

But Hanno's proposal is a terrible thing to have to implement.  You have to 
assume that there is some way to recover which CID to use in decrypting any 
record.  You might save some datagram-local state, but that's awkward.  Stacks 
that I've worked on try very hard not to have state transmission between 
records for good reasons.  So this would be a fairly bad complication.  
Separately, I hope that no one would be contemplating trial decryption for 
this, which would be terrible.

So I'm inclined toward cautioning against omitting the connection ID when one 
is used.

DTLS 1.3 already has fairly lightweight requirements around how linkability is 
avoided.  Activity on new paths does not strictly require the use of a 
different CID, it's just a recommendation. Allowing endpoints to omit a CID is 
consistent with that, even if we don't recommend that.  However, we do need to 
be careful to explain this risk so that people are aware of the consequences of 
omission.

I would also point out that we attempt to avoid creating correlators so that 
attackers can't create hypotheses about linkability.  Allowing confirmation of 
a hypothesis is not that bad when the existence of the hypothesis is itself 
what we are trying to avoid.  Given the relative cost of performing this attack 
to other means of confirming the hypothesis - dropping packets and observing 
the response would be much easier in many cases - I don't think that this 
warrants a strong response.

Cheers,
Martin

On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote:
>  Hi Ekr,
>
>  I still don't yet understand which concrete problems you see with the
> proposed solution. In particular, as mentioned in the last mail, I
> don't think there is a contradiction with any design choice for TLS
> 1.3 - in contrast, decoupling record header compression from record
> protection aligns with how cTLS proposes to compress TLS 1.3 without
> affecting any cryptographic computations and hence hopefully easing
> carrying over the security analysis of TLS 1.3. This decoupling
> doesn't hold for the current 

Re: [TLS] Efficiency of ACKing scheme

[Hannes Tschofenig]

Hi Thomas, Hi Ekr,

It seems we need to fix Figure 11 of Section 7.1 of
https://www.ietf.org/id/draft-ietf-tls-dtls13-37.html
(ACK[1] should actually be ACK[])

It should follow the “empty ACK” description of the last paragraph of the same 
section.

Good catch!

Ciao
Hannes

From: TLS  On Behalf Of Eric Rescorla
Sent: Thursday, April 9, 2020 4:33 PM
To: Thomas Fossati 
Cc: tls@ietf.org
Subject: Re: [TLS] Efficiency of ACKing scheme



On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati 
mailto:thomas.foss...@arm.com>> wrote:
On 09/04/2020, 15:18, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:
> > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati 
> > mailto:thomas.foss...@arm.com>> wrote:
> > On 09/04/2020, 14:20, "Eric Rescorla" mailto:e...@rtfm.com>> 
> > wrote:
> > > Assuming I understand Hanno's proposal, I do not believe that this
> > > is in fact an improvement, as it does not cover the important case
> > > where the record containing the SH is lost and then the rest of
> > > the messages from the server are uninterpretable.
> >
> > I don't want to speak for Hanno here but the refinement proposed in
> > [1], specifically the bit that says:
> >
> >   [...] They may also proactively retransmit parts of a flight early
> >   if an ACK message indicates a gap.
> >
> > should cover the case you mention I think.
>
> But this requires being able to send an empty ACK that means "I got
> nothing". In which case, I don't see how it's really different from
> the current text except that it gives the sender less guidance.

Not sure there's an "empty ACK" in Hanno's proposal.  This is how I
interpret it in the context of your example: in the second flight, if
rec#0 (containing SH) is lost and rec#1 gets through, the receiver sends
ACK {1}.  From that the sender can infer the gap and retransmit rec#0.

You can't send ACK{1} because you can't  decrypt it because it is out of order 
with respect to the DH key. This is the point of the empty ACK.

-Ekr



(But again, I'm not him and that's why I suggested collecting all the
pieces of this discussion together in one PR.)

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS

[Hannes Tschofenig]

Thanks for the info, John. I will have a look at this publication.

-Original Message-
From: John Mattsson 
Sent: Wednesday, April 8, 2020 3:14 PM
To: Hannes Tschofenig ; tls@ietf.org; u...@ietf.org
Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates 
suitable for cTLS

Hi Hannes,

I have requested and been assigned time for 
draft-mattsson-tls-cbor-cert-compress-00 and 
draft-raza-ace-cbor-certificates-04 at the UTA virtual interim on March 23.

We have an implementation of 
https://link.springer.com/chapter/10.1007%2F978-3-319-93797-7_14 / 
draft-raza-ace-cbor-certificates-03, but the code is not written in a way so 
that the compression mechanism DER-> CBOR can be extracted. The example in 
draft-raza-ace-cbor-certificates-04 was created by hand with cbor.me. We are 
planning to implement a updated standalone version of the DER->CBOR compression 
and hopefully have interop testing in the COSE WG.

Cheers,
John

-Original Message-
From: TLS  on behalf of Hannes Tschofenig 

Date: Friday, 3 April 2020 at 14:20
To: John Mattsson , "TLS@ietf.org" 
, "u...@ietf.org" 
Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates 
suitable for cTLS

Hi John,

Thanks for the heads-up.

Discussing this aspect in draft-tschofenig-uta-tls13-profile-01 makes sense.

I was wondering whether you have been working on an implementation of 
draft-mattsson-cose-cbor-cert-compress-00 / draft-raza-ace-cbor-certificates-04.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of John Mattsson
Sent: Friday, April 3, 2020 9:03 AM
To: TLS@ietf.org; u...@ietf.org
Subject: [TLS] CBOR Certificate Compression of RFC 7925 certificates 
suitable for cTLS

Hi,

During the COSE virtual interim meeting yesterday, there was agreement that 
the COSE working group should work on CBOR compression of RFC 7925 profiled 
X.509 certificates. The work will be based on draft-raza-ace-cbor-certificates 
and draft-mattsson-cose-cbor-cert-compress and the two drafts will be merged. 
Doing this work in a security group focused on CBOR makes a lot of sense.

https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04

The COSE draft charter has already been updated to reflect this.

https://github.com/cose-wg/Charter/blob/master/Charter.md

As the algorithm is focused on compressing RFC 7925 profiled certificates, 
It seems like a very good match for cTLS. To keep the number of internet-drafts 
down, I plan to also include the TLS IANA registrations in the merged draft 
submitted to the COSE WG and let draft-mattsson-tls-cbor-cert-compress-00 
expire.

Any comments from the TLS WG are very welcome, but otherwise these is not 
so much to discuss, this is just another certificate compression algorithm. Any 
TLS related discussions would likely be regarding the certificate profile in 
RFC 7925 and if any clarifications or updates are needed. This is likely best 
discussed in UTA which may take up work on a TLS/DTLS 1.3 update of RFC 7925.

https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Thursday, 12 March 2020 at 08:58
To: "TLS@ietf.org" 
Cc: "u...@ietf.org" 
Subject: FW: New Version Notification for 
draft-mattsson-tls-cbor-cert-compress-00.txt

Hi,

We have submitted a new draft to TLS 
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 The draft 
register a new compression algorithms for use with TLS Certificate Compression 
in TLS 1.3 and DTLS 1.3 (draft-ietf-tls-certificate-compression).

The draft uses 
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 to compress RFC 
7925 profiles certificates by encoding them from DER to CBOR. The aim is to be 
compatible with all RFC 7925 profiled certificates. With the included example 
DER encoded RFC 7925 certificate to certificate is compressed from 314 to 136 
bytes, a compression rate of 57%.

The general purpose compression algorithms defined in 
draft-ietf-tls-certificate-compression do not seem able to compress profiled 
RFC 7925 X.509 certificates much at all. zlib compressed the example cert 9%, 
but for other certificates we tested, zlib did in many cases not provide any 
compression at all.

We have submitted a similar draft to the COSE WG registering a new 
algorithms for the TLS 1.3 certificate compression extension.

https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00

Cheers,
John

-Original Message-
From: "internet-dra...@ietf.org" 
Date: Monday, 9 March 2020 at 21:19
To: John Mattsson , John Mattsson 
, Joel Höglund , Joel Hoglund 
, Göran Selander , Martin 

Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS

[Hannes Tschofenig]

Hi John,

Thanks for the heads-up.

Discussing this aspect in draft-tschofenig-uta-tls13-profile-01 makes sense.

I was wondering whether you have been working on an implementation of 
draft-mattsson-cose-cbor-cert-compress-00 / draft-raza-ace-cbor-certificates-04.

Ciao
Hannes

-Original Message-
From: TLS  On Behalf Of John Mattsson
Sent: Friday, April 3, 2020 9:03 AM
To: TLS@ietf.org; u...@ietf.org
Subject: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable 
for cTLS

Hi,

During the COSE virtual interim meeting yesterday, there was agreement that the 
COSE working group should work on CBOR compression of RFC 7925 profiled X.509 
certificates. The work will be based on draft-raza-ace-cbor-certificates and 
draft-mattsson-cose-cbor-cert-compress and the two drafts will be merged. Doing 
this work in a security group focused on CBOR makes a lot of sense.

https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04

The COSE draft charter has already been updated to reflect this.

https://github.com/cose-wg/Charter/blob/master/Charter.md

As the algorithm is focused on compressing RFC 7925 profiled certificates, It 
seems like a very good match for cTLS. To keep the number of internet-drafts 
down, I plan to also include the TLS IANA registrations in the merged draft 
submitted to the COSE WG and let draft-mattsson-tls-cbor-cert-compress-00 
expire.

Any comments from the TLS WG are very welcome, but otherwise these is not so 
much to discuss, this is just another certificate compression algorithm. Any 
TLS related discussions would likely be regarding the certificate profile in 
RFC 7925 and if any clarifications or updates are needed. This is likely best 
discussed in UTA which may take up work on a TLS/DTLS 1.3 update of RFC 7925.

https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Thursday, 12 March 2020 at 08:58
To: "TLS@ietf.org" 
Cc: "u...@ietf.org" 
Subject: FW: New Version Notification for 
draft-mattsson-tls-cbor-cert-compress-00.txt

Hi,

We have submitted a new draft to TLS 
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 The draft 
register a new compression algorithms for use with TLS Certificate Compression 
in TLS 1.3 and DTLS 1.3 (draft-ietf-tls-certificate-compression).

The draft uses 
https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 to compress RFC 
7925 profiles certificates by encoding them from DER to CBOR. The aim is to be 
compatible with all RFC 7925 profiled certificates. With the included example 
DER encoded RFC 7925 certificate to certificate is compressed from 314 to 136 
bytes, a compression rate of 57%.

The general purpose compression algorithms defined in 
draft-ietf-tls-certificate-compression do not seem able to compress profiled 
RFC 7925 X.509 certificates much at all. zlib compressed the example cert 9%, 
but for other certificates we tested, zlib did in many cases not provide any 
compression at all.

We have submitted a similar draft to the COSE WG registering a new 
algorithms for the TLS 1.3 certificate compression extension.

https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00

Cheers,
John

-Original Message-
From: "internet-dra...@ietf.org" 
Date: Monday, 9 March 2020 at 21:19
To: John Mattsson , John Mattsson 
, Joel Höglund , Joel Hoglund 
, Göran Selander , Martin 
Furuhed , Göran Selander 
, Shahid Raza 
Subject: New Version Notification for 
draft-mattsson-tls-cbor-cert-compress-00.txt


A new version of I-D, draft-mattsson-tls-cbor-cert-compress-00.txt
has been successfully submitted by John Preuss Mattsson and posted to 
the
IETF repository.

Name:draft-mattsson-tls-cbor-cert-compress
Revision:00
Title:CBOR Certificate Algorithm for TLS Certificate Compression
Document date:2020-03-09
Group:Individual Submission
Pages:6
URL:
https://www.ietf.org/internet-drafts/draft-mattsson-tls-cbor-cert-compress-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-mattsson-tls-cbor-cert-compress/
Htmlized:   
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-cbor-cert-compress


Abstract:
   Certificate chains often take up the majority of the bytes
   transmitted in TLS handshakes.  Large handshakes can cause problems,
   particularly in constrained IoT environments.  RFC 7925 defines a TLS
   certificate profile for constrained IoT.  General purpose compression
   algorithms can in many cases not compress RFC 7925 profiled
   certificates at all.  By using the fact that the certificates are

Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

[Hannes Tschofenig]

Hi Hanno,


I believe the part of the paragraph that talks about "canned ACKs" needs to be 
clarified.


In https://github.com/tlswg/dtls13-spec/pull/135 I changed the text  from



"

   Although KeyUpdate MUST be acknowledged, it is possible for the ACK

   to be lost, in which case the sender of the KeyUpdate will retransmit

   it.  Implementations MUST retain the ability to ACK the KeyUpdate for

   up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-

   update keying material, but they MAY do so by responding to messages

   which appear to be out-of-epoch with a canned ACK message; in this

   case, implementations SHOULD rate limit how often they send such

   ACKs.

"



To:


"
Although KeyUpdates MUST be acknowledged, it is possible for the ACK to be
lost, in which case the sender of the KeyUpdate will retransmit it.
The receiver of the KeyUpdate MUST retain the ability to ACK the KeyUpdate for
up to 2MSL. It is RECOMMENDED that they do so by retaining the
pre-update keying material, but they MAY remove the pre-update
keying material only upon receipt and successful decryption of a message
using the new keys.
"

Ciao
Hannes


From: Hanno Becker 
Sent: Monday, March 30, 2020 8:02 PM
To: Hannes Tschofenig ; tls@ietf.org
Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

Hi Hannes,

>  In your example below, the sender of the initial KeyUpdate has to re-send it 
> because of the lost ACK. In order to resubmit it, it has to use the old 
> keying material (or cache the message). The receiver cannot immediately 
> delete keying material after processing the initial KeyUpdate message because 
> it does not know whether the ACK will subsequently get lost.

My point is that the paragraph cited at the top of my post appears to say that 
receivers MAY immediately delete keying material after
receiving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate 
(even though they can't decrypt it anymore). The example
shows that this doesn't work, unless I've made a mistake.

Best,
Hanno
____
From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Sent: Monday, March 30, 2020 11:57 AM
To: Hanno Becker mailto:hanno.bec...@arm.com>>; 
tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>>
Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages?


Hi Hanno, Hi all,



I believe it would be useful to add some extra sentences to the draft to 
retaining the old key material.



In your example below, the sender of the initial KeyUpdate has to re-send it 
because of the lost ACK. In order to resubmit it, it has to use the old keying 
material (or cache the message). The receiver cannot immediately delete keying 
material after processing the initial KeyUpdate message because it does not 
know whether the ACK will subsequently get lost.



Ciao

Hannes



From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Hanno Becker
Sent: Saturday, March 28, 2020 11:31 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages?



In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states:



   Although KeyUpdate MUST be acknowledged, it is possible for the ACK

   to be lost, in which case the sender of the KeyUpdate will retransmit

   it.  Implementations MUST retain the ability to ACK the KeyUpdate for

   up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-

   update keying material, but they MAY do so by responding to messages

   which appear to be out-of-epoch with a canned ACK message; in this

   case, implementations SHOULD rate limit how often they send such

   ACKs.



This seems to allow implementations to remove old incoming keys immediately

after ACKing the KeyUpdate, which appears to open the door for the following

situation leading to deadlock:





  +-+

  |   KeyUpdate, epoch N|-> received

  +-+

  ++

   lost x-| ACK,   epoch M |

  ++



  [ new incoming epoch N+1,

remove keys for epoch N ]



- ++

  received  <-|   KeyUpdate, epoch M   |

  ++

  +-+

  |   ACK, epoch N  |---[ irrelevant whether it goes through - see 
below ]

  +-+



  [ new incoming epoch M+1,

remove keys for epoch M ]



Note: This isn't an entirely unlikely situation, since a KeyUpdate with 
update_requested flag

will result in a subsequent KeyUpdate fro

Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

[Hannes Tschofenig]

Hi Hanno, Hi all,

I believe it would be useful to add some extra sentences to the draft to 
retaining the old key material.

In your example below, the sender of the initial KeyUpdate has to re-send it 
because of the lost ACK. In order to resubmit it, it has to use the old keying 
material (or cache the message). The receiver cannot immediately delete keying 
material after processing the initial KeyUpdate message because it does not 
know whether the ACK will subsequently get lost.

Ciao
Hannes

From: TLS  On Behalf Of Hanno Becker
Sent: Saturday, March 28, 2020 11:31 PM
To: tls@ietf.org
Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages?

In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states:

   Although KeyUpdate MUST be acknowledged, it is possible for the ACK
   to be lost, in which case the sender of the KeyUpdate will retransmit
   it.  Implementations MUST retain the ability to ACK the KeyUpdate for
   up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-
   update keying material, but they MAY do so by responding to messages
   which appear to be out-of-epoch with a canned ACK message; in this
   case, implementations SHOULD rate limit how often they send such
   ACKs.

This seems to allow implementations to remove old incoming keys immediately
after ACKing the KeyUpdate, which appears to open the door for the following
situation leading to deadlock:


  +-+
  |   KeyUpdate, epoch N|-> received
  +-+
  ++
   lost x-| ACK,   epoch M |
  ++

  [ new incoming epoch N+1,
remove keys for epoch N ]

- ++
  received  <-|   KeyUpdate, epoch M   |
  ++
  +-+
  |   ACK, epoch N  |---[ irrelevant whether it goes through - see 
below ]
  +-+

  [ new incoming epoch M+1,
remove keys for epoch M ]

Note: This isn't an entirely unlikely situation, since a KeyUpdate with 
update_requested flag
will result in a subsequent KeyUpdate from the other side, and the only unlucky 
thing that
needs to happen is for the original ACK to be lost while both KeyUpdate 
messages go through.

At this point, both sides have updated their incoming key material but
not their outgoing key material, since they're still awaiting the ACK -
however, it turns out that they can't actually read those ACKs anymore:

After some time, the peers resend the KeyUpdate messages, which will be
blindly ACKed by the peer according to the recommendation in the spec;
however, the ACKs will be encrypted with the wrong keys and cannot
be parsed on either side:

  +---+
  | resent KeyUpdate, epoch N |-> received, but can't be read
  +---+   because incoming epoch N+1

send 'blind' ACK

  received, but can't be read++
  because incoming epoch M+1  <--| ACK,   epoch M |
 ++

The same will happen to KeyUpdate retransmission from the other side.

It seems that this results in a deadlock. Am I missing / misunderstanding 
something?

A possible mitigation would be to force retaining the old key material for 2MSL,
or alternatively, to mandate that old key material must only be removed upon
receipt and successful decryption of a message using the new keys.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

[Hannes Tschofenig]

Hi Jonathan,

Thanks for carefully reading the spec and for your feedback.

Let me quickly respond to some of your comments.

-Original Message-
From: TLS  On Behalf Of Jonathan Hammell
Sent: Friday, March 27, 2020 6:10 PM
To: Sean Turner 
Cc: TLS List 
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13

I know that this WGLC was supposed to focus on the diff between -34 and -37.  I 
don't have any comments on that diff, but I do have some comments on the draft 
following a re-read of the entire document.

# Minor

The term "deprotection" is used twice in document but never defined.

[Hannes] Looking at the text I believe we can just remove the term.
Here is the PR: https://github.com/tlswg/dtls13-spec/pull/129

~snip~

# Nits

Section 3.1 Packet Loss.  Figure 1 is a little confusing since it resembles 
Figure 5; as each has the server sending a HelloRetryRequest. Might illustrate 
the concept better to have the server send a ServerHello in Figure 1 rather 
than a HelloRetryRequest?

[Hannes] I changed Figure 1, as suggested. Note, however, there is nothing 
wrong with the figures as they are because these two sections describe 
different concepts. Figure 1 talks about packet loss and retransmissions while 
Figure 5 is about the cookie exchange.

PR is here: https://github.com/tlswg/dtls13-spec/pull/130 and for the wording 
changes below I have created another PR here: 
https://github.com/tlswg/dtls13-spec/pull/131

Section 5.1. para 3 - Typo.  "The DTLS 1.3 specification changes the way how 
cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses the 
HelloRetryRequest message". The "... the way how cookies..."
either use "how" or "the way" but not both.

[Hannes] OK.

Page 9 last para - Typo.  s/assocatiation/association

[Hannes] Fixed.

In section 3, bullet #3, the term "flight" is used without being defined; a 
reference to section 5.6 would be nice.

[Hannes] I changed the sentence to omit the term 'flight' to avoid the forward 
reference to Section 5.6 in the overview.

MSL is used first in section 4.2.1 but only defined in section 5.7.1

[Hannes] I added MSL to the terminology section.

In section 5.11 the notion of "CID concept" is mentioned. Might be nice to 
refer to section 9.1 where an example of the concept is presented. Also, 
section 9.1 never mentions "CID concept"; might be good to add the term to know 
that we are talking about the same thing.

[Hannes] I removed the term concept and added a sentence to the terminology.

In Section 6.1, the phrase "...loss and re-order an identifier is needed to 
determine..." could use a comma after "re-order" and possibly replace 
"re-order" with "re-ordering".

[Hannes] Ok.

In Section 6.1, the phrase "In addition to the key derivation steps described 
in Section 7 of [TLS13] triggered by the states during the handshake a sender 
may want to rekey at any time during the lifetime of the connection and has to 
have a way to indicate that it is updating its sending cryptographic keys" is 
long and difficult to follow.  It could be rephrased as "In addition to the key 
derivation steps described in Section 7 of [TLS13], a sender may want to rekey 
at any time during the lifetime of the connection.
The epoch value provides a means to indicate that the sender is updating its 
sending cryptographic keys."

[Hannes] I re-worded the sentence.

In Section 6.1, replace "For example, client incorrectly uses..." with "For 
example, if a client incorrectly uses..."

[Hannes] OK.

In Section 7, the term "current key" is used in the phrase "Implementations 
SHOULD simply use the current key."  Would it be clearer to say that 
"Implementations SHOULD use the key material of the current epoch"?

[Hannes] Fine for me.

Section 11, second para, s/Even with such a test, An/Even with such a test, an

[Hannes] Fixed.

Section 11, third bullet: the statement "...DTLS 1.3 records irrespectively of 
the use of a CID" could be rephrased as "...DTLS 1.3 records irrespective of 
whether a CID is used or not."

[Hannes] Fixed.

Ciao
Hannes


On Fri, Mar 20, 2020 at 10:18 AM Sean Turner  wrote:
>
> This is the third working group last call for the "The Datagram
> Transport Layer Security (DTLS) Protocol Version 1.3" draft available
> at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please
> review the document and send your comments to the list by 2359 UTC on
> 27 March 2019.
>
> This is a targeted one-week WGLC intended to focus on the changes from -34, 
> which was the subject of the second working group last call, and -37. The 
> diffs between -34 and -37 can be found at:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34=draft-
> ietf-tls-dtls13-37 As you will see in the diffs, the changes include
> 2119-language related changes in s5.1 and s7. These two changes were 
> introduced in -35, which was post in November.
>
> Note the the GH repo for this draft can be found at:
> https://github.com/tlswg/dtls13-spec
>
> Thanks,
> Chris, Joe, and 

Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Hannes Tschofenig]

John,  you reference RFC 7540 and I believe you wanted to refer to RFC 7925 
instead.

RFC 7925 talks about the Extended Master Secret extension, Signature Algorithm 
extension, and
OCSP stapling.

Ciao
Hannes

-Original Message-
From: saag  On Behalf Of John Mattsson
Sent: Samstag, 5. Oktober 2019 12:36
To: hannes.tschofe...@gmx.net; TLS@ietf.org; s...@ietf.org
Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

"hannes.tschofe...@gmx.net"  wrote:

> PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follow 
> RFC 7925/7525.

While TLS 1.2 and DTLS 1.2 can be configured to be secure, RFC 7525 is 
definitely not enough. RFC 7540 would be a good start, but also that would need 
to be extended with support of extensions like Extended Master Secret, 
Signature Algorithms, and Certificate Status Request to be considered fine in 
2019.

Cheers,
John




___
saag mailing list
s...@ietf.org
https://www.ietf.org/mailman/listinfo/saag
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

[Hannes Tschofenig]

Hi all,

working on the DTLS connection id drafts we noticed that there is one security 
aspect, which could benefit from an extra mitigation technique.


The issue is that an on-path adversary could intercept and modify the source IP 
address  (and the source port) of a DTLS datagram.  Even if receiver checks the 
authenticity and freshness of the packet, the recipient is fooled into changing 
the CID-to-IP/port association. This can lead to black-holed or redirected 
traffic. Of course, an on-path adversary can do lots of things to traffic and 
the problem is self-fixing but it still lead us to work on a solution in form 
of a return-routability check.

Here is the draft:
https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] draft-friel-tls-atls-03

[Hannes Tschofenig]

Hi all,

Owen and I have been working on a new version of ATLS, which you can find here:
https://tools.ietf.org/html/draft-friel-tls-atls-03

The plain version (with the DTLS record layer for protecting application data) 
is used by Cisco and by us in products.
We did, however, add extra functionality to allow the establishment of an 
OSCORE and COSE security context.
(Conceptually, this is similar to what was done many years ago with the 
DTLS-SRTP framework for media security.)

What this work provides us is re-use of existing TLS/DTLS stacks for 
application layer security.

While the actual standardization work is rather small, we noticed that the idea 
of using TLS/DTLS handshake at the application layer is still something that's 
difficult to understand.
I ran into people who thought it is not possible to use TLS/DTLS handshake at 
the application layer. For those people, the additional background text in the 
draft is quite helpful.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Elliptic Curve J-PAKE

[Hannes Tschofenig]

Hi Hugo,

I raised this issue because the IoT device bootstrapping/commissioning use case 
was the justification for developing OPAQUE and J-PAKE. J-PAKE seems to have 
met the requirements by companies working in the Thread Group working on their 
IEEE 802.15.4 mesh network*.

As someone on the microphone mentioned, the question is really about what the 
requirements are for IoT device bootstrapping.

Ciao
Hannes

*: In the meanwhile the Thread Group has moved to a certificate-based model 
since the use of passwords was not very useful for commercial indoor lighting 
deployments and they didn’t want to have the user interaction needed by 
passwords.


From: Hugo Krawczyk 
Sent: Mittwoch, 27. März 2019 03:48
To: Hannes Tschofenig 
Cc: tls@ietf.org
Subject: Re: [TLS] Elliptic Curve J-PAKE

Hi Hannes,

J-PAKE is a symmetric PAKE. Both parties store the same password. It is not 
suitable for most client-server scenarios where using J-PAKE would mean that an 
attacker that breaks into the server simply steals all plaintext passwords. 
OPAQUE is an asymmetric (or augmented) PAKE where user remembers a password 
(and nothing else, including no public key of the server) while the server 
stores a one-way image of the password. Security requires that if the server is 
compromised, the attacker needs to run an offline dictionary attack for each 
user in the database to find the password.

If what you need is a symmetric PAKE then there are better candidates than 
J-PAKE such as SPAKE2 described in draft-irtf-cfrg-spake2-08. SPAKE2 is *much* 
more efficient than J-PAKE and while both J-PAKE and SPAKE2 have proofs of 
security, SPAKE2 is proven in a stronger security model relative to J-PAKE.

I am not aware of any advantage of J-PAKE over SPAKE2 - but I may be missing 
something. Maybe the PAKE presentation in cfrg will clarify these issues 
further.

Hugo



On Tue, Mar 26, 2019 at 1:03 PM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
Hi all,

in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned 
that the Thread Group has used the Elliptic Curve J-PAKE for IoT device 
onboarding.
Here is the draft written for TLS 1.2:
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01

The mechanism is described in https://tools.ietf.org/html/rfc8236

@Nick & Richard: Have a look at it and see whether it fits your needs.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Elliptic Curve J-PAKE

[Hannes Tschofenig]

Hi all,

in context of the OPAQUE talk by Nick today at the TLS WG meeting I mentioned 
that the Thread Group has used the Elliptic Curve J-PAKE for IoT device 
onboarding.
Here is the draft written for TLS 1.2:
https://tools.ietf.org/html/draft-cragie-tls-ecjpake-01

The mechanism is described in https://tools.ietf.org/html/rfc8236

@Nick & Richard: Have a look at it and see whether it fits your needs.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

[TLS] draft-ietf-tls-dtls-connection-id-04

[Hannes Tschofenig]

Hi all,

Yesterday I submitted version -04 of the DTLS 1.2 CID draft. On the working 
group Github issue tracker we spent a long time discussing how the MAC 
calculation should be changed to include the cid/cid_length information. In 
version -03 we only provided a description how to use the CID functionality 
with AEAD ciphersuites. In version -04 we also included a description for 
non-AEAD ciphersuites as well. Since the description became a bit convoluted we 
improved the language and the representation of the record layer protection and 
of the record layer format. We hope that implementers will find the -04 version 
easier to read.

Here is the draft:
https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-04

Here is the diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-04.txt

We have been doing interop testing this year while editing the spec. If you 
want to test your code please drop me an email or take a look at 
https://github.com/tlswg/dtls-conn-id/issues/18

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] CWTs in TLS

[Hannes Tschofenig]

Hi all,

I submitted a short document about the use of CBOR Web Tokens (CWTs) in TLS.. 
The document is quite simple in the sense that it registers a new "certificate 
type" into an already existing registry.

Here is the draft: https://tools.ietf.org/html/draft-tschofenig-tls-cwt-00

At the moment, this is a bit of an experiment. We hope to get some code size 
improvements over the use of X.509 certificates.

Ciao
Hannes & Mathias

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Enforcing Protocol Invariants

[Hannes Tschofenig]

Hi Ryan

 

reading through your email and the subsequent exchanges I am surprised that you show up right after years of standardization of TLS 1.3.

Suggesting ideas at the right time is somewhat important.  

 

Later in your emails you explain what you consider complex in TLS and some of the ideas you are suggesting are alternative design approaches. What standardization helps you do is to work out the details of these different proposals and then to compare the different approaches against each other. 


 

> The state of cyber security is a horrible disappointment.

... and most (if not all) of that disappointment has nothing to do with TLS. 

 

Ciao

Hannes

 


Gesendet: Donnerstag, 08. November 2018 um 09:44 Uhr
Von: "Ryan Carboni" 
An: tls@ietf.org
Betreff: [TLS] Enforcing Protocol Invariants

Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe we should ask Google.
 

The SSHFP DNS record exists. DNSSEC exists.

 

This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record. In another DNS TXT record, a list of supported protocols could be listed.

A DNS SRV record would define the port that one can use to connect to a service, because the URL scheme died after .onion was recognized as a domain and after chromium decided to that the presentation of sub domains was unimportant. So no browser has to show which port it is connected to.

Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, and SHAKE-128 as AEAD.

And maybe recommend that boot entropy could be obtained by using the timer entropy daemon for one second (and which would in theory provide enough entropy for perpetuity).

 

This isn’t rocket science. The state of cyber security is a horrible disappointment.
___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls




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

Re: [TLS] Are we holding TLS wrong?

[Hannes Tschofenig]

I took a quick look at the document and I don't know Babel. 

 

I see that you have two different proposals for securing Babel messages, namely 

* DTLS, and 

* a custom format offering integrity protection only. 

 

You correctly note in the document that DTLS offers more features. It is an authentication and key exchange protocol.  

 

One option to explore is to use DTLS to perform authentication and key exchange then use your custom format for integrity protection of packets with the keys exported from DTLS. Design-wise this approach is similiar to what we have done with DTLS-SRTP. This would also allow you to cover the multicast security case. 

 

Ciao

Hannes

 



Gesendet: Donnerstag, 08. November 2018 um 11:30 Uhr
Von: "Fossati, Thomas (Nokia - GB/Cambridge)" 
An: "David Schinazi" 
Cc: "draft-ietf-babel-d...@ietf.org" , "tls@ietf.org" 
Betreff: Re: [TLS] Are we holding TLS wrong?

Hi David,

A few quick notes below.

Cheers

The 11/08/2018 09:14, David Schinazi wrote:
> Hi everyone,
>
> Over in the Babel working group we have a draft about securing Babel with
> DTLS:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
>
> It's 5 pages long, could any TLS experts please give it a quick read and
> let us know if we're using DTLS correctly?
>
> Also, should the document contain guidance such as which DTLS version to
> use?
>
> Thanks,
> David

Premise: I don't know Babel -- apologies for any nonsense!

One high level thing which I can't extrapolate from the draft (which is
probably due to my ignorance with Babel) is whether you envisage that
*every* node does DTLS on the unicast channel, IOW that non-DTLS nodes
are excluded from the mesh? Or would it be acceptable to mesh HMAC and
DTLS neighbours? What about clear-text speakers? (It'd seem unwise to
let them in an otherwise secured enclave.)

You should probably provide some guidance about the kind of
credentials do you plan to use (certs, raw pkeys)?

It seems to me that the P2P nature of the protocol requires mutual
authentication, could you confirm it? This seems to be a critical thing
to prevent a rogue node to spoof the lowest (highest, I have already
forgot, sorry) L-L address in a clear-text multicast Hello and bypass
authentication.

- s2.1
"Nodes SHOULD ensure that new client DTLS connections use different
ephemeral ports from recently used connections to allow servers to
differentiate between the new and old DTLS connections."

Maybe you could suggest using a sufficiently entropic connection id here
as a more robust alternative.

- s2.5
Not sure what the ceremonies around flushing a neighbor are, but I'd
make explicit signalling EOD at least a SHOULD? It seems more polite
:-)

- s.3
Not sure which TLS stack Babel nodes will use (are you targeting
extremely constrained devices with custom TLS implementations?), but all
the stacks I know of let the application set the MTU and take care of
splitting the messages in MTU sized chunks transparently.

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



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

[TLS] Application Transport LAyer Security (ATLAS)

[Hannes Tschofenig]

Hi all,

around the last IETF meeting we had a good discussion on the list
regarding application layer TLS, as proposed in
draft-friel-tls-over-http-00 and various other drafts. For the next IETF
meeting we are planning to request a BOF to have a dedicated timeslot
allocated.

For upfront discussions we have created a new mailing list, see
https://www.ietf.org/mailman/listinfo/atlas

We are planning to distribute a strawman charter proposal to that list
in the next few days.

Ciao
Hannes

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

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

Hi Peter,

too bad that you are not attending the upcoming IETF meeting in person.
I am sure that others would like to hear your thoughts about an
end-to-end security solution that is even better than the TLS 1.3
protocol. At least I am interested.

Maybe you can share something on the list.

Ciao
Hannes

On 11/07/2017 05:21 PM, Peter Saint-Andre wrote:
> On 11/7/17 8:15 AM, Hannes Tschofenig wrote:
>> FWIW: I can tell you what the threat model was with the layered TLS work.
>>
>> Let me give you a very specific example. Imagine a Bluetooth Low Energy
>> device that communicates via a phone to a cloud-based service. The
>> communication from the phone to the cloud uses HTTPS. The communication
>> from the BLE device to the phone uses ordinary BLE
>> services/characteristics.
>>
>> The Layered TLS/application layer TLS would in this case run from the
>> BLE device all the way to the cloud-based service at the application layer.
>>
>> This allows us to provide end-to-end security across a proxy (in this
>> case the phone) and independent of the underlying protocols.
>>
>> Does this make sense?
> 
> Given your assumptions, yes. Although IMHO there's got to be a better
> way to accomplish the goal of end-to-end security here. If I were going
> to IETF 100, I'd propose getting together for a beer to discuss...
> 
> Peter
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

On 11/07/2017 01:20 PM, Salz, Rich wrote:
> 
> ➢ Our work was motivated by the discussions in the IoT groups about
> re-inventing the TLS handshake at the application layer.
> 
>  Isn’t that what QUIC does (to a good enough approximation)?
> 

I see QUIC more as a new transport layer.

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

[TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

[Hannes Tschofenig]

This is interesting since Mark Baugher and myself have also been working
on the use of TLS at the application layer and we did some
implementation work with mbed TLS (with TLS 1.3) and OpenSSL.

Our work was motivated by the discussions in the IoT groups about
re-inventing the TLS handshake at the application layer.

Our document can be found here:
https://tools.ietf.org/html/draft-tschofenig-layered-tls-00

Ciao
Hannes

On 11/07/2017 10:21 AM, Alex C wrote:
> What exactly is the threat model here?
> 
> Are you trying to hide a connection from a reverse proxy at the server
> end? If so, the server operator should not have deployed a reverse proxy
> in the first place.
> 
> Are you trying to hide from a MITM proxy that supplies its own
> certificate? If so, then what prevents the proxy from doing the same to
> the tunnelled session?
> When MITM proxies learn to do that, will we create another tunnelling
> protocol inside this one?
> 
> This is a cat-and-mouse game with middleboxes (much like the version
> negotiation problem, but in a different way). Keep playing and everyone
> loses.
> 
> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  > wrote:
> 
> Hey TLS folks,
> 
> Owen, Max, and I have been kicking around some ideas for how to make
> secure connections in environments where HTTPS is subject to MitM /
> proxying.
> 
> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> creating a channel you could use when you really need things to be
> private, even from the local MitM. 
> 
> Feedback obviously very welcome.  Interested in whether folks think
> this is a useful area in which to develop an RFC, and any thoughts
> on how to do this better.
> 
> Thanks,
> --Richard
> 
> 
> On Mon, Oct 30, 2017 at 3:47 PM,  > wrote:
> 
> 
> A new version of I-D, draft-friel-tls-over-http-00.txt
> has been successfully submitted by Owen Friel and posted to the
> IETF repository.
> 
> Name:           draft-friel-tls-over-http
> Revision:       00
> Title:          Application-Layer TLS
> Document date:  2017-10-30
> Group:          Individual Submission
> Pages:          20
> URL:           
> https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt
> 
> 
> Status:       
>  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
> 
> Htmlized:     
>  https://tools.ietf.org/html/draft-friel-tls-over-http-00
> 
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00
> 
> 
> 
> Abstract:
>    Many clients need to establish secure connections to application
>    services but face challenges establishing these connections
> due to
>    the presence of middleboxes that terminate TLS connections
> from the
>    client and restablish new TLS connections to the service.  This
>    document defines a mechanism for transporting TLS records in HTTP
>    message bodies between clients and services.  This enables
> clients
>    and services to establish secure connections using TLS at the
>    application layer, and treat any middleboxes that are
> intercepting
>    traffic at the network layer as untrusted transport.  In
> short, this
>    mechanism moves the TLS handshake up the OSI stack to the
> application
>    layer.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time
> of submission
> until the htmlized version and diff are available at
> tools.ietf.org .
> 
> The IETF Secretariat
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Preshared Keypairs for (D)TLS 1.2

[Hannes Tschofenig]

Hi Tony

thanks for sharing your thoughts.

It sounds a bit like you want to use public key crypto but without the
overhead of certificates.

If that's true then you might find https://tools.ietf.org/html/rfc7250
useful.

Ciao
Hannes


On 10/26/2017 05:03 PM, Tony Putman wrote:
> Hi all,
> 
>  
> 
> I've recently started working in the IoT space and wish to standardize
> 
> our transport security by introducing the use of DTLS. It seems that the
> 
> usual practice is to use PSK for mutual authentication, but I'm not
> 
> happy with this solution. A breach of server security allows not only
> 
> server impersonation, but also, due to the PSK symmetry, client
> 
> impersonation.
> 
>  
> 
> We are already using static ECDH keys for authentication (at the
> 
> application layer), so I looked for a way to make use of these in DTLS
> 
> and came up with the following solution using (D)TLS 1.2:
> 
>  
> 
> Assume the client is provisioned with an Id, a corresponding private key
> 
> 'c_id' and a corresponding server public key 'S_id' (the server key may
> 
> be different for each Id or it may be common across all clients); the
> 
> server has a list of client public keys 'C_id' and corresponding server
> 
> private key(s) 's_id'. This OOB pre-provisioning corresponds to that of
> 
> a symmetric PSK.
> 
>  
> 
> The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK
> 
> handshake as in RFC4279. This solution applies to both DH/DHE keys and
> 
> to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so
> 
> the following explanation focuses on the EC variant. The messages are:
> 
>  
> 
>     Client Server
> 
>     -- --
> 
>     ClientHello ->
> 
>   ServerHello
> 
>     ServerKeyExchange
> 
>     <-    ServerHelloDone
> 
>     ClientKeyExchange
> 
>     ChangeCipherSpec
> 
>     Finished    ->
> 
>  ChangeCipherSpec
> 
>     <-   Finished
> 
>     Application Data    <>   Application Data
> 
>  
> 
> The way this differs from TLS_ECDHE_PSK is only in the generation of
> 
> the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A'
> 
> (public) from the server; and 'b' (private) and 'B' (public) from the
> 
> client. Then the client and server form the premaster secret in a struct
> 
> with the following information (where [x]Y represents multiplication of
> 
> the point 'Y' by the scalar 'x'):
> 
>     Client Premaster:   [b]A || [c_id]A || [b]S_id
> 
>     Server Premaster:   [a]B || [a]C_id || [s_id]B
> 
>  
> 
> The first term provides PFS even if both client and server static
> 
> private keys become known; the second term provides client
> 
> authentication even if server keys are compromised; and the third term
> 
> provides server authentication even if client keys are compromised.
> 
>  
> 
> My questions to the list are:
> 
> =
> 
> 1. Has anything similar to this been proposed before (I found nothing)?
> 
> 2. Can anyone see a problem with this formulation?
> 
> 3. Is there any interest in this (I would be happy to write an ID)?
> 
>  
> 
> The reason that I advocate this for IoT devices over signature schemes
> 
> is that the code for ECDH will already have to be present if modern
> 
> key agreement methods with PFS are to be used. So this solution uses
> 
> fewer resources than ECDHE together with a signature scheme in terms of
> 
> code space and RAM, and improves execution speed (I believe ECDH is about
> 
> twice as fast as equivalent signature generation/checking). Also, fewer
> 
> messages are needed and the messages are smaller (even if using raw keys).
> 
>  
> 
> A constraint not made explicit above is that the (EC)DHE keys must use
> 
> the same group/curve parameters as define the preshared keypairs. Since
> 
> the ClientHello does not contain any client information, this means the
> 
> server endpoint (e.g. as defined by SNI) can only support a single form
> 
> of preshared keypair. This could be improved on in TLS 1.3.
> 
>  
> 
> I don't believe that this constraint is serious, because this method is
> 
> designed to be used in the same scenarios as PSK; that is, where client
> 
> and server have an OOB method of receiving authentication credentials
> 
> from a common source. In this situation, the server is unlikely to be
> 
> serving clients which use multiple types of preshared keypairs, though
> 
> it does mean that if the keypair format is changed (e.g. strengthened)
> 
> during the life of an IoT product then a new server endpoint will have
> 
> to be defined for the upgraded products.
> 
>  
> 
> Additionally, this method is proposed to prevent the leaking of client
> 
> credentials if the server is compromised. This means that the client
> 
> private key must 

Re: [TLS] Connection ID Draft

[Hannes Tschofenig]

I would like to focus on one of the points raised below:
> 3.   We have a practical usecase in IoT. The IOT device, like
> intelligent water meter, sends one message per day, and goes to sleep.
> It wakes up in the second day and sends a message and then goes to
> sleep. If it always (or for a long time) use the same CID, there may be
> a risk of tracing IOT device or the owner of this device. Therefore, it
> is important to recommend user to update CID once it finishes sending
> message. For the CID in DTLS1.2, this becomes worse.


The user is typically not doing anything.


Without this CID extension you would send a full exchange or use session
resumption. This would allow someone in the middle to see the handshake.
In DTLS/TLS 1.2 this would reveal the client certificate.

With DTLS 1.3 and this extension you would hide the certificate and you
could echange new CIDs and switch between them every day. The source IP
address will most likely still reveal the subscriber (if you consider
some cooperation with the ISP).

So, you actually get pretty good privacy properties with DTLS 1.3 & CID
(unless some of the data center folks destroy it again with their fancy
extensions). With DTLS 1.2 there is only a performance benefit but the
privacy properties remain the same IMHO.

Ciao
Hannes


> 
>  
> 
> Regards,
> 
> Yin Xinxing
> 
>  
> 
> *发件人:*TLS [mailto:tls-boun...@ietf.org] *代表 *Eric Rescorla
> *发送时间:*2017年10月13日7:14
> *收件人:*tls@ietf.org
> *主题:*[TLS] Connection ID Draft
> 
>  
> 
> Hi folks,
> 
>  
> 
> I have just posted a first cut at a connection ID draft.
> 
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
> 
>  
> 
> Comments welcome.
> 
>  
> 
> -Ekr
> 
>  
> 
>  
> 
>  
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Should CCM_8 CSs be Recommended?

[Hannes Tschofenig]

CCM_8 is used in the IoT space because some SDOs believed that they need
to optimize the transmission overhead. Clearly, this is not meant for
general purpose use but rather for IoT only.

Is it a good idea to truncate the authentication tag? I don't have an
opinion about that but that's what the specifications make you use and
that's also what is now in hardware.

On 10/10/2017 01:05 AM, Sean Turner wrote:
> Anybody else has thoughts on this?
> 
> spt
> 
>> On Oct 3, 2017, at 18:53, Sean Turner  wrote:
>>
>> In the IANA registries draft 
>> (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added 
>> a recommended column to the Cipher Suites (CSs) registry (and some others).  
>> Right now, the criteria for getting a recommended mark is AEAD ciphers with 
>> strong authentication standards track ciphers.  While that’s great 
>> generally, the list we’ve got five CSs that gave Joe and I pause:
>>
>> TLS_DHE_RSA_WITH_AES_128_CCM_8
>> TLS_DHE_RSA_WITH_AES_256_CCM_8
>> TLS_PSK_DHE_WITH_AES_128_CCM_8
>> TLS_PSK_DHE_WITH_AES_256_CCM_8
>> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256
>>
>> The CCM_8 CSs have a significantly truncated authentication tag that 
>> represents a security trade-off that may not be appropriate for general 
>> environment.  In other words, this might be great for some IoT device but we 
>> should not generally be recommending these.
>>
>> We’re recommending that these five suites be dropped from the recommended 
>> list.  Please let us know what you think.
>>
>> J
>> (editor hats on)
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Hannes Tschofenig]

Hi Martin,

On 10/10/2017 10:52 AM, Martin Rex wrote:
> Nope, none at all.  I'm _not_ asking for protocol changes, just that
> the TLS handshake continues to end with CCS + HS, and ContentTypes
> remain visible.  Contents of all handshake messages, and whether
> and how that content is protected, remains subject to negotiated
> protocol version which may vary significantly.

FWIW: Making the ContentType visible is a protocol change since the
current version of the TLS / DTLS 1.3 protocol encrypts them.

Ciao
Hannes

PS: I think sending fake ChangeCipherSpec messages around is a terrible
idea.

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

Re: [TLS] draft-ietf-tls-record-limit-01

[Hannes Tschofenig]

Hi Hubert,

your proposal to include the worst case calculations are indeed another
possibility. It provides more information for the developer than the
current version of the document.

A few additional remarks:

On 09/12/2017 08:11 PM, Hubert Kario wrote:
> On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote:
>> Hi Martin,
>>
>> I have implemented the record size extension into mbed TLS. It can be
>> found at https://github.com/ARMmbed/mbedtls/pull/1088
>>
>> There is only one problem that remains to be addressed IMHO. This
>> extension was developed to address the problem of devices with small
>> RAM. Application developers have to configure their embedded TLS stack
>> in such a way that the parameters configured with this TLS extensions
>> match the available hardware.
>>
>> The record_size_limit helps a lot already but does not quite to the
>> final goal since it uses an artificial metric for deciding when to
>> fragment records.
>>
>> Currently, a developer has to understand various security concepts to
>> get this right, namely
>>  * Ciphersuite negotiated (and the overhead associated with it, such as
>> tag length),
>>  * DTLS vs. TLS record layer header differences,
>>  * potential compression being applied.
>>
>> Additionally, there is, of course, other header information that needs
>> to be considered in the overall buffer size calculation, such as TCP or
>> UDP, IP and potentially any lower layer headers.
>>
>> I just think that this is too much to ask for from an ordinary developer.
>>
>> Hence, I would suggest to use a different metric so that the developer
>> can be certain that at least from a DTLS/TLS layer there are not records
>> being sent that exceed the indicated threshold.
>>
>> If you think that this idea is worthwhile to entertain then I will make
>> a proposal.
> 
> yes, I too found the necessary calculation rather complex and thus hard to 
> get 
> right
> 
> that being said, if you are ok with "good enough" solutions (for memory 
> allocation, for verifying correctness of packets it should be exact), the 
> actual receive buffer for encrypted TLS records has to be only 85 bytes 
> longer 
> than the value you send to server:
>  - max MAC size - 48 bytes
>  - max IV size - 16 bytes
>  - header size - 5 bytes
... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most
likely different since we are trying to optimize the record layer format.

>  - max block size for CBC ciphers - 16 bytes
>  - max padding - 16 bytes
... unless TLS/DTLS 1.3 is used where padding is a different meaning.

> since MAC size is the exact multiple of block size, the padding starts in 
> worst possible place if the MAC size is arranged on block boundary. Thus the 
> worst case scenario padding length is 16 bytes. Same in case of EtM.

Ciao
Hannes

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

[TLS] draft-ietf-tls-record-limit-01

[Hannes Tschofenig]

Hi Martin,

I have implemented the record size extension into mbed TLS. It can be
found at https://github.com/ARMmbed/mbedtls/pull/1088

There is only one problem that remains to be addressed IMHO. This
extension was developed to address the problem of devices with small
RAM. Application developers have to configure their embedded TLS stack
in such a way that the parameters configured with this TLS extensions
match the available hardware.

The record_size_limit helps a lot already but does not quite to the
final goal since it uses an artificial metric for deciding when to
fragment records.

Currently, a developer has to understand various security concepts to
get this right, namely
 * Ciphersuite negotiated (and the overhead associated with it, such as
tag length),
 * DTLS vs. TLS record layer header differences,
 * potential compression being applied.

Additionally, there is, of course, other header information that needs
to be considered in the overall buffer size calculation, such as TCP or
UDP, IP and potentially any lower layer headers.

I just think that this is too much to ask for from an ordinary developer.

Hence, I would suggest to use a different metric so that the developer
can be certain that at least from a DTLS/TLS layer there are not records
being sent that exceed the indicated threshold.

If you think that this idea is worthwhile to entertain then I will make
a proposal.

Ciao
Hannes

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

[TLS] draft-ietf-tls-record-limit-00

[Hannes Tschofenig]

Hi Martin,


In Section 4 you define what is meant by the "maximum size of record"
and in TLS 1.3 it refers to the complete length of TLSInnerPlaintext,
namely

   struct {
   opaque content[TLSPlaintext.length];
   ContentType type;
   uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;


For TLS 1.2 you are less explicit. Is it the complete length of the
TLSPlaintext or just the fragment?

  struct {
  ContentType type;
  ProtocolVersion version;
  uint16 length;
  opaque fragment[TLSPlaintext.length];
  } TLSPlaintext;

I prefer it to be the TLSPlaintext structure.

You write:
"an endpoint MUST NOT generate a protected
   record with plaintext that is larger than the RecordSizeLimit value
   it receives from its peer.
"

I think it would be good to say that a TLS stack has to check this limit
and to return an error to the application through the API so that the
application has a possibility to correct the size of the transmitted
data or to select other ways to recover from the situation.

You write:

"Unprotected messages - handshake messages
   in particular - are not subject to this limit.
"

I believe what you are trying to say is that this restriction is not
applicable to the handshake protocol and also not to the alert protocol.
Whether messages are protected or unprotected does not really matter for
the code idea of this document (which is about the buffer sizes).

It might also be good to indicate a recommended value. A meaningful
value is one that is equal to or larger than the handshake messages. If
you have buffer to store the large handshake messages, such as the
Certificate message then you will also be able to have the buffer for
the subsequent data packets. Currently, the minimum size is indicated as
64 bytes, which I believe is a bit unrealistic since even a PSK-based
exchange will need larger handshake message sizes than that.

The RecordSizeLimit is indicated in bytes, correct?

I also think it might be worthwhile to move the following paragraph to
the beginning of the document since it motivates the use of this extension:

   An Authentication Encryption with Additional Data (AEAD) ciphers (see
   [RFC5116]) API requires that an entire record be present to decrypt
   and authenticate it.  Some implementations choose not to implement an
   AEAD interface in this way to avoid this problem, but that exposes
   them to risks that an AEAD is intended to protect against.


Ciao
Hannes

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

[TLS] CoAP, TLS and ALPN

[Hannes Tschofenig]

Hi all,

I would need your deployment experience with the use of ALPN.

Here is the background: With the CoAP over TCP/TLS described in
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09
we are defining how to run CoAP over TCP and TLS. CoAP is a protocol
typically used in the Internet of Things environment, which was
initially designed to operate over UDP.

To ensure proper multiplexing we offer two approaches, namely one using
ALPN and the other one is to use a dedicated port.

The suggestion was made to only use ALPN (see
https://github.com/core-wg/coap-tcp-tls/issues/155).

This is may be fine since many stacks implement ALPN already (including
embedded TLS stacks).

What is the situation on the TLS loadbalancer/concentrator side? Do
these boxes also forward the ALPN information to the application server?
Has someone run into operational issues with ALPN on the server-side?

Ciao
Hannes

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

Re: [TLS] What counts as the same ClientHello?

[Hannes Tschofenig]

Hi Noah, Todd, Ilari,

the HRR is used for two purposes, namely
 * to report an error (with the key shares), and
 * for DoS protection.

In both cases it feels excessive to require that the two ClientHellos
are the same (with some minor exceptions). I see this as particularly
problematic for the use with DTLS since with connectionless transport
protocols the use of the HRR is obviously common and we are essentially
wasting bytes on the wire for no good reason(with every handshake).

For the return-routability check there will be a cookie in the HRR and
the RR check is useful primarily for connectionless transports.
Re-transmitting the same information twice in this case is of doubtful
value since (a) either the cookie contains the necessary info already or
(b) the second ClientHello carries the relevant information.

Does this make sense?

Ciao
Hannes

On 08/22/2017 10:13 PM, Ilari Liusvaara wrote:
> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>> Hello Todd!
>>
>> I also did not see a reason why the random values had to be the same
>> but the language does mandate it.  
> 
> I really do not think there is any technical or security reason why the
> randoms have to be the same. After all, TLS 1.3 does not directly use
> the randoms anywhere (they only affect things indirectly via hashes of
> the handshake).
> 
>> You make a good argument for not altering the padding on the second
>> ClientHello.
> 
> I read that argument as "TLS 1.3 implementations should not need
> padding".
> 
> I took a look at struct ClientHello and the extensions list:
> 
> There are technical reasons for not altering (the client has no idea
> what the heck server did with these):
> 
> - server_name
> - max_fragment_length
> - status_request
> - signature_algorithms
> - use_srtp
> - heartbeat
> - application_layer_protocol_negotiation
> - signed_certificate_timestamp
> - client_certificate_type
> - server_certificate_type
> - psk_key_exchange_modes (due to side-effects)
> - certificate_authorities
> - post_handshake_auth
> 
> The following are explicitly listed as to be altered/deleted:
> 
> - key_share 
> - pre_shared_key
> - early_data
> - cookie
> 
> The following do not negotiate state:
> 
> - 
> - padding
> 
> The following can't appear in ClientHello:
> 
> - oid_filters
> 
> The following client gains information about in HRR:
> 
> - 
> - supported_groups (partially if key_share was not present).
> - supported_versions (the client knows what server selected).
> 
> 
> However the last group seems to be kind of things that are rather
> questionable to prune (might be okay, but those make me wary).
> 
> 
> 
> Also, I came accross one edge case: What if client discovers that all
> tickets in pre_shared_key are incompatible? The definition does not
> allow 0 tickets, so choices are:
> 
> 1) Leave all the tickets (which is not going to work) in.
> 2) Leave one ticket (which is not going to work) in.
> 3) Strip the entiere extension.
> 
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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