Re: [TLS] Don't Split HelloRetryRequest
I've created a few pull requests that make the changes I propose. I think that the whole suite of related issues are closed as a result. The main one is here: https://github.com/tlswg/draft-ietf-tls-esni/pull/417 There's a bit of rewriting here, but the change is not that large. I would expect most implementations to be compliant already (it's much more work not to be). The whole set: https://github.com/tlswg/draft-ietf-tls-esni/pulls/martinthomson On Thu, Apr 1, 2021, at 12:57, Martin Thomson wrote: > I just reviewed the proposal to split HelloRetryRequest into outer and > (encrypted) inner. > > https://github.com/tlswg/draft-ietf-tls-esni/pull/407/files > > I'm strongly opposed to taking the change. It complicates the design > greatly and unnecessarily. > > The existing design has some flaws, but they can be fixed more > elegantly than this. > > (Apologies if this seems a little long. I'm writing down every > possible argument I can think of, because I can't guarantee that I will > be coherent at the meeting.) > > # HelloRetryRequest Has a Narrow Purpose > > Let's first address the key question of what HelloRetryRequest exists > to do. It exists to ensure that the client and server are able to > jointly agree on keys to use for the remainder of the handshake. This > is a very narrow scope. > > Furthermore, the particulars of key agreement are public. This is > important as we can also say that all hidden servers need to use the > same configuration as it relates to cipher suites, key exchange, and > related parameters, as the results of negotiation are sent in the clear > in the ServerHello. > > My claim here is that there is no value in protecting any parameter > that might change in response to HelloRetryRequest. > > # Don't Seek Complexity > > It is entirely possible to imagine scenarios where an inner ClientHello > has different preferences from an outer ClientHello. While in theory > we can construct a design that would support that (the pull request > does this well enough), to do so only serves to increase complexity. > It does not address any real use case or problem that I'm aware of. > > If we allow for the client to provide different values in inner and > outer ClientHello messages, then the current design means that the > client is faced with some ambiguity about which of the two messages a > HelloRetryRequest applies to. If we try to create an indicator, then > that leaks. > > We could solve the problem by making the protocol more complex. Or we > could avoid it. > > This problem is entirely avoidable. > > # Matching Inner and Outer Values > > When we get right down to it, there are a very small number of things > that truly change in response to HelloRetryRequest. And all of these > changes are to values that do not need confidentiality protection. > > The draft lists three fields that change: ciphersuites, key_share, and > version. From my perspective, changing cipher suites, supported > groups, or versions would be a big mistake. So what changes is even > more limited. Just the shares in key_share. > > On this basis, a client that offers cipher suites, groups, versions, > and key shares that are identical in both inner and outer ClientHello > messages will always receive a HelloRetryRequest that applies equally > to both messages. > > The only adjustment that is acceptable with respect to these fields > being identical is the addition of TLS 1.2-only options to the outer > ClientHello (or the removal of the same from the inner ClientHello if > you prefer it that way around). This is a fine optimization on the > basis that accepting ECH represents a commitment to support TLS 1.3 (or > higher). But it is really just an optimization (the draft makes this > mandatory, which is silly). The client can therefore remove options > from the inner ClientHello only if it is impossible to select them with > TLS 1.3 or higher. > > For new extensions, if they define a means of adjustment or correction > via HelloRetryRequest (there is currently just one: password_salt, > which I haven't examined), then they too need to follow this > restriction. It's not an onerous one. > > Follow this simple constraint and HelloRetryRequest will always apply > equally to both inner and outer ClientHello and everything works. > Conveniently, this is more or less exactly what the current draft says. > Almost. > > The draft currently allows inner and outer ClientHello to have > different types of key share. The way it handles this is terrible: it > recommends breaking the transcript. To me, that seems like it would > only serve to open the protocol up to downgrade attack. > > Incidentally, I don't see a problem with having a different key share > *value* in inner and outer ClientHello. There's no point in doing that > unless you believe that these values leak information (they really > shouldn't), but it wouldn't break
Re: [TLS] Transport Issues in DTLS 1.3
Thanks for the discussion. I have pushed the following PR to address your comments: https://github.com/tlswg/dtls13-spec/pull/226 Here is a summary of the changes: - Change the default retransmission timer to 1s and allow people to do otherwise if they have side knowledge. - Cap any given flight to 10 records - Don't re-set the timer to the initial value but to 1.5 times the measured RTT. - A bunch more clarity about the reliability algorithms and timers (including changing reset to re-arm) PTAL -Ekr On Tue, Mar 30, 2021 at 11:47 AM Martin Duke wrote: > Thank you Eric (and Mark). > > To reiterate, I believe introducing latency regressions with respect to > DTLS 1.2 would be bad for the internet. So what's new in the area under > discussion is (a) lowering the timeout from 1s to 100ms, and (b) the > introduction of ACKs. > > I would characterize ekr's reply as making the following points: > > (1) *DTLS practice at Mozilla and elsewhere already uses timeouts << 1 > sec*. > > Thanks for this report about the real world. I have no doubt that for > WebRTC and other use cases, a short timeout is fine. However, DTLS is a > general-purpose protocol and the standard should be quite conservative > about the paths this thing is going to run over. Obviously, people are > going to ignore this requirement when they think they can get an advantage > no matter what the RFC says. > > I see three acceptable ways to proceed: > (a) stick with 1 second with words saying that given some OOB knowledge > you can go lower; > (b) the same, but having an explicit floor of 100ms or 200ms; or > (c) having a shorter threshold for small flights, as I proposed in my > DISCUSS > > (2) *DTLS 1.2 does full retransmissions on each timeout, and there is no > window halving.* > > This is a good point, but I will note that 1.2 always has an RTO-based > timeout, so the sending rate is halved because the timeout doubles each > time. With an ACK, there will be no rate halving, unless the ACK clears > half the window or more. > > That said, Mark doesn't seem to be too concerned about it. The > constrained-network problem where these bursts are just too large already > exists in DTLS 1.2 so I'm increasingly persuaded that it's OK to drop this > issue. > > Mark said a lot about RTT measurement in his reply. I gather from the > draft that there is no such measurement going on, but including it would be > another way to address some of the backoff issues. > > (3) *The applicability of this algorithm is at most a few packets, which > strictly limits the risk in a way that renders RFC 8085, etc. > considerations largely irrelevant.* > > The strawman in my DISCUSS was that bursts of <= 2 packets could be more > aggressive; that's a negotiable number, and the de jure TCP 4*MSS initial > window, for example, is one I can easily be persuaded of. I feel some > desire to guard against giant post-quantum certificates, or what have you, > but some sufficiently wide guardrails here will probably have little or no > short-term real-world impact, and I trust we can reach a mutually agreeable > number. The largest flights today in DTLS 1.2 seem like a good number that > addresses my concerns while respecting my no-regressions principle. > > Thanks, > Martin > > On Tue, Mar 30, 2021 at 10:48 AM Mark Allman > wrote: > >> >> Hi Ekr! >> >> > This means that we have rather more latitude in terms of how >> > aggressively we retransmit because it only applies to a small >> > fraction of the traffic. >> >> (Strikes me as a bit of a weird formulation.) >> >> > Firefox uses 50ms and AIUI Chrome >> > uses a value derived from the ICE handshake (which is probably >> > better because there are certainly times where 50ms is too short). >> >> Yes- the best thing to do is to use a measured value instead of >> assuming on static number will always work. But, you have to get a >> measurement to do that, so you have to start somewhere. >> >> >> Relatedly, in section 5.8.3 there is no specific recommendation for a >> >> maximum flight size at all. I would think that applications SHOULD >> >> have no more than 10 datagrams outstanding unless it has some OOB >> >> evidence of available bandwidth on the channel, in keeping with de >> >> facto transport best practice. >> > >> > I agree that this is a reasonable change. >> >> I like this, too. I think that limits the impact of any sort of >> badness. >> >> >> Granted, doubling the timeout will reduce the rate, but when >> >> retransmission is ack-driven there is essentially no reduction of >> >> sending rate in response to loss. >> > >> > I don't believe this is correct. Recall that unlike TCP, there's >> > generally no buffer of queued packets waiting to be transmitted. >> > Rather, there is a fixed flight of data which must be delivered. >> > With one exceptional case [1], an ACK will reflect that some but >> > not all of the data was delivered and processed; when >> > retransmitting, the sender will only retransmit
Re: [TLS] DTLS/SCTP and fragmentation
You could also do SCTP over DTLS, which is what WebRTC uses. On Tue, Apr 6, 2021, at 02:40, Rick van Rein wrote: > Hello Michael, > > Thank you! I was searching for options, things that should go into > DTLS, but I was unaware of the attempts of mapping it better to SCTP. > > > What about using: > > https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01 > > This looks very good, thank you for the pointer! > > -Rick > > ___ > 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] ECH-10 interop test server
Hiya, On 05/04/2021 18:01, Christopher Patton wrote: Hi list, just FYI that Cloudflare's test server is upgrading to draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few hours. Note that we've dropped support for draft-ietf-tls-esni-09. The endpoint is https://crypto.cloudflare.com. You'll also find our ECH config in the HTTPS resource record. Good stuff. I have a client that thinks it's ready to go but we'll see:-) I also have an openssl s_server running on port 8410 at draft-10.esni.defo.ie with an ECHConfig published in the DNS for that. It's probably v. fragile, so likely best to contact me if playing with it. That works with my draft-10 openssl s_client and with a build of curl using my fork of the openssl library. Cheers, S. Best, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] ECH-10 interop test server
Hi list, just FYI that Cloudflare's test server is upgrading to draft-ietf-tls-esni-10 this morning. It should finish rolling out in a few hours. Note that we've dropped support for draft-ietf-tls-esni-09. The endpoint is https://crypto.cloudflare.com. You'll also find our ECH config in the HTTPS resource record. Best, Chris P. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
Hello Michael, Thank you! I was searching for options, things that should go into DTLS, but I was unaware of the attempts of mapping it better to SCTP. > What about using: > https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01 This looks very good, thank you for the pointer! -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS/SCTP and fragmentation
> On 5. Apr 2021, at 14:12, Rick van Rein wrote: > > Hi, > > Larger frames than the MTU are not just a problem to Diameter; they also > complicate the normal handshake in DTLS which is a bit of a misfit with > DTLS delivery semantics. > > Since the version is bit-swapped in DTLS, each record can easily be > distinguished as being either DTLS or TLS. Then, why not allow the > mixing of those records in a stream, and map them differently to the > transport protocol? Why do to use TLS over SCTP? It has substantial limitations. That is why DTLS over SCTP was specified. > > I suppose the records could be marked as being the first and/or last in > a large user message, and this could be meaningfully translated to > properties and behaviour of the transport. Below the DTLS MTU, > information is sent as DTLS, and above it, it is sent as a sequence of > TLS frames -- or are rejected, if the transport cannot handle that. > Plain TLS could be a special case where the DTLS MTU is set to 0. You still would need to preserve message boundaries, don't you? > > Datagrams may have a number of meanings, too, that translate to > different transport meanings. Diameter differs from RTP in that it > wants reliable delivery (which is why it does not carry over UDP) but it > is like RTP in that it does not want ordered delivery. Plain TLS > applications would present the usecase of reliable ordered delivery. My understanding is that Diameter wants reliable unordered delivery. So basically you can send every diameter message as an unordered SCTP user message. At least this is what is described in https://tools.ietf.org/html/rfc6733#section-2.1.1 Best regards Michael > > > Hopefully helpful, > -Rick > > ___ > 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/SCTP and fragmentation
> On 2. Apr 2021, at 23:46, Rick van Rein wrote: > > Hello, > > I was looking into DTLS/SCTP as a carrier for Diameter. Lengths in > Diameter are 24 bit to avoid ever having to bother about that, but when > run over the preferred DTLS/SCTP carrier this may yet be a concern, so > that its only option is to fallback to a _separate_ TLS/TCP connection: > > * For DTLS over TCP or SCTP, which automatically fragment and > reassemble datagrams, there is no PMTU limitation. However, the > upper layer protocol MUST NOT write any record that exceeds the > maximum record size of 2^14 bytes. > > SCTP can offer better guarantees than UDP; this relaxation may provide > leverage to split a large application message into a sequence of DTLS > frames carried under specific guarantees. > > 1. To handle a larger application message, it is split into pieces >of 2^14 bytes, followed by one that has <2^14 (possibly 0) bytes. >Fragments are sent to the same stream, without interleaving other >content, and in-order. Upon reception, the DTLS frames are each >decoded and the result concatenated to recover the message. Doesn't that results in head of line blocking? > > 2. Since delivery is reliable for SCTP, it would (also) be possible >to send the same sequence number for the fragments. The sequence >number field is not as useful for SCTP as it is for UDP. > > 3. It may be an idea to allocate one stream for all fragmentation. >But even within a stream, it is possible to combine in-order and >out-of-order. It is probably good to continue in-order sending >until the <2^14 sized DTLS frame is acknowledged. The application >or DTLS handshake may further constrain this. > > These are three possible ways of relaxing this. If we pick a simple > one, like the 1st, we might pass more SCTP semantics over to the > application that wants DTLS but not its size constraints. What DTLS > does to Diameter is best resolved. What about using: https://tools.ietf.org/html/draft-westerlund-tsvwg-dtls-over-sctp-bis-01 Best regards Michael > > > I hope this is useful, > > Cheers, > > Rick van Rein > > ___ > 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/SCTP and fragmentation
Hi, Larger frames than the MTU are not just a problem to Diameter; they also complicate the normal handshake in DTLS which is a bit of a misfit with DTLS delivery semantics. Since the version is bit-swapped in DTLS, each record can easily be distinguished as being either DTLS or TLS. Then, why not allow the mixing of those records in a stream, and map them differently to the transport protocol? I suppose the records could be marked as being the first and/or last in a large user message, and this could be meaningfully translated to properties and behaviour of the transport. Below the DTLS MTU, information is sent as DTLS, and above it, it is sent as a sequence of TLS frames -- or are rejected, if the transport cannot handle that. Plain TLS could be a special case where the DTLS MTU is set to 0. Datagrams may have a number of meanings, too, that translate to different transport meanings. Diameter differs from RTP in that it wants reliable delivery (which is why it does not carry over UDP) but it is like RTP in that it does not want ordered delivery. Plain TLS applications would present the usecase of reliable ordered delivery. Hopefully helpful, -Rick ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
