Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[Dan Wing]

On Sep 16, 2020, at 1:08 PM, Nick Harper  
wrote:
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy  wrote:
> Hi Nick,
> 
> Please see inline
> 
> On Wed, 16 Sep 2020 at 06:00, Nick Harper  wrote:
> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
> 
> The grease_extension parameter shouldn't exist, and there should be no 
> special handling for GREASE values. GREASE doesn't need to be mentioned in 
> this draft, except to say that a client may send values (cipher suites, 
> extensions, named groups, signature algorithms, versions, key exchange modes, 
> ALPN identifiers, etc.) that are unknown to the middlebox and that the 
> middlebox MUST NOT reject connections with values unknown to the middlebox.
> 
> The grease_extension parameter in the YANG model is a "boolean" type to 
> indicate whether the GREASE values are offered by the client or not.  The MUD 
> YANG model does not convey the GREASE values.
>  
> This is still problematic.
> 
> Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to 
> check that their peers correctly ignore unknown values (instead of closing 
> the connection). If a device special-cases GREASE values when processing TLS 
> messages, that device has completely missed the purpose of GREASE and is 
> likely to cause interoperability failures when in the future it sees a TLS 
> message that contains a new extension/cipher suite/etc. that isn't a GREASE 
> value.
> 
> The IETF should not be encouraging devices to special-case GREASE values. I 
> can see no use of the grease_extension parameter in the YANG model that does 
> not involve special-casing GREASE values. Hence it needs to be removed.

Yes, that is the better way to handle GREASE:  expect Grease from any client, 
on any TLS value (as Ben pointed out supported_versions may well be Grease'd 
next).

-d

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

Re: [TLS] draft-kinnear-tls-client-net-address comments

[Dan Wing]

Good point.  Furthering that point:

- what about DTLS/SRTP when that is used with ICE (RFC8445 and its precursor 
RFC5245) and QUIC (c.f., https://w3c.github.io/webrtc-quic/).  Need guidance in 
the document to use ICE and/or quic-address-extension, as well as what it means 
if they differ (heaven forbid they differ, but ...).  
- Some motivational text and advice-to-implementor text explaining how 
ICE-over-QUIC-over-UDP is unsuitable compared to 
draft-pauly-quic-address-extension (lack of specification, desire to use same 
technique for both TLS-over-TCP and QUIC-over-UDP (perhaps), ICE too heavy (and 
can't be profiled?), or whatever the reasons are.  Such guidance will help 
developers who might happen to notice several IETF protocols that could be made 
to achieve the same ends.  
- Also need guidance that the information is time-limited, source network 
specific (different answers on Ethernet vs WiFi vs LTE) and destination 
specific (different answer is possible depending on the server queried, due to 
a NAT or Carrier Grade NAT using multiple outbound interfaces ("pooling") and 
whatever the NAT's algorithm to choose whichever outbound interface (based on 
client VLAN, performance of each outbound interface, etc., who knows).  NAT 
pooling can be a significantly complicated issue 
(https://tools.ietf.org/html/rfc4787#page-7.
- Does anyone see a need for a well-known underscore name to retrieve this 
information from a web server?  As written both drafts work with TLS and with 
QUIC, which means they don't require an HTTP server on the far side so works 
with SMTP, IMAP, etc.  However, I could see it being difficult for an 
application to learn its public IP address (needs to get its TLS or QUIC 
implementation to support these I-Ds).  Supporting this over HTTP has the 
advantage that both the OS and an application can programmatically learn its 
public IP address.  
- As already mentioned, MPTCP complicates the answer from the server, as will 
multipath QUIC (which publicly appears to be stalled, but we should reasonably 
expect it might come to life again).  Guidance text needs to be added, or 
perhaps we can safely punt the problem with 'for further study' and recommend 
against using it with MPTCP?
- Finally, the datastructure doe not convey protocol; I worked on a TCP-to-SCTP 
gateway a few years ago and one might envision a TCP-to-QUIC gateway or 
QUIC-to-QUIC8 gateway in 2030.  Should we anticipate that and include protocol 
number to fully qualify the port number that exists already in the 
datastructure?  I honestly don't know the answer to that, but throwing it out 
for consideration.

-d


> On Mar 21, 2019, at 12:26 AM, Jim Schaad  wrote:
> 
> I have not looked at this draft yet, but what about DTLS/UDP?
> 
> Jim
> 
> 
>> -Original Message-
>> From: TLS  On Behalf Of Tommy Pauly
>> Sent: Wednesday, March 20, 2019 3:00 PM
>> To: Martin Thomson 
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] draft-kinnear-tls-client-net-address comments
>> 
>> The QUIC and TLS drafts were written together, and are quite similar as
> you
>> note. The intention is to use the TLS extension over TLS/TCP connections,
>> and the QUIC extension for QUIC/UDP.
>> 
>> I agree that QUIC as a protocol benefits more from the extension than TLS
>> does, but applications on top of both can benefit by detecting NATs, for
>> making decisions about long-lived connections and privacy mitigations.
>> 
>> Thanks,
>> Tommy
>> 
>>> On Mar 20, 2019, at 2:26 AM, Martin Thomson 
>> wrote:
>>> 
>>> I see a substantially similar draft in
> draft-pauly-quic-address-extension.  I'd
>> like to understand how these might be complementary, or whether the idea
>> is to pursue only one.  The QUIC extension seems superior, if you have
> QUIC.
>> There are a lot more plausible reasons to want this information in QUIC
>> though.
>>> 
>>> Nits:
>>> 
>>> The format of the extension is not ideal.  Wouldn't you want to know
> which
>> family it came from?
>> 
>> I think the intention was to use the length to infer the family.
>>> 
>>> The term of art is reflexive address (or reflected address).
>> 
>> Thanks, good to know!
>>> 
>>> ___
>>> 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] The future devices that will break TLS 1.4

[Dan Wing]

On Jan 12, 2018, at 3:02 PM, Hanno Böck  wrote:
> 
> Hi,
> 
> This working group just went through a painful process of realizing
> that deploying a new TLS version on the Internet is a hard task due to
> broken devices. If you're not aware David Benjamin just gave a great
> talk summarizing the issues:
> https://www.youtube.com/watch?v=_mE_JmwFi1Y
> 
> Today I found this article:
> https://www.theregister.co.uk/2018/01/11/cisco_sniff_malware_inside_encrypted_traffic/
> 
> tl;dr Cisco now says they can identify malware in TLS traffic by
> carefully looking at it.
> (For context: devices from Cisco were responsible for many of the
> issues that made deploying TLS 1.3 hard, e.g. version intolerance on
> load balancers and recently by not correctly terminating TLS in a
> firewall.)

Those bugs that interfere with TLS handshakes are un-related to Cisco's 
Encrypted Traffic Analytics ("ETA").  Different technologies.

-d


> I'll dare to have a look into the future and make this imho very
> plausible claim:
> Cisco won't be the only vendor selling such things. We will see more
> products that magically can identify "bad things" in TLS traffic by
> applying everything from AI to Blockchain.
> We will almost certainly see a whole new generation of devices doing
> weirdness with TLS and who will drop or manipulate packages that contain
> things they don't know (like... a version negotiation field with TLS
> 1.4 or a large post quantum key exchange message).
> 
> The question I want to ask: What can we do *now* to stop this from
> happening when TLS 1.4 will be deployed? I have the feeling GREASE
> won't be enough...
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> 
> ___
> 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] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[Dan Wing]

> On Jul 16, 2017, at 8:39 PM, yinxinxing <yinxinx...@huawei.com> wrote:
> 
> Hi Wing,
> 
> I noticed that Helloverifyrequest is optional by the server and used when DOS 
> is to be mitigated. 
> 
> But from practical use cases, the IOT server may not have dedicated anti-DOS 
> mechanism. 
> 
> If there is a more power-saving solution with the function of DOS mitigation 
> retained, and don't need to bother the server(customer) to deploy anti-DOS 
> devices, why not have a try?  

Sure.  You might work with the authors of draft-mavrogiannopoulos-tls-cid to 
add more considerations around denial of service, perhaps also a longer cid as 
you suggested earlier.

-d


> Regards,
> Yin Xinxing
> 
> -邮件原件-----
> 发件人: yinxinxing 
> 发送时间: 2017年7月13日 16:56
> 收件人: 'Dan Wing'
> 抄送: tls@ietf.org; Sean Turner
> 主题: 答复: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> Hi Wing,
> 
> Please see the comments inline
> 
> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: Dan Wing [mailto:danw...@gmail.com] 
> 发送时间: 2017年7月13日 12:35
> 收件人: yinxinxing
> 抄送: tls@ietf.org; Sean Turner
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> 
>> On Jul 12, 2017, at 7:11 PM, yinxinxing <yinxinx...@huawei.com> wrote:
>> 
>> Thanks Wing,
>> 
>> Please see my comments inline.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> -邮件原件-
>> 发件人: Dan Wing [mailto:danw...@gmail.com] 
>> 发送时间: 2017年7月13日 8:52
>> 收件人: yinxinxing
>> 抄送: tls@ietf.org; Sean Turner
>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
>> with high power consumption in DTLS1.2
>> 
>> 
>>> On Jul 12, 2017, at 5:21 PM, yinxinxing <yinxinx...@huawei.com> wrote:
>>> 
>>> Hi Dan Wing,
>>> 
>>> Thanks for your comments.
>>> 
>>> Please see my comments inline.
>>> 
>>> Regards,
>>> Yin Xinxing
>>> 
>>> -邮件原件-
>>> 发件人: Dan Wing [mailto:danw...@gmail.com] 
>>> 发送时间: 2017年7月13日 1:09
>>> 收件人: yinxinxing
>>> 抄送: tls@ietf.org; Sean Turner
>>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
>>> with high power consumption in DTLS1.2
>>> 
>>> 
>>>> On Jul 12, 2017, at 7:56 AM, Sean Turner <s...@sn3rd.com> wrote:
>>>> 
>>>> 
>>>>> On Jul 6, 2017, at 23:04, yinxinxing <yinxinx...@huawei.com> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> The NAT table expiring problem mentioned in the  following email should 
>>>>> also be considered in DTLS1.2 as an extension.
>>>>> 
>>>>> The value and necessity are as follows.
>>>>> 
>>>>> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
>>>>> power consumption is existing in DTLS 1.2. Even if we solve this in 
>>>>> DTLS1.3, this problem still exist for products using DTLS1.2.
>>>>> Currently, many IOT products using DTLS 1.2 are going to be deployed 
>>>>> commercially, such as intelligent water/gas meter. These meters usually 
>>>>> have limited battery and low cost. To be more accurate, the battery of 
>>>>> the chip module of the intelligent water/gas meter are required to last 
>>>>> for 10 years. These lead to an exercise strict control over the power 
>>>>> consumption of the chip module. NAT expiring problem causing DTLS 
>>>>> renegotiation with high power consumption is a bottleneck of these IOT 
>>>>> devices. According to our experimental data, under the worst coverage 
>>>>> level (ECL2), power consumption of the chip module when DTLS is embedded 
>>>>> increases by nearly 60%. Therefore, there should be a solution to solve 
>>>>> the urgent problem to match the low-cost and low-battery feature of the 
>>>>> IOT devices in DTLS 1.2.
>>>> 
>>>> I have to ask whether these IoT devices are updatable?
>>>> 
>>>>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open 
>>>>> source code will be available about one year later after the 
>>>>> standardization. At present, large-scale commercial IOT industry 
>>>>> deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope 
>>&

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[Dan Wing]

> On Jul 12, 2017, at 7:11 PM, yinxinxing <yinxinx...@huawei.com> wrote:
> 
> Thanks Wing,
> 
> Please see my comments inline.
> 
> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: Dan Wing [mailto:danw...@gmail.com] 
> 发送时间: 2017年7月13日 8:52
> 收件人: yinxinxing
> 抄送: tls@ietf.org; Sean Turner
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> 
>> On Jul 12, 2017, at 5:21 PM, yinxinxing <yinxinx...@huawei.com> wrote:
>> 
>> Hi Dan Wing,
>> 
>> Thanks for your comments.
>> 
>> Please see my comments inline.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> -邮件原件-
>> 发件人: Dan Wing [mailto:danw...@gmail.com] 
>> 发送时间: 2017年7月13日 1:09
>> 收件人: yinxinxing
>> 抄送: tls@ietf.org; Sean Turner
>> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
>> with high power consumption in DTLS1.2
>> 
>> 
>>> On Jul 12, 2017, at 7:56 AM, Sean Turner <s...@sn3rd.com> wrote:
>>> 
>>> 
>>>> On Jul 6, 2017, at 23:04, yinxinxing <yinxinx...@huawei.com> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> The NAT table expiring problem mentioned in the  following email should 
>>>> also be considered in DTLS1.2 as an extension.
>>>> 
>>>> The value and necessity are as follows.
>>>> 
>>>> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
>>>> power consumption is existing in DTLS 1.2. Even if we solve this in 
>>>> DTLS1.3, this problem still exist for products using DTLS1.2.
>>>> Currently, many IOT products using DTLS 1.2 are going to be deployed 
>>>> commercially, such as intelligent water/gas meter. These meters usually 
>>>> have limited battery and low cost. To be more accurate, the battery of the 
>>>> chip module of the intelligent water/gas meter are required to last for 10 
>>>> years. These lead to an exercise strict control over the power consumption 
>>>> of the chip module. NAT expiring problem causing DTLS renegotiation with 
>>>> high power consumption is a bottleneck of these IOT devices. According to 
>>>> our experimental data, under the worst coverage level (ECL2), power 
>>>> consumption of the chip module when DTLS is embedded increases by nearly 
>>>> 60%. Therefore, there should be a solution to solve the urgent problem to 
>>>> match the low-cost and low-battery feature of the IOT devices in DTLS 1.2.
>>> 
>>> I have to ask whether these IoT devices are updatable?
>>> 
>>>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open 
>>>> source code will be available about one year later after the 
>>>> standardization. At present, large-scale commercial IOT industry 
>>>> deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope 
>>>> that the above problem could be solved in DTLS 1.2 as soon as possible.
>>> 
>>> On this point, I’m hoping that you’ll be wrong ;). From the list of TLS 
>>> implementations found here:
>>> https://github.com/tlswg/tls13-spec/wiki/Implementations
>>> and assuming there is as much enthusiasm to implement DTLS1.3 as there was 
>>> for TLS1.3 then I’m hoping that the DTLS implementations will be ready much 
>>> sooner than a year after publication (they might be ready before the RFC is 
>>> published).
>> 
>> 
>>> Yin Xinxing,
>> 
>>> While waiting for cid, perhaps today do session resumption (RFC5077), 
>>> anytime the client has reason to suspect their UDP port or IP address might 
>>> have changed -- such as it's been longer than, say, 30 seconds since last 
>>> UDP transmission.  (The problem isn't solely NAT; there are several ISPs 
>>> that change subscriber's IP address, >also forcing re-negotiation of DTLS 
>>> security association.  Less frequent than NATs timing out UDP, of course.)
>> 
>>> -d
>> [Yin] Yes, you are right. The problem isn't solely NAT expiring, but 
>> changing from WLAN to 3GPP, or IOT devices waking up from sleep mode. All of 
>> these could lead to IP change.
>> Session resumption is a good way to re-negotiate the DTLS session. However, 
>> according to our IOT products, e.g., intelligent water/gas meter, session 
>> resumption mechanism still needs to communicate 6 or 5 messages(based on the 
>> cipher suite TLS_PSK_WITH_AES_128_CBC_SHA25

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[Dan Wing]

> On Jul 12, 2017, at 5:21 PM, yinxinxing <yinxinx...@huawei.com> wrote:
> 
> Hi Dan Wing,
> 
> Thanks for your comments.
> 
> Please see my comments inline.
> 
> Regards,
> Yin Xinxing
> 
> -邮件原件-
> 发件人: Dan Wing [mailto:danw...@gmail.com] 
> 发送时间: 2017年7月13日 1:09
> 收件人: yinxinxing
> 抄送: tls@ietf.org; Sean Turner
> 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation 
> with high power consumption in DTLS1.2
> 
> 
>> On Jul 12, 2017, at 7:56 AM, Sean Turner <s...@sn3rd.com> wrote:
>> 
>> 
>>> On Jul 6, 2017, at 23:04, yinxinxing <yinxinx...@huawei.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> The NAT table expiring problem mentioned in the  following email should 
>>> also be considered in DTLS1.2 as an extension.
>>> 
>>> The value and necessity are as follows.
>>> 
>>> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
>>> power consumption is existing in DTLS 1.2. Even if we solve this in 
>>> DTLS1.3, this problem still exist for products using DTLS1.2.
>>> Currently, many IOT products using DTLS 1.2 are going to be deployed 
>>> commercially, such as intelligent water/gas meter. These meters usually 
>>> have limited battery and low cost. To be more accurate, the battery of the 
>>> chip module of the intelligent water/gas meter are required to last for 10 
>>> years. These lead to an exercise strict control over the power consumption 
>>> of the chip module. NAT expiring problem causing DTLS renegotiation with 
>>> high power consumption is a bottleneck of these IOT devices. According to 
>>> our experimental data, under the worst coverage level (ECL2), power 
>>> consumption of the chip module when DTLS is embedded increases by nearly 
>>> 60%. Therefore, there should be a solution to solve the urgent problem to 
>>> match the low-cost and low-battery feature of the IOT devices in DTLS 1.2.
>> 
>> I have to ask whether these IoT devices are updatable?
>> 
>>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open source 
>>> code will be available about one year later after the standardization. At 
>>> present, large-scale commercial IOT industry deployment is urgent, it is 
>>> too late to wait for DTLS 1.3. Thus, we hope that the above problem could 
>>> be solved in DTLS 1.2 as soon as possible.
>> 
>> On this point, I’m hoping that you’ll be wrong ;). From the list of TLS 
>> implementations found here:
>> https://github.com/tlswg/tls13-spec/wiki/Implementations
>> and assuming there is as much enthusiasm to implement DTLS1.3 as there was 
>> for TLS1.3 then I’m hoping that the DTLS implementations will be ready much 
>> sooner than a year after publication (they might be ready before the RFC is 
>> published).
> 
> 
>> Yin Xinxing,
> 
>> While waiting for cid, perhaps today do session resumption (RFC5077), 
>> anytime the client has reason to suspect their UDP port or IP address might 
>> have changed -- such as it's been longer than, say, 30 seconds since last 
>> UDP transmission.  (The problem isn't solely NAT; there are several ISPs 
>> that change subscriber's IP address, >also forcing re-negotiation of DTLS 
>> security association.  Less frequent than NATs timing out UDP, of course.)
> 
>> -d
> [Yin] Yes, you are right. The problem isn't solely NAT expiring, but changing 
> from WLAN to 3GPP, or IOT devices waking up from sleep mode. All of these 
> could lead to IP change.
> Session resumption is a good way to re-negotiate the DTLS session. However, 
> according to our IOT products, e.g., intelligent water/gas meter, session 
> resumption mechanism still needs to communicate 6 or 5 messages(based on the 
> cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256) and this re-negotiation 
> mechanism still costs too much battery and can not ensure 10-year lifetime of 
> the IOT products' battery. 

I see 3 messages and no cryptographic operations for the client in Figure 2 of 
https://tools.ietf.org/html/rfc5077#page-5.  So I guess you're saying the IoT 
device can't send two packets and receive one packet without impacting its 
battery.  I agree 'cid' is more efficient, but it isn't yet standardized.  I 
would consider doing RFC5077 and then, when 'cid' or DTLS 1.3 is available, 
update the devices to support 'cid' or DTLS 1.3, as Sean implied when he asked 
if the devices could be updated.

(I hope the devices aren't using the same pre-shared key!  That would be bad.)

-d




> 
>> spt
>> 
>>> Any comment is appr

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

[Dan Wing]

> On Jul 12, 2017, at 7:56 AM, Sean Turner  wrote:
> 
> 
>> On Jul 6, 2017, at 23:04, yinxinxing  wrote:
>> 
>> Hi all,
>> 
>> The NAT table expiring problem mentioned in the  following email should also 
>> be considered in DTLS1.2 as an extension.
>> 
>> The value and necessity are as follows.
>> 
>> 1. Essentially, NAT expiring problem causing DTLS renegotiation with high 
>> power consumption is existing in DTLS 1.2. Even if we solve this in DTLS1.3, 
>> this problem still exist for products using DTLS1.2.
>> Currently, many IOT products using DTLS 1.2 are going to be deployed 
>> commercially, such as intelligent water/gas meter. These meters usually have 
>> limited battery and low cost. To be more accurate, the battery of the chip 
>> module of the intelligent water/gas meter are required to last for 10 years. 
>> These lead to an exercise strict control over the power consumption of the 
>> chip module. NAT expiring problem causing DTLS renegotiation with high power 
>> consumption is a bottleneck of these IOT devices. According to our 
>> experimental data, under the worst coverage level (ECL2), power consumption 
>> of the chip module when DTLS is embedded increases by nearly 60%. Therefore, 
>> there should be a solution to solve the urgent problem to match the low-cost 
>> and low-battery feature of the IOT devices in DTLS 1.2.
> 
> I have to ask whether these IoT devices are updatable?
> 
>> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open source 
>> code will be available about one year later after the standardization. At 
>> present, large-scale commercial IOT industry deployment is urgent, it is too 
>> late to wait for DTLS 1.3. Thus, we hope that the above problem could be 
>> solved in DTLS 1.2 as soon as possible.
> 
> On this point, I’m hoping that you’ll be wrong ;). From the list of TLS 
> implementations found here:
> https://github.com/tlswg/tls13-spec/wiki/Implementations
> and assuming there is as much enthusiasm to implement DTLS1.3 as there was 
> for TLS1.3 then I’m hoping that the DTLS implementations will be ready much 
> sooner than a year after publication (they might be ready before the RFC is 
> published).


Yin Xinxing,

While waiting for cid, perhaps today do session resumption (RFC5077), anytime 
the client has reason to suspect their UDP port or IP address might have 
changed -- such as it's been longer than, say, 30 seconds since last UDP 
transmission.  (The problem isn't solely NAT; there are several ISPs that 
change subscriber's IP address, also forcing re-negotiation of DTLS security 
association.  Less frequent than NATs timing out UDP, of course.)

-d


> spt
> 
>> Any comment is appreciated.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> 
>> 发件人: yinxinxing 
>> 发送时间: 2017年6月27日 16:28
>> 收件人: 'Eric Rescorla'
>> 抄送: tls@ietf.org; Tobias Gondrom
>> 主题: Re: [TLS] Yin Xinxing joins the TLS WG
>> 
>> Thanks Eric,
>> 
>> I have seen the CID scheme, and talked with Hannes(the author of the scheme).
>> 
>> CID scheme is a good idea to solve the problem I mentioned.
>> 
>> I think the length of CID (currently, it is 32 bits) can be longer so that 
>> it can support more DTLS sessions. It is known that for IOT scenario, 1 
>> million connection is nothing.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> 发件人: Eric Rescorla [mailto:e...@rtfm.com] 
>> 发送时间: 2017年6月25日 21:33
>> 收件人: yinxinxing
>> 抄送: tls@ietf.org; Xiongxiaochun
>> 主题: Re: [TLS] Yin Xinxing joins the TLS WG
>> 
>> Hi Yin,
>> 
>> The usual solution to this is to add a connection id. Please see:
>> https://github.com/tlswg/dtls13-spec/issues/6
>> 
>> -Ekr
>> 
>> 
>> 
>> 
>> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing  wrote:
>> Hello everyone,
>> 
>> I am Yin Xinxing from Huawei company. I am glad to join the TLS WG.
>> 
>> For the DLTS 1.3 draft, I am interested and have some ideas to talk with you.
>> 
>> DTLS has a lot of application scenarios in IOT fields, but currently, there 
>> is some difficulty when DTLS 1.2 is applied to IOT devices, especially the 
>> battery-constrained IOT devices.
>> 
>> For example, when the IOT device wakes up from sleep mode, the NAT table may 
>> have expired.
>> Then the IOT device has to establish a new DTLS session or at least launches 
>> a resume process with the server, the corresponding power consumption is too 
>> high for some power-constrained devices. 
>> How can DTLS renegotiation be avoided in order to save battery?
>> 
>> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem 
>> and give a proper solution.  
>> 
>> Any comment or idea about this problem is welcome.
>> 
>> Regards,
>> Yin Xinxing
>> 
>> ___
>> 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
> 
>