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

[Achim Kraus]

Hi,


I'd go further - ISTM an argument for a re-design
that just doesn't have the privacy problem. (And
maybe come back to the TLS WG after that's done.)


The "privacy problem" may disappear, if the DLT is
part of that "IoT deployment" and is not considered
as an external component. Anyway, it's the proposal
of others, so it's also their mission to argument
and convince others.

best regards
Achim

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

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

[Achim Kraus]

Hi,


On that basis, I'd consider this a bad idea that
ought not be pursued, and certainly not by the TLS
WG.


for me this sounds more like an argument for a

"recommended (for general use-cases) n".

Or does the TLS group focus on Web only and I missed that?

best regards
Achim

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

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

[Achim Kraus]

Hi Andrea,

>  to avoid the only option available today:

That wonders me. I think, what is more in question is the comparison
of the new certficate type with the two currently used ones (x509 and
Raw Public Key). Reading your link, my first impression is, that this
is pretty similar to x509 but in json. So talking about "only option"
seems to be a little over done.

best regards
Achim

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


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

Re: [TLS] dispatching DTLS 1.2 errata

[Achim Kraus]

Hi Sean,
Hi List,

> Errata on obsolete RFCs should be considered according to whether the
error persists in the obsoleting RFC. ... If it does not, it should be
Rejected with an explanation that the error is corrected in the
obsoleting RFC (cited by number).

I'm not sure, but I guess, that assumes the error either persists or
is corrected in an obsoleting RFC. But of the obsoleting RFC doesn't
address it because of more fundamental changes, we need first to
decide, if such "stale" errors should be corrected or not.

If such stale errors should be corrected, then the most rejects
are wrong.

About EID 5186:

(p17 is 4.2.1 not 4.2.4)

AFAIK, for stateless implementations of 4.2.1 requires that
the HelloVerifyRequest takes both, the record sequence number
and the (handshake) message_seq from the ClientHello. The same
applies to the ServerHello

best regards
Achim






Am 20.03.24 um 05:11 schrieb Sean Turner:

Hi! We’ve got 8 reported errata on DTLS 1.2 (RFC 6347):
https://www.rfc-editor.org/errata_search.php?rfc=6347_status=15=records
that we, the royal we where we is the WG, need to dispatch.  By way of 
background, the
IESG has the following statement about processing errata on the IETF stream:
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
Based on the IESG statement, please let me know by 3 April if you disagree with 
the following proposed
resolutions:

1. https://www.rfc-editor.org/errata/eid3917

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and extensions is added to the 
ClientHello struct (see s5.3).

2. https://www.rfc-editor.org/errata/eid4103

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and HelloVerifyRequest is no longer 
applicable to DTLS 1.3.

3. https://www.rfc-editor.org/errata/eid5186

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the section in question was 
extensively revised; the offending text is removed or no longer applies.

4. https://www.rfc-editor.org/errata/eid4104

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347and the paragraph in questions was 
extensively revised; the offending text is removed.

5. https://www.rfc-editor.org/errata/eid4105

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the two sections were merged into 
one.

6. https://www.rfc-editor.org/errata/eid4642

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347, the field has been renamed, and the 
field’s explanation updated.

7. https://www.rfc-editor.org/errata/eid5903

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the paragraph in questions was 
extensively revised; the offending text is reworded.

8. https://www.rfc-editor.org/errata/eid5026

Proposed dispatch: reject
Rationale: RFC 9147 obsoletes RFC 6347 and the 2119-language for the length is 
no longer in RFC 9147.

Cheers,
spt

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

[Achim Kraus]

Hi Peter,

with or without "freeze", I guess it will be not too easy to get enough
interest for required discussions and reviews to change or fix TLS 1.2.
On the other side, if there is enough interest for a special future 1.2
topic, I also don't get it, why that should be blocked with an "feature
freeze". For me it looks quite common, that only those who are
interested are participating in discussions. Those who are not
interested don't need to spend time. At least, I don't see, that someone
has to spend in the future more time in TLS 1.2 than in this discussion
about to "freeze" it.

(Yes, I read that "once" and then "never again". We will see, if that
works.)

best regards
Achim


Am 12.12.23 um 10:09 schrieb Peter Gutmann:

Rob Sayre  writes:


On Mon, Dec 11, 2023 at 5:30 PM Peter Gutmann  wrote:

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.


I have to say, I am skeptical of this claim.


Which one, that there is equipment out there with 20-30 year life cycles or
that the WebTLS folks will be arguing over TLS 1.64 in the future?  If the
latter then it may just be TLS 1.59 at that point, as I said I can't see the
future.  If the former then I don't really know how to respond to that, are
you saying you don't believe that there are systems out there deployed and
used with multi-decade life cycles?

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] Hardware friendly packet/record format negotiation

[Achim Kraus]

Hi Boris,

> (1)

In my experience, DTLS packages mainly contain a single application data
records, not more. So that limitation should not cause too much pain.

> The purpose of this format is to be used in closed networks, such as
high performance computing clusters

> (2)

If your network is closed, I guess you don't need to consider NATs and
so just use the old RFC6347 record without CID.

If you want to use CID, then the situation is split into receiving and
sending. For the received records your own peer defines the length.
If your peer uses a "fixed cid lenght", then the hw don't need to deal
with the variable length when receiving.
For sending the cid length may be an additional parameter for the
encryption function. That may save the additional lookup, at least at
the hw-encryption level.

> (3)

Even if it's possible, its rarely used in practice. In my experience,
it's more for very small messages, which would otherwise be too easy to
be detected, e.g. a CoAP ACK with 4 bytes. So my forecast will be, that
the performance will not be affected too much by padding.

best regards
Achim



Am 28.08.23 um 12:49 schrieb Boris Pismenny:

Hello,

*
*

I work for NVIDIA on accelerating DTLS (and QUIC) encryption in
hardware. We find that the following DTLS record aspects make
acceleration less efficient:

(1) multiple encrypted records per-packet;

(2) variable length headers; and

(3) variable length padding.

To make the protocol more hardware friendly, I would like to propose a
negotiable record format that will improve acceleration efficiency. The
purpose of this format is to be used in closed networks, such as high
performance computing clusters, and not necessarily for the Internet, so
it should be disabled by default.

*
*

Next, I explain in more detail the problem with each protocol aspect:

(1) When there are multiple encrypted records in a single packet,
hardware must perform multiple (de)encryption operations to process the
packet. This is particularly challenging for match and action pipeline
designs (such as P4) that are otherwise very suitable for packet-based
encryption. Multi-record packets are rare in the data exchange phase
which is when hardware is involved, and it would greatly simplify
hardware to avoid checking for the multi-record case.

*
*

(2) variability in the packet length and connection ID fields of DTLS1.3
requires hardware to support a number of possible formats for each
protected connection, the additional match operations to identify the
length of variable fields is unnecessarily costly.

*
*

(3) variable padding makes it hard to efficiently identify the real
content type at the trailer and the trailer's length in general. Since
there is no explicit padding length field, hardware needs to
sequentially go through the padding bytes at the trailer, which
increases latency.

*
*

All of the above are desirable features in many cases, but in
high-performance computing environments they add unnecessary flexibility
at the cost of performance. Hence, I'd like to gather feedback on a
proposal for a simplified negotiable packet format for such
environments. The proposed negotiated format will:

(1) limit the protocol to one record per-packet after the initial
handshake (epoch>=3);

(2) fix header field lengths; and

(3) eliminate packet padding.

*
*

Best,

Boris


___
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] Question about DTLS for the "no new features" draft

[Achim Kraus]

(My guess is that most would-be DTLS 1.3 implementors are off
working on QUIC; that’s certainly the case of OpenSSL.)


My guess is that many companies, which have been interested in
secure IoT device communication, are now focus on AI and not QUIC.

For hobby developers it maybe a little too much work,
to implement DTLS 1.3 in the free time. But that also
applies for DTLS 1.2 extensions with higher development
effort, not only for a general switch to DTLS 1.3.

best regards
Achim

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

Re: [TLS] Question about DTLS for the "no new features" draft

[Achim Kraus]

I don't have a complete overview, but AFAIK:

- wolfSSL (C) has DTLS 1.3

- mbedTLS (C) for now doesn't support it

- pion/dtls (GO) for now doesn't support it

- Eclipse/tinydtls (C) doesn't support it

- Eclipse/Californium (Java) doesn't support it

best regards
Achim

Am 06.08.23 um 17:01 schrieb Salz, Rich:

Quoting https://github.com/richsalz/tls12-frozen/issues/7
 raised by Jonathan
Lennox, in its entirety:

“Given the slow progress of implementations of DTLS 1.3, I think this
draft needs to be clear that this feature freeze applies only to TLS 1.2
proper, not DTLS 1.2.

“For example, I would be very sad if any new DTLS-SRTP protection
profiles could only be negotiated with DTLS 1.3.

“This may have implications for the IANA instructions section, for
registries that are shared between the two protocols.”

Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right
now, but is the industry overall lagging? Should we allow changes to
DTLS 1.2?


___
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] Servers sending CA names

[Achim Kraus]

One purpose additional to the already mentioned selection of the "right"
client certificate may be to truncate the sent client certificate path
at such a CA certificate, though that certificate is already available
at the server.
If x509 is used at all for IoT, such a truncation may reduce the amount
of data, but the list of CAs must be rather small to benefit from that
effect.

best regards
Achim

Am 12.04.23 um 22:41 schrieb Salz, Rich:

Is this generally used?  Would things go badly if we stopped sending them?


___
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] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Achim Kraus]

Too fast.
Very sorry, it is already linked to that thread.


 Weitergeleitete Nachricht 
Betreff: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and
draft-ietf-tls-rfc8447bis
Datum: Wed, 5 Apr 2023 10:47:11 +0200
Von: Achim Kraus 
An: Martin Thomson , tls@ietf.org

Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.

https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

My personal "favorite interpretation" of

RFC5246 7.4.6.  Client Certificate

is to stick to that definition there regardless of the certificate type,
which isn't mentioned there.

"If no suitable certificate is available,
 the client MUST send a certificate message containing no
 certificates.  That is, the certificate_list structure has a
 length of zero."

Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00).
From the other thread, there seems to be also other certificate types,
which defined this different, but for all, which starts with a 3-bytes
length, the "empty list" will do it.

best regards
Achim


Am 05.04.23 um 08:02 schrieb Martin Thomson:

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:

https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to
be published.

For the 8447 revision, I found that our decision to remove the
definition of the fields for each registry to be difficult.  The draft
lists changes, so now this document is no longer an easy reference for
how to register TLS extension bits.  Not a big deal and I don't want to
ask the authors to flip flop here, but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:

As mentioned during yesterday's meeting, this email starts the working
group last call for "The Transport Layer Security (TLS) Protocol
Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located
here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the
GitHub repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris
___
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


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

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

[Achim Kraus]

Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.

https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

My personal "favorite interpretation" of

RFC5246 7.4.6.  Client Certificate

is to stick to that definition there regardless of the certificate type,
which isn't mentioned there.

"If no suitable certificate is available,
 the client MUST send a certificate message containing no
 certificates.  That is, the certificate_list structure has a
 length of zero."

Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00).
From the other thread, there seems to be also other certificate types,
which defined this different, but for all, which starts with a 3-bytes
length, the "empty list" will do it.

best regards
Achim


Am 05.04.23 um 08:02 schrieb Martin Thomson:

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:

https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to
be published.

For the 8447 revision, I found that our decision to remove the
definition of the fields for each registry to be difficult.  The draft
lists changes, so now this document is no longer an easy reference for
how to register TLS extension bits.  Not a big deal and I don't want to
ask the authors to flip flop here, but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:

As mentioned during yesterday's meeting, this email starts the working
group last call for "The Transport Layer Security (TLS) Protocol
Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located
here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the
GitHub repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris
___
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


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

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

[Achim Kraus]

My interpretation of RFC5246, 7.4.6 Client Certificate

https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6

"If no suitable certificate is available, the client MUST send a
certificate message containing no certificates. That is, the
certificate_list structure has a length of zero."

covers RFC7250 as well. That section doesn't say something about
the certificate type and so in my interpretation it applies general
to all certificate types, including RPK.

So, even if RPK is negotiated for the client, the client complies
to RFC5246, 7.4.6 sending a empty list in order to indicate, that
"no suitable certificate is available".

best regards
Achim


Am 04.02.23 um 19:10 schrieb Viktor Dukhovni:

On Sun, Jan 22, 2023 at 03:41:06PM -0500, Viktor Dukhovni wrote:


Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing certificate chains.


In TLS 1.2, in response to a CertificateRequest, and with X.509 as the
(typically implicit) client certificate type, a client can decline to
authenticate itself by sending a zero length certificate list.

The ability for the client to opt-out of client authentication is quite
useful, it allows servers to request optional client certs, that give
some clients additional capabilities, while allowing other clients
to connect anonymously, and either not authenticate, or use some
other mechanism (SASL, ...) after the handshake.

RFC7250 introduces a polymorphic TLS Certificate message that admits raw
public keys.  The message contains a possibly empty certificate list, or
(crux of the problem detailed below) exactly one non-empty raw public key:

 https://datatracker.ietf.org/doc/html/rfc7250#section-3

   opaque ASN.1Cert<1..2^24-1>;

   struct {
   select(certificate_type){

// certificate type defined in this document.
case RawPublicKey:
  opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

   // X.509 certificate defined in RFC 5246
   case X.509:
 ASN.1Cert certificate_list<0..2^24-1>;

   // Additional certificate type based on
   // "TLS Certificate Types" subregistry
   };
   } Certificate;

The certificate_type is implicit, from the client_certificate_type
extension in the Server Hello, which carries exactly the subsequently
implicit type.  Therefore, with TLS 1.2, it appears that if the server
sends RPK as the client certificate type, the client has no means for
*not* sending a raw public key.

Not being able to opt-out leads to usability barriers:

- A naive client application may have signalled support for RPK
   as a supported protocol feature, expecting to be able to opt-out
   in the absence of a configured key, just as with X.509.

- The client's RPK algorithm may not be among the server's
   ClientCertificateType Identifiers:

   https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.4
   
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-2

   As a result, the client may discover late that it has no
   compatible key to send.

TLS 1.3 addresses this by wrapping even RPK client crendentials in
a list (that can be zero length).

What is the right way to handle this in TLS 1.2?

- Never offer to use client RPKs with TLS 1.2?

- Advertise client RPK support only in very narrow contexts
   where the client knows in advance that it has a key that
   will be acceptable to the server, and the server doesn't
   just solicit, but in fact requires client auth?

- Add a variant of the client_certificate_type extension
   that that allows the client to opt-out in its Certificate
   message (send length 0 to signal lack of an RPK)?

- Just send a length 0 RPK, and expect that to be taken as
   "no RPK"?

It would certainly be possible to make the upcoming OpenSSL RPK support
at least tolerate the last choice on the server side, and allow clients
to send 0-length TLS 1.2 RPKs.  Sending such 0-length RPKs in the
absence of suitable keys, will run into interoperability issues with
implemntations that don't take the same liberal reading the RFC7250
message format.

In the mean time, it seems that TLS 1.2 servers should only enable
support for client RPKs when client authentication is *mandatory*,
and clients should only advertise RPK support if they have keys that
they have good reason to expect the server to support (either RSA
expected to be generally supported by servers, or specific knowledge
of the capabilities of the particular server).

Any thoughts, comments, or advice?



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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hi Viktor,

using a compression format comes with savings, but in my experience, one
of the other issues, which comes with pain for constraint IoT, is the
amount of "parameters" sent in the ClientHello. For DTLS 1.2, that's
even sent twice, if a HelloVerifyRequest is used.
A macro to enable the set recommended by Thomas and Hannes (RFC 7925,
draft-ietf-uta-tls13-iot-profile-05) helps as well.

best regards
Achim


Am 23.01.23 um 23:47 schrieb Viktor Dukhovni:

On Mon, Jan 23, 2023 at 09:04:40PM +, John Mattsson wrote:


RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
Section 4.1 of RFC 5280".

The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
which says that: "MUST support the uncompressed form and MAY support
the compressed form".

My reading is that point compressed X.509 and RPK are allowed in TLS
and that this follows from X.509. I don't think RFC 8422 applies here.


I find that reading surprising, because at least when the point formats
extension is used:

 https://www.rfc-editor.org/rfc/rfc4492#section-5.3 (bottom of page 16)

...   If the client has used
a Supported Point Formats Extension, both the server's public key
point and (in the case of an explicit curve) the curve's base point
MUST respect the client's choice of point formats.  (A server that
cannot satisfy these requirements MUST NOT choose an ECC cipher suite
in its ServerHello message.)

which rather indicates that in *TLS* supported point formats is supposed
to cover not just the key exchange, but also the certificates.

With point formats other than "uncompressed" (or default for curve in
TLS 1.3) now deprecated, it sure seems like RPK would need to comply.

Any comments from the usual suspects (ekr, et. al.)?

Of course on the receiving side, of some implementation is more liberal
and accepts compressed there's probably little harm (provided TLSA
records or whatever the peer uses to match the expected key when/if
validating also match the compressed SPKI).

On the sending side, my reading is that the sender should probably
ensure that the transmitted form is "uncompressed" (default for
curve).  In practice, the sender's private key is likely already
in the default point format, so the "right thing" happens most
of the time, but perhaps implementations should be prepared to
DTRT in the rare case that the configured key material is in
some non-default point form.



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

Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hi John,

>  I don't think RFC 8422 applies here.

maybe, if one of that authors are reading the list, we can get an
statement, what the intention of was.

A RFC7250 handshake takes about 1500 bytes "on the wire".
Saving 32 bytes twice is not that great improvement.
If someone want to be "better off" and uses DTLS 1.2,
then considering RFC9146 improves much more, it reduces
the number of handshake.

best regards
Achim



Am 23.01.23 um 22:04 schrieb John Mattsson:

RFC 7250 states that "The SubjectPublicKeyInfo structure is defined in
Section 4.1 of RFC 5280".

The encoding of secp256r1 public keys in X.509 is defined in RFC 5480
which says that: "MUST support the uncompressed form and MAY support the
compressed form".

My reading is that point compressed X.509 and RPK are allowed in TLSand
that this follows from X.509. I don't think RFC 8422 applies here.


Should there be some code to make sure that the uncompressed format is used?


If you do something, it should probably be for all SubjectPublicKeyInfo,
not just in RPKs.

The numbers I posted beforewas wrong, I think the correct sizes are:

- Uncompressed secp256r1 RPKs are 91 bytes.

- Point compressed secp256r1 RPKs are 59 bytes

- Ed25519 RPKs are 44 bytes

Cheers,

John

*From: *TLS  on behalf of Viktor Dukhovni

*Date: *Monday, 23 January 2023 at 16:36
*To: *tls@ietf.org 
*Subject: *Re: [TLS] FYI, RFC7250 (raw public keys) to be supported in
OpenSSL ~3.2

On Mon, Jan 23, 2023 at 07:01:38AM +, John Mattsson wrote:

Hi Viktor,

Are point compressed secp256r1 RPKs supported?

- Uncompressed secp256r1 RPKs are 91 bytes.
- Point compressed secp256r1 RPKs are 59 bytes
- Ed25519 RPKs are 58 bytes


It looks to me like EC keys will be sent in their default point format,
which is set when the key pair is loaded.

I don't see any text in RFC7250 that describes how the TLS supported
point formats extension relates to EC raw public keys.  On the other
hand:

https://www.rfc-editor.org/rfc/rfc8422.html#section-5.1.2


seems to say that only the uncompressed format is to be used in TLS.

If so what is the right question now?  Should there be some code to make
sure that the uncompressed format is used?  (Rather than rely on the
private key passed through i2d_PUBKEY() to output that form by default).

--
     Viktor.

___
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] FYI, RFC7250 (raw public keys) to be supported in OpenSSL ~3.2

[Achim Kraus]

Hello Viktor,

> Thanks to Todd Short, RFC7250 raw public keys should be available in
> OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,

Sounds great. Especially for IoT/constraint use-cases that's a real
benefit.

Just in the case, someone is interested, I asked a couple of months ago,
if https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10 has
some considerations about certificate types without a validation date.
See https://github.com/tlswg/tls-subcerts/issues/107

> The pull request  is
> still a work in progress, but complete enough for application
> integration testing.

I will try to test next week the DTLS interoperability with

Eclipse/tinydtls
Eclipse/Californium

best regards
Achim


Am 22.01.23 um 21:41 schrieb Viktor Dukhovni:

Thanks to Todd Short, RFC7250 raw public keys should be available in
OpenSSL ~3.2.  Applications that use unauthenticated opportunistic TLS,
employ DANE or have other ways to avoid X.509 certificates and make do
with raw peer public keys can avoid the overhead of receiving and
processing certificate chains.

The pull request  is
still a work in progress, but complete enough for application
integration testing.  Likely too late for OpenSSL 3.1 (in beta now), but
seems likely to land by 3.2.  The TODO items on the OpenSSL side are
at this point IMHO minor.  Review eyeballs of course always appreciated.

I have a Postfix branch with a reasonably complete implementation:

 # posttls-finger -c 
 posttls-finger: [192.0.2.1]:25: raw public key fingerprint=<...>
 posttls-finger: [192.0.2.1]:25: Matched DANE raw public key: 3 1 1 
<...>
 posttls-finger: Verified TLS connection established to 
[192.0.2.1]:25:
 TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519
 server-signature RSA-PSS (2048 bits)
 server-digest SHA256

based on the the current state of the pull request.



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

Re: [TLS] Profile ID in CTLSServerPlaintext

[Achim Kraus]

I don't follow LwM2M, but DTLS-SRTP already handles this case.  See:
https://www.rfc-editor.org/rfc/rfc5763#section-5


If you're aware of cases where this design does not correctly handle
the situation, please surface them...

-Ekr




RFC 5763 lists Hannes as Author and he is involved in LwM2M.
I consider, he's the best to takes care of that.

best regards
Achim

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

Re: [TLS] Profile ID in CTLSServerPlaintext

[Achim Kraus]

> OK. Well, I believe that CID *can* handle this. Do you think otherwise?

As I wrote in the second mail: "Sorry, too fast and unprecise."

Reading the other messages in this thread, I assume, that it mainly
refers to handshakes at the same time. But I missed in my first e-mail
to be clear at that.

Under the precondition, that the handshake are executed at the same
time, I belief DTLS 1.2 CID *can not* handle this. For the handshake
messages of epoch 0 no cid-records are used, therefore parallel
handshakes requires distinguished endpoints.

best regards
Achim


Am 07.01.23 um 18:52 schrieb Eric Rescorla:



On Fri, Jan 6, 2023 at 11:43 PM Achim Kraus mailto:achimkr...@gmx.net>> wrote:


  > 2. A single server serving multiple clients, where the clients
share an
  > address.

Not sure, if "address" is just the ip-address or the ip-address and
service port. For the first it works in DTLS 1.2 CID, if the clients
have different service ports.


You don't need CID for demultiplexing in this case.


For the second it may depend on the
implementation. My implementations of DTLS 1.2 CID don't support that.


OK. Well, I believe that CID *can* handle this. Do you think otherwise?


  > 3. A single endpoint acting as both client and server on the same
address.

See the DTLS 1.2 role exchange discussion in LwM2M.


I don't follow LwM2M, but DTLS-SRTP already handles this case.  See:
https://www.rfc-editor.org/rfc/rfc5763#section-5
<https://www.rfc-editor.org/rfc/rfc5763#section-5>

If you're aware of cases where this design does not correctly handle
the situation, please surface them...

-Ekr

Am 06.01.23 um 23:17 schrieb Eric Rescorla:
 >
 >
 > On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak
mailto:xpeperm...@gmail.com>
 > <mailto:xpeperm...@gmail.com <mailto:xpeperm...@gmail.com>>> wrote:
 >
 >
 >>     On 6 Jan 2023, at 18:39, Eric Rescorla mailto:e...@rtfm.com>
 >>     <mailto:e...@rtfm.com <mailto:e...@rtfm.com>>> wrote:
 >>
 >>
 >>
 >>     On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak
 >>     mailto:xpeperm...@gmail.com>
<mailto:xpeperm...@gmail.com <mailto:xpeperm...@gmail.com>>> wrote:
 >>
 >>         > If I understand correctly, the issue here is a difference
 >>         between DTLS and
 >>         > "Datagram cTLS".  In DTLS, the syntax allows a client to
 >>         parse handshake
 >>         > messages from the server and discover that the message is
 >>         actually a
 >>         > ClientHello.  I don't know that this is a good idea,
or actually
 >>         > implemented anywhere, or even formally "allowed", but it's
 >>         at least
 >>         > syntactically possible.
 >>
 >>         Yes.
 >>
 >>         > In Datagram cTLS (as of -07), this is not possible.  The
 >>         parsing of
 >>         > handshake messages depends on prior knowledge of who
is the
 >>         client and who
 >>         > is the server.  This is because CTLSServerPlaintext and
 >>         CTLSClientPlaintext
 >>         > are different structs, but they use the same ContentType.
 >>
 >>         OK, "prior knowledge" explains everything :). I assumed all
 >>         structures should be parsed as unique objects.
 >>
 >>         RFC9146 and RFC9147 somehow confused me and made me
think that
 >>         by using CIDs it's allowed to reuse sockets A and B and then
 >>         handle multiple connections through a single path. In that
 >>         case you would have clients and servers on both sides.
Inputs
 >>         from this thread suggest that CIDs are meant for "NAT
 >>         rebinding" purpuse only.
 >>
 >>
 >>     Hmm, no, I don't think that's quite true. A server can serve
 >>     multiple clients on the same 4-tuple using the CID. It's
just that
 >>     it will not generally act as a client.
 >
 >     For sure, a server can serve multiple clients on the same address
 >     :). What I meant is that, isolated to a single path, an
endpoint (A
 >     or B) should only be a server or a client, not both at the same
 >     time. So a single "ip:port" is not supposed to “initiate”/"run"
 >     multiple isolated servers and clients at the same time.
 >
 >
 > There are t

Re: [TLS] Profile ID in CTLSServerPlaintext

[Achim Kraus]

Sorry, too fast and unprecise.

Corrections:

At retry it's unlikely, that both peers start the handshake at the same
time.

>  > 2. A single server serving multiple clients, where the clients
share an
>  > address.
>
> Not sure, if "address" is just the ip-address or the ip-address and
> service port. For the first it works in DTLS 1.2 CID, if the clients
> have different service ports. For the second it may depend on the
> implementation. My implementations of DTLS 1.2 CID don't support that.

That refers to a handshake at the same time. For handshakes at different
times or later traffic that's supported.

best regards
Achim

Am 07.01.23 um 08:43 schrieb Achim Kraus:

Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more.

DTLS role exchange was an topic in DTLS 1.2.
It was in discussion in LwM2M.

 > What I meant is that, isolated to a single path, an endpoint (A
 > or B) should only be a server or a client, not both at the same
 > time. So a single "ip:port" is not supposed to “initiate”/"run"
 > multiple isolated servers and clients at the same time.

In DTLS 1.2 that causes race conditions and the easiest way out was
to abandon the handshake and retry it with a random timeout. At retry
it's unlikely, that both peers start the handshake.

 > 2. A single server serving multiple clients, where the clients share an
 > address.

Not sure, if "address" is just the ip-address or the ip-address and
service port. For the first it works in DTLS 1.2 CID, if the clients
have different service ports. For the second it may depend on the
implementation. My implementations of DTLS 1.2 CID don't support that.

 > 3. A single endpoint acting as both client and server on the same
address.

See the DTLS 1.2 role exchange discussion in LwM2M.
Even if a "central server" is used, there are corner cases, when
such a "DTLS 1.2 role exchange" seems to be the only escape. A
NAT will frequently block that, but sometimes it may succeed.
(I don't use this approach, but others may do.)

best regards
Achim


Am 06.01.23 um 23:17 schrieb Eric Rescorla:



On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak mailto:xpeperm...@gmail.com>> wrote:



    On 6 Jan 2023, at 18:39, Eric Rescorla mailto:e...@rtfm.com>> wrote:



    On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak
    mailto:xpeperm...@gmail.com>> wrote:

    > If I understand correctly, the issue here is a difference
    between DTLS and
    > "Datagram cTLS".  In DTLS, the syntax allows a client to
    parse handshake
    > messages from the server and discover that the message is
    actually a
    > ClientHello.  I don't know that this is a good idea, or
actually
    > implemented anywhere, or even formally "allowed", but it's
    at least
    > syntactically possible.

    Yes.

    > In Datagram cTLS (as of -07), this is not possible.  The
    parsing of
    > handshake messages depends on prior knowledge of who is the
    client and who
    > is the server.  This is because CTLSServerPlaintext and
    CTLSClientPlaintext
    > are different structs, but they use the same ContentType.

    OK, "prior knowledge" explains everything :). I assumed all
    structures should be parsed as unique objects.

    RFC9146 and RFC9147 somehow confused me and made me think that
    by using CIDs it's allowed to reuse sockets A and B and then
    handle multiple connections through a single path. In that
    case you would have clients and servers on both sides. Inputs
    from this thread suggest that CIDs are meant for "NAT
    rebinding" purpuse only.


    Hmm, no, I don't think that's quite true. A server can serve
    multiple clients on the same 4-tuple using the CID. It's just that
    it will not generally act as a client.


    For sure, a server can serve multiple clients on the same address
    :). What I meant is that, isolated to a single path, an endpoint (A
    or B) should only be a server or a client, not both at the same
    time. So a single "ip:port" is not supposed to “initiate”/"run"
    multiple isolated servers and clients at the same time.


There are three things going on here, not two.

1. A single server serving multiple clients, where the clients have
different addresses.
2. A single server serving multiple clients, where the clients share an
address.
3. A single endpoint acting as both client and server on the same
address.

DTLS allows (1) by default (2) with CID, and not (3).

-Ekr



    -Ekr


    -Kristijan



___
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] Profile ID in CTLSServerPlaintext

[Achim Kraus]

Not sure, if some DTLS 1.2 history helps. Hope, it doesn't mix up more.

DTLS role exchange was an topic in DTLS 1.2.
It was in discussion in LwM2M.

> What I meant is that, isolated to a single path, an endpoint (A
> or B) should only be a server or a client, not both at the same
> time. So a single "ip:port" is not supposed to “initiate”/"run"
> multiple isolated servers and clients at the same time.

In DTLS 1.2 that causes race conditions and the easiest way out was
to abandon the handshake and retry it with a random timeout. At retry
it's unlikely, that both peers start the handshake.

> 2. A single server serving multiple clients, where the clients share an
> address.

Not sure, if "address" is just the ip-address or the ip-address and
service port. For the first it works in DTLS 1.2 CID, if the clients
have different service ports. For the second it may depend on the
implementation. My implementations of DTLS 1.2 CID don't support that.

> 3. A single endpoint acting as both client and server on the same
address.

See the DTLS 1.2 role exchange discussion in LwM2M.
Even if a "central server" is used, there are corner cases, when
such a "DTLS 1.2 role exchange" seems to be the only escape. A
NAT will frequently block that, but sometimes it may succeed.
(I don't use this approach, but others may do.)

best regards
Achim


Am 06.01.23 um 23:17 schrieb Eric Rescorla:



On Fri, Jan 6, 2023 at 9:59 AM Kristijan Sedlak mailto:xpeperm...@gmail.com>> wrote:



On 6 Jan 2023, at 18:39, Eric Rescorla mailto:e...@rtfm.com>> wrote:



On Fri, Jan 6, 2023 at 9:28 AM Kristijan Sedlak
mailto:xpeperm...@gmail.com>> wrote:

> If I understand correctly, the issue here is a difference
between DTLS and
> "Datagram cTLS".  In DTLS, the syntax allows a client to
parse handshake
> messages from the server and discover that the message is
actually a
> ClientHello.  I don't know that this is a good idea, or actually
> implemented anywhere, or even formally "allowed", but it's
at least
> syntactically possible.

Yes.

> In Datagram cTLS (as of -07), this is not possible.  The
parsing of
> handshake messages depends on prior knowledge of who is the
client and who
> is the server.  This is because CTLSServerPlaintext and
CTLSClientPlaintext
> are different structs, but they use the same ContentType.

OK, "prior knowledge" explains everything :). I assumed all
structures should be parsed as unique objects.

RFC9146 and RFC9147 somehow confused me and made me think that
by using CIDs it's allowed to reuse sockets A and B and then
handle multiple connections through a single path. In that
case you would have clients and servers on both sides. Inputs
from this thread suggest that CIDs are meant for "NAT
rebinding" purpuse only.


Hmm, no, I don't think that's quite true. A server can serve
multiple clients on the same 4-tuple using the CID. It's just that
it will not generally act as a client.


For sure, a server can serve multiple clients on the same address
:). What I meant is that, isolated to a single path, an endpoint (A
or B) should only be a server or a client, not both at the same
time. So a single "ip:port" is not supposed to “initiate”/"run"
multiple isolated servers and clients at the same time.


There are three things going on here, not two.

1. A single server serving multiple clients, where the clients have
different addresses.
2. A single server serving multiple clients, where the clients share an
address.
3. A single endpoint acting as both client and server on the same address.

DTLS allows (1) by default (2) with CID, and not (3).

-Ekr



-Ekr


-Kristijan



___
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] FW: New Version Notification for draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt

[Achim Kraus]

Hi John,

I'm not sure, are there any new arguments for this since this discussion

https://mailarchive.ietf.org/arch/msg/tls/WoBwUCqEMcFhvIHN6neo5W4Urg4/

in 2020?
Maybe, if the new arguments are highlighted, the discussion gets this
time shorter.

"Malicious actors can get access to long-term keys in different ways"

Are there considerations how that affects similar simple OSCORE variants?

best regards
Achim

Am 30.12.22 um 09:58 schrieb John Mattsson:

Hi,

I submitted a new version of draft-mattsson-tls-psk-ke-dont-dont-dont.
psk_ke is likely the weakest part of TLS 1.3 and German BSI has already
made a deadline for its deprecation. It is long overdue to change the
"Recommended" value for psk_ke to "N".

This is a major update to earlier versions and adds a lot of background
and motivation. The earlier version was never posted to the list. I plan
to request presentation time at IETF 116.

Cheers,

John

*From: *internet-dra...@ietf.org 
*Date: *Friday, 30 December 2022 at 09:47
*To: *John Mattsson , John Mattsson

*Subject: *New Version Notification for
draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt


A new version of I-D, draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-psk-ke-dont-dont-dont
Revision:   02
Title:  Key Exchange Without Forward Secrecy is NOT RECOMMENDED
Document date:  2022-12-30
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.txt 

Status:
https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/ 

Html:
https://www.ietf.org/archive/id/draft-mattsson-tls-psk-ke-dont-dont-dont-02.html 

Htmlized:
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-psk-ke-dont-dont-dont 

Diff:
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-psk-ke-dont-dont-dont-02 


Abstract:
    Massive pervasive monitoring attacks using key exfiltration and made
    possible by key exchange without forward secrecy has been reported.
    If key exchange without Diffie-Hellman is used, static exfiltration
    of the long-term authentication keys enables passive attackers to
    compromise all past and future connections.  Malicious actors can get
    access to long-term keys in different ways: physical attacks,
    hacking, social engineering attacks, espionage, or by simply
    demanding access to keying material with or without a court order.
    Exfiltration attacks are a major cybersecurity threat.  The use of
    psk_ke is not following zero trust principles and governments have
    already made deadlines for its deprecation.  This document updates
    the IANA PskKeyExchangeMode registry by setting the "Recommended"
    value for psk_ke to "N".




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

Re: [TLS] FW: New Version Notification for draft-ietf-lwig-security-protocol-comparison-06.txt

[Achim Kraus]

Hi John,

just to mention, the CCM8 is also considered to be not recommended in
the future (see
https://mailarchive.ietf.org/arch/msg/core/WnRInwF-j0uZmLggFh37ySljnwE/).
Wouldn't it make more sense to use then CCM
instead (16 bytes tag length)?

I would appreciate, if the comparison DTLS vs. TLS mentions also the
difference of UDP vs. TCP (8 vs. 24 bytes). And just a short sentence
about some more bytes for additional messages used in TCP internally?

best regards
Achim

Am 30.12.22 um 10:58 schrieb John Mattsson:

Hi,

We feel that draft-ietf-lwig-security-protocol-comparisonis getting
quite ready now that the included protocols are published or at least
stable.

We would love to have more examples of cTLS. Are there any more examples
available? We currently included the example in the draft.

Review by people in the TLS WG would be great as the draft covers TLS
1.2, DTLS 1.2, TLS 1.3, DTLS 1.3, and cTLS.

Cheers,

John

*From: *John Mattsson 
*Date: *Sunday, 25 December 2022 at 20:19
*To: *l...@ietf.org 
*Subject: *Re: New Version Notification for
draft-ietf-lwig-security-protocol-comparison-06.txt

Hi,

We submitted a new version of
draft-ietf-lwig-security-protocol-comparison. This document has been
dormant for a while as several of the referenced protocols were not
stable, which lead to a lot of work in earlier versions. All of the
protocols now seem to be stable and publishedor close to being
published. This version fixes all the comments we have received. We
think it is close to being ready for WGLC.

This is obviously needed information for a lot of people. The draft
already has 17 citations.

https://scholar.google.com/scholar?hl=en_sdt=0,5=11841781769013384442 


The need for compact formats and protocols has also gained attention
outside of IoT. In the IAB workshop on Environmental Impact of Internet
Applications and Systems, compact formats and protocols were discussed
as a way to reduce the energy consumption of the Internet as a whole.

https://www.iab.org/activities/workshops/e-impact/


Changes in -06:

- Added more context to abstract and introduction

- Added high level comparison of the number of bytes in TLS 1.2 and TLS
1.3 handshakes

- Added Compact TLS 1.3 (cTLS)

- Added some more clarification on (D)TLS choices

- Added text that CoAP needs to be added to the EDHOC figures to be
directly comparable to DTLS.

- Added more DTLS and EDHOC alternatives to the summary table.

- Added ECDSA keys without point compression as that does not seem to be
supported.

- Corrected DTLS calculation where 10 was used instead of 12 (thanks to
Stephan Koch for reporting this)

- Updated DTLS 1.3 records to align with the RFC.

- Updated EDHOC numbers to align with latest drafts.

- Added numbers for Group OSCORE pairwise mode.

- Added that DTLS and OSCORE numbers might not be directly comparable as
requirements on CoAP Token reuse are different.

- Changed names to Unicode

- Added SVG figures and tables with the help of aasvg

Cheers,

John Preuß Mattsson

*From: *internet-dra...@ietf.org 
*Date: *Sunday, 25 December 2022 at 19:52
*To: *Mališa Vučinić , John Mattsson
, Francesca Palombini
, John Mattsson
, Malisa Vucinic 
*Subject: *New Version Notification for
draft-ietf-lwig-security-protocol-comparison-06.txt


A new version of I-D, draft-ietf-lwig-security-protocol-comparison-06.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-ietf-lwig-security-protocol-comparison
Revision:   06
Title:  Comparison of CoAP Security Protocols
Document date:  2022-12-25
Group:  lwig
Pages:  45
URL:
https://www.ietf.org/archive/id/draft-ietf-lwig-security-protocol-comparison-06.txt 

Status:
https://datatracker.ietf.org/doc/draft-ietf-lwig-security-protocol-comparison/ 

Html:
https://www.ietf.org/archive/id/draft-ietf-lwig-security-protocol-comparison-06.html 

Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-security-protocol-comparison 

Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lwig-security-protocol-comparison-06
 


Abstract:
    This document analyzes and compares the sizes of key exchange flights
    and the per-packet message size overheads when using different
    security protocols to secure CoAP.  Small message sizes are very
    important for reducing energy consumption, latency, and time to
    completion in constrained radio network 

Re: [TLS] DTLS AAD length usage clarification?

[Achim Kraus]

Hi Andrew,

> length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized
DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.

Yes, the original plaintext, the original record type and the padding.
For AEAD and CBC without EtM, that "length_of_DTLSInnerPlaintext" is used.

> My understanding is that the DTLSCiphertext.length =
length_of_DTLSInnerPlaintext  + MAC Length i.e 16B for AES-GCM;

I haven't implemented EtM, so I'm not sure about that. I would guess,
the length of the explicit nounce is also included.

You may check your implementation (AEAD and CBC MtE) against:

https://github.com/eclipse-californium/californium#interop-server

https://github.com/Mbed-TLS/mbedtls/pull/6264 (AFAIK, that question
about EtM was raised also there.)

and

https://github.com/eclipse/tinydtls/tree/feature/connection_id
(client only, AEAD only)

best regards
Achim



Am 28.11.22 um 16:25 schrieb Cunningham, Andrew:

Greetings all.

I was wondering could someone help clarify my understanding on the use
of length fields for DTLS 1.2 + CID with respect to TLS1.3, specifically
with the additional data input to the AEAD functions.

If we  start with the DTLS1.2 + CID’s RFC:
https://www.rfc-editor.org/rfc/rfc9146.html#section-5

length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized
DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.

The enc_content field is the encrypted form of the serialized
DTLSInnerPlaintext structure which is covered by the DTLSCiphertext.length

My understanding is that the DTLSCiphertext.length =
length_of_DTLSInnerPlaintext  + MAC Length i.e 16B for AES-GCM;

The protection layer definitions use these variables interchangeable in
the DTLS 1.2 CID specification which is leading to some confusion (at
least in my head);

https://www.rfc-editor.org/rfc/rfc9146.html#section-5


Block Ciphers;

     MAC(MAC_write_key,

     seq_num_placeholder +

     tls12_cid +

     cid_length +

     tls12_cid +

     DTLSCiphertext.version +

     epoch +

     sequence_number +

     cid +

*_    length_of_DTLSInnerPlaintext +_*

     DTLSInnerPlaintext.content +

     DTLSInnerPlaintext.real_type +

     DTLSInnerPlaintext.zeros

     );

Encrypt then MAC;

MAC(MAC_write_key,

     seq_num_placeholder +

     tls12_cid +

     cid_length +

     tls12_cid +

     DTLSCiphertext.version +

     epoch +

     sequence_number +

     cid +

*_    DTLSCiphertext.length +_*

     IV +

     ENC(cont

AEAD Ciphers;

     additional_data = seq_num_placeholder +

   tls12_cid +

   cid_length +

   tls12_cid +

   DTLSCiphertext.version +

   epoch +

   sequence_number +

   cid +

*_  length_of_DTLSInnerPlaintext;_*

So we have some cases where the length_of_DTLSInnerPlaintext is used in
the additional data and another case for Encrypt/then/MAC where the DTLS
header length (DTLSCiphertext.length) as seen on the wire is used in the
additional data.

This seems to be slightly different for TLS1.3 which always the
TLSCiphertext.length field.
https://www.rfc-editor.org/rfc/rfc8446.html#section-5.2


I am trying to understand why we use different lengths for different
cryptographic algorithms for DTLS and diverge from how TLS1.3 implements
things.  Was there some security reason for selected of
length_of_DTLSInnerPlaintext vs DTLSCiphertext.length in the additional
data for the various protection modes?

Thanks in advance,

Regards

Andrew

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution by
others is strictly prohibited. If you are not the intended recipient,
please contact the sender and delete all copies.


___
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 Action: draft-ietf-tls-subcerts-13.txt

[Achim Kraus]

Hello list,

are there any considerations about using tls-subcerts also with other
certificate types than X509?

Especially RFC7250 (Raw Public Key) would raise the question, how to
handle certificate types, which don't carry a "notBefore". Maybe a
default value can be used.

I created https://github.com/tlswg/tls-subcerts/issues/107

best regards
Achim Kraus


Am 10.05.22 um 02:37 schrieb internet-dra...@ietf.org:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

 Title   : Delegated Credentials for (D)TLS
 Authors : Richard Barnes
   Subodh Iyengar
   Nick Sullivan
   Eric Rescorla
Filename: draft-ietf-tls-subcerts-13.txt
Pages   : 17
Date: 2022-05-09

Abstract:
The organizational separation between operators of TLS and DTLS
endpoints and the certification authority can create limitations.
For example, the lifetime of certificates, how they may be used, and
the algorithms they support are ultimately determined by the
certification authority.  This document describes a mechanism to to
overcome some of these limitations by enabling operators to delegate
their own credentials for use in TLS and DTLS without breaking
compatibility with peers that do not support this specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] Up to date overview of TLS implementations?

[Achim Kraus]

Hi John,

for draft-ietf-tls-dtls-connection-id, I have some views ("overview" may
be something else).

Eclipse/Californium, Release 3.0 (3. November 2021), Java, CoAP + DTLS
1.2, supports/configurable both deprecated variants (old MAC and
deprecated extension code-point 53) and RFC9146 variant (new MAC and
extension code-point 54).

Eclipse/Leshan, Java, LwM2M, using Californium and current development
of leshan is updated to use Californium 3.0.

Eclipse/tinydtls, C, DTLS 1.2, on my list (but for now I'm still too
busy with Californium).

Mbedtls 3.0, C, ongoing, https://github.com/ARMmbed/mbedtls/pull/5061

Tools:

Wireshark, implemented,
https://gitlab.com/wireshark/wireshark/-/issues/17695

Zephyr, waiting on mbedtls,
https://github.com/zephyrproject-rtos/zephyr/pull/36738

best regards
Achim Kraus


Am 12.11.21 um 09:55 schrieb John Mattsson:

Hi,

Is there any up to date overwiew of which TLS libraries support or are
working on support for new and upcoming stuff like:

RFC 8879 TLS Certificate Compression

draft-ietf-tls-dtls-connection-id

draft-ietf-tls-ticketrequests

draft-ietf-tls-subcerts

draft-ietf-tls-dtls13

draft-ietf-tls-esni

Cheers,

John


___
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] DTLS 1.2 and 1.3: HS message reassembly prior to processing

[Achim Kraus]

Hi Hanno,

> Note also that in the context of Post-Quantum Crypto, we're sometimes
> talking about key material >100Kb - this is an issue for MCUs.

I didn't say, this is impossible, it's more that in my opinion for DTLS
1.2 it doesn't pay off. Considering 100k, I guess, that will require a
more general update of the RFCs, not just that MUST. For IoT it may be
also valid, to assume that such large public keys will be shared ahead
by other means.

best regards
Achim

Am 06.11.21 um 09:18 schrieb Hanno Becker:

Hey Achim,

Thanks for the quick reply!

Actually, for TLS, you can do the same: Process handshake messages
piece by piece (ordered, this time), without full reassembly. I'm
not aware that the TLS spec forbids that, or does it?

For Post-Quantum Crypto, streaming implementations of schemes
with very large key materials are a thing, see e.g. SPHINCS or McEliece [1].
However, those are only of value for (D)TLS if the (D)TLS stack forwards
data
to the handshake layer prior to full reassembly -- again, both in TLS
and DTLS.

You're right that in DTLS the situation is even harder, because
fragments might be received out of order. But that doesn't mean
there's no way of potentially processing them out of order -- it very
much depends on the data. E.g. if you receive a huge matrix
which you'd like to perform a matrix-vector multiplication with,
you can do that entry by entry -- so long as you know the offset
of the data you received, which you do of course.

Note also that in the context of Post-Quantum Crypto, we're sometimes
talking about key material >100Kb - this is an issue for MCUs.

I think a MUST like this should have a justification. If there's none, then
IMO it should be left out for the benefit of implementation flexibility.

Cheers,
Hanno

[1]:

Johannes Roth and Evangelos Karatsiolis and Juliane Krämer

"Classic McEliece Implementation with Low Memory Footprint",
https://eprint.iacr.org/2021/138 <https://eprint.iacr.org/2021/138>,
Cryptology ePrint Archive: Report 2021/138 - Classic McEliece
Implementation with Low Memory Footprint - IACR
<https://eprint.iacr.org/2021/138>
Cryptology ePrint Archive: Report 2021/138. Classic McEliece
Implementation with Low Memory Footprint. Johannes Roth and Evangelos
Karatsiolis and Juliane Krämer
eprint.iacr.org

//

--------
*From:* Achim Kraus 
*Sent:* Saturday, November 6, 2021 7:36 AM
*To:* Hanno Becker 
*Cc:* tls@ietf.org 
*Subject:* Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to
processing
Hi Hanno,

  > Can someone explain the underlying rationale?

I can only guess, that this makes the processing of the handshake
messages equal to TLS. So it's separating the layers (record layer -
handshake layer).

  > It seems that in the context of very large key material or certificate
  > chains (think e.g. PQC), gradual processing of handshake messages
  > (where possible) is useful to reduce RAM usage.
  > Is there a security risk in doing this?

I'm not sure, if such an approach really pays off. Consider, that
sometimes the fragments may be reordered or single fragments are
missing. Under such conditions, collecting the fragments is a solution,
which makes receiving the complete message more probable.
For me, if someone decides to go with x509, then please provide the RAM.
That RAM may only be used temporary, later it may be used for
application payload processing. So, I don't think this should be really
an issue.

  > It would also be useful for stateless handling of fragmented
  > ClientHello messages. I'm sure this was discussed before but
  > I don't remember where and who said it, but a server implementation
  > could peek into the initial fragment of a ClientHello, check if it
  > contains a valid cookie, and if so, allocate state for subsequent full
  > reassembly. That wouldn't be compliant with the above MUST, though,
  > as far as I understand it.

How do you want to calculate the cookie. According:

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1
<https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1>

Cookie = HMAC(Secret, Client-IP, Client-Parameters)

So, which Client-Parameters are included?
For me, stateless processing would require to challenge the first
fragment (0) only, though otherwise, I can't see, how that could work
stateless.
If the cookie is build only for the first fragment, you must ensure,
that the Client-Parameters, which may be shifted by the cookie to the
next fragment, are excluded from the cookie's Client-Parameters,
otherwise you will not be able to do a stateless check of first fragment
with cookie.

But that all seems for me to be not mentioned nor intended by RFC6347.
Therefore I would recommend, to use less Client-Parameters to make the
ClientHello small. That's one good reason for RFC7252 to define a
mandatory set, clients can rely on.

best regards

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

[Achim Kraus]

Hi Hanno,

> Can someone explain the underlying rationale?

I can only guess, that this makes the processing of the handshake
messages equal to TLS. So it's separating the layers (record layer -
handshake layer).

> It seems that in the context of very large key material or certificate
> chains (think e.g. PQC), gradual processing of handshake messages
> (where possible) is useful to reduce RAM usage.
> Is there a security risk in doing this?

I'm not sure, if such an approach really pays off. Consider, that
sometimes the fragments may be reordered or single fragments are
missing. Under such conditions, collecting the fragments is a solution,
which makes receiving the complete message more probable.
For me, if someone decides to go with x509, then please provide the RAM.
That RAM may only be used temporary, later it may be used for
application payload processing. So, I don't think this should be really
an issue.

> It would also be useful for stateless handling of fragmented
> ClientHello messages. I'm sure this was discussed before but
> I don't remember where and who said it, but a server implementation
> could peek into the initial fragment of a ClientHello, check if it
> contains a valid cookie, and if so, allocate state for subsequent full
> reassembly. That wouldn't be compliant with the above MUST, though,
> as far as I understand it.

How do you want to calculate the cookie. According:

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.1

Cookie = HMAC(Secret, Client-IP, Client-Parameters)

So, which Client-Parameters are included?
For me, stateless processing would require to challenge the first
fragment (0) only, though otherwise, I can't see, how that could work
stateless.
If the cookie is build only for the first fragment, you must ensure,
that the Client-Parameters, which may be shifted by the cookie to the
next fragment, are excluded from the cookie's Client-Parameters,
otherwise you will not be able to do a stateless check of first fragment
with cookie.

But that all seems for me to be not mentioned nor intended by RFC6347.
Therefore I would recommend, to use less Client-Parameters to make the
ClientHello small. That's one good reason for RFC7252 to define a
mandatory set, clients can rely on.

best regards
Achim Kraus

Am 05.11.21 um 20:14 schrieb Hanno Becker:

Hi all,

Both DTLS 1.2 and DTLS 1.3 mandate:

 > When a DTLS implementation receives a handshake message fragment
corresponding to the next expected handshake message sequence number, it
MUST buffer it until it has the entire handshake message.

Can someone explain the underlying rationale?

It seems that in the context of very large key material or certificate
chains (think e.g. PQC), gradual processing of handshake messages
(where possible) is useful to reduce RAM usage.
Is there a security risk in doing this?

It would also be useful for stateless handling of fragmented
ClientHello messages. I'm sure this was discussed before but
I don't remember where and who said it, but a server implementation
could peek into the initial fragment of a ClientHello, check if it
contains a valid cookie, and if so, allocate state for subsequent full
reassembly. That wouldn't be compliant with the above MUST, though,
as far as I understand it.

Thanks!
Hanno
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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

Hi Sean,

I hope, the answer of Hannes counts as "significant justification".

Most of the discussion and arguments are about TLS 1.2 and 1.3.

Just to be clear:
RRC will only apply to DTLS, 1.2 and 1.3. There is no usage for TLS.
And for RRC, Hannes and Thomas wants to use the "Flags Extension".

I'm not sure, how fast DTLS 1.2 deployments will be moved to DTLS 1.3.
But I'm pretty sure, that DTLS 1.2 with Connection ID will make many
NB-IoT solutions possible, and RRC will help to defend that against
attacks.

best regards
Achim Kraus
Eclipse/Californium
(Currently DTLS 1.2 only ;-) )

Am 04.11.21 um 14:27 schrieb Sean Turner:

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


___
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 Flags and IANA registration policy

[Achim Kraus]

Hi List,

a lot of things have already been written.

So I'm not sure, if my e-mail from September last year could be
considered as well.

https://mailarchive.ietf.org/arch/msg/tls/pY6JDDb_WxBfgGbYh15vCS7sQQQ/

It's about, when replacing a "Y" with "N", then put also the period of
the "Y" amended to the "N", e.g. "N (was Y 2010-2019)".

best regards
Achim Kraus

Am 30.10.21 um 04:47 schrieb Sean Turner:

I actually think we’re going to try to do this 8447bis:
https://github.com/tls-stuff/rfc8447bis
We need to get it adopted, but that’s on tap for this IETF (or should be).

spt


On Oct 29, 2021, at 17:16, Eric Rescorla  wrote:

Well, we certainly can change it in 8446-bis.

My put here would be: let's get consensus on the *semantics* we want for the 
various categories without worrying about the names (call them A, B, C, etc.) 
and then we can name them after.

-Ekr


On Fri, Oct 29, 2021 at 2:14 PM Ira McDonald  wrote:
Hi Eric,

Thanks for the background.  I still sympathize with Hannes' point that
"Recommended" means "IETF Consensus".  I have to explain this
too often in the insular automotive industry.

But I certainly wouldn't write an RFC to change the title of a single
column in an IANA registry.  I've been one of the Designated Experts
for the IANA Internet Printing Protocol (IPP) registry for 20 years and
we rename IANA fields as needed by a direct request to our IANA
folks (after consensus in the IEEE-ISTO Printer Working Group IPP
WG - successor to IETF IPP WG in the 1990s).

Cheers,
- Ira


On Fri, Oct 29, 2021 at 3:18 PM Eric Rescorla  wrote:
Previous discussion is on this issue: 
https://github.com/tlswg/tls13-spec/issues/1214

On Fri, Oct 29, 2021 at 12:13 PM Salz, Rich  wrote:
• I am actually not in favor of changing it to IETF Consensus. I think 
these have different meanings.


To be clear, I wasn’t expressing an opinion on whether or not to do this, I was 
just showing folks how to start the change process.

___
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] Spec issue with RFC 7627 (EMS) and resumption

[Achim Kraus]

Hi David,

I'm still not sure, if there is just a misunderstanding:

For me, case 2, the support of legacy peers comes with using only
full-handshakes, and no abbreviated handshakes.

For the client the consequence is, to use full-handshakes with legacy
servers.

So, I would assume, that just the same applies for servers as well.

If a legacy client tries to execute a resumption handshake, the server
in mode 2 has two options to support such a legacy client according the
general rule to only use "full-handshakes" and not "abbreviated" ones.

- abort the client initiated abbreviated handshake in order to make the
client restart with a full-handshake (that's what the RFC defines)
- the server chose to fallback to a full-handshake directly in the same
way, that the server would do, if no matching session id is available.

https://datatracker.ietf.org/doc/html/rfc5246#page-36

"The client sends a ClientHello using the Session ID of the session to
be resumed.  The server then checks its session cache for a match.
...
If a Session ID match is not
found, the server generates a new session ID, and the TLS client and
server perform a full handshake."

With such a fallback by the server, the general rule, to only use
"full-handshakes", will be also full filled. And the benefit would be,
that the client doesn't need to send a second handshake.

best regards
Achim Kraus


Am 28.10.21 um 19:44 schrieb David Benjamin:

It depends on what the server is trying to do. If the server is trying
to mandate EMS, aborting the connection is correct. E.g. the full
handshake section then says:

    If the server receives a ClientHello without the extension, it SHOULD
    abort the handshake if it does not wish to interoperate with legacy
    clients.

Though I suppose the abbreviated handshake version is missing a "if it
does not wish to interoperate with legacy clients". Yeah, okay, this
probably also needs an erratum to add the right qualifier. Gosh this
document is confusingly organized.



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

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[Achim Kraus]

Hi David,

my question considers 2. ,
if one peer uses RFC 7627 and the other not (legacy).

Case 1:
- client using RFC 7627, server not (legacy)
-- client fallsback to full-handshakes

Case 2:
- server using RFC 7627, client not (legacy)
-- if the client tries a resumption, the current definition is, that the
server SHOULD abort.

In my opinion in case 2, the server SHOULD also just fallback to a
full-handshake. That's done by sending a ServerHello with a new Session
ID and the other handshake messages of a full handshake.
In the end, that prevents, that a client to have to execute a second,
then full handshake, as fallback.

best regards
Achim


Am 26.10.21 um 17:50 schrieb David Benjamin:

At least for an erratum, I don't think it makes sense to change that as
part of this.

I think your question is conflating a few things. Let me try to untangle
this, as this document is little confusing. It seems to be describing,
via SHOULDs and MUSTs, three different implementation profiles concurrently:
1. A client or server that negotiates EMS when available, but continues
to be compatible with legacy peers, resumption and all.
2. A client or server that negotiates EMS when available, continues to
be compatible with legacy peers, but only allows full handshakes with
them. I forget how 3SHAKE worked, but I vaguely recall that cutting out
legacy resumptions avoided a source of issues
3. A client or server that requires EMS on all connections, and is not
compatible with legacy peers at all. This way you can rely on the EMS
bugfix being applied.

Because these are all interleaved, it's a very hard to tell what bits
correspond to this profile and what bits correspond to EMS itself. I
think this was overambitious. Anything but (1) was implausible for most
deployments in 2016, because EMS only just started existing. I expect it
is still implausible for most, though I don't have metrics for the web.
Hence, if we were completely redoing this document (probably not worth
it?), I think it should be reorganized. :-)

Now, as to your question, I don't believe this is right:

 > If the client follows this guide, it falls-back to use a full handshake.
 > If the client doesn't follow this (maybe, the client is not aware of RFC
 > 7627), the server SHOULD aborts.

The client SHOULD you are referring to is for a client that implements
(2). If a client does not follow this, it implements (1). The server
SHOULD, however, says "If neither the original session /nor the new
ClientHello/ uses the extension, the server SHOULD abort the handshake."
That clause doesn't apply to the client SHOULD in the first place
because, whether the client is (1) or (2), the ClientHello will signal EMS.

It does apply to legacy clients that do not implement EMS at all.
Whether the server continues, does a full handshake, or aborts depends
on whether the server wants to do (1), (2), or (3). Yes, if it picks (3)
and aborts, the server will not interoperate with a legacy client. That
is exactly what those servers would want. It is odd that the text only
describes (1) and (3) for the server in this case, not (2). But adding
(2) in without a rework will only make this complicated situation worse,
so I do not propose to address it as part of this fix.

On Tue, Oct 26, 2021 at 1:05 AM Achim Kraus mailto:achimkr...@gmx.net>> wrote:

Hi David,

if you're on it, maybe it's worth to consider my question from January
2021 as well.

  > If the client follows this guide, it falls-back to use a full
handshake.
  > If the client doesn't follow this (maybe, the client is not
aware of RFC
7627), the server SHOULD aborts.

  > Why SHOULD the server not (also) just fall-back to use a full
handshake?

For more details see:

https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/
<https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/>

best regards
Achim Kraus

Am 26.10.21 um 00:51 schrieb David Benjamin:
 > Here's some possible replacement text for that paragraph:
 >
 > """
 > In some deployments, a legacy client or server may be exposed to a
 > session using extended master secret. For example, a group of servers
 > sharing a ticket encryption key may be in the process of enabling
this
 > extension. If such a session is used in an abbreviated handshake
without
 > the extension, a newer peer will fail the connection, as described in
 > Section 5.3. To avoid this, legacy servers SHOULD ignore such
sessions
 > and continue with a full handshake, and legacy clients SHOULD NOT
offer
 > such sessions in the ClientHello.
 >
 > This can be implemented by ensuring legacy implementations do not
 > recognize sessions using extended master secret. For example, the
 > sessions may have a higher internal ve

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[Achim Kraus]

Hi David,

if you're on it, maybe it's worth to consider my question from January
2021 as well.

> If the client follows this guide, it falls-back to use a full handshake.
> If the client doesn't follow this (maybe, the client is not aware of RFC
7627), the server SHOULD aborts.

> Why SHOULD the server not (also) just fall-back to use a full handshake?

For more details see:

https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/

best regards
Achim Kraus

Am 26.10.21 um 00:51 schrieb David Benjamin:

Here's some possible replacement text for that paragraph:

"""
In some deployments, a legacy client or server may be exposed to a
session using extended master secret. For example, a group of servers
sharing a ticket encryption key may be in the process of enabling this
extension. If such a session is used in an abbreviated handshake without
the extension, a newer peer will fail the connection, as described in
Section 5.3. To avoid this, legacy servers SHOULD ignore such sessions
and continue with a full handshake, and legacy clients SHOULD NOT offer
such sessions in the ClientHello.

This can be implemented by ensuring legacy implementations do not
recognize sessions using extended master secret. For example, the
sessions may have a higher internal version number or, if the older
implementation rejects unrecognized fields, include a new field. If this
is not possible, deployments may deploy a new session cache or ticket
encryption key alongside the new version.
"""

Unfortunately, "session using extended master secret" is a bit of a
mouthful, but section 5.4 didn't define a more concise term.

On Mon, Oct 25, 2021 at 4:01 PM David Benjamin mailto:david...@chromium.org>> wrote:

Hi all,

In diagnosing an interop issue, I noticed RFC 7627 did not describe
the correct server behavior for EMS very well. Seemingly as a
result, some server implementation has gotten this wrong. I'd like
to fix this in the spec so this doesn't happen again. I think, at
minimum, we need to replace the last paragraph of section 5.4.

The issue is a server that /doesn't/ implement EMS, when presented a
ClientHello containing a ticket or session ID by a server that
/did/ implement EMS, must ignore the session and continue with a
full handshake. Failing to do so will trip the client check in
Section 5.3, "If a client receives a ServerHello that accepts an
abbreviated handshake, [...]". This is important to meet these three
properties:

- If the client and server both support EMS, the connection must
negotiate it.
- On resumption, the EMS status of the connection must match the EMS
status of the session
- In order for EMS to be safely deployable, it must be possible to
roll EMS out gradually, or roll it back, without breaking
connections. This means a mixed pre-EMS and post-EMS server
deployment must work.

Note that, although this behavior is only visible at the pre-EMS
server (not directly in scope for this document), it is actually a
requirement on the post-EMS server. When the post-EMS server issues
a session, it must arrange for the pre-EMS server to ignore it. For
example, if the pre-EMS server rejects sessions with unparsable
fields (the safest option), the post-EMS server can add a new field
to the session state serialization. Failing that, it can bump some
internal version number. Another strategy is to rotate session
ticket keys alongside the version, but this can be tricky the way
deployments and software updates are often split.

There's an analogous, though less likely, client scenario that a
pre-EMS client must not offer a post-EMS session. Otherwise it will
run afoul of a server requirement. This can be relevant for clients
that serialize their session cache.

As far as I can tell, RFC 7627 does not specify any of this. The
first paragraph of section 5.4 talks about adding a flag, but
doesn't talk about how pre-EMS servers interact with that flag. The
last paragraph discusses this scenario, but says something very
strange, if not plain wrong:

    If the original session uses an extended master secret but the
    ClientHello or ServerHello in the abbreviated handshake does not
    include the extension, it MAY be safe to continue the abbreviated
    handshake since it is protected by the extended master secret of the
    original session.  This scenario may occur, for example, when a
    server that implements this extension establishes a session but the
    session is subsequently resumed at a different server that does not
    support the extension.  Since such situations are unusual and likely
    to be the result of transient or inadvertent misconfigurations, this
    document recommends that the client and server MUST abort such
 

Re: [TLS] DTLS RRC and heartbeat

[Achim Kraus]

Hi Mohit,

Am 21.10.21 um 16:40 schrieb Mohit Sahni:

Just want to highlight one more issue with using the original extension,
many network security devices have threat signatures to identify the
heartbeat extension in packet streams and they will block the sessions
that match the signatures.



that sounds as a good reason, to ask for a new code-point.

best regards
Achim Kraus

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

Re: [TLS] DTLS RRC and heartbeat

[Achim Kraus]

Hi Hanno,

thanks for your feedback.

> I feel this may be enough justification to define a hearbeat-simplified
> spec that doesn't have these problems.

The point with that would be, that it requires a new code-point for the
content-type
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

And we are not sure, if considering mainly implementation issues, will
justify to allocate a new code-point.

best regards
Achim Kraus

Am 21.10.21 um 16:30 schrieb Hanno Böck:

On Thu, 21 Oct 2021 10:35:54 +0100
Thomas Fossati  wrote:


One problem is - as Hannes put it - that heartbeat has a "somewhat
tricky history", making its marketing a slightly intricate operation,
and the code reuse story a bit more complicated than desired (see for
example [3]).


I think there were a few things that went spectacularly wrong with the
original heartbeat extension. Some of them are implementation issues
(like merging code without proper review and testing), but others are in
the spec itself.

I think this boils down to two things that added unnecessary
complexity, which is always bad in security:
1. The use cases were all UDP, but the extension was defined for both
UDP and TCP for no good reason.
2. The extension contained a completely unnecessary length-encoded
message that was sent forth and back. That's a very risky
construction in terms of memory safety.

I feel this may be enough justification to define a hearbeat-simplified
spec that doesn't have these problems.
If you decide to go with the old heartbeat extension then I'd still
wish you at least adress 1. I think many people have just compiled
openssl without heartbeat, which is a good thing as long as it's not
used anyway. If it gets used in DTLS then at least make sure that
doesn't mean it also has to be enabled in TCP-based normal TLS at the
same time.



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

[TLS] (TLS) RFC5246 - 7.2.1. Closure Alerts - Applied to (DTLS) RFC 6347

[Achim Kraus]

Hi List,

I currently try to get some clarity about usage of DTLS 1.2.

One topic, which comes across, is the

(TLS) RFC5246 - 7.2.1.  Closure Alerts:

> The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack.

AFAIK, the protection of the "close_notify" is build on the grants of
TCP. On receiving the "close_notify" in the TLS layer, TCP ensures that
all data before was also passed to TLS. If something would be missing,
the "close_notify" will not be passed to TLS.
(e.g.
https://www.usenix.org/system/files/conference/woot13/woot13-smyth.pdf)

Applying this mechanism to DTLS and UDP, seems for me breaking that
protection. UDP doesn't grant the order nor the completeness and so the
"close_notify" mechanism stops working.

So, are there considerations, if/how a "close_notify" can provide that
protection for DTLS as it does for TLS?
It's not about to protect DTLS in general against message loss (for me,
that must be addressed in the layers above), it's about, how a
"close_notify" can provide that protection, or not.

I found:
https://mailarchive.ietf.org/arch/msg/tls/VNrSd7gv7uFjJNZH6frBt5lb57A/
https://mailarchive.ietf.org/arch/msg/tls/FJM6OHfvLJP_pF5uUcR86pzrdYo/

But I miss a explicit statement about the "truncation attack".
Or is that too obvious?

best regards
Achim Kraus

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

[Achim Kraus]

Hi Martin,



Nothing here depends on using a CID, except perhaps to the extent that the endpoint that 
observes the "migration" needs to be able to match incoming records with 
connection state.  If they need a CID for that, then this needs a CID.


If the threat is only weakly related to the use of a CID, would then the
discussion of that more general threats not require also a more general
scope than that of this DTLS CID RFC?


5. Victim believes that the connection has migrated and stops sending on the 
old path.

If the new address is attacker controlled, the attacker is now on-path.  The 
attacker can stop forwarding and deny service at its discretion.


For a "service deny" no attacker is needed :-), UDP traffic may be lost,
DTLS traffic may be ignored, and overloaded peers may response out of
the expected time-frame.

Most of that is in my opinion the general risk using something as the
"public internet" with its grants and no-grants.

In all cases of a "service-deny", the peer was, and with CID, is still,
intended to try a reconnect strategy (what ever that means according the
destination ip-address.)

In my sum:
- without CID, much more (resumption) handshakes are needed in order to
communicate using DTLS.
- with CID, such (resumption) handshakes are still required, but much less.

Your attack adds some more handshakes, but it doesn't introduce
something new, nor do I see, that this will exceed the number of
handshakes without CID.

best regards
Achim Kraus

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

[Achim Kraus]

Hi Martin,

> The attack here is fairly simple: an attacker gets a valid packet and
rewrites the source address (to an address it controls).  If that packet
is accepted by the endpoint that receives it, then it will probe toward
the attacker.  The attacker needs to rewrite the source address on the
packet it receives so that it elicits a genuine response from the peer.
Then the attacker captures the response and rewrites the source address.

For me, this requires, that cid is used in both directions. If not, the
"elicits" doesn't work, or? If both parties are using CID in order to
signal, that the addresses are changing, my feeling is, this scenario is
not that common. (Even more, it will have anyway troubles, with or
without CID.)

> With this, if the attacker can observe two dropped packets (or cause
them to be dropped somehow).  The first probably has to precede a quiet
period that is long enough to complete the process; the latter needs to
contain a probe response.  If those conditions can be met, then the
attack can place itself on-path.

"With this" and a "setup, where both peer's addresses will change
dynamically", 

In my experience, one peer uses a fixed ip-address, while the other one
uses a temporary/dynamic assigned one. Yes, the RFC supports that both
peers are using CID. FMPOV, that's more about that the CID principals
maybe used for both directions (with the risk you point), than that
there are real worlds use-cases on a "both sides dynamic".

> Without a probe on the original path, the attacker doesn't have to
provide a better route than the original.  Adding that probe means that
the attacker has to provide a faster and more consistent service, which
looks more like a net gain than an attack.

I see, that in cases, where both sides uses cid and dynamic addresse,
there maybe that manipulation. But, I can't see the attack. Maybe I
oversee something. If the "on path attacker" is installed and that
attacker changes the source of the traffic again in order to attack an
other victim peer, the probe will again protect the victim's new source
from being DDoS'ed.
So, please be more explizit, what the resulting attack would look like?

best regards
Achim Kraus


Am 05.05.21 um 04:45 schrieb Martin Thomson:

I can't claim credit for all of the jankiness in QUIC regarding on-path, 
off-path, and friends.

The attack here is fairly simple: an attacker gets a valid packet and rewrites 
the source address (to an address it controls).  If that packet is accepted by 
the endpoint that receives it, then it will probe toward the attacker.  The 
attacker needs to rewrite the source address on the packet it receives so that 
it elicits a genuine response from the peer.  Then the attacker captures the 
response and rewrites the source address.

With this, if the attacker can observe two dropped packets (or cause them to be 
dropped somehow).  The first probably has to precede a quiet period that is 
long enough to complete the process; the latter needs to contain a probe 
response.  If those conditions can be met, then the attack can place itself 
on-path.

Without a probe on the original path, the attacker doesn't have to provide a 
better route than the original.  Adding that probe means that the attacker has 
to provide a faster and more consistent service, which looks more like a net 
gain than an attack.

On Wed, May 5, 2021, at 01:49, Martin Duke wrote:

Hannes,

What you might be missing is that Martin Thomson chose what to me is an
unintuitive definition of off-path attacker. On-path means that you a
router that you can drop a packet. An off-path attacker might be an
observer, which can see the packets, or not. I hope that clears things
up a little bit -- although this is very hard to reason about.


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


I would argue it needs to only observe from the client (the one
allegedly changing address) to server.


* replay the packets in such a way that they arrive faster than the original 
packets send by the DTLS endpoints, and


This is the hardest part. The most plausible way is to purchase a
higher SLA from the service provider than the victim traffic.


* re-write both source and destination IP address to appear like a NAT for both 
endpoints.


No, it just needs to rewrite the source address of client->server packets.

Your second and third capabilities would actually defeat the "probe the
original address" countermeasure provided in the draft.

So yes, if the "attacker" is actually a router providing a superior
route to the host, there's nothing you can do.

But the required capabilities are the same for (1) pretending there is
a NAT rebinding where there isn't, and (2) pretending there isn't one
where there is. In both cases, one h

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

[Achim Kraus]

Hello Sean,
Hello List,

FMPOV, that dtls-rrc work is very welcome!
All use-cases, where the northbound-layers don't provide solutions for
that, will benefit from it.

best regards
Achim Kraus

Am 03.05.21 um 17:44 schrieb Sean Turner:

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



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

[Achim Kraus]

Hi Francesca,

> Then I guess 53 will become unassigned, no need to reserve it, right?

After a "reserved period", yes.
If that value is then assigned for TLS or DTLS 1.3 only, then that
period may be very short. If that value is assigned also for DTLS 1.2
(again), I would prefer a longer "reserved period", e.g. 12 months.
(That's just my personal preference.)

Best regards
Achim Kraus

Am 21.04.21 um 10:29 schrieb Francesca Palombini:

Hi Hannes, Achim,

Thanks, that's all I was curious about! No need to add that to the IANA 
considerations, this was more of a question on my side. Then I guess 53 will 
become unassigned, no need to reserve it, right?

Thomas: thanks for creating the issue - I will track there.

Francesca

On 21/04/2021, 08:00, "Hannes Tschofenig"  wrote:

 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



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

[Achim Kraus]

HI John,

Am 21.04.21 um 00:42 schrieb John Scudder:


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? That
might be worth saying, if so.



Yes, see
https://github.com/tlswg/dtls-conn-id/issues/103#issuecomment-822306643

best regards
Achim Kraus

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

[Achim Kraus]

Hello Francesca,

> 5. -
>
> Section 10.2
>
> FP: Just checking - why is 53 "incompatible with this document"?

The 53 was is used with the MAC definition of the previous version 06 of
this draft. Though the MAC has been adapted, using a different extension
number makes it easier to migrate existing deployments to that new MAC.
At least for Eclipse/Californium I know, that is used with 53 and the
old MAC.

best regards
Achim Kraus

Am 20.04.21 um 18:22 schrieb Francesca Palombini via Datatracker:

Francesca Palombini 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:
--

Thank you for the work on this document. I only have minor comments and nits
below.

Francesca

1. -

sending messages to the client.  A zero-length CID value indicates
that the client is prepared to send with a CID but does not wish the
server to use one when sending.

...

to use when sending messages towards it.  A zero-length value
indicates that the server will send with the client's CID but does
not wish the client to include a CID.

FP: clarification question: I am not sure the following formulation is very
clear to me: "to send with a(/the client's) CID". Could "send with" be
rephrased to clarify? The previous paragraph uses "using a CID value", that
would be better IMO.

2. -

the record format defined in {{dtls-ciphertext} with the new MAC

FP: nit - missing "}" in markdown.

3. -

The following MAC algorithm applies to block ciphers that use the
with Encrypt-then-MAC processing described in [RFC7366].

FP: remove "with"

4. -

Section 10.1

FP: I believe you should specify 1. what allowed values are for this column
(i.e. Y or N, and what they mean) and 2. what happens to the existing entries -
namely that they all get "N" value.

5. -

Section 10.2

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

6. -

Value   Extension Name  TLS 1.3  DTLS Only  Recommended  Reference

FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1



___
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] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Achim Kraus]

Hello Éric,

> This specification addresses the IPv4-mainly issue of NAT binding and
is still required.

Yes, that is the main initial trigger.
It helps also for peers, which use only temporary assigned IP-addresses
which may change (e.g during a power-saving-sleep-wake-up cycle in some
CAT-NB solutions). And there are also some advanced use-cases, e.g. CID
based load-balancer.

For your other points, Thomas created an issue on github
(https://github.com/tlswg/dtls-conn-id/issues/103). I left some comments
there.

best regards
Achim Kraus

Am 19.04.21 um 09:47 schrieb Éric Vyncke via Datatracker:

Éric Vyncke 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:
--

Thank you for the work put into this document. This specification addresses the
IPv4-mainly issue of NAT binding and is still required. I am also trusted the
security ADs for section 5.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As an important part of this document is the padding, should it be mentioned
also in the abstract ?

-- Section 3 --
While I am not a DTLS expert, I find this section quite difficult to understand
the reasoning behind the specification as little explanations are given about,
e.g, what is the motivation of "A zero-length value indicates that the server
will send with the client's CID but does not wish the client to include a CID."

-- Section 6 --
I am puzzled by the text:
  "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."
Does this mean that there is no way to update the peer IP address ?

== NITS ==

-- Section 1 --
Please expand CID on first use outside of the abstract.

-- Section 4 --
Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks
like figure 3 belongs to the 'zeros' field description.



___
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] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard

[Achim Kraus]

Hi Tom,

> I think that I cannot make sense of that 'alternately'.  The subsequent
> paragraphs seem to rule it out as an option.  On a first read I thought
> that a zero length CID was a valid option for Application Data and
> wanted to know which form of header and MAC was appropriate but my
> understanding of the later paragraphs became that a zero length CID can
> only appear in Hello; but I do think that this needs fixing.
>
> I did track the WG discussion last October and did not see anything very
> clear then.

That was a discussion in 2019, see
https://github.com/tlswg/dtls-conn-id/issues/43 and follow the refered PRs.

The outcome:
If the CID is empty, RFC6347 record format is used. That's equivalent to
"empty CID is only used in the extensions of the Hellos".

Best regards
Achim Kraus

Am 12.03.21 um 18:28 schrieb tom petch:


On 12/03/2021 16:18, Achim Kraus wrote:

Hi Tom, Hannes, Thomas,

"A zero-length value indicates that the server will send with the
client's CID but does not wish the client to include a CID (or again,
alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that only
to negate the use of tls_cid record. It may be more straight forward, if
the use of a "zero-length CID" is limited to the ClientHello and the
ServerHello extensions. And later the use of a tls_cid record is then
only for negotiated non-empty CID.

WDYT?


I think that I cannot make sense of that 'alternately'.  The subsequent
paragraphs seem to rule it out as an option.  On a first read I thought
that a zero length CID was a valid option for Application Data and
wanted to know which form of header and MAC was appropriate but my
understanding of the later paragraphs became that a zero length CID can
only appear in Hello; but I do think that this needs fixing.

I did track the WG discussion last October and did not see anything very
clear then.

Tom Petch



best regards
Achim Kraus


Am 12.03.21 um 12:58 schrieb 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, d

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

[Achim Kraus]

Hi Tom, Hannes, Thomas,

"A zero-length value indicates that the server will send with the
client's CID but does not wish the client to include a CID (or again,
alternately, to use a zero-length CID)."

My feeling is, the text in the paragraphs following that seems to
introduce first the idea of a "zero-length CID", and later use that only
to negate the use of tls_cid record. It may be more straight forward, if
the use of a "zero-length CID" is limited to the ClientHello and the
ServerHello extensions. And later the use of a tls_cid record is then
only for negotiated non-empty CID.

WDYT?

best regards
Achim Kraus


Am 12.03.21 um 12:58 schrieb 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

[TLS] RFC7627 - 5.3 - inconsistent behavior of client and server?

[Achim Kraus]

Dear List,

according

https://tools.ietf.org/html/rfc7627#section-5.3

5.3 Client and Server Behavior: Abbreviated Handshake

"The client SHOULD NOT offer an abbreviated handshake to resume a
session that does not use an extended master secret.  Instead, it
SHOULD offer a full handshake."
...
"If neither the original session nor the new ClientHello uses the
extension, the server SHOULD abort the handshake.  If it continues
with an abbreviated handshake in order to support legacy insecure
resumption, the connection is no longer protected by the
mechanisms in this document, and the server should follow the
guidelines in Section 5.4."

If the original session doesn't use an extended master secret:
- the client SHOULD offer a full handshake.
- the server SHOULD abort

If the client follows this guide, it falls-back to use a full handshake.
If the client doesn't follow this (maybe, the client is not aware of RFC
7627), the server SHOULD aborts.

Why SHOULD the server not (also) just fall-back to use a full handshake?

best regards
Achim Kraus

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

[TLS] RFC 6347 - Section 4.2.1 - used version in a HelloVerifyRequest

[Achim Kraus]

Dear list,

according https://tools.ietf.org/html/rfc6347#section-4.2.1

"The server_version field ...
DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless
of the version of TLS that is expected to be negotiated. ...
The server MUST use the same version number in the HelloVerifyRequest
that it would use when sending a ServerHello. ...
"

For me that seems to be ambiguous.

I checked two other implementations (openssl sends 1.0, mbedtls send
1.2) and it seems to be not clear there as well.

So, which version should a "DTLS 1.2 only server" send in its
HelloVerifyRequest?

best regrads
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,

Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:

On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:

Hi Ekr,


As for EtM

Encrypt-then-MAC:
struct {
    uint8 marker = tls12_cid;
    uint8 cid_len;
    uint8 content_type = tls12_cid;      \
    uint16 DTLSCiphertext.version;       |  appears on wire
    uint64 seq_num; // includes epoch    |
    opaque cid[cid_len];                 /
    uint16 iv_length;
    opaque IV[iv_length];
    uint16 enc_content_length;
    opaque enc_content[enc_content_length];
};



I failed to understand the reasons behind this proposal.

1. Why should the "marker" be added, if the "content_type" is already in
the MAC, and this special MAC is only applied for tls12_cid records.
What is the intended benefit of that?


This is another general hygiene item; we are preserving the invariant that
the first byte of the MAC input is the content type -- this is at present
(IIRC) invariant across all TLS versions and MtE/EtM, and not something to
change lightly.


"All TLS versions"?

TLS 1.2, RFC 5246

https://tools.ietf.org/html/rfc5246#section-6.2.3.1

The MAC is generated as:

  MAC(MAC_write_key, seq_num +
TLSCompressed.type +
TLSCompressed.version +
TLSCompressed.length +
TLSCompressed.fragment);


https://tools.ietf.org/html/rfc5246#section-6.2.3.3

The additional authenticated data, which we denote as
   additional_data, is defined as follows:

  additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;


So, as far as I see, at least the TLS 1.2 variant doesn't do that.
RFC6347 doesn't change that, so DTLS 1.2 also doesn't do that.

Maybe you precise the "all" to a set of versions to make it easier to
check it?

best regards
Achim

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Peter,

thanks!

> It precedes the IV, i.e. the field that it describes.

In other contributions, it's said, that it is also important to keep the
header bytes as they are. With that, the "iv_length" should be ahead
before the header bytes starts.

And I'm still curious about the "uint16" instead of "uint8".

I'm looking forward, when this will get finished :-).

best regards
Achim Kraus


Am 30.10.20 um 13:39 schrieb Peter Gutmann:

Achim Kraus  writes:


2. Why should a "uint16 iv_length" be added?


To make it explicit which of the bits being hashed is the IV.  This is one of
the flaws of things like OAEP, there are a large number of implicitly-sized
fields controlled by external, unauthenticated parameters, so you can make the
verifier see fields as other, nearby fields (I'm using OAEP as an example
because it's particularly bad, there are so many optional values controlled by
external unauthenticated data that you can have all sorts of fun with it).


2.b If it should be added, why in the middle? It's not on the wire and so I
would assume, if at all, to have that at the begin.


It precedes the IV, i.e. the field that it describes.

Peter.




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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ekr,


As for EtM

Encrypt-then-MAC:
struct {
   uint8 marker = tls12_cid;
   uint8 cid_len;
   uint8 content_type = tls12_cid;      \
   uint16 DTLSCiphertext.version;       |  appears on wire
   uint64 seq_num; // includes epoch    |
   opaque cid[cid_len];                 /
   uint16 iv_length;
   opaque IV[iv_length];
   uint16 enc_content_length;
   opaque enc_content[enc_content_length];
};



I failed to understand the reasons behind this proposal.

1. Why should the "marker" be added, if the "content_type" is already in
the MAC, and this special MAC is only applied for tls12_cid records.
What is the intended benefit of that?

2. Why should a "uint16 iv_length" be added?
2.a If it should be added, why as "uint16" instead of "uint8"
2.b If it should be added, why in the middle? It's not on the wire and
so I would assume, if at all, to have that at the begin.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,

at least at your point (from the e-mail before)

> and not have to change it again.

I agree :-).

That will naturally become true, if the RFC gets released.

best regards
Achim



Am 26.10.20 um 17:56 schrieb Benjamin Kaduk:

Hi Achim,

On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:

Hi Ben,


 Because each party sends the value in the "connection_id" extension
 it wants to receive as a CID in encrypted records, it is possible for
 an endpoint to use a globally constant length for such connection
 identifiers.  This can in turn ease parsing and connection lookup,
 for example by having the length in question be a compile-time
 constant.  Implementations, which want to use variable-length CIDs,
 are responsible for constructing the CID in such a way that its
 length can be determined on reception.  Such implementations must
 still be able to send CIDs of different length to other parties.
 Note that there is no CID length information included in the record
 itself.


...and thanks for the reminder about how we say so in the text already.


(your example from a previous e-mail)

  > Attempting to construct a trivial example on the fly, (hex)

  > 01 01 02 02 01 <513 bytes of plaintext content>

  > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
  > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
  > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
  > DTLSInnerPlaintext.content = <513 bytes>.

I would feel much more comfortable, if you state,
that you consider now either

1. that example was not compliant to the draft,

or

2. the draft is not clear enough about that.

If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
closed.


It is neither of those two.

While the party that will be parsing packets that use a given CID value to
identify the connection needs to be able to determine the length from the
byte stream, the other party does not.  Accordingly, when computing the
MAC, there is still malleability in terms of which "interpretation" of the
byte stream was intended by the party computing the MAC.  The party
receiving the packet (and MAC) will only use one interpretation, but the
party generating the MAC could have been deceived into using the other
interpretation.

As I said previously, the CID values are not authenticated until the
handshake completes, so there is a real window where this attack surface is
exposed.  Note that I do not need to present a complete end-to-end attack
that breaks the TLS guarantees in order for us to change the spec -- it is
enough to have shown that the malleability of the cryptographic input
stream is exposed to potential attack.  To leave such behavior in a
published protocol spec would be irresponsible, in effect, publishing an
algorithm with known weaknesses.

Thanks,

Ben



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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


Because each party sends the value in the "connection_id" extension
it wants to receive as a CID in encrypted records, it is possible for
an endpoint to use a globally constant length for such connection
identifiers.  This can in turn ease parsing and connection lookup,
for example by having the length in question be a compile-time
constant.  Implementations, which want to use variable-length CIDs,
are responsible for constructing the CID in such a way that its
length can be determined on reception.  Such implementations must
still be able to send CIDs of different length to other parties.
Note that there is no CID length information included in the record
itself.


...and thanks for the reminder about how we say so in the text already.


(your example from a previous e-mail)

> Attempting to construct a trivial example on the fly, (hex)

> 01 01 02 02 01 <513 bytes of plaintext content>

> could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
> DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
> cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
> DTLSInnerPlaintext.content = <513 bytes>.

I would feel much more comfortable, if you state,
that you consider now either

1. that example was not compliant to the draft,

or

2. the draft is not clear enough about that.

If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
closed.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


The attack does not require that both are valid for the same peer at the
same time -- the attack can still occur when the party producing the MAC is
induced to use the "wrong" (invalid CID) interpretation of the byte stream
but then the version with valid CID is presented to the party verifying the
MAC.


Though I consider the CID mainly as lookup-key for the security context,
including the MAC_write_key for Block Ciphers or the write_key /
write_IV for AEAD Ciphers provides in almost all casses the protection,
not the cid in the MAC. The only exclusion would be, if two different
cids point to the same security context. With a injective cid encoding,
that is mitigated.

As far as I understand your description:

1. The (server) peer 1 used cid "abcd" for it's encryption context.

2. An attacker modifies that cid "abcd" into a different cid (any
assumptions about that? Should it be "abcd12"? Or "ef3456"? Or no
special consideration?)

3. Then the other peer 2 uses the modified cid to place it into the
FINISH record and to calculate the MAC for that. The used security
context on peer 2 is NOT defined by that modified CID, it's defined by
peer 1's 5-tupel (according draft-ietf-tls-dtls-connection-id-07).

4. Now peer 1 will use the modified cid to
4.a. lookup the security context. What is assumed as result here?
4.b. calculated the MAC using the security context and modified cid

In my opinion, the MAC verfication generally fails, if at least one
input is different. So either a different security context or a
different cid will fail the MAC verification.

Though you say, that not both cids need to be valid for peer 1, the
consequence for me is, that peer 1 knows only the unmodified cid, but
not the modified cid. With that, peer 1 doesn't even have a security
context to calculate the MAC with.

It's totally mystic to me, what you assume as attack.

I guess, you adapt now your example. If so, would it be possible, that
you try to follow the above steps and show, where you deviate?


If the internal structure (including length encoding) of the CID is
opaque to the party producing the MAC, that party cannot validate the data
used as input to the MAC.

(Sorry for duplicating this previous paragraph here and on the github
issue.)



From the github issue:

> In short, you asked me to show how having a cid-length (in a different
> position than currently) will prevent an attack: the attack in
> question occurs when the client is generating a (its first) MAC, not
> at the time when the MAC is validated.

I still fail to follow your description, even with that amend.
Would it be possible, to get more information about an attack applied on
the generation of a MAC (above in step 3)? Or does the effect occur in
an other step (maybe 4)? Which effect should be considered?

Maybe, someone else has also an opinion about that attack or the
description.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:

- include in the MAC as much application/protocol context and protocol
   fields as you can without breaking operation of the procotol
- ensure that the mapping from (set of protocol fields and values derived
   from application context) to (bytes given as input to the MAC function) is
   an injective mapping

In some (many?) cases, there is not any additional contextual information
available, and the protocol header itself has a deterministic/fixed-length
encoding, so both points can be achieved by just using the protocol
header/payload as it appears on the wire as MAC input.  For better or for
worse, the current construction in the -07 diverges significantly from the
actual protocol header, so we have to do a bit of thinking to ensure that
we are compliant to the guidelines (that I just described, so I assume you
did not previously think about them in that formulation).



Hope, I'm not again catched by my bad english :-):

If the forumlation refers to draft-ietf-tls-dtls-connection-id-07 (and
not my e-mails), I can't say, what was thought or not by the authors. My
role in that discussion quite a year ago, was just to ask, which of the
many variants should then be chosen in order not to change it every year.

That's also the main thing, which drives me to this endless discussion.
If it changes again, try to change it that last time.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,




Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try out the MAC for both "different
MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
the receiver will not know by the failing MAC, which interpretation is
the right. I guess, this will end up in decrypt twice, also obvious time
signal.)


Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.



My concerns are based on permit ambiguous CIDs.

> Attempting to construct a trivial example on the fly, (hex)

> 01 01 02 02 01 <513 bytes of plaintext content>

> could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
> DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
> cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
> DTLSInnerPlaintext.content = <513 bytes>.

That results in my opinion in cid 01 and cid 01 01 being valid for the
same peer and same time.

or

> - Application record on CID 63 containing 04 00 02 FF, or
> - Application record on CID 63 01 00 05 containing FF.

being valid for the same peer and same time.

That seems to be the precondition for the threats. Permitting such
ambiguous CIDs may be then the root cause for such a "time side channel".

With the reference from Antoine (https://eprint.iacr.org/2020/114.pdf,
Section III.D), I started to consider the encoding of a "variable length
CID" to be the real spot. That points for me to the same direction, it's
that encoding not the position of the cid-lenght.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Dear Antoine,

thanks for adding the references.

I tried to understand https://eprint.iacr.org/2020/114.pdf (Section
III.D). But to be frank, as developer, it's extremley hard not to
misunderstand, what is documented there.

For me, this seems like in QUIC, the length of the CID is encoded in the
sent message (so it's on the wire).

For draft-ietf-tls-dtls-connection-id-07, at least as far as I
understood it, there are two general possiblities:

- a peer chose to emit only CID with the same static length. In that
case, the cid-length will always be the same (cid-length is not on the
wire). It can't be injected, except someone injects the execute programm
code itself.

- a peer chose to emit CIDs with variable length. In the case the other
peer is intended just to add that received CID in the hello extension to
the dtls-records. The emitting peer has to chose a encoding for such CID
with variable length, that the emitting peer is able to decode it. In
this case the cid-length is on the wire, but the encoding is not
specified in draft-ietf-tls-dtls-connection-id-07. In my opinion it's
extremely important, to chose a encoding, which could not be interpreted
in different ways (I guess, that's what Watson ment by "injective").

With these both options, FMPOV, to add explicit someting as the
cid-length to the MAC is not required. It's either the same static
value, or must be already encoded in the CID itself, which is already in
the MAC. But it may be required, to add constraints about such a
encoding for variable length CIDs to the draft.

The confusion may be mainly caused by the idea, to support both, static
length CID and variable length CIDs. That misleads to build examples,
assming that two CID may be used, where one CID is the start of the
other. In my opinion, that's a problem of the encoding of the variable
length CID, but not the MAC.

best regards
Achim Kraus


Am 11.10.20 um 22:53 schrieb anto...@delignat-lavaud.fr:

Dear Watson,

I object to your comment about formal models of TLS not capturing wire encoding 
issues. miTLS does in fact formally specify the format of all messages on the 
wire to the bit.
In fact this is complex enough that we have a full paper just about the subject 
that will tell you more or less everything that was said in this thread
http://antoine.delignat-lavaud.fr/doc/usenix19.pdf - 
https://github.com/project-everest/mitls-fstar/blob/dev/src/parsers/Parsers.rfc 
is the formal TLS message format specification including the demonstrably 
unsafe constructions (implicit tags on server key exchange in 1.2 and 
CertificateEntry in TLS 1.3).

In the specific context of connection ID, QUIC up to draft 16 did suffer from 
an attack caused by the lack of encoding of the CID length. The attack is 
caused by the concatenation of two variable length fields in the network format 
(the CID and the packet number) that can both be tampered by an active 
attacker. The boundary of the concatenation is made ambiguous to the crypto 
authentication (AAD of packet content encryption) by QUIC header protection, 
which is applied before decryption. See https://eprint.iacr.org/2020/114.pdf 
(Section III.D) for a description of the attack. See 
https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fsti
 and 
https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fst
  for the formal proof that the QUIC varint encoding with minimal length 
representation satisfies the strong prefix property.

Antoine

-Original Message-
From: TLS  On Behalf Of Watson Ladd
Sent: dimanche 11 octobre 2020 08:50
To: Achim Kraus 
Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls@ietf.org; Benjamin Kaduk 

Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus  wrote:


Hi Joe,

  > [Joe]  It's unfortunate to find issues that require breaking change
at  > the end of the review cycle, especially for a draft that has taken a
  > long path to get here.   If there is an issue that is exploitable, even
  > in a corner case, someone will develop an attack, clever name, logo and
  > website and we will all have to scramble to deploy a fix.   It's better
  > to fix now rather than later.

Agreed, therefore I wrote at the begin of the discussion with Ben:

  >> I would prefer, if this is not changed again without strong  >>
arguments!

  > In this case, I don't have a way to  > exploit this issue, but
unless someone has a way to demonstrate that  > this is not going to
be an issue then I believe it is prudent to fix it  > now.
  >

In my opinion, ONE change may be possible. A server may be configured
to use only the old, only the new, or both by "try on the client's finish".
I'm not happy with such "dirty" work-around. I would prefer to do so
for something more the "cryptographic hygiene".

So, if the MAC is 

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Wadson,

my bad, I mislead in understanding "injective".
It's not related to "injection".

best regards
Achim Kraus



Hi Wadson,


The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective.


I hope, this is just a "typo" or "mistake".

Prepending the length is the change, Ben want to use to protect against
injection. You now say, this will be "obviously injective".


Here though it isn't clear if two different inputs to the
encoding could end up the same.


Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
all examples so far are just incomplete. They must declare, if the
"different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.

"different MAC_write_key" => obviously "end up" different.
"same MAC_write_key" => the decoding of the records gets ambiguous


In fact I think in the MAC setting
there almost certainly is a problem as the length of the ciphertext is
right after the cid length, and with some cleverness you can come up
with a cid and ciphertext that could be interpreted multiple ways.
Unfortunately I haven't followed the draft's discussions that closely.

I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.


That's just a theroretical numbers game. No one os far made any really
useful example from start to end. FMPOV, "CID with dynamic length" MUST
use a unique/deterministic encoding. If that encoding ambiguous, as
others imply/assume in their "numbers game", the whole record gets
ambiguous.

Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try out the MAC for both "different
MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
the receiver will not know by the failing MAC, which interpretation is
the right. I guess, this will end up in decrypt twice, also obvious time
signal.)

best regards
Achim Kraus

___
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] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi,


I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.



I created an issue on github to discus the requirements for encoding
variable length CIDs.

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

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ilari,


The problem is the follows:

Take the following input to the MAC (MtE case):

 19 FE FD 63 01 00 05 04 00 02 FF 17

There is no way to tell from that input if it is:

- Application record on CID 63 containing 04 00 02 FF, or
- Application record on CID 63 01 00 05 containing FF.



Maybe you check your example?

Does the 1. assume cid-length := 1?
And the 2. cid-length := 4?


The dtls-record will then contain:

(remove cid-length 01, cid-length is NOT encoded in the dtls-record!)

19 FE FD  63 00 05 04 00 02 FF 17

or

(remove cid-length 04)

19 FE FD  63 01 00 05 00 02 FF 17

For me this seems to be different input to the MAC, if the cid-length is
left out. My feeling is, your example proves my opinion, that it's
better to remove the cid-length from the MAC.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Wadson,


The doubt is because of where it appears not that it appears. If every
value was preceded by its length the encoding would obviously be
injective.


I hope, this is just a "typo" or "mistake".

Prepending the length is the change, Ben want to use to protect against
injection. You now say, this will be "obviously injective".


Here though it isn't clear if two different inputs to the
encoding could end up the same.


Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
all examples so far are just incomplete. They must declare, if the
"different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.

"different MAC_write_key" => obviously "end up" different.
"same MAC_write_key" => the decoding of the records gets ambiguous


In fact I think in the MAC setting
there almost certainly is a problem as the length of the ciphertext is
right after the cid length, and with some cleverness you can come up
with a cid and ciphertext that could be interpreted multiple ways.
Unfortunately I haven't followed the draft's discussions that closely.

I do not understand how a CID is supposed to be parsed by a recipient
when the length can change and the length field is not encoded, but
perhaps I'm misreading the intent of the [] notation in the record
layer of the draft.


That's just a theroretical numbers game. No one os far made any really
useful example from start to end. FMPOV, "CID with dynamic length" MUST
use a unique/deterministic encoding. If that encoding ambiguous, as
others imply/assume in their "numbers game", the whole record gets
ambiguous.

Just as forecast:
Without agreement, that the CIDs must be encoded using deterministic
interpretation, which in my opinion obsoletes these "number games",
next Summer either Raccoon or Kenny will write up their next
"time side channel attack" on this.
(The ambiguity will end up in try out the MAC for both "different
MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
the receiver will not know by the failing MAC, which interpretation is
the right. I guess, this will end up in decrypt twice, also obvious time
signal.)

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Joe,

> [Joe]  It's unfortunate to find issues that require breaking change at
> the end of the review cycle, especially for a draft that has taken a
> long path to get here.   If there is an issue that is exploitable, even
> in a corner case, someone will develop an attack, clever name, logo and
> website and we will all have to scramble to deploy a fix.   It's better
> to fix now rather than later.

Agreed, therefore I wrote at the begin of the discussion with Ben:

>> I would prefer, if this is not changed again without strong
>> arguments!

> In this case, I don't have a way to
> exploit this issue, but unless someone has a way to demonstrate that
> this is not going to be an issue then I believe it is prudent to fix it
> now.
>

In my opinion, ONE change may be possible. A server may be configured to
use only the old, only the new, or both by "try on the client's finish".
I'm not happy with such "dirty" work-around. I would prefer to do so for
something more the "cryptographic hygiene".

So, if the MAC is considered to be adpated again, should it not be
discussed, why at all the cid-length should be put in?
I asked this already in January 2019

https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915

The MAC contains already a overall length. Even in that discussion, no
one mentioned the reason for adding it. So if there a doubts about
injection, why not remove it at all?

> Would this issue have been caught by formal verification?

That may also be something to help, not to change still again and again.

best regards
Achim Kraus

Am 11.10.20 um 00:26 schrieb Joseph Salowey:



On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus mailto:achimkr...@gmx.net>> wrote:

Hi Ben,

 >
 > To be frank, I'm actually surprised that this is even seen as a
matter for
 > discussion.

As developer, I'm surprised, that this discussion now spans a couple of
years, starting on summer 2018 with:

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

There are many (proposed) changes since then. I already tried to point
to that with my e-mail answer from 4. September

  >> That order was also discussed a lot.
  >> https://github.com/tlswg/dtls-conn-id/pull/29
  >> I would prefer, if this is not changed again without strong
arguments!

For me, "cryptographic hygiene", which breaks the API, are not strong
arguments. Sure, that's only my personal opinion. I'm not sure, if a new
code-point helps, nor that a new one is emitted for changing a draft (I
would not recommend to do so, draft is a draft).

So let me try to find a end:
As developer, I see it's very important to come to a stable definition
of the MAC. If now the order of the cid/cid-length is changing the MAC
(again), and in half a year the next "cryptographic hygiene" campaign
removes the cid-length (because it's not on the header and some
(including me) don't see the benefit), then FMPOV this "process" just
demonstrates more weakness, than I appreciate.

So:
If there is a guideline for constructing MACs, is that guideline
documented somewhere?
If the guideline is changing over the time, are these changes
documented?

And I would really welcome, also based on the experience with the long
history of this discussion, if more can give their feedback about
changing the MAC again. Please, this year, not next :-).


[Joe]  It's unfortunate to find issues that require breaking change at
the end of the review cycle, especially for a draft that has taken a
long path to get here.   If there is an issue that is exploitable, even
in a corner case, someone will develop an attack, clever name, logo and
website and we will all have to scramble to deploy a fix.   It's better
to fix now rather than later.   In this case, I don't have a way to
exploit this issue, but unless someone has a way to demonstrate that
this is not going to be an issue then I believe it is prudent to fix it
now.

Would this issue have been caught by formal verification?

best regards
Achim Kraus

___
TLS mailing list
TLS@ietf.org <mailto: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] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Mike,

> in C:
>
>  if (complex_value_a = complex_value_b) {
>  // we're in trouble
>  }

That's a pitfall of C ('=' is not '=='). You will be almost in trouble,
if the complex value is not 0.

But the discussion here is more about how often somethings should be
adapted again and again. The point from Ben are all very valid, but they
should have been raised at least 1 year ago. Now, the point is, if
"cryptographic hygiene" without "actual threat" (at least, this was not
explained) should modify the MAC again. If so, the question may be, when
this changes will end.

best regards
Achim Kraus

Am 10.10.20 um 19:29 schrieb Michael D'Errico:

On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:

[...]  The behavior we should demand from our cryptographic
constructions is that the cryptography itself correctly returns
"valid" or "invalid" based on the input message, provided that
the application inputs the correct key material.  (It should also
return "invalid" if incorrect key material is supplied, of course.)
The ability to produce two different messages for which the
cryptography returns "valid" violates this principle; even if we
do not see an obvious path by which a reasonable application
might supply those inputs to the cryptographic code, it is still
a flawed construction.


Hi,

I'd like clarification about this point, where the cryptography
should return values of "valid" or "invalid".  This is a general
question, not specifically about this draft.  (Please read at
least the next 2 paragraphs.)

I remember a long time ago, it may have been the renegotiation
info extension, where there was a lot of calculation being done,
there were two complicated values each side had to compute.
If they were equal, then everything was fine and the handshake
could proceed.  If not, there was an insecure renegotiation
happening.  (Or maybe it was the downgrade protection RFC,
I can't remember now.)  But if the values were not equal, then
something bad was happening and the handshake should not
proceed.

The problem both Martin Rex and I discovered at nearly the
same time (posts to the mailing list within minutes of each
other) was that both sides could go through all the motions
faithfully calculating all of the values, correctly, and then
forget to compare them to see if the values were actually
the same.  I noticed this because I wrote the code, and it
seemed like an easy thing to overlook.

I remember suggesting that we somehow incorporate the
calculated values into the derivation of the record layer keys
so the MAC would fail, or maybe into the Finished message
calculation so (if you remember to check that?) a failure is
noticed later.  This suggestion was shot down by the author
unilaterally for what I perceived at the time to be petty
reasons.

I still believe that (D)TLS security should not rely on the
implementer to check whether two values are equal.  This
is too easy to forget to do.  Or you could do this in C:

 if (complex_value_a = complex_value_b) {
 // we're in trouble
 }

I have not looked at the TLS 1.3 draft beyond the hour or so
I've put in so far to see whether this reliance on checking is
in there too.  I've also not checked whether the security
proof I was referred to has any games where the implementer
forgot to compare values.  Or a game where everybody made
the same error and nobody noticed (forgetting to put the
HelloRetryRequest into the Tramscript-Hash for example).

Mike



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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,



To be frank, I'm actually surprised that this is even seen as a matter for
discussion.


As developer, I'm surprised, that this discussion now spans a couple of
years, starting on summer 2018 with:

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

There are many (proposed) changes since then. I already tried to point
to that with my e-mail answer from 4. September

>> That order was also discussed a lot.
>> https://github.com/tlswg/dtls-conn-id/pull/29
>> I would prefer, if this is not changed again without strong arguments!

For me, "cryptographic hygiene", which breaks the API, are not strong
arguments. Sure, that's only my personal opinion. I'm not sure, if a new
code-point helps, nor that a new one is emitted for changing a draft (I
would not recommend to do so, draft is a draft).

So let me try to find a end:
As developer, I see it's very important to come to a stable definition
of the MAC. If now the order of the cid/cid-length is changing the MAC
(again), and in half a year the next "cryptographic hygiene" campaign
removes the cid-length (because it's not on the header and some
(including me) don't see the benefit), then FMPOV this "process" just
demonstrates more weakness, than I appreciate.

So:
If there is a guideline for constructing MACs, is that guideline
documented somewhere?
If the guideline is changing over the time, are these changes documented?

And I would really welcome, also based on the experience with the long
history of this discussion, if more can give their feedback about
changing the MAC again. Please, this year, not next :-).

best regards
Achim Kraus

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

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


Let me add:

- If the scenario uses "dynamic 5-tuples, with CID or without" and
"static 5-tuples without CID",
- then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
pool) and CID (described in
https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
communication to such a static-5-tuple without CID.


Yes, I think this is the disruption I was pondering.


Even then, that "static-5-tuple" peers must be anyway aware, that
sometimes new handshakes are required. So that scenario may also depend
more on the volume of such attacks, than just on the pure possibility.


It does seem like a pretty rare/difficult attack, unlikely to be worth the
trouble.  But perhaps it is still worht documenting as a property of the
protocol ...



The point from my side was, that anyway, with or without that attack,
even clients with static-5-tuples must take care of their "encryption
association". If the client expects responses but didn't get them, then
a new handshake may be required. So, I'm not sure, if explicitly mention
that, really changes the game.


In my experience, such "static-5-tuples" are rare and I would guess,
they will benefit from different handling also for other reasons.
Therefore I would just spend them an separate endpoint to separate their
traffic.


... especially when we can give this recommendation as a workaround.
(Actually, is it generally a good idea to try to steer CID-ful and CID-less
traffic to different endpoints?)



If it's possible to use different endpoints, I think so.

best regards
Achim Kraus

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,

>> If that is going to be changed, the early adopters run into trouble with
>> their deployments!
>
> I'm not sure I follow.  Are you saying that if there is a theoretical
> problem with the construction it would have been exposed by
implementation
> testing?

No, I don't say that.
"Early adopters" means, there people using
draft-ietf-tls-dtls-connection-id-07 in real world systems with that
current definiton of the MAC. If that MAC calculation is changed, then
they need to adapt their deployments in the field, which is not too easy
(and potential dangerous). Sure, draft-ietf-tls-dtls-connection-id-07 is
still only a draft and could be changed. But not without trouble for
those "early adopters".

> My primary concern is not actually about a specific situation where
> injection occurs, but rather for cryptographic hygiene -- whenever we
> assemble an input for a cryptographic operation (especially MAC or
signing)
> it is important to ensure that the sequence of bits used as input to the
> cryptographic operation can only be produced by a single combination of
> logical inputs to the protocol-level operation or message that we are
> applying cryptographic protection to.  This property is known as
> "injectivity", because the map from protocol-level values to bitstrings
> (themselves used as input for cryptographic operations) is an injective
> mapping in the mathematical sense.  I believe that I have
demonstrated that
> the current MAC construction does not use an injective mapping and is
thus
> not consistent with best practices.

*** protocol-level operation or message ***

I understood your example in your previous mail.
I tried to explain, that the data of your example, especially the
cid-length, is not in the message. Please, find the time to check that
current record defintion! There the CID is encoded in the protocols
tls-cid-records without the explicit CID length.

With that, I can't see the posssiblity to inject the cid-length.
It's simply not "in" and so can't be "injected".

best regards
Achim Kraus

Am 09.10.20 um 01:34 schrieb Benjamin Kaduk:

Hi Achim,

Sorry for the long silence on this front; my attention had cycled elsewhere
and I was just overall operating slowly for a couple weeks (sick, maybe,
but no clear symptoms).

My primary concern is not actually about a specific situation where
injection occurs, but rather for cryptographic hygiene -- whenever we
assemble an input for a cryptographic operation (especially MAC or signing)
it is important to ensure that the sequence of bits used as input to the
cryptographic operation can only be produced by a single combination of
logical inputs to the protocol-level operation or message that we are
applying cryptographic protection to.  This property is known as
"injectivity", because the map from protocol-level values to bitstrings
(themselves used as input for cryptographic operations) is an injective
mapping in the mathematical sense.  I believe that I have demonstrated that
the current MAC construction does not use an injective mapping and is thus
not consistent with best practices.

However, in particular...

On Sun, Oct 04, 2020 at 04:35:49PM +0200, Achim Kraus wrote:

Hi Ben,

any progress on the cid-length / calculate MAC topic?

As I wrote, though the cid-length itself is not "on the wire" (it's only
the cid), I can't see, that the cid-length could be injected.
Do I oversee soemthing?

best regrads
Achim Kraus

 Weitergeleitete Nachricht ----
Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Datum: Wed, 16 Sep 2020 08:31:19 +0200
Von: Achim Kraus 
An: Benjamin Kaduk 
Kopie (CC): draft-ietf-tls-dtls-connection...@ietf.org, tls@ietf.org

Hi Ben,

...



The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
and the DTLS (explicit) sequence number.  I do not see this
concatenation given the name "seq_num" anywhere, so I think we need to
reformulate this expression.

  cid +
  cid_length +

Does this construction preserve injectivity?  It seems easier to reason
about when the length of an element is always before or always after the
element itself, but we put the length first for some of the other
fields (that appear after these) so there seems to be some malleability.


That order was also discussed a lot.
https://github.com/tlswg/dtls-conn-id/pull/29
I would prefer, if this is not changed again without strong arguments!


Thanks for the pointer!
I am not sure that the specific question about injectivity was raised
there, though.  (The topic of whether "seq_num" includes epoch was raised
but I did not see a clear resolution on my first reading, just
https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)

Specif

[TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,

any progress on the cid-length / calculate MAC topic?

As I wrote, though the cid-length itself is not "on the wire" (it's only
the cid), I can't see, that the cid-length could be injected.
Do I oversee soemthing?

best regrads
Achim Kraus

 Weitergeleitete Nachricht 
Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
Datum: Wed, 16 Sep 2020 08:31:19 +0200
Von: Achim Kraus 
An: Benjamin Kaduk 
Kopie (CC): draft-ietf-tls-dtls-connection...@ietf.org, tls@ietf.org

Hi Ben,

...



The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
and the DTLS (explicit) sequence number.  I do not see this
concatenation given the name "seq_num" anywhere, so I think we need to
reformulate this expression.

 cid +
 cid_length +

Does this construction preserve injectivity?  It seems easier to reason
about when the length of an element is always before or always after the
element itself, but we put the length first for some of the other
fields (that appear after these) so there seems to be some malleability.


That order was also discussed a lot.
https://github.com/tlswg/dtls-conn-id/pull/29
I would prefer, if this is not changed again without strong arguments!


Thanks for the pointer!
I am not sure that the specific question about injectivity was raised
there, though.  (The topic of whether "seq_num" includes epoch was raised
but I did not see a clear resolution on my first reading, just
https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)

Specifically, the question of "injectivity" is referring to a scenario
where I can use different actual values for (cid, cid_length,
length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed

cid + cid_length + length_of_DTLSInnerPlaintext + ...

(Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
field...)

Attempting to construct a trivial example on the fly, (hex)

01 01 02 02 01 <513 bytes of plaintext content>

could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
DTLSInnerPlaintext.content = <513 bytes>.  The possibility of such a
collision weakens the cryptographic protection and should be avoided.



If that is going to be changed, the early adopters run into trouble with
their deployments!

The cid length is not on the wire, so on the wire is (cid 01 01)


01 01 02 01 <513 bytes of plaintext content>


Therefore I don't understand, WHO will inject something, which is not on
the wire. For me that would only be the peer's implementation, which
extracts it's "own" CID wrong, or a "spoofed CID" (maybe that's the time
to read my proposal about a CID Authentication Code, issue #74.). But
with the wrong CID, the wrong keys would be selected and the MAC will
fail anyway. So, I can't see that collision.

best regards
Achim

___
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] The future of external PSK in TLS 1.3

[Achim Kraus]

For me this seems to be a philosophic dispute about the
"philosopher's stone".

So, not too serious:

Great idea!

just add the number of the year to the term TLS for the main stream!
And leave the term TLS without the year numbers to those, who want to
use recommended stuff from last year also next year.

best regards
Achim Kraus

Am 30.09.20 um 10:19 schrieb Rob Sayre:

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

___
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] The future of external PSK in TLS 1.3

[Achim Kraus]

Hi list,

exchanging arguments for N or Y again seems for me to be in vain.

Therefore my proposal to add the Y-period. For me that documents more
the fact, that the security trade off between security and resources is
changing over time. And so will the implementations and deployments.

best regards
Achim Kraus

Am 30.09.20 um 02:48 schrieb Blumenthal, Uri - 0553 - MITLL:

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

___
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] The future of external PSK in TLS 1.3

[Achim Kraus]

Hi list,

I'm still worrying about the "recommended" and the (mis-)interpretation
of that. I'm fine with the explanation

---
Note

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

but, I feel uncomfortable considering too many decision makers will not
read that details. Though the "recommendation" is changing over the
time, I would feel more comfortable, if the N would be amended by the
Y-period.

e.g. N (was Y 2001-2015)

FMPOV, if someone reads that, it may explain, that the N is a recent one
and some use-case will still need some time to adapt for the new
recommendations.

best regards
Achim Kraus

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

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

[Achim Kraus]

Hi Pascal,

> But what about heath devices, autonomous cars, nuclear plants,
> blockchain transfers ?. Maybe, they are not in the IoT scope...

Agreed. Therefore I wrote

>> Isn't it always a question of what to protect in which environment?

Maybe, one column with recommended (Y/N/), is not enough.

##
Note

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

best regards
Achim

Am 21.09.20 um 22:57 schrieb Pascal Urien:

Hi Achim

Your local network "light bulb" is likely not a big issue

But what about heath devices, autonomous cars, nuclear plants,
blockchain transfers ?. Maybe, they are not in the IoT scope...

Best Regards

Pascal


Le lun. 21 sept. 2020 à 19:57, Achim Kraus mailto:achimkr...@gmx.net>> a écrit :

Hi Pascal,

that using these ISO 7816 card is fast and save, doesn't say too much
about the use-case without that card, or? For sure, there are
micro-controller, which are also equipped with hw-ecc or hw-rsa. And
there are more secure-devices protecting credentials. But there are also
still ones without.
I'm not sure, if I want spend too much money in my local network "light
bulb". Isn't it always a question of what to protect in which
environment?

best regards
Achim

Am 21.09.20 um 14:53 schrieb Pascal Urien:
 > tls-se memory footprint is
 > flash 《 40KB
 > ram   《 1KB
 >
 > time to open a tls session 1.4 seconds
 >
 >
 > Le lun. 21 sept. 2020 à 14:47, Pascal Urien
mailto:pascal.ur...@gmail.com>
 > <mailto:pascal.ur...@gmail.com <mailto:pascal.ur...@gmail.com>>>
a écrit :
 >
 >     hi Hannes
 >
 >     no openssl or wolfssl are used as client in order to check
 >     interoperability with tls-se server
 >
 >     tls-se is of course a specific implémentation for tls13 server in
 >     javacard..it is written in java but an ôter implémentation is
 >     written in c for constraint notes. as written in the draft tls-se
 >     implementation has three software blocks: crypto lib, tls state
 >     machine, and tls lib
 >
 >
 >
 >     Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig
 >     mailto:hannes.tschofe...@arm.com>
<mailto:hannes.tschofe...@arm.com
<mailto:hannes.tschofe...@arm.com>>> a écrit :
 >
 >         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 mailto:pascal.ur...@gmail.com>
 >         <mailto:pascal.ur...@gmail.com
<mailto:pascal.ur...@gmail.com>>>
 >         *Sent:* Monday, September 21, 2020 2:01 PM
 >         *To:* Hannes Tschofenig mailto:hannes.tschofe...@arm.com>
 >         <mailto:hannes.tschofe...@arm.com
<mailto:hannes.tschofe...@arm.com>>>
 >         *Cc:* Filippo Valsorda mailto:fili...@ml.filippo.io>
 >         <mailto:fili...@ml.filippo.io
<mailto:fili...@ml.filippo.io>>>; tls@ietf.org <mailto:tls@ietf.org>
<mailto:tls@ietf.org <mailto: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 wor

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

[Achim Kraus]

Hi John,

I can only fully agree with Hannes's arguments!

PSK is in my experience for some constraint devices currently the only
choice. Devices, which are able to execute a PSKs with ECDHE handshakes,
will be able to use RPK.

I'm not sure, if sometimes the arguments, not to recommend something,
should be more differentiated. Pretty sure, outside IoT, there may be no
reason left to use that. But inside IoT, it may take some more time
until almost all device can use it.

best regards
Achim

Am 20.09.20 um 13:18 schrieb 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



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

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

[Achim Kraus]

Hi Pascal,

that using these ISO 7816 card is fast and save, doesn't say too much
about the use-case without that card, or? For sure, there are
micro-controller, which are also equipped with hw-ecc or hw-rsa. And
there are more secure-devices protecting credentials. But there are also
still ones without.
I'm not sure, if I want spend too much money in my local network "light
bulb". Isn't it always a question of what to protect in which environment?

best regards
Achim

Am 21.09.20 um 14:53 schrieb Pascal Urien:

tls-se memory footprint is
flash 《 40KB
ram   《 1KB

time to open a tls session 1.4 seconds


Le lun. 21 sept. 2020 à 14:47, Pascal Urien mailto:pascal.ur...@gmail.com>> a écrit :

hi Hannes

no openssl or wolfssl are used as client in order to check
interoperability with tls-se server

tls-se is of course a specific implémentation for tls13 server in
javacard..it is written in java but an ôter implémentation is
written in c for constraint notes. as written in the draft tls-se
implementation has three software blocks: crypto lib, tls state
machine, and tls lib



Le lun. 21 sept. 2020 à 14:36, Hannes Tschofenig
mailto:hannes.tschofe...@arm.com>> a écrit :

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 mailto:pascal.ur...@gmail.com>>
*Sent:* Monday, September 21, 2020 2:01 PM
*To:* Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
*Cc:* Filippo Valsorda mailto:fili...@ml.filippo.io>>; 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

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

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,


Am 16.09.20 um 08:31 schrieb Achim Kraus:

Hi Ben,



If I did't get it, it may be easier to discus this as issue in the
github repo.


I think you got it; I am just failing to remember where the "MUST anyway
use new handshakes" requirement comes in from.  And I guess that also
raises the question of what the expected behavior is when a server
expects
CID-ful traffic on a given 5-tuple and receives an (unencrypted)
ClientHello on that 5-tuple.



"when a server expects CID-ful traffic on a given 5-tuple"

I'm not sure, why that should happen. If CID is used, the server should
not expect a given 5-tuple (at least not longer than a few seconds).
If a new CLIENT_HELLO arrives, it's first challenge it with a
HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
of a previous CID message" is hit, then just mark/remove the 5-tuple of
that CID association. That mainly means, you will not be able to reach
the CID peer with that 5-tuple. That's anyway extremely common to lose
the ip-route to such CID peers, otherwise CID would not be required.



Let me add:

- If the scenario uses "dynamic 5-tuples, with CID or without" and
"static 5-tuples without CID",
- then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
pool) and CID (described in
https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
communication to such a static-5-tuple without CID.

Even then, that "static-5-tuple" peers must be anyway aware, that
sometimes new handshakes are required. So that scenario may also depend
more on the volume of such attacks, than just on the pure possibility.
In my experience, such "static-5-tuples" are rare and I would guess,
they will benefit from different handling also for other reasons.
Therefore I would just spend them an separate endpoint to separate their
traffic.

best regards
Achim

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

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,



 For receiving, if the tls12_cid content type is set, then the CID is
 used to look up the connection and the security association.  If the
 tls12_cid content type is not set, then the connection and security
 association is looked up by the 5-tuple and a check MUST be made to
 determine whether the expected CID value is indeed zero length.  If
 the check fails, then the datagram MUST be dropped.

I guess there's maybe a risk that an attacker sets up a CID-ful
connection on a given 5-tuple and then disappears, thereby denying
the target of the attack the ability to use a CID-less DTLS association
on that 5-tuple.  But it would be hard to swamp all the ports, so it's
only likely to be an issue when fixed ports are used on both sides ...
which is known to happen sometimes.  Perhaps we should document this in
the security considerations.



I'm not sure, if I understand that well.
Do you assume, that in a network envirnoment, where the 5-tuple is not
stable, someone may use a CID and so block the (instable) 5-tuple? Yes,
but in that network your peer MUST anyway use new handshakes and so the
CID usage will be overwriten by the new handshake.
If the 5-tuples are stable, then the attack must spoof the 5-tuple, but
the hello verify mechanism will block that.

If I did't get it, it may be easier to discus this as issue in the
github repo.


I think you got it; I am just failing to remember where the "MUST anyway
use new handshakes" requirement comes in from.  And I guess that also
raises the question of what the expected behavior is when a server expects
CID-ful traffic on a given 5-tuple and receives an (unencrypted)
ClientHello on that 5-tuple.



"when a server expects CID-ful traffic on a given 5-tuple"

I'm not sure, why that should happen. If CID is used, the server should
not expect a given 5-tuple (at least not longer than a few seconds).
If a new CLIENT_HELLO arrives, it's first challenge it with a
HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
of a previous CID message" is hit, then just mark/remove the 5-tuple of
that CID association. That mainly means, you will not be able to reach
the CID peer with that 5-tuple. That's anyway extremely common to lose
the ip-route to such CID peers, otherwise CID would not be required.

Just if you're interested:
I have already implemented that CID/5-tuple management in the open
source project Eclipse/Californium. (That project also contains a very
simple test-NAT, where you may simulate some address changes. But that
requires some more docu :-) ).
You may check, if that works as you would expect. Any feedback will be
very welcome. If you want ot use it with other implementations (e.g.
mbedTLS), ensure that the hello extension uses the right assigned IANA
value 53.



The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
and the DTLS (explicit) sequence number.  I do not see this
concatenation given the name "seq_num" anywhere, so I think we need to
reformulate this expression.

 cid +
 cid_length +

Does this construction preserve injectivity?  It seems easier to reason
about when the length of an element is always before or always after the
element itself, but we put the length first for some of the other
fields (that appear after these) so there seems to be some malleability.


That order was also discussed a lot.
https://github.com/tlswg/dtls-conn-id/pull/29
I would prefer, if this is not changed again without strong arguments!


Thanks for the pointer!
I am not sure that the specific question about injectivity was raised
there, though.  (The topic of whether "seq_num" includes epoch was raised
but I did not see a clear resolution on my first reading, just
https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)

Specifically, the question of "injectivity" is referring to a scenario
where I can use different actual values for (cid, cid_length,
length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed

cid + cid_length + length_of_DTLSInnerPlaintext + ...

(Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
field...)

Attempting to construct a trivial example on the fly, (hex)

01 01 02 02 01 <513 bytes of plaintext content>

could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
DTLSInnerPlaintext.content = <513 bytes>.  The possibility of such a
collision weakens the cryptographic protection and should be avoided.



If that is going to be changed, the early adopters run into trouble with
their deployments!

The cid length is not on the wire, so on the wire is (cid 01 01)

> 01 01 02 01 <513 bytes of plaintext content>

Therefore I don't understand, WHO will inject something, which is not on
the wire. 

Re: [TLS] Static DH timing attack

[Achim Kraus]

Am 10.09.20 um 11:23 schrieb Peter Gutmann:


Reason the second: Telling people not to use static-ephemeral DH will mean
telling them not to use 25519 key exchange, which will make their heads
asplode.

Peter.


So, risking damaged heads:
Does using x25519 for ECDHE is significant less secure
than using it with e.g. secp384r1?

Or do I mix-up things and "DH with 25519 keys" is something different?

best regards
Achim Kraus

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

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus]

Hi Ben,

see my comments inline.

Generally you may read the closed issues or PRs with the proper keywords
in https://github.com/tlswg/dtls-conn-id.

FMPOV most stuff has been discussed over and over. For me, in many cases
there are not that strong arguments for the choosen option over the
others. But these discussion have been at that time. For now, I'm not
sure, if changing details will bring that benefit.
So, please, only address and change things, which are really important.

best regards
Achim Kraus

Am 04.09.20 um 01:02 schrieb Benjamin Kaduk:

Hi all,

Sorry for the slow processing time -- my queue is still longer than I am
happy with.

There's a few apparent inconsistencies that we'll need to tighten up,
but I don't think there's anything particularly problematic.
I made a PR for most of the editorial stuff:
https://github.com/tlswg/dtls-conn-id/pull/75
And having pulled the github repo up, it looks like there's a few open
issues and PRs still, there -- what's the status of those?



#73 FMPOV it's worth to address the issue Thomas found.
I would prefer a wording, which point to RFC6347, 4.1.2.1 and explain
not to use the option "If a DTLS implementation chooses to generate an
alert".


I wonder whether, as a rhetorical device, it would be helpful to give
the new record payload structure a new name (DTLSCIDCiphertext?) to
distinguish it from the RFC 6347 DTLSCiphertext.  Then we could write
things like "in order to distinguish between DTLSCiphertext and
DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used
once encryption is enabled", etc.

Section 3

For sending, if a zero-length CID has been negotiated then the RFC
6347-defined record format and content type MUST be used (see
Section 4.1 of [RFC6347]) else the new record layer format with the
tls12_cid content type defined in Figure 3 MUST be used.

I'm glad that we take a clear stance on what content-type to use for
zero-length CIDs, though I forget what the reasoning was to fall this
way vs requiring that the tls12_cid ContentType is used whenever CIDs
are negotiated.  I see how this approach makes some processing easier
(there is always a CID present when the ContentType is used), but it
does have the drawback of requiring use of actual CIDs in order to
get encrypted content-type.  If you could remind me why this approach
was chosen, that will be helpful for subsequent discussions/IESG
review/etc.


There have benn some discussion about that, see

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

So, I'm also glad that in the end of the discussion there was a
consense. I'm not sure, but I think that comment

https://github.com/tlswg/dtls-conn-id/issues/28#issuecomment-458032109

made mainly the decission.




For receiving, if the tls12_cid content type is set, then the CID is
used to look up the connection and the security association.  If the
tls12_cid content type is not set, then the connection and security
association is looked up by the 5-tuple and a check MUST be made to
determine whether the expected CID value is indeed zero length.  If
the check fails, then the datagram MUST be dropped.

I guess there's maybe a risk that an attacker sets up a CID-ful
connection on a given 5-tuple and then disappears, thereby denying
the target of the attack the ability to use a CID-less DTLS association
on that 5-tuple.  But it would be hard to swamp all the ports, so it's
only likely to be an issue when fixed ports are used on both sides ...
which is known to happen sometimes.  Perhaps we should document this in
the security considerations.



I'm not sure, if I understand that well.
Do you assume, that in a network envirnoment, where the 5-tuple is not
stable, someone may use a CID and so block the (instable) 5-tuple? Yes,
but in that network your peer MUST anyway use new handshakes and so the
CID usage will be overwriten by the new handshake.
If the 5-tuples are stable, then the attack must spoof the 5-tuple, but
the hello verify mechanism will block that.

If I did't get it, it may be easier to discus this as issue in the
github repo.


When receiving a datagram with the tls12_cid content type, the new
MAC computation defined in Section 5 MUST be used.  When receiving a
datagram with the RFC 6347-defined record format the MAC calculation
defined in Section 4.1.2 of [RFC6347] MUST be used.

I guess that "4.1.2" includes "4.1.2.5 New Cipher Suites", so this is
not inadvertently closing off extensibility (not that we expect much in
the way of new 1.2 ciphersuites)...right?


The MAC calculation have also been discussed:
https://github.com/tlswg/dtls-conn-id/issues/25

If the CID is to be included into the MAC, then in my opinion, that must
be defined for each supported cipher suite.



Section 4

When CIDs are being used, the content to be sent is first wrapped
  

Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

[Achim Kraus]

Hello Ben,

thanks for your answer and actions.

best regards
Achim

Am 27.07.20 um 21:03 schrieb Benjamin Kaduk:

Hi Achim,

My apologies for the URL mangling by my corporate spam filter.

On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote:

Dear list,

are there any news about the draft-ietf-tls-dtls-connection-id and the
IANA registration of the connection_id?

According
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Ddtls-2Dconnection-2Did=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg=kAlzAEjg0E4P_Cw7G3afL6NHvcFJpJLl72gJVzBvrJ8=
  the
draft expired on April 23, 2020 and according
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_tls-2Dextensiontype-2Dvalues_tls-2Dextensiontype-2Dvalues.xhtml=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg=poEk1-YL4mzxACY3b-Ldn9NtcPOSd-ZvDKXJcbQ3Ep0=
the assigned value expired on 2020-07-02.


There seems to have been some oversight, as this assignment was not included
in a report of "early allocations assigning in the next 60 days" that was 
produced
on 2020-06-15.  I have asked IANA to investigate (and indicated that this
extension's allocation should be renewed).

The draft itself is essentially done from the WG's point of view, with just
the two PRs you note left to merge.  It has been waiting for quite some time for
me to perform an AD evaluation and start an IETF Last Call on it; I expect to do
so in the next couple weeks.

Thanks,

Ben


I still very interested in this extension, it makes coap over dtls 1.2 a
very powerful technology for the cloud and NB IoT.

Currently two pending threats are discussed, see the PRs in
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls-2Dconn-2Did=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg=6LWHz8pLHziy_jeL2sXwJnw4Y7gz84VzFUe0ur4RsDg=
  .

One of both is in my opinion a general one using UDP, several
countermeasures are discussed, including RRC. Let me add, that in my
opinion, it's also about to chose cid for the right use-case, and not
generally. That would mostly eliminated the DDoS threat, if the use-case
doesn't offer an amplification.
The other one requires in my opinion a remark about not using the option
of RFC 6347 to generate an alert on invalid MACs, if the cid is used.
Potentially, if of any interest at all, an additional remark about
AES-CBC, the CID length and "lucky 13" maybe added, though the cid
changes the 13.

For me this looks much more, that the authors are too busy with other
work and not that this draft doesn't make sense anymore. Therefore I
would appreciate, if the temporary IANA registration for the
connection_id could be extended by an additional year.

Best regards
Achim Kraus

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DwICAg=96ZbZZcaMF4w0F4jpN6LZg=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg=FbOzAxOPoG1SVAsJCPteFfbyv3RYaOwBj5OuZTxcerk=


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

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

[Achim Kraus]

Hello Martin,
Hello list,

> That said, I believe that this falls a long way short of addressing
the attacks that I'm aware of.  But that assumes we share an
understanding about what those attacks are.  To begin with, we probably
need a clearer description of goals.

Fully agreed. Unfortunately, that discussion seems to be either not
public, or, somehow, stale.

https://github.com/tlswg/dtls-conn-id/pull/71

So, if you have any update, please provide the details, where to find it.

> To give an idea, address validation in QUIC is much more complex than
is proposed here, for reasons I believe to be good.  If this document
does less than QUIC, it needs to justify that.

I disagree. QUIC (as any other technology) sticks to use-cases, and the
therefore the definitions there are also depend on the use-case.

https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#address-validation

"Address validation ensures that an endpoint cannot be used for a
traffic amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a victim.
If a server generates more or larger packets in response to that packet,
the attacker can use the server to send more data toward the victim than
it would be able to send on its own.

The primary defense against amplification attack is verifying that an
endpoint is able to receive packets at the transport address that it
claims."

In my opinion, the primary defense depends on the use-case.

1. Just don't sent anything back is the very primary defense.

That will not work for all use-cases, therefore the secondary defense is

2. Just don't sent back more than received.

(Considering DDoS results in a combination of the primary and secondary
defense, means only send back responses, limited by size and number.)

That again limits also the use-cases, therefore the third defense is
then the

3. "primary defense" of QUIC.

The difference between QUIC and RRC could analyzed from both ends.
The one may justify, why they don't consider something and therefore do
less. The others may also justify, why they consider something
additionally, and therefore do more.

In the end, it's more the question, who is intended to invest the time.

best regards
Achim Kraus


Am 23.07.20 um 02:32 schrieb Martin Thomson:

I'm OK with adoption.

That said, I believe that this falls a long way short of addressing the attacks 
that I'm aware of.  But that assumes we share an understanding about what those 
attacks are.  To begin with, we probably need a clearer description of goals.

To give an idea, address validation in QUIC is much more complex than is 
proposed here, for reasons I believe to be good.  If this document does less 
than QUIC, it needs to justify that.

On Thu, Jul 23, 2020, at 04:55, Sean Turner wrote:

Hi!

The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3"
have asked for adoption of their draft as a WG item.  Please state
whether you support adoption of this draft as a WG item by posting a
message to the TLS list by 2359 UTC 06 August 2020.  Please include any
additional information that is helpful in understanding your position.

NOTE:
We discussed this draft at IETF 105 in connection with
draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to
progress draft-tschofenig-tls-dtls-rrc after we progressed
draft-ietf-tls-dtls-connection-id. That time is now.

Thanks,
Chris, Joe, and Sean

[0]
https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-cid-00
___
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

[TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

[Achim Kraus]

Dear list,

are there any news about the draft-ietf-tls-dtls-connection-id and the
IANA registration of the connection_id?

According
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id the
draft expired on April 23, 2020 and according
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
the assigned value expired on 2020-07-02.

I still very interested in this extension, it makes coap over dtls 1.2 a
very powerful technology for the cloud and NB IoT.

Currently two pending threats are discussed, see the PRs in
https://github.com/tlswg/dtls-conn-id .

One of both is in my opinion a general one using UDP, several
countermeasures are discussed, including RRC. Let me add, that in my
opinion, it's also about to chose cid for the right use-case, and not
generally. That would mostly eliminated the DDoS threat, if the use-case
doesn't offer an amplification.
The other one requires in my opinion a remark about not using the option
of RFC 6347 to generate an alert on invalid MACs, if the cid is used.
Potentially, if of any interest at all, an additional remark about
AES-CBC, the CID length and "lucky 13" maybe added, though the cid
changes the 13.

For me this looks much more, that the authors are too busy with other
work and not that this draft doesn't make sense anymore. Therefore I
would appreciate, if the temporary IANA registration for the
connection_id could be extended by an additional year.

Best regards
Achim Kraus

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

Re: [TLS] RFC 8449 – DTLS 1.2 considerations

[Achim Kraus]

Hello Martin,

thanks a lot for your answer!
That helps very much to overcome my UDP confusion :-).

best regards
Achim

Am 15.07.20 um 08:41 schrieb Martin Thomson:

On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote:

For me it seems, that an agreement about this message buffer size is
still missing.


This is a question we dealt with in QUIC by limiting UDP datagram size rather 
than the record size (or packet size in QUIC terminology).

In this case, the spec doesn't really say the most helpful thing about UDP 
datagram size in DTLS.  Indeed, you might say that pointing to the ability to 
include multiple records per datagrams is an invitation to do bad things.  
After all, a receiver that receives a datagram that is too large for it likely 
has to drop it or only process part of it.  The partial processing is possible 
if there are small records, but it does lead to lots of losses.

The way I would approach this is to send one record per datagram in DTLS, no 
matter what the spec says.

(NSS implements this spec, but does not assume any limits, it only respects a 
limit set by a peer.  For DTLS it sends one record per datagram, outside of the 
handshake.)

Assuming that you do have a constrained implementation that can't receive large 
datagrams, then we probably need different signaling.  But there are 
workarounds.

If you start receiving large UDP datagrams, then it is possible to drop those 
and hope that your peer has some sort of PMTU discovery (NSS has something, but 
it is crude).  At that point, the size of datagrams is limited as though it 
were a path limitation.  That likely gets you down to the minimum MTU for the 
IP version you are using.  For IPv6, that's not so different from the 1400-odd 
that you describe, but IPv4 - and therefore some implementations - might go as 
low as the IPv4 minimum MTU.

(FWIW, NSS will go as low as a 228 byte MTU, which is pretty extreme.  And it 
takes a lot of failed retransmissions to get that low.  I wouldn't expect that 
small an MTU from other implementations.)

All that said, if you have a size constraint smaller than a typical UDP MTU, 
then you have a very constrained implementation.  Not being able to spare ~1k 
but expecting to do TLS is something I struggle to comprehend.


___
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] Banning implicit CIDs in DTLS

[Achim Kraus]

Hi Thomas,

> Now, it turns out in the specific situation (and whenever the data
> framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
> might as well buffer and coalesce all the application stuff into one
> single record, making the need for CID compression moot.

I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the size
of the UDP message (or that of the DTLS "application_data" part). Only
for TCP the size is explicitly encoded in the CoAP messages (but that's
not RFC7252). If I miss something about that, it would be great, if you
share some details to help me out.

In my opinion, introducing a new TLS Content Type
"multi_application_data" would help in a more general way. Even without
the "implicit CIDs" discussion it may help in some cases, where a couple
of "very small" "application_data"-messages are sent at once.

best regards
Achim

Am 27.05.20 um 12:03 schrieb Thomas Fossati:

On 24/05/2020, 20:45, "Eric Rescorla"  wrote:

In what context do you have a use for implicit CIDs?


The specific use case I had in mind is that of an endpoint sending small
and frequent application data units to the same peer - e.g., sensor
readings through CoAP observe.  In this (and similar) situation(s) where
the payload / header ratio is low one wants to have as little transport
overhead as possible.

Now, it turns out in the specific situation (and whenever the data
framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one
might as well buffer and coalesce all the application stuff into one
single record, making the need for CID compression moot.

So, I am now convinced I don't have a compelling case to bring to the
table and might as well move into Martin's "vanishingly small use cases"
camp, therefore subscribing the gist of PR#148.


PS  A note about the more general argument of a pure pseudo-header
approach: it'd enable compression boxes at ingress into a constrained
network, which would be really useful.  Without a thorough analysis wrt
header malleability this is unfortunately out of reach.

--

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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Achim Kraus]

Hi Martin,

> So this depends on either concurrent use of the two CIDs,

with that and the "routing based on cid", I would raise the question, if
the usage of the cid turns into a swiss-army-knife?
Therefore it may get larger, and so it gets attractive,
to use it only on the first record, but leave it out on follow up records.
So, is that the idea? Use a large CID to include more information?

> or moving a record from before a change in CID to after a change.

I'm still not common to DTLS 1.3.
With DTLS 1.2 a resumption- or full-handshake will result in a new
context. So for me moving the record will fail.

best regards
Achim

Am 24.04.20 um 12:09 schrieb Martin Thomson:

Hi Hannes,

Let me see if I can clarify then :)

On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote:

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?


I don't think that DTLS really says what the CID is for, but this particular 
attack depends on being able to shift records from a datagram containing a 
record that has CID A to a datagram containing a record with CID B.  So this 
depends on either concurrent use of the two CIDs, or moving a record from 
before a change in CID to after a change.

Imagine that you have record 1 and 2 in the same datagram, with record 1 having 
CID A and record 2 having no explicit CID (but for the same connection, as 
required).  Then record 3 is sent with CID B (maybe on a different path).  The 
attacker can remove record 2 from the first datagram and add it to the second.  
If the attacker can determine whether record 2 was consumed, it can confirm 
that CID A and CID B are for the same connection.


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.


by "route" I am trying to be generic.  In QUIC, the CID is used by cooperating 
middleboxes to select server instances.  But as you say, it is also used to identify 
which connection (and the right keys) to pick from potentially many choices, without 
necessarily using addressing information (which might have changed).  To me, that's all 
just routing, whether between boxes, or threads, or connections.


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.


Probably, yeah.  That's why you need to find a record with the other CID to pair it with. 
 Besides, the "attack" is trying to link CID A and CID B, and having the record 
consumed without linking to either doesn't tell the attacker much (except perhaps that 
the CID wasn't needed for routing purposes).

___
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] Choice of Additional Data Computation

[Achim Kraus]

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



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

Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

[Achim Kraus]

Hi Kenny,

> That would still leave a timing side channel which would reveal
whether the padding length exceeds the amount of data.

Maybe I was not precise:
Regardless of the content of the padding length byte and the result of
it's overflow check, I would always apply b), as you (and others)
recommended in the document. My impression of that "defined padding and
check" was a optimization to skip the MAC calculations. But as lucky13
shows, the MAC must always be calculated and filled up with extra
evaluations!
But, if b) is always applied, the intensive padding check in a) should
be possibly replaced by a simple overflow check without drawback.

> I'd need to dig into it more to be certain, but my sense is that such
a side channel could be turned into at least a partial plaintext
recovery attack, and possibly a full plaintext recovery attack.

That would be great!

Just one additional question, but if it's too far/deep, just ignore it:
My impression is, that the "plaintext recovery" requires the same
plaintext payload "serveral" times. Then the recover is from the end,
starting with 2 bytes, adding more bytes toward the start of the message
(here it comes, that it must be the same plaintext). With that, I'm
wondering, if such an approach could pass the MAC part (as plaintext
recovery), because this seems to be changing from session to session or
with the record sequence number. Assuming, that therefore the MAC part
must be cut of efficiently, but leave enough for still have an MAC check
on the truncated message, lead to a conclusion, that at least very short
messages are not affected. Does this match your assumptions?

best regards
Achim Kraus

Am 09.09.19 um 10:45 schrieb Paterson  Kenneth:

Hi Achim,

See below for a comment on your analysis.

-Original Message-
From: TLS  on behalf of Achim Kraus 
Date: Monday, 9 September 2019 at 09:24
To: "tls@ietf.org" 
Subject: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

 RFC 7457, Lucky 13, mitigation, DTLS 1.2

 Dear List,

 currently I try to do some investigation about the simplest way to
 mitigate the “lucky 13” attack without using RFC 7366.

 Therefore I read the slides in [1] and also the recommended mitigation
 in [2], which is cited in RFC 7457.

  From the slides, my impression is, that the “defined padding & padding
 check” was used to reduce the “timing side channel” of MAC depending on
 the data fragment size. Lucky 13 demonstrates, that this “defined
 padding” could be tricked out.

 The recommended mitigation in [2] describes on page 539 to do,
 a) the padding check “time side channel” free by using always “256 
compares”
 b) and the MAC check “time side channel” free, by adjust the number of
 compression function evaluations with extra evaluations on dummy data to
 achieve always the same number of evaluations.

 FMPOV b) is the one, which closes the “time side channel”.
 But a) seems to be more a left over. It doesn’t protect enough, as lucky
 13 shows, and complicated algorithms, as “always 256 compares” even on
 shorter messages, may harm more.

 So, why should that “defined padding” check be done, if b) is applied?

 Wouldn’t a simple check, if the padding length exceeds the amount of
 data, and on failure, set it to 0, simplify the mitigation?

That would still leave a timing side channel which would reveal whether the 
padding length exceeds the amount of data. I'd need to dig into it more to be 
certain, but my sense is that such a side channel could be turned into at least 
a partial plaintext recovery attack, and possibly a full plaintext recovery 
attack.

You might want to read Adam Langley's account of how L13 was addressed in 
OpenSSL:

https://www.imperialviolet.org/2013/02/04/luckythirteen.html

Regards,

Kenny



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

Re: [TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

[Achim Kraus]

Hi Martin,

thanks for your answer!

> Are you able to use an AEAD?
> I agree that EtM is likely a non-starter, but moving to an AEAD is
just better.

I totally agree! I always recommend to use AEAD and not to start with
CBC, regardless of the flavor. But for "historical reasons", there maybe
users, which are bound to CBC. Though a migration of distribute system
to AEAD (or EtM) may also come with risks, my plan was to offer an
"improvement as temporary solution" to give a little more time for such
migrations.

> NSS does the "255 compares" approach, which I think is OK.  In
particular, if the record is shorter, that information is public which
ensures that the timing behaviour is dependent on only public information.

You may do it with the "256 compares".
But my feeling is, this is just a left over and could be replaced by a
simple padding overflow check without drawbacks.

best regards
Achim Kraus

Am 09.09.19 um 10:03 schrieb Martin Thomson:

Are you able to use an AEAD?

I agree that EtM is likely a non-starter, but moving to an AEAD is just better.

NSS does the "255 compares" approach, which I think is OK.  In particular, if 
the record is shorter, that information is public which ensures that the timing behaviour 
is dependent on only public information.

On Mon, Sep 9, 2019, at 17:23, Achim Kraus wrote:

RFC 7457, Lucky 13, mitigation, DTLS 1.2

Dear List,

currently I try to do some investigation about the simplest way to
mitigate the “lucky 13” attack without using RFC 7366.

Therefore I read the slides in [1] and also the recommended mitigation
in [2], which is cited in RFC 7457.

  From the slides, my impression is, that the “defined padding & padding
check” was used to reduce the “timing side channel” of MAC depending on
the data fragment size. Lucky 13 demonstrates, that this “defined
padding” could be tricked out.

The recommended mitigation in [2] describes on page 539 to do,
a) the padding check “time side channel” free by using always “256 compares”
b) and the MAC check “time side channel” free, by adjust the number of
compression function evaluations with extra evaluations on dummy data to
achieve always the same number of evaluations.

FMPOV b) is the one, which closes the “time side channel”.
But a) seems to be more a left over. It doesn’t protect enough, as lucky
13 shows, and complicated algorithms, as “always 256 compares” even on
shorter messages, may harm more.

So, why should that “defined padding” check be done, if b) is applied?

Wouldn’t a simple check, if the padding length exceeds the amount of
data, and on failure, set it to 0, simplify the mitigation?

Additionally, the formula to calculate the extras compression evaluations,

L1=13+plen−t, L2=13+plen−padlen−1−t,

should in my opinion also consider the padlen byte for L1, resulting in

L1=13+plen−1−t

that reduces in some case (1/mac-blocksize) the number of extras
compression evaluations

best regards
Achim Kraus

[1]
https://www.ietf.org/proceedings/89/slides/slides-89-irtfopen-1.pdf

[2]
http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf

___
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

[TLS] RFC 7457, Lucky 13, mitigation, DTLS 1.2

[Achim Kraus]

RFC 7457, Lucky 13, mitigation, DTLS 1.2

Dear List,

currently I try to do some investigation about the simplest way to
mitigate the “lucky 13” attack without using RFC 7366.

Therefore I read the slides in [1] and also the recommended mitigation
in [2], which is cited in RFC 7457.

From the slides, my impression is, that the “defined padding & padding
check” was used to reduce the “timing side channel” of MAC depending on
the data fragment size. Lucky 13 demonstrates, that this “defined
padding” could be tricked out.

The recommended mitigation in [2] describes on page 539 to do,
a) the padding check “time side channel” free by using always “256 compares”
b) and the MAC check “time side channel” free, by adjust the number of
compression function evaluations with extra evaluations on dummy data to
achieve always the same number of evaluations.

FMPOV b) is the one, which closes the “time side channel”.
But a) seems to be more a left over. It doesn’t protect enough, as lucky
13 shows, and complicated algorithms, as “always 256 compares” even on
shorter messages, may harm more.

So, why should that “defined padding” check be done, if b) is applied?

Wouldn’t a simple check, if the padding length exceeds the amount of
data, and on failure, set it to 0, simplify the mitigation?

Additionally, the formula to calculate the extras compression evaluations,

L1=13+plen−t, L2=13+plen−padlen−1−t,

should in my opinion also consider the padlen byte for L1, resulting in

L1=13+plen−1−t

that reduces in some case (1/mac-blocksize) the number of extras
compression evaluations

best regards
Achim Kraus

[1]
https://www.ietf.org/proceedings/89/slides/slides-89-irtfopen-1.pdf

[2]
http://www.ieee-security.org/TC/SP2013/papers/4977a526.pdf

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

Re: [TLS] early code-point assignment request for draft-ietf-tls-dtls-connection-id-04

[Achim Kraus]

Hello Joe,

did the working group receive any concerns about the early code-point
assignment? I hope not. Hannes did again a very great job and so I
closed my open issues on the github repo.
Is there any schedule for the early code-point assignment?
I plan a next eclipse-californium milestone release and it would be very
great, if I could include the values of the early assigned code-points.

best regards
Achim Kraus

Am 05.04.19 um 22:18 schrieb Joseph Salowey:

We have received a request for early code-point assignment of values for
draft-ietf-tls-dtls-connection-id-04.  We believe that only editorial
changes are pending. Please respond to this list of you have concerns
about these assignments by April 12, 2019.

Thanks,

Joe, Sean and Chris

___
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