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

[Simon Bernard]

I support adoption. It should be useful to deal with this issue at DTLS 
level.


Le 03/05/2021 à 17:44, Sean Turner a écrit :

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] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

[Simon Bernard]

Hi,

  My 2 cents, I think a kind of overview page with status about 
protocols, ciphers an others would helps a lot. Something near of what 
is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
  This would be the page to know to be updated about security 
deprecation and planned obsolescence.
  If API was available to query this data, it could maybe be used by 
tools like : https://www.ssllabs.com/index.html


Regards,
Simon

Le 26/09/2019 à 15:50, Daniel Migault a écrit :
Thanks for raising this discussion John, we have been struggling with 
this in curdle as well and ipsecme. This is also a topic that I 
believe would be useful to improve the security.


One aspect is that some implementers go to the IANA pages and believe 
that everything on the pages is acceptable. I believe that it would be 
worth adding some status associated to the code points. Currently, in 
most cases a reference is associated to the code point. In some cases, 
the reference is the RFC or document creating that created the code 
point in other cases, the reference could be the RFC that deprecates 
the code point. There is no specific rules, and that is probably 
something that would worth being clarified. That being clarified, I 
still believe that it could be useful to have a some sort of 
indication like a column that indicates whether the code point is 
deprecated or not. This may involve additional terminology depending 
on the level of information needed.


Another aspect would be to have software automatically checking which 
are the code points status. This would of course only solve one side 
of the problem as a device may end up on becoming silent, but that is 
probably what should occur to non maintained devices.


Yours,
Daniel


On Thu, Sep 26, 2019 at 8:18 AM John Mattsson 
> wrote:


Hi,

Hopefully, we have learned some lessons from the TLS 1.0 and TLS
1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson)
broken in a myriad subtle ways and should according to me
optimally have been deprecated years ago.

3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at
that time not forbid use of TLS 1.1 as that would potentially
break interoperability with some Rel-12 nodes (that had TLS 1.2 as
should support). The lesson 3GPP learned from this was the need to
as early as possible mandate support of new protocol versions.
With TLS 1.3, 3GPP took action early and TLS 1.3 support was
mandated for network nodes in Rel-15 (2018) and for mobile phones
in Rel-16 (2019).

At some point in time we will want to deprecate TLS 1.2. To enable
that, TLS 1.3 support should be mandated or encouraged as much as
possible. I would like to avoid a situation where we want to
deprecate TLS 1.2 but realize that it cannot be done because some
implementations only support TLS 1.2. How can IETF enable smoother
and faster deprecations in the future? The browser industry has a
decent track record of algorithm deprecation and I hope to soon
see the following warning in my browser:

“TLS 1.2 is obsolete. Enable TLS 1.3 or later.”

Other industries have less stellar track records of algorithm
deprecation.

How can IETF be more pro-active regarding deprecations in the
future? In the best of words, nobody should be surprised when IETF
deprecates a protocol version or algorithm. NIST and similar
organizations in other countries have the practice to long time in
advance publish deadlines for security levels, algorithms, and
protocol versions. Can the IETF do something similar, not just for
TLS but in general? For TLS, there are several things to
deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5,
RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher
suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in
the future.

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

Re: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

[Simon Bernard]

Hi,

  Should "return_routability_check" use flight retransmission [1] ?

Should the heartbeat message be re-used instead of the proposed new 
message exchange? 


  It sounds really similar, except that if heartbeat failed we 
terminate the connection and for "return_routability_check" we update 
the peer address.


  Must heartbeat message be authenticated and encrypted using the 
currently active security context ? reading the RFC[2] it's not clear to me.


  heartbeat RFC also explains how to handle heartbeat message during 
handshake. Maybe this RFC should clarify this too.


Simon

[1] https://tools.ietf.org/html/rfc6347#section-4.2.4
[2] https://tools.ietf.org/html/rfc6520

Le 09/07/2019 à 11:05, Hannes Tschofenig a écrit :


Hi all,

working on the DTLS connection id drafts we noticed that there is one 
security aspect, which could benefit from an extra mitigation technique.


The issue is that an on-path adversary could intercept and modify the 
source IP address  (and the source port) of a DTLS datagram.  Even if 
receiver checks the authenticity and freshness of the packet, the 
recipient is fooled into changing the CID-to-IP/port association. This 
can lead to black-holed or redirected traffic. Of course, an on-path 
adversary can do lots of things to traffic and the problem is 
self-fixing but it still lead us to work on a solution in form of a 
return-routability check.


Here is the draft:

https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00

Ciao

Hannes

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


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

Re: [TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption)

[Simon Bernard]

Thx Ekr. Here is a discussion about our concerns : 
https://github.com/eclipse/californium/pull/751


Le 16/10/2018 à 22:18, Eric Rescorla a écrit :

Hi Simon,

I don't think we specified a concrete recommendation, but I think the 
answer is probably no. The reason is that:


(a) a resumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification 
isn't much of an issue.


Maybe I'm missing something though.

-Ekr




On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard <mailto:cont...@simonbernard.eu>> wrote:


Hi,

    In DTLS 1.2 over UDP, I would like to know what is the
recommendation about using HELLO_VERIFY_REQUEST during an abbreviated
handshake.

    Should we send it all the time ? or could we avoid to send it if
SESSION ID is known ?

Thx,


Simon

___
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

[TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption)

[Simon Bernard]

Hi,

   In DTLS 1.2 over UDP, I would like to know what is the 
recommendation about using HELLO_VERIFY_REQUEST during an abbreviated 
handshake.


   Should we send it all the time ? or could we avoid to send it if 
SESSION ID is known ?


Thx,


Simon

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

Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?

[Simon Bernard]

Eric, thx a lot for your answer.

We are discussing a lot about that with our community and there is still 
no consensus ...


So I come back to you to have clearer information to help us to make the 
good decision.


Using DTLS with PSK over UDP, without re-negotiation allowed :
- Is there known security issue about sending the same alert for both 
"unknown identity" and "bad_psk"(invalid record for handshake message) ?


"Discarding records aims to preserve current association", if we are 
able to preserve current association using :

- no renegotiation allowed,
- send alert for invalid record only for handshake record and if we have 
an ongoing handshake,
- In cases where a server believes it has an existing association on a 
given host/port quartet and it receives an epoch=0 ClientHello, destroy 
the existing association only if the client has demonstrated 
reachability by completing a cookie exchange.


Should it be OK ?

Thx again for your time.

Simon

Le 06/04/2018 à 19:26, Eric Rescorla a écrit :



On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard 
<cont...@simonbernard.eu <mailto:cont...@simonbernard.eu>> wrote:


Hi,

We are implementing DTLS with PSK over UDP and I would like to
know how "unknown identity" and "bad psk" should be handled

Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2
<https://tools.ietf.org/html/rfc4279#section-2>)

>   If the server does not recognize the PSK identity, it MAY respond
>   with an "unknown_psk_identity" alert message. Alternatively,
if the
>   server wishes to hide the fact that the PSK identity was not
known,
>   it MAY continue the protocol as if the PSK identity existed
but the
>   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7
<https://tools.ietf.org/html/rfc6347#section-4.1.2.7>

>   In general, invalid records
>   SHOULD be silently discarded, thus preserving the association;
>   however, an error MAY be logged for diagnostic purposes.
>   Implementations which choose to generate an alert instead, MUST
>   generate fatal level alerts to avoid attacks where the attacker
>   repeatedly probes the implementation to see how it responds to
>   various types of error.  Note that if DTLS is run over UDP,
then any
>   implementation which does this will be extremely susceptible to
>   denial-of-service (DoS) attacks because UDP forgery is so easy.
>   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even
HANDSHAKE(22) record (and so FINISHED message) or is it mainly for
APPLICATION_DATA(23) record ?

Is it acceptable to send fatal alert "decrypt_error" in DTLS or
should we just ignore bad credentials silently ?


Hi  Simon,

The advice in 4279 is basically "make an unknown identity look like a 
bad key". So the idea would be to just randomize the key and then get 
the TLS or DTLS-type behavior. I.e., with TLS you would send 
decrypt_error and in DTLS the handshake would just stall because you 
would drop packets.


-Ekr

--
Simon

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




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

[TLS] [DTLS]: how to handle unknown identity and bad psk ?

[Simon Bernard]

Hi,

We are implementing DTLS with PSK over UDP and I would like to know how 
"unknown identity" and "bad psk" should be handled


Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says :
(https://tools.ietf.org/html/rfc4279#section-2)

>   If the server does not recognize the PSK identity, it MAY respond
>   with an "unknown_psk_identity" alert message. Alternatively, if the
>   server wishes to hide the fact that the PSK identity was not known,
>   it MAY continue the protocol as if the PSK identity existed but the
>   key was incorrect: that is, respond with a "decrypt_error" alert.

In TLS the safer way seems to send a "decrypt_error" alert for both.

But in DTLS :
https://tools.ietf.org/html/rfc6347#section-4.1.2.7

>   In general, invalid records
>   SHOULD be silently discarded, thus preserving the association;
>   however, an error MAY be logged for diagnostic purposes.
>   Implementations which choose to generate an alert instead, MUST
>   generate fatal level alerts to avoid attacks where the attacker
>   repeatedly probes the implementation to see how it responds to
>   various types of error.  Note that if DTLS is run over UDP, then any
>   implementation which does this will be extremely susceptible to
>   denial-of-service (DoS) attacks because UDP forgery is so easy.
>   Thus, this practice is NOT RECOMMENDED for such transports.

Is this record layer recommendation for all type of record ? even 
HANDSHAKE(22) record (and so FINISHED message) or is it mainly for 
APPLICATION_DATA(23) record ?


Is it acceptable to send fatal alert "decrypt_error" in DTLS or should 
we just ignore bad credentials silently ?


--
Simon

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

Re: [TLS] Connection ID Draft

[Simon Bernard]

Hi,

Here are the scenarios we would be interested to see covered by this CID 
extension.


1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID 
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID 
connections.


Linkability is not an issue for us, we have almost the same kind of 
linkability than with fixed IP.


Point 1. seems already supported.
Points 2. and 3. seems not ok for now because its not so easy to know if 
a record contains a CID or not.


To know if a record contains a CID, the proposed solution in this thread 
are:

- using content type (not sure to see how?)
- using version (not available in DTLS 1.3? impact on current 
implementation?)

- add a MAC for CID (bandwidth cost?)

I don’t know which one could be the best, but I have one question: how 
to know the CID length for stateless middlebox or packet introspector ?


Simon

Le 03/11/2017 à 11:12, Matt Caswell a écrit :


On 03/11/17 09:28, Martin Thomson wrote:

On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:

It was my understanding that it is precisely this sort of problem that
this draft was attempting to address. Explicit marking would solve this.

Yes, and the connection ID is that marking.  The contention - I think
- is what to do when there is a mix of marked connections and
unmarked.

Right - where you have a mix of packets with connection ID and no
connection ID you don't know whether to look for one or not. IMO this
draft won't really be addressing the issues unless it includes a
mechanism for determining that.

Matt

___
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] Connection ID Draft

[Simon Bernard]

This makes me think about if this is feasible/desirable to use 
connection id to do load balancing.


I think about use cases where you have a cluster of server behind only 
one IP address. Often traffic will be load balanced by IP.

But with UDP and Nat environment, the IP can change.

Thx to CID, if client is redirected to the same server in the cluster, 
even if its IP has changed it will be able to communicate without new 
handshake.
But if its IP has changed there is little chance than load balancer will 
balance it on the same server and so new handshake is needed. (unless 
server share their connection state)


Any thought about that ?


Le 17/10/2017 à 23:35, Martin Thomson a écrit :

On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
GB/Cambridge, UK)  wrote:

The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
meanwhile);

How is B.1 supposed to correctly interpret the bytes starting at offset
+11?  (For what it knows, it could be CID from A.1 or the length field
from A.2.)

I don't think that this is a problem.

connection = five_tuples.lookup(packet.five_tuple)
if (!connection) {
   connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
}
if (!connection) {
   // is this a ClientHello?  otherwise drop it
}

Of course this doesn't help you with A.2, but that's why this draft exists.

If the server can insist on connection IDs from all clients (in the
far future perhaps, or for an entirely new protocol), then the code is
more simply:

connection = 
connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
if (!connection) {
   // is this a ClientHello?  otherwise drop it
}


I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?

Not by my understanding.  There isn't any need (the intent is to have
the CID only consumable by the entity that created it, and any others
that it collaborates with, like a load balancer).

___
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] Stopping retransmission DTLS 1.2

[Simon Bernard]

Hi,

   The RFC6347, 4.2.4 [1] say :

"3. The implementation receives the next flight of messages: if 
this

is the final flight of messages, the implementation transitions to
FINISHED. If the implementation needs to send a new flight, it
transitions to the PREPARING state. Partial reads (whether
partial messages or only some of the messages in the flight) do
not cause state transitions or timer resets."

   I would like to know why "partial reads do not cause state timer 
resets".


   I mean if we receive the first "handshake message" of the expected 
"flight". we can assume that the foreign peer received our previous 
flight and so we can stop retransmissions of this flight.
   If the next message is lost, we will never respond and so the 
foreign peer should retransmit the whole flight. We don't need to 
retransmit on our side, so timer should be reset ?


   Did I missed something ?

Thx.

Simon

[1]https://tools.ietf.org/html/rfc6347#section-4.2.4

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

Re: [TLS] DTLS epoch and resume session/handshake

[Simon Bernard]

I'm sorry to insist, but What did you mean by transport level connection 
? For me UDP was a connectionless protocol.


Simon

Le 31/07/2015 18:53, Eric Rescorla a écrit :



On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard 
cont...@simonbernard.eu mailto:cont...@simonbernard.eu wrote:


Thx.
What did you mean by connection ?


transport level connection.

A resume handshake is a new connection ?


You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :

The epoch is set to 0 at the start of each connection and then
incremented
with each handshake on that connection.

-Ekr

On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard
cont...@simonbernard.eu mailto:cont...@simonbernard.eu
mailto:cont...@simonbernard.eu
mailto:cont...@simonbernard.eu wrote:

Hi,

  I search in DTLS RFC 6347 if the epoch should be (re)set
to 0
when we start a resume handshake, or if we keep the last used
value, or the last used value+1 ? I can not any clue of
that in
the spec.
  Any idea ?

Thx
Simon

___
TLS mailing list
TLS@ietf.org mailto:TLS@ietf.org mailto: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] DTLS epoch and resume session/handshake

[Simon Bernard]

I re-readed this paragraph and it's still not clear, what did you mean 
by connection at transport layer for UDP.


I well understand that if a server receive a clientHello with epoch=0, 
this means that a new handshake should be done.


But I still don't know what happends in a ResumeHandshake use case.

In fact, my use case is a client behind a NAT which communicate 
periodically. at each period, its IP/Port could changed (because of 
NAT), so we would like to resume handshake each time.

1) Does it make sense ?
2) If yes, should we do the resume handhsake with epoch = 0 or continue 
with previous epoch ?



Le 17/08/2015 16:24, Eric Rescorla a écrit :

Please see RFC 6347 S 4.2.8

-Ekr


On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard 
cont...@simonbernard.eu mailto:cont...@simonbernard.eu wrote:


I'm sorry to insist, but What did you mean by transport level
connection ? For me UDP was a connectionless protocol.

Simon


Le 31/07/2015 18:53, Eric Rescorla a écrit :



On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard
cont...@simonbernard.eu mailto:cont...@simonbernard.eu wrote:

Thx.
What did you mean by connection ?


transport level connection.

A resume handshake is a new connection ?


You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :

The epoch is set to 0 at the start of each connection and
then incremented
with each handshake on that connection.

-Ekr

On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard
cont...@simonbernard.eu mailto:cont...@simonbernard.eu
mailto:cont...@simonbernard.eu
mailto:cont...@simonbernard.eu wrote:

Hi,

  I search in DTLS RFC 6347 if the epoch should be
(re)set to 0
when we start a resume handshake, or if we keep the
last used
value, or the last used value+1 ? I can not any clue
of that in
the spec.
  Any idea ?

Thx
Simon

___
TLS mailing list
TLS@ietf.org mailto:TLS@ietf.org mailto: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