Re: [TLS] Getting started, clock not set yet
Hal Murray writes: >Many security schemes get tangled up with time. TLS has time limits on >certificates. That presents a chicken-egg problem for NTP when getting >started. > >I'm looking for ideas, data, references, whatever? For commercial CAs, the expiry time is a billing mechanism, not a security mechanism. A certificate is no more, or less, valid at 23:59:59 than it is at 00:00:01, no matter what the subscription renewal time in it says. It's fairly widespread practice in SCADA to completely ignore expiry times because equipment that takes itself offline at 4am at a site six hours' drive away because of an expired certificate is the last thing you want. So set up the TLS connection, ignore the expiry time, perform your NTP update, and then if necessary do the expiry check (unless it's SCADA gear, in which case don't). Nothing of value will be lost. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Getting started, clock not set yet
I work on NTP software. NTS (Network Time Security) uses TLS. Many security schemes get tangled up with time. TLS has time limits on certificates. That presents a chicken-egg problem for NTP when getting started. I'm looking for ideas, data, references, whatever? Is there other work in this area? Is there any sort of consensus on how close a clock needs to be when checking certificates? At this point, I divide the problem into 3 chunks. The first case is easy. I'll call it the RTC case. Most PCs, laptops, and servers have some sort of battery backed clock. As long as it is close enough, everything just works. But how close is close enough? You need a plan for when the battery dies and such. Set the clock from the BIOS. ssh in and set the clock. That requires setting up the ssh keys ahead of time. The second case is something like a Raspberry Pi. They don't have RTCs. Debian has a fake-hwclock module that writes the time to the disk every hour. I call this the one year case. What happens when you leave it on the shelf for a year? Certificates are generally available with only a 1 year lifetime. That's built into popular browsers so everybody else gets stuck with the decision. After a year, nothing works. After 6 months, half of your servers should still work. A vendor could setup 2 servers with their certificates 6 months out of phase so that 1 will last at least a year. Note that games and IoT gear sold through retail channels will hit this problem if they sit on a shelf for a year. The really hard case is the 10 year problem. Consider a spare board sitting on the shelf for 10 years. That's longer than batteries will last for RTCs. Phone companies used to work on this time frame. I think we need to provide them guidance. I've seen two ways. One is to manually set the clock somewhere in the replace-the-board process. I'm picturing a USB port where the technician can plug in his laptop. The laptop can set the time. The other is to use a certificate with a long lifetime. Are those available or does that turn into a self-signed certificate? There is also DNSSEC. I don't know anything about that yet. For the 1 year or 10 year cases, you could "cache" the data in /etc/hosts. Then you need a cron job to keep the cache up to date. Does this make sense? Am I on the right track? ... -- These are my opinions. I hate spam. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData
Hello everyone. I decided to get involved here since I hit a dead end when resolving an Alert(20) error that I get from almost all servers when using PSK with EarlyData. Here's the initial issue I opened https://github.com/thekuwayama/tttls1.3/issues/48. It relates to a specific implementation but my questions are general. There's also a code snippet that you can run and see the issue yourself. So it happens that when sending a GET request as EarlyData and then completing the handshake with EndOfEarlyData following the ClientFinished message, a server (e.g. ssltest.louis.info) successfully sends a complete response but finishes the request with Alert(20) message. It doesn't happen on 1-RTT nor 0-RTT(without early data). If I don't send ClientFinished in 0-RTT+EarlyData I don't get Alert(20) and everything works as expected. I don't see anything in the spec that would describe something like this or would point to a different way for calculating the ClientFinished for 0-RTT+EarlyData case. Is maybe this sentence from the spec "PSK-based authentication happens as a side effect of key exchange." something that some of us miss interpreter and states that Finished message should be verified and sent only in 1-RTT? What could be the case here? Thank you in advance. Kristijan ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What is "completed handshake"?
Peace, On Mon, Aug 8, 2022 at 4:19 PM Dmitry Belyavsky wrote: > RFC 8446 refers to "completed handshake" as a prerequisite for some messages. > But looking for the word "completed", I don't see any definition. Section "2. Protocol Overview", page 13 says: "Upon receiving the server's messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished. At this point, the handshake is complete" -- Töma ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] What is "completed handshake"?
Dear colleagues, RFC 8446 refers to "completed handshake" as a prerequisite for some messages. But looking for the word "completed", I don't see any definition. Could you please point me to it (and probably, include this definition into rfc8446-bis)? Many thanks! -- SY, Dmitry Belyavsky ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
