Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014

From: "Kumar, Sandeep" <[email-masked]>
Date: Mon, 1 Dec 2014 13:47:32 +0000

Hi Hannes

I read through the latest version at
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-06.txt

My main reason to look at it again is to identify issues if a (D)TLS profiled Client would work with an existing non-profiled (D)TLS Server. I assume this to be a valid scenario since I did not explicitly see any mention of not using a profiled client with existing servers.

1)      Section 6.1 says
For use with this profile the

PSK identities SHOULD NOT assume a structured format (as domain

names, Distinguished Names, or IP addresses have) and a bit-by-bit

comparison operation can then be used by the server-side

infrastructure.

Does this require a change on the server side? As an alternative you can also suggest that the (existing) servers continue to store the PSK-Identity encoded as defined in RFC4279 which would still pass the check if done as in RFC4279.

2)      Section 6.3 says
IoT devices MUST provide support for a server certificate chain of at

least 3 not including the trust anchor and MAY reject connections

from servers offering chains longer than 3.

Can you clarify what would happen after rejecting the connection? Should a fatal alert message be sent and if so which one?

Regards

Sandeep

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 01 Dec 2014 15:44:53 +0100

Hi Sandeep,

thanks for your comments.

On 12/01/2014 02:47 PM, Kumar, Sandeep wrote:
> My main reason to look at it again is to identify issues if a (D)TLS
> profiled Client would work with an existing non-profiled (D)TLS Server.
> I assume this to be a valid scenario since I did not explicitly see any
> mention of not using a profiled client with existing servers.

Of course, there are a number of ways this could lead to a failed
exchange. One obvious reason is a mismatch of ciphersuites supported by
the client and the server. For example, a client only supporting AES-CCM
will not be able to talk to a server that does not support it at all.
For the extensions, however, the issue is less dramatic since the client
will propose them and a server who does not understand them will ignore
them and consequently the client will have to fall-back to a more chatty
exchange.

> Does this require a change on the server side? As an alternative you can
> also suggest that the (existing) servers continue to store the
> PSK-Identity encoded as defined in RFC4279 which would still pass the
> check if done as in RFC4279.

This should not lead to any changes on the server-side infrastructure.

> Can you clarify what would happen after rejecting the connection? Should
> a fatal alert message be sent and if so which one?

Very good question. There is no alert error message that exactly fits
this error condition but the 'certificate_unknown' alert message would
fit according to the description. Alternatively, we could define a new
error message but I am not sure it will provide us a lot of benefit to
allow the server to learn that the certificate chain was too long.

Note that this does not require any changes at the server-side code but
rather in the way how it is operated (in the sense that one can obtain
certificates that fulfill this requirement).

Ciao
Hannes

> 
>  
> 
>  
> 
> Regards
> 
> Sandeep
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> The information contained in this message may be confidential and
> legally protected under applicable law. The message is intended solely
> for the addressee(s). If you are not the intended recipient, you are
> hereby notified that any use, forwarding, dissemination, or reproduction
> of this message is strictly prohibited and may be unlawful. If you are
> not the intended recipient, please contact the sender by return e-mail
> and destroy all copies of the original message.

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Tue, 9 Dec 2014 15:08:07 +0000

Hi Alexey,

On 28/11/2014 12:07, "Hannes Tschofenig" <[email-masked]> wrote:
>On 11/22/2014 08:08 PM, Alexey Melnikov wrote:
>>In Section 18:
>> 
>>    CoAP demands version 1.2 of DTLS to be used and the earlier version
>>    of DTLS is not supported.  As such, there is no risk of downgrading
>>    to an older version of DTLS.  The work described in
>>    [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to
>>    this environment since there is no legacy server infrastructure to
>>    worry about.
>> 
>> While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it might
>> be useful when TLS 1.3/etc gets deployed and problems are found in TLS
>> 1.2. Is this something we need to worry about in long term?
>> 
>
>I created an issue for this item:
>https://tools.ietf.org/wg/dice/trac/ticket/21

Do you think the following might be a sensible way out?

1) We explicitly tell that the handshake MUST fail hard if a version < 1.2
is negotiated;
2) once 1.3 is published, if 1.2 turns out to be flawed then deprecate 1.2
and jointly describe the use of SCSV to avoid 1.2 fallback.

Rationale: there seems to be no need for SCSV until 1.2 is shown to be
broken -- if we don't allow negotiating versions less then 1.2 in the
first place.

Cheers, t

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 18:35:33 +0100

A few remarks in addition to what Thomas said below.

The problem <draft-ietf-tls-downgrade-scsv-02> is trying to solve is
that implementations do not rely only on the TLS implemented version
negotiation mechanism.

A further assumption is that the end points are running such an insecure
version of TLS, for example, because they need to interact with some
legacy systems.

This allows an attacker to downgrade the protocol handshake to SSL 3.0
even if the protocol interaction in question could use something better.
(Obviously with the legacy system nothing better than SSL 3.0 would
work.) SSL 3.0 is so broken that there is no secure cipher available for
it. If an attacker manages to downgrade the exchange to SSL 3.0 then he
has essentially won.

To apply this to the DTLS profile document is a bit tricky since we do
not support versions older than DTLS 1.2. Of course, one could imagine a
future where DTLS 1.2 a becomes so broken that it essentially has the
quality of SSL 3.0. In that case I hope that the other recommendation
for using the software update mechanism should kick-in.

Finally, I doubt that IoT devices are less likely to support multiple
versions of DTLS/TLS since this is also a size issue. In that sense it
is rather difficult to downgrade to a different version.

While the downgrade SCSV functionality is very lightweight (from an
implementation point of view, as Manuel Pégourié-Gonnard told me) it
still does not make a lot of sense to me to support it.

Ciao
Hannes

On 12/09/2014 04:08 PM, FOSSATI, Thomas (Thomas) wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Dec 2014 23:27:54 +0100

> still does not make a lot of sense to me to support it.

It may be worth pointing out that the reason we haven’t specified SCSV support in is that we do not expect implementations of this profile to support a broken version fallback mechanism, i.e. all version negotiation MUST be using TLS mechanisms (as opposed to the ad-hoc hacks that lead to SSLv3).

Grüße, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 11 Dec 2014 14:28:44 +0000

On 10/12/2014 17:35, Hannes Tschofenig wrote:
> quality of SSL 3.0.
Yes, that is the case I am concerned about. IoT devices once installed 
might be working for years.
> In that case I hope that the other recommendation
Is this even likely?
> still does not make a lot of sense to me to support it.
I think I can buy your argument, but I suggest you add something like 
your explanation above (at least setting expectations right) to the 
document.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 15:38:33 +0100

I agree that it is useful to add some text, as Carsten also noted, to
help others to also understand our thought process.